152 lines
4.9 KiB
Markdown
152 lines
4.9 KiB
Markdown
# 第21天：加密与密钥管理——保护你的数据
|
||
|
||
## 今天你将学到什么
|
||
|
||
今天学习如何保护数据安全：KMS（密钥管理）负责加密数据，Secrets Manager 负责管理密码和密钥。学完你会明白为什么"加密一切"是 AWS 的基本原则。
|
||
|
||
---
|
||
|
||
## 为什么需要加密
|
||
|
||
**场景一**：你的数据库存储了用户的手机号和地址。如果有人偷走了数据库的硬盘（物理盗窃或黑客入侵），他们能直接读取所有用户信息。
|
||
|
||
**加密后**：即使硬盘被偷，看到的也是一堆乱码。没有密钥就无法解读。
|
||
|
||
**场景二**：你的应用配置文件里写着数据库密码 `password123`。如果代码仓库泄露了，黑客就能直接连上你的数据库。
|
||
|
||
**用 Secrets Manager 后**：配置文件里只有一个引用 ID，真正的密码存在 AWS 的保险箱里，只有有权限的程序才能取出来。
|
||
|
||
---
|
||
|
||
## 加密的两种场景
|
||
|
||
| 场景 | 含义 | 类比 |
|
||
|------|------|------|
|
||
| 静态加密 | 数据存在磁盘上时是加密的 | 保险箱里的文件是锁着的 |
|
||
| 传输加密 | 数据在网络上传输时是加密的 | 快递包裹是密封的 |
|
||
|
||
AWS 的大多数服务**默认启用**这两种加密。你几乎不需要额外操作。
|
||
|
||
---
|
||
|
||
## KMS（Key Management Service）
|
||
|
||
KMS 是 AWS 的"密钥保险箱"——帮你创建、存储和管理加密密钥。
|
||
|
||
### 工作原理（简化版）
|
||
|
||
你不需要自己写加密算法。只需要告诉 AWS："帮我加密这段数据"，AWS 用 KMS 里的密钥帮你加密。解密时也一样。
|
||
|
||
**类比**：KMS 就像银行的保险箱服务。你把贵重物品（数据）交给银行，银行帮你锁好（加密）。需要取的时候，验证你的身份后帮你打开（解密）。
|
||
|
||
### 哪些 AWS 服务用 KMS 加密
|
||
|
||
几乎所有存储数据的服务都支持 KMS：
|
||
- S3：存储的文件自动加密
|
||
- EBS：硬盘上的数据自动加密
|
||
- RDS：数据库文件自动加密
|
||
- DynamoDB：表数据自动加密
|
||
- SQS：消息内容加密
|
||
- Lambda：环境变量加密
|
||
|
||
**你要做的**：创建资源时勾选"启用加密"（很多服务现在默认就是启用的）。
|
||
|
||
### 密钥类型
|
||
|
||
| 类型 | 谁管理 | 费用 | 适合 |
|
||
|------|--------|------|------|
|
||
| AWS 托管密钥 | AWS 自动管理 | 免费 | 大多数场景 |
|
||
| 客户托管密钥 | 你自己管理 | $1/月/密钥 | 需要精细控制的场景 |
|
||
|
||
学习阶段用 AWS 托管密钥就够了。
|
||
|
||
---
|
||
|
||
## Secrets Manager——密码的保险箱
|
||
|
||
### 问题：密码放哪里？
|
||
|
||
你的应用需要连接数据库，需要一个密码。这个密码放哪里？
|
||
|
||
**错误做法**：
|
||
- 写在代码里 → 代码泄露密码就泄露
|
||
- 写在配置文件里 → 配置文件可能被误提交到 Git
|
||
- 写在环境变量里 → 环境变量可能出现在日志中
|
||
|
||
**正确做法**：放在 Secrets Manager 里。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
1. 你把数据库密码存入 Secrets Manager
|
||
2. 应用启动时，调用 Secrets Manager API 获取密码
|
||
3. 用获取到的密码连接数据库
|
||
4. 密码永远不会出现在代码或配置文件中
|
||
```
|
||
|
||
### Secrets Manager 的杀手锏：自动轮换
|
||
|
||
**传统方式**：数据库密码设置后就不变了。如果泄露了，你可能很久才发现。
|
||
|
||
**Secrets Manager 自动轮换**：
|
||
- 每 30 天（你设置的周期）自动更换数据库密码
|
||
- 自动在数据库中更新新密码
|
||
- 应用下次获取时自动拿到新密码
|
||
- 全程无需人工干预，无需重启应用
|
||
|
||
**就像银行定期帮你换保险箱密码，而且自动通知所有需要知道的人。**
|
||
|
||
---
|
||
|
||
## 实际应用场景
|
||
|
||
### 场景：Web 应用连接数据库
|
||
|
||
**不安全的做法**：
|
||
```
|
||
数据库地址：mydb.xxx.rds.amazonaws.com
|
||
用户名：admin
|
||
密码：MyP@ssw0rd123 ← 写死在代码里
|
||
```
|
||
|
||
**安全的做法**：
|
||
```
|
||
数据库地址：mydb.xxx.rds.amazonaws.com
|
||
用户名：从 Secrets Manager 获取
|
||
密码：从 Secrets Manager 获取
|
||
```
|
||
|
||
应用运行时动态获取凭证，代码里看不到任何密码。
|
||
|
||
---
|
||
|
||
## 加密最佳实践
|
||
|
||
1. **默认加密一切**：创建任何存储资源时都启用加密，成本几乎为零
|
||
2. **不要硬编码密码**：所有密码、API 密钥都放 Secrets Manager
|
||
3. **启用自动轮换**：密码定期更换，减少泄露风险
|
||
4. **最小权限**：只有需要解密的服务才给 KMS 权限
|
||
5. **审计**：通过 CloudTrail 监控谁在什么时候使用了密钥
|
||
|
||
---
|
||
|
||
## 今天的小测验
|
||
|
||
1. "静态加密"和"传输加密"分别保护什么场景？
|
||
2. 为什么不应该把数据库密码写在代码里？
|
||
3. Secrets Manager 的"自动轮换"解决了什么问题？
|
||
4. KMS 的作用是什么？用一句话概括。
|
||
|
||
---
|
||
|
||
## 延伸阅读
|
||
|
||
- [KMS 开发者指南](https://docs.aws.amazon.com/kms/latest/developerguide/)
|
||
- [Secrets Manager 用户指南](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)
|
||
|
||
---
|
||
|
||
## 明天预告
|
||
|
||
明天学习 AWS 的网络安全服务：WAF（Web 应用防火墙）和 Shield（DDoS 防护）——保护你的网站不被黑客攻击。
|