2026-05-08 10:24:39 +08:00

195 lines
6.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 第6天IAM 入门——谁能做什么
## 今天你将学到什么
今天学习 AWS 中最重要的安全服务IAMIdentity 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 倍。