AWS IAM 细粒度访问控制 - 基于策略的设计实现最小权限原则
解析 AWS IAM 基于策略的访问控制设计思想，并与 Azure RBAC 和 GCP IAM 在粒度方面进行具体比较。
基于策略的设计这一根本思想
AWS IAM 最大的特点是将访问控制作为策略文档以 JSON 编写的设计。策略由 Effect（Allow/Deny）、Action（操作）、Resource（目标资源）、Condition（条件）四个要素构成。这种组合可以表达极其细粒度的权限。例如可以定义仅允许特定 S3 存储桶的特定前缀下的对象读取，且仅限从特定 VPC 端点访问时。这种粒度在其他云平台上难以实现。AWS IAM 的策略评估逻辑遵循明确的优先级：显式 Deny 优先于一切，无显式 Allow 则默认 Deny。这种默认拒绝的设计确保未明确授权的操作一律被阻止，是安全的基础。
条件键实现的上下文相关控制
决定性提升 AWS IAM 粒度的是 Condition 元素。组合全局条件键和服务特定条件键，可实现超越简单资源级控制的上下文相关访问控制。例如 aws:SourceIp 限制来源 IP 范围，aws:RequestedRegion 限制可操作的区域，aws:PrincipalOrgID 限制为组织内的主体。服务特定条件键更为强大。s3:prefix 限制可访问的对象前缀，ec2:ResourceTag 基于标签控制访问，rds:DatabaseEngine 限制可创建的数据库引擎。这些条件键的组合可实现数千种访问控制模式。权限边界（Permissions Boundary）是限制 IAM 实体可获得最大权限的机制。即使附加了 AdministratorAccess 策略，权限边界也能将实际有效权限限制在指定范围内。这在委托 IAM 管理时防止权限升级方面极为有效。
与 Azure RBAC 粒度的差异
Azure 的访问控制以 RBAC（Role-Based Access Control）为基础。Azure RBAC 将角色定义分配到作用域（管理组、订阅、资源组、资源）。角色定义包含允许的操作列表，分配到作用域后该作用域内的操作被允许。Azure RBAC 的粒度主要由作用域的层次结构决定。资源组级别的分配允许该资源组内所有资源的操作，资源级别的分配限制为特定资源。但 AWS IAM 的 Condition 键那样基于请求上下文的动态控制在 Azure RBAC 中表达困难。Azure 也有条件式访问（Conditional Access），但这主要用于认证层面的控制（MFA 要求、设备合规等），与 AWS IAM Condition 的资源操作级粒度不同。
与 GCP IAM 设计方法的差异
GCP IAM 采用基于角色的访问控制，有预定义角色、自定义角色、基本角色三种。GCP 的预定义角色为各服务细致准备，但不能像 AWS 那样在策略文档中任意组合 Action 和 Resource。GCP 的 IAM Conditions 支持基于资源属性和请求属性的条件控制，功能上接近 AWS 的 Condition 键。但支持的条件属性数量和表达力不及 AWS。GCP 的 IAM 设计优先简洁性。预定义角色覆盖大多数用例，自定义角色用于细粒度控制。这种方法学习曲线较低，但在需要复杂访问控制模式时灵活性不足。
实现最小权限的实践方法
要将最小权限原则从理论落实到实现，关键在于活用 AWS 提供的工具群。IAM Access Analyzer 分析 CloudTrail 日志，自动生成仅包含实际使用操作的策略。这使得从过度宽松的初始策略逐步收紧为最小权限策略成为可能。IAM Policy Simulator 可在不实际执行的情况下测试策略的评估结果。Service Control Policies（SCP）在组织级别设置权限上限，即使个别账户的 IAM 策略允许，SCP 禁止的操作也无法执行。这些工具的组合使最小权限不是一次性设置而是持续改进的过程。这正是 AWS IAM 基于策略设计的真正价值。如果想系统学习 IAM 设计模式，相关书籍 (Amazon) 也可供参考。
总结
AWS IAM 的基于策略设计通过 Action、Resource、Condition 的组合，实现了其他云平台难以达到的粒度访问控制。Azure RBAC 的角色分配模型简洁但在上下文相关控制方面灵活性有限。GCP IAM 优先简洁性但在复杂访问控制模式方面表达力不足。AWS IAM 的条件键、权限边界、SCP 的多层控制机制使最小权限原则从理论变为可实践的现实。访问控制的粒度和灵活性方面 AWS 明显领先。