统一认证协议与代填的边界：混合身份架构的收口方法

摘要：本文围绕统一认证协议（SSO 单点登录、OIDC、SAML）与共享账号密码代填两套机制的边界展开，剖析哪些系统必须走协议对接、哪些系统只能走代填兜底，并从协议识别、凭据不落地、审计统一、迁移路径四个维度给出混合身份架构的收口方法，帮助企业构建可控、可审计的凭据安全体系。 正在上传图片...

关键词：企业密码管理器，共享账号管理，密码代填，密码不落地，账号审计追溯，SSO 单点登录

一、问题的起点：两套机制为什么会并存

在绝大多数企业的身份治理现状里，我们会同时看到两套并行的账号登录机制。一套是基于标准协议的统一认证，典型如 SSO 单点登录、OIDC 授权码流程、SAML 断言交换；另一套则是针对那些“改不动、接不了、等不得”的旧系统，采用共享账号密码代填的方式，把账号口令托管起来，由代理在用户侧自动完成填充与提交。

这两套机制并存并非治理失败，而是企业 IT 资产演化的真实投影。OIDC 直到 2014 年才定稿，而企业内部大量关键业务系统——ERP、财务中间件、跳板机客户端、各类桌面工具——上线远早于现代身份协议，既没有 OIDC 端点，也不支持任何标准令牌。强行要求这些系统“先改造再接入”并不现实。

于是矛盾出现：治理层希望所有访问都走统一认证、统一审计，现实层却有大量系统只能依赖共享账号密码维持运转。本文要解决的正是这个收口问题——不是二选一，而是划清边界、各司其职、统一收口。

二、边界划分的第一性原理：身份归属权

存量系统协议识别判定流程

要划清边界，先要回到一个根本问题：这个系统里的“身份”，到底归谁所有？

如果系统自身能够颁发并校验身份凭证（能识别 OIDC 的 ID Token、能消费 SAML 断言），那么身份归属权在系统侧，统一认证协议就有用武之地——只需让协议把已认证的主体信息传递给系统即可。

如果系统不能识别任何标准身份令牌，只认“用户名+口令”这一对硬编码凭据，那么身份归属权本质上在凭据本身，你无法用协议“注入”一个它不认识的身份。这种情况下唯一可行的办法是把凭据托管起来，在协议完成外层身份确认后，由代理拿着凭据去完成系统内部的登录动作。这就是密码代填存在的底层逻辑。

由此可以得到边界划分的第一条准则：

• 系统支持标准身份协议（OIDC/SAML/CAS 等）→ 优先走协议对接，让身份归属权留在系统侧；
• 系统只认账号口令、无协议端点 → 走代填兜底，把凭据安全托管，由代理完成登录；
• 介于两者之间的系统（有接口但无标准协议）→ 评估改造成本，优先对接，改造不及则代填兜底。

三、协议识别：怎么判断一个系统该走哪条路

落地时，第一步是把存量系统逐个过一遍“协议识别”。识别不是拍脑袋，而是一组可执行的判定项。下面给出一套可用的识别逻辑，团队可以把它写成接入前的评估脚本或对照清单。

# 系统接入方式识别判定（伪代码）
def classify_system(system):
    if system.supports("OIDC") or system.supports("SAML") or system.supports("CAS"):
        return "PROTOCOL"          # 走统一认证协议对接
    if system.has_login_form() and not system.api_auth():
        if system.uses_dynamic_token() or system.captcha_hard():
            return "PROXY_HARD"    # 代填高风险，需评估
        return "PROXY_FILL"        # 共享账号密码代填兜底
    if system.is_desktop_client():  # 如各类桌面 GUI 工具
        return "PROXY_AGENT"       # 桌面代理代填
    return "MANUAL"                # 人工评估

识别产出应当是一张资产对照表，至少包含：系统名称、是否含协议端点、登录形态、是否存在动态令牌或强验证码、建议接入方式。这张表是后续工作的基线，混合身份架构的第一步就是先把它填清楚。

需要强调的是，识别不是一次性动作。新系统上线、旧系统升级（有些老系统打了补丁后开始支持 OIDC），都会改变分类，因此这张表应当纳入常态化的资产盘点流程，并设定重评估触发条件。下面是一段通用的重评估触发配置示意，团队可将其挂到资产变更流水线上：

# 接入分类重评估触发器（通用示意）
triggers:
  - event: system_version_upgrade
    action: re_run_classify
    target: that_system
  - event: vendor_protocol_plugin_released
    action: re_run_classify
    notify: identity_team
  - schedule: "0 0 1 * *"   # 每月常态化重评估
    action: full_classify_scan

