3. 常见 Secrets 类型：密码、、SSH 密钥……你都得认出来
审计日志里五花八门的 Secrets，其实就那几大类。我刚开始做审计时，经常把 和 OAuth 搞混，后来才摸出门道。这一节我把最常见类型捋一遍，顺便分享一些我踩过的坑。
3.1 为什么要区分类型？
不同类型的 Secret，泄露后的影响天差地别。密码泄露可以改，但私钥泄露可能意味着整个基础设施都要重建。审计日志里，光看“被访问的资源”还不够，得先知道它是个什么 Type，才能快速判断风险等级。
secret_type 必须和被访问资源一一对应。如果日志里写了 secret_type: password 但实际是个 GitHub Personal Access ——嗯，那就是严重的数据质量问题。
3.2 密码（Password）—— 最容易被忽视的“雷”
密码是最古老的 Secret，但在现代微服务架构里依然大量出现。我见过有些团队把数据库密码直接写在 Git 仓库的 application.properties 里——审计扫描到那一刻，所有人都吓了一跳。
| 子类型 | 常见审计特征 | 风险等级 |
|---|---|---|
| 用户登录密码 | 哈希存储，但日志中可能意外出现明文 | 高 |
| 服务间共享密码 | 无过期、明文传输 | 极高 |
| 应用配置密码 | 硬编码在 YAML / XML 中 | 高 |
password=admin123，我当时以为是测试账号，结果发现是生产环境 Redis 的密码。从此以后我要求所有审计管道必须对这类字段做脱敏，否则日志泄露就是雪崩。
3.3 / —— 最难追踪的隐性权限
背后往往绑定了云服务权限。你想想看，一个 AWS Access Key 被泄露，攻击者可以直接开 EC2 挖矿，而你从审计日志里只能看到一堆 SecretAccessKey 的调用记录，根本不知道是哪个 App 在用。
我个人习惯在审计日志中额外抓取 _scopes（作用域）和 _ttl（过期时间）。如果没有这两个字段，就等于只看到了半张图。
- 特点：长期有效、无绑定用户、容易被硬编码。
- OAuth ：有时效、有 scope，但审计时容易漏掉 refresh 。
- Service Account Key：GCP 上的 JSON 密钥文件，泄露后可以直接控制整个项目。
Bearer xxx 或 Authorization: Basic xxx，一定要解析出真正的 格式。不要只记录头部，否则事后根本无从溯源是哪个用户。
3.4 SSH 密钥 —— 基础设施的“万能钥匙”
SSH 私钥一旦泄露，攻击者就能直接登录服务器。我记得有一家客户，他们的 CI 用同一个 SSH 密钥连接上百台生产机器——审计日志里只记录了 ssh-rsa AAA... 的前 20 个字符，根本看不出是哪台主机。
| 子类型 | 审计要点 | 建议处理 |
|---|---|---|
| 用户 SSH 私钥 | 存储路径、是否加密（passphrase） | 审计 + 强制加密 |
| 部署密钥（Deploy Key） | 只读还是读写？绑定了哪些仓库？ | 定期轮换，最小权限 |
| SSH 证书（由 CA 签发） | 有效期、用户身份 | 自动回收 |
这里要特别提一下 SSH 证书（不是密钥对）。很多团队开始用 SSH CA 来管理，这时审计日志里的 cert_serial 和 ca_fingerprint 就变得至关重要。你需要在日志中记录谁签发了谁，否则后面查起来两眼一抹黑。
3.5 其他类型——别漏了这几个
- 数据库连接串：通常包含用户名、密码、主机、端口，全都在一个字符串里。审计时建议拆解成单独字段。
- TLS/SSL 私钥：PEM 文件，泄露后可以伪造证书。审计日志里要记录
key_algorithm、key_size和not_after。 - 加密密钥（Symmetric Key）：比如 AES-256 的密钥文件，泄露后所有加密数据都白搭。
- 服务账户令牌（Kubernetes ServiceAccount ）：挂载在 Pod 里，很多事故都是因为这个令牌权限过大。
3.6 如何从审计日志中快速识别 Secret 类型？
没有银弹，但我总结了几个实用线索：
- 看路径/名称：含
password、secret、key、大概率是 Secret。 - 看格式：SSH 私钥以
-----BEGIN OPENSSH PRIVATE KEY-----开头；PEM 编码的 TLS 私钥以-----BEGIN PRIVATE KEY-----开头。 - 看长度和字符集：通常是 20-40 位大小写字母数字；OAuth 往往以
ghp_（GitHub）或ya29.（Google）开头。 - 看上下文：请求头
Authorization: Bearer后面的值多半是 ；如果是Basic，base64 解码后就是用户名:密码。
把这些规则写成正则表达式放在审计引擎里，效果立竿见影。我建议每半年更新一次——因为厂商们总爱改格式。
3.7 最佳实践：审计字段清单（速查）
| Secret 类型 | 必须记录的字段（除通用字段外） | 示例值 |
|---|---|---|
| 密码 | hashed、source_app、rotated_at | true、my-app、2025-04-01T00:00:00Z |
_type、scopes、expires_at | AWS_ACCESS_KEY、ec2:*,s3:read、2025-06-30T23:59:59Z | |
| SSH Private Key | fingerprint、encrypted、bits | SHA256:abc123、true、4096 |
| OAuth | client_id、grant_type、refresh__available | my-client、authorization_code、true |
| TLS Private Key | algorithm、size、not_after | RSA、2048、2026-12-31T00:00:00Z |
说实话，能把这些字段收全的团队不到 20%。大部分都只记了个 content 字段。如果你能推动记录上面这些结构化信息，审计质量直接上一个台阶。
secret_pattern 字段，把匹配到的正则表达式名称存进去。比如 GitHub_PAT、AWS_AccessKey。查问题的时候直接过滤这个字段，比靠人工猜快得多。
好了，常见 Secrets 类型就是这么些。下次你在审计日志里看到一串乱码，先套上面说的特征过一遍——大概率能猜出个八九不离十。记住：只有认清了类型，才知道怎么处理。