195 lines
6.5 KiB
Markdown
195 lines
6.5 KiB
Markdown
|
# 第6天：IAM 入门——谁能做什么
|
|||
|
|
|
|||
|
|
## 今天你将学到什么
|
|||
|
|
|
|||
|
|
今天学习 AWS 中最重要的安全服务：IAM（Identity and Access Management，身份与访问管理）。
|
|||
|
|
|
|||
|
|
它回答两个核心问题：
|
|||
|
|
- **你是谁？**（身份认证）
|
|||
|
|
- **你能做什么？**（权限授权）
|
|||
|
|
|
|||
|
|
这是 AWS 安全的基石，后面学的所有服务都离不开它。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 用公司来理解 IAM
|
|||
|
|
|
|||
|
|
想象你新入职一家公司：
|
|||
|
|
|
|||
|
|
- **你的工牌** = IAM 用户（证明你是谁）
|
|||
|
|
- **你所在的部门** = IAM 组（研发部、市场部、财务部）
|
|||
|
|
- **你的门禁权限** = IAM 策略（你能进哪些房间、用哪些设备）
|
|||
|
|
- **临时访客证** = IAM 角色（外来人员临时获得某些权限，离开后就失效）
|
|||
|
|
|
|||
|
|
公司不会给每个人一把万能钥匙，而是根据岗位需要给不同的权限。IAM 做的就是这件事。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四个核心概念
|
|||
|
|
|
|||
|
|
### 1. 用户（User）
|
|||
|
|
|
|||
|
|
一个 IAM 用户代表一个具体的人或程序。
|
|||
|
|
|
|||
|
|
**每个用户有自己的登录凭证**：
|
|||
|
|
- 用户名 + 密码（用于登录网页控制台）
|
|||
|
|
- Access Key ID + Secret Access Key（用于命令行和程序调用）
|
|||
|
|
|
|||
|
|
**重要原则：一人一账号，绝不共享。**
|
|||
|
|
|
|||
|
|
为什么？如果三个人共用一个账号，出了问题你根本不知道是谁干的。就像公司的门禁卡，每人一张才能追踪谁什么时候进了哪个房间。
|
|||
|
|
|
|||
|
|
### 2. 组（Group）
|
|||
|
|
|
|||
|
|
组是用户的集合，方便批量管理权限。
|
|||
|
|
|
|||
|
|
**举个例子**：
|
|||
|
|
|
|||
|
|
你公司有 10 个开发人员，他们都需要访问代码仓库和测试服务器。你可以：
|
|||
|
|
- 方法 A：给每个人单独设置权限（重复 10 次，累死）
|
|||
|
|
- 方法 B：创建一个"开发者"组，把权限给这个组，然后把 10 个人加进去（一次搞定）
|
|||
|
|
|
|||
|
|
显然方法 B 更聪明。新人入职？加入组就自动有权限。离职？移出组就自动失去权限。
|
|||
|
|
|
|||
|
|
**注意**：
|
|||
|
|
- 一个用户可以属于多个组（比如既在"开发者"组又在"项目A"组）
|
|||
|
|
- 组不能嵌套（组里面不能再包含组）
|
|||
|
|
|
|||
|
|
### 3. 策略（Policy）
|
|||
|
|
|
|||
|
|
策略是一份"权限清单"，用 JSON 格式写成，定义了"谁能对什么资源做什么操作"。
|
|||
|
|
|
|||
|
|
**用大白话说就是**：
|
|||
|
|
|
|||
|
|
"允许/拒绝 + 某人 + 对某个东西 + 做某个操作"
|
|||
|
|
|
|||
|
|
比如：
|
|||
|
|
- "允许张三读取 S3 桶里的文件"
|
|||
|
|
- "拒绝所有人删除生产数据库"
|
|||
|
|
- "允许开发组启动和停止测试环境的 EC2 实例"
|
|||
|
|
|
|||
|
|
AWS 预置了很多常用策略（叫"AWS 托管策略"），比如：
|
|||
|
|
- `AmazonS3ReadOnlyAccess` — 只能读 S3，不能写
|
|||
|
|
- `AmazonEC2FullAccess` — 对 EC2 有完全权限
|
|||
|
|
- `AdministratorAccess` — 对所有服务有完全权限（相当于万能钥匙）
|
|||
|
|
|
|||
|
|
### 4. 角色（Role）
|
|||
|
|
|
|||
|
|
角色是一个"临时身份"，不绑定特定的人。谁需要谁来"穿上"这个角色，用完就"脱下"。
|
|||
|
|
|
|||
|
|
**为什么需要角色？**
|
|||
|
|
|
|||
|
|
场景一：你的应用程序运行在 EC2 服务器上，需要读取 S3 里的文件。你不能给服务器一个"用户账号"（那样就有永久密码了，不安全）。正确做法是给服务器一个"角色"——它运行时自动获得临时权限，权限会自动过期和刷新。
|
|||
|
|
|
|||
|
|
场景二：外部审计人员需要临时查看你的 AWS 资源。你不想给他创建永久账号。给他一个角色，审计完了角色权限就失效了。
|
|||
|
|
|
|||
|
|
**角色的核心优势：没有永久密码，临时获取、自动过期，比用户账号安全得多。**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 最小权限原则
|
|||
|
|
|
|||
|
|
这是 IAM 最最最重要的设计原则：
|
|||
|
|
|
|||
|
|
> **只给完成工作所需的最小权限，一分都不多给。**
|
|||
|
|
|
|||
|
|
**为什么这么重要？**
|
|||
|
|
|
|||
|
|
想象一下：如果公司每个人都有所有房间的钥匙——
|
|||
|
|
- 实习生不小心进了机房拔了网线，全公司断网
|
|||
|
|
- 保洁阿姨误删了财务系统的数据
|
|||
|
|
- 某个员工的钥匙丢了，所有房间都不安全了
|
|||
|
|
|
|||
|
|
同样的道理：
|
|||
|
|
- 如果每个 IAM 用户都有 AdministratorAccess，一个误操作就可能删掉生产数据库
|
|||
|
|
- 如果某个用户的密码泄露了，攻击者能做的事情越少越好
|
|||
|
|
|
|||
|
|
**实践方法**：
|
|||
|
|
- 新用户创建时零权限，需要什么再加什么
|
|||
|
|
- 定期检查：这个人还需要这些权限吗？
|
|||
|
|
- 用 AWS 的工具（Access Analyzer）发现从未使用过的权限，然后移除
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 动手：创建你的第一个 IAM 用户
|
|||
|
|
|
|||
|
|
现在我们来创建一个日常使用的 IAM 用户，替代 Root 账户。
|
|||
|
|
|
|||
|
|
### 步骤：
|
|||
|
|
|
|||
|
|
1. 用 Root 账户登录 AWS 控制台
|
|||
|
|
2. 搜索并进入 "IAM" 服务
|
|||
|
|
3. 左侧菜单点击 "用户"（Users）→ "创建用户"（Create user）
|
|||
|
|
4. 用户名填写：`admin-daily`（或者你喜欢的名字）
|
|||
|
|
5. 勾选"提供用户对 AWS 管理控制台的访问权限"
|
|||
|
|
6. 设置密码
|
|||
|
|
7. 下一步：设置权限
|
|||
|
|
8. 选择"将用户添加到组"→ "创建组"
|
|||
|
|
9. 组名填写：`Administrators`
|
|||
|
|
10. 搜索并勾选 `AdministratorAccess` 策略
|
|||
|
|
11. 创建组，将用户加入
|
|||
|
|
12. 完成创建
|
|||
|
|
|
|||
|
|
### 记录登录信息：
|
|||
|
|
|
|||
|
|
创建完成后，你会看到一个专属的登录 URL：
|
|||
|
|
```
|
|||
|
|
https://你的账户ID.signin.aws.amazon.com/console
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
把这个 URL 收藏起来。以后用这个 URL + IAM 用户名密码登录，不再用 Root 账户。
|
|||
|
|
|
|||
|
|
### 给 IAM 用户也启用 MFA
|
|||
|
|
|
|||
|
|
和 Root 账户一样，IAM 用户也应该启用 MFA：
|
|||
|
|
1. 用 IAM 用户登录
|
|||
|
|
2. 右上角 → 安全凭证
|
|||
|
|
3. 分配 MFA 设备
|
|||
|
|
4. 扫码绑定
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## IAM 的工作流程
|
|||
|
|
|
|||
|
|
当你在 AWS 上做任何操作时，背后发生了什么：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
你点击"创建 EC2 实例"
|
|||
|
|
↓
|
|||
|
|
AWS 检查：你是谁？（认证）
|
|||
|
|
↓
|
|||
|
|
AWS 检查：你有权限做这个操作吗？（授权）
|
|||
|
|
↓
|
|||
|
|
有权限 → 执行操作
|
|||
|
|
没权限 → 返回"Access Denied"错误
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**授权的判断逻辑**：
|
|||
|
|
1. 默认：所有操作都被拒绝（除非有明确的"允许"）
|
|||
|
|
2. 如果找到了"允许"规则 → 允许
|
|||
|
|
3. 但如果同时存在"拒绝"规则 → 最终拒绝
|
|||
|
|
|
|||
|
|
**记住：拒绝永远优先于允许。** 这是安全设计的基本原则。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 今天的小测验
|
|||
|
|
|
|||
|
|
1. IAM 用户和 IAM 角色有什么区别？各自适合什么场景？
|
|||
|
|
2. 为什么要用"组"来管理权限，而不是给每个用户单独设置？
|
|||
|
|
3. "最小权限原则"是什么意思？为什么重要？
|
|||
|
|
4. 你现在应该用什么账户做日常操作？Root 还是 IAM 用户？
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 延伸阅读
|
|||
|
|
|
|||
|
|
- [IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
|
|||
|
|
- [IAM 入门教程](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 明天预告
|
|||
|
|
|
|||
|
|
明天学习 AWS CLI（命令行工具）的安装和配置。虽然控制台（网页）很直观，但真正高效的 AWS 操作都是通过命令行完成的。学会 CLI，你的效率会提升 10 倍。
|