云日志、对象存储与审计入口：从上传校验到可证明删除

日志、对象与审计证据链从请求标识进入日志查询，沿审计主体追到对象版本、校验值、复制副本、保留策略与可证明删除。高清原图

一次文件导出失败后，应用日志显示上传成功，下载接口却返回 404。对象存储控制台里同名 key 前面有删除标记，版本列表里还有三个旧版本；复制桶仍保留一份，生成过的签名 URL 也没有到期。团队想追查是谁删除的，只在业务日志中找到一个 request_id，控制面审计里却按另一个事件 ID 组织。几天后，存储量和日志查询费用继续上涨，大家才发现“页面上看不到对象”与“数据已经物理消失”根本不是一件事。

这个现场同时存在三种数据对象。应用日志记录程序运行时发生了什么；对象存储保存原始文件、构建产物、导出包及其版本；控制面审计记录哪个身份通过控制台、CLI、SDK 或 API 调用了什么管理动作。它们有不同的主键、权限、保留和删除语义。可靠的云上开发流程不是把三者倒进同一个搜索框，而是先给一次动作建立关联标识，再让每种数据保留自己不可替代的证据。

先认清三种对象各自能证明什么

应用日志的最小单位是日志事件。它通常包含时间、级别、服务、环境、request_id、消息和业务字段；一组同源事件进入 log stream，多条 stream 再归入共享保留与权限策略的 log group。日志能够证明“应用观察到了什么”，却不能单独证明云 API 最终成功，也不能把字符串 uploaded 当成对象已经持久化的证据。异步上传、重试、代理缓存和错误吞噬都会让业务日志早于真实结果。

对象存储的最小身份不是文件名，而是 bucket + key + version/generation。未开启版本时，同 key 写入通常替换当前内容；开启版本后，每次写入会产生新版本，旧版本继续占用存储。对象元数据还包括长度、内容类型、校验值、加密方式、KMS key 标识、存储级别、标签和复制状态。ETag 是协议元数据，不应普遍当作本地文件 MD5：分段上传和不同加密模式都可能让它不再等于对象内容的 MD5。Amazon S3 的对象完整性说明把上传端校验、服务端校验和下载校验分开说明；项目应记录明确的 checksum 算法和值，而不是猜测 ETag。

控制面审计的最小单位是 API 事件。它回答调用时间、服务、动作、区域、主体、会话来源、请求参数摘要、响应或错误、源地址、user agent、资源和 request ID。AWS CloudTrail 的 userIdentity 会区分 IAM 用户、AssumedRole、AWS 服务等身份，并在临时凭据场景记录会话来源，字段语义可按CloudTrail userIdentity 参考判断。审计事件证明“云控制面接收并记录了哪个调用”，但未必包含对象正文，也不等于业务请求全链路追踪。

因此一次上传至少要保存两个关联键：应用生成的 <request-id> 和云 API 返回的 <cloud-request-id>。对象清单再保存 <bucket>/<key>#<version-id> 与 checksum。查事故时先由业务请求定位日志，再由云请求 ID、事件名和时间窗定位审计，最后用对象版本与校验值验证数据；不能只靠文件名和操作者记忆拼接。

evidence-manifest.json

{
  "request_id": "<request-id>",
  "cloud_request_id": "<cloud-request-id>",
  "environment": "<test-environment>",
  "region": "<aws-region>",
  "principal_role": "<assumed-role-name>",
  "object": {
    "bucket": "<your-audit-bucket>",
    "key": "evidence/<request-id>/payload.json",
    "version_id": "<version-id>",
    "checksum_algorithm": "SHA256",
    "checksum_base64": "<sha256-base64>",
    "encryption": "aws:kms",
    "kms_key_alias": "alias/<your-test-key-alias>"
  },
  "retention_class": "<short-lived-test>",
  "owner": "<team-name>",
  "expires_at": "<T-plus-N>"
}

清单中不放 AK/SK、session token、签名 URL、邮箱、内网域名、原始 IP 或完整敏感请求体。主体用受控角色和匿名化会话标识，资源 ID 使用团队可查的受控映射；真正的敏感数据留在有权限和保留策略的数据源里。

在隔离身份和区域中启用查询入口

下面用 AWS CLI v2 把三个入口串起来，因为 S3、CloudWatch Logs 和 CloudTrail 的 CLI 可以共享 profile 与区域。AWS CLI v2 的 Windows、macOS 和 Linux 安装方式及平台要求会更新，应从官方安装页取得安装包并按团队基线锁定来源；安装后用 aws --version 记录实际版本，不从文章示例推断版本号。AWS 服务能力和价格随区域变化，执行前还要在AWS 区域服务表确认目标区域可用性。

开发者不要把默认 profile 当成测试身份。先用隔离配置目录、显式 profile 和显式 region 查询身份，再读取 bucket、log group 与审计事件。CLI 的 help 和 --generate-cli-skeleton 不发送业务请求，适合先确认参数形状；真正调用前，终端输出里的账号、角色和区域必须与任务记录一致。

