1、Secrets 概述
说起 Secrets，我刚开始做安全运维那几年，其实也没太当回事儿。总觉得「密码放配置文件里很正常啊」，直到有一次审计发现开发环境的一个 被人挂到了 GitHub 上……嗯，那件事之后，我对 Secrets 的态度彻底变了。
1.1 什么是 Secrets
说白了，Secrets 就是一组需要严格保密的敏感数据。它们用来证明身份、授权访问，或者加密通信。你想想看，没有 Secrets，系统之间怎么相互信任？
- 认证信息：比如密码、、SSH 密钥
- 凭证类：、服务账号密钥
- 加密材料：证书私钥、对称密钥、加盐值
- 连接串：数据库连接字符串、Redis 密码、消息队列地址
我个人习惯把 Secrets 分成两类——静态密钥和动态凭证。静态密钥写死在代码或配置里，基本不变；动态凭证（比如临时 、OAuth Code）会频繁轮换，管理起来更麻烦。
password = "123456" 还提交到 Git……那是灾难的开始。
1.2 常见 Secrets 类型
在实际工作中，我碰过最头疼的几类 Secrets 列在下面。每种都有不同的泄露风险，检测频率也不能一刀切。
| Secrets 类型 | 典型示例 | 泄露风险 | 访问频率特点 |
|---|---|---|---|
| AWS Access Key, GitHub | 直接调用云资源，造成经济损失 | 通常高频但不稳定，异常时突增 | |
| 数据库密码 | MySQL root, PostgreSQL 密码 | 数据泄露、删库跑路 | 应用启动时高，运行中稳定 |
| 证书私钥 | TLS 私钥、SSH 密钥 | MITM 攻击、身份冒用 | 极低频，出错时才会有读取 |
| 服务账号 | JWT, Service Account 密钥 | 横向移动、权限提升 | 与业务调用频率相关，偶尔突发 |
| 加密盐/初始化向量 | bcrypt salt, AES IV | 密码破解加速 | 低频，泄露更难发现 |
这里要特别提醒：和数据库密码是异常检测的优先目标。我做过一个项目的统计，70% 的泄露事件都跟这两种有关。
1.3 泄露场景与影响
泄露不是只有黑客攻击才会发生——很多时候是我们自己埋的雷。我回忆几个真实场景：
- 代码仓库误提交：开发人员在 `.env` 或 `config.json` 里写死密码，顺手 push 到公共仓库。
- 日志明文记录：调试日志把 SQL 完整的连接串打出来，结果日志被第三方日志平台公开。
- 配置中心泄露：K8s Secret 被不小心 `describe` 出来，或者 Consul/Vault 的 ACL 配置错误。
- 第三方漏洞利用：Log4Shell 那段时间，很多攻击者通过 JNDI 注入读取了 JVM 内存里的 Secrets。
- 内部人员误操作：运维执行 `cat secret.txt` 在共享终端，被同事看到并截图。
为了让你看得更清楚，我画了一张结构图，把泄露路径和后果串起来：
1.4 为什么需要异常检测
你想想看，Secrets 访问频率本身是个很敏感的指标。正常情况下的访问节奏比较规律，一旦出现异常突增、突降，或者在同一时间点大量调用不同 Secrets，八九不离十是有问题的。
我记得有一次排查告警，发现一个生产环境的数据库密码在凌晨 3 点被连续读取了 500 次——而那个时间段明明没有定时任务。后来查出来是一个新上线的微服务使用了错误的连接池配置，疯狂重建连接。虽然这次不是攻击，但也差点把数据库打崩。
不过要注意，不同 Secrets 的“正常频率”差异巨大。可能每分钟几百次，证书私钥可能几个月都不被读取一次。所以检测模型不能一刀切——具体怎么做，后面的章节会展开。
1.5 我的避坑建议
- 别等泄露了再找原因——把 Secrets 的访问日志集中到 SIEM 里，至少保留 90 天。
- 曾经我在一个项目里发现运维把 Secrets 写到了 Docker 镜像的环境变量里……后来镜像被拉取到私有仓库，所有人都能看到。从那以后我强制团队使用动态注入。
- 检查频率时，别忘了看 访问上下文：谁在调？从哪调？调的是哪个 Secrets？三个维度一起看才能形成完整判断。
好，Secrets 的基本概念和泄露场景就聊到这儿。记住一句话：Secrets 的管理，本质是信任管理。丢了 Secrets 就等于把门的钥匙交给了别人。接下来的章节，我们会深入讲如何用频率异常检测来提前发现这类危险。