分布式系统密钥/凭证泄露应急响应 Runbook

适用对象：SRE / 安全工程师 / 值班 oncall 目标：检测 → 止血 → 溯源 → 恢复 → 加固 全链路可执行 版本：v1.0 ｜ 维护人：苏清和-423

TOC

1. 检测层（3 条泄露路径 × 可复现命令）
2. 止血层（AWS / GCP / 阿里云 × 吊销与轮换 CLI）
3. 溯源层（CloudTrail / GCP Audit Log / ActionTrail 查询）
4. 恢复层（服务恢复 checklist）
5. 加固层（3 条工程化改进 + 配置示例）
6. Runbook 维护记录

1. 检测层：3 条典型泄露路径

1.1 CI 日志泄露（本次事件场景）

场景：CI 脚本 set -x 或 echo $AWS_SECRET_ACCESS_KEY 被写入公开 Artifact / 日志归档。

# 1) 在仓库历史里全量搜 AKIA 前缀（AWS 长期 AK）
git log --all -p | grep -nE 'AKIA[0-9A-Z]{16}'

# 2) 扫当前工作区（含 .env、docker-compose、脚本）
grep -rInE '(AKIA[0-9A-Z]{16}|aws_secret_access_key\s*[:=])' . \
  --exclude-dir=.git --exclude-dir=node_modules

# 3) 扫 Artifact 仓库（以 JFrog Artifactory 为例）
artifactory api /api/search/artifact?name=*.log \
  | jq -r '.results[] | .repo + "/" + .path + "/" + .name' \
  | while read p; do curl -s "https://artifactory.example.com/artifactory/$p" | grep -E 'AKIA[0-9A-Z]{16}'; done

判定标准：命中即视为已泄露，直接进入 §2 止血；仅当 grep 结果为空且 CI 日志系统可审计时才可降级为"疑似"。

1.2 镜像层泄露

场景：docker build 阶段把 secret 以 ENV 或 COPY 写进了某层。

# 1) 列出镜像所有层并查看指令
docker history --no-trunc <image:tag>

# 2) 对每一层展开文件系统（离线分析，不启动容器）
mkdir -p /tmp/layer && cd /tmp/layer
docker save <image:tag> | tar -x
for d in */; do
  if grep -rIlE 'AKIA[0-9A-Z]{16}|aws_secret_access_key' "$d" 2>/dev/null; then
    echo "[HIT] $d"; fi
done

# 3) 或用 trivy 做规则化扫描
trivy image --scanners secret --severity HIGH,CRITICAL <image:tag>

1.3 对象存储 bucket 公开读

场景：S3/GCS/OSS 的 bucket policy 或 ACL 被误开为 public-read。

# AWS S3：列出所有 bucket 并逐桶查 ACL 与 policy
aws s3api list-buckets --query 'Buckets[].Name' --output text | while read b; do
  acl=$(aws s3api get-bucket-acl --bucket "$b" --query 'Grants[].(Grantee.ID,Permission)' --output json)
  pol=$(aws s3api get-bucket-policy --bucket "$b" --query 'Policy' 2>/dev/null)
  echo "[$b] $acl $pol"
done | grep -E 'AuthenticatedURI|public-read|"Principal"\s*:\s*"\*"'

# 阿里云 OSS
aliyun oss ls | awk '{print $2}' | while read b; do
  aliyun oss stat "oss://$b" | grep -i 'acl'
done

2. 止血层：按「密钥类型 × 云厂商」吊销/轮换

原则：先吊销旧凭证，再签发新凭证；吊销动作 5 分钟内必须完成。

2.1 AWS（IAM 用户 AK / 临时凭证 / 根账号 AK）

# 1) 定位泄露凭证所属 IAM 用户（AK 前 4 位 + 中段可反查）
aws iam list-access-keys --user-name <USER>

# 2) 立即禁用（不删除，便于回滚）
aws iam update-access-key --user-name <USER> \
  --access-key-id AKIA_EXAMPLE --status Inactive

# 3) 签发新 AK 并同步到 secret 源
aws iam create-access-key --user-name <USER> --output json

# 4) 若泄露的是 root 账号 AK（罕见但最严重）：直接删除
aws iam delete-access-key --access-key-id AKIA_EXAMPLE

# 5) 撤销该用户所有未过期 STS 临时凭证
aws iam simulate-custom-policy --policy-source arn:aws:iam::<ACCOUNT>:policy/<POL> --policy-source-arn arn:aws:iam::<ACCOUNT>:role/<ROLE>

# 6) 通知：通过 IAM 控制台 / 邮件通道确认告警触达

2.2 GCP（Service Account Key / Workload Identity）

# 1) 列出 SA 的所有 key
gcloud iam service-accounts keys list \
  --service-account=<SA>@<PROJECT>.iam.gserviceaccount.com

# 2) 删除泄露 key（GCP 没有 disable 语义，直接 delete）
gcloud iam service-accounts keys delete <KEY_ID> \
  --service-account=<SA>@<PROJECT>.iam.gserviceaccount.com

# 3) 重新签发
gcloud iam service-accounts keys create /tmp/new-key.json \
  --service-account=<SA>@<PROJECT>.iam.gserviceaccount.com

# 4) 若使用 Workload Identity（推荐），SA 通常无需长期 key，
#    只需确认 Pod 的 annotation 未被替换为异常值
kubectl get pods -A -o jsonpath='{range .items[?(@.metadata.annotations."iam\.gke\.google\.com/service-account")]}{.metadata.annotations."iam\.gke\.google\.com/service-account"}{"\n"}{end}'

2.3 阿里云（RAM 用户 AK / STS Token）

# 1) 查询 RAM 用户的 AK 列表
aliyun ram ListAccessKeys --UserName <USER>

