4. 常见的 Secrets 类型（、、密码等）
干了这么多年安全审计，我最常说的一句话就是：你连自己有哪些秘密都不知道，谈何保护？ 很多团队上来就搞加密、上 vault，结果扫描一圈发现几百个硬编码的密码躺在代码里。所以咱先不急着上工具，先把常见的几种 Secrets 掰扯清楚。
我按实际工作中的出现频率，把它们分成四大类。每一类我都会讲清楚“它是什么、长啥样、风险在哪、怎么处理”。
4.1 ——最常用的“门禁卡”
说白了就是一串固定字符串，用来标识调用者身份。你想想看，现在哪个 SaaS 服务没有 ？
- 典型样子：
sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx或=abcdef123456 - 风险特点： 大部分 没有过期时间，一旦泄露，除非手动吊销，否则等于永久后门。
- 常见存放位置： 代码里的常量、环境变量、配置文件、甚至日志里——我在项目中就见过某公司的 被打印在了终端日志里，一躺就是两年。
我的经验： 审计 时，我建议先查三处：git log 的历史提交、.env 文件、还有 CI/CD 的变量面板。很多 Key 藏在历史 commits 里，删了代码也删不掉。
我曾经踩过的坑： 有一回扫描某仓库，发现一个 AWS_ACCESS_KEY_ID 硬编码在数据库连接字符串里。当时团队觉得“内网没事”，结果某个开发打包镜像时忘了脱敏，镜像被上传到公共仓库——嗯，后果自己想吧。
4.2 ——有生命周期的通行证
比 聪明一点，它通常带有时效性和作用域。常见的几种子类型：
| 类型 | 特点 | 生命周期 | 常见用途 |
|---|---|---|---|
| JWT | 自包含 payload，可验证 | Access 短（15min～1h） Refresh 长（天/周） |
API 鉴权、前端-后端通信 |
| OAuth 2.0 | 授权码流程，支持 scope | 服务端控制，通常 1h 内 | 第三方登录、跨平台授权 |
| Personal Access | 类似 但有有效期 | 可设置 1-365 天 | GitHub/GitLab 等平台 |
我个人习惯把 的这种“短生命周期”机制看作安——即使泄露，伤害窗口也有限。但要注意：Refresh 如果保护不当，等于拥有了永久门票。审计时务必检查 Refresh 的存储策略。
4.3 密码——最传统的认证方式
密码这东西，几乎每个系统都有。但最常见的审计问题反而不是密码本身，而是怎么存放密码。
- 错误示范： 明文存储在数据库里、用 Base64 编码（这不是加密）、甚至写成
password=123456放在代码里。 - 正确方式： 使用 bcrypt / argon2 等慢哈希 + 随机盐。我在检查时一定会看
password_hash()函数用的是哪种算法。 - 审计重点： 检查是否有默认密码、弱密码字典、哪些系统还在用 MD5 / SHA1 存储密码。
一个小技巧： 审计时可以用 hashcat 或 john 跑一下被抓到的哈希样本，看看弱密码比例。我见过一个项目，60% 的密码能在一小时内破解出来——嗯，你猜怎么着？他们用的是加盐的 MD5，但盐值重复度太高。
4.4 其他常见 Secret 类型
除了上面三大类，还有不少“游击队”类型的秘密，审计时很容易被忽略：
- 证书私钥（.key / .pem / .pfx）： 通常与 SSL/TLS 或代码签名绑定。私钥泄露意味着信任链崩塌。
- SSH 密钥（id_rsa）： 很多团队把 SSH 私钥直接复制到容器镜像里。我个人习惯在构建流水线里加入
ssh-keygen -lf的验证。 - 数据库连接串： 里面同时包含用户名、密码、主机、端口——一串泄露等于数据库裸奔。
- 第三方服务凭据： 比如 Twilio 的 Account SID + Auth 、Stripe 的 Secret Key 等，通常权限极大。
- 加密密钥： AES 密钥、HMAC 密钥等，存储在代码里或配置文件中。
我曾经遇到过一个案例： 某团队把整个 .gitignore 都配好了，却把私钥放进了 Dockerfile 的 COPY 指令里。镜像被推到了公开仓库，第二天 AWS 上就多出了几百台挖矿实例。所以审计时不仅要查代码，还要查构建产物。
4.5 综合对比表
最后，我习惯用一张大表来总结常见 Secrets 类型的关键属性。这样在出审计报告时，一眼就能看出风险优先级。
| Secret 类型 | 是否可过期 | 是否可吊销 | 典型泄露后果 | 审计优先级 |
|---|---|---|---|---|
| ✘ 通常无 | ✔ 手动吊销 | 数据读取、API 滥调用量 | 高 | |
| JWT | ✔ 短有效 | ✔ 黑名单/无效化 | 会话劫持、越权 | 中 |
| 密码（用户） | ✘（可强制改） | ✔ 重置 | 账户被盗、数据泄露 | 高 |
| 密码（系统/数据库） | ✘ 通常无 | ✔ 修改 | 内网横向移动、数据脱裤 | 紧急 |
| 证书私钥 | ✔ 证书过期 | ✔ CRL/OCSP 吊销 | 中间人攻击、信任崩塌 | 高 |
| SSH 密钥 | ✘ 通常无 | ✔ 从 authorized_keys 移除 | 服务器直接控制权 | 紧急 |
| 连接串 | ✘ | ✔ 修改密码后废弃 | 数据库全部数据 | 紧急 |
审计备忘： 拿到代码库后，先用 gitleaks 或 trufflehog 做全量扫描。我通常先看扫描结果中标记为 “high entropy” 和 “private key” 的条目，再手动验证上下文。记住：没有上下文的风险不是真风险——有些 Base64 字符串其实是正则表达式测试数据，别误判。