drdre4664/AWS-cloud-threat-detection

# AWS 云威胁检测 ## 概述 在 AWS 上部署云原生安全监控栈的基础设施即代码。 利用 CloudTrail、CloudWatch 和 SNS 告警，自动检测可疑活动，包括未经授权的 API 调用、IAM 变更、root 账户 使用以及安全组修改。 ## 架构 ``` AWS Account Activity │ ▼ CloudTrail ──► S3 Bucket (encrypted log storage) │ ▼ CloudWatch Logs ──► Metric Filters ──► Alarms ──► SNS ──► Email Alert ``` ## 检测到的威胁场景 | 场景 | 严重程度 | 检测方法 | |----------|----------|-----------------| | root 账户登录 | 严重 | 基于 CloudTrail 的 CloudWatch 指标过滤器 | | IAM 策略变更 | 高 | 基于 CloudTrail 的 CloudWatch 指标过滤器 | | 安全组修改 | 高 | 基于 CloudTrail 的 CloudWatch 指标过滤器 | | 未经授权的 API 调用 | 中 | 基于 CloudTrail 的 CloudWatch 指标过滤器 | | 禁用用户 MFA | 高 | 基于 CloudTrail 的 CloudWatch 指标过滤器 | | S3 存储桶策略变更 | 高 | 基于 CloudTrail 的 CloudWatch 指标过滤器 | ## 仓库结构 - `terraform/` — 用于部署完整监控栈的 IaC - `alerts/` — CloudWatch 告警示例 payload - `docs/` — 威胁检测方法学与操作手册 ## 展示的技能 - 云安全架构 (AWS) - 基础设施即代码 - 威胁检测工程 - CloudTrail 日志分析 - CloudWatch 告警与监控 - 安全事件关联 ## 前置条件 - 已配置 AWS CLI - 已安装 Terraform - 具有相应权限的 AWS 账户 ## 部署方式 ``` cd terraform terraform init terraform plan terraform apply ``` ## 销毁方式 ``` cd terraform terraform destroy ``` ## 经验总结 ### CloudTrail 与 CloudWatch —— 截然不同的两项职责 ### 过滤器模式决定一切 metric filter 模式决定了具体能检测到什么内容。在使用 `CreateUser` 和 `DeleteUser` 进行测试时，IAM 告警并未触发——因为这些事件未包含在过滤器模式中。该过滤器仅监控策略变更（`CreatePolicy`、`AttachRolePolicy`、`PutUserPolicy` 等）。这是一个极其重要的教训：如果你的过滤器模式未覆盖该事件，无论发生什么，告警都不会触发。务必验证你的模式是否与实际的 CloudTrail 事件名称匹配。 ### CloudTrail 到 CloudWatch 的传输延迟 事件并不会从 CloudTrail 瞬间传输至 CloudWatch。由于 CloudTrail 是批量投递日志，因此会存在 5 到 15 分钟的延迟。在真实的 SOC 环境中，这是预期之内且可接受的——告警会在事件发生后的几分钟内触发，而非几秒内。若要实现真正的实时检测，AWS GuardDuty 处理 CloudTrail 事件的速度快于手动的 CloudWatch pipeline。 ### 触发并验证全部 4 个告警 成功触发并接收到了全部 4 条检测规则的 SNS 邮件通知： - **root 账户使用** —— 以 root 账户登录 AWS 控制台 - **IAM 策略变更** —— 执行了 `aws iam create-policy` 和 `aws iam delete-policy` - **安全组变更** —— 执行了 `aws ec2 create-security-group` 和 `aws ec2 delete-security-group` - **未经授权的 API 调用** —— 对不存在的 role 执行了 6 次 `aws sts assume-role`，引发 `AccessDenied` 错误 ### 阈值设计至关重要 root、IAM 和安全组告警在阈值为 1 时触发——零容忍，一次事件即足够。未经授权的 API 调用告警在阈值为 5 时触发——因为少数几次拒绝调用属于正常的噪音，但 5 分钟内出现 5 次则表明存在主动探测。阈值校准是由分析师根据各类事件的信噪比做出的决策。 ### 控制台验证 —— 可视化确认 Terraform 构建的资源 使用 Terraform 完成部署后，通过 AWS 控制台逐一验证了每个资源： - **CloudTrail → Trails** —— 确认 `cloud-threat-detection-trail` 处于活跃状态，已启用多区域，已连接 S3 存储桶，并且已关联 CloudWatch 日志组 - **CloudWatch → Log groups** —— 确认 `/aws/cloudtrail/cloud-threat-detection` 日志组下拥有 4 个活跃的日志流，正在实时接收事件 - **CloudWatch → Log groups → Metric filters 标签页** —— 直接在控制台中查看了全部 4 个过滤器模式，确认了与 Terraform 部署的 JSON 字段模式完全一致 - **CloudWatch → Alarms** —— 实时监测了全部 4 个告警，观察到每次测试触发后，状态从“数据不足”转变为“告警中” 这是一项关键实践——Terraform 告诉你它*意图*部署什么，而控制台则确认了实际存在且正在运行的内容。两者结合能让你充分确保检测栈处于正常运行状态。 ### Terraform 使其可重复且可审计 整个检测栈——CloudTrail trail、开启加密及阻止公共访问的 S3 存储桶、CloudWatch 日志组、用于日志投递的 IAM role、4 个 metric filter、4 个告警、SNS topic 以及邮件订阅——全都定义在一个 Terraform 文件中。一条 `terraform apply` 即可部署所有内容。一条 `terraform destroy` 便能将其彻底清除。每一项配置决策都经过了版本控制且可审计，这正是 CIS AWS Foundations Benchmark 等合规框架所要求的。 ### CIS Benchmark 对齐 实现的 4 条检测规则与 CIS AWS Foundations Benchmark 的控制项对齐： - root 使用 → CIS 3.3 - IAM 变更 → CIS 3.4 - 安全组变更 → CIS 3.10 - 未经授权的 API 调用 → CIS 3.1 声称你的控制项与 CIS 对齐，意味着你正在实施业界公认的安全标准，而不是在自行编造规则。

标签：AMSI绕过, AWS, DPI, ECS, Terraform, 威胁检测