Luekrit/Cloud-Security-Automation

# 云安全自动化与修复 **AWS | Terraform | IAM | EventBridge | Lambda | CloudTrail | SNS | Python** 一个云安全工程项目，使用 Terraform 和 AWS 原生服务演示**事件驱动的检测、告警以及感知治理的修复决策逻辑**。 该项目模拟了现代云环境如何检测高风险的 IAM 权限提升活动、通知安全团队、评估已批准的例外情况，并通过**优先执行空运行（dry-run）**的方法支持安全的修复。 # 项目概述 本项目实现了一种**云安全自动化架构**，可以近乎实时地检测高风险的 IAM 策略附加活动。 系统无需依赖手动的事件响应，而是： - 使用 CloudTrail 监控 AWS API 活动 - 使用 EventBridge 检测安全相关事件 - 使用 Lambda 触发响应逻辑 - 使用 SNS 电子邮件发送安全告警 - 使用 IAM 标签评估感知治理的例外情况 - 以受控的方式支持自动化修复 目前的实现侧重于针对 IAM 用户的 **AdministratorAccess 附加检测**，并在启用真正的强制执行之前通过**空运行测试**验证控制措施。 # 架构图 ``` graph TD classDef trigger fill:#ed2c13,stroke:#333,stroke-width:2px; classDef logic fill:#326ee6,stroke:#333,stroke-width:2px; classDef action fill:#d4772a,stroke:#333,stroke-width:2px; classDef final fill:#7330e6,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5; subgraph Detection_Layer [1. Detection] A[IAM / Security Events
AttachUserPolicy]:::trigger --> B[AWS CloudTrail
Records API Activity] end subgraph Routing_Layer [2. Filtering] B --> C[Amazon EventBridge
Matches Security Event Patterns]:::logic end subgraph Logic_Layer [3. Logic Engine] C --> D[AWS Lambda
remediate.py]:::logic D --> D1[Parse Event Metadata] D --> D2[Evaluate Risk] D --> D3[Check Governance Exceptions] D --> D4[Decide Remediate or Skip] end subgraph Response_Layer [4. Response] D4 --> E[SNS Email Alert
Structured Security Notification]:::action D4 --> F[CloudWatch Logs
Audit Trail and Debugging]:::action D4 --> G[IAM Remediation
Detach Policy in Enforcement Mode]:::action end subgraph Outcome [5. Desired State] G --> H[Least Privilege Preserved]:::final E --> H F --> H end ``` # 核心安全能力 ## 事件驱动的威胁检测 系统当前监控与 IAM 相关的 API 活动，主要验证的用例集中在： - AttachUserPolicy EventBridge 实时过滤匹配的 CloudTrail 事件，并调用 Lambda 响应工作流。 ## 感知治理的响应逻辑 Lambda 响应引擎： - 解析传入的 CloudTrail 事件元数据 - 识别目标 IAM 用户和高风险策略附加 - 评估修复是否在范围内 - 检查已批准的例外标签，例如： - `SecurityApproved=true` - 决定是进行修复还是跳过 这通过将技术检测与**感知治理的例外处理**相结合，创建了一个更切合实际的安全控制机制。 ## SNS 告警 当检测到高风险 IAM 事件时，系统会发送结构化的 SNS 电子邮件告警，其中包含： - 事件名称 - 操作者 ARN - 目标用户 - 策略 ARN - 空运行状态 - 修复决策 - 批准或跳过的原因 这提高了在启用全面强制执行之前的操作可见性。 ## 空运行安全模式 该控制目前在**空运行模式**下运行。 这意味着： - 仍会检测高风险活动 - 仍会发送告警 - 仍会记录决策 - 但暂不执行实际的 IAM 剥离操作 这允许在启用实时修复之前进行安全验证。 # 安全日志与可见性 所有修复操作都会记录到： - **Amazon CloudWatch Logs** 这提供了： - 安全操作的审计跟踪 - 调试能力 - 操作可见性 - 用于验证和测试的证据 # 攻击模拟 为了验证系统，测试了以下场景： 1. 授予 IAM 用户 **AdministratorAccess** 策略 2. CloudTrail 记录 IAM 策略更改 3. EventBridge 检测到匹配的事件 4. Lambda 评估该事件 5. SNS 发送结构化的安全告警 6. Lambda 将执行以下操作之一： - 在空运行模式下批准修复，或者 - 如果存在已批准的例外标签，则跳过修复 # Terraform 基础设施 基础设施使用**具有安全最佳实践的 Terraform** 进行部署。 ## 基础设施设计 ``` graph TD %% Define Styles classDef tool fill:#742fba,stroke:#fff,stroke-width:2px,color:#fff; classDef iam fill:#f6a800,stroke:#333,stroke-width:2px; classDef aws fill:#232f3e,stroke:#fff,stroke-width:2px,color:#fff; classDef storage fill:#3b48cc,stroke:#fff,stroke-width:2px,color:#fff; A[Terraform CLI
Local Machine / CI/CD]:::tool -->|sts:AssumeRole| B[TerraformExecutionRole
IAM Role]:::iam B -->|Provision Resources| C[AWS Infrastructure
VPC, Lambda, EventBridge]:::aws subgraph Remote_Backend [Remote State Management] D[S3 Bucket
Remote State Storage]:::storage E[DynamoDB Table
State Locking]:::storage D ---|Stores| F(terraform.tfstate):::storage E ---|Prevents| G(Concurrent Runs):::storage end C -.->|Update State| D A <-->|Check/Update Lock| E ``` ## 关键基础设施特性 - 模块化的 Terraform 架构 - 使用 **AssumeRole 进行安全访问（无长期凭证）** - 在 **S3** 中进行远程状态存储 - 使用 **DynamoDB** 进行状态锁定 - 用于 IAM、Lambda、EventBridge、SNS、CloudTrail 和 S3 的可重用模块 - 在 us-east-1 中为 IAM 事件处理设置单独的全局路径 - 具有作用域 IAM 权限的强化 Lambda 执行角色 - 限制为仅匹配 `iam-test-*` 的测试 IAM 用户的受控修复范围 # 阶段 3.5：基础设施与 Lambda 角色强化 在启用实时修复之前，我完成了一次强化，以改善项目的 Terraform 状态管理和 Lambda 执行角色权限。 此阶段侧重于在从空运行测试过渡到受控强制执行之前降低操作风险。 ## 远程状态与锁定强化 Terraform 状态已使用以下方式移动到远程后端： * **Amazon S3** 用于远程状态存储 * **Amazon DynamoDB** 用于状态锁定 * 用于引导和环境状态的单独后端路径 - 特定于环境的状态分离，以便更安全地管理基础设施 这通过防止本地状态漂移并降低并发 Terraform 运行修改同一基础设施的风险，提高了可靠性。 ## Lambda 执行角色强化 Lambda 修复策略也进行了收紧，以减少自动化修复的爆炸半径。 原始策略允许跨所有资源进行 IAM 读取和剥离操作。这对于早期测试来说是可以接受的，但对于实际的安全自动化工作流来说范围太广。 更新后的 Lambda 执行角色现在限制了权限，因此该功能只能： * 仅为匹配 `iam-test-user` 的受控测试用户读取 IAM 用户详细信息和标签 * 仅剥离 AWS 管理的 `AdministratorAccess` 策略 - 仅对匹配 `iam-test-user` 命名模式的测试 IAM 用户应用修复 - 仅向项目 SNS 主题发布告警 这在保持工作流可用于受控验证的同时，改善了最小权限态势。 ## 阶段 3.5 验证 在应用 Terraform 更改后，工作流在空运行模式下进行了重新测试。 验证确认： * Terraform 成功应用了 IAM 策略更新，状态为 `0 added, 1 changed, 0 destroyed` * SNS 告警继续正常工作 * CloudWatch 日志确认了 Lambda 的执行 * 测试 A：没有例外标签的用户在空运行模式下被批准进行修复 * 测试 B：具有 `SecurityApproved=true` 的用户被检测到，但被跳过未进行修复 * `DRY_RUN=true` 保持启用状态，因此没有发生实时的策略剥离 这确认了在 Lambda 角色受到限制后，自动化仍能检测高风险 IAM 活动、发送告警、评估例外标签并做出修复决策。 # 验证结果 此阶段在**空运行模式**下验证了项目的端到端检测、告警以及感知治理的例外处理。 ## 测试场景 A — 未批准的 AdministratorAccess 附加 **目标：** 确认在没有适用例外情况时，该控制能够检测到高风险的 IAM 策略附加、发送告警并批准修复。 **测试操作** - 将 `AdministratorAccess` 附加到 `iam-test-user` **预期行为** - CloudTrail 记录 IAM API 事件 - EventBridge 匹配该事件 - Lambda 在 `us-east-1` 中被调用 - 发送 SNS 电子邮件告警 - 批准修复 - 因为设置了 `DRY_RUN=true`，所以不会发生实际的剥离 **观察结果** - Lambda 日志显示： - `Security detection triggered` - `Parsed event` - `SNS alert processed` - `Dry run enabled - remediation skipped` - SNS 电子邮件告警显示： - `approved_for_remediation: true` - `decision_reason: "Approved for remediation"` **证据** **图 1. 测试 A — 显示检测、SNS 告警和空运行修复批准的 CloudWatch 日志**  **图 2. 测试 A — 显示已批准修复的 SNS 电子邮件告警**  **结果** - 检测有效 - 告警有效 - 修复决策逻辑有效 - 空运行安全控制有效 ## 测试场景 B — 使用 IAM 标签的已批准例外 **目标：** 确认控制措施仍能检测到高风险 IAM 事件并发出告警，但当目标用户具有已批准的例外标签时跳过修复。 **测试操作** - 添加 IAM 用户标签： - `SecurityApproved = true` - 将 `AdministratorAccess` 附加到 `iam-test-user` **预期行为** - CloudTrail 记录 IAM API 事件 - EventBridge 匹配该事件 - Lambda 在 `us-east-1` 中被调用 - 发送 SNS 电子邮件告警 - **不**批准修复，因为目标用户具有已批准的例外标签 - Lambda 清楚地记录跳过原因 **观察结果** - Lambda 日志显示： - `Security detection triggered` - `Parsed event` - `SNS alert processed` - `No remediation performed` - SNS 电子邮件告警显示： - `approved_for_remediation: false` - `decision_reason: "User has approved exception tag: SecurityApproved=true"` **证据** **图 3. 测试 B — 显示告警和基于例外的修复跳过的 CloudWatch 日志**  **图 4. 测试 B — 显示已批准例外决策的 SNS 电子邮件告警**  **结果** - 检测有效 - 告警有效 - 感知治理的例外处理有效 - 已批准的例外被正确跳过 ## 验证总结 这些测试确认了该控制能够： - 检测高风险的 IAM 策略附加事件 - 通过 SNS 电子邮件向安全团队发出告警 - 支持使用空运行模式进行安全推广 - 使用 IAM 用户标签应用感知治理的例外处理 此阶段展示了一个更切合实际的安全工程工作流： **CloudTrail → EventBridge → Lambda → SNS 告警 → 空运行修复决策** # 展示的安全原则 本项目应用了核心的云安全工程实践： - **最小权限访问控制** - **事件驱动的安全自动化** - **基础设施即代码安全** - **自动化的事件响应** - **云身份保护** # 使用的技术 - Terraform - AWS IAM - AWS CloudTrail - Amazon EventBridge - AWS Lambda - Amazon CloudWatch Logs - Amazon SNS - Python # 项目存在的原因 本项目灵感来源于早期开发中获得的安全教训，当时不当的凭证处理凸显了云配置错误是多么容易引入风险。 本项目的目标是演示**自动化和安全工程实践如何防止这些风险在真实环境中持续存在**。 # 未来改进 - 增加对额外 IAM 滥用场景的检测 - 集成通过 **SNS / Slack 通知**进行的告警 - 扩展针对更广泛安全事件的修复逻辑 - 与 **AWS Security Hub 或 SIEM 工具**集成 - 增加对异常 API 行为的异常检测

标签：AWS, DPI, ECS, IAM权限提升检测, Python, Terraform, 事件驱动架构, 无后门, 自动化响应, 逆向工具