2026 年 API Key 泄露之后：用 Postgres 日志还原真实访问痕迹

文章讨论 API key 泄露后的两个冲突目标：既要阻止进一步访问，又要保留足够可信的证据来还原该 key 已经触及的范围。建议先创建替代凭证并与仍有效的旧凭证并行部署，确认替代凭证已在生产流量中生效后再吊销泄露 key。调查方面，建议将网关、应用、数据访问和控制面日志整合为一条按 UTC 排序的使用序列，按 key 指纹、请求或 trace ID、认证主体、来源上下文、动作、资源和结果进行关联；爆炸半径应界定为这些记录实际支持的资源与操作集合，而不是凭证理论上可访问的全部资源。

AI推荐理由 这是一篇面向安全事件响应的实操文章，核心新信息是提出 API key 泄露后的处置顺序：先创建替代凭证并与旧凭证并行部署、确认替代凭证已承载生产流量后再吊销泄露 key；调查侧则建议把网关、应用、数据访问和控制面日志合并为一条 UTC 排序的使用序列，按 key 指纹、请求/trace ID、认证主体、来源上下文、动作、资源和结果做关联，并强调爆炸半径应以日志证据实际覆盖的资源与操作为准，而非凭证理论权限。该思路对使用 Postgres 日志做取证有具体可操作性，但内容属于方法论建议，未提供真实事件数据或验证结果，且标题中的 2026 年份不构成已发生事件的证据。