IAM基础概念：用户、组、角色、策略

说到IAM，很多刚接触云计算的朋友会觉得它挺虚的。就是一个权限系统嘛，有什么好讲的？其实不然。我见过太多因为权限配置不当导致的数据泄露事故了。说白了，IAM就是你AWS账户的“门禁系统”。

这一章，我们来聊聊IAM最核心的几个概念。我个人习惯把IAM拆成四个部分来看：用户、组、角色、策略。它们之间的关系，就像公司的门禁卡系统。

IAM核心组件概览

在深入每个概念之前，我们先看一张图。这张图我画了好几年，每次培训都会拿出来用。它能帮你快速建立IAM的知识框架。

用户（User）

用户，就是你创建的一个“人”的身份。你在AWS控制台里登录用的那个账号，其实就是root用户。但咱们一般不直接用root，它太危险了。

我建议你创建IAM用户给团队成员用。每个用户都有一个名字，一组密钥（AK/SK），和一个密码。用户能干什么？全靠附加在它身上的策略说了算。

我记得有一次，一个开发同事问我：“为什么我的EC2启动不了？” 查了半天，原来是他用的IAM用户没有ec2:RunInstances的权限。嗯，权限这事儿，真不能想当然。

组（Group）

组，就是把用户归到一起。比如说，你有一个“开发者”组，里面放着所有开发人员。你只需要给这个组加上策略，组里的所有成员就自动拥有了那些权限。

你想想看，这样多省事。如果公司来了个新人，你直接把他加到“开发者”组里就行，不用一个个去配置权限。

• 省时省力：批量管理，一劳永逸
• 减少错误：统一配置，避免漏配
• 便于审计：谁在哪个组，一目了然

角色（Role）

角色这个东西，刚接触时会觉得有点抽象。它没有用户名，也没有密码。它的本质是一个临时的身份。谁需要用它，谁就“扮演”它。

比如，你的一个EC2实例需要访问S3。你不能把IAM用户的密钥放到EC2里，太容易泄露了。怎么做？创建一个角色，给它S3的访问权限，然后把这个角色附加到EC2实例上。EC2启动时，会自动通过STS服务获取临时凭证。

我在项目中遇到过好几次，有人把长期密钥写死在代码里。后来出事了，才跑来问我。我告诉他们：用角色，临时凭证自动轮换，安全又省心。

策略（Policy）

策略，才是核心中的核心。它是一个JSON文档，描述了一组权限。AWS里有两种策略：

策略类型	说明	适用场景
托管策略	AWS管理或客户管理的策略，可复用	标准权限场景，如管理员、只读
内联策略	直接写在用户/组/角色上的策略	特殊场景，精细控制

来看看一个策略长什么样子：

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

策略里最关键的就是这几个部分：

• Effect： Allow 或者 Deny，决定了是允许还是拒绝
• Action： 具体的操作，比如 s3:ListBucket
• Resource： 操作的目标，比如哪个S3存储桶
• Condition： 额外条件，比如IP地址限制

为什么会这样设计？说白了，就是为了让你能精细控制。我曾经给一个金融客户配权限，要求只能从公司IP访问数据库。用Condition轻松搞定。

策略评估逻辑

这部分我刚开始也搞混过。AWS的策略评估有个默认规则：一切请求默认Deny，除非显式Allow。但如果你写了Deny，那Deny永远优先。

我简单总结一下：

举个例子。你有一个策略允许访问S3，另一个策略拒绝访问某个特定存储桶。不管你挂了多少个Allow策略，那个Deny就是最后的“一票否决权”。

嗯，这里要注意。多个策略之间是合并的。如果你挂了一个允许EC2的策略，又挂了一个允许S3的策略，用户就能同时操作EC2和S3。但只要有任何一个Deny存在，它就生效。

最佳实践：最小权限原则

讲到最后，我想聊聊“最小权限原则”。这是IAM里最重要的一条铁律。说白了就是：只给完成工作所需的最小权限。

很多人一上来就给AdministratorAccess，图省事。我见过这样出事的，也是因为这个才开始认真学IAM的。别偷懒，该细就细。

• 从宽到细：先给一个宽泛的策略，然后逐步收紧
• 多用托管策略： AWS帮你维护，减少配置错误
• 定期审计： 用IAM Credential Report检查哪些权限用得少