wangqifan/aws-doc

Fork 0

wangqifan a80067d684 all

2026-05-08 10:24:39 +08:00

7.8 KiB

Raw Permalink Blame History

第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

安全最佳实践清单

加密一切：静态数据和传输数据都要加密
最小权限：只给完成工作所需的最少权限
纵深防御：多层防护，不依赖单一安全措施
审计一切：所有操作都要有记录
自动化响应：安全事件要能自动检测和通知
定期审查：定期检查权限、规则、配置是否仍然合理
假设被攻破：设计架构时假设任何一层都可能被突破

今天的小测验

"纵深防御"是什么意思？为什么不能只依赖一层防护？
为什么数据库要放在私有子网而不是公有子网？
如果一个员工的 AWS 账号被盗，这个架构中哪些措施能帮助你发现和应对？
为什么要用 Secrets Manager 管理密码而不是写在配置文件里？

明天预告

进入第四阶段：应用架构。明天学习容器技术——Docker 基础和 AWS ECS。了解为什么现代应用都在用容器，以及 AWS 如何帮你管理容器。

7.8 KiB Raw Permalink Blame History Unescape Escape