wangqifan/aws-doc

Fork 0

wangqifan a80067d684 all

2026-05-08 10:24:39 +08:00

5.8 KiB

Raw Permalink Blame History

第20天：IAM 策略深入——精确控制权限

今天你将学到什么

第 6 天我们学了 IAM 的基本概念。今天深入学习 IAM 策略的编写——它是一份 JSON 格式的"权限清单"，精确定义"谁能对什么资源做什么操作"。

策略长什么样

一个 IAM 策略就是一段 JSON 文本。别被 JSON 吓到，它的结构其实很简单：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-photos/*"
    }
  ]
}

翻译成人话：允许从 my-photos 这个 S3 桶里下载文件。

策略的四个核心要素

每条策略声明（Statement）回答四个问题：

1. Effect（效果）：允许还是拒绝？

只有两个值：

"Allow" — 允许
"Deny" — 拒绝

2. Action（操作）：能做什么？

格式是 服务名:操作名，比如：

s3:GetObject — 从 S3 下载文件
s3:PutObject — 往 S3 上传文件
ec2:StartInstances — 启动 EC2 实例
ec2:TerminateInstances — 终止（销毁）EC2 实例
rds:CreateDBInstance — 创建 RDS 数据库

通配符：

s3:* — S3 的所有操作
ec2:Describe* — EC2 所有以 Describe 开头的操作（都是只读查询）
* — 所有服务的所有操作（超级危险！）

3. Resource（资源）：对什么东西？

用 ARN（Amazon Resource Name）指定具体资源：

arn:aws:服务:区域:账户ID:资源

举例：

arn:aws:s3:::my-photos/* — my-photos 桶里的所有文件
arn:aws:ec2:ap-northeast-1:123456789012:instance/i-abc123 — 东京区域的某台特定 EC2
* — 所有资源（谨慎使用！）

4. Condition（条件）：在什么条件下？（可选）

添加额外的限制条件，比如：

只在工作时间允许
只从公司 IP 地址允许
必须使用 MFA 验证后才允许

用生活例子理解策略

例子 1：实习生的权限

"允许实习生查看所有 S3 桶的文件列表，但不能下载、上传或删除任何文件"

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:ListAllMyBuckets"
      ],
      "Resource": "*"
    }
  ]
}

就像给实习生一把只能看目录的权限——能看到有什么文件，但打不开。

例子 2：开发者的权限

"允许开发者对测试环境的 EC2 做任何操作，但不能碰生产环境"

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "test"
        }
      }
    }
  ]
}

只有标签为 Environment=test 的 EC2 实例才能操作。生产环境的实例（Environment=production）碰不了。

例子 3：安全红线

"无论如何，任何人都不能删除生产数据库"

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "rds:DeleteDBInstance",
      "Resource": "arn:aws:rds:*:*:db:production-*"
    }
  ]
}

即使某人有 AdministratorAccess，这条 Deny 规则也会阻止他删除生产数据库。因为 Deny 永远优先于 Allow。

策略评估逻辑

当你在 AWS 上做一个操作时，系统怎么判断你有没有权限？

第一步：默认拒绝（什么权限都没有）
    ↓
第二步：查找所有适用的策略
    ↓
第三步：有没有显式的 Deny？
    ├── 有 → 最终结果：拒绝（到此结束，Deny 最大）
    └── 没有 ↓
第四步：有没有显式的 Allow？
    ├── 有 → 最终结果：允许
    └── 没有 → 最终结果：拒绝（默认拒绝）

记住三句话：

默认所有操作都被拒绝
需要显式的 Allow 才能做事
任何地方有 Deny 就一定被拒绝（Deny 优先级最高）

AWS 托管策略 vs 自定义策略

AWS 托管策略：AWS 预先写好的常用策略，开箱即用。

常用的有：

策略名	权限范围
AdministratorAccess	所有服务所有操作（万能钥匙）
PowerUserAccess	除了 IAM 之外的所有权限
ReadOnlyAccess	所有服务的只读权限
AmazonS3FullAccess	S3 的完全权限
AmazonS3ReadOnlyAccess	S3 的只读权限
AmazonEC2FullAccess	EC2 的完全权限

自定义策略：你自己写的策略，可以精确到具体的资源和操作。

建议：

学习阶段用 AWS 托管策略（方便）
生产环境写自定义策略（精确控制，最小权限）

常见错误和调试

错误信息：Access Denied（访问被拒绝）

排查步骤：

确认你用的是哪个 IAM 用户/角色
检查这个用户/角色附加了哪些策略
策略里有没有覆盖你要做的操作和资源
有没有 Deny 规则在阻止你

调试工具：

IAM Policy Simulator：模拟测试策略效果，不用真的去执行操作
CloudTrail：查看被拒绝的 API 调用详情

今天的小测验

一个 IAM 策略的四个核心要素是什么？
如果一个用户同时有一条 Allow 规则和一条 Deny 规则针对同一个操作，最终结果是什么？
"Action": "s3:*" 和 "Action": "*" 有什么区别？
为什么生产环境不建议用 AdministratorAccess？

明天预告

明天学习 IAM 角色的高级用法：跨账户访问、服务角色、联合身份。理解企业环境中如何安全地管理多个账户和外部用户的访问。

5.8 KiB Raw Permalink Blame History Unescape Escape