云端数据泄露响应
云环境中的数据泄露响应面临独特的挑战，需要采用针对证据保全、事件遏制和分布式系统恢复的专门流程。云基础设施动态且短暂的特性（实例可能被自动销毁、日志在短时间内过期、snapshots 被覆盖）要求立即采取行动，在取证物证消失之前进行捕获。与您对服务器拥有物理控制权的 on-premises 环境不同，在云端，响应依赖于 Cloud Service Provider (CSP) 的 APIs，依赖对 CloudTrail (AWS)、Activity Logs (Azure) 或 Cloud Audit Logs (GCP) 的分析以重建攻击时间线，依赖对暴露配置的识别，例如公开的 S3 buckets、开放的 security groups、权限过度的 IAM roles，依赖与 CSP 支持团队协调以保全数据并隔离被攻陷的资源，依赖对可能已被攻陷的 IAM 权限和 access keys 的详细审查，以及依赖从未受攻击者影响的不可变 snapshots/backups 进行恢复。响应速度至关重要，尤其是在每一分钟都至关重要的数据窃取场景中，而使用自动化（通过 IaC、Lambda functions、Azure Functions）进行遏制和恢复的能力，可能成为可控事件与影响数千客户并引发大规模通知监管义务的灾难性泄露之间的分水岭。
通过 Snapshots 和 Backups 快速遏制
响应云泄露的第一步是确保在采取任何可能销毁证据的遏制行动之前，您拥有被攻陷环境的取证有效副本。立即为所有受影响的 EC2 实例/VMs、EBS 卷/磁盘、RDS/SQL Database 数据库以及任何其他可能包含攻击证据的存储资源创建 snapshots。重要提示：使用特定的 tags（incident-id、timestamp、"DO NOT DELETE"）标记这些 snapshots，并配置可防止意外或自动删除的保留策略。对于正在运行的实例，请考虑在关闭或隔离机器之前，使用 LiME (Linux) 或 FTK Imager (Windows) 等工具，通过 SSM Session Manager (AWS) 或 Custom Script Extension (Azure) 执行以创建 memory dumps。同时，将 CloudTrail/Activity Logs 导出到一个单独的、受 MFA Delete 和 Bucket Lock 保护的 S3 bucket/Storage Account 以确保不可变性——请记住，API 调用日志往往是云中恶意行为的唯一记录，如不加以保全，可能会被覆盖或迅速过期。同时配置 VPC Flow Logs、DNS Query Logs 以及任何可能揭示初始攻击向量的 WAF/Load Balancer 日志的导出。一种推荐做法是设置一个单独的 "forensics account" 或 "security account"，将这些物证自动复制到其中，并与生产环境中被攻陷的凭据相隔离。
CloudTrail 和 Activity Logs 分析
CloudTrail (AWS)、Azure Activity Log 和 GCP Cloud Audit Logs 是您了解泄露期间所发生情况的主要事实来源——它们记录在您的云账户中进行的每一次 API 调用，包括谁发起了调用、来自何处、何时以及使用了哪些参数。使用 AWS CloudTrail Lake、Azure Log Analytics 或 Google Cloud Logging 等工具快速查询可疑事件：查找新建 IAM 用户、生成 access keys、对 security groups/NSGs 的更改、创建宽松的防火墙规则、对 bucket policies 的修改、通过 CreateSnapshot 后再共享给外部账户的窃取尝试、通过 AttachUserPolicy 或 PutRolePolicy 进行的权限提升，以及在异常地理区域使用被攻陷的凭据。请特别关注使用服务凭据（service accounts、roles）而非人类用户执行的事件，因为这可能表明通过被攻陷的实例进行横向移动。通过从已知恶意事件向后追溯，识别 "patient zero"——第一个被攻陷的资源或凭据。如果可通过 S3 Server Access Logs 或 Database Audit Logs 获取，还应分析 data plane 事件（对 S3 对象的访问、数据库 queries）。CloudMapper、ScoutSuite、Prowler 等工具以及使用 boto3 (AWS) 或 Azure SDK 编写的自定义 Python 脚本，可自动分析数千个事件以识别异常。请以可在日后用于监管报告和 post-mortem 分析的格式记录整个时间线。
暴露配置的识别
云数据泄露往往源于 misconfigurations 而非精密的 exploits——配置为公开且包含敏感数据的 S3 buckets、带有 0.0.0.0/0 规则允许从互联网进行 SSH/RDP 访问的 security groups、提交到公开仓库的源代码中 hardcoded 的 secrets、容器环境变量中的数据库凭据、被公开共享的磁盘 snapshots，以及带有 "*"（wildcard）权限、对关键资源授予完全控制权的 IAM policies。使用 Prisma Cloud、Wiz、Orca Security 等 CSPM (Cloud Security Posture Management) 工具，或 Prowler、ScoutSuite、CloudSploit 等 open-source 工具立即运行 scans，以识别所有违反安全 best practices 的配置。请尤其关注：具有 public-read 或 public-read-write 的 S3/Blob Storage buckets、带有允许 0.0.0.0/0 的 ingress rules 的 security groups/NSGs、带有授予管理权限的 inline policies 的 IAM 用户/service principals、在 EC2 user data 或 Lambda environment variables 中暴露的 secrets、在无身份验证或使用默认凭据情况下暴露的数据库，以及可能由攻击者创建的位于意外区域的资源。请立即修复最关键的暴露（含敏感数据的公开 buckets 必须立即设为私有），但在进行更改之前先记录一切，以保全证据链。请考虑攻击者可能已创建 backdoors，例如新的 IAM 用户、恶意 Lambda functions，或允许其返回的 security group rules——查找最近创建或在攻击窗口期内被修改的资源。
与 Cloud Service Provider 协调
在严重事件中，尤其是那些可能涉及 CSP 自身基础设施遭到攻陷（尽管极为罕见）或需要执行您无法独自完成的操作（例如识别 CDNs 背后的真实源 IP、保全已过期的日志，或调查其他 tenants 中的活动）的事件，您应向您的 Cloud Service Provider 支持部门开启一个 security incident case。AWS、Azure 和 GCP 拥有专门的事件响应团队，可以：保全已从您的 tenant 删除或过期但仍存在于 CSP 内部 backups 中的日志和取证数据，提供与恶意活动关联的源 IP 和 ASNs 的信息，确认被攻陷的凭据是否在其他环境中被使用（不侵犯其他客户的隐私），通过 subpoenas 协助为法律程序保全证据，并在极端情况下完全隔离您的账户或对恶意资源执行 takedowns。对于 AWS，使用 AWS Support Center 开启一个 severity 为 "critical" 的 case 并提及 "security incident"——您将被接入 AWS Trust & Safety 团队。Azure 设有 Security Response Center 以及正式的 incident reporting 流程。GCP 通过 Google Cloud Support 提供类似流程。重要提示：在联系之前请准备详细信息——事件时间线、受影响的资源（instance IDs、ARNs、resource IDs）、攻陷的证据，以及您需要 CSP 执行的具体操作。请记住，CSPs 在 shared responsibility model 下运营——他们负责云"本身"的安全（物理基础设施、hypervisor、全球网络），而您负责云"之中"的安全（您的应用程序、数据、配置、IAM）。
被攻陷 IAM 权限的审查
遏制后的首要行动之一应是对您云账户中所有 IAM 权限、roles、policies 和凭据进行全面审计，并假设攻击者可能已通过更改访问控制建立了 persistence。列出所有 IAM 用户、service accounts 和 roles——检查它们的创建时间、最后活动，以及是否有任何在攻击窗口期内创建。立即 rotate 所有 access keys，尤其是与管理账户关联或在日志中显示可疑活动的那些。使用 AWS STS RevokeSessionsPolicy 或其他云中的等效项撤销 IAM roles 的活动 sessions。检查附加到每个 principal 的 inline policies 和 managed policies——查找最近添加的过度权限，尤其是 Actions 或 Resources 中的 wildcards (*)。审查 IAM roles 上的 assume role trust policies，以确保它们未被修改为允许外部账户承担您的 roles。在关键 S3 buckets 上启用 MFA delete，并对敏感的管理操作启用 MFA。在 AWS Organization 级别实施 SCPs (Service Control Policies)，以防止某些破坏性操作，即使是被攻陷的管理员也无法执行。配置 AWS IAM Access Analyzer、Azure AD Privileged Identity Management 或 GCP Policy Analyzer，以识别 over-provisioned 权限和 external access。严格采用 least privilege 原则——如果某个 role/用户仅需列出 buckets，请不要授予 s3:*，仅授予 s3:ListBucket。请考虑使用 HashiCorp Boundary 或 AWS Systems Manager Session Manager 等工具实施 just-in-time access，而非使用持久凭据。对于关键环境，请配置 break-glass procedures，将凭据保存在离线的物理 vault 中，以应对所有 IAM 均被攻陷的极端情况。