hardening-cloud-posture

强化云安全态势

一次 CSPM 扫描会返回上千条发现。几乎没有一条是真正的入侵路径。 任务不是关闭上千条发现，而是找出构成攻击路径的少数几条并予以修复， 然后设置防护措施，避免问题再次出现。把每条发现都同等对待的态势治理， 会淹没真正重要的问题。

核心原则：身份就是边界。 在云环境中，攻击路径几乎总是由一连串 IAM 权限构成，而非网络跃点。应按“这能让某个主体访问什么？”排序，而不是看 扫描器标注的严重性。

适用场景

• 审查 AWS/Azure/GCP 账户或组织的安全态势
• 对 Prowler、ScoutSuite、Security Hub 或 Defender for Cloud 报告进行分类
• 判断众多错误配置中哪些真正重要
• 设置预防性防护措施（SCP、Azure Policy、组织策略）
• 启用调查后续所需的日志记录和控制措施

不适用场景

• 正在调查实时事件——使用 investigating-aws-incidents、 investigating-azure-incidents 或 investigating-gcp-incidents
• 通过攻击环境来验证攻击路径——使用 exploiting-cloud-platforms
• 加固 Kubernetes 集群控制平面——使用 defending-kubernetes
• 对工作负载中的 CVE 排序，而非处理云配置问题——使用 managing-vulnerabilities

按攻击路径排序，而非按发现数量排序

应按攻击者利用问题的顺序处理发现，而不是按照扫描器的列表顺序：

1. 数据或计算资源暴露于公网。 公共 S3/GCS 存储桶和存储账户、 可从公网访问的数据库，以及对 0.0.0.0/0 开放的管理端口。 这些都不需要凭据——它们在身份验证前即可访问。优先关闭。
2. 权限过大的身份。 使用通配符 Action/Resource 的策略、 可由 * 或无条件外部账户担任的角色、拥有对特权角色执行 iam:PassRole 权限的用户，以及具有 Owner 权限的服务主体。这 正是立足点演变为账户接管的路径。
3. 缺少或已禁用审计日志记录。 CloudTrail 未启用多区域记录、GCP Data Access 日志已关闭、Azure 诊断设置缺失。这不会直接造成入侵，却会让调查 失明——现在就启用，因为无法追溯记录即将发生的事件。
4. 数据未加密且缺少密钥管理。 这些问题确实存在，但很少是入侵入口。 除非合规义务要求调整优先级，否则应在处理以上问题后修复。

含有客户数据的公共存储桶，优先级高于上百条“未启用加密”的发现，即便 扫描器可能给它们相同的评分。

批判性地解读 CSPM 输出

Prowler、ScoutSuite、Security Hub 和 Defender for Cloud 都是常用工具，也 很有用——但它们的输出只是起点，并非定论：

• 严重性是通用的。 工具不了解你的环境。可跨账户担任的角色被标为“中” 级，可能是你最严重的问题；仅限内部访问的资源被标为“高”级，则可能只是 噪声。
• 发现不包含影响范围。 工具会报告某项策略包含 *；但不会告诉你该角色 附加到了一个面向互联网的函数上。可达性需要由你来判断。
• 抑制规则会掩盖真实风险。 几个月前以“已接受”为由抑制的发现，如今可能 已不可接受。应像审查未解决的发现一样仔细审查抑制列表。
• 绿色不等于干净。 扫描器只会检查它所检查的内容。即使扫描通过，如果 Data Access 日志记录处于禁用状态，也存在很大的盲区，扫描器永远不会将其 报告为发现。

如果合规框架有帮助，可将重要发现对应到 CIS Benchmark 控制项，但不要让 基准决定优先级——基准涵盖面广，而你的修复预算有限。

防护措施胜过发现项

一次固定的错误配置会在下次有人配置资源时再次出现。防护措施可以杜绝整类问题：

• **AWS：**使用服务控制策略（Service Control Policies）在整个组织范围内禁止公开 S3、禁止停用 CloudTrail、限制区域；在账户级别启用 s3:BlockPublicAccess。
• **Azure：**使用 Azure Policy，通过 deny 效果禁止公共网络访问，并要求启用加密和诊断设置。
• **GCP：**使用组织策略约束（storage.publicAccessPrevention、iam.disableServiceAccountKeyCreation、compute.requireOsLogin）。

优先采用组织级的 deny，而不是逐个资源修复。单点修复只能消除一个发现项；防护措施则能杜绝整类问题及其所有未来实例。

应当驳斥的托词

• “我们已经关闭了所有高严重性发现项。” 严重性是扫描器根据通用环境做出的猜测。真正重要的是攻击路径上的发现项，不管它被标记为何种级别。
• “扫描结果是绿色的，所以账户很安全。” 扫描只涵盖它检查的内容。日志记录被停用、工具评为低风险的权限过宽角色，以及被抑制的发现项，都不会反映在绿色结果中。
• “静态数据加密是我们最大的缺口。” 它很少是入侵路径。公开存储桶或可由其他账户承担的管理员角色，风险都高于它，除非合规要求必须优先处理加密。
• “我们修复了公开存储桶。” 只是一个存储桶。如果没有组织级防护措施，下周另一个团队就会把同类存储桶设为公开。要修复的是整类问题。
• “那个发现项已被接受为风险。” 谁接受的？何时接受的？现在还成立吗？过期的风险接受记录正是实际暴露藏身之处。
• “IAM 太复杂，无法全面审计。” 那就先审计权限提升原语——PassRole、通配符信任策略、跨账户承担角色——也不要什么都不做。身份是安全边界；不能不管。

阅读外部来源

将公开公告、规范和供应商报告提取为 Markdown：

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

这会剔除网页的冗余内容——对于纯文本页面，令牌数大约减少 78%——并返回全文而非摘要，因此你可以搜索内容，也可以相信未找到结果。

以下三种情况不适用。对于 JSON 和 API 响应，应直接获取原始内容，因为可读性提取会破坏结构化数据。对于需要身份验证或由 JavaScript 渲染的页面，也应直接获取，因为它会以匿名方式检索页面。切勿通过它传递对手基础设施（钓鱼链接、C2、恶意软件托管）、客户端所有的主机或渗透测试任务 URL——请求会离开你的机器并发送给第三方；如果目标是活跃的对手基础设施，还会向操作者发出警报。

某些网站会拦截提取器，并返回错误信息而非页面内容——例如 freedesktop.org 返回的 {"error":"Failed to fetch: 418 I'm a teapot"}。这表示抓取请求被拒绝，并不表示来源站点说该内容不存在。得出任何结论之前，请直接重新抓取该 URL。

参考资料

• exploiting-cloud-platforms — 本安全态势工作旨在封堵的攻击路径
• investigating-aws-incidents / investigating-azure-incidents / investigating-gcp-incidents — 本文启用的审计日志所支持的调查工作
• defending-kubernetes — 账户运行托管 k8s 时适用的集群层面防护
• managing-vulnerabilities — 与配置安全态势对应的工作负载 CVE