aws-doc/课程/第三阶段-安全与身份/第25天-安全架构综合实战.md

211 lines
7.8 KiB
Markdown
Raw Permalink Normal View History

2026-05-08 10:24:39 +08:00
# 第25天安全架构综合实战——构建完整的防护体系
## 今天你将学到什么
今天是第三阶段的收尾。我们把前面学到的所有安全知识串联起来,用一个完整的案例展示如何构建企业级的安全防护体系。
---
## 项目背景:一个在线医疗平台
假设你要为一个在线医疗咨询平台设计安全架构:
- 患者可以在线咨询医生
- 存储患者的病历和个人信息(高度敏感数据)
- 需要满足医疗行业的合规要求
- 有管理后台供运营人员使用
**安全要求**
- 患者数据必须加密存储和传输
- 只有授权的医生能查看对应患者的病历
- 所有操作必须有审计记录
- 必须防御常见的 Web 攻击
- 异常行为要实时告警
---
## 安全架构全景图
```
互联网用户
Route 53 + CloudFrontHTTPS 强制加密传输)
AWS WAF防御 SQL 注入、XSS、恶意爬虫
ALB仅允许 443 端口)
┌─────────────────────────────────────────┐
│ VPC │
│ ┌─────────────────────────────────┐ │
│ │ 公有子网 │ │
│ │ - NAT Gateway │ │
│ │ - 网络 ACL严格限制 │ │
│ └─────────────────────────────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ 应用子网(私有) │ │
│ │ - EC2 应用服务器 │ │
│ │ - 安全组:只允许 ALB 流量 │ │
│ └─────────────────────────────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ 数据子网(私有,最严格) │ │
│ │ - RDS加密存储 │ │
│ │ - ElastiCache │ │
│ │ - 安全组:只允许应用子网流量 │ │
│ └─────────────────────────────────┘ │
│ │
│ VPC Endpoint → S3病历文件加密存储
│ VPC Flow Logs → 记录所有网络流量 │
└─────────────────────────────────────────┘
CloudTrail记录所有 API 操作)
GuardDuty智能威胁检测
Security Hub统一安全视图
```
---
## 逐层安全设计
### 第一层:传输安全
**目标**:数据在网络上传输时不被窃听或篡改。
| 措施 | 实现方式 |
|------|----------|
| 强制 HTTPS | CloudFront 配置HTTP 自动重定向到 HTTPS |
| TLS 证书 | ACMAWS Certificate Manager免费申请和管理证书 |
| 最低 TLS 版本 | 设置为 TLS 1.2,禁用老旧的不安全协议 |
### 第二层:边界防护
**目标**:在流量到达应用之前,过滤掉恶意请求。
| 措施 | 实现方式 |
|------|----------|
| Web 攻击防护 | WAF 启用核心规则集SQL 注入、XSS |
| 频率限制 | WAF 规则:同一 IP 每分钟最多 100 次请求 |
| 地域限制 | WAF 规则:只允许业务覆盖地区的访问 |
| DDoS 防护 | Shield Standard自动启用 |
| 管理后台保护 | WAF 规则:管理后台只允许公司 IP 访问 |
### 第三层:网络隔离
**目标**:即使攻击者突破了边界,也无法横向移动到其他系统。
| 措施 | 实现方式 |
|------|----------|
| 子网隔离 | 公有/应用/数据三层子网,层层隔离 |
| 安全组最小化 | 每个组件只开放必要的端口和来源 |
| 网络 ACL | 子网级别的额外防护,封禁已知恶意 IP |
| 私有连接 | VPC Endpoint 访问 S3不走公网 |
| 流量监控 | VPC Flow Logs 记录所有网络通信 |
### 第四层:身份与访问控制
**目标**:确保只有正确的人和程序能访问正确的资源。
| 措施 | 实现方式 |
|------|----------|
| 最小权限 | 每个 IAM 角色只有完成工作所需的最少权限 |
| MFA 强制 | 所有人类用户必须启用 MFA |
| 服务角色 | EC2 通过 IAM 角色访问其他服务,不使用长期密钥 |
| 临时凭证 | 使用 STS 生成临时凭证,不使用永久 Access Key |
| 条件限制 | 敏感操作要求 MFA + 公司 IP + 工作时间 |
### 第五层:数据保护
**目标**:即使数据被盗,攻击者也无法读取。
| 措施 | 实现方式 |
|------|----------|
| 数据库加密 | RDS 启用 KMS 加密(静态加密) |
| 文件加密 | S3 启用 SSE-KMS 加密 |
| 密码管理 | 数据库密码存在 Secrets Manager自动轮换 |
| 字段级加密 | 特别敏感的字段(身份证号)在应用层额外加密 |
| 备份加密 | 所有备份和快照都加密 |
### 第六层:检测与响应
**目标**:即使攻击发生了,也能快速发现并响应。
| 措施 | 实现方式 |
|------|----------|
| 操作审计 | CloudTrail 记录所有 API 调用 |
| 威胁检测 | GuardDuty 持续监控异常行为 |
| 配置合规 | AWS Config 检测不合规的资源配置 |
| 实时告警 | CloudWatch 告警 + SNS 通知安全团队 |
| 统一视图 | Security Hub 汇总所有安全发现 |
---
## 安全事件响应流程
当安全事件发生时:
```
1. 检测GuardDuty 发现异常)
2. 通知SNS 发送告警给安全团队)
3. 调查CloudTrail 查看操作记录Flow Logs 查看网络流量)
4. 遏制(修改安全组切断攻击者访问,禁用被盗账号)
5. 修复(修补漏洞,更换密钥,恢复数据)
6. 复盘(分析根因,改进防护措施)
```
---
## 安全服务速查表
| 我想... | 用什么 |
|---------|--------|
| 控制谁能做什么 | IAM 策略 |
| 加密存储的数据 | KMS |
| 安全存储密码和密钥 | Secrets Manager |
| 防御 Web 攻击 | WAF |
| 防御 DDoS | Shield |
| 检测账户异常行为 | GuardDuty |
| 审计所有操作 | CloudTrail |
| 检测配置不合规 | AWS Config |
| 监控网络流量 | VPC Flow Logs |
| 隔离网络资源 | VPC + 安全组 + 网络 ACL |
| 统一安全管理 | Security Hub |
---
## 安全最佳实践清单
1. **加密一切**:静态数据和传输数据都要加密
2. **最小权限**:只给完成工作所需的最少权限
3. **纵深防御**:多层防护,不依赖单一安全措施
4. **审计一切**:所有操作都要有记录
5. **自动化响应**:安全事件要能自动检测和通知
6. **定期审查**:定期检查权限、规则、配置是否仍然合理
7. **假设被攻破**:设计架构时假设任何一层都可能被突破
---
## 今天的小测验
1. "纵深防御"是什么意思?为什么不能只依赖一层防护?
2. 为什么数据库要放在私有子网而不是公有子网?
3. 如果一个员工的 AWS 账号被盗,这个架构中哪些措施能帮助你发现和应对?
4. 为什么要用 Secrets Manager 管理密码而不是写在配置文件里?
---
## 延伸阅读
- [AWS 安全最佳实践](https://docs.aws.amazon.com/security/)
- [AWS Well-Architected 安全支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/)
- [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/)
---
## 明天预告
进入第四阶段应用架构。明天学习容器技术——Docker 基础和 AWS ECS。了解为什么现代应用都在用容器以及 AWS 如何帮你管理容器。