代理密码长期不换，泄露风险会不断累积；直接把旧密码改掉，又可能让仍在运行的应用全部报407。要兼顾安全与可用性，关键不是“挑个半夜改密码”，而是先弄清服务是否支持双凭据、哪些系统在使用，以及旧连接何时真正结束。
本文面向企业自有和经授权系统的认证管理。不同代理服务支持的子账号、令牌和密码修改方式不同，执行前以平台当前能力为准。
一、先盘点凭据在哪里被使用
| 位置 | 常见形式 | 检查重点 |
|---|---|---|
| 服务器应用 | 环境变量、配置中心、密钥服务 | 部署版本与重启方式 |
| 桌面客户端 | 本地配置、系统凭据库 | 是否自动同步到其他设备 |
| 浏览器 | 扩展或保存的认证 | 个人设备和已离职人员 |
| CI/CD | 流水线变量、项目密钥 | 分支、环境和日志脱敏 |
| 路由设备 | VPN或代理客户端配置 | 是否支持热更新与回退 |
| 文档/聊天 | 历史粘贴和截图 | 发现明文后按泄露处理 |
没有完整使用清单，就无法判断撤销旧凭据会影响谁。团队场景应先建立代理节点台账与权限交接流程；若发布后的文章ID不同，可按标题查找。
二、最稳妥的是双凭据过渡
如果平台支持同时存在两个子账号、令牌或密码版本，可采用：
- 保留旧凭据A，创建权限相同的新凭据B；
- 在测试环境验证B的协议、认证和出口；
- 逐批把应用配置从A切到B；
- 观察407、连接失败和业务指标；
- 确认所有使用点均完成后，撤销A；
- 检查撤销后是否还有旧凭据尝试。
双凭据窗口应尽可能短，并有明确结束时间。长期保留两个有效凭据只会扩大攻击面。
三、不支持双凭据怎么办
如果服务只能直接修改密码，应安排维护窗口，并提前：
- 停止或排空非关键任务；
- 把新配置安全分发到待发布版本；
- 准备能够快速回退的旧配置，但不要长期明文保存；
- 明确修改、部署、验证和回退负责人；
- 通知受影响业务，设置故障升级通道。
修改后按优先级快速更新关键系统，再更新低风险客户端。无法及时更新的设备应断开，而不是继续无限重试旧密码。
四、为什么切换配置后仍然看到旧凭据
应用可能继续使用已有连接池，部分代理只在建立新连接时认证。配置中心显示新值，不代表进程已经重新加载，也不代表长连接已结束。
轮换时要确认：
- 应用是否支持热加载；
- 旧TCP和HTTP长连接的最大寿命；
- 任务队列中是否有运行中的长任务；
- 是否需要新建客户端会话或滚动重启；
- 连接池排空是否会导致重复提交。
旧出口与连接复用原理可参考代理连接池为何继续使用旧配置。
五、分批发布比一次全改更容易回退
先让少量测试实例使用新凭据，确认认证成功、出口正确、延迟和错误率没有异常；再逐步扩大比例。每一批都要有停留观察时间，并能回退到上一版本。
写操作应使用幂等键或业务去重，避免滚动重启和重试造成重复订单或数据。
六、轮换期间监控哪些指标
- 407认证失败数量和来源应用；
- 代理连接成功率与连接耗时；
- 新旧凭据的认证请求数量；
- 业务成功率、队列积压和超时；
- 出口IP是否符合预期；
- 部署版本、配置版本和回退次数。
日志中只记录凭据版本ID，例如 proxy-cred-v2，不要输出用户名、密码、Authorization或完整代理URL。
七、什么时候可以撤销旧凭据
至少满足：
- 台账中的所有使用点已更新；
- 旧连接的最大寿命已经过去；
- 监控中旧凭据调用降为零；
- 关键业务完成一个完整观察周期；
- 回退方案已经改为新凭据版本；
- 业务和安全负责人确认撤销。
撤销后继续监控一段时间。若仍出现旧凭据认证，说明存在未登记系统、离线设备或泄露副本。
八、怀疑密码泄露时不要按普通轮换处理
泄露应急更强调快速止损：
- 立即确认泄露范围和时间；
- 必要时先停用受影响凭据或限制来源IP；
- 创建新凭据并恢复关键系统；
- 检查异常连接、地区、时间和业务操作；
- 清理Git历史、日志、工单和聊天中的副本；
- 按企业事件响应流程通知并复盘。
如果完整代理URL进入公开仓库，即使随后删除文件，也应视为已经暴露，因为历史和缓存仍可能保存内容。
九、来源IP白名单也要一起轮换吗
密码与来源白名单是不同认证因素。服务器迁移或办公出口变化时，要采用“先添加新出口并验证，再撤销旧出口”的顺序。若同时改密码和白名单，会增加排障变量，最好拆成两个有记录的变更。
十、轮换频率如何确定
不要机械套用固定天数。应结合凭据权限、共享人数、供应商能力、人员流动、合规要求和泄露风险制定。人员离职、供应商变更、明文暴露或异常认证发生时，应触发事件型轮换。
好的轮换流程最后应能回答：哪些系统已经更新、旧连接何时结束、旧凭据何时撤销、如果失败如何回退。只有密码变了但台账和监控没变，并不能算完成。