# 2) 禁用泄露 AK（保留 7 天观察期）
aliyun ram UpdateAccessKey --UserName <USER> \
  --AccessKeyId LTAI_EXAMPLE --Status Inactive

# 3) 创建新 AK 并推送到 KMS / 内部 secret 源
aliyun ram CreateAccessKey --UserName <USER>

# 4) 若泄露的是 STS Token（有 1h~12h TTL），
#    通过 RAM 控制台 → 会话管理 → 强制下线
#    （CLI 无对应命令，需控制台操作并截图留档）

# 5) 检查 ActionTrail 是否有异常调用（见 §3.3）

3. 溯源层：泄露后 30 分钟内的异常 API 调用

3.1 AWS CloudTrail

# 时间范围：泄露时刻 T0 - 5min ~ T0 + 30min
# 过滤条件：EventName in (RunInstances, PutObject, CreateAccessKey, ...)
#           且 sourceIPAddress 非公司出口段
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValues=RunInstances,PutObject,CreateAccessKey,DeleteBucket \
  --start-time 2026-10-22T08:00:00Z --end-time 2026-10-22T08:35:00Z \
  --max-items 100 --output json \
  | jq '.Events[] | select(.userIdentity.type=="AssumedRole" or .userIdentity.type=="IAMUser") | {time:.eventTime, user:.userIdentity.arn, ip:.sourceIPAddress, action:.eventName}'

3.2 GCP Audit Log（Cloud Logging）

# 时间窗：ISO 8601
gcloud logging read \
  "resource.type=gcp_span OR resource.type=cloudsql_database OR resource.type=bigquery_dataset" \
  --freshness=24h \
  --format=json \
  --limit=100 \
  --query='timestamp >= "2026-10-22T08:00:00Z" AND timestamp < "2026-10-22T08:35:00Z" AND (protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey" OR protoPayload.methodName="storage.buckets.insert")'

3.3 阿里云 ActionTrail

# 时间窗：RFC3339
aliyun actiontrail LookupEvents \
  --StartTime 2026-10-22T08:00:00Z \
  --EndTime 2026-10-22T08:35:00Z \
  --LookupAttribute.1.Key EventName --LookupAttribute.1.Value CreateAccessKey \
  --LookupAttribute.2.Key EventName --LookupAttribute.2.Value PutObject

判定异常的标准：

• sourceIPAddress 不在公司出口 CIDR 白名单内
• 调用 DeleteBucket / CreateAccessKey / RunInstances 等高危 API
• 同一 IAM 身份在 5 分钟内 ≥3 次不同地域调用

4. 恢复层：服务恢复 checklist

- [ ] 1. 确认所有泄露凭证已 Inactive / Deleted，且无新 STS 签发
- [ ] 2. 重启使用旧凭证的服务（K8s）：kubectl rollout restart deployment/<svc> -n <ns>
- [ ] 3. 清理本地 / 节点上的凭证缓存（~/.aws/credentials、/tmp/*.json、K8s projected volume）
- [ ] 4. 重建连接池：对使用 AWS SDK 的服务执行一次健康检查 + 强制刷新 client
- [ ] 5. 验证新凭证：aws sts get-caller-identity / gcloud auth list / aliyun sts GetCallerIdentity
- [ ] 6. 检查所有下游依赖（DB、MQ、对象存储）的 ACL 与授权策略未被篡改
- [ ] 7. 在 Incident 频道同步恢复时间线，附 CloudTrail / Audit Log 截图

5. 加固层：3 条工程化改进

5.1 Secret 注入方式：从 ENV → 挂载文件 / 短期凭证

问题：ENV AWS_SECRET_ACCESS_KEY 写入容器 env 后，docker inspect、CI 日志、kubectl describe pod 均可泄露。

改进：使用 AWS IRSA（IAM Roles for Service Accounts）+ K8s ServiceAccount，彻底消除长期 AK。

# K8s ServiceAccount 绑定 IAM Role（AWS EKS）
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-svc-sa
  namespace: prod
  annotations:
    eks.amazonaws.com/role-arn: "arn:aws:iam::123456789012:role/my-svc-role"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-svc
spec:
  template:
    spec:
      serviceAccountName: my-svc-sa
      containers:
        - name: app
          # 不再需要任何 AWS_* env

5.2 镜像扫描 CI Gate

问题：含 secret 的镜像被推送到 registry 后才被发现。

改进：在 CI 构建阶段加 trivy 扫描，CRITICAL/HIGH 阻断 push。

# .github/workflows/build.yaml 片段
- name: Scan image for secrets
  run: |
    trivy image --scanners secret --severity HIGH,CRITICAL \
      --exit-code 1 --no-progress "myregistry.example.com/app:${{ github.sha }}"

5.3 最小权限策略 + 定期轮换

问题：AK 权限过大（AdministratorAccess），泄露后影响面不可控。

改进：按服务拆分 IAM Policy，仅授予所需 API；配合 aws iam generate-service-specific-credential 或 KMS 定期轮换。

// IAM Policy 示例：仅允许写特定 S3 前缀
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteToSpecificPrefix",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": ["arn:aws:s3:::my-bucket/uploads/*"]
    },
    {
      "Sid": "DenyPrivilegeEscalation",
      "Effect": "Deny",
      "Action": ["iam:AttachUserPolicy", "iam:CreateUser", "iam:CreateAccessKey"],
      "Resource": ["*"]
    }
  ]
}

6. Runbook 维护记录

| 版本 | 日期 | 修改人 | 变更摘要 | |------|------|--------|----------| | v1.0 | 2026-10-22 | 苏清和-423 | 初版发布：检测/止血/溯源/恢复/加固 5 层全链路 | | | | | |