# 第25天：安全架构综合实战——构建完整的防护体系

## 今天你将学到什么

今天是第三阶段的收尾。我们把前面学到的所有安全知识串联起来，用一个完整的案例展示如何构建企业级的安全防护体系。

---

## 项目背景：一个在线医疗平台

假设你要为一个在线医疗咨询平台设计安全架构：
- 患者可以在线咨询医生
- 存储患者的病历和个人信息（高度敏感数据）
- 需要满足医疗行业的合规要求
- 有管理后台供运营人员使用

**安全要求**：
- 患者数据必须加密存储和传输
- 只有授权的医生能查看对应患者的病历
- 所有操作必须有审计记录
- 必须防御常见的 Web 攻击
- 异常行为要实时告警

---

## 安全架构全景图

```
互联网用户
    ↓
Route 53 + CloudFront（HTTPS 强制加密传输）
    ↓
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 证书 | ACM（AWS 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 如何帮你管理容器。