Waliur003/automated-incident-response-active-defense
GitHub: Waliur003/automated-incident-response-active-defense
基于 AWS Serverless 架构的自动化事件响应系统，通过威胁检测、事件路由与有状态编排实现机器速度的边缘防火墙自动封禁与清理闭环。
Stars: 0 | Forks: 0
# 云安全工程项目 06：自动化事件响应（主动防御与安全编排）
## 概述
我在 AWS 上架构并部署了一个自动化威胁缓解与主动防御 pipeline，使用了事件驱动的 serverless 基础组件和边缘网络防火墙。该项目建立了一个自动化安全修复闭环，能够检测基础设施威胁，在解耦的事件层中安全地路由遥测数据，并在 10 秒内修改边缘防火墙以阻断攻击者。通过将有状态的、程序化的修复 playbook 替代被动的合规通知，该架构大幅缩短了平均修复时间 (MTTR)，并保护内部云资产免受主动的自动化漏洞利用。
## 问题描述
标准的云安全架构依赖于异步告警配置，由于系统性的监控漏洞，这会造成严重的暴露窗口：
* **不可接受的平均修复时间 (MTTR)：** 传统的告警系统在攻击发生时会发送电子邮件或聊天通知，这需要人工干预，通常需要数小时才能解决，而数据泄露却在悄然进行。
* **告警工作流中缺乏状态管理：** 标准的事件触发是无状态的，这意味着单个脚本无法处理复杂的逻辑条件、跟踪主动封禁窗口，或在威胁过去后自动恢复网络基线状态。
* **手动防火墙规则膨胀：** 安全运营团队在事件发生期间经常手动更新封禁列表，导致过期的规则被无限期保留，这 cluttered 了配置文件并降低了防火墙的效率。
## 解决方案
* **机器速度的边缘封禁：** 配置 Amazon GuardDuty 持续分析基础设施日志，在发现暴力破解或命令与控制通信等高危威胁时，即时提取攻击者源 IP 特征。
* **解耦的安全遥测路由：** 在 Amazon EventBridge 内部对原始安全发现进行模式匹配，过滤掉冗余噪音，并立即将关键目标指标路由到修复集群。
* **有状态的编排 Playbook：** 构建了一个 AWS Step Functions 状态机，用于评估威胁画像，根据严重程度进行分支处理，执行 serverless worker 拦截流量，并管理精确的等待状态。
* **自动化的防火墙清理动作：** 使用 AWS Lambda 实现了自动冷却逻辑序列，在预定义的冷却窗口后，自动从 AWS WAF IP Set 封禁列表中清除过期条目，保持干净的网络配置。
## 技术栈
* **威胁情报引擎：** Amazon GuardDuty
* **事件代理层：** Amazon EventBridge (高级自定义模式匹配)
* **Playbook 编排器：** AWS Step Functions (Amazon States Language - ASL)
* **边缘保护层：** AWS WAF v2 (Web Application Firewall)
* **修复计算集群：** AWS Lambda (Python 3.12 运行时)
* **基础设施即代码：** Terraform (v1.5+ 声明式配置语法)
## 架构图
## 项目流程
### 边缘防火墙基线初始化 (AWS WAF)
我通过创建一个名为 `ThreatBlockList` 的区域级 AWS WAF IP Set 建立了网络防御边界。该资源充当针对恶意端点的动态封禁列表。接着，我构建了一个针对区域计算资源的名为 `IngressShieldWebACL` 的 AWS WAF Web ACL，并附加了一条名为 `BlockMaliciousHackers` 的自定义匹配规则。此配置指示 WAF 引擎执行实时数据包过滤，立即丢弃来自封禁列表中任何源 IP 的所有传入 7 层流量。
### 智能云传感器激活 (Amazon GuardDuty)
我在整个账户范围内启用了 Amazon GuardDuty，以建立持续的账户监控。GuardDuty 充当自动化的机器学习传感器，检查 VPC Flow Logs、CloudTrail 管理事件日志和 DNS 查询。它能检测异常情况，例如受感染的 compute 实例与已知的恶意命令与控制服务器通信，或执行自动化网络扫描。
### Serverless 封禁 Worker 工程 (AWS Lambda)
我编写了两个专门的 Python Lambda 修复函数，以编程方式与 WAF 层进行交互：
* **BlockMaliciousIPFunction：** 从传入事件数据中提取远程 IP 地址，获取活跃的 WAF lock token，并将目标地址以严格的 /32 CIDR 掩码追加到封禁列表中。
* **UnblockMaliciousIPFunction：** 作为自动清理实用程序运行，一旦封禁窗口关闭，即从防火墙封禁列表中移除指定的 IP。
我使用自定义的 IAM 内联策略保护了两个执行配置文件，将其权限专门限制为针对特定封禁列表资源 ID 的 `wafv2:GetIPSet` 和 `wafv2:UpdateIPSet` 操作。
### 有状态的威胁修复 Playbook 编排 (AWS Step Functions)
我在 AWS Step Functions 中使用 Amazon States Language (ASL) 设计了一个有状态的工作流，以管理每个安全事件的生命周期。该 playbook 实现了以下步骤逻辑序列：
* **FilterHighSeverity：** 一个 Choice 状态评估传入发现的数值严重性分数。低于 7.0 的警报绕过修复以避免系统噪音，而 7.0 及以上的警报进入封禁处理。
* **IsolateAttackerIP：** 一个 Task 状态调用阻断 Lambda 函数，将远程 IP 地址直接传递给 WAF 引擎。
* **CoolingOffPeriod：** 一个 Wait 状态暂停工作流执行一段可配置的持续时间（例如 3600 秒），以在事件窗口期间保持阻断状态。
* **RestoreFirewallBaseline：** 最终的 Task 状态调用解封 Lambda 函数，安全地从防火墙封禁列表中清除该地址。
### 解耦的实时触发器同步 (Amazon EventBridge)
为了完成自动化闭环，我在默认事件总线上部署了一条名为 `RouteGuardDutyThreats` 的自定义 Amazon EventBridge 路由规则。我配置了高级 JSON 模式过滤器来拦截 GuardDuty 发现，并将它们直接绑定到 Step Functions 状态机 ARN。我修改了规则执行配置文件以自动生成专用的 IAM role，每当安全发现符合条件时，即授权 EventBridge 触发 playbook 执行。
## 基础设施即代码 架构
为了保证环境的精确可重复性，防止配置漂移，并消除手动控制台交互，完整的主动防御平台使用模块化的 Terraform 文件进行了代码化。
## 目录布局与模块化结构
```
automated-incident-response/
├── provider.tf # Configures AWS provider constraints and global resource tagging
├── variables.tf # Abstracted input fields for cooling times and regional options
├── waf.tf # Provisions the core Web ACL and empty IP block list infrastructure
├── lambda.tf # Compresses python scripts and deploys serverless functions with IAM permissions
├── step_functions.tf # Orchestrates the state machine playbook using declarative ASL definitions
├── eventbridge.tf # Enables the GuardDuty detector and establishes the rule pattern filter
└── outputs.tf # Exports the live Web ACL and Step Function orchestration ARNs
```
## 详细的文件级技术分解
### 系统提供者范围 (`provider.tf`)
初始化核心的 AWS infrastructure 插件要求，将版本约束目标定为 `~> 5.0`，并在自动化资源清单中嵌入默认的资源标签。
### 变量抽象 (`variables.tf`)
管理部署目标区域，并对事件冷却窗口进行参数化，使修复时间可调。
### 边缘安全层 (`waf.tf`)
以编程方式构建区域级的 `ThreatBlockList` IP set 和 `IngressShieldWebACL`，构建防火墙规则库，默认允许干净流量通过，同时阻断匹配目标列表的攻击向量。
### 计算 Worker (`lambda.tf`)
使用 archive provider 内联压缩 Boto3 Python 文件，构建 serverless 运行时，并创建仅限于最小权限操作的独立 IAM 权限策略。
### Playbook 工程 (`step_functions.tf`)
构建状态机工作流，加载 ASL JSON 执行路径，并为 Lambda worker 资源建立目标执行权限。
### 事件代理集成 (`eventbridge.tf`)
启动账户范围的 GuardDuty 跟踪接口，并部署高级 CloudWatch 事件规则结构，将威胁检测直接链接到 playbook。
## 验证与结果
### WAF 核心 IP Set 与全局规则库配置
**截图说明：** AWS WAF IP 地址集管理控制台界面。
**技术证明：** 确认 `ThreatBlockList` 资源已在美国东部（弗吉尼亚北部）以区域级别部署，映射到唯一的 GUID 资源 ID `7976e390-0a03-4475-8ee5-112c24d759b5`。这验证了 serverless 封禁脚本使用的程序化目标端点存在于账户架构中。
### 有状态事件 Playbook 结构验证
**截图说明：** AWS Step Functions 图形检查器画布和代码验证面板。
**技术证明：** 证明声明的 ASL JSON schema 编译成功，没有语法错误。结构预览验证了 choice 逻辑、Lambda 执行步骤、wait 定时器和清理功能映射为一个连贯的、未中断的工作流路径。
### 实时触发器事件模式关联
**截图说明：** Amazon EventBridge 目标配置仪表板。
**技术证明：** 证明 `RouteGuardDutyThreats` 规则绑定到默认事件总线，专门过滤 `aws.guardduty` 源流，并持有有效的 IAM 权限以在目标状态机资源上触发执行例程。
### 机器速度自动化摄入执行
**截图说明：** 在样本威胁生成周期后的 Step Functions 执行跟踪矩阵。
**技术证明：** 验证了 pipeline 成功消化了大量并发安全事件。状态跟踪列展示了成功的路由行为：低风险项目通过日志记录路径在几毫秒内以 `Succeeded` 状态完成，而高风险项目则按预期触发了阻断状态。
## 验证截图
### 1. AWS WAF IP Set 区域配置
此截图展示了 `ThreatBlockList` IP set 的 AWS WAF 管理控制台界面。它验证了该资源已在美国东部（弗吉尼亚北部）区域正确配置，具有区域范围和唯一的资源 GUID (`7976e390-0a03-4475-8ee5-112c24d759b5`)。这证明了基础阻断网格端点已上线，并准备好接收来自您的 serverless 封禁功能的程序化 API 更新。
### 2. 有状态的 Step Functions 事件响应 Playbook 工作流
此截图捕获了 `IncidentResponsePlaybook` 的 AWS Step Functions 工作流可视化检查器和 Amazon States Language (ASL) 代码面板。它验证了状态机编译成功，没有语法验证错误。可视化蓝图描绘了显式的威胁分流路由逻辑、serverless AWS Lambda 执行 worker、wait 定时器和防火墙自动清理状态。
### 3. Amazon EventBridge 目标路由与 IAM 映射
此截图展示了 `RouteGuardDutyThreats` 的 Amazon EventBridge 规则审查仪表板。它确认了该规则在默认事件总线上处于活动状态，利用自定义 JSON 模式拦截 Amazon GuardDuty 源流，并配置为自动生成专用的 IAM role，以便顺利、无障碍地触发目标 playbook。
### 4. 模拟威胁处理与执行矩阵
此截图捕获了 Step Functions 执行跟踪仪表板，展示了在自动化威胁模拟周期中产生的大量并发事件波。它演示了成功的机器速度 pipeline 执行：低严重性警报通过旁路日志记录轨道成功完成，而高严重性攻击则被直接推送到活跃的防火墙修复组件中。
## 未来改进
* **持久的威胁情报源：** 将开源信誉封禁列表（例如 Tor 出口节点目录和 Abuse.ch 指标）直接集成到 EventBridge 路由矩阵中，以预先阻断已知的恶意网络。
* **ChatOps 通信同步：** 在 Step Functions playbook 中添加 Amazon SNS 执行分支，以将丰富的 JSON 封禁更新发布到专用的 SecOps Slack 频道，为团队提供实时事件数据。
* **跨账户修复中心：** 使用跨账户 IAM 交叉代入 role 模式扩展事件路由器，允许集中的安全账户同时修改多个生产辐射账户中的防火墙。
## 备注
**核心总结：** 自动化事件响应项目将云安全生态系统从被动配置模型转变为自动化的主动防御环境。通过将实时的 GuardDuty 威胁情报直接链接到有状态的 Step Functions playbook 和 serverless Python worker，该系统能够在 10 秒内在 AWS WAF 网络边缘隔离高危攻击者。这种自动化显著降低了基础设施暴露窗口，消除了手动清理开销，并确保云资源以机器速度进行自我防御，无需人工干预。
### 2. 有状态的 Step Functions 事件响应 Playbook 工作流
此截图捕获了 `IncidentResponsePlaybook` 的 AWS Step Functions 工作流可视化检查器和 Amazon States Language (ASL) 代码面板。它验证了状态机编译成功，没有语法验证错误。可视化蓝图描绘了显式的威胁分流路由逻辑、serverless AWS Lambda 执行 worker、wait 定时器和防火墙自动清理状态。
### 3. Amazon EventBridge 目标路由与 IAM 映射
此截图展示了 `RouteGuardDutyThreats` 的 Amazon EventBridge 规则审查仪表板。它确认了该规则在默认事件总线上处于活动状态，利用自定义 JSON 模式拦截 Amazon GuardDuty 源流，并配置为自动生成专用的 IAM role，以便顺利、无障碍地触发目标 playbook。
### 4. 模拟威胁处理与执行矩阵
此截图捕获了 Step Functions 执行跟踪仪表板，展示了在自动化威胁模拟周期中产生的大量并发事件波。它演示了成功的机器速度 pipeline 执行：低严重性警报通过旁路日志记录轨道成功完成，而高严重性攻击则被直接推送到活跃的防火墙修复组件中。
## 未来改进
* **持久的威胁情报源：** 将开源信誉封禁列表（例如 Tor 出口节点目录和 Abuse.ch 指标）直接集成到 EventBridge 路由矩阵中，以预先阻断已知的恶意网络。
* **ChatOps 通信同步：** 在 Step Functions playbook 中添加 Amazon SNS 执行分支，以将丰富的 JSON 封禁更新发布到专用的 SecOps Slack 频道，为团队提供实时事件数据。
* **跨账户修复中心：** 使用跨账户 IAM 交叉代入 role 模式扩展事件路由器，允许集中的安全账户同时修改多个生产辐射账户中的防火墙。
## 备注
**核心总结：** 自动化事件响应项目将云安全生态系统从被动配置模型转变为自动化的主动防御环境。通过将实时的 GuardDuty 威胁情报直接链接到有状态的 Step Functions playbook 和 serverless Python worker，该系统能够在 10 秒内在 AWS WAF 网络边缘隔离高危攻击者。这种自动化显著降低了基础设施暴露窗口，消除了手动清理开销，并确保云资源以机器速度进行自我防御，无需人工干预。标签：AMSI绕过, AWS, DPI, IP 地址批量处理, 威胁检测, 自动化响应, 防火墙管理