Keyvaci博客 · 策略 · 2026年8月16日
SSO 覆盖了你的应用，
其余的一切谁来管？
把单点登录推广落地，感觉像是凭据安全这件事已经做完了。实际上更接近只做了一半。一旦泄露最伤筋动骨的那些系统，银行、域名注册商、基础设施的根账户、老旧管理后台，大多根本接不进 SSO。下面是如何治理你的身份提供方看不见的那条长尾。
SSO 够不到的那条长尾
只有当应用会说 SAML 或 OIDC，并且有人真的把它接上时，SSO 才起作用。这个圈子之外，住着单次泄露影响面最大的那些凭据：
- 银行和支付门户，它们很少支持联合身份，而且常常不允许使用个人账户。
- 位于身份提供方之上的那几个元账户：域名注册商、DNS 托管商、运行着你 IdP 的那个云账户。这些一旦失守，SSO 本身就成了攻击者的工具。
- 老旧系统和硬件设备的管理后台：防火墙、打印机、只有一个共享管理员登录的本地部署工具。
- 应急破窗账户，它们被刻意排除在 SSO 之外，好让 SSO 挂掉时你还进得去。
- 机器机密：API 密钥、令牌、服务账户，这是在 AI 智能体时代增长最快的一类。
- 某个团队用一个共享邮箱注册、又从未告诉 IT 的一切东西。
这些东西最后落进聊天记录、电子表格和个人保管库，恰恰是因为官方系统里没有给它们留位置。这不是用户的失误，而是覆盖面上的缺口。
用同样的三条规则治理这条长尾
- 一份清单。 每一条不走 SSO 的凭据都放进共享保管库，并指定明确的负责人。不在保管库里的，就等于在正式意义上不存在，它的审计也就没有人负责。
- 权限对应实际需要，并随人一起离开。 按团队设定保管库角色，绑定到 SSO 所用的同一套目录身份，这样离职流程能一次切断两个世界。
- 每一次显示都是一个事件。 读取银行密码应当要求重新完成一次验证，并落入只可追加的日志，也就是把 SSO 为你的应用带来的那套纪律，用在 SSO 碰不到的凭据上。
是搭档，不是对手
这正是凭据保管库之于 SSO 是搭档而非竞争者的原因。在有联合身份的地方，你的身份提供方治理的是“谁在登录”；在没有联合身份的地方，保管库治理的是“谁持有”，而且它沿用同一套身份，因此入职离职流程依然只有一条。Keyvaci 就是按这个搭档角色设计的：通过你的 Entra ID 登录，用保管库装下 Entra ID 无法联合的一切，再加上零知识设计，让保管库自身永远不会变成新的单点泄露源。