Multi-Account Access After Acquisitions
A healthcare SaaS company has 140 AWS accounts in Organizations after two acquisitions. Developers currently use long-lived IAM users with AdministratorAccess; 22 access keys were found in public repositories last quarter. Compliance requires MFA, least privilege, and no long-lived credentials for human access. There are three production accounts, 60 developers who need read-only production access, and 12 senior engineers who need time-bound break-glass access during incidents. The identity team uses Okta and wants a single sign-on experience. The security team also wants to prevent any account from leaving the organization or enabling root access keys. A recent audit found 9 former employees still active. The company must preserve a 15-minute incident response capability and keep an audit trail for 400 days.
1. Design human access for developers and production read-only users. Explain how it removes long-lived credentials.
Read the worked answer
Recommendation: use IAM Identity Center federated with Okta as the single sign-on source, assign permission sets to groups, and remove human IAM users. Developers get read-only production access through a dedicated permission set; non-production access can be broader but still scoped by group.
Reasoning: Long-lived IAM users and access keys are the root cause of the public repository exposure. Identity Center issues short-lived credentials through SAML/SCIM, so Okta deprovisioning removes access without hunting for individual IAM users. Map Okta groups to Identity Center groups rather than assigning permissions per person, or 60 developers become unmanageable. Use separate permission sets for production read-only and non-production power-user access, and attach them to the three production accounts through account assignments. The tradeoff is that Identity Center adds a dependency on Okta availability; document a break-glass path for identity outages. Also enable MFA in Okta and require it in Identity Center. The 9 former employees likely remain because accounts were created locally; SCIM deprovisioning and an access review fix that.
2. How should break-glass access work for the 12 senior engineers without creating a permanent backdoor?
Read the worked answer
Recommendation: create a dedicated break-glass IAM role in each production account, trusted by a tightly controlled identity source, requiring MFA and a ticket or incident reference. Limit session duration to one hour, log the session, and alert the security team on assumption.
Reasoning: Incident response needs a path that does not depend on normal approval workflows, but that path must be exceptional and visible. A permanent administrator IAM user would recreate the original problem. A role with short session duration and MFA gives time-bound access; CloudTrail logs the role assumption and actions, and EventBridge can notify SecOps immediately. Use a separate role rather than adding break-glass permissions to the normal developer permission set, so routine access does not become administrative. The tradeoff is that an on-call engineer may need to find the procedure during an incident, so test it quarterly and keep a printed or offline runbook. Do not let the break-glass role create access keys or modify organization-level controls.
3. Which SCPs and remediation steps should be applied to prevent organization exit and root access keys?
Read the worked answer
Recommendation: apply SCPs at the organization root that deny organizations:LeaveOrganization, deny iam:CreateAccessKey when the principal is the account root, and deny disabling CloudTrail or GuardDuty in production accounts. Remediate existing keys before enforcing the deny.
Reasoning: SCPs are guardrails, not identity policies; they limit what any principal in a member account can do, including the root user. The condition for root access keys should use the account root ARN so normal IAM users are not blocked unnecessarily. Denying LeaveOrganization prevents an acquired account from escaping controls. Remediation must come first: inventory keys, disable and rotate them, move application secrets to Secrets Manager, and enable GuardDuty and CloudTrail organization trails. The tradeoff is that a strict SCP can break a legitimate automation that still uses root; identify those cases first. Keep CloudTrail logs in a central archive with 400-day retention, and test SCPs in a sandbox account before production.