📚 课程目录第4章最小权限原则

4. 最小权限原则：云上访问控制的“金标准”

聊到云上数据保护，有个原则我几乎每次培训都会强调——最小权限。说白了，就是给每个身份只分配刚刚好的权限，多一分都不给。

你想想看，如果公司里每个人都拿着总经理的万能门禁卡，那数据泄露只是时间问题。我在项目中见过太多因为权限过大导致的惨案了。嗯，这一章我们就来彻底搞懂它。

核心观点：最小权限不是限制业务，而是用技术手段把“能做什么”和“该做什么”画上等号。

4.1 为什么说它是“金标准”？

云环境里，权限就是攻击者的第一目标。一旦某个角色权限过大，被攻破后整个数据湖都可能被拖走。我个人习惯把权限设计比作“洋葱模型”——一层层剥开，每一层都只暴露必要的东西。

我曾经帮一家金融客户做审计，发现他们的一个测试账号居然有生产库的删除权限。问了一圈，没人知道这个权限什么时候开的。这就是典型的“权限膨胀”。

攻击面缩小：权限越小，被利用的路径越少。
合规要求：GDPR、等保2.0都明确要求最小化授权。
故障隔离：误操作的影响范围可控。

4.2 IAM 策略设计：从粗放走向精细

IAM 策略是权限的“法律条文”。写得好，系统稳如泰山；写得烂，处处是漏洞。

4.2.1 策略结构拆解

一个标准的 IAM 策略包含几个核心要素：

要素	说明	常见坑点
Effect	Allow 或 Deny	Deny 优先级高于 Allow，容易误伤
Action	具体操作，如 s3:GetObject	滥用通配符 *，导致权限过大
Resource	操作对象，如 arn:aws:s3:::my-bucket/*	不指定资源，等于开放所有资源
Condition	附加条件，如 IP 限制、MFA 要求	条件写错导致策略失效

我的习惯：写策略时，先写 Deny 再写 Allow。Deny 用来兜底，比如禁止删除日志。Allow 只开最小集合。这样即使 Allow 写漏了，Deny 还能挡一下。

4.2.2 策略设计最佳实践

拒绝通配符滥用：Action 里尽量不用 *。比如只给 s3:GetObject，而不是 s3:*。
资源级限定：Resource 要精确到桶、目录甚至对象前缀。
条件限制：加上 aws:SourceIp 或 aws:MultiFactorAuthPresent。
使用托管策略：AWS 的 ReadOnlyAccess 等托管策略可以作为起点，但必须裁剪。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::data-lake-prod/processed/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/16"
        }
      }
    }
  ]
}

这个策略只允许从内网 IP 读取生产数据湖中 processed 目录下的对象。你看，权限被锁得很死。

4.3 角色与用户组管理：组织权限的正确姿势

直接给单个用户挂策略？我建议你千万别这么干。管理成本太高了，而且容易失控。

4.3.1 用户组：权限的“模板”

用户组就是权限的集合。把相同职能的人放进一个组，然后给组授权。比如：

DataEngineer-Group：可以读写数据湖，但不能删除。
DataAnalyst-Group：只能读取已处理的数据。
Admin-Group：可以管理 IAM 和资源，但需要 MFA。

我曾经接手过一个项目，200 多个用户每个都有独立的策略。后来我花了整整两周，把所有策略合并成 8 个用户组。权限清晰了，审计也轻松了。

4.3.2 角色：跨账号和临时授权的利器

角色不是给“人”用的，而是给“场景”用的。比如：

跨账号访问：开发账号的角色可以切换到生产账号的只读角色。
服务间授权：EC2 实例通过角色获取访问 S3 的权限。
外部身份联合：企业 AD 用户通过角色映射到云上权限。

注意：角色的信任策略一定要写严谨。我曾经见过一个角色信任了 * 主体，结果任何账号都能代入这个角色。这是灾难级的配置错误。

4.4 临时凭证（STS）：动态权限的终极方案

长期密钥（Access Key）就像家里的备用钥匙——放久了容易丢。临时凭证（STS）则像酒店房卡，到期自动失效。

4.4.1 STS 的工作原理

STS 的核心是“请求-颁发-使用-过期”四个步骤：

用户或服务向 STS 服务发起请求。
STS 验证请求者的身份和权限。
颁发临时凭证（包含 AccessKeyId、SecretAccessKey、SessionToken）。
凭证在指定时间内有效（最短 15 分钟，最长 36 小时）。

# 使用 AWS CLI 获取临时凭证
aws sts assume-role \
  --role-arn "arn:aws:iam::123456789012:role/DataReadOnlyRole" \
  --role-session-name "DataAnalysisSession" \
  --duration-seconds 3600

这个命令会返回一组临时凭证，有效期为 1 小时。过期后，任何使用该凭证的请求都会被拒绝。

4.4.2 最佳实践

缩短有效期：能设 15 分钟就别设 1 小时。我一般默认 30 分钟。
结合 MFA：要求用户代入角色前必须通过 MFA 验证。
审计日志：开启 CloudTrail 记录所有 STS 调用，方便追溯。
避免硬编码：临时凭证也不要写在代码里。用实例元数据或 Secrets Manager 获取。

我的经验：在 CI/CD 流水线中，我强制所有部署操作都使用 STS 临时凭证。这样即使流水线被攻破，攻击者拿到的凭证也只能用几分钟，根本来不及做坏事。

4.5 避免权限过大的坑

这些年我踩过不少坑，挑几个典型的分享给你：

坑一：给 Lambda 执行角色挂了 AdministratorAccess。结果一个函数被注入，整个账号被删了两个 S3 桶。后来我强制所有 Lambda 角色必须通过策略审核才能上线。
坑二：使用 Resource: "*" 配合 Action: "s3:ListAllMyBuckets"。这个组合看起来无害，但结合其他策略可能泄露桶列表。
坑三：忘记设置 Condition。比如允许 ec2:TerminateInstances 但没有限制实例标签，结果误终止了生产实例。

避坑指南：我曾经因为一个角色的信任策略没写 sts:ExternalId，导致第三方服务商能代入我们的角色访问内部数据。从那以后，所有跨账号角色必须加上 ExternalId 校验。

4.6 知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以把它当作一个检查清单：

这张图展示了最小权限的四个支柱：策略设计、角色与用户组、临时凭证、以及避坑指南。每个支柱下面还有具体的实践要点。你可以把它打印出来贴在工位上。

4.7 小结

最小权限原则听起来简单，做起来需要持续投入。我建议你从今天开始，做一次权限审计：

检查所有 IAM 策略中是否有 * 通配符。
确认每个角色是否都有明确的信任策略。
把长期密钥换成 STS 临时凭证。