在现代企业的云端架构中，安全始终是我们构建一切系统的基石。当我们的业务迁移到像 Amazon Web Services (AWS) 这样的云平台时，如何像管理公司办公室钥匙一样管理数字资源的访问权，就显得尤为关键。我们不能给每个人都能打开所有房间的“万能钥匙”，这不仅不安全，更是运营管理的大忌。
这就引出了我们今天要探讨的核心话题：AWS 身份和访问管理 (IAM)。在这篇文章中，我们将深入探讨如何利用 IAM 这一强大的系统，为不同的团队成员创建专属身份（即 IAM 用户），并根据他们的职能精准地分配最小权限。我们将从零开始，通过分步实操，一起掌握如何在 AWS 中创建用户、分配策略以及配置安全凭证。无论你是负责 DevOps 的工程师，还是正在学习云架构的学生，这篇指南都将帮助你建立起安全合规的云端访问习惯。
IAM 核心概念解析：为何我们需要它？
在动手操作之前，让我们先理解一下 IAM 的基本逻辑。想象一下，AWS 账户就像是一个银行账户，而 Root 用户（根用户）就是拥有无限权力的“银行行长”。这个账号可以删除所有服务、关闭所有服务器，甚至注销账户。因此，最佳实践告诉我们：除了极少数必须进行账单管理或紧急恢复的场景外，绝对不要在日常工作中使用 Root 用户。
我们需要做的，是为团队中的开发人员、运维人员甚至应用程序本身，创建属于他们自己的“普通员工身份证”，这就是 IAM 用户。我们将基于“最小权限原则”来配置这些身份证，确保开发人员只能访问他们负责的 EC2 实例，而无法无意中触数据库删除按钮。
第一步：准备工作与登录控制台
首先，我们需要准备好操作环境。请打开浏览器，访问 Amazon Web Services 官方网站并登录控制台。如果你还没有账号，可以注册一个 AWS Free Tier Account（免费层级账户），这对于我们学习和测试功能来说已经绰绰有余。
> 专业提示：在登录时，请务必确认你使用的是 Root 用户凭证（即创建账户时的邮箱和密码），因为只有 Root 用户才有权限去创建第一批 IAM 管理员。后续我们将不再使用此账号登录。
登录成功后，你会看到一个布满各种服务卡片的主控台。这里就是我们管理云世界的指挥中心。
第二步：定位 IAM 服务
在 AWS 庞大的服务家族中找到 IAM，就像在图书馆找一本书一样简单。我们可以直接使用顶部的全局搜索栏。
- 在搜索框中输入 "IAM"。
- 在下拉列表或搜索结果中，点击 "IAM" 服务进入。
此时，屏幕中央会出现 IAM 的控制面板。在这里，我们可以看到一个可视化的安全状态概览。不过，我们现在的重点是左侧导航栏中的“用户”选项。
第三步：创建 IAM 用户
点击左侧菜单中的“用户”，你会看到当前的 IAM 用户列表（如果是新账号，这里可能是空的）。为了添加新成员，我们点击右上角的蓝色按钮——“创建用户”。
这一步将启动一个多阶段的向导，AWS 将引导我们完成用户详细信息的配置。我们将这个过程分为三个关键阶段：指定用户详情、设置权限、以及审查与创建。
#### 阶段 i：指定用户详细信息
首先，我们需要给这个新用户起个名字。
- 用户名：在输入框中输入一个具有辨识度的名字，例如 INLINECODEcaedb220 或 INLINECODEabc07318。
> 实战见解：在起名时，建议遵循团队的命名规范，例如包含部门前缀。这在后期管理大量用户时非常有帮助。
#### 阶段 ii：设置权限 —— 权限的核心
这是创建过程中最关键的一步。在这里，我们决定这个用户能做什么，不能做什么。
AWS 提供了几种权限设置方式。对于初学者和标准流程来说，最直观的方式是 “直接附加策略”。策略 实际上就是一个 JSON 格式的文档，它详细定义了允许和拒绝的操作。
让我们来添加一个具体的权限：
- 在权限设置页面，点击“直接附加策略”。
- 在搜索框中输入
EC2ReadOnly。 - 在结果列表中找到名为
AmazonEC2ReadOnlyAccess的策略，并勾选它。
这个策略的作用是赋予用户只读访问 EC2 服务的权限。这意味着该用户可以查看服务器状态、启动或停止实例（视具体策略定义而定，ReadOnly通常仅限查看），但无法创建新的实例或删除现有的关键资源。
代码示例 1：策略的 JSON 本质
当我们选中 AmazonEC2ReadOnlyAccess 时，背后其实对应着一段 JSON 代码。理解这段代码有助于我们深入掌握权限控制。以下是该策略的一个简化逻辑示例：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:Get*"
],
"Resource": "*"
}
]
}
代码解析：
-
"Effect": "Allow"：这是允许的意思。 - INLINECODE293dcb1c：这里列出了具体的操作，如 INLINECODE12950e39 表示允许所有以“Describe”开头的 EC2 操作，即查看信息。
-
"Resource": "*"：表示该策略适用于所有 AWS 资源。
如果系统自带的策略无法满足你的需求（例如，你只想让用户访问特定的某一个存储桶 S3 Bucket），你就需要点击“创建策略”来编写自己的 JSON 文档。这属于进阶操作，但在实际的企业环境中非常常见。
#### 阶段 iii：审查并创建
在完成上述配置后，向导会带我们进入“审查”页面。这里就像是我们下单前的购物车确认。
- 核对信息：检查用户名是否拼写正确，勾选的策略是否正是我们想要的。
- 创建：确认无误后，点击页面底部的“创建用户”按钮。
几秒钟后，屏幕上会提示“创建成功”。至此，一个名为 IAM 用户的数字身份就已经在后台生成了。
第四步：配置登录凭证（安全凭证）
虽然用户身份已经创建，但现在的它只是一个“空壳”。为了让这个人能够真正登录 AWS 控制台，我们还需要给他一把“钥匙”——也就是登录密码。
请执行以下操作：
- 在用户列表中，点击刚刚创建的那个用户名。
- 在下方的详细信息选项卡中，点击 “安全凭证” 选项卡。
- 找到“控制台登录”部分，点击 “启用控制台登录”。
接下来是密码设置环节。这里有两种方式：
- 自定义密码：由管理员设置一个初始密码，告知用户后要求其首次登录时修改。
- 自动生成密码：系统生成一个高强度随机密码。
最佳实践：无论选择哪种方式，请务必勾选 “用户在下次登录时需要创建新密码”。这是强制用户重置密码的关键步骤，能有效防止凭证泄露后的长期风险。
代码示例 2：密码策略的严格要求
AWS 对密码有严格的复杂度要求。以下是一个符合 AWS 标准的密码正则表达式校验逻辑（用于理解 AWS 的后端校验规则）：
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$
解析：
-
(?=.*[a-z])：必须包含至少一个小写字母。 -
(?=.*[A-Z])：必须包含至少一个大写字母。 -
(?=.*\d)：必须包含至少一个数字。 -
(?=.*[@$!%*?&])：必须包含至少一个特殊字符。 -
{8,}：长度至少为 8 位。
设置完密码后，点击“应用”或“完成”。系统可能会提示你下载或者复制安全凭证文件（如果这是编程访问的 Access Key），对于控制台登录，你需要手动告知用户他的密码。
第五步：使用 IAM 用户登录
现在，所有设置已就绪。让我们换一个视角，看看作为新用户是如何登录的。
登录前的准备工作：你需要三个关键信息：
- AWS 账户 ID：这是一个 12 位数字的 ID。你可以通过点击右上角 Root 用户下拉菜单中的“我的账户”或在登录页面的提示中找到它。
- IAM 用户名：也就是我们在步骤三中创建的名字。
- 密码：刚刚设置的密码。
登录步骤：
- 也就是 AWS 的通用登录页面。
- 输入 AWS 账户 ID，然后点击下一步。
- IAM 用户登录页面会自动加载。这里输入 IAM 用户名 和 密码。
> 常见错误与解决方案：
> * 问题：登录时提示“账户不存在”。
> * 解决：请确认你是否输入了 Root 用户的邮箱。IAM 用户必须先输入账户 ID，然后切换到 IAM 登录界面，不能直接在 Root 界面输入 IAM 用户名。
进阶理解：访问密钥 与编程访问
除了我们在文中重点介绍的“控制台密码”，IAM 用户还经常需要“访问密钥”来通过代码（如 Python 的 Boto3 库，或 AWS CLI）与 AWS 交互。
代码示例 3：使用 AWS CLI 配置凭证
如果你为用户生成了 Access Key ID 和 Secret Access Key，你可以在本地终端通过以下命令配置环境，以便后续进行自动化运维操作：
# 执行配置命令
aws configure
# 系统会提示你输入以下信息：
# AWS Access Key ID: [输入你的 Key ID]
# AWS Secret Access Key: [输入你的 Secret Key]
# Default region name: cn-north-1 (或其他区域)
# Default output format: json
代码解析：
这行命令实际上是在本地目录下生成了一个名为 INLINECODE49c10809 的文件（通常在 INLINECODE6297205d 目录下）。这是一个纯文本文件，包含了你刚才输入的明文密钥。
> 安全警告：千万不要将 Access Key 写在代码里并上传到 GitHub 这样的公共代码仓库！这是导致 AWS 账户被盗刷的最常见原因。
性能优化与权限边界
在大型企业中，单纯给用户附加策略是不够的。为了防止权限过度扩张，AWS 引入了 Permissions Boundaries（权限边界）。这是一个高级概念，它为管理员设置了一道不可逾越的“红线”。
代码示例 4：使用 Terraform 定义 IAM 用户与策略（IaC 实践）
在现代 DevOps 实践中，我们很少手动点击按钮创建用户，而是使用基础设施即代码 工具，如 Terraform。以下是一个使用 Terraform 创建 IAM 用户并附加只读策略的完整示例：
# 1. 创建 IAM 用户
resource "aws_iam_user" "my_dev_user" {
name = "DevOps_Terraform_User"
tags = {
Environment = "Production"
ManagedBy = "Terraform"
}
}
# 2. 创建一个自定义只读策略（例如只读 S3）
resource "aws_iam_policy" "s3_readonly_policy" {
name = "S3ReadOnlyAccess_Custom"
description = "This policy grants read-only access to S3 buckets."
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = [
"s3:Get*",
"s3:List*"
]
Effect = "Allow"
Resource = "*"
}
]
})
}
# 3. 将策略附加到用户
resource "aws_iam_user_policy_attachment" "attach_s3_readonly" {
user = aws_iam_user.my_dev_user.name
policy_arn = aws_iam_policy.s3_readonly_policy.arn
}
代码深度解析：
-
resource "aws_iam_user"：定义了用户资源，名字是唯一的。 -
resource "aws_iam_policy"：这里我们不仅使用了系统策略，还展示了如何创建一个 JSON 格式的自定义策略。这个策略限制了用户只能对 S3 服务进行 Get 和 List 操作。 -
resource "aws_iam_user_policy_attachment"：这是将“人”和“规矩”绑定的桥梁。通过引用 ARN（Amazon Resource Name），我们将策略精确地挂载到了用户身上。
使用 IaC 的好处是，所有的权限变更是可追溯、可版本控制和可自动审计的。当你的团队从 5 个人扩张到 500 人时，手动点击控制台将无法维持安全和效率。
关键要点与后续步骤
通过这篇文章，我们不仅学会了如何在 AWS 中创建一个 IAM 用户并赋予其密码，更重要的是，我们理解了 IAM 在云安全中的核心地位。
回顾一下我们的成就：
- 规避风险：明白了 Root 用户的危险性，转而使用 IAM 用户进行日常操作。
- 精准授权：掌握了如何通过策略来限制用户的权限，确保“最小权限原则”的落地。
- 安全意识：了解了强密码策略和 Access Key 的安全处理方式。
- 自动化思维：接触了 Terraform 等工具在用户管理中的实际应用。
你可以尝试的后续挑战：
- 尝试创建一个自定义策略，只允许用户访问某个特定的 S3 存储桶，而不是所有 S3 资源。
- 探索 IAM Groups（用户组）。在实际工作中，我们通常不直接给用户分配策略，而是将用户加入一个“组”，然后给组分配策略。这样，当新员工入职时，只需将其加入“开发组”即可自动继承所有开发权限。
- 设置 MFA（多因素认证）。强制要求 IAM 用户在登录时提供手机或硬件 MFA 设备的验证码，这是保护账户安全的最后一道防线。
云端安全是一场持久战，创建 IAM 用户只是万里长征的第一步。希望你能带着这些知识，在 AWS 的世界里构建出既高效又坚不可摧的堡垒！