# Linux / macOS：隔离本次练习的配置，不读取个人默认目录
export AWS_CONFIG_FILE="$PWD/.tmp/aws/config"
export AWS_SHARED_CREDENTIALS_FILE="$PWD/.tmp/aws/credentials"
export AWS_EC2_METADATA_DISABLED=true
export AWS_PROFILE="<short-lived-profile>"
export AWS_REGION="<aws-region>"
export AWS_PAGER=""

aws --version
aws s3api put-object help
aws logs start-query help
aws cloudtrail lookup-events help
aws sts get-caller-identity --profile "$AWS_PROFILE" --region "$AWS_REGION"

PowerShell 对应使用 $env:AWS_CONFIG_FILE、$env:AWS_SHARED_CREDENTIALS_FILE、$env:AWS_PROFILE 和 $env:AWS_REGION。推荐通过 IAM Identity Center、角色切换或其他短期凭据机制建立 <short-lived-profile>；配置文件只保存非秘密选项或受控登录入口，不把个人长期 AK/SK 写进仓库。身份查询成功时至少核对账号占位值、角色 ARN 和 session；出现 Unable to locate credentials 说明隔离生效但尚未取得凭据，出现 ExpiredToken 说明会话已过期，出现 AccessDenied 则说明已经认证但没有调用权限。三者不是同一种故障。

对象读写角色只获得测试桶前缀上的 s3:PutObject、s3:GetObject、必要的 s3:ListBucket 与版本读取权限；永久删除版本的 s3:DeleteObjectVersion 单独授予清理角色。日志查询角色需要 logs:StartQuery、logs:GetQueryResults 和受控 log group 的读取能力，CloudWatch Logs 的服务授权参考列出了动作可约束的资源类型。审计查询角色需要 cloudtrail:LookupEvents；修改 trail、事件数据存储和日志目的地属于另一组高风险权限，不能因“需要查审计”一并授予。

上传、下载和哈希要形成正向闭环

先在本地生成不含真实业务数据的样例，计算 SHA-256，再把对象上传到已经由管理员准备好的测试 bucket。put-object 显式请求 checksum 与 SSE-KMS，响应中的 VersionId、ChecksumSHA256、SSEKMSKeyId 和请求元数据一起进入证据清单。S3 支持在上传时独立计算并比较 checksum，服务端不匹配时拒绝对象；这比上传完成后只对比文件大小可靠。具体算法、完整对象与分段对象的差异以S3 上传完整性指南为准。

set -euo pipefail
: "${AWS_PROFILE:?set AWS_PROFILE}"
: "${AWS_REGION:?set AWS_REGION}"
: "${BUCKET:?set BUCKET to <your-audit-bucket>}"
: "${REQUEST_ID:?set REQUEST_ID to <request-id>}"
: "${KMS_KEY_ID:?set KMS_KEY_ID to alias/<your-test-key-alias>}"

mkdir -p .tmp/cloud-evidence
printf '{"request_id":"%s","status":"ok"}\n' "$REQUEST_ID" \
  > .tmp/cloud-evidence/payload.json

openssl dgst -sha256 .tmp/cloud-evidence/payload.json
CHECKSUM_B64="$(openssl dgst -sha256 -binary .tmp/cloud-evidence/payload.json | openssl base64 -A)"
KEY="evidence/${REQUEST_ID}/payload.json"

aws s3api put-object \
  --profile "$AWS_PROFILE" --region "$AWS_REGION" \
  --bucket "$BUCKET" --key "$KEY" \
  --body .tmp/cloud-evidence/payload.json \
  --content-type application/json \
  --checksum-algorithm SHA256 \
  --checksum-sha256 "$CHECKSUM_B64" \
  --server-side-encryption aws:kms \
  --ssekms-key-id "$KMS_KEY_ID" \
  --metadata "request-id=${REQUEST_ID},data-class=test" \
  > .tmp/cloud-evidence/put-result.json

aws s3api head-object \
  --profile "$AWS_PROFILE" --region "$AWS_REGION" \
  --bucket "$BUCKET" --key "$KEY" --checksum-mode ENABLED \
  > .tmp/cloud-evidence/head-result.json

aws s3api get-object \
  --profile "$AWS_PROFILE" --region "$AWS_REGION" \
  --bucket "$BUCKET" --key "$KEY" --checksum-mode ENABLED \
  .tmp/cloud-evidence/downloaded.json \
  > .tmp/cloud-evidence/get-result.json

openssl dgst -sha256 .tmp/cloud-evidence/downloaded.json
cmp .tmp/cloud-evidence/payload.json .tmp/cloud-evidence/downloaded.json

正向结果不是一句 upload completed。put-result.json 应出现服务端 checksum、加密确认和版本 ID（bucket 已启用版本时）；head-result.json 应显示相同的对象长度、checksum 与加密 key；cmp 退出码应为 0。SSE-KMS 还要求调用主体可以使用目标 key，S3 与 KMS 的授权共同决定成功。SSE-KMS 的 key、bucket 默认设置与调用关系见AWS KMS 服务端加密说明。

