☁️ 云漏洞管理：使用 Prowler 进行 AWS 资产安全评估
识别 → 评估 → 排定优先级 → 补救 → 验证
使用 Prowler 云安全态势管理，将完整的漏洞管理生命周期应用于真实的 AWS 账户。
## 📌 执行摘要
本项目使用开源云安全态势管理 (CSPM) 平台 **Prowler**，将**漏洞管理生命周期**应用于真实的 Amazon Web Services 账户（`819211780002`，别名 *Phour Global Limited*）的*虚拟资产*。
我们配置了一个最小权限扫描身份，在 6 分 20 秒内扫描了 **跨 17 个 AWS 区域的 285 个资源**，并将结果汇总到结构化的**网络风险登记册**中，使用 5x5 矩阵进行评分，最后转化为由责任人指定的**补救计划**。
| 指标 | 结果 |
|---|---|
| 🎯 总体 Prowler ThreatScore | **85.05%** |
| 🖥️ 已评估资源 | 跨 **17** 个区域的 **285** 个 |
| ❌ 失败的发现 | **81** |
| 🚨 严重失败的要求 | **6** |
| 📋 已正式登记并排定优先级的风险 | **10** (4 个严重，6 个高) |
| 🛡️ 扫描身份 | 专用的**最小权限** IAM 用户 |
## 🧭 目录
- [目标](#-objectives)
- [方法论](#-methodology-the-vulnerability-management-lifecycle)
- [阶段 1：最小权限扫描身份](#-phase-1-least-privilege-scanning-identity)
- [阶段 2：扫描执行](#-phase-2-scan-execution)
- [阶段 3：评估结果](#-phase-3-assessment-results)
- [阶段 4：风险分析与优先级排序](#-phase-4-risk-analysis-and-prioritization)
- [阶段 5：补救计划](#-phase-5-remediation-plan)
- [关键要点](#-key-takeaways)
- [仓库结构](#-repository-structure)
- [完整文档](#-full-documentation)
- [作者](#-author)
## 🎯 目标
1. 为云安全扫描配置一个专用的、**最小权限**的身份。
2. 使用 Prowler 对 AWS 账户执行自动化的漏洞与合规性评估。
3. 解读 **ThreatScore** 并识别最实质性的弱点。
4. 将发现汇总并排定优先级至结构化的**网络风险登记册**（5x5 矩阵）中。
5. 制定一份包含明确响应策略的**责任人指定补救计划**。
## 🔄 方法论：漏洞管理生命周期
```
┌────────────┐ ┌──────────┐ ┌──────────────┐ ┌─────────────┐ ┌──────────┐
│ IDENTIFY │ → │ ASSESS │ → │ PRIORITIZE │ → │ REMEDIATE │ → │ VERIFY │
│ (Prowler │ │ (Threat │ │ (5x5 Risk │ │ (Owners + │ │ (Re-scan │
│ inventory)│ │ Score) │ │ Register) │ │ Strategy) │ │ planned)│
└────────────┘ └──────────┘ └──────────────┘ └─────────────┘ └──────────┘
```
本仓库记录了从识别到补救（计划）阶段的过程。验证（补救后的重新扫描）被定义为下一步。
## 🔐 阶段 1：最小权限扫描身份
扫描由专用的 IAM 用户（`Prowler-scan-user`）执行，该用户**仅具有编程访问权限**，绝不由特权管理员执行。附加了三个策略：
| 策略 | 类型 | 用途 |
|---|---|---|
| `SecurityAudit` | AWS 托管 | 读取跨服务的安全配置 |
| `ViewOnlyAccess` | AWS 托管 | 枚举资源而不进行修改 |
| `prowler-additions-policy` | 客户托管 | Prowler 所需的最少额外读取权限 |
Least-privilege permission set attached to the dedicated scanning user.
## ⚡ 阶段 2：扫描执行
针对已连接的 AWS provider 启动了手动 ThreatScore 扫描，并顺利完成。
Completed scan: 285 resources, 6 min 20 sec, 17 regions (scan ID 019ee5c2...).
## 📊 阶段 3：评估结果
### 各支柱的 ThreatScore
| 支柱 | 分数 | 评级 |
|---|---|---|
| 身份与访问管理 | 70.3% | ⚠️ 中等：密码策略和 root MFA 存在缺失 |
| 攻击面 | 91.2% | ✅ 强：公开暴露有限 |
| **日志与监控** | **0.0%** | 🔴 **严重：无检测控制** |
| 加密 | 92.0% | ✅ 强：存在少量的静态加密缺失 |
| **总体 ThreatScore** | **85.05%** | 加权汇总 |
85.05% ThreatScore. The 0.0% Logging and Monitoring pillar is hidden behind a healthy aggregate.
### 严重失败的要求 (6)
| ID | 要求 | 支柱 | 风险 / 权重 |
|---|---|---|---|
| 1.1.2 | 为 **root** 用户启用硬件 MFA | IAM | 5 / 1000 |
| 2.1.6 | 实例的常用端口未暴露在互联网上 | 攻击面 | 5 / 1000 |
| 2.1.7 | 安全组不允许流入常用端口 | 攻击面 | 5 / 1000 |
| 1.3.1 | 未附加具有完全 `*:*` 权限的 IAM 策略 | IAM | 4 / 100 |
| 2.1.4 | 没有安全组允许从 `0.0.0.0/0` 流入管理端口 | 攻击面 | 4 / 100 |
| 3.1.1 | 在所有区域启用 CloudTrail | 日志与监控 | 4 / 100 |
Failed-findings list, ranked by severity, used to drive risk consolidation.
## 🗂️ 阶段 4：风险分析与优先级排序
81 个失败的发现跨区域进行了去重，并汇总为网络风险登记册中的 **10 个独立风险**，每个风险都在 **5x5（影响 x 可能性）** 矩阵上进行了评分。
| 等级 | 分数范围 |
|---|---|
| 🟩 低 | 1 到 5 |
| 🟨 中等 | 6 到 10 |
| 🟧 高 | 11 到 15 |
| 🟥 极高 | 16 到 25 |
### 已排定优先级的风险登记册（摘要）
| 编号 | 风险 (Prowler 发现) | 等级 | 策略 |
|---|---|---|---|
| RI-001 | IAM 用户直接附加了 `AdministratorAccess` | 🟥 严重 | 缓解 |
| RI-002 | Root 账户缺少硬件 MFA 设备 | 🟥 严重 | 缓解 |
| RI-003 | AWS 托管策略允许 `*:*` 管理员权限 | 🟥 严重 | 缓解 |
| RI-004 | EC2 实例向互联网暴露了 TCP 22 (SSH) | 🟥 严重 | 缓解 |
| RI-005 | 未启用带有标准/集成的 Security Hub | 🟧 高 | 缓解 |
| RI-006 | 未启用 GuardDuty detector | 🟧 高 | 缓解 |
| RI-007 | GuardDuty 缺少委托管理员 / 组织自动启用 | 🟧 高 | 缓解 |
| RI-008 | CloudTrail 未在所有区域记录日志 | 🟧 高 | 缓解 |
| RI-009 | IAM 用户缺少硬件 MFA | 🟧 高 | 缓解 |
| RI-010 | VPC 子网默认分配公共 IP | 🟧 高 | 缓解 |
📥 包含描述、责任人、日期和状态的完整登记册：[`docs/Cyber-Risk-Register.xlsx`](docs/Cyber-Risk-Register.xlsx)
## 🛠️ 阶段 5：补救计划
每个风险都被分配了责任人和**缓解**策略。按领域划分的计划操作：
| 领域 | 关键计划操作 |
|---|
| 身份与访问 | 在 root 上注册硬件 MFA 并删除 root 访问密钥 · 移除直接的 AdministratorAccess 并应用限定的最小权限策略 · 为 IAM 用户强制执行硬件 MFA 和更强的密码策略 |
| 日志与监控 | 部署多区域 CloudTrail · 在组织范围内启用 Security Hub 和 GuardDuty · 启用 AWS Config · 为敏感事件添加 CloudWatch 指标过滤器和警报 |
| 攻击面 | 限制 SG/NACL 流入，确保管理端口永远不对 0.0.0.0/0 开放 · 禁用在私有子网上自动分配公共 IP |
| 加密 | 强制执行 IMDSv2 · 拒绝非 HTTPS S3 访问 · 使用 KMS CMK 加密 EBS 卷和 CloudTrail 日志 |
Prowler finding detail with built-in remediation guidance for the root hardware MFA gap.
## 💡 关键要点
- **高总分可能会掩盖系统性缺失。** 总体 85.05%，但检测控制覆盖率为 **0.0%**。
- **检测控制是不可妥协的。** 由于 17 个区域均缺少 CloudTrail、Config、GuardDuty 和 Security Hub，该账户对恶意活动的可见性为*零*。
- **强大的外围防御并不等于强大的安全态势。** 攻击面 (91.2%) 和加密 (92.0%) 表现稳健；薄弱环节在于*可观测性与身份*，而不是暴露。
- **实践中的最小权限。** 评估本身通过只读、无写入的扫描身份树立了良好的安全卫生典范。
## 📁 仓库结构
```
.
├── README.md ← you are here
├── assets/
│ └── screenshots/ ← highlight images used in this README
└── docs/
├── Cyber-Risk-Register.xlsx ← full 5x5 risk register
├── Prowler-ThreatScore-Report.pdf ← raw Prowler ThreatScore export
├── AWS-Cloud-Vulnerability-Management-APA-Report.pdf ← full APA report (chronological walkthrough)
└── build_docx.py ← report generator (reproducible)
```
## 📄 完整文档
| 文档 | 描述 |
|---|---|
| 📘 [APA 评估报告 (PDF)](docs/AWS-Cloud-Vulnerability-Management-APA-Report.pdf) | 完整的时间线演练，APA 第 7 版，按顺序包含所有捕获的截图，以及风险分析和补救计划 |
| 📊 [网络风险登记册 (XLSX)](docs/Cyber-Risk-Register.xlsx) | 风险评分、责任人、响应策略和状态 |
| 📑 [Prowler ThreatScore 报告 (PDF)](docs/Prowler-ThreatScore-Report.pdf) | 所有失败要求的原生 Prowler 导出文件 |
## 👤 作者
**Ibrahim Fayomi** · 网络安全指导计划
云安全 · 漏洞管理 · 安全态势管理
⚠️ 出于教育目的在受控的实验室账户中进行。未影响任何生产系统。