先判断凭据类别，不在工单里复制秘密
Stripe 将服务端秘密 API 密钥与可嵌入网页或应用的公开密钥区分开来，要求秘密密钥留在服务端；其文档把出现在不该出现的位置称为暴露，把存在未授权使用证据称为被利用。[1] 因此，发现代码片段、错误页或构建日志中出现疑似秘密时，不要等到查出异常交易才处理。建议先记录供应商、账户、测试或生产环境、密钥标识、发现时间与受影响服务，不复制完整密钥到聊天或工单。本文处理的是商户获授权管理的 API 凭据，不是钱包私钥、助记词或链上资产恢复教程。
暴露后的第一步是止损，不是清理截图
Stripe 明确要求秘密或受限 API 密钥一旦暴露或疑似泄露就立即轮换，即使不确定是否有人看见；它也不保证检测到所有暴露或被利用的密钥。[1] 删除一个仓库提交或隐藏日志页面并不能替代这一步。建议由有权限的值班人员按实际供应商流程使旧凭据失效并供应新凭据，同时通知负责业务连续性的人。如果需要临时停用依赖该凭据的操作，应明确影响范围和恢复条件，不为了避免短暂失败而无限延长已暴露密钥的可用期。不要把常规轮换的便利流程直接当成泄露时的风险判断。
用使用方清单找出被遗忘的定时任务
以下清单是编辑建议，而不是厂商自动发现功能：逐项列出结账服务、后台工作进程、定时查询任务、财务导出任务、运维脚本及有授权的第三方集成。每项记录负责人、读取密钥的位置、是否进程启动时缓存、加载新版本的方法和验证动作。只填配置引用或密钥标识，不填秘密值。尤其确认低频任务；前台结账恢复并不能证明每晚运行的查询也已换钥。测试和生产清单分别维护，避免用生产凭据验证测试服务。找不到负责人的使用方应进入待处理列表，而不是默认为已完成。
新凭据应缩小权限，并留在秘密管理系统
Stripe 建议通过平台的秘密管理工具供应凭据；平台没有秘密库时才使用环境变量，同时警告不要在错误页或广泛开放的诊断界面暴露环境变量。其受限密钥可按应用组件分配所需权限。[1] 建议根据真实调用清单为每个服务评审最小权限，把读取报表与修改支付状态的需要分开。不要声称环境变量本身就构成完整防护，也不要把 Stripe 的权限粒度移植成其他供应商的功能承诺。轮换记录应保存谁批准、谁执行、哪个配置版本生效，而不是新旧秘密的内容。
验证三个结果：新钥可用、旧钥失效、后台恢复
这是建议的验收顺序，不是本文已经完成的生产测试。先让各使用方通过正常配置路径加载新凭据，再在授权环境执行所需的低风险读取或沙箱动作，确认权限够用且没有多余权限。随后使用供应商支持的状态核查或受控认证测试，确认旧凭据已不可用；不要为了证明这一点向真实客户发起扣款。最后检查长驻进程与低频任务是否仍出现认证失败。记录时间、服务名、配置版本和结果即可。若某操作超时，先查询既有操作结果，不以反复创建支付来判断网络是否恢复。
回滚应用版本，不回滚到已泄露凭据
建议把恢复预案分成应用恢复与凭据恢复两条线。代码回滚时必须继续使用已审核的新秘密配置，否则旧镜像或旧任务定义可能重新注入失效或已暴露的值。若新权限不足，应核对必要权限或申请另一个受控替代凭据，不把恢复旧密钥作为默认捷径。Stripe 建议定期审查 API 请求日志以发现滥用。[1] 调查时保留必要的访问时间、来源、操作类型与异常结果，限制证据的访问；是否存在未授权交易应由记录和供应商调查支持，不能仅凭没有用户投诉就宣布没有影响。
交接单怎样才算可以关闭
建议用一份不含秘密的交接单完成收尾：暴露入口已关闭；受影响凭据已失效；每个使用方的新配置已验证；后台任务的下一次运行已检查或有明确后续责任人；日志调查范围与尚未确认的影响已写明。只验证了结账服务时，应写“后台任务待验”，不能写“全部恢复”。Stripe 建议预先制定并演练轮换流程，定期轮换有助于确认每把钥匙在哪里使用及能否及时替换。[1] 演练应先在非生产环境进行。本指南是文档研究与编辑建议，不是事故响应服务、真实渗透测试结果或对某支付系统安全性的保证。
来源与日期
本次核验日期：2026-09-20。来源日期指原页面明确标注的更新时间；未标注不等于本日发布。本文为公开文档研究，未进行真实支付、安全审计或辅助技术合规认证。厂商事实仅归属于被引用厂商；流程建议为编辑综合。