下载校验要比较同一种算法、同一种编码。CLI 返回的 ChecksumSHA256 是 Base64 编码值，而 openssl dgst -sha256 默认打印十六进制；直接比较字符串一定失败。证据清单可以统一存 Base64，同时把本地十六进制值作为人类排查信息。大型文件若走 multipart，必须确认记录的是完整对象 checksum 还是组合 checksum，不能再用“ETag 看起来像 MD5”作为判断。

反向实验要让损坏、越权和错区域显形

最便宜的反例在本地就能完成。复制下载文件，追加一个字节后重新计算 SHA-256；哈希必须变化，cmp 必须非零。这个实验验证的是校验链，而不是云厂商可用性。

cp .tmp/cloud-evidence/downloaded.json .tmp/cloud-evidence/tampered.json
printf ' ' >> .tmp/cloud-evidence/tampered.json

openssl dgst -sha256 .tmp/cloud-evidence/downloaded.json
openssl dgst -sha256 .tmp/cloud-evidence/tampered.json

if cmp .tmp/cloud-evidence/downloaded.json .tmp/cloud-evidence/tampered.json; then
  echo "unexpected: tampering was not detected" >&2
  exit 1
else
  echo "expected: content differs and SHA-256 must differ"
fi

云端反例应在测试账号由管理员配置：上传角色保留 PutObject，显式拒绝 DeleteObjectVersion；读者尝试删除指定版本时应得到 AccessDenied，CloudTrail 中应出现失败主体、动作、资源和错误。另一个稳定反例是把 AWS_REGION 临时改成 <wrong-region> 后执行 head-object。不同 endpoint 和 bucket 类型可能返回重定向、区域不匹配或签名错误；判断依据是响应头、CLI debug 中的 endpoint 和审计区域，而不是反复刷新控制台。

若上传返回 BadDigest，先比较算法与 Base64/hex 编码，再确认 shell 没有把换行或 BOM 写进文件；若返回 KMS AccessDenied，检查调用者权限、key policy、key 状态和区域，不能只给 S3 放宽权限；若下载得到 404，先列版本和删除标记，不能立即断言物理删除。403 还可能刻意隐藏对象是否存在，只有同时具备受控列表权限并核对审计，才能区分“对象不存在”和“没有读取权”。

版本、加密和签名 URL 是三个独立控制面

版本解决误覆盖与误删除恢复，不解决机密性；加密保护静态数据和 key 控制，不自动限制谁能生成下载能力；签名 URL 把签名者已有权限包装成一段限时 bearer capability，不等于匿名公开，也不会替代版本与加密。

S3 开启版本后，普通 DELETE 不会永久移除当前版本，而是插入 delete marker；不带 version ID 的 GET 随后返回 404，旧版本仍可读取且继续计费。S3 Versioning 工作流明确区分 current version、noncurrent version、delete marker 与指定 version ID 的永久删除。恢复时优先把目标旧版本复制成新的 current version，保留原历史；删除 marker 也能让旧版本重新可见，但更容易在并发写入和生命周期动作之间造成误判。

SSE-S3、SSE-KMS 和客户端加密的责任不同。SSE-S3 由存储服务管理 key；SSE-KMS 让团队控制 key policy、审计和停用，但引入 KMS 权限、区域、请求量和 key 生命周期；客户端加密让服务端只看到密文，却把 key 备份、轮换、元数据和恢复责任推给应用。不要把 key 名、原始 IV 或敏感分类写进公开对象名。KMS key 被禁用或进入 PendingDeletion 后立即不能用于正常加解密；等待期结束后的删除不可逆，仍依赖该对称 key 的密文会永久无法恢复。AWS KMS 本身不保存“哪些对象使用了这把 key”的完整清单，因此退出前必须从 S3 Inventory、对象头、CloudTrail 使用记录和应用清单反向盘点，并完成新 key 重写、抽样下载和灾备恢复验证。AWS 的KMS key 删除说明也建议不确定时先禁用而非删除；“无法解密”不等于“对象已删除”，存储费用仍可能存在。

签名 URL 应绑定具体方法、bucket、key、必要时的 version ID、内容类型、checksum 和短过期时间。AWS 的预签名 URL 指南说明 URL 使用生成者的凭据权限，并可用于限时上传或下载；持有人在有效期内可以使用它，因此 URL 不进入聊天、工单正文、日志、Referer、分析平台或 CI 控制台。由临时凭据签出的 URL 最晚会随底层凭据失效，即使 URL 参数声明了更长时间；桶策略还可用 s3:signatureAge 给所有签名请求设置更短的服务器端上限。即时止血要按签发身份处理：撤销临时会话、禁用签发 access key、收窄角色或桶策略；更换对象 key 只能阻断旧路径，禁用 KMS key 会同时伤及所有依赖对象，不应作为单条 URL 的常规撤销手段。

