uzobola/aws-incident-response-automation

# AWS 事件响应自动化 这是七层云安全计划中的第 5 层（响应层）。检测层回答“出问题时我们如何知晓”，而这一层回答的是“当问题发生时，系统会自动采取什么行动”。 ## 目的 只有检测而没有响应会留下缺口：警报触发后，必须由人来注意到它、进行分类并采取行动。对于一组已定义的高可信度调查结果，本服务通过自动执行经过审查且可审计的响应工作流来填补这一缺口，并在执行任何不可逆或高影响范围的操作之前设置人工审批环节。 ## 输入 使用该计划检测和态势层中的调查结果，而不是重新发现它们： - AWS Security Hub（汇总调查结果，包括 GuardDuty 和 Config） - IAM 跨账号检测管道（第 4 层），用于 AssumeRole 异常 - NHI 治理引擎（前沿层），用于非人类身份风险 ## 架构 ``` Security Hub finding / EventBridge rule match → EventBridge rule (filters by finding type and severity) → Step Functions state machine (the response workflow) ├─ Triage: enrich the finding (principal, action, blast radius, owner tag) ├─ Decision: auto-contain low-blast-radius, or pause for approval ├─ Approval gate: SNS to responder; workflow waits for callback ├─ Containment: scoped, reversible action (see below) ├─ Evidence: write a structured record to the evidence store └─ Notify: post the outcome to the responder channel ``` 状态和审计跟踪保存在 Step Functions 执行历史记录以及 DynamoDB 响应日志中。没有任何操作会在无声无息中发生。 ## 遏制措施（优先使用限定范围且可逆的操作） 每项操作均遵循最小权限原则，并记录在案，且尽可能可逆： - 禁用（而非删除）暴露的 IAM access key - 为被标记的 role 附加 deny-all permissions boundary，等待审查 - 通过将资源移至隔离 security group 来对其进行隔离 - 撤销受损 principal 的活动会话 不可逆或高影响范围的操作始终需要经过审批环节。 ## 审批环节 状态机使用 Step Functions 回调模式（`waitForTaskToken`）。高影响操作会暂停并通知响应人员，由其批准或拒绝，工作流在回调时继续执行。自动化确保了安全操作的执行速度，同时让高风险操作受人工管控。 ## 控制措施映射 (NIST 800-53) | 控制措施 | 本方案如何满足该要求 | |---|---| | IR-4 事件处理 | 自动化、可重复的处理工作流 | | IR-5 事件监控 | DynamoDB 响应日志和 Step Functions 历史记录 | | IR-6 事件报告 | 结构化通知和证据记录 | | AC-2 / AC-6 | 遏制措施对受损的 principals 强制执行最小权限 | | AU-6 | 响应操作和审批均被记录以供审计 | ## 设计决策 - **选择 Step Functions 而非单一 Lambda。** 工作流是多步骤的，需要人工介入暂停，并且得益于可见、可审计的执行历史记录。 - **选择审批环节而非完全自动化。** 可能导致合法用户被锁定或破坏生产环境的遏制措施必须受人工管控。速度仅保留给低影响范围、可逆的操作。 - **优先采用可逆的遏制措施。** 在删除前先禁用，在终止前先隔离，确保误报是可恢复的。 - **默认收集证据。** 每次响应都会写入审计记录，因此系统能够经受住与其所执行的控制措施同样严格的审查。 ## 连接方式 使用第 4 层（检测）和前沿层（NHI 引擎）的调查结果，并写入可供第 3 层（GRC）和第 7 层执行仪表板使用的证据。响应并不是一个孤岛。它是整个计划体系中的执行臂。

标签：AWS, DPI, Serverless, 安全运营, 扫描框架, 自动化响应