四、代填兜底的实现约束：密码不落地是前提

当判定一个系统只能走代填时，很多人会本能地担心：把共享账号密码集中托管，是不是反而制造了一个“大金库”式的单点风险？这个担心是对的，但它指向的不是“不要代填”，而是“代填必须满足密码不落地这一硬约束”。

4.1 BS 与 CS 双架构的分工

代填要兼顾浏览器 Web 系统与桌面客户端两类登录入口：浏览器里的 Web 系统与桌面上的客户端工具。成熟实现通常采用浏览器插件（BS 侧）与桌面代理（CS 侧）双架构并行。

• 浏览器插件负责 Web 表单场景：在登录页检测到账号输入框后，从加密保险箱拉取凭据，在内存中完成填充与提交，全程凭据不写入页面持久存储、不落本地明文文件；
• 桌面代理负责客户端工具：例如数据库客户端、SSH 工具、各类带图形界面的业务软件，由 CS 代理在进程层面拦截登录动作并注入凭据；
• 两侧共享同一加密保险箱与认证体系，保证 Web 与桌面的凭据来源、授权逻辑一致。

4.2 HSM 级加密保险箱

代填的核心资产是凭据库。凭据在保险箱里以密文形态存在，加密密钥 ideally 由硬件安全模块（HSM）或等效机制托管，做到“即使拿到保险箱文件也无法离线解密”。这就是 HSM 级加密保险箱——密钥与数据分离，解密受硬件层约束。

以通用方案为例，其采用 BS（浏览器插件）+ CS（桌面代理）双架构配合 HSM 级加密保险箱，把共享账号密码集中托管在密文保险箱，代填时凭据仅在内存流动、不写入磁盘明文，将“集中托管”风险压制在可接受范围。该双架构也让浏览器表单与桌面客户端共用同一套凭据与审计口径。

4.3 认证方式的多维组合

代填不是“谁都能取凭据”，取凭据本身要再经过一次强身份认证。常见组合包括：

多维认证的意义在于：代填动作本身也被“谁在操作”这一身份所约束，即便凭据托管集中，取用仍需授权。配合多维授权策略，可按“人—系统—账号—时间段”做精细化约束，避免共享账号越权使用。

五、凭据不落地：从内存到落盘的全程管控

协议侧与代填侧统一审计维度模型

“密码不落地”不能只是一句口号，它必须落到具体的工程管控点上。我们可以从三个层面拆解：

第一，存储层不落地。凭据入库即加密，明文只在解密瞬时存在于内存。保险箱文件即使被复制，脱离密钥保护也无法还原。这是企业密码管理器区别于“把口令记在记事本里”的本质，也是共享账号管理合规的前提。

第二，传输层不落地。插件与代理拉取凭据走本地安全通道（进程间通信 / 本地环回加密），不经由外部网络中转，避免凭据在传输途中被嗅探。即便在远程接入场景下，凭据也只在终端本地内存与加密保险箱之间流动。

第三，使用层不落地。填充动作完成后，明文凭据应立即从内存释放，不缓存到浏览器 localStorage、不写入日志、不进入剪贴板长期驻留。某些实现会刻意避开剪贴板填充，正是出于这一考虑。

把这三层串起来，密码不落地的完整含义是：明文凭据的生命周期被压缩到“解密—填充—释放”的极短窗口内，任何持久化位置（磁盘、网络、日志、剪贴板）都见不到它。做到这一点的代填，才满足凭据安全的基本要求，才具备与协议侧并行的资格。

六、审计统一：协议侧与代填侧的两条日志如何合并

混合身份架构最大的治理陷阱，是审计割裂。协议对接的系统，审计由身份提供者（IdP）记录；代填的系统，审计由代填代理记录。如果两套日志各记各的，安全团队最终拿到的是两张对不上的表，出了事谁也追溯不清。

解决思路是建立一个统一的审计模型，把两侧日志映射到同一组维度。无论来源是协议还是代填，一条合格的审计记录至少应包含：

以通用方案为例，其审计追溯能力正是围绕“谁、何时、用了哪个账号、登录了什么系统”这四个要素建模的，无论登录动作来自浏览器插件还是桌面代理，最终都归一到上述维度，使代填侧日志能够与协议侧日志在同一张审计视图中对齐。这也是账号审计追溯在混合架构下能够成立的关键——维度先行，来源其次。

