Seanfrvr/gcp-data-breach-incident-response

# 数据泄露事件响应 — Cymbal Retail (Google Cloud) ## 场景 Cymbal Retail 是一家零售公司，在 28 个国家/地区运营着 170 家实体店和一个在线平台，报告收入达 150 亿美元，拥有超过 80,000 名员工。作为安全团队的一名初级云安全分析师，我的任务是应对一起重大数据泄露事件：攻击者利用配置不当的云资源组合，未经授权访问了敏感的客户信息，包括信用卡数据和个人详细信息。 本项目介绍了在 Google Cloud 中完整的事件响应生命周期——从调查到遏制、修复和合规性验证——使用了 Security Command Center (SCC)、Compute Engine、Cloud Storage 和 VPC Firewall。 ## 1. 调查 第一步是使用 SCC 的 Risk Overview 和 PCI DSS 3.2.1 合规报告确定泄露范围。由于 Cymbal Retail 处理信用卡支付，因此 PCI DSS 合规是一项直接的监管要求——而该报告清楚地表明该组织未能满足这一要求。  报告标记了几个与违规事件直接相关的高和中等严重性发现： | 发现类别 | 严重性 | 问题 | |---|---|---| | 公开 bucket ACL | 高 | Cloud Storage bucket 可被公开/匿名访问 | | 开放的 SSH 端口 | 高 | 防火墙允许来自任何 IP 地址的 SSH (端口 22) | | 开放的 RDP 端口 | 高 | 防火墙允许来自任何 IP 地址的 RDP (端口 3389) | | 公网 IP 地址 | 高 | Compute VM 直接暴露在互联网上 | | 完整的 API 访问权限 | 中 | VM 正在使用具有完整 API 访问权限的默认服务账号 | | 防火墙规则日志记录已禁用 | 中 | 防火墙流量没有审计追踪记录 | 在 SCC 中按资源类型过滤发现项，从另一个角度证实了同样的情况：受感染的 VM (`cc-app-01`) 因访问已知的恶意软件相关域名、禁用 Secure Boot 以及使用默认服务账号而被标记——这与一台实际已被利用、而不仅仅是理论上存在漏洞的机器的情况一致。 ## 2. 遏制与修复 ### Compute Engine — 替换受感染的 VM 我没有在原地修补受感染的 VM，而是将其视为不受信任的，并从已知干净的快照中重新构建了它——这是当系统可能在 OS 级别遭到篡改时的标准做法。 1. 停止受感染的 VM (`cc-app-01`) 以中止任何正在进行的恶意活动。  2. 从泄露前的快照创建新 VM (`cc-app-02`)，将其配置为无公网 IP 地址、无默认服务账号，并配置网络标签 (`cc`) 以实现精确的防火墙定位。 3. 在新 VM 上启用 Secure Boot 并重新启动它，直接修复了 Secure Boot 被禁用的发现项。  4. 一旦确认替换的 VM 运行正常，便删除了原始受感染的 VM，彻底消除了违规的源头。 ### Cloud Storage — 锁定暴露的 bucket 包含泄露客户数据 (`myfile.csv`) 的存储 bucket 可通过遗留的 ACL 条目公开访问。我移除了 `allUsers` 权限并启用了公共访问权限阻止，然后将 bucket 切换为统一存储桶级访问控制，以便访问由单一且一致的 IAM 策略管理，而不是由对象级 ACL 混合管理——同时保留了现有的项目级 Owner/Editor/Viewer 角色，确保合法用户不会失去访问权限。  ### VPC Firewall — 关闭攻击面 默认的防火墙配置允许来自互联网上任何来源的 SSH、RDP 和 ICMP 流量——这很可能是最初违规事件中使用的入口点。为了在不切断合法管理访问权限的情况下修复此问题： 1. 创建了一个范围严格限制的新防火墙规则 (`limit-ports`)，仅允许来自 Google Cloud 的 Identity-Aware Proxy 范围 (`35.235.240.0/20`) 的 SSH (TCP 22)，并专门针对标记为 `cc` 的实例。 2. 在确认替换规则处于活动状态后，删除了三个过于宽松的默认规则——`default-allow-icmp`、`default-allow-rdp` 和 `default-allow-ssh`——以避免锁定管理访问权限。 3. 在剩余的两条规则（`limit-ports` 和 `default-allow-internal`）上启用了日志记录，以恢复对网络流量的审计可见性。  ## 3. 验证 每个修复步骤都直接映射回初始调查中确定的发现项： - 受感染的 VM 被替换为加固的实例——启用了 Secure Boot，没有公网 IP，没有默认服务账号——解决了公网 IP 暴露、Secure Boot 被禁用以及完整 API 访问权限的发现项。 - 存储 bucket 不再允许公开或匿名访问，现在强制执行单一的统一访问策略，解决了公开 bucket ACL 的发现项。 - 防火墙不再允许来自互联网的不受限制的 SSH 或 RDP 访问；访问范围仅限于 Google 的 IAP 范围，并且启用了日志记录以提供未来的可见性。 这些更改共同直接解决了导致此次泄露的高严重性发现项，并使 Cymbal Retail 的环境重新符合 PCI DSS 合规要求。 *（注意：实验室内部子网的流日志发现项不属于本次练习的范围，因为它们与共享的实验室环境有关，而不是与事件本身有关。）* ## 展示的技能 - 使用 Security Command Center 和 PCI DSS 合规报告进行事件调查 - 在疑似受到破坏后从快照进行安全的 VM 恢复 - Cloud Storage 访问控制加固（公共访问权限阻止、统一存储桶级访问） - 使用最小权限 / IAP 范围的访问权限设计 VPC 防火墙规则 - 将技术修复步骤映射回特定的合规性和风险发现项 ## 环境 Google Cloud Platform — Security Command Center, Compute Engine, Cloud Storage, VPC Firewall 一些修复步骤（存储 bucket 访问模型、限定范围的防火墙规则以及防火墙规则清理）是作为开放式挑战完成的，没有分步说明，这需要独立判断应更改哪些设置以及按何种顺序更改，以避免破坏合法的访问权限。

标签：CISA项目, GCP, PE 加载器, StruQ, 云计算, 安全运营, 库, 应急响应, 扫描框架, 网络安全配置, 规则引擎