A security team has discovered an IAM role that is configured with a broad trust policy, allowing principals from another AWS account to assume it without any conditions. The role also has an attached policy that grants extensive permissions, including 'ec2:*' and 's3:*'. The team needs to immediately revoke access for the external account and implement a more secure configuration for future cross-account access, requiring MFA for any assumption of this role. Which two actions should the security team take?
- ASet a global IAM password policy requiring MFA for all IAM users in the account.
- BModify the trust policy of the IAM role to remove the external account from the 'Principal' element and add a 'Condition' requiring 'aws:MultiFactorAuthPresent': 'true'.
- CDetach the broad permissions policy ('ec2:*', 's3:*') from the IAM role and attach a new, more restrictive policy.
- DCreate an AWS Organizations Service Control Policy (SCP) to explicitly deny 'sts:AssumeRole' for the external account.
Show answer & explanationAnswer & explanation
Correct answer: B. Modify the trust policy of the IAM role to remove the external account from the 'Principal' element and add a 'Condition' requiring 'aws:MultiFactorAuthPresent': 'true'.
Modifying the trust policy to remove the external account immediately revokes its ability to assume the role. Adding the 'Condition' requiring MFA ensures that any *future* trusted principals assuming the role must use MFA, fulfilling the secure configuration requirement. Detaching the broad permissions policy would be a separate, good practice for least privilege, but doesn't *immediately* revoke the external account's ability to assume the role, nor does it enforce MFA.
Why the other options are wrong
- A. A global IAM password policy applies to IAM users, not directly to roles being assumed cross-account, and it doesn't enforce MFA for role assumption itself, only for login by IAM users.
- C. While detaching the broad permissions policy is a good security practice (least privilege), it doesn't immediately revoke the external account's ability to assume the role itself, nor does it enforce MFA for future assumptions.
- D. An SCP would deny 'sts:AssumeRole' for the external account, but it's an organization-level control and might not be the most immediate or precise way to revoke access for a *single* role. It also doesn't enforce MFA for *trusted* principals.
IAM Role Trust Policy Conditions
Conditions in an IAM role's trust policy add constraints that must be met for a principal to successfully assume the role, such as requiring MFA or specific source IPs.
- Refine when `sts:AssumeRole` is allowed.
- Can include `aws:MultiFactorAuthPresent` to enforce MFA.
- Applied at the time of role assumption.
Memory trick: Trust policy conditions gate role assumption with MFA.