处置顺序比处置速度更重要
凭据泄露的应急处置有一个容易搞反的顺序：很多人先去删掉泄露源——清理日志、删除提交记录、下架页面，然后才开始改凭据。但删除动作不改变凭据仍然有效这一事实，清理期间攻击者仍可正常使用。正确顺序是先让凭据失效，再排查是否已被使用，最后才处理泄露源与复盘。这个顺序也决定了沟通口径：先确认边界，再对外说明。
基本信息
| 适用对象 | 口令、密钥、令牌、证书与连接串的泄露事件 |
|---|---|
| 处置顺序 | 确认范围 → 失效凭据 → 排查滥用 → 清理源 → 加固复盘 |
| 紧急程度 | 由该凭据的权限影响面决定，而非泄露位置 |
| 关键证据 | 认证日志、接口调用记录、主机登录记录 |
| 配合要求 | 涉及客户数据或合规要求时需同步通知相关方 |
处置步骤
- 确认范围：该凭据能在哪些系统使用、权限多大、有效期多长、副本分布在哪里
- 立即失效：能吊销的吊销，不能吊销的改密，同时检查是否有多套副本
- 检查滥用：按时间窗口检索认证与调用记录，确认在泄露期间是否被使用
- 清理源头：日志、仓库、镜像、工单与聊天记录中的明文一并处理
- 补齐防护：分析泄露路径，补齐拦截与检测，避免同类位置再次发生
- 对外沟通：按合规要求与影响范围决定通知对象与时间
止损与排查
止损与排查
passwd svcauto # 口令类凭据：立即改密
sed -i '/^svcauto/d' /home/svcauto/.ssh/authorized_keys # 移除可疑授权公钥
ssh-keygen -lf /home/svcauto/.ssh/authorized_keys # 复核剩余授权项指纹
grep -RIn 'svcauto' /var/log/auth.log | tail -30 # 查该账号的登录记录
grep -RInE 'token|access_key' /var/log/app | tail -30 # 查凭据是否已被使用
journalctl --since '48 hours ago' | grep -i 'denied\|invalid' | tail -20 # 异常认证尝试时间线与动作
| 阶段 | 目标 | 常见失误 |
|---|---|---|
| 0 至 15 分钟 | 确认影响面并通知关键人 | 先清理后处置，凭据仍可用 |
| 15 至 60 分钟 | 让凭据失效并排查滥用 | 只改一处，忽略副本与缓存 |
| 1 至 24 小时 | 清理泄露源与相关副本 | 遗漏镜像、备份与归档 |
| 24 小时后 | 补齐防护并复盘 | 只记录结论未验证改进 |
失效动作要覆盖所有副本：同一凭据常被写入脚本、定时任务、镜像与备份，只改主用位置时旧值仍然可用。可以在失效后主动用旧值发起一次连接做验证，确认它真的不再生效。
怀疑泄露后不要在原通道上继续沟通细节：如果泄露来自被入侵的通道，处置方案本身也会暴露。切换沟通渠道属于应急处置的一部分，同时应注意不要在工单与聊天中再次粘贴凭据。