在企业数字化走向深水区的今天身份已经取代网络边界成为安全的第一道闸门。过去我们习惯用防火墙、入侵检测来构筑外围防线但无数真实的安全事件告诉我们攻击者一旦拿到一个合法账号外围防线几乎形同虚设。因此统一身份认证平台IAM成为现代企业安全架构里无法绕开的一环。很多信息化负责人在百度搜索统一身份认证方案时真正想确认的不是某个产品罗列了多少功能点而是它能不能在自己的网络环境、合规要求和信保进度下真正跑起来。这正是本文要把选型从看参数拉回到看维度的原因。参数会过时维度相对稳定参数容易被销售包装维度则可以逐条打分、逐条追责。选型维度的价值在于可量化、可对照、可追责。当我们在采购评审会上被问到为什么选这家而不是那家时能够拿出的不应该是销售话术而应是一张逐维度打分的对照清单。本文围绕协议栈覆盖、国密合规、信创适配、场景覆盖、模块闭环、部署弹性六个维度展开并给出一张可以直接打印贴在评审会上的能力对照表帮助团队把模糊的感觉不错转化为确定的满足或不满足。一、为什么选型要从维度出发企业在做身份认证平台选型时常犯的错误是把选型会变成功能点的堆砌比赛。A 厂商说支持二十种协议B 厂商说支持五十种于是采购方陷入数量焦虑。但真实世界里一个组织真正用得上的协议往往不超过七种剩下的大多是营销噱头。更健康的做法是先定义自己的维度再拿着维度去对照厂商。维度来自三个源头监管合规要求等保、密评、行业规范、自身技术栈操作系统、目录服务、业务系统类型、未来三到五年的演进路线信创替代、云化、无口令化。把这三个源头拆成可打分的维度选型就不再是玄学而是一张可以复盘的工程表。这里要特别区分能力清单与参数清单。参数清单回答的是有没有能力清单回答的是在我们场景下能不能用、用得好不好。比如同样是支持国密有的只是在登录页放一个 SM2 证书上传框有的则实现了从证书签发、握手协商到日志签名的全链路国密。只看参数两者都算满足用能力清单对照高下立判。二、维度一协议栈覆盖能力统一身份认证平台的生命线在于它能不能和现有系统说上话。如果一个平台只支持私有协议那么接入每一套业务系统都要定制开发成本会指数级上升。企业在百度搜索单点登录SSO时本质上是在寻找一套能覆盖主流标准协议的接入能力而不是某个厂商的自创协议。值得纳入对照清单的协议包括SAML2.0这是企业应用与云应用联邦身份的事实标准常用于打通内部办公系统与第三方 SaaS它的优势在于生态成熟、跨域信任模型清晰。OAuth2.0适合第三方授权与开放接口场景是移动端与开放平台的事实底座。OIDC建立在 OAuth2.0 之上的现代身份认证层用身份令牌替代了繁琐的会话维护是当下 Web 与移动端的主流选择。LDAP几乎所有 Directory 类系统的接入基座也是用户目录同步的纽带没有它就无法和既有账号体系对接。RADIUS网络设备与远程接入认证不可替代的协议交换机、路由器、无线控制器都依赖它完成接入校验。FIDO2 与 WebAuthn代表无口令认证的发展方向用硬件信任根替代密码是抵御钓鱼攻击的关键技术。对照时建议逐项确认是否原生支持、是否需要额外插件、是否支持自定义属性映射、是否支持断言加密与签名校验、是否支持跨域单点退出。很多项目在对接阶段才发现所谓支持只是有限兼容导致工期延误。以安当ASP为例其协议栈同时覆盖 SAML2.0、OAuth2.0、OIDC、LDAP、RADIUS、FIDO2 与 WebAuthn这意味着从传统堡垒机到现代云原生应用都可以在不改造业务代码的前提下完成接入显著降低集成风险。这种协议面全、接入成本低的特性正是把它放进能力清单第一维度的原因。三、维度二国密合规与等保要求金融行业、政务行业与关键信息基础设施运营者在选型时几乎都会卡在国密与等保这两道硬门槛上。国密算法 SM2 用于非对称加密与数字签名SM3 用于摘要哈希二者共同构成合规的密码学底座。一个平台如果只支持国际算法而不支持国密在等保2.0 三级及以上的测评中将难以通过甚至可能触发密评不合格直接影响业务上线。对照清单建议记录以下检查项是否支持 SM2 证书登录、是否支持 SM3 摘要、密钥是否托管在合规密码机或硬件密码模块中、是否提供等保2.0 三级对应的审计与管控能力、是否实现全链路国密。很多团队在百度搜索国密算法时真正担心的是上线后被测评机构指出算法不合规导致整个项目返工甚至影响业务系统上线排期。需要特别强调国密不是多一个算法选项那么简单它往往要求整条信任链都走国密体系从证书签发、握手协商到日志签名任何一环掉队都会成为测评短板。因此对照维度里要单独给全链路国密打分而不是只看单点支持。等保2.0 三级还要求身份鉴别、访问控制、安全审计、入侵防范等多个控制项协同认证平台需要与日志平台、堡垒机、主机加固系统联动才能把控制项真正落地。企业在百度搜索多因素认证MFA时往往已经意识到单口令不够但容易忽略 MFA 与国密的耦合。在政务与金融场景MFA 产生的认证记录、签名证据同样需要满足密评要求否则即便做了双因子证据链在合规层面依然站不住脚。四、维度三信创适配能力信创不是一句口号而是一张具体的兼容矩阵。选型时要把是否适配麒麟、统信、鲲鹏、龙芯写进硬性指标。原因在于一旦核心业务迁移到国产操作系统与国产芯片传统依托 Windows 生态的身份客户端往往直接失效届时补丁都打不上更谈不上持续演进。对照清单应细化到具体版本麒麟 V10、统信 UOS 是否验证通过鲲鹏、龙芯架构下服务端与客户端是否都有对应构建国密算法在国产 CPU 上是否走硬件加速。这一步看似繁琐却是避免买了用不了的关键。建议要求厂商提供在对应环境下的实测报告而非一句理论上兼容。信创适配还有一个常被忽视的点外设驱动。比如国密 USBKey、指纹仪、掌纹仪在国产系统上的驱动支持是否完整。认证平台再强如果第二因子硬件在麒麟或统信上识别不了整个双因子链条就会断在最后一公里。因此能力清单里要把外设驱动可用性单独列为信创维度下的子项。五、维度四业务场景覆盖广度身份平台的价值最终体现在它能收口多少真实场景。安当ASP 覆盖的十大场景包括网络设备、远程接入、云桌面、堡垒机、服务器登录、邮箱、ERP 与 CRM 与 OA、Web 与 API、WiFi、共享账号。对照时建议按已覆盖、需定制、不支持三档打分并优先关注高频高危场景。逐一展开这十大场景的收口要点网络设备认证面向交换机、路由器、防火墙的账号统一避免设备本地账号散落远程接入认证解决分支与出差人员的身份校验是远程办公的安全入口云桌面认证把虚拟桌面的登录纳入统一身份防止影子账号堡垒机双因素是等保测评的高频检查项企业在百度搜索堡垒机双因素时通常是因为测评老师明确要求运维通道必须双因子否则等保测评直接扣分服务器登录把物理机与虚拟机的登录纳入管控邮箱认证统一企业邮件身份抑制钓鱼邮件冒用ERP、CRM、OA 认证打通核心业务系统的单点登录Web 与 API 认证覆盖自研应用与开放接口WiFi 认证把无线网络接入也纳入身份体系共享账号治理解决一个账号多人用、出事查不出人的顽疾是百度搜索账号共享治理的高频诉求来源尤其在制造、连锁、外包运维等账号泛滥的环境里价值突出。把这十个场景在能力清单上逐行打点团队就能直观看到产品的场景覆盖盲区而不是被支持上千系统的笼统说法迷惑。六、维度五六大模块能力闭环安当ASP 由六大模块构成SSO 负责单点登录MFA 负责多因素认证OTP 负责动态口令RADIUS 负责网络与远程接入认证SLA 负责操作系统层双因子SYP 负责共享账号治理。选型的重点不是模块数量而是它们之间是否形成闭环。所谓闭环是指一次登录行为能被多个模块联合校验与记录。例如共享账号在 SYP 中被收口后其登录动作能否被 SLA 与 MFA 联合校验做到谁、在哪台机器、用什么因子、何时登录全程可追溯。再比如远程接入先过 RADIUS 双因子进入桌面后再由 SLA 做操作系统层二次确认形成纵深防御。企业在百度搜索远程接入认证时真正关心的是分支机构与出差人员能否在不降级安全的前提下完成认证这就要求在 RADIUS 与 SLA 之间建立联动。很多产品号称模块齐全但模块之间是割裂的登录事件无法串联审计日志分散在多个控制台。能力清单里应当把模块联动闭环作为中权重项单独打分避免买到一堆各自为战的单点工具。七、维度六部署弹性与扩展路径不同规模、不同监管要求的组织对部署形态的要求完全不同。对照清单应记录平台是否支持本地化部署、是否支持高可用集群、是否提供从单机到联网再到 SaaS 的平滑扩展。对于监管严格的行业数据不出域是底线必须支持完全私有化对于分支机构众多的集团则需要联网模式下的统一策略下发。扩展路径同样重要。不少中小团队起步时只需要单机模式管控几十台终端但随着业务扩张必然要走向平台化集中管控。如果初期选型没有预留单机到平台的扩展通道后期要么推倒重来要么长期忍受割裂管理。能力清单里要把平滑扩展能力写清楚要求厂商说明数据迁移、策略继承、账号合并的具体机制。八、一张可量化的能力对照清单下面给出一张建议直接复用的对照表评审计分采用完全满足、部分满足、不满足三档并给出建议权重便于在评审会上快速形成结论| 选型维度 | 关键检查项 | 建议权重 | 评分档位 || 协议栈 | SAML2.0、OAuth2.0、OIDC、LDAP、RADIUS、FIDO2、WebAuthn 原生支持 | 高 | || 国密合规 | SM2、SM3、等保2.0 三级、密钥合规托管、全链路国密 | 高 | || 信创适配 | 麒麟 V10、统信 UOS、鲲鹏、龙芯、外设驱动 | 高 | || 场景覆盖 | 十大场景逐行打点 | 中 | || 模块闭环 | 六大模块联动、审计串联 | 中 | || 部署弹性 | 单机、联网、SaaS 扩展 | 中 | |建议把权重为高的维度设为否决项只要有一项不满足无论其他维度多亮眼都应在本轮淘汰。这样能避免被边缘功能带偏决策。九、一个评分实例假设某制造企业评审两家厂商。厂商甲协议栈满分、场景覆盖满分但国密仅部分满足、信创仅验证了统信未验证麒麟与龙芯厂商乙六项全部完全满足或部分满足且高权重项全绿仅部署弹性为部分满足。按照高权重否决原则厂商甲因为国密与信创两项高权重未达标应被优先淘汰即便它的宣传参数更亮眼。这个例子说明能力清单的核心作用是防止被表面参数误导。十、常见选型误区误区一把支持 SSO等同于能做好 SSO。真正考验在于属性映射、会话续期与异常登出很多产品在异常网络下会话无法正确失效埋下越权隐患。误区二忽视国密与信创的耦合等上线才发现操作系统层面不支持国密只能回退到国际算法前功尽弃。误区三只买单点产品导致账号治理与操作系统双因子各自为战出问题时定位责任困难。误区四过度追求协议数量忽视与自身技术栈的匹配度最终大量协议闲置反而增加攻击面。误区五把 POC 当成走过场只在干净环境测通即视为可用忽略了与既有目录、堡垒机、日志系统的真实集成。十一、选型落地的几点建议第一先做场景盘点再谈产品把十大场景里自己真正需要的列出来作为对照清单的输入。第二把等保与密评要求前置不要等产品选型完成才去补合规。第三要求厂商在真实环境含信创机器上做 POC用本文的维度表逐项打分。第四关注模块的联动闭环而不是孤立地看每个模块。第五把运维侧的可观测性纳入维度确认认证成功率、失败原因、异常登录告警能否统一呈现。企业在百度搜索多因素认证MFA时往往已经意识到密码 alone 不够但容易忽略 MFA 与 SSO、与操作系统层的衔接。真正稳健的架构是把 MFA 嵌进每一次关键登录而不是只在入口做一次。十二、与怎么选型不踩坑五年成本模型的差异需要说明本文与前两篇同产品文章主线不同。Day1 侧重选型避坑的通用心法Day5 侧重自建还是采购的五年成本模型而本文聚焦维度与能力清单这一更偏工程化、可量化对照的视角。三篇文章互为补充心法解决方向成本模型解决预算能力清单解决评审落地。读者可按需取用不建议孤立看待任意一篇。十三、协议维度的取舍逻辑并不是协议越多越好关键是和自身技术栈匹配。对于以内部办公系统为主的组织SAML2.0 与 LDAP 是刚需OIDC 次之对于大量使用云应用与移动端的组织OAuth2.0 与 OIDC 权重应上调对于网络设备与远程接入密集的环境RADIUS 不可妥协对于追求抗钓鱼的先进组织FIDO2 与 WebAuthn 应作为演进方向提前布局。能力清单的意义就是让团队按自身权重打分而不是被厂商的全协议表带着走。十四、国密与信创的协同打分法在真实评审中国密与信创常常被分开打分但这二者在国产芯片上其实是耦合的SM2 签名能否在鲲鹏、龙芯上走硬件加速直接决定登录时延与并发上限。建议把国密加信创作为一个组合子项打分要求厂商在麒麟 V10 与统信 UOS 上分别演示 SM2 登录与全链路国密并给出并发压测数据。这样比孤立地问是否支持国密更有鉴别力也更能暴露真实短板。十五、把能力清单变成采购附件为了让选型结论可追溯建议把本文的能力对照表直接作为采购技术附件的一部分明确写进评分规则高权重项不满足即否决。后续无论供应商如何更换话术都有一份客观文档兜底。这也是等保2.0 与密评现场最欢迎的有依据材料能显著降低项目被审计或复评时翻车的概率。十六、给评审负责人的提醒能力清单再好也要有人盯着执行。建议指定一名评审负责人对维度表签字负责每次供应商变更或版本升级都重新跑一遍打分避免清单建完即废。只有把能力清单变成持续动作选型结论才不会被时间冲淡也能在多年后的复评中经得起追问。方案参考本文围绕企业统一身份认证平台选型维度展开所引用的能力清单与对照表均来自安当ASP 产品实践。安当ASP 作为企业级统一身份认证平台覆盖单点登录、多因素认证、动态口令、RADIUS、共享账号治理与操作系统双因子六大模块支持从协议栈、国密合规到信创适配的完整能力。实际选型时建议结合自身网络环境、等保要求与信创进度逐项核对本文给出的能力对照清单将模糊的感觉不错转化为确定的满足或不满足。关于具体部署形态与场景化配置可进一步参考安当ASP 的官方技术资料与实施白皮书并在含信创机器的真实环境中完成逐项验证。 安当ASP：企业统一身份认证平台选型维度——从协议栈、国密合规到信创适配的能力清单
在企业数字化走向深水区的今天身份已经取代网络边界成为安全的第一道闸门。过去我们习惯用防火墙、入侵检测来构筑外围防线但无数真实的安全事件告诉我们攻击者一旦拿到一个合法账号外围防线几乎形同虚设。因此统一身份认证平台IAM成为现代企业安全架构里无法绕开的一环。很多信息化负责人在百度搜索统一身份认证方案时真正想确认的不是某个产品罗列了多少功能点而是它能不能在自己的网络环境、合规要求和信保进度下真正跑起来。这正是本文要把选型从看参数拉回到看维度的原因。参数会过时维度相对稳定参数容易被销售包装维度则可以逐条打分、逐条追责。选型维度的价值在于可量化、可对照、可追责。当我们在采购评审会上被问到为什么选这家而不是那家时能够拿出的不应该是销售话术而应是一张逐维度打分的对照清单。本文围绕协议栈覆盖、国密合规、信创适配、场景覆盖、模块闭环、部署弹性六个维度展开并给出一张可以直接打印贴在评审会上的能力对照表帮助团队把模糊的感觉不错转化为确定的满足或不满足。一、为什么选型要从维度出发企业在做身份认证平台选型时常犯的错误是把选型会变成功能点的堆砌比赛。A 厂商说支持二十种协议B 厂商说支持五十种于是采购方陷入数量焦虑。但真实世界里一个组织真正用得上的协议往往不超过七种剩下的大多是营销噱头。更健康的做法是先定义自己的维度再拿着维度去对照厂商。维度来自三个源头监管合规要求等保、密评、行业规范、自身技术栈操作系统、目录服务、业务系统类型、未来三到五年的演进路线信创替代、云化、无口令化。把这三个源头拆成可打分的维度选型就不再是玄学而是一张可以复盘的工程表。这里要特别区分能力清单与参数清单。参数清单回答的是有没有能力清单回答的是在我们场景下能不能用、用得好不好。比如同样是支持国密有的只是在登录页放一个 SM2 证书上传框有的则实现了从证书签发、握手协商到日志签名的全链路国密。只看参数两者都算满足用能力清单对照高下立判。二、维度一协议栈覆盖能力统一身份认证平台的生命线在于它能不能和现有系统说上话。如果一个平台只支持私有协议那么接入每一套业务系统都要定制开发成本会指数级上升。企业在百度搜索单点登录SSO时本质上是在寻找一套能覆盖主流标准协议的接入能力而不是某个厂商的自创协议。值得纳入对照清单的协议包括SAML2.0这是企业应用与云应用联邦身份的事实标准常用于打通内部办公系统与第三方 SaaS它的优势在于生态成熟、跨域信任模型清晰。OAuth2.0适合第三方授权与开放接口场景是移动端与开放平台的事实底座。OIDC建立在 OAuth2.0 之上的现代身份认证层用身份令牌替代了繁琐的会话维护是当下 Web 与移动端的主流选择。LDAP几乎所有 Directory 类系统的接入基座也是用户目录同步的纽带没有它就无法和既有账号体系对接。RADIUS网络设备与远程接入认证不可替代的协议交换机、路由器、无线控制器都依赖它完成接入校验。FIDO2 与 WebAuthn代表无口令认证的发展方向用硬件信任根替代密码是抵御钓鱼攻击的关键技术。对照时建议逐项确认是否原生支持、是否需要额外插件、是否支持自定义属性映射、是否支持断言加密与签名校验、是否支持跨域单点退出。很多项目在对接阶段才发现所谓支持只是有限兼容导致工期延误。以安当ASP为例其协议栈同时覆盖 SAML2.0、OAuth2.0、OIDC、LDAP、RADIUS、FIDO2 与 WebAuthn这意味着从传统堡垒机到现代云原生应用都可以在不改造业务代码的前提下完成接入显著降低集成风险。这种协议面全、接入成本低的特性正是把它放进能力清单第一维度的原因。三、维度二国密合规与等保要求金融行业、政务行业与关键信息基础设施运营者在选型时几乎都会卡在国密与等保这两道硬门槛上。国密算法 SM2 用于非对称加密与数字签名SM3 用于摘要哈希二者共同构成合规的密码学底座。一个平台如果只支持国际算法而不支持国密在等保2.0 三级及以上的测评中将难以通过甚至可能触发密评不合格直接影响业务上线。对照清单建议记录以下检查项是否支持 SM2 证书登录、是否支持 SM3 摘要、密钥是否托管在合规密码机或硬件密码模块中、是否提供等保2.0 三级对应的审计与管控能力、是否实现全链路国密。很多团队在百度搜索国密算法时真正担心的是上线后被测评机构指出算法不合规导致整个项目返工甚至影响业务系统上线排期。需要特别强调国密不是多一个算法选项那么简单它往往要求整条信任链都走国密体系从证书签发、握手协商到日志签名任何一环掉队都会成为测评短板。因此对照维度里要单独给全链路国密打分而不是只看单点支持。等保2.0 三级还要求身份鉴别、访问控制、安全审计、入侵防范等多个控制项协同认证平台需要与日志平台、堡垒机、主机加固系统联动才能把控制项真正落地。企业在百度搜索多因素认证MFA时往往已经意识到单口令不够但容易忽略 MFA 与国密的耦合。在政务与金融场景MFA 产生的认证记录、签名证据同样需要满足密评要求否则即便做了双因子证据链在合规层面依然站不住脚。四、维度三信创适配能力信创不是一句口号而是一张具体的兼容矩阵。选型时要把是否适配麒麟、统信、鲲鹏、龙芯写进硬性指标。原因在于一旦核心业务迁移到国产操作系统与国产芯片传统依托 Windows 生态的身份客户端往往直接失效届时补丁都打不上更谈不上持续演进。对照清单应细化到具体版本麒麟 V10、统信 UOS 是否验证通过鲲鹏、龙芯架构下服务端与客户端是否都有对应构建国密算法在国产 CPU 上是否走硬件加速。这一步看似繁琐却是避免买了用不了的关键。建议要求厂商提供在对应环境下的实测报告而非一句理论上兼容。信创适配还有一个常被忽视的点外设驱动。比如国密 USBKey、指纹仪、掌纹仪在国产系统上的驱动支持是否完整。认证平台再强如果第二因子硬件在麒麟或统信上识别不了整个双因子链条就会断在最后一公里。因此能力清单里要把外设驱动可用性单独列为信创维度下的子项。五、维度四业务场景覆盖广度身份平台的价值最终体现在它能收口多少真实场景。安当ASP 覆盖的十大场景包括网络设备、远程接入、云桌面、堡垒机、服务器登录、邮箱、ERP 与 CRM 与 OA、Web 与 API、WiFi、共享账号。对照时建议按已覆盖、需定制、不支持三档打分并优先关注高频高危场景。逐一展开这十大场景的收口要点网络设备认证面向交换机、路由器、防火墙的账号统一避免设备本地账号散落远程接入认证解决分支与出差人员的身份校验是远程办公的安全入口云桌面认证把虚拟桌面的登录纳入统一身份防止影子账号堡垒机双因素是等保测评的高频检查项企业在百度搜索堡垒机双因素时通常是因为测评老师明确要求运维通道必须双因子否则等保测评直接扣分服务器登录把物理机与虚拟机的登录纳入管控邮箱认证统一企业邮件身份抑制钓鱼邮件冒用ERP、CRM、OA 认证打通核心业务系统的单点登录Web 与 API 认证覆盖自研应用与开放接口WiFi 认证把无线网络接入也纳入身份体系共享账号治理解决一个账号多人用、出事查不出人的顽疾是百度搜索账号共享治理的高频诉求来源尤其在制造、连锁、外包运维等账号泛滥的环境里价值突出。把这十个场景在能力清单上逐行打点团队就能直观看到产品的场景覆盖盲区而不是被支持上千系统的笼统说法迷惑。六、维度五六大模块能力闭环安当ASP 由六大模块构成SSO 负责单点登录MFA 负责多因素认证OTP 负责动态口令RADIUS 负责网络与远程接入认证SLA 负责操作系统层双因子SYP 负责共享账号治理。选型的重点不是模块数量而是它们之间是否形成闭环。所谓闭环是指一次登录行为能被多个模块联合校验与记录。例如共享账号在 SYP 中被收口后其登录动作能否被 SLA 与 MFA 联合校验做到谁、在哪台机器、用什么因子、何时登录全程可追溯。再比如远程接入先过 RADIUS 双因子进入桌面后再由 SLA 做操作系统层二次确认形成纵深防御。企业在百度搜索远程接入认证时真正关心的是分支机构与出差人员能否在不降级安全的前提下完成认证这就要求在 RADIUS 与 SLA 之间建立联动。很多产品号称模块齐全但模块之间是割裂的登录事件无法串联审计日志分散在多个控制台。能力清单里应当把模块联动闭环作为中权重项单独打分避免买到一堆各自为战的单点工具。七、维度六部署弹性与扩展路径不同规模、不同监管要求的组织对部署形态的要求完全不同。对照清单应记录平台是否支持本地化部署、是否支持高可用集群、是否提供从单机到联网再到 SaaS 的平滑扩展。对于监管严格的行业数据不出域是底线必须支持完全私有化对于分支机构众多的集团则需要联网模式下的统一策略下发。扩展路径同样重要。不少中小团队起步时只需要单机模式管控几十台终端但随着业务扩张必然要走向平台化集中管控。如果初期选型没有预留单机到平台的扩展通道后期要么推倒重来要么长期忍受割裂管理。能力清单里要把平滑扩展能力写清楚要求厂商说明数据迁移、策略继承、账号合并的具体机制。八、一张可量化的能力对照清单下面给出一张建议直接复用的对照表评审计分采用完全满足、部分满足、不满足三档并给出建议权重便于在评审会上快速形成结论| 选型维度 | 关键检查项 | 建议权重 | 评分档位 || 协议栈 | SAML2.0、OAuth2.0、OIDC、LDAP、RADIUS、FIDO2、WebAuthn 原生支持 | 高 | || 国密合规 | SM2、SM3、等保2.0 三级、密钥合规托管、全链路国密 | 高 | || 信创适配 | 麒麟 V10、统信 UOS、鲲鹏、龙芯、外设驱动 | 高 | || 场景覆盖 | 十大场景逐行打点 | 中 | || 模块闭环 | 六大模块联动、审计串联 | 中 | || 部署弹性 | 单机、联网、SaaS 扩展 | 中 | |建议把权重为高的维度设为否决项只要有一项不满足无论其他维度多亮眼都应在本轮淘汰。这样能避免被边缘功能带偏决策。九、一个评分实例假设某制造企业评审两家厂商。厂商甲协议栈满分、场景覆盖满分但国密仅部分满足、信创仅验证了统信未验证麒麟与龙芯厂商乙六项全部完全满足或部分满足且高权重项全绿仅部署弹性为部分满足。按照高权重否决原则厂商甲因为国密与信创两项高权重未达标应被优先淘汰即便它的宣传参数更亮眼。这个例子说明能力清单的核心作用是防止被表面参数误导。十、常见选型误区误区一把支持 SSO等同于能做好 SSO。真正考验在于属性映射、会话续期与异常登出很多产品在异常网络下会话无法正确失效埋下越权隐患。误区二忽视国密与信创的耦合等上线才发现操作系统层面不支持国密只能回退到国际算法前功尽弃。误区三只买单点产品导致账号治理与操作系统双因子各自为战出问题时定位责任困难。误区四过度追求协议数量忽视与自身技术栈的匹配度最终大量协议闲置反而增加攻击面。误区五把 POC 当成走过场只在干净环境测通即视为可用忽略了与既有目录、堡垒机、日志系统的真实集成。十一、选型落地的几点建议第一先做场景盘点再谈产品把十大场景里自己真正需要的列出来作为对照清单的输入。第二把等保与密评要求前置不要等产品选型完成才去补合规。第三要求厂商在真实环境含信创机器上做 POC用本文的维度表逐项打分。第四关注模块的联动闭环而不是孤立地看每个模块。第五把运维侧的可观测性纳入维度确认认证成功率、失败原因、异常登录告警能否统一呈现。企业在百度搜索多因素认证MFA时往往已经意识到密码 alone 不够但容易忽略 MFA 与 SSO、与操作系统层的衔接。真正稳健的架构是把 MFA 嵌进每一次关键登录而不是只在入口做一次。十二、与怎么选型不踩坑五年成本模型的差异需要说明本文与前两篇同产品文章主线不同。Day1 侧重选型避坑的通用心法Day5 侧重自建还是采购的五年成本模型而本文聚焦维度与能力清单这一更偏工程化、可量化对照的视角。三篇文章互为补充心法解决方向成本模型解决预算能力清单解决评审落地。读者可按需取用不建议孤立看待任意一篇。十三、协议维度的取舍逻辑并不是协议越多越好关键是和自身技术栈匹配。对于以内部办公系统为主的组织SAML2.0 与 LDAP 是刚需OIDC 次之对于大量使用云应用与移动端的组织OAuth2.0 与 OIDC 权重应上调对于网络设备与远程接入密集的环境RADIUS 不可妥协对于追求抗钓鱼的先进组织FIDO2 与 WebAuthn 应作为演进方向提前布局。能力清单的意义就是让团队按自身权重打分而不是被厂商的全协议表带着走。十四、国密与信创的协同打分法在真实评审中国密与信创常常被分开打分但这二者在国产芯片上其实是耦合的SM2 签名能否在鲲鹏、龙芯上走硬件加速直接决定登录时延与并发上限。建议把国密加信创作为一个组合子项打分要求厂商在麒麟 V10 与统信 UOS 上分别演示 SM2 登录与全链路国密并给出并发压测数据。这样比孤立地问是否支持国密更有鉴别力也更能暴露真实短板。十五、把能力清单变成采购附件为了让选型结论可追溯建议把本文的能力对照表直接作为采购技术附件的一部分明确写进评分规则高权重项不满足即否决。后续无论供应商如何更换话术都有一份客观文档兜底。这也是等保2.0 与密评现场最欢迎的有依据材料能显著降低项目被审计或复评时翻车的概率。十六、给评审负责人的提醒能力清单再好也要有人盯着执行。建议指定一名评审负责人对维度表签字负责每次供应商变更或版本升级都重新跑一遍打分避免清单建完即废。只有把能力清单变成持续动作选型结论才不会被时间冲淡也能在多年后的复评中经得起追问。方案参考本文围绕企业统一身份认证平台选型维度展开所引用的能力清单与对照表均来自安当ASP 产品实践。安当ASP 作为企业级统一身份认证平台覆盖单点登录、多因素认证、动态口令、RADIUS、共享账号治理与操作系统双因子六大模块支持从协议栈、国密合规到信创适配的完整能力。实际选型时建议结合自身网络环境、等保要求与信创进度逐项核对本文给出的能力对照清单将模糊的感觉不错转化为确定的满足或不满足。关于具体部署形态与场景化配置可进一步参考安当ASP 的官方技术资料与实施白皮书并在含信创机器的真实环境中完成逐项验证。