# GET URL：只打印到受控终端，不写入日志或仓库
aws s3 presign "s3://${BUCKET}/${KEY}" \
  --profile "$AWS_PROFILE" --region "$AWS_REGION" \
  --expires-in "<short-expiry-seconds>"

# 需要精确绑定 PUT 的 checksum、Content-Type 或 SSE 头时，
# 使用受审 SDK 生成 URL，并把这些请求头纳入签名；调用方必须原样发送。
# URL 本身按 secret 处理，过期后执行一次请求并期望 403 作为失效证据。

URL 过期只阻止后续请求，不会终止已经开始的数据传输，也不会删除此前下载的副本。上传 URL 若允许同 key 覆盖，还可能制造新版本和额外费用；生成端应使用随机且可归属的 key、条件写入与 checksum，并在完成后读取对象元数据验证。Google Cloud 的Signed URL 说明同样强调“持有 URL 即可在有效期内执行特定请求”；Azure 场景优先采用由 Microsoft Entra 凭据签发的 user delegation SAS，避免把存储账号 key 变成长期共享秘密。

从 request ID 进入日志查询，而不是扫描全部历史

日志查询先限定账号、区域、log group 和窄时间窗，再按 <request-id> 过滤。这样既降低扫描费用，也减少无关敏感信息暴露。CloudWatch Logs Insights 的官方查询示例展示了 fields、filter、sort、stats 等基本语法；项目应优先写结构化 JSON 日志，让 request_id、cloud_request_id、object_key_hash、status 和 duration_ms 成为字段，而不是依赖正则从自由文本猜。

START_EPOCH="<T0-300-seconds>"
END_EPOCH="<T0+900-seconds>"
LOG_GROUP="<your-test-log-group>"
REQUEST_ID="<request-id>"

QUERY_ID="$(aws logs start-query \
  --profile "$AWS_PROFILE" --region "$AWS_REGION" \
  --log-group-name "$LOG_GROUP" \
  --start-time "$START_EPOCH" --end-time "$END_EPOCH" \
  --query-string "fields @timestamp, level, request_id, cloud_request_id, status, @message | filter request_id = '${REQUEST_ID}' | sort @timestamp asc | limit 100" \
  --query 'queryId' --output text)"

for attempt in 1 2 3 4 5; do
  aws logs get-query-results \
    --profile "$AWS_PROFILE" --region "$AWS_REGION" \
    --query-id "$QUERY_ID" > .tmp/cloud-evidence/log-query.json
  STATUS="$(jq -r '.status' .tmp/cloud-evidence/log-query.json)"
  case "$STATUS" in
    Complete|Failed|Cancelled|Timeout) break ;;
    Scheduled|Running) sleep 2 ;;
  esac
done

test "$(jq -r '.status' .tmp/cloud-evidence/log-query.json)" = "Complete"
jq '.statistics, .results' .tmp/cloud-evidence/log-query.json

StartQuery 是异步操作，返回 queryId 不代表结果完成；GetQueryResults 在 Scheduled 或 Running 时可能只有部分结果。StartQuery 命令参考还说明查询结果会被服务保存、查询有超时与区域并发限制。脚本必须轮询终态、设置总超时，并在自动化任务中避免高频空轮询。

零结果先检查五件事：区域是否正确、log group 是否正确、时间戳是秒还是毫秒、应用字段名是否一致、采集延迟是否超过窗口。MalformedQueryException 是查询语法或字段解析问题；AccessDeniedException 是查询动作或 log group 资源授权问题；长时间 Scheduled 常见于并发槽位被占用。不要为了“能搜到”直接把时间窗放大到全部保留期，先用已知时间和 stream 验证采集，再逐步扩窗，并观察返回 statistics 中的扫描量。

审计主体、会话和云 request ID 必须一起看

审计查询从事件名或资源名进入，再展开原始事件。CloudTrail Event history 默认提供区域内近期 management events，可用控制台或 lookup-events 查询；它不包含 data events，且持续留存需要 trail 或 event data store，能力边界见Event history 官方说明。对象级 GetObject、PutObject、DeleteObject 属于数据面操作，想追踪它们必须在目标 bucket/prefix 上启用相应 data events，并评估事件量与费用，不能误以为默认事件历史天然拥有所有对象访问。

EVENT_NAME="<PutObject-or-DeleteObject>"

aws cloudtrail lookup-events \
  --profile "$AWS_PROFILE" --region "$AWS_REGION" \
  --lookup-attributes AttributeKey=EventName,AttributeValue="$EVENT_NAME" \
  --start-time "<T0-minus-window>" \
  --end-time "<T0-plus-window>" \
  --max-results 50 \
  > .tmp/cloud-evidence/cloudtrail-events.json

