资源策略对Secrets访问日志审计指南 - 第1节

前言：为什么我总盯着 Secrets 和访问日志

说实话，刚做云安全那两年，我也觉得 Secrets 和日志没什么特别的。直到有一次，公司的一个内部 CI/CD 密钥被员工误传到 GitHub 公共仓库，五分钟内就被爬虫扫到，一夜之间我们的测试服务器被挖矿脚本占满。那次事故让我意识到——不做 Secrets 审计，等于把家门钥匙挂在门外。

从那天起，我养成了一个习惯：每到一个新项目，第一件事就是检查 哪里存了 Secret，以及 谁在什么时候访问过它。这就是本章要讲的核心——Secrets 与访问日志的审计基础。

1.1 什么是 Secret？别想复杂了

简单说，Secret 就是那些一旦泄露就会产生风险的敏感数据。我见过很多人以为只有数据库密码才叫 Secret，其实范围大得多。

常见 Secret 类型

1.2 访问日志：谁、什么时候、做了什么

光知道 Secrets 存在哪里还不够，你还得知道 谁在什么时候访问了它。这就是访问日志的作用。

审计日志的核心字段

我个人习惯把审计日志看作一个 五元组：

• Who — 用户、服务账号或 Pod 身份
• What — 访问的资源路径或 Secret 名称
• When — 精确到毫秒的时间戳
• Where — 源 IP、地理区域、集群名称
• How — 操作类型（Read / Write / Delete / List）

举个例子，你在云平台（比如 AWS CloudTrail 或 GCP Audit Logs）里看到的日志大概长这样：

{
  "eventTime": "2025-03-20T14:23:11Z",
  "userIdentity": {
    "arn": "arn:aws:iam::123456789012:user/deploy-bot"
  },
  "eventSource": "secretsmanager.amazonaws.com",
  "eventName": "GetSecretValue",
  "requestParameters": {
    "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod-db-password"
  },
  "sourceIPAddress": "10.0.1.100"
}

1.3 资源策略：把钥匙和锁分开管

有 Secret，有日志，但如果没有 资源策略，你仍然控制不住谁可以做什么。说白了，资源策略就是一张 谁有权对哪个 Secret 执行什么操作 的权限表。

常见的三种策略模型

你想想看，如果你在一个 K8s 集群中给了一个 ServiceAccount 能读取所有 Namespace 的 Secrets 权限，而审计日志里只记录了“哪位用户调用了 API”，你根本不知道是哪个 Pod 在偷偷拉取密码。所以，资源策略必须和日志审计绑在一起看。

1.4 Secrets、日志、策略的关系（一张图看懂）

下面这张图是我自己画的一个核心关系图，各位在以后做审计时可以直接参考这个视角。

1.5 从审计角度看，这三者缺一不可

我做审计这么多年，发现一个规律：凡是出了重大 Secrets 泄露事故的公司，99% 都至少在这三块中的一块出了问题。

• 没有 Secret 清单 — 你都不知道自己有哪些密码，怎么保护？
• 没有访问日志 — 被偷了钥匙也查不出是谁干的。
• 没有资源策略 — 日志里全是合法的成功操作，你却分不清是正常访问还是越权。