为何启用MFA会话后IAM策略仍拒绝S3与SSM访问？

你的核心问题大概率是IAM策略的条件逻辑写反，或者缺少明确的Allow授权，以下是具体拆解：

1. 策略条件逻辑错误（最可能） #

如果你的DenyAllExceptListedIfNoMFA策略中，Condition判断的是aws:MultiFactorAuthPresent: "true"而非"false"，会导致启用MFA会话时反而触发Deny规则——即当用户有MFA时，拒绝所有不在NotAction列表中的操作，这正好匹配你遇到的现象：添加S3/SSM操作到NotAction后，这些操作不再被Deny，就能正常执行。

正确的MFA强制策略逻辑应该是：仅当用户没有MFA会话时，拒绝除必要操作外的所有行为，对应的Condition应该是：

"Condition": {
  "BoolIfExists": {
    "aws:MultiFactorAuthPresent": "false"
  }
}

BoolIfExists确保即使会话中没有aws:MultiFactorAuthPresent变量（比如用长期密钥直接登录），也会触发Deny。

2. 缺少对应的Allow策略 #

IAM的默认权限是拒绝所有操作，你的Deny策略只是在无MFA时限制操作，但当有MFA会话时，Deny规则不触发，此时仍需要明确的Allow策略授权S3/SSM操作。

如果你的用户仅绑定了这一条Deny策略，即使MFA会话正常，也会因默认拒绝无法执行S3/SSM操作。而将这些操作加入NotAction后，它们不受Deny规则限制，但如果没有Allow策略，理论上仍无法执行——除非你的用户继承了其他隐含权限（比如管理员组），但你明确说明仅应用该策略，所以这条可能性较低。

3. MFA会话未正确建立 #

确认你的MFA会话是通过以下方式正确创建的：

• 控制台登录：必须完成MFA验证码验证步骤
• CLI/SDK：使用aws sts get-session-token --serial-number <你的MFA设备ARN> --token-code <MFA验证码>获取临时凭证，而非直接使用长期Access Key/Secret Key登录

如果未正确建立MFA会话，aws:MultiFactorAuthPresent会被标记为false，导致Deny规则依然触发。

验证方法 #

1. 检查策略的Condition部分，确认是判断aws:MultiFactorAuthPresent为false而非true
2. 使用aws sts get-caller-identity --debug查看会话中的aws:MultiFactorAuthPresent变量值，确认MFA会话已激活
3. 若仅使用Deny策略，需补充对应的Allow策略授权S3/SSM操作（比如添加一条允许s3:*、ssm:StartSession等操作的策略）

内容的提问来源于stack exchange，提问作者Vincent Verbist