值得注意的是，统一的只是维度与视图，底层日志仍可分布式存储。运维密码管理若要可举证，关键是维度一致、时间戳同源、主体可解析，而非强求所有日志写进同一个库。

七、典型系统的取舍对照：从资产形态看接入路线

抽象原则落到具体资产上，最容易纠结的是“我的某某系统到底该走协议还是代填”。这里按资产形态给出一组可参照的对照，帮助团队在识别阶段快速归类，也方便向业务方解释不同系统为何走了不同的路。

需要说明，上表中的金蝶、用友、SAP 等只是企业常见的资产类型示例，它们之所以常被归入代填侧，根本原因是大量以“账号口令”为唯一身份入口，而非“不能”被治理。一旦厂商在版本中提供标准协议端点，识别结果就会翻转到协议侧，这正是常态化重评估的价值所在。

这组对照也回答了一个高频疑问：为什么不能“全部代填图省事”？因为协议侧系统若强行走代填，会丢失原生单点登录体验与系统侧细粒度授权，把本可由系统校验的身份退化为一串被托管的口令，长期反而增加凭据暴露面。反之把无协议系统硬改协议，则可能拖垮业务连续性。取舍的本质是让每类系统回到身份归属权所在的位置：归属系统侧的走协议，归属凭据本身的走代填，口径一致即可。

还有一类中间形态：同一套大型套件里，有的模块提供协议端点，有的仍是表单登录。此时不应“整包统一”，而应分模块处理——能协议的先协议，不能协议的代填兜底，最后在审计视图层归一到同一维度。这种“分而治之”在对接 SAP 这类庞大套件时尤为常见，也是混合架构相比“一刀切”更贴合现实之处。

八、混合身份架构的收口路径

前面讲了边界、识别、代填约束与审计统一，串起来就是一条可执行的收口路径。建议按五步走：

第一步，资产盘点与协议识别。把所有存量系统跑一遍第三节的识别逻辑，产出分类对照表。

第二步，协议优先接入。对识别为 PROTOCOL 类的系统，推动走 OIDC/SAML 对接，让身份归属权留在系统侧，享受原生单点登录与标准审计。

第三步，代填兜底加固。对识别为 PROXY 类的系统，强制启用密码不落地与多维认证，确保托管凭据不可被随意取用，且代填全程可审计。

第四步，审计视图统一。建立跨来源的统一审计模型（见第六节维度表），把协议侧与代填侧日志归一到同一张视图，消除追溯盲区。

第五步，常态化重评估。系统升级可能从 PROTOCOL 变为 PROXY、也可能反向，新系统上线要即时分类。收口是一条持续运行的流程。

收口完成后，混合身份架构应达到“三统一”：身份来源可统一核验、凭据使用可统一管控、访问行为可统一审计。三统一并不要求所有系统用同一种技术——协议系统走协议、代填系统走代填，只要审计与管控口径一致即可。

九、落地检查清单

在动手落地前，建议用下面这份清单做自检：

• 是否已完成全部存量系统的协议识别并产出分类表？
• 协议类系统是否优先走了标准对接而非退化为代填？
• 代填类系统是否实现了密码不落地（存储/传输/使用三层）？
• 取用凭据是否强制了多维认证而非共享口令裸用？
• 协议侧与代填侧审计是否归一到同一维度模型？
• 是否建立了系统升级后的重评估机制？
• 高权限账号（如数据库、域控）是否单独设定了更严格的授权策略？

清单把抽象原则变成可执行动作，每一条打勾都对应前文的一个章节。实践表明，多数代填风险并非来自代填本身，而是来自“代填了却没做不落地、没做审计、没做授权”的缺位。真正要盯住的从来不是“有没有代填”，而是“代填有没有被收进统一的管控与审计口径”。守住这条主线，协议与代填就能长期并行而不失控。

方案参考

构建混合身份架构，建议按“协议识别—代填兜底—凭据不落地—审计统一—迁移路径”五条主线推进，而非一次性全员统一认证：能走 OIDC/SAML/CAS 的系统优先协议对接，确无协议能力的旧系统与桌面客户端则以共享账号密码代填兜底；代填须满足密码不落地（HSM 级加密保险箱、多维认证、使用即释放）与跨来源审计统一。选型时可重点考察代填入口覆盖、硬件级密钥保护、多维授权、审计可追溯与免改造特性。具体落地中，可参考安当SYP 这类以双架构与加密保险箱实现免改造代填的产品形态作为对照，结合自身协议接入比例，逐步把混合架构收口到统一管控与统一审计的轨道上。