PeteAndrews1289/ai-cloud-threat-detection-platform

# AWS CloudTrail → Splunk 检测实验室 [](https://github.com/PeteAndrews1289/ai-cloud-threat-detection-platform/actions/workflows/validate.yml) 一个已完成并退役的实验室，它通过 S3、SNS 和 SQS 将 AWS CloudTrail 管理事件路由到 Splunk 中，用于调查和初步检测规则开发。  ## 该实验室所展示的内容 | 证据 | 限定结果 | | --- | ---: | | 在 Splunk 中观察到的 CloudTrail 事件 | 647 | | 实验室期间展示的 Splunk SQS 轮询间隔 | 600 秒 | | 已记录的 SPL 初始搜索规则 | 6 | | 已实现的数据路径 | CloudTrail → S3 → SNS → SQS → Splunk | | AI/LLM 组件 | 未实现 | | 基础设施即代码 | 未实现 | 这些数字仅描述了一次实验室观察结果，并不代表规模、延迟或生产就绪的基准。请参阅[证据与局限性](docs/evidence-and-limitations.md)。 ## 架构 ``` flowchart LR Activity[AWS management activity] --> CloudTrail[CloudTrail] CloudTrail --> S3[S3 log bucket] S3 --> SNS[SNS notification] SNS --> SQS[SQS queue and DLQ] SQS --> SplunkTA[Splunk Add-on for AWS] SplunkTA --> Splunk[Splunk Enterprise] Splunk --> Detections[Starter SPL searches] Detections --> Analyst[Analyst triage] ``` S3 提供了持久的日志存储；SNS 和 SQS 解耦了对象创建与收集过程；Splunk Add-on for AWS 轮询 SQS 并检索引用的 CloudTrail 对象。由于观察到的轮询间隔为 600 秒，这应被描述为定期摄取——而非实时检测。 ## 检测覆盖范围 该仓库包含针对以下内容的初始搜索规则： 1. 失败的 AWS API 调用； 2. IAM 权限变更； 3. root 账户使用情况； 4. 侦察式 API 活动； 5. 安全组变更；以及 6. S3 策略或 ACL 变更。 在成为生产告警之前，每个搜索规则仍然需要特定于环境的 index、调度、阈值、抑制策略和验证 fixture。查询语句和初步分诊指南位于 [detections/detection-queries.md](detections/detection-queries.md)。 ## 工程决策与经验教训 - **解耦交付：** SQS 在 AWS 存储和 Splunk 收集之间缓冲通知，同时死信队列（dead-letter queue）提供了故障转移目标。 - **先求证后自动化：** 确认可搜索的 CloudTrail 数据是进行告警或 AI 辅助分诊的前提。 - **最小权限至关重要：** 早期的手动设置使用了比生产收集器应具有的更宽泛的 IAM 访问权限。该配置已被弃用，并作为局限性记录，而非推荐模式。 - **控制台配置难以复现：** 该实验室是手动配置的。可靠的下一个版本应使用 Terraform 和策略测试。 - **检测名称不等于验证：** 在针对带有预期匹配项和误报案例的脱敏 fixture 进行验证之前，这六个搜索规则仅为假设。 ## 仓库结构图 ``` architecture/ Data-flow notes detections/ Six starter SPL searches and triage guidance docs/ Sanitized evidence summary and limitations ingestion/ Splunk collection notes setup/ High-level AWS configuration notes .github/workflows/validate.yml Documentation and evidence-hygiene checks ``` ## 范围边界 本仓库**不**声称具备： - 已实现的 AI 或 LLM 分诊层； - 自动化响应或遏制功能； - 生产级的检测延迟； - 可复现的基础设施即代码； - 经过验证的检测精确率或召回率；或 - 最小权限参考部署。 这些边界是刻意为之的：当前的产出物是一项已完成的 CloudTrail 到 Splunk 摄取与检测学习练习的证据。 ## 最佳的下一步迭代 与其创建另一个宽泛的概念性仓库，最有力的后续行动是将此遥测路径整合到现有的 SOAR 案例研究中： 1. 使用 Terraform 和受限的 IAM 重建 AWS 路径； 2. 添加脱敏的 CloudTrail fixture； 3. 将检测表达为代码，包含 ATT&CK 映射、阈值、预期结果、误报和分诊步骤； 4. 在 CI 中测试检测；以及 5. 从经过验证的告警驱动一个经过身份验证、可审计的分析师批准工作流。 ## 负责任的使用 在公开示例中使用合成或刻意脱敏的遥测数据。切勿提交凭证、访问密钥标识符、账户 ID、公共 IP、客户数据或原始 CloudTrail 导出文件。验证工作流会检查当前代码树以发现几种常见的标识符模式，但这仅是一种防护措施——不能替代人工审查。

标签：AWS CloudTrail, 安全运营, 扫描框架