题目
客户经常因 API key 长期不轮换而暴露风险。请评估是否推出凭证轮换控制台，覆盖目标用户、最小可行范围、双凭证迁移、审计与成功指标。
场景与约束
平台同时有个人 key、团队 key 和服务令牌；客户把凭证放在 CI、云函数和本地环境。部分系统无法同时保存两把 key，部分管理员没有读取秘密值的权限。轮换必须可暂停、可回滚且不显示完整秘密。
核心考点
考察能否把安全能力转成可采用的产品流程。Stripe 将 key 创建、过期和轮换作为生命周期能力；Cloudflare 提供服务令牌轮换动作；GitHub push protection 说明预防泄露和处理绕过请求都需要明确责任边界。
参考解法
先按凭证类型和客户部署方式分层。MVP 提供到期提醒、拥有者与作用域、轮换预览、创建新凭证、短暂重叠、验证新凭证、撤销旧凭证和审计事件；默认只显示前缀、创建时间和最后使用时间。对不能双凭证运行的客户，提供暂停撤销、导出迁移清单和人工确认，而不是自动失效。
关键细节
轮换流程要有幂等操作和状态：预览、创建、验证、激活、撤销。定义最短重叠时间、未使用旧 key 的提醒和异常回滚；通知对象包括拥有者、管理员和安全团队。指标包括轮换完成率、到期凭证数、因轮换导致的失败请求、平均迁移时间和撤销后残余使用量。
常见误区
强制所有 key 同日轮换；在界面显示完整秘密；把最后使用时间当成绝对准确；只做提醒不提供迁移路径；忽略权限委托、服务账号和跨区域缓存。
评估标准
优秀答案能明确风险分层、MVP 边界、双凭证与单凭证两种路径、权限和审计设计，并用失败率与轮换完成率验证价值。一般答案只说“增加一个轮换按钮”。
追问
客户要求平台自动替换其 CI 秘密，你会承诺吗？
先确认集成范围和授权，优先提供短期双凭证、验证和回滚；无法确认写入成功时不撤销旧凭证，并把人工确认作为明确状态。
如何处理发现 key 可能泄露的紧急情况？
将紧急撤销与计划轮换分开，提供影响范围、最后使用时间和替代凭证创建；撤销前显示不可逆后果，并通过审计和通知记录决定。
如何防止轮换控制台本身成为秘密泄露面？
采用最小权限、一次性显示、短期操作令牌、敏感字段脱敏和完整访问审计；把秘密值留在受控存储，界面只处理标识与状态。