凭据管理10条安全红线：这些错千万别犯
凭据管理做得好不好，不在于你用了多炫的技术，而在于有没有守住底线。安当 SMS 在部署实践中沉淀了10 条强制安全红线，每一条都是真实踩坑的教训。本文逐条解读，并附 9 大常见误区对照，帮你少走弯路。
一、10 条安全红线
- 业务系统不长期持有固定高权限账号，统一通过 SMS 动态/托管获取。
- 任何环境明文凭据不得写入git / 镜像 / 配置文件 / 日志 / Excel / 邮件 / 聊天记录 / 代码仓库。
- 绝不回显明文密码、Token、私钥、密文。
- 运行型凭据与管理型凭据严格分离；禁止管理员账号作业务运行账号。
- 多个系统/环境不共用同一份凭据；测试与生产账号隔离。
- 高敏凭据（私钥、管理员密码、高权限密钥、签名密钥）限制导出，避免明文散落。
- 轮换基于版本且可回退；禁止直接覆盖旧值。
- 生产环境启用 TLS 校验；不长期依赖关闭 TLS 校验。
- 不绕开平台直接改密且不回填平台。
- 日志/报表/截图/工单中不得暴露真实密码或密钥内容。
记忆口诀：不持有、不落盘、不回显、不分家、不共用、不散落、可回退、开 TLS、不走偏、不暴露。
二、9 大常见误区对照
| 误区 | 正解 |
|---|---|
| 把 Jenkins / 业务系统当长期秘密存储 | 只保存定位信息与接入配置，真实秘密来自 SMS |
把label当成 Jenkins ID / 业务引用名 | label 是 SMS 远端定位值，本地引用名是另一语义，可相同但含义不同 |
| 日志打印真实密码做验证 | 用存在性 / 长度 / 真实连接验证，不依赖日志脱敏 |
| 联调成功后长期关闭 TLS 校验 | 联调可暂关，生产恢复证书校验 |
| 容器内临时装工具后不做镜像固化 | 生产把依赖固化进镜像或编排配置 |
| 数据库只发不收 | 强制启用回收与残留账号巡检，否则退化为"伪动态" |
| 静态凭据"永久不轮换" | 按风险分级建立轮换计划与提醒 |
RabbitMQ 配.*全通配权限 | 标准仅发布 / 仅消费两类，禁止全通配与管理员角色 |
| 多个系统共用同一份凭据 | 按系统 / 环境 / 用途拆分，独立账号独立责任 |
三、红线与等保 2.0 的对应关系
凭据管理的红线，本质上是在落地等保 2.0 身份鉴别、访问控制、安全审计三块要求：
- 身份鉴别：不共用凭据、不长期持有高权限、定期轮换 → 对应"应对登录的用户进行身份标识和鉴别"“口令定期更换”。
- 访问控制：运行/管理分离、最小权限、限制导出 → 对应"授予用户所需最小权限"“实现颗粒度访问控制”。
- 安全审计：全程留痕、不暴露真实密钥内容 → 对应"应对审计记录进行保护"“应对重要安全事件进行审计”。
四、验收通用四标准
无论哪种接入方式，上线前用这四条过一遍：
- 可用：真实业务连接验证通过，不依赖日志脱敏"假装成功"。
- 可控：账号台账、责任人、审批记录齐全；谁能用、能用什么权限一清二楚。
- 可轮转：按风险分级有轮换计划，轮换基于版本且可回退。
- 可审计：具备轮转记录、禁用/吊销记录、异常事件处理记录，全程留痕。
五、小结
红线的本质就一句话：让凭据"看不见、拆得散、收得回、查得到"。看不见（不落盘不回显）、拆得散（不共用不混岗）、收得回（可轮换可回退）、查得到（全程审计）。守住这四条，凭据治理的安全水位就过了及格线。
关键词：凭据管理 / 密钥管理 / 安全红线 / 最小权限 / 审计追溯 / 等保合规 / 安当SMS / 凭据安全