敏感配置如何管理？
简化版
数据库口令、API Token、私钥等不应像普通配置一样明文存储、展示和广播。 更推荐在配置中心保存 secretRef，由专门秘密管理系统提供加密存储、工作负载身份鉴权、短期凭证、轮换和审计。 确需保存密文时也要使用 KMS 信封加密、严格授权和服务端脱敏，并避免密钥与密文处在同一边界。
详细版
先盘点并分类敏感数据，执行最小权限：能编辑普通配置不代表能读秘密，应用只能获取自身运行所需的项。 传输使用 TLS，静态存储采用由 KMS 管理的数据密钥；日志、diff、通知、版本上报和审计不得包含明文。
轮换采用新旧凭证短暂并存：先让服务端接受新凭证，再更新消费者并验证，最后撤销旧凭证。 泄露处置优先撤销和轮换，不能只删除日志。 敏感值不适合长期本地明文快照，缓存和内存生命周期也要受控。
完整版教学
一、先界定什么是秘密
口令、私钥、访问令牌、证书私钥和第三方凭证属于秘密。 数据库地址、线程数等普通配置即使重要，通常不是秘密。 分类决定存储、展示、授权、轮换和审计强度。
加密不是终点；身份、最小权限、轮换和不泄露明文共同构成秘密治理。
二、优先保存引用
配置中心保存逻辑引用，应用凭工作负载身份向秘密系统获取实际值。
database:
passwordRef: secret://prod/order-db/password#current这样普通配置审批人不需要看到口令，秘密系统可独立轮换和审计。 引用解析失败时应失败关闭相关能力，不能回退到代码中的共享默认密码。
三、确需存储时用信封加密
随机数据密钥 DEK 加密秘密，KMS 主密钥 KEK 再加密 DEK。 存储系统保存密文、加密后的 DEK、算法和密钥版本。 解密服务根据身份和上下文向 KMS 请求，不把 KEK 放入应用配置。
| 层次 | 保护对象 | 控制 |
|---|---|---|
| TLS | 传输中数据 | 双向认证可选 |
| DEK | 单个秘密 | 随机、可轮换 |
| KMS KEK | DEK | 独立权限与审计 |
自制加密算法或把固定 AES key 写在同一数据库里没有形成有效边界。
四、权限要区分动作
权限至少分为创建、更新、引用、运行时读取、明文读取、轮换和审计。 控制台管理员不应默认拥有生产秘密明文读取权。 应用身份限定环境、租户和资源路径，并使用短期凭证。 紧急明文访问要求强认证、短时授权、理由和告警。
五、全链路防泄露
服务端在返回前脱敏，不能把明文发给浏览器再靠前端遮盖。 日志、异常、APM 标签、消息队列、diff、搜索索引和备份都要检查。 客户端不得打印完整配置，崩溃转储和诊断接口需限制访问。 摘要也可能泄露低熵秘密，应使用带密钥的指纹或仅记录版本 ID。
六、轮换的正确顺序
假设旧凭证 A 将替换为 B。 先让提供方同时接受 A/B，再发布消费者使用 B，确认所有实例收敛，最后撤销 A。 直接先撤销 A 会让尚未更新的实例全部失败。 证书、数据库用户和第三方 Token 的具体双凭证能力不同，需要预先设计。
七、泄露响应与观测
发现泄露后确定影响范围，立即撤销或轮换，审计访问记录并修复泄露渠道。 从 Git 或日志删除明文不能使已复制的凭证失效。 监控解密失败、异常读取、跨环境访问、旧版本使用和轮换收敛。 定期扫描仓库与配置存储，但扫描结果本身也要保护。
八、常见误区与追问
- 误区：数据库加密就能让管理员随意看明文。 授权和审计仍必须最小化。
- 误区：前端显示星号就是脱敏。 明文不应先到浏览器。
- 误区：Base64 是加密。 它只是编码，任何人都能还原。
- 误区：泄露后删掉配置即可。 必须撤销或轮换凭证。
- 追问：为何更推荐 secretRef？ 它分离配置治理与秘密生命周期，减少明文暴露。
- 追问：轮换如何不中断？ 提供方短暂接受新旧凭证，消费者收敛后撤销旧值。
- 追问：本地缓存怎么办？ 尽量不持久化秘密，确需缓存则加密、限权并缩短生命周期。
九、加强记忆
- 先分类秘密，普通配置与秘密分开治理。
- 优先保存引用，由专门秘密系统提供明文。
- 必须存储时采用 KMS 信封加密和独立权限边界。
- 明文不进入界面、日志、diff、审计和版本上报。
- 轮换先兼容新旧、再迁移、最后撤销；泄露后必须让旧凭证失效。