Catheren/aws-security-posture

# AWS 云安全态势 [](https://aws.amazon.com/) [](https://aws.amazon.com/guardduty/) [](https://aws.amazon.com/security-hub/) [](https://aws.amazon.com/config/) [](https://aws.amazon.com/inspector/) [](https://www.python.org/) 一个实操性的多账号 AWS 安全项目，展示了相关的架构、工具运用和专业判断能力。 本项目基于 AWS 构建，在单一的 AWS Organizations 下包含三个工作负载账号（security、prod、dev）。这里的每一个决策——启用什么功能、在哪里运行、以及暂缓哪些操作——都真实反映了中小型企业会如何在实际中运营这套技术栈，而不是单纯罗列每一个可用的开关选项。 ## 本项目展示了什么 | 技能 | 实现方式 | |---|---| | 多账号 AWS 安全架构 | 4 账号模式，通过 AWS Organizations 实现委派管理员 | | 威胁检测 | 在整个组织内部署 GuardDuty 并集中管理发现结果 | | 云安全态势管理 (CSPM) | Security Hub CSPM 结合 CIS AWS Foundations Benchmark v5.0.0 | | 配置合规性 | AWS Config 结合自定义 Lambda 规则 + 2 项托管规则 | | 漏洞管理 | 在所有账号中对 EC2 和 ECR 进行 Amazon Inspector 扫描 | | 跨账号事件流水线 | EventBridge 将所有 CloudTrail 事件转发至中央安全总线 | | 兼容 SIEM 的架构 | 通过 Kinesis Firehose 构建 S3 落地专区，实现与供应商无关的数据接入 | | 事件响应 | 针对凭证泄露、公开的 S3、可疑 IAM 行为的 IR 应急预案 | | 检测差距分析 | 通过覆盖图记录原生检测与自定义检测的决策对比 | ## 架构 ``` Management Account (org root) │ │ delegates admin (GuardDuty, Security Hub, Inspector, Config) │ └── Security Account (centralized visibility hub) │ GuardDuty · Security Hub CSPM · Config aggregator │ Inspector · EventBridge central bus · Config rules │ SNS alerting · S3 SIEM export bucket │ ├── Prod Account (us-east-2) │ GuardDuty member · Config recorder · Inspector │ EventBridge → central bus · EC2 · S3 · IAM · RDS │ └── Dev Account (us-east-2) GuardDuty member · Config recorder · Inspector EventBridge → central bus · dev workloads > **Note:** AWS resources were deprovisioned after project completion to avoid ongoing costs. > The console-walkthrough.md documents the full setup process and can be used to reproduce > the environment. ``` security 账号没有自己的工作负载。它纯粹作为可视化和控制中心而存在——提供一个集中的位置来查看所有账号的安全发现、合规态势和漏洞数据，而无需为每个账号单独配置凭证。 ## 仓库结构 ``` aws-cloud-security-engineering/ console-walkthrough.md Step-by-step setup guide docs/ coverage-map.md Native vs custom detection analysis cis-benchmark-mapping.md CIS findings triage notes lambda/ no_wildcard_iam.py Custom Config rule evaluation logic playbooks/ IR playbooks (credential compromise, public S3, suspicious IAM activity) ``` ## 构建内容 ### 账号结构与委派 四账号模式（management、security、prod、dev）是 AWS 为任何运行多环境的组织推荐的基线架构。management 账号的唯一职责是为 security 账号授予各项服务的委派管理员状态——它不运行任何工作负载，也没有长期配置。 有一个不太明显的细节：Config 的委派管理员注册只能通过 CLI 完成。GuardDuty、Security Hub 和 Inspector 在控制台上都有对应的操作按钮，但 Config 没有——它要求通过 CloudShell 在 management 账号中运行 `aws organizations register-delegated-administrator`。这是产品体验上的不一致，而不是安全模型有什么不同。 ### GuardDuty 在所有三个账号中启用，并将 security 账号设为委派管理员。Prod 和 dev 通过组织设置自动加入，因此任何加入该组织的新账号都会自动受到 GuardDuty 的保护。 **功能：** 行为威胁检测。监控 CloudTrail API 调用、VPC Flow Logs 和 DNS 查询。利用威胁情报源和 ML 基线来标记异常模式——例如在异常位置使用的凭证、进行可疑出站连接的 EC2 实例、IAM 枚举行为等。 **不包含的功能：** 它不检查实例上的软件漏洞（那是 Inspector 的工作），不评估 AWS 资源配置（那是 Config 和 Security Hub CSPM 的工作），也不支持自定义检测规则。其检测逻辑是一个托管的黑盒。 **设计提示：** GuardDuty 原生涵盖了几种通常被认为需要自定义检测的模式——例如不可能的登录地点、权限提升异常、root 账号使用等。在构建任何自定义规则之前，本项目详细记录了 GuardDuty 能够捕获的内容及其盲区。请参阅 `docs/coverage-map.md`。 ### AWS Config 在所有三个账号中均已启用。security 账号运行着一个组织聚合器，将 prod 和 dev 的配置历史和合规结果提取到一个统一视图中。 **功能：** 持续的配置合规性。记录 AWS 资源的每一项变更，并根据规则（包括 AWS 托管规则和自定义规则）对其进行评估。它可以回答诸如“自昨天以来是否有 S3 存储桶被公开？”或“哪些 IAM 用户没有启用 MFA？”等问题。 **正在运行的三项规则：** | 规则 | 类型 | 触发条件 | |---|---|---| | `s3-bucket-public-read/write-prohibited` | AWS 托管 | 配置变更 | | `mfa-enabled-for-iam-console-access` | AWS 托管 | 定期（计划任务） | | `no-wildcard-iam-policies` | 自定义 Lambda | 配置变更 | MFA 规则是按计划运行的，而不是对变更做出反应——因为用户是否绑定了 MFA 设备并不会在 Config 中作为独立的配置变更事件被捕获。在设计合规性覆盖范围时，区分变更触发规则和定期触发规则至关重要。 通配符 IAM 策略规则是一个自定义的 Lambda 函数，用于评估每一个客户托管的 IAM 策略，检查是否同时包含 `"Action": "*"` 和 `"Resource": "*"` 的语句。其实 AWS 托管规则 `iam-policy-no-statements-with-admin-access` 已经涵盖了相同的检查——保留自定义版本仅作为编写 Config 评估逻辑的演示。在生产环境中，选择托管规则才是正确的做法。 ### Security Hub CSPM 在 security 账号中启用，并激活了 CIS AWS Foundations Benchmark v5.0.0 标准。 **功能：** 主要包含两点。首先，将 GuardDuty、Inspector 和 Config 的安全发现汇总到单一仪表板中。其次，根据已启用的标准（如 CIS、FSBP、PCI DSS、NIST）对 AWS 资源配置执行合规性检查。 **名称提示：** AWS 在 2025 年底推出了一款名为“Security Hub”的独立新产品（这是一种使用 OCSF 格式的较新关联层）时，将原有的 Security Hub 更名为“Security Hub CSPM”。对于拥有基于 ASFF 自动化架构的团队来说，Security Hub CSPM 是正确的选择。这两个产品在控制台的 Security Hub 区域下都会显示，这种并存容易引起混淆，了解这一点很有必要。 CIS 基准的评估分类工作——即确定哪些控件失效是真正的问题、哪些是沙盒噪音、哪些属于可接受的风险——已被记录在 `docs/cis-benchmark-mapping.md` 中。这种判断能力才是真正的安全核心工作，而不是仅仅启用标准这个动作本身。 ### Amazon Inspector 在所有三个账号中启用，由 security 账号担任委派管理员，负责扫描 EC2 实例和 ECR 容器镜像。 **功能：** 漏洞评估。将 EC2 实例和容器镜像上安装的软件包与 CVE 数据库进行比对。例如，运行了存在漏洞的 OpenSSL 版本的实例会在此处被标记出来。 **与 GuardDuty 的区别：** GuardDuty 关注的是“当前是否正在发生恶意行为？”而 Inspector 关注的是“我的软件是否存在已知漏洞？”前者监控行为，后者监控已安装的软件。两者无法相互替代。 ### EventBridge 跨账号事件流水线 prod 和 dev 环境中的 EventBridge 转发规则会将所有 CloudTrail 管理事件发送到 security 账号中的 `central-security-bus`。 **此项功能的优势：** 挂载到中央总线上的任何实时检测或响应机制，无需在那些账号中配置凭证，即可查看 prod 和 dev 中的事件。无论是 SIEM 连接器、检测 Lambda 还是自动响应功能，都可以在此订阅。 **为什么转发所有事件：** 检测上下文依赖于完整的事件流，而不仅仅是你在编写过滤器时预期到的事件。在 EventBridge 规则层面进行过滤，本质上是在用检测覆盖率换取成本的降低——任何利用未被过滤掉的 API 调用的攻击技术，对于下游的所有组件来说都将是不可见的。在中小型账号的活动量级别下，成本差异微乎其微。当数据量增长时，进行过滤的合适位置是在下游的 SIEM 中，这样检测逻辑就可以在不改动基础设施的前提下不断演进。 ### SIEM 导出路径 security 账号中的一个 S3 存储桶充当了与供应商无关的落地专区，用于接收来自中央 EventBridge 总线、通过 Kinesis Data Firehose 传输的原始 CloudTrail 事件和安全发现结果。 **为什么选择 S3 作为落地专区：** Splunk、Microsoft Sentinel、Elastic 和 Datadog Security 都原生支持从 S3 接入数据。这样 SIEM 就能获得完整的事件上下文——而不是预先过滤过的子集——这正是实现跨账号和跨服务事件关联的关键。现在预先配置好这一切，意味着将来接入 SIEM 时只需更改配置即可，而无需重新设计数据流水线。 **为什么不用自定义 Lambda 检测作为替代方案：** 对于中小型安全团队来说，通过 SIEM 运营原生的 AWS 安全发现结果，比维护定制的检测代码更为实际。自定义 Lambda 检测通常是拥有专门检测工程职能的大型团队才会采用的模式。目前的架构支持将其作为未来的扩展方向接入，而不需要进行重新设计。 ## 关键设计决策 **security 账号是此架构中价值最高的攻击目标。** 作为所有检测服务的委派管理员，意味着 security 账号一旦被攻破，暴露的将不仅仅是一个工作负载——它将暴露整个组织的可见性和配置控制权，甚至可能让攻击者获得在 prod 和 dev 中悄悄关闭检测能力的权限。缓解措施包括：任何人工访问都必须强制使用抗钓鱼的 MFA；通过 IAM Identity Center 使用短期凭证（不保留常驻的 IAM 用户）；账号内不运行任何工作负载；并利用 GuardDuty 和 Config 对 security 账号本身进行监控。 **特意将 dev 纳入监控范围。** 攻击者窃取了开发者的凭证后，绝对不会只停留在 dev 环境中。通过扮演假定角色或利用共享密钥，从 dev 横向移动到 prod 是一条真实存在的攻击路径。如果认为 dev 不在检测范围内，就会在最容易被攻击者盯上的切入点制造盲区。 **优先使用原生工具，而非自定义检测。** GuardDuty、Security Hub CSPM、Config 和 Inspector 开箱即用，共同覆盖了最常见的云攻击模式。在构建任何自定义检测之前，应该提出这样的问题：原生工具是否已经具备此功能？如果是，那么自定义规则到底能带来什么实际价值——是填补盲区，还是仅仅为了调整控制粒度？覆盖图记录了针对最常见的 IAM 和凭证滥用检测模式的此项分析。 **将所有事件转发至 SIEM 导出存储桶。** SIEM 的效果取决于其掌握的上下文。在源头预先过滤事件虽然节省了成本，但却牺牲了检测覆盖率和关联准确度。在当前规模下，成本可以忽略不计，而广泛的覆盖率则是物超所值的。 ## 前置条件 - 已配置 Organizations 的 AWS 账号（包含 management 和成员账号） - AWS CLI v2，Python 3.12 - 每个账号在初始设置时需要管理员访问权限 完整的分步设置指南请参阅 `console-walkthrough.md`。

标签：AMSI绕过, AWS, DPI, GPT, 威胁检测, 安全架构, 漏洞利用检测, 漏洞探索, 漏洞管理, 速率限制, 配置合规