淘汰长期静态凭证：仅8.4% SaaS厂商支持安全认证

一家安全团队在调查了 1,000+ 家 SaaS 厂商后抛出一个刺眼的数据：只有 8.4% 的厂商支持安全认证方式。他们由此发出呼吁——是时候淘汰长期存活的静态凭证了。

这不是又一篇泛泛而谈的安全倡议。它把问题指向了一个具体、可量化、且长期被容忍的行业惯例。

8.4% 背后的真相：静态凭证为何成为默认选项

静态凭证（长期有效的 API Key、固定密码、永不过期的 Access Token）之所以流行，原因很朴素：它对厂商和用户都最省事。厂商不需要搭建 OAuth 流程、不需要处理短期令牌的刷新与吊销；用户复制粘贴一个字符串就能接入。

省事的代价是风险的长期沉淀。一个永不过期的密钥一旦泄露——无论是在代码仓库、日志、截图还是第三方工具里——攻击者就获得了几乎永久有效的入口。轮换（rotation）在理论上可以缓解，但在实践中，大量团队根本没有自动化轮换机制。

据该调查团队的结论，支持安全认证的厂商占比之低，说明这已经不是个别厂商的疏忽，而是整个 SaaS 生态的系统性短板。

API Key 与 Access Token 的区别值得澄清：API Key 通常是长期有效的字符串，用于标识调用方身份，往往不具备细粒度权限控制，也难以单独撤销；而 Access Token 是 OAuth 流程中颁发的短期凭证，通常带有明确的过期时间和作用域（scope），可被授权服务器随时吊销。文章所指的"静态凭证"主要对应前者，以及那些被当作长期密码使用的固定 Token。二者在泄露后的影响半径差异巨大：静态凭证泄露后攻击者可持续访问直至人工发现并轮换，而短期令牌的暴露窗口通常以分钟或小时计。

凭证轮换（Rotation） 指定期或按事件触发更换密钥/令牌的机制。理想的轮换是自动化的：密钥管理系统生成新凭证、更新所有依赖方、作废旧凭证，全程无需人工介入。实践中轮换难以落地，往往是因为凭证被硬编码在多个应用、脚本和 CI 配置中，缺乏统一的引用入口，导致"换一次要改几十处"。这也是密钥管理设施（如 HashiCorp Vault、云厂商的 Secrets Manager）被推崇的原因——它们把凭证从代码中抽离，使轮换成为集中操作。

安全认证的差距在哪

“安全认证”在这里并非玄学，它对应一系列相对成熟、有标准可循的机制：

• 短期令牌与自动过期：凭证有明确的生命周期，到期即失效，缩小泄露窗口。
• OAuth 等授权框架：以授权代替密码共享，权限可精细控制、可随时撤销。
• 密钥轮换与吊销能力：系统层面支持批量、自动化地更换和作废凭证。
• 最小权限原则：凭证只授予完成特定任务所需的最小范围。

8.4% 这个数字意味着，绝大多数厂商在上述能力的支持上仍存在明显缺口。对使用方而言，这意味着接入多个 SaaS 服务时，往往被迫接受“一把长期钥匙开所有门”的现状。

OAuth 2.0 是当前授权框架的主流标准，其核心思想是"授权代替密码共享"：用户或系统不把密码交给第三方应用，而是通过授权服务器颁发一个限定范围、限定有效期的 Access Token。OAuth 还配套定义了 Refresh Token 机制，让短期令牌可以续期而无需重新走完整授权流程；以及 Token Revocation 端点，使授权方可随时作废令牌。对 SaaS 厂商而言，支持 OAuth 意味着要承担授权服务器、令牌生命周期管理、scope 设计等工程成本，这正是许多厂商选择"发一个永久 API Key 了事"的现实原因。

最小权限原则（Principle of Least Privilege） 要求每个凭证只拥有完成其既定任务所必需的最小权限集合。在静态凭证模式下这一原则很难落实：一把长期 API Key 往往被赋予账户级全量权限，因为厂商没有提供更细粒度的权限模型。一旦泄露，攻击者获得的就是该账户的全部能力。相比之下，OAuth 的 scope 机制天然支持按需授权，使最小权限从"建议"变为"可实现"。

为什么“淘汰静态凭证”是行动号召而非口号

该团队将这条调查结果定位为 call to action，并强调“how we're doing our part”——他们自己在以身作则。这一点值得注意：安全倡议最容易停留在指责厂商，但真正推动改变的是需求侧的施压和使用侧的示范。

从行业分析角度看，静态凭证的淘汰需要三方合力：

1. 厂商侧：把短期令牌、OAuth、自动化轮换作为默认能力，而非付费增值项。
2. 使用侧：在采购和集成评估中把认证安全性作为硬性门槛，而不是事后补丁。
3. 工具生态侧：让密钥管理、扫描与轮换工具足够易用，降低“安全 = 麻烦”的摩擦成本。

这项调查的价值在于提供了一个可追踪的基线。8.4% 是一个起点，后续是否上升，将成为衡量 SaaS 生态安全成熟度的直观指标。

Call to Action 在安全研究语境中通常指研究者不止于披露问题，而是明确提出行动诉求并给出可执行路径。这类倡议的有效性依赖于"可量化基线"——一个具体的百分比或计数，让问题从模糊的"很多厂商不安全"变成可对比、可追踪的指标。8.4% 之所以有传播力，正因为它是可复现的调查结果，后续任何机构都可以用同样口径复测，形成行业进步的度量尺。

需求侧施压（Demand-side Pressure） 是安全生态演进的常见杠杆：当采购方在合同和选型评估中把"是否支持 OAuth/短期令牌"列为硬性条件时，厂商的改造动力会比单纯的安全呼吁强得多。历史上 TLS 普及、多因素认证推广，都经历过从"可选加分项"到"准入必选项"的转变，静态凭证的淘汰大概率也会沿这条路径推进。

对开发者和企业的现实建议

在生态整体改善之前，使用方并非无事可做：

• 盘点现有集成中的长期凭证，优先处理权限过大、长期未轮换的那些。
• 在代码仓库和日志中排查硬编码密钥，把凭证移入专门的密钥管理设施。
• 在选型时主动询问厂商是否支持短期令牌与 OAuth，把答案纳入决策依据。
• 为可自动化的轮换建立流程，减少对人工操作的依赖。

安全认证的普及不会靠一次调查完成，但把“只有 8.4%”这样的数字摆到台面上，是让行业无法继续假装问题不存在的第一步。