IAM 策略评估逻辑完全解析 - 隐式 Deny 优先于显式 Allow 的机制
逐步解析 IAM 在允许或拒绝请求时的评估流程，涵盖隐式 Deny、显式 Allow、显式 Deny 的优先级，以及 SCP、权限边界、会话策略的交叉判定。
IAM 的评估结果只有三种
IAM 的策略评估看似复杂，但最终结果只有显式 Deny、显式 Allow 和隐式 Deny 三种。优先级始终为显式 Deny > 显式 Allow > 隐式 Deny。隐式 Deny 是指任何策略中都未记述 Allow 的状态。IAM 默认拒绝所有操作，因此未显式 Allow 的操作会被隐式拒绝。显式 Deny 是在策略中明确记述了 Effect: Deny 的状态，即使其他策略中有 Allow 也会被拒绝。
同一账户内的评估流程
同一账户内的策略评估是按顺序评估多种策略类型的多阶段过程。首先评估 Organizations 的 SCP (Service Control Policy)。SCP 作为组织账户的天花板，SCP 中未允许的操作即使在账户内任何策略中 Allow 也会被拒绝。接下来评估资源策略（S3 存储桶策略、KMS 密钥策略等）。在同一账户内，资源策略的 Allow 可单独授予访问权限。然后评估权限边界（如已设置）。最后评估身份策略。
SCP 与权限边界的交叉判定
SCP 和权限边界都是设置允许上限的机制，但应用级别不同。SCP 在 Organizations 的账户级别，权限边界在 IAM 实体（用户/角色）级别。两者都设置时，最终允许的操作是 SCP 允许 AND 权限边界允许 AND 身份策略允许的交集。任何一层缺少 Allow 都会导致拒绝。这种多层防御结构确保即使某一层配置错误，其他层也能防止过度权限。
条件键评估 - 容易忽视的陷阱
IAM 策略的 Condition 块是基于请求属性（源 IP、请求时间、标签值等）控制访问的强大功能，但评估逻辑中存在陷阱。最常见的误解是条件键不存在时的行为。例如设置了 aws:SourceIp 条件限制访问的策略时，来自 AWS 服务的内部调用（Lambda 访问 S3 等）不包含 SourceIp，条件评估为 false，访问被拒绝。解决方案是使用 IfExists 条件运算符或 Null 条件。
跨账户访问的评估规则
跨账户访问的评估规则与同一账户内不同。当账户 A 的主体访问账户 B 的资源时，需要账户 A 端的身份策略和账户 B 端的资源策略双方都有 Allow。在同一账户内，仅资源策略的 Allow 即可授予访问权限，但跨账户时这种单方允许不成立。例外是当资源策略中指定了具体的 IAM 角色 ARN 时，该角色无需身份策略中的 Allow 即可访问（仅限部分服务）。