4、云身份与访问管理：IAM 核心概念、用户与组管理、角色与权限策略、最小权限原则

4.1 IAM 到底是什么？

说实话，很多刚接触云安全的朋友，一上来就被 IAM 的各种术语搞懵了。我当年也一样。

IAM，全称是 Identity and Access Management。说白了，就是「谁」能对「什么资源」做「什么操作」。就这么简单。

你想想看，在传统机房里面，我们靠的是防火墙、VPN、物理隔离。但在云上，一切都变了。你的服务器、数据库、存储桶，全都在同一个大池子里。如果没有 IAM，那就像把自家大门钥匙挂在门口——谁都能进。

我个人习惯把 IAM 比作一个公司的门禁系统：

• 你是谁？——身份（用户、组、角色）
• 你能进哪扇门？——资源（云服务、API、存储）
• 你能做什么？——权限（读、写、删、管理）

嗯，这里要注意：IAM 不是某个单一功能，而是一整套体系。它涵盖了身份认证（Authentication）和授权（Authorization）两个层面。认证是「证明你是你」，授权是「你来了，能干啥」。

4.2 用户与组管理：别让每个人都拿管理员钥匙

我在项目中遇到过最典型的问题是什么？就是「一人一账号，权限全放开」。很多团队图省事，直接给每个开发人员配一个管理员账号。结果呢？某天有人误操作，把整个生产数据库删了……

所以，用户管理的第一条铁律就是：每个使用者必须有独立的 IAM 用户。不要共享账号，不要用根用户（Root User）做日常操作。

那组（Group）是干嘛用的？说白了就是批量管理权限的工具。你想想看，如果公司有 50 个开发人员，每个人都要配一样的权限，你一个个配？累不累？

我建议这样设计：

组名	成员	典型权限
Developers	开发工程师	EC2 启动/停止、S3 读写、日志查看
DevOps	运维工程师	全量管理权限（除 IAM 外）
Auditors	审计人员	只读权限、日志查看
DBAs	数据库管理员	RDS 管理、备份恢复

把用户加到组里，权限自动继承。哪天有人离职了，直接从组里移除就行。干净利落。

4.3 角色与权限策略：这才是 IAM 的精髓

用户和组管的是「人」。但云上还有「非人」的东西——比如 EC2 实例、Lambda 函数、容器。它们也需要访问其他云资源。这时候，角色（Role）就派上用场了。

角色和用户最大的区别是什么？角色没有长期凭证（密码或 Access Key）。它是临时「借用」权限的。你想想看，一个 EC2 实例要读取 S3 里的配置文件，总不能把 Access Key 硬编码在代码里吧？那太危险了。

正确的做法是：给这个 EC2 实例绑定一个 IAM 角色，角色里写好权限策略。实例启动时自动获取临时凭证，用完就失效。

权限策略（Policy）是什么呢？它是一段 JSON 文本，定义了「允许」或「拒绝」哪些操作。举个例子：

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

这段策略的意思是：允许读取 my-company-config 这个桶里的所有对象。注意看，我用了通配符 *，但只限定在特定桶里。这就是精细控制。

我曾经见过一个团队，策略里写的是 "Resource": "*"，结果一个开发人员不小心把整个公司的备份数据全删了。嗯，血的教训。

4.4 最小权限原则：少即是多

最小权限原则（Principle of Least Privilege）是 IAM 的基石。说白了就是：每个身份只拥有完成工作所必需的最小权限集。

怎么落地呢？我总结了一个三步法：

1. 先拒绝，再允许。 默认情况下，所有权限都是隐式拒绝的。你只需要显式允许必要的操作。
2. 从宽到窄。 刚开始可以给一个相对宽松的策略，然后通过日志分析（比如 CloudTrail）看看实际用了哪些 API，再逐步收紧。
3. 定期审计。 每季度检查一次 IAM 策略，把那些「僵尸权限」清理掉。

我记得有一次帮客户做安全审计，发现一个 IAM 用户居然有 3 年没登录了，但他的权限还是「管理员」级别。这种账号一旦被攻破，后果不堪设想。

另外，我建议使用「条件键」（Condition Keys）来进一步限制权限。比如：

{
  "Effect": "Allow",
  "Action": "ec2:TerminateInstances",
  "Resource": "*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": "10.0.0.0/8"
    }
  }
}

这段策略的意思是：只有来自内网 IP 的请求才能终止 EC2 实例。就算你的 Access Key 泄露了，攻击者从外网也干不了坏事。

4.5 避坑指南：我踩过的那些坑

最后，分享几个我亲身踩过的坑，希望能帮你少走弯路：

• 别用根用户。 创建完账号后，立刻给根用户启用 MFA，然后锁起来。日常操作全用 IAM 用户。
• 别把 Access Key 写在代码里。 用 IAM 角色或者 Secrets Manager 来管理凭证。
• 别给「*」权限。 哪怕只是临时测试，也要写具体的 Resource ARN。否则很容易忘记回收。
• 别忽略「拒绝」的效果。 显式拒绝（Deny）的优先级高于允许（Allow）。可以用它来做「安全护栏」。

我曾经有一次，为了图方便，给一个 Lambda 函数绑定了「AdministratorAccess」策略。结果这个函数被外部触发了，攻击者通过它创建了一个新的管理员用户……嗯，从那以后，我再也不敢偷懒了。

好了，这一章的内容就到这里。IAM 是云安全的基石，花再多时间学习都值得。下一章我们会聊聊「网络隔离与安全组」，敬请期待。