dreighton90/Cloud-Security-Alerting-System-AWS-PostgreSQL

# 🔐 云事件响应 + IAM 锁定 **利用 AWS CloudTrail、CloudWatch、SNS 和 CLI 驱动的策略执行，实现自动化威胁检测和 IAM 遏制。** ## 🧩 问题背景 在云环境中，权限提升是最常见且最具破坏性的攻击模式之一。攻击者——或受损的内部账户——一旦获得创建或修改 IAM 策略的能力，就能在几分钟内实际控制整个 AWS 环境。 面临的挑战是：大多数云团队都是在*损失造成之后*，通过手动日志审查或延迟的 SIEM 警报才检测到这些事件。本项目的目标是构建一个从检测到响应的管道，使其从可疑 IAM 事件触发的那一刻起，到访问受限的那一刻止，全流程自动运行——在遏制步骤中无需人工干预。 ## 🛠️ 实施方法 ### 架构 ``` CloudTrail → CloudWatch Logs → Metric Filter → CloudWatch Alarm → SNS → IAM Lockdown (CLI) ``` | 组件 | 作用 | |---|---| | AWS CloudTrail | 捕获所有 API 活动，包括 IAM 事件 | | CloudWatch Logs + Metric Filter | 解析日志以检测 `CreatePolicyVersion` 和侦察模式 | | CloudWatch Alarm | 当筛选指标越过阈值时触发 | | Amazon SNS | 发送电子邮件警报并发出遏制信号 | | IAM Policy (CLI) | 应用拒绝策略以限制受损用户 | | EventBridge | 将 IAM 变更事件路由到目标日志组 | ### 模拟攻击场景 使用 `suspect-user` 账户来模拟内部威胁或凭证泄露。该场景分两个阶段运行： **阶段 1 — 权限提升** - 通过 `attach-user-policy` 授予可疑账户 AdministratorAccess 权限 - 生成新的访问密钥，模拟凭证盗窃 - 使用被盗密钥配置 AWS CLI 配置文件 - 攻击者进行侦察：查询日志组，枚举 IAM 结构 **阶段 2 — 检测与响应** - CloudTrail 记录来自可疑配置文件的 `CreatePolicyVersion` 事件 - 指标筛选器标记该事件；CloudWatch 警报突破阈值 - SNS 向安全团队发送电子邮件警报 - 通过 CLI 应用 IAM 拒绝策略以锁定可疑用户 ### 关键技术决策 - **选用指标筛选器而非仅使用 EventBridge：** EventBridge 提供近实时的路由，但原生不支持基于阈值的警报。CloudWatch 指标筛选器允许设置警报逻辑（例如，“如果此事件在 5 分钟内出现不止一次则触发”），这对于避免针对一次性 API 调用的误报至关重要。 - **选用 CLI 驱动的锁定而非 Lambda 自动化：** 对于本次实验，IAM 锁定是通过 CLI 手动执行的，旨在逐步演示分析人员的工作流程。该架构已为 Lambda 做好准备——SNS 主题可以触发 Lambda 函数以自动应用拒绝策略，这是此模式在生产环境中的延伸。 - **作用域拒绝策略：** 锁定策略对 `iam:*` 和 `sts:AssumeRole` 使用显式拒绝，而不是全面拒绝整个账户，以避免在遏制期间中断合法的 CloudWatch 代理和 EC2 服务调用。 ## ✅ 成果 | 里程碑 | 结果 | |---|---| | CloudTrail 初始化并记录日志 | ✅ 已确认 | | Root 登录警报配置并触发 | ✅ 收到电子邮件警报 | | 模拟可疑用户权限提升 | ✅ 已附加 AdministratorAccess，已创建访问密钥 | | 通过指标筛选器检测到侦察活动 | ✅ 触发 SNS 警报 | | 检测到 `CreatePolicyVersion` 提升 | ✅ 越过警报阈值 | | 已应用 IAM 锁定策略 | ✅ 通过 CLI 限制访问 | 完整的检测到警报管道已端到端运行。可疑配置文件的 `CreatePolicyVersion` 事件在指标评估窗口内触发了 CloudWatch 警报，并送达了 SNS 电子邮件通知。随后应用了 IAM 拒绝策略，限制了受损账户对 IAM 和角色扮演的访问。 ## 📸 操作演示 ### 基础设施设置  *CloudTrail 已初始化用于 API 活动记录*  *已为所有区域启用日志记录以实现全面治理覆盖*  *EventBridge 规则将 IAM 变更事件路由到 CloudWatch 日志组* ### 检测管道  *针对 CloudTrail 日志组中 `CreatePolicyVersion` 事件的指标筛选器*  *已更正筛选器目标——初始配置错误指向了错误的日志组；通过验证日志组 ARN 修复*  *监控 Root 账户登录的 CloudWatch 警报——任何 Root API 活动都会触发*  *警报违规时送达的 SNS 电子邮件通知*  *Root 登录事件被捕获并在 CloudTrail 事件历史记录中可见* ### 攻击模拟  *账户中已确认存在可疑 IAM 用户*  *已附加 AdministratorAccess 策略——执行权限提升*  *为可疑用户生成了新访问密钥——模拟凭证渗出*  *使用被盗凭证配置的 AWS CLI 配置文件*  *攻击者通过 CLI 枚举日志组——侦察行为已记录* ### 响应  *添加了指标筛选器以检测日志组枚举模式*  *为侦察检测阈值创建的 CloudWatch 警报*  *当突破侦察阈值时发出的警报*  *为 `CreatePolicyVersion` 权限提升检测添加了第二个指标筛选器*  *针对 IAM 和 STS 操作起草的自定义拒绝策略*  *锁定策略成功部署到账户*  *可疑配置文件的 `CreatePolicyVersion` 事件触发警报*  *CloudWatch 确认警报违规——事件严重性已确认* ## 📚 经验教训 **日志组定位比筛选器本身更重要。** 指标筛选器的编写是正确的，但最初指向了错误的日志组——CloudTrail 记录到一个组，而筛选器监视的是另一个。直到我明确验证了 ARN，警报才触发。在生产环境中，这将是一个无声的故障——检测已配置但无法运行。教训：在宣布检测规则上线之前，务必使用测试事件进行端到端验证。 **阈值调优是真正的权衡。** 将警报阈值设置为 1（任何单次出现都触发）适用于像非管理员账户执行 `CreatePolicyVersion` 这样的高置信度事件。对于像日志组枚举这样噪声较大的事件，阈值为 1 会在真实环境中产生误报。区分信号与噪声是检测工程的核心技能。 **CLI 锁定速度快，但 Lambda 是生产模式。** 通过 CLI 手动应用拒绝策略在实验室中可行，并且清晰地展示了分析人员的工作流程。在生产中，SNS 主题应触发 Lambda 函数，在警报发出后的几秒钟内自动应用锁定——从而完全消除遏制步骤中的人工延迟。 ## 🔧 工具与服务 - AWS CloudTrail - AWS CloudWatch Logs & Alarms - Amazon SNS - Amazon EventBridge - AWS IAM - AWS CLI - Ubuntu 24.04 (VirtualBox) ## 🚀 计划扩展 - **Lambda 自动化：** 用 SNS 触发的 Lambda 替换手动 CLI 锁定，以实现 60 秒内的自动遏制 - **Terraform 配置：** 使用基础设施即代码 实现完整检测管道的可重复部署 - **额外的检测规则：** 扩展指标筛选器以覆盖 `AttachUserPolicy`、`CreateUser` 和 `AssumeRole` 滥用模式 - **与云安全警报系统集成：** 将 IAM 事件输入 PostgreSQL 警报管道以进行跨系统关联 ## ⚠️ 免责声明 本项目完全在个人 AWS 账户内使用模拟测试身份进行。未发生未经授权的访问、凭证使用或与外部系统的交互。所有内容仅用于教育和专业发展目的。

标签：AWS, CloudTrail, CloudWatch, containment, DPI, FOFA, FTP漏洞扫描, IAM 策略, JSONLines, PostgreSQL, 云端防御, 内部威胁, 威胁情报, 安全编排, 开发者工具, 攻击模拟, 测试用例, 特权升级, 蜜罐技术, 足迹分析, 身份与访问管理, 零信任, 驱动签名利用