2. AWS身份与访问管理基础

AWS Identity and Access Management（IAM）是AWS账户内所有访问控制的根基。它并不直接保护数据本身，而是回答一个核心问题：谁，在什么条件下，可以对哪个资源执行什么操作。理解IAM的五个基本构件——用户、组、角色、策略、权限边界——以及访问密钥的管理方式，是后续学习S3、KMS、RDS等具体服务安全配置的前提。

一、五个核心构件的关系

IAM用户（User）代表一个长期存在的身份，通常对应一名员工、一个应用程序或一个运维脚本。IAM组（Group）是用户的集合，用于批量授予权限，组不能嵌套组，也不能被直接授予资源访问权，它只是权限的载体。IAM角色（Role）是一种临时身份，没有固定密码或长期密钥，由受信任的实体（如EC2实例、Lambda函数、另一个AWS账户或联合身份用户）通过STS服务扮演，获得有效期通常为15分钟到12小时的临时凭证。IAM策略（Policy）是JSON格式的权限声明文档，定义允许或拒绝的操作。权限边界（Permissions Boundary）则是一道“天花板”，用于限制某个用户或角色最多能拥有多少权限，即使其附加的策略允许更多操作，也不能突破边界。

这五个构件的关系可以用下面的结构图表示：用户和角色是“被授权主体”，组用于聚合用户，策略是“权限内容”，权限边界是“权限上限”，访问密钥则是用户或角色访问AWS API的凭证形式之一。

二、策略的语法与评估逻辑

一条IAM策略由若干语句（Statement）组成，每条语句包含Effect（Allow或Deny）、Action（操作，如s3:GetObject）、Resource（资源ARN）、Condition（可选条件）等字段。AWS的权限评估遵循明确的优先级：显式Deny > 显式Allow > 默认Deny。也就是说，只要有一条策略显式拒绝了某个操作，无论其他策略是否允许，最终结果都是拒绝。如果没有任何策略允许，默认也是拒绝。

下面是一个允许读取特定S3桶中对象的策略示例，同时通过Condition限制只能从公司IP段访问：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromCorpIP",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-data-bucket",
        "arn:aws:s3:::example-data-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

这里Resource字段需要同时列出桶本身（用于ListBucket）和桶内对象（用于GetObject），因为这是两个不同的资源层级。Condition中的aws:SourceIp是全局条件键，表示请求来源IP必须落在指定CIDR范围内，否则即使策略允许也会被拒绝。

三、权限边界的作用与典型用法

权限边界本身也是一条策略，但它不授予权限，只限制权限的上限。一个用户或角色最终的有效权限是“身份策略允许的操作”与“权限边界允许的操作”的交集。例如，某开发人员的身份策略允许ec2:*，但权限边界只允许ec2:Describe*和ec2:StartInstances，那么他实际只能执行描述和启动实例，无法终止或修改实例。

权限边界常用于两种场景：一是将创建IAM用户或角色的权限下放给团队负责人，同时用边界确保他们不能创建出权限过大的身份；二是对第三方或临时人员设置硬性上限，防止权限蔓延。需要注意的是，权限边界不适用于AWS账户的根用户，也不适用于服务关联角色。

四、访问密钥的创建与管理

访问密钥由Access Key ID和Secret Access Key组成，用于通过AWS CLI、SDK或API以编程方式访问AWS。创建访问密钥的典型流程是：在IAM控制台选择用户 → 安全凭证 → 创建访问密钥 → 下载或复制密钥对。Secret Access Key只在创建时显示一次，之后无法再次查看，必须妥善保存。

访问密钥的管理应遵循以下原则：不为根用户创建访问密钥；为每个应用程序或脚本使用独立的IAM用户或角色，避免多人共用同一密钥；定期轮换密钥，建议每90天更换一次；使用IAM Access Analyzer或凭证报告识别长期未使用的密钥并及时禁用或删除。对于运行在EC2、Lambda、ECS等AWS计算服务上的应用，应优先使用IAM角色而非长期访问密钥，因为角色提供的临时凭证会自动轮换，无需人工管理。

五、组、角色与用户的选择建议

在实际设计中，可以遵循以下判断逻辑：如果是一个长期存在的人类用户，需要控制台登录或编程访问，使用IAM用户并加入组；如果是一个AWS服务需要访问其他AWS资源，使用IAM角色；如果是跨账户访问或联合身份登录，使用角色配合信任策略；如果需要批量管理多个用户的相同权限，使用组来附加策略，而不是逐个用户配置。

下表对比了用户、组、角色在几个关键维度上的差异，便于快速选择：

掌握这些基础构件之后，后续在配置S3桶策略、KMS密钥策略、RDS访问控制时，就能清楚地区分“身份策略”和“资源策略”各自的作用范围，以及它们如何共同决定一次请求的最终结果。