157 lines
6.1 KiB
Markdown
157 lines
6.1 KiB
Markdown
# 第23天：CloudTrail——谁在什么时候做了什么
|
||
|
||
## 今天你将学到什么
|
||
|
||
今天学习 CloudTrail——AWS 的"监控录像系统"。它记录你 AWS 账户中的每一个操作：谁在什么时间、从哪个 IP 地址、对什么资源做了什么操作、结果是成功还是失败。这是安全审计和故障排查的基础。
|
||
|
||
---
|
||
|
||
## 为什么需要审计日志
|
||
|
||
### 场景一：安全事件调查
|
||
|
||
周一早上你发现生产数据库被删除了。老板问："谁干的？"
|
||
|
||
没有 CloudTrail：不知道。只能猜。
|
||
|
||
有 CloudTrail：打开日志一查——周日凌晨 3:17，用户 `dev-zhang` 从 IP `203.x.x.x` 调用了 `rds:DeleteDBInstance`。进一步调查发现他的账号被盗了。
|
||
|
||
### 场景二：故障排查
|
||
|
||
你的应用突然无法访问 S3 桶了。什么时候开始的？谁改了权限？
|
||
|
||
CloudTrail 告诉你：昨天下午 4:32，用户 `ops-li` 修改了桶策略，把 `Allow` 改成了 `Deny`。
|
||
|
||
### 场景三：合规审计
|
||
|
||
审计师问："过去 90 天内，谁访问过客户数据？有没有未授权的访问？"
|
||
|
||
CloudTrail 可以提供完整的访问记录。
|
||
|
||
**类比**：CloudTrail 就像银行的监控录像 + 操作流水。每一笔交易、每一次进出都有记录。出了问题可以回放查看。
|
||
|
||
---
|
||
|
||
## CloudTrail 记录什么
|
||
|
||
### 每条记录包含的信息
|
||
|
||
| 字段 | 含义 | 举例 |
|
||
|------|------|------|
|
||
| 时间 | 操作发生的精确时间 | 2024-01-15T03:17:42Z |
|
||
| 用户身份 | 谁做的操作 | 用户 dev-zhang / 角色 lambda-role |
|
||
| 源 IP | 从哪里发起的 | 203.0.113.50 |
|
||
| 操作 | 做了什么 | DeleteDBInstance |
|
||
| 资源 | 对什么东西操作 | arn:aws:rds:...:production-db |
|
||
| 结果 | 成功还是失败 | 成功 / AccessDenied |
|
||
| 请求参数 | 具体的操作细节 | DBInstanceIdentifier: production-db |
|
||
|
||
### 三种事件类型
|
||
|
||
| 类型 | 记录什么 | 举例 |
|
||
|------|----------|------|
|
||
| 管理事件 | 对 AWS 资源的管理操作 | 创建/删除 EC2、修改安全组、更改 IAM 策略 |
|
||
| 数据事件 | 对数据的读写操作 | S3 对象的上传/下载、Lambda 函数的调用 |
|
||
| 洞察事件 | 异常活动模式 | API 调用量突然暴增、异常的错误率 |
|
||
|
||
**默认情况**：管理事件自动记录（免费保留 90 天）。数据事件需要手动开启（因为量太大）。
|
||
|
||
---
|
||
|
||
## 怎么使用 CloudTrail
|
||
|
||
### 方式一：快速查看（Event History）
|
||
|
||
打开 CloudTrail 控制台 → Event History，可以直接搜索最近 90 天的管理事件。
|
||
|
||
**常用搜索方式**：
|
||
- 按用户名搜索：看某个人做了什么
|
||
- 按事件名搜索：看谁做了某个操作（比如搜 `DeleteBucket`）
|
||
- 按资源名搜索：看某个资源被谁动过
|
||
|
||
### 方式二：创建 Trail（长期保存）
|
||
|
||
如果你需要保留超过 90 天的日志，或者需要记录数据事件，就创建一个 Trail：
|
||
|
||
```
|
||
CloudTrail → 创建 Trail → 选择保存到 S3 桶
|
||
```
|
||
|
||
日志会以 JSON 文件的形式存储在你指定的 S3 桶里。你可以保留多久就保留多久。
|
||
|
||
### 方式三：配合其他服务
|
||
|
||
- **CloudWatch Logs**：把 CloudTrail 日志发送到 CloudWatch，设置告警。比如"有人删除了安全组就立刻通知我"。
|
||
- **Athena**：用 SQL 查询 S3 里的 CloudTrail 日志。适合大规模分析。
|
||
- **EventBridge**：实时响应特定事件。比如"有人创建了 IAM 用户就自动触发审批流程"。
|
||
|
||
---
|
||
|
||
## 实际应用场景
|
||
|
||
### 场景一：检测异常登录
|
||
|
||
设置告警：如果有人从非公司 IP 地址登录 AWS 控制台，立刻发送通知。
|
||
|
||
CloudTrail 记录每次控制台登录的源 IP。配合 CloudWatch 告警，可以实时检测异常登录。
|
||
|
||
### 场景二：追踪资源变更
|
||
|
||
"这个安全组的规则是谁改的？什么时候改的？改之前是什么样的？"
|
||
|
||
在 CloudTrail 中搜索 `AuthorizeSecurityGroupIngress` 或 `RevokeSecurityGroupIngress` 事件，可以看到完整的变更历史。
|
||
|
||
### 场景三：满足合规要求
|
||
|
||
很多行业法规（如 PCI DSS、HIPAA、SOC 2）要求保留完整的操作审计日志。CloudTrail 天然满足这些要求。
|
||
|
||
---
|
||
|
||
## CloudTrail 最佳实践
|
||
|
||
1. **所有区域都开启**：攻击者可能在你不常用的区域搞破坏。确保所有 AWS 区域都有 CloudTrail 记录。
|
||
2. **日志文件完整性验证**：开启日志文件验证，防止有人篡改日志（删除自己的犯罪记录）。
|
||
3. **日志桶加密**：存储日志的 S3 桶要加密，防止日志本身被泄露。
|
||
4. **限制日志桶访问**：只有安全团队能访问日志桶，普通开发者不能删除或修改日志。
|
||
5. **设置关键操作告警**：对高危操作（删除资源、修改 IAM、关闭 CloudTrail）设置实时告警。
|
||
|
||
---
|
||
|
||
## AWS Config——资源配置的"时光机"
|
||
|
||
和 CloudTrail 经常一起提到的还有 AWS Config。它们的区别：
|
||
|
||
| | CloudTrail | AWS Config |
|
||
|--|-----------|------------|
|
||
| 记录什么 | 谁做了什么操作（API 调用） | 资源的配置状态变化 |
|
||
| 回答什么问题 | "谁在 3 点删了数据库？" | "这个安全组的规则上周是什么样的？" |
|
||
| 类比 | 监控录像（记录动作） | 定期拍照（记录状态） |
|
||
|
||
**Config 的独特价值**：
|
||
- 记录资源配置的完整变更历史
|
||
- 可以设置合规规则（比如"所有 S3 桶必须开启加密"）
|
||
- 自动检测不合规的资源并通知你
|
||
|
||
---
|
||
|
||
## 今天的小测验
|
||
|
||
1. CloudTrail 记录的一条事件包含哪些关键信息？
|
||
2. 管理事件和数据事件的区别是什么？为什么数据事件默认不开启？
|
||
3. 如果你想保留超过 90 天的审计日志，应该怎么做？
|
||
4. CloudTrail 和 AWS Config 各自解决什么问题？
|
||
|
||
---
|
||
|
||
## 延伸阅读
|
||
|
||
- [CloudTrail 用户指南](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)
|
||
- [AWS Config 开发者指南](https://docs.aws.amazon.com/config/latest/developerguide/)
|
||
- [CloudTrail 支持的服务列表](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)
|
||
|
||
---
|
||
|
||
## 明天预告
|
||
|
||
明天学习 VPC 安全进阶——网络 ACL、VPC Flow Logs、PrivateLink。深入理解如何在网络层面保护你的 AWS 资源。
|