jq -r '.Events[].CloudTrailEvent' .tmp/cloud-evidence/cloudtrail-events.json \
  | jq '{
      eventTime,
      eventSource,
      eventName,
      awsRegion,
      userIdentity: {
        type: .userIdentity.type,
        arn: .userIdentity.arn,
        principalId: .userIdentity.principalId,
        sessionIssuer: .userIdentity.sessionContext.sessionIssuer.arn
      },
      requestID,
      sourceIPAddress,
      userAgent,
      errorCode,
      errorMessage,
      resources
    }'

AssumedRole 事件要同时看角色 ARN、session issuer、principal ID 和 session name。只保存展示名会把多个人的共享角色操作混在一起；只保存 access key ID 又会泄漏敏感标识且不利于长期归因。团队应让 SSO/STS session name 或 source identity 可追到内部工单，同时在导出给普通开发者的报告中脱敏。

requestID 是服务请求关联键，eventID 是审计事件自身标识，两者不能互换。业务 SDK 应从成功响应和异常响应元数据中提取云 request ID，写入结构化日志；排障时用 eventName + region + narrow time window + resource + principal 缩小集合，再比较 request ID。没有命中时，检查查询的是 management event 还是 data event、事件是否在另一区域、trail selector 是否覆盖目标 prefix、事件交付是否存在延迟，以及调用是否在进入服务前就被代理或 DNS 拦截。

开启 trail 的日志文件完整性验证只会让 CloudTrail 交付按小时串联并签名的 digest，不会自动替团队验证。取证演练还要在原始投递位置运行 aws cloudtrail validate-logs，保存验证时间窗、trail ARN、区域和失败区间；该命令只验证 digest 引用的文件，移动到其他位置的副本不能直接套用 CLI 验证。AWS 的完整性验证机制使用 SHA-256 与 RSA 签名检测日志或 digest 被修改、删除的情况。停止 logging、删除 trail 或关闭 validation 会打断 digest 链，这些动作本身应由独立安全身份控制并告警。

Azure 中对应的控制面证据是 Activity Log，它默认记录创建、更新、删除等控制面事件，读取操作通常不在其中；需要更长保留或关联 Log Analytics 时，应通过 diagnostic setting 导出，具体保留与导出能力见Azure Activity Log 官方说明。Google Cloud Audit Logs 则从 protoPayload.authenticationInfo、authorizationInfo、requestMetadata 和资源字段识别主体、权限判断与来源；调用者身份在某些失败读取场景可能被脱敏，不能把空 principal 直接解释为匿名，字段边界见Cloud Audit Logs 概览。跨云平台应统一“主体、会话、动作、资源、区域、request/correlation ID、结果”这组逻辑字段，但保留原始事件，不强行抹平厂商语义。

保留与生命周期要分别作用于日志、版本和审计

保留策略不是一个全局天数。应用日志按排障和安全需求设置 log group retention；对象按当前版本、非当前版本、删除标记、未完成分段上传和存储级别分别处理；审计按管理事件、数据事件、事件存储和导出副本分别处理。三种数据的 owner 也不同：服务团队负责日志字段与噪声，数据 owner 决定对象恢复窗口，云平台或安全 owner 负责审计选择器与不可篡改存档。

CloudWatch Logs 默认可长期保留，设置 retention 后，超过窗口的事件会被标记删除，实际移除通常不是瞬时完成；官方log group 与 retention 说明还指出标记删除后不再计入归档存储费用和 storedBytes。因此“查询不到旧事件”“storedBytes 下降”和“后台物理删除完成”是三个不同观察面。降低保留后不要马上调高并宣称清理完成，应保持较低设置越过删除处理窗口并复核。

S3 版本 bucket 的生命周期至少显式处理 current、noncurrent、expired delete marker 和 incomplete multipart upload。下面的 14、30、3、7 只是让 JSON 保持可执行的短期测试值，不是生产保留承诺；团队应按恢复窗口、合规和费用预算审批后替换，并先在独立测试 prefix 上观察清单，再扩大到目标数据。规则筛选错误会批量改变数据状态。

lifecycle.json

{
  "Rules": [
    {
      "ID": "<expire-short-lived-evidence>",
      "Status": "Enabled",
      "Filter": { "Prefix": "evidence/" },
      "Expiration": { "Days": 14 },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30,
        "NewerNoncurrentVersions": 3
      },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    },
    {
      "ID": "<remove-expired-delete-markers>",
      "Status": "Enabled",
      "Filter": { "Prefix": "evidence/" },
      "Expiration": { "ExpiredObjectDeleteMarker": true }
    }
  ]
}

当前版本过期在版本化 bucket 中通常产生 delete marker，非当前版本只有命中 NoncurrentVersionExpiration 才永久移除；相关分支可按S3 Lifecycle 配置元素核对。Object Lock、legal hold、保留策略和复制状态还会阻止或推迟生命周期动作。上线规则前导出对象 inventory，按 prefix、版本数、大小、存储级别、复制状态、lock 状态估算影响；上线后以 inventory 和版本列表验证，不以规则页面显示 Enabled 代替结果。

Object Lock 只保护具体对象版本，并且依赖已启用的 Versioning。governance 模式允许持有 s3:BypassGovernanceRetention 且在请求中显式声明 bypass 的主体提前删除或缩短保留，适合先演练权限与流程；compliance 模式在 retain-until 到期前连 root 也不能删除受保护版本或缩短期限，不能把它当作可以紧急回滚的开关。legal hold 没有固定到期时间，必须由获授权主体显式解除；它与 retention 可同时生效。AWS 的Object Lock 工作机制还指出，不带 version ID 的普通 DELETE 仍可能成功创建 delete marker，页面上的当前对象因此消失，但受保护旧版本仍在。上线前应分别验证“普通删除生成 marker”“指定受保护版本永久删除得到 403”“无 bypass 权限不能改变 governance retention”，再决定谁持有保留与解除权限。

复制副本不会自动服从源端删除

复制解决区域故障、账号隔离或数据分发，却扩大了删除面和费用面。S3 live replication 主要处理启用后新写入的对象，既有对象需要 Batch Replication；临时停用后漏掉的对象也不会因重新启用自动补齐。源对象状态为 PENDING 时，区域或目标暂时不可用后服务可继续处理；状态进入 FAILED 后，修好权限并不会自动重放该版本，需要重新上传产生新版本或使用 Batch Replication。目标端由复制创建的版本显示 REPLICA。AWS 的复制状态说明还要求在删除源版本前确认复制已经 COMPLETED；这些状态应进入对象清单和告警，而不是只看目标桶里是否碰巧出现同名 key。

最容易误判的是删除传播。S3 复制默认不复制 delete marker；即使启用 delete marker replication，指定 version ID 的永久删除也不会传播到目标 bucket，这种设计可以抵抗源端误删和恶意删除。S3 删除标记复制说明与复制对象边界列出了这些分支。源端 404 因而不能证明目标副本删除，源端版本清空也不能替代目标 bucket 的版本清理。

复制 bucket 应有独立 owner、KMS key、保留和退出清单。跨账号复制还要确认 replica ownership 与目标 key 权限；移除源端复制角色只会让新对象失败，不会回收旧副本。若源 bucket 启用了 Object Lock，目标 bucket 也必须启用 Object Lock，复制角色还需要读取 retention 与 legal hold；复制会异步带走源对象版本的保留元数据，但直接写入目标的对象遵循目标桶自己的默认保留。停用复制前记录切断点，列出 PENDING/FAILED，决定补齐还是接受缺口；清理时分别枚举源和每个目标的 current version、noncurrent version、delete marker、retention、legal hold、inventory、访问日志和审计导出。

Azure Blob 的 version、snapshot 与 soft-deleted blob 也会分别保留。生命周期删除在启用 soft delete 时只把 blob 放入软删除状态，保留期结束后才永久删除；Azure Blob soft delete还说明软删除数据在保留期间继续按活动数据计费。Google Cloud Storage 的 soft delete 对新 bucket 默认启用并具有可配置保留，删除对象或 bucket 后先进入不可读但可恢复状态，具体行为以Cloud Storage soft delete为准。跨云清理脚本必须读取目标租户真实配置，不能把 AWS delete marker、Azure soft delete 和 Google soft delete 当成同一种状态。

物理删除必须逐层证明，而不是执行一条 rm

删除演练从只读清单开始：确认账号、区域、bucket、prefix、owner、审批号和对象数量；冻结新写入或切换应用目的地；撤销签名 URL 生成权限；等待或处理复制；逐版本删除；确认目标副本与导出副本；最后删除空容器和相关日志策略。任何一步数量异常都停止，不能用 --force 跨过去。

set -euo pipefail
: "${CONFIRM_ACCOUNT_ID:?set approved account id}"
: "${CONFIRM_BUCKET:?set exact approved bucket}"
: "${CONFIRM_REGION:?set exact approved region}"

ACTUAL_ACCOUNT="$(aws sts get-caller-identity --profile "$AWS_PROFILE" --query Account --output text)"
test "$ACTUAL_ACCOUNT" = "$CONFIRM_ACCOUNT_ID"
test "$AWS_REGION" = "$CONFIRM_REGION"
test "$BUCKET" = "$CONFIRM_BUCKET"

# 只读盘点；先保存版本、删除标记、复制状态和 lock 状态。
aws s3api list-object-versions \
  --profile "$AWS_PROFILE" --region "$AWS_REGION" \
  --bucket "$BUCKET" --prefix "evidence/<request-id>/" \
  > .tmp/cloud-evidence/versions-before-delete.json

jq '{
  versions: [.Versions[]? | {Key, VersionId, IsLatest, Size}],
  deleteMarkers: [.DeleteMarkers[]? | {Key, VersionId, IsLatest}]
}' .tmp/cloud-evidence/versions-before-delete.json

# 审批系统应把逐项 Key + VersionId 的不可变清单交给独立清理角色执行；
# 正文不提供可直接复制的永久删除命令。

# 删除后再次 list-object-versions：源和每个复制目标的已批准对象版本应为空；
# 审计导出位置必须保留，并包含这次清理的管理事件和已启用的数据事件。

注释中的永久删除命令不能去掉 version ID，也不能由日常上传角色执行。S3 版本化 bucket 必须删除所有 versions 和 delete markers 才能删除 bucket，aws s3 rb --force 不会替你删除这些版本；删除 S3 bucket 的官方说明明确了这一点。若 Object Lock retention 或 legal hold 生效，永久删除应失败；这时记录阻断原因和到期/解除责任，不能尝试绕过治理模式。

所谓物理删除证据至少有四层：API 清单不再返回已批准的目标版本；每个复制与备份位置各自完成同样的版本核验；适用的生命周期、软删除、回收站、Object Lock 和 legal hold 已按批准流程到期、解除或明确证明未覆盖该对象；费用与容量指标在相应计费周期内收敛。云服务内部介质擦除由厂商的数据删除承诺和合规报告支撑，租户侧通常拿不到磁盘扇区级证明；团队能证明的是所有可寻址逻辑副本已经越过保留与恢复窗口，并保存审计事件、清单摘要和审批链。

审计日志自身不能由被审计者随清理脚本一起删除。开发资源删除后，管理事件仍应按审计保留策略存在；事件历史、trail 目标 bucket、CloudTrail Lake 或外部归档各有独立生命周期。若“删除证据”跟资源一起消失，团队得到的不是更彻底的清理，而是不可追责的空白。

费用治理从字节、请求、扫描和副本四条线核算

对象存储费用不只有当前对象字节。版本、软删除数据、复制目标、inventory、对象标签、KMS 请求、PUT/GET/LIST、数据取回、跨区域传输、互联网下载、提前删除费和未完成 multipart 都可能计费。S3 的价格页按区域和存储级别列出存储、请求、数据传输、管理功能与复制费用；复制会产生目标存储、复制 PUT，并可能产生跨区域传输。预算模型必须读目标区域价格，不能把某一区域示例单价写进永久脚本。

日志费用至少拆成采集字节、归档字节、查询扫描字节、数据保护扫描、导出/投递和跨区域副本。字段无限增长、重复堆栈、把大响应体写入日志会同时抬高采集、存储和查询成本。CloudWatch 价格页明确提示费率随区域变化，并分别核算 ingestion、storage 与 Logs Insights scanned data。查询治理应设置默认窄时间窗、强制 log group 选择、结果上限、dashboard 刷新频率和扫描量预算；同一句查询每天手工跑一次与 dashboard 每分钟刷新，成本模型完全不同。

审计费用取决于事件类型、份数、事件数据存储、查询和投递目的地。默认事件历史可以满足近期 management event 追查，但对象 data event 数量可能接近对象请求量；开启前按 bucket/prefix、读写类型和环境筛选，保留对删除、写入和权限变化的高价值证据。CloudTrail 的价格页应与 S3、CloudWatch、KMS 和目标查询服务一起估算，避免只看“审计服务单价”。

每个团队月度报表至少呈现：current bytes、noncurrent bytes、soft-deleted bytes、replica bytes、delete marker 数、incomplete multipart bytes、日志 ingest/stored/scanned bytes、审计 management/data event 数、KMS 请求、数据传输和永久删除候选量。趋势比孤立阈值更重要：临时数据 current bytes 下降而 noncurrent bytes 单调上升，说明生命周期只做了逻辑删除；源 bucket 收敛而 replica bytes 不降，说明退出流程漏了目标；日志存储下降而 scanned bytes 上升，说明查询范围或 dashboard 失控。

项目接入要把证据字段写进 SDK 边界

应用上传函数应返回结构化结果，而不是只返回 URL。结果对象包含 provider、region、bucket、key、version/generation、checksum 算法和值、加密 key 别名、云 request ID 和完成时间；日志只记录对象 key 的受控摘要或非敏感 key，不记录签名 URL。异常对象保留 SDK error code、HTTP status、request ID 和 retryable 判断，调用方据此决定重试、告警或人工处理。

storage-evidence.ts

export interface StoredObjectEvidence {
  provider: 'aws'
  region: string
  bucket: string
  key: string
  versionId?: string
  checksum: { algorithm: 'SHA256'; base64: string }
  encryption: { mode: 'aws:kms'; keyAlias: string }
  cloudRequestId: string
}

export function auditFields(
  requestId: string,
  evidence: StoredObjectEvidence,
) {
  return {
    request_id: requestId,
    cloud_request_id: evidence.cloudRequestId,
    provider: evidence.provider,
    region: evidence.region,
    bucket_alias: '<approved-bucket-alias>',
    object_key_hash: '<sha256-of-object-key>',
    version_id: evidence.versionId ?? '<unversioned>',
    checksum_algorithm: evidence.checksum.algorithm,
    checksum_base64: evidence.checksum.base64,
    encryption_mode: evidence.encryption.mode,
    kms_key_alias: evidence.encryption.keyAlias,
  }
}

CI 上传构建证据时使用 workload identity 或角色联合，不写个人 AK/SK；临时会话使用短有效期，并由身份提供方在 job 结束后回收其可续期能力或等待到期，不能假设每个云都支持对单个已签发会话即时撤销。artifact manifest 作为流水线产物保存。重跑同一 job 时，key 应包含不可混淆的 run/attempt 标识，或使用条件写入防止覆盖。消费者下载后先校验 checksum，再解析内容；解压归档还要防路径穿越、压缩炸弹和恶意文件名，云端 checksum 只能证明字节一致，不能证明内容安全。

项目配置把 bucket alias、region、log group、审计环境和 KMS alias 作为批准枚举，不允许任意用户输入直达资源名。开发、测试与生产分离账号或项目，至少也要分离角色、bucket、prefix、key 和 retention。SDK 升级后跑固定正反用例：正确 checksum 上传成功，错误 checksum 被拒；允许前缀可读写，越界前缀 AccessDenied；签名 URL 到期后 403；普通删除后旧版本可恢复；清理角色永久删除后版本列表为空。

用故障证据反推原因，而不是扩大权限

遇到 404，先问当前版本是否为 delete marker、请求是否缺 version ID、bucket/key 大小写是否一致、签名 URL 是否指向旧 key、请求是否到达正确区域。遇到 403，再区分身份策略、bucket policy、KMS key policy、组织策略、Object Lock、签名过期和请求头不匹配。把角色临时换成管理员会破坏最有价值的权限证据，还可能让后续成功无法解释。

日志查不到时，按“是否采集、是否入对区域、是否入对 log group、时间窗是否正确、字段是否解析、查询是否完成”逐层判断。审计查不到时，先分 management event 与 data event，再查 selector、区域、时间窗、事件延迟和主体。对象 checksum 对不上时，确认下载的是同一 version、比较的是完整对象还是分段组合、Base64 与 hex 是否混淆、内容是否被代理解压或换行转换。

删除后费用不降，优先列 noncurrent versions、delete markers、replicas、soft-deleted objects、incomplete multipart uploads 和低频存储提前删除条件。bucket 删不掉通常不是控制台缓存，而是仍有版本、marker、lock 或未清理子对象。复制状态长期 FAILED 时，检查复制角色、目标 bucket policy、KMS 权限和目标区域；恢复权限后，失败对象通常还需要显式批量复制，不能假定服务自动补账。

排障输出也要脱敏。CLI --debug 可能打印 endpoint、请求头、账号、资源 ARN 和签名上下文，只在受控终端短时开启，保存前过滤 Authorization、session token、signed query string、Cookie 和内部地址。截图若包含对象名、账号 ID、主体 ARN 或签名 URL，应视为敏感证据，进入同样的 RBAC 与删除流程。

长期治理以可恢复、可追责、可退出为终点

平台 owner 维护账号、区域、日志目的地、审计 selector、对象存储基线与费用模型；服务 owner 维护字段、敏感数据分类、请求关联和保留需求；安全 owner 审查主体、KMS、不可篡改保留与永久删除权限；成本 owner 关注版本、复制、扫描和数据传输趋势。共享账号和共享长期密钥会让这四类责任失去依据，应从工作流中淘汰。

权限评审把“日常写入、日常读取、日志查询、审计查询、签名生成、生命周期修改、复制修改、版本永久删除、KMS 管理”拆成不同能力。删除版本、缩短保留、停用审计和销毁 key 需要双人复核；日常开发角色不能通过修改生命周期间接获得批量删除。离职或项目结束时回收角色绑定、OIDC trust、CLI profile、SDK secret、签名服务权限和 KMS grant，并搜索历史 CI 日志与 artifact 是否泄漏 URL 或 token。

季度演练不追求创建大量云资源，而是用一个批准的测试前缀证明不变量：上传后本地与服务端 checksum 一致；错误 checksum 稳定失败；业务 request ID 能关联云 request ID 与审计主体；普通删除可恢复；永久删除需要独立角色；复制副本不会被误认为已同步删除；所有恢复窗口结束后清单、容量与费用趋势收敛。任何一个不变量失效，都先冻结自动清理和签名分发，再修复策略与脚本。

退出某个云服务或项目时，先导出必要对象和原始审计事件并校验，再停止新写入、撤销签名入口、清理 current/noncurrent/soft-deleted/replica 数据、关闭无用查询与投递，最后处理 bucket、log group、trail/event store 和 KMS key。KMS key 最后退出，因为先销毁 key 只会制造“数据仍计费但无法验证和迁移”的僵尸对象。

当团队能从一个 <request-id> 稳定找到应用事件、云 request ID、调用主体、对象版本、checksum、加密 key、复制状态、保留规则和删除证据，日志、对象存储与审计才真正组成了研发证据链。真正的完成标志也不是控制台里少了一行，而是每个可恢复副本都有 owner，每项限时能力都能失效，每次高风险删除都能追责，容量与费用最终回到预期基线。