eds-zx/aws-s3-auto-remediation

# Cloud Guardrails：自动化 S3 配置错误检测与修复 检测 S3 bucket 何时变为公开状态，并通常在 30-90 秒内无需人工干预地自动对其进行修复。 公开的 S3 bucket 是导致真实云数据泄露的最常见原因之一，通常源于配置错误而非复杂的攻击。本项目构建了一个小型的、可运行的检测与修复机制版本，这正是 CSPM 工具（Wiz、Security Hub、Prisma Cloud）在生产环境中所使用的机制。 ## 功能说明 1. S3 bucket 被设为公开（模拟配置错误或攻击者的操作） 2. CloudTrail 记录确切的 API 调用，包括操作者和时间 3. EventBridge 匹配该特定事件类型 4. Lambda 函数自动将 bucket 恢复为私有状态 5. 系统会忽略其自身的修复操作，因此不会在循环中触发自身 ## 架构 ``` Public bucket policy applied | v CloudTrail (records the change, with full identity attribution) | v EventBridge rule (matches PutBucketPolicy / PutBucketAcl / PutBucketPublicAccessBlock, excludes events caused by the remediation Lambda's own role) | v Lambda function (removes public policy, re-enables public access block) | v Bucket is private again, typically within 30-90 seconds ``` ## 实际运行效果 **自动记录的攻击行为。** 附加了公开的 bucket 策略，CloudTrail 捕获了确切的策略、执行该操作的身份以及时间戳。  **正确触发的自动修复。** 随着完整 pipeline 的接通，破坏 bucket 会在几秒钟内触发修复，且该修复不会重复触发自身。  **实际部署的函数。** 不是代码片段，而是运行在 AWS 中的真实代码。  涵盖每个构建阶段的更多截图位于 `screenshots/` 中。 ## 使用的工具 - **Terraform** 用于基础设施即代码（S3、CloudTrail、EventBridge、IAM） - **AWS Lambda (Python 3.12)** 用于修复逻辑 - **AWS CLI** 用于在每个阶段进行手动测试和验证 - **boto3** 用于在 Lambda 函数内部进行 AWS 调用 ## 诚实的构建说明 这是我第一个亲自动手的云安全项目。我之前的 AWS 和 Python 经验有限，因此我借助了 AI 辅助来编写 Terraform 和 Python 代码。我自己所做的事：在应用之前理解了每一个资源和每一行代码，在连接之前单独测试了每个组件，并在构建过程中诊断和修复了两个真实的 bug（见下文）。这个项目的重点不是从零开始编写代码。而是确切地理解在云环境中检测和自动响应是如何工作的，到了足以解释和捍卫每一个决策的程度。 ## 我遇到并修复的两个真实问题 **静默的 EventBridge 投递失败。** EventBridge 规则匹配正确，但没有任何内容到达其 CloudWatch Logs 目标，且任何地方都没有错误提示。原因：写入 CloudWatch Logs 的 EventBridge 目标需要一个显式的资源策略，以授予 `events.amazonaws.com` 对该特定日志组的权限。匹配规则与拥有向目标投递的权限是两码事，当缺少后者时，AWS 并不会醒目地报错。添加日志资源策略后修复了此问题。 **修复反馈循环。** 一旦接通系统并针对真实的配置错误进行测试，Lambda 就能正常工作，但它会每几秒触发一次，而不是只触发一次。原因：Lambda 自身的修复操作本身就是 API 调用，这些调用会被 CloudTrail 记录，进而匹配触发 Lambda 的同一个 EventBridge 规则。它正在对自己的修复操作做出反应。通过向 EventBridge 规则添加身份过滤器修复了此问题，排除了任何 CloudTrail 的 `userIdentity.arn` 与 Lambda 自身 IAM role 匹配的事件。 ## IAM 设计 Lambda 的执行 role 被严格限制为仅对匹配此项目命名前缀的资源执行三个 S3 操作（`PutBucketPublicAccessBlock`、`GetBucketPolicy`、`DeleteBucketPolicy`），外加写入其自身执行日志所需的最低 CloudWatch Logs 权限。没有广泛的 S3 访问权限，也没有对账户中任何其他 bucket 的访问权限。 ## 下一步计划 - 在 EventBridge 路径旁添加 AWS Config 规则，以将持续合规性检查与这种事件驱动方法进行比较 - 在每次修复操作时发送 SNS 通知 - 使用 GuardDuty 发现的结果，为开放的 SSH 安全组建立第二条检测和修复路径 - 使用跨账户 EventBridge 提供多账户支持 ## 仓库内容 - `terraform/` – 所有基础设施定义 - `lambda/remediate_s3/handler.py` – 修复函数 - `lambda/remediate_s3/test_local.py` – 部署到 AWS 之前使用的本地测试脚本 - `screenshots/` – 来自实际运行的 CloudTrail 事件、EventBridge 配置和 Lambda 执行日志

标签：AWS, Cloud Security Posture Management, DPI, S3存储桶, 云计算, 自动修复, 规则引擎, 逆向工具