211 lines
7.8 KiB
Markdown
211 lines
7.8 KiB
Markdown
# 第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 如何帮你管理容器。
|