备考助手
安全与合规
这一章在 CLF-C02 里是高频重点（约 30%）。
很多同学不是“安全不会”，而是“题目一长就分不清责任边界和服务边界”。
你这章要做到 4 件事：
- 先判断“谁负责”（AWS 还是客户）。
- 再判断“用什么控权限”（IAM 用户、角色、策略）。
- 最后判断“用哪个安全服务”（CloudTrail、KMS、WAF 等）。
- 知道哪些是默认开启，哪些必须你手动配置。
🤝 AWS 共享责任模型
共享责任模型是 AWS 安全的基石，也是考试的最高频考点之一。
为什么它这么重要？因为很多题目其实都在问同一件事：
“这件安全工作到底该 AWS 做，还是该你做？”
你只要先把责任边界判断对，很多选项可以直接排除。
术语：Shared Responsibility Model（共享责任模型）
- 一句话解释：AWS 负责把云平台本身保护好，你负责把自己放上去的系统和数据保护好。
- 形象比喻：你租的是精装办公室。楼体安保是物业（AWS）负责，办公室门禁和文件柜锁是你（客户）负责。
- 考试怎么考：常用“谁负责打补丁/谁负责加密配置/谁负责物理安全”来出题。
- 最易混淆：AWS 会提供安全能力，但“是否启用、如何配置”通常仍是客户责任。
┌─────────────────────────────────────────────────────────────┐
│ AWS 共享责任模型 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ╔═══════════════════════════════════════════════════════╗ │
│ ║ 客户责任 ║ │
│ ║ "云中的安全" ║ │
│ ║ (Security IN the Cloud) ║ │
│ ╠═══════════════════════════════════════════════════════╣ │
│ ║ ║ │
│ ║ 📊 客户数据 ║ │
│ ║ └─ 你的数据内容 ║ │
│ ║ ║ │
│ ║ 🔐 平台、应用程序、身份和访问管理 ║ │
│ ║ └─ IAM 用户、角色、策略 ║ │
│ ║ ║ │
│ ║ 💻 操作系统、网络和防火墙配置 ║ │
│ ║ └─ EC2 实例的 OS 补丁、安全组 ║ │
│ ║ ║ │
│ ║ 🔒 客户端数据加密 | 服务器端加密 | 网络流量保护 ║ │
│ ║ └─ 数据加密、HTTPS、VPN ║ │
│ ║ ║ │
│ ╚═══════════════════════════════════════════════════════╝ │
│ │
│ ╔═══════════════════════════════════════════════════════╗ │
│ ║ AWS 责任 ║ │
│ ║ "云的安全" ║ │
│ ║ (Security OF the Cloud) ║ │
│ ╠═══════════════════════════════════════════════════════╣ │
│ ║ ║ │
│ ║ 🖥️ 软件: 计算 | 存储 | 数据库 | 网络 ║ │
│ ║ └─ AWS 服务的底层软件 ║ │
│ ║ ║ │
│ ║ 🔧 硬件 / AWS 全球基础设施 ║ │
│ ║ └─ 区域、可用区、边缘位置 ║ │
│ ║ └─ 物理服务器、存储设备、网络设备 ║ │
│ ║ ║ │
│ ║ 🏢 物理安全 ║ │
│ ║ └─ 数据中心安全、门禁、监控 ║ │
│ ║ ║ │
│ ╚═══════════════════════════════════════════════════════╝ │
│ │
└─────────────────────────────────────────────────────────────┘
配图：Shared Responsibility Model（共享责任模型）
图解说明：
- 先看上半部分 CUSTOMER：这是你负责的“云中安全”（数据、身份权限、OS/网络配置、加密开关）。
- 再看下半部分 AWS：这是 AWS 负责的“云的安全”（硬件、底层软件、全球基础设施与物理安全）。
- 考试最常见陷阱：题干写“加密功能由 AWS 提供”不代表“加密策略自动归 AWS 负责”；策略配置通常仍是客户责任。
- 答题动作：先判“责任归属”，再判“该用哪个服务”，速度会明显提升。
责任划分详解
┌─────────────────────────────────────────────────────────────┐
│ 不同服务类型的责任划分 │
├─────────────────────────────────────────────────────────────┤
│ │
│ IaaS (EC2) PaaS (RDS) SaaS (S3) │
│ ────────── ────────── ────────── │
│ │
│ 应用程序 👤 客户 👤 客户 ☁️ AWS │
│ 数据 👤 客户 👤 客户 👤 客户 │
│ 运行时 👤 客户 ☁️ AWS ☁️ AWS │
│ 操作系统 👤 客户 ☁️ AWS ☁️ AWS │
│ 虚拟化 ☁️ AWS ☁️ AWS ☁️ AWS │
│ 服务器 ☁️ AWS ☁️ AWS ☁️ AWS │
│ 存储 ☁️ AWS ☁️ AWS ☁️ AWS │
│ 网络 ☁️ AWS ☁️ AWS ☁️ AWS │
│ │
│ ───────────────────────────────────────────────────── │
│ 客户责任: 最多 中等 最少 │
│ │
└─────────────────────────────────────────────────────────────┘
服务类型责任对比
| 服务类型 | AWS 服务示例 | 客户责任 | AWS 责任 |
|---|---|---|---|
| IaaS | EC2 | OS补丁、安全组、应用、数据 | 物理基础设施、虚拟化层 |
| PaaS | RDS, Lambda | 数据、应用配置 | OS补丁、数据库引擎 |
| 更高抽象托管服务 | S3, DynamoDB | 数据分类、访问控制、加密策略 | 服务可用性与底层基础设施 |
💡 说明：CLF 里常把服务抽象成“你管得多/你管得少”，不用纠结名词本身。
记住核心：托管程度越高，你运维责任越少，但数据与权限责任始终在你。
💡 考试技巧：记住口诀 - AWS 负责"云的安全"，客户负责"云中的安全"！
具体场景责任划分
| 场景 | 负责方 | 说明 |
|---|---|---|
| EC2 实例操作系统补丁 | 👤 客户 | IaaS，客户管理 OS |
| RDS 数据库引擎补丁 | ☁️ AWS | PaaS，AWS 管理引擎 |
| S3 数据加密配置 | 👤 客户 | 客户决定是否加密 |
| 数据中心物理安全 | ☁️ AWS | AWS 负责所有物理安全 |
| IAM 用户权限配置 | 👤 客户 | 客户管理访问控制 |
| AWS 服务可用性 | ☁️ AWS | AWS 保证服务正常运行 |
| 安全组配置 | 👤 客户 | 客户配置网络安全 |
| 硬件故障处理 | ☁️ AWS | AWS 负责硬件维护 |
先判责任再做题（30 秒判断法）
- 题干提到“机房/硬件/底层网络” -> 先偏向 AWS 责任
- 题干提到“账号权限/数据加密开关/OS 配置” -> 先偏向客户责任
- 看服务抽象层级：EC2 常常客户责任更多，RDS/S3 常常 AWS 托管更多
这个判断法帮助你先排掉 2 个明显错误选项，再细看剩余选项。
🔐 IAM 身份和访问管理
IAM (Identity and Access Management) 是 AWS 的核心安全服务。
Authentication（认证）：先确认“你是谁”。
Authorization（授权）：再决定“你能做什么”。
在 IAM 题里，经常把这两个概念混在一起出题。
看到 “MFA/登录/身份验证” 多半是认证；看到 “允许/拒绝某操作” 多半是授权。
配图：IAM Identities（用户/组/角色关系）
图解说明：
- 先看 User/Group/Role 的层级：用户是具体身份，组是权限集合，角色是可被临时扮演的身份。
- 再看权限附加位置：策略可以直接挂用户、挂组（用户继承）、或挂角色（被 Assume 后生效）。
- 考试高频点：跨服务调用、跨账号访问、给应用授予权限，优先用 Role 而不是长期 Access Key。
┌─────────────────────────────────────────────────────────────┐
│ IAM 核心组件 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ IAM 用户 (Users) │ │
│ │ │ │
│ │ 👤 代表个人或应用程序 │ │
│ │ │ │
│ │ • 长期凭证 (用户名/密码, 访问密钥) │ │
│ │ • 可以直接附加策略 │ │
│ │ • 最佳实践: 每人一个 IAM 用户 │ │
│ │ │ │
│ │ ⚠️ 不要使用 root 账户进行日常操作！ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ IAM 组 (Groups) │ │
│ │ │ │
│ │ 👥 用户的集合 │ │
│ │ │ │
│ │ • 简化权限管理 │ │
│ │ • 策略附加到组，组内用户继承权限 │ │
│ │ • 一个用户可属于多个组 │ │
│ │ │ │
│ │ 示例: Developers 组, Admins 组, Finance 组 │ │
│ │ │ │
│ │ ⚠️ 组不能嵌套（组不能包含组） │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ IAM 角色 (Roles) │ │
│ │ │ │
│ │ 🎭 可被承担的身份，获得临时权限 │ │
│ │ │ │
│ │ • 临时凭证 (自动轮换) │ │
│ │ • 可被用户、服务或外部身份承担 │ │
│ │ • 跨账户访问 │ │
│ │ │ │
│ │ 常见用例: │ │
│ │ • EC2 实例访问 S3 │ │
│ │ • Lambda 函数访问 DynamoDB │ │
│ │ • 跨账户资源访问 │ │
│ │ │ │
│ │ ✅ 最佳实践: 优先使用角色，避免长期访问密钥 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ IAM 策略 (Policies) │ │
│ │ │ │
│ │ 📜 JSON 格式的权限文档 │ │
│ │ │ │
│ │ { │ │
│ │ "Version": "2012-10-17", │ │
│ │ "Statement": [{ │ │
│ │ "Effect": "Allow", │ │
│ │ "Action": "s3:GetObject", │ │
│ │ "Resource": "arn:aws:s3:::bucket/*" │ │
│ │ }] │ │
│ │ } │ │
│ │ │ │
│ │ 策略类型: │ │
│ │ • AWS 托管策略 (AWS Managed) │ │
│ │ • 客户托管策略 (Customer Managed) │ │
│ │ • 内联策略 (Inline) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
IAM 策略结构
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3Read",
"Effect": "Allow", // Allow 或 Deny
"Action": [ // 允许的操作
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [ // 资源 ARN
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": { // 可选条件
"IpAddress": {
"aws:SourceIp": "192.168.1.0/24"
}
}
}
]
}
策略评估逻辑
┌─────────────────────────────────────────────────────────────┐
│ IAM 策略评估流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 请求到达 │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 是否有显式 │ 是 │
│ │ Deny 策略？ │ ────→ ❌ 拒绝 │
│ └────────┬────────┘ │
│ │ 否 │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 是否有显式 │ 是 │
│ │ Allow 策略？ │ ────→ ✅ 允许 │
│ └────────┬────────┘ │
│ │ 否 │
│ ▼ │
│ ❌ 默认拒绝 │
│ │
│ ⚠️ 记住: 显式 Deny > 显式 Allow > 默认 Deny │
│ │
└─────────────────────────────────────────────────────────────┘
💡 考试技巧：默认情况下一切都被拒绝！必须显式允许，而显式拒绝优先级最高。
IAM 组件怎么选（高频场景）
| 需求 | 推荐组件 | 原因 |
|---|---|---|
| 员工长期登录控制台 | IAM User + Group + MFA | 便于审计和最小权限管理 |
| AWS 服务访问其他 AWS 服务 | IAM Role | 临时凭证，避免硬编码密钥 |
| 跨账户访问 | IAM Role（AssumeRole） | 安全、可审计、可撤销 |
| 给一批人统一授权 | IAM Group + Policy | 降低运维复杂度 |
IAM 最佳实践
先给一个实战视角：
很多账号出问题，不是 AWS 不安全，而是权限太大、凭证泄露、Root 误用。
所以 IAM 最佳实践本质在做三件事：缩权限、缩暴露面、缩攻击窗口。
┌─────────────────────────────────────────────────────────────┐
│ IAM 最佳实践清单 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1️⃣ 锁定 Root 账户 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 启用 MFA │ │
│ │ • 删除 root 访问密钥 │ │
│ │ • 仅用于账户级操作 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 2️⃣ 最小权限原则 (Least Privilege) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 只授予完成任务所需的最小权限 │ │
│ │ • 定期审查和删除不需要的权限 │ │
│ │ • 使用 IAM Access Analyzer │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 3️⃣ 启用 MFA (多因素认证) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 为所有用户启用 MFA │ │
│ │ • 特别是特权用户 │ │
│ │ • 支持: 虚拟MFA、硬件MFA、U2F │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 4️⃣ 使用组管理权限 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 将权限附加到组而非用户 │ │
│ │ • 用户通过组继承权限 │ │
│ │ • 便于管理和审计 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 5️⃣ 使用角色替代长期凭证 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • EC2 使用实例角色而非嵌入访问密钥 │ │
│ │ • 临时凭证自动轮换 │ │
│ │ • 更安全、更易管理 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 6️⃣ 定期轮换凭证 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • 定期更换密码 │ │
│ │ • 轮换访问密钥 │ │
│ │ • 使用密码策略强制执行 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
IAM 最佳实践落地顺序（新账号前 7 天）
| 时间点 | 应做动作 | 目的 |
|---|---|---|
| Day 1 | Root 启用 MFA，删除/禁用 Root Access Key | 先锁最高权限账户 |
| Day 1-2 | 建立 Admin/Dev/ReadOnly 组 | 权限分层 |
| Day 2-3 | 所有人员用 IAM User + MFA | 身份可审计 |
| Day 3-4 | 服务访问改用 IAM Role | 去掉长期密钥 |
| Day 5 | 启用 CloudTrail + Config | 能追踪、能审计 |
| Day 6-7 | 清理过大权限策略（*:*） | 收敛风险面 |
Root 账户 vs IAM 用户
| 特性 | Root 账户 | IAM 用户 |
|---|---|---|
| 创建时间 | 注册 AWS 时自动创建 | 手动创建 |
| 权限 | 完全访问，无法限制 | 可自定义权限 |
| MFA | 强烈建议启用 | 建议启用 |
| 日常使用 | ❌ 不建议 | ✅ 建议 |
| 用例 | 账户级操作、支付设置 | 日常运维 |
一句话记忆：
- Root 像“总保险箱钥匙”，平时锁起来；日常工作用 IAM 用户/角色。
🛡️ AWS 安全服务
┌─────────────────────────────────────────────────────────────┐
│ AWS 安全服务生态 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 身份和访问管理 │ │
│ │ │ │
│ │ 🔐 IAM 身份和访问管理 │ │
│ │ 🎫 AWS SSO 单点登录 (现 IAM Identity Center) │ │
│ │ 📱 Cognito 移动/Web 应用用户身份验证 │ │
│ │ 📁 Directory 目录服务 (AD 集成) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 检测和响应 │ │
│ │ │ │
│ │ 🔍 GuardDuty 智能威胁检测 │ │
│ │ 🛡️ Inspector 漏洞扫描和评估 │ │
│ │ 🔎 Macie 敏感数据发现 (S3) │ │
│ │ ⚠️ Security Hub 安全状态聚合仪表板 │ │
│ │ 📊 Detective 安全调查和分析 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 网络和应用保护 │ │
│ │ │ │
│ │ 🔥 WAF Web 应用防火墙 │ │
│ │ 🛡️ Shield DDoS 防护 │ │
│ │ 🔒 Firewall Mgr 跨账户防火墙管理 │ │
│ │ 🌐 Network FW VPC 网络防火墙 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据保护 │ │
│ │ │ │
│ │ 🔑 KMS 密钥管理服务 │ │
│ │ 🗝️ CloudHSM 硬件安全模块 │ │
│ │ 🔐 Secrets Mgr 密钥和凭证管理 │ │
│ │ 📜 Certificate SSL/TLS 证书管理 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 合规和审计 │ │
│ │ │ │
│ │ 📝 CloudTrail API 调用日志 │ │
│ │ ⚙️ Config 资源配置跟踪和合规 │ │
│ │ 📋 Artifact 合规报告下载 │ │
│ │ 🔎 Audit Manager 审计证据收集 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
核心安全服务详解
| 服务 | 功能 | 考试重点 |
|---|---|---|
| AWS IAM | 身份和访问管理 | 用户、组、角色、策略 |
| AWS WAF | Web 应用防火墙 | 防 SQL 注入、XSS |
| AWS Shield | DDoS 防护 | Standard (免费) vs Advanced |
| AWS KMS | 密钥管理 | 加密密钥的创建和管理 |
| CloudTrail | API 审计日志 | 谁在何时做了什么 |
| AWS Config | 配置跟踪 | 资源配置变更历史 |
| GuardDuty | 威胁检测 | 智能检测恶意活动 |
| Inspector | 漏洞扫描 | EC2 和容器安全评估 |
| Macie | 敏感数据发现 | S3 中的 PII 检测 |
常考易混服务：一眼区分
| 服务 | 它回答的问题 | 常见题干关键词 |
|---|---|---|
| CloudTrail | “谁在何时调用了什么 API？” | API 审计、操作追踪、取证 |
| AWS Config | “资源配置有没有被改、是否合规？” | 配置历史、合规规则、漂移 |
| GuardDuty | “有没有可疑攻击行为？” | 威胁检测、异常活动、恶意 IP |
| Security Hub | “多账号安全告警如何统一看板？” | 汇总、集中视图、统一评分 |
配图：CloudTrail（API 审计轨迹）
图解说明：
- 先看“谁调用了什么 API”：CloudTrail 记录调用者、时间、来源、操作结果，是审计与取证基础。
- 再看日志落地：常配合 S3 做长期留存，配合 CloudWatch 做告警。
- 易混点：CloudTrail 管“操作日志”；CloudWatch 更偏“监控指标与应用日志”；Config 管“配置状态变化”。
AWS Shield: DDoS 防护
┌─────────────────────────────────────────────────────────────┐
│ AWS Shield 对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Shield Standard Shield Advanced │
│ ──────────────── ───────────────── │
│ │
│ ✅ 免费 💰 $3,000/月 + 数据费用 │
│ │
│ ✅ 自动启用 需要订阅 │
│ │
│ ✅ 第 3/4 层防护 ✅ 第 3/4/7 层防护 │
│ (网络/传输层) (包括应用层) │
│ │
│ 基本 DDoS 防护 ✅ 高级 DDoS 防护 │
│ ✅ 24/7 DDoS 响应团队 │
│ ✅ 成本保护 │
│ ✅ 实时指标和报告 │
│ ✅ WAF 集成 │
│ │
│ 适用: 适用: │
│ 所有 AWS 客户 关键业务、高风险应用 │
│ │
└─────────────────────────────────────────────────────────────┘
💡 考试技巧：Shield Standard 对所有客户免费自动启用！
⚠️ 易混点：
WAF 主要防应用层攻击（如 SQL 注入、XSS），Shield 主要防 DDoS。
题干出现“DDoS”优先想到 Shield；出现“SQL 注入/XSS”优先想到 WAF。
🔒 数据保护
加密类型
┌─────────────────────────────────────────────────────────────┐
│ 数据加密方式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 静态数据加密 (At Rest) │ │
│ │ │ │
│ │ 数据存储时的加密 │ │
│ │ │ │
│ │ 💾 S3: 服务器端加密 (SSE-S3, SSE-KMS, SSE-C) │ │
│ │ 💿 EBS: 卷加密 │ │
│ │ 🗄️ RDS: 数据库加密 │ │
│ │ 📁 EFS: 文件系统加密 │ │
│ │ │ │
│ │ 使用 AWS KMS 管理加密密钥 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 传输中数据加密 (In Transit) │ │
│ │ │ │
│ │ 数据传输时的加密 │ │
│ │ │ │
│ │ 🔐 HTTPS/TLS - Web 流量加密 │ │
│ │ 🔒 VPN - 站点到站点连接 │ │
│ │ 🔑 SSL/TLS - API 调用 │ │
│ │ │ │
│ │ 使用 AWS Certificate Manager (ACM) 管理证书 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
考试快速判断：
- 题干强调“存储时加密” ->
Encryption at Rest - 题干强调“传输链路防窃听” ->
Encryption in Transit
S3 加密选项
| 加密类型 | 描述 | 密钥管理 |
|---|---|---|
| SSE-S3 | S3 管理的密钥 | AWS 完全管理 |
| SSE-KMS | KMS 管理的密钥 | 可审计、可控制 |
| SSE-C | 客户提供的密钥 | 客户完全管理 |
| 客户端加密 | 上传前加密 | 客户完全管理 |
一句话选型：
- 要省事：
SSE-S3 - 要审计与细粒度权限：
SSE-KMS（考试最常考） - 有极端密钥控制要求：
SSE-C或客户端加密
配图：KMS Architecture（密钥管理路径）
图解说明：
- 先看 KMS 的角色：KMS 主要“管密钥”，业务数据由 S3/EBS/RDS 等服务存储。
- 再看调用关系：业务服务在需要加解密时向 KMS 请求数据密钥或使用 CMK 进行受控加密操作。
- 考试高频点：KMS 不是“存秘密文本”的主服务；存数据库密码/API Key 更偏 Secrets Manager。
配图：S3 + KMS（SSE-KMS 加密链路）
图解说明：
- 先看上传路径：对象写入 S3 时触发 SSE-KMS，加密过程由 S3 调用 KMS 完成。
- 再看读取路径：授权用户读取对象时，S3 通过 KMS 完成解密后返回明文数据流。
- 考试怎么问：出现“需要审计密钥使用、细粒度控制谁可解密”时，优先
SSE-KMS。
KMS、Secrets Manager、CloudHSM 区别
| 服务 | 主要用途 | 记忆点 |
|---|---|---|
| KMS | 管理加密密钥（CMK） | “管钥匙” |
| Secrets Manager | 管密码/密钥并可自动轮换 | “管机密” |
| CloudHSM | 专用硬件安全模块 | “超高合规硬件管钥匙” |
📋 AWS 合规计划
┌─────────────────────────────────────────────────────────────┐
│ AWS 合规认证 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 全球标准 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ISO 27001 - 信息安全管理体系 │ │
│ │ ISO 27017 - 云安全控制 │ │
│ │ ISO 27018 - 云中个人数据保护 │ │
│ │ SOC 1/2/3 - 服务组织控制报告 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 行业标准 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ PCI DSS - 支付卡行业数据安全标准 │ │
│ │ HIPAA - 健康信息保护 (美国医疗) │ │
│ │ FedRAMP - 美国联邦政府云安全 │ │
│ │ HITRUST - 健康信息信托联盟 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 地区标准 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GDPR - 欧盟通用数据保护条例 │ │
│ │ IRAP - 澳大利亚政府安全评估 │ │
│ │ MTCS - 新加坡多层云安全 │ │
│ │ C5 - 德国云计算合规标准 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 📥 AWS Artifact: 下载合规报告和协议 │
│ │
└─────────────────────────────────────────────────────────────┘
AWS Artifact
AWS Artifact 是一个自助服务门户，用于访问 AWS 合规报告和协议。
| 功能 | 描述 |
|---|---|
| 合规报告 | 下载 SOC、PCI、ISO 等审计报告 |
| 协议管理 | 查看和接受 BAA、NDA 等协议 |
| 免费访问 | 所有 AWS 客户免费使用 |
合规题常见误区
- AWS “有某项认证” 不等于你“自动合规”
- AWS 提供的是合规能力和审计材料，你还需要完成自己的流程与控制
- 题目问“下载 SOC/ISO 报告”时，答案通常是 AWS Artifact
🎯 CLF-C02 安全题秒选框架
- 先判断题目在问哪一类：身份权限 / 检测审计 / 网络防护 / 数据加密
- 再抓关键词：API 审计、配置漂移、DDoS、SQL 注入、密钥轮换
- 用“最小可行服务”作答，避免过度设计
高频映射：
- “谁在何时做了什么 API 调用” ->
CloudTrail - “资源配置是否合规、是否变更” ->
AWS Config - “基础且免费 DDoS 防护” ->
Shield Standard - “下载 SOC/ISO 合规报告” ->
AWS Artifact
⚠️ 常见错误与误区
| 错误 | 正确理解 |
|---|---|
| ❌ AWS 负责 EC2 操作系统补丁 | ✅ EC2 是 IaaS，客户负责 OS 补丁 |
| ❌ IAM 策略默认允许所有操作 | ✅ IAM 默认拒绝一切，必须显式允许 |
| ❌ Root 账户应该用于日常操作 | ✅ Root 仅用于账户级操作，日常用 IAM |
| ❌ Shield Advanced 是免费的 | ✅ Standard 免费，Advanced $3000/月 |
| ❌ AWS 负责 S3 数据的加密 | ✅ 客户决定是否加密及如何加密 |
| ❌ IAM 组可以嵌套 | ✅ IAM 组不能包含其他组 |
| ❌ MFA 只能用手机 | ✅ 支持虚拟 MFA、硬件令牌、U2F |
📝 考试场景题
场景 1：EC2 安全责任
问题：你的公司运行 EC2 实例，发现操作系统有安全漏洞需要打补丁。谁负责应用这个补丁？
分析：
- EC2 是 IaaS 服务
- 客户负责 "云中的安全"
- 操作系统是客户责任
答案：客户 负责 EC2 实例的操作系统补丁
场景 2：权限管理
问题：你需要让一个 EC2 实例访问 S3 存储桶，但不想在实例中存储访问密钥。应该怎么做？
分析：
- 避免长期凭证
- 需要临时权限
- EC2 访问其他服务
答案：创建 IAM 角色 并将其附加到 EC2 实例
场景 3：DDoS 防护
问题：你的网站需要防护 DDoS 攻击，但预算有限。哪个服务可以提供基本保护而不产生额外费用？
分析：
- 需要 DDoS 防护
- 预算有限
- 基本保护即可
答案：AWS Shield Standard - 对所有客户免费自动启用
✏️ 练习题
题目 1
在共享责任模型中，谁负责 EC2 实例的操作系统补丁？
- A. AWS
- B. 客户
- C. 共同负责
- D. 第三方供应商
答案：B
解析：
- EC2 是 IaaS 服务，客户获得完全控制
- AWS 负责底层硬件和虚拟化层
- 客户负责操作系统及以上的所有内容
- 这包括 OS 补丁、防火墙配置、应用程序等
题目 2
哪个 IAM 组件提供临时安全凭证？
- A. IAM 用户
- B. IAM 组
- C. IAM 角色
- D. IAM 策略
答案：C
解析：
- IAM 用户: 长期凭证（密码、访问密钥）
- IAM 组: 用户的集合，本身没有凭证
- IAM 角色: 提供临时凭证，自动轮换
- IAM 策略: 权限文档，不是凭证
角色最适合需要临时访问的场景，如 EC2 访问 S3。
</details>题目 3
以下哪项是 IAM 最佳实践？
- A. 共享 root 账户凭证
- B. 为每个用户创建单独的 IAM 用户
- C. 使用广泛的权限策略
- D. 避免使用 MFA
答案：B
解析：
- A. 错误 - 永远不要共享凭证
- B. 正确 - 每人一个 IAM 用户，便于审计和管理
- C. 错误 - 应使用最小权限原则
- D. 错误 - 应该启用 MFA
题目 4
哪个服务提供免费的 DDoS 防护？
- A. AWS WAF
- B. AWS Shield Standard
- C. AWS Shield Advanced
- D. AWS Firewall Manager
答案：B
解析：
- AWS WAF: 需要付费
- Shield Standard: 免费，自动为所有 AWS 客户启用
- Shield Advanced: $3,000/月 + 数据传输费
- Firewall Manager: 需要付费
题目 5
哪个服务记录 AWS API 调用以供审计？
- A. Amazon CloudWatch
- B. AWS CloudTrail
- C. AWS Config
- D. AWS Inspector
答案：B
解析：
- CloudWatch: 监控和指标（性能监控）
- CloudTrail: API 调用审计日志（谁在何时做了什么）
- Config: 资源配置历史（配置变更追踪）
- Inspector: 安全漏洞扫描
CloudTrail 专门记录所有 AWS API 调用，用于安全分析和合规审计。
</details>📚 本章小结
| 主题 | 要点 |
|---|---|
| 共享责任模型 | AWS 负责"云的安全"，客户负责"云中的安全" |
| IaaS 责任 | EC2 - 客户负责 OS、应用、数据 |
| PaaS 责任 | RDS - AWS 负责 OS 和引擎补丁 |
| IAM 用户 | 长期凭证，代表个人 |
| IAM 组 | 用户集合，不能嵌套 |
| IAM 角色 | 临时凭证，推荐使用 |
| IAM 策略 | JSON 权限文档，默认拒绝 |
| 最小权限 | 只授予完成任务所需的最小权限 |
| MFA | 为所有用户（尤其是 root）启用 |
| Shield | Standard 免费，Advanced $3000/月 |
| KMS | 密钥管理服务，加密数据 |
| CloudTrail | API 调用审计日志 |
| Artifact | 下载合规报告 |