企业身份安全选型：从六大场景判断IAM厂商能力边界

一、企业采购“身份安全”时的真实选型场景
如果按传统 IAM 理解，企业通常关注统一账号、组织架构、单点登录、权限治理和账号生命周期。但在真实项目里，企业采购“身份安全”时，经常会把IAM与AD 替代、MFA、弱口令治理、PAM、NAC、零信任访问放在同一个议题里讨论。
原因很简单：身份已经不只是“谁能登录应用”，而是延伸到“谁能登录终端、谁能接入网络、谁能访问应用、谁能操作核心资产、异常时如何阻断和回溯”。

因此，本文按 6 个真实采购场景展开：
其中前两类更接近核心IAM 场景，后四类属于身份安全扩展场景。这样分类的目的，是避免把所有问题都硬说成 IAM，同时也不忽略企业在身份安全项目中经常一起采购和评估的能力。

二、主流厂商能力画像

三、6大场景
1、统一身份治理与应用访问管理
客户典型痛点
业务系统越来越多，各系统独立维护账号、密码和权限。员工入职、转岗、离职时，账号开通、权限变更和账号回收依赖人工处理，容易产生僵尸账号、共享账号、越权访问和审计盲区。
客户真正要解决的问题
• 统一账号源和组织架构，减少多系统重复维护；
• 实现 SSO，降低用户多系统反复登录成本；
• 统一人员入转调离流程，避免账号遗留；
• 建立角色、岗位、组织、属性驱动的权限模型；
• 实现权限申请、审批、授权、复核、回收闭环；
• 对账号和权限进行持续审计。
厂商能力判断
---传统 IAM 厂商在这一场景通常最强，尤其是应用集成、账号生命周期、组织架构同步、权限治理和复杂业务系统对接。
---身份基础设施与终端安全联动型厂商如果参与纯 IAM 项目，需要证明其应用集成深度、权限模型、账号生命周期和审计能力，而不能只强调 AD 替代或终端管控。
---MFA/RADIUS 厂商可以补强认证安全，但不一定能承担完整统一身份治理。
建议验证方式
• 选择 3-5 个典型业务系统验证 SSO 和账号同步；
• 验证员工入职、转岗、离职的账号自动开通、变更和回收；
• 验证权限申请、审批、授权、复核、撤销流程；
• 验证僵尸账号、共享账号、异常账号识别；
• 要求厂商提供同行业复杂应用集成案例。
2、认证安全与账号风险治理
客户典型痛点
弱口令、密码复用、共享账号、僵尸账号、暴力破解、非工作时间登录、异地登录，是监管检查、攻防演练和日常安全运营中的高频问题。客户希望提升认证安全，但又不希望明显增加用户使用负担。
客户真正要解决的问题
• 关键系统登录是否需要 MFA；
• 弱口令能否被提前发现和强制整改；
• 账号异常行为能否被识别；
• 风险登录能否触发二次认证、阻断或强制改密；
• 终端开机账号、域账号、业务系统账号能否统一纳入治理；
• 用户忘记密码、手机不可用、离线办公时是否有应急机制。
厂商能力判断
---MFA/RADIUS 厂商在多因素认证、网络认证、VPN/Wi-Fi 认证方面能力突出，适合快速补齐认证安全短板。
---传统 IAM 厂商通常能把 MFA 与账号生命周期、应用访问、权限治理结合起来，适合业务系统身份治理。
---终端安全厂商在 USB Key、桌面登录二次认证、终端安全登录方面有经验，但要核验跨平台能力和统一身份治理能力。
---身份基础设施与终端安全联动型厂商更适合把弱口令治理落到终端开机账号、域账号、AD 替代和终端安全联动中。
建议验证方式
• 验证短信、邮件、OTP、扫码、USB Key 等认证方式；
• 验证弱口令库、密码复杂度、密码过期、账号锁定策略；
• 验证异常时间、异常地点、连续失败登录的风险策略；
• 验证 MFA 对 VPN、Wi-Fi、业务系统、终端登录的覆盖范围；
• 模拟手机不可用、网络不可用、认证服务异常时的应急登录。
3、身份基础设施与 AD/国产域控替代
客户典型痛点
大量企业长期依赖微软 AD 管理终端登录、组织架构、账号密码、共享目录权限、组策略和业务系统认证。国产化替代并不是简单新建一套目录服务，而是身份基础设施迁移。
客户真正担心的是迁移风险：
• 原有业务系统是否需要重新对接；
• 用户是否需要退域、加域、重置密码；
• 共享目录、部门盘、历史权限是否能够继承；
• Windows、麒麟、统信、Linux、Mac、云桌面是否能统一认证；
• 域控不可达、网络异常、客户端异常时能否正常登录；
• 迁移失败时是否支持灰度回退。
厂商能力判断
---传统 IAM 厂商在账号治理和应用集成方面成熟，但 AD 替代涉及终端登录、共享目录、组策略、DNS、域控高可用和迁移回退，需要重点核验其域管产品成熟度。
---MFA/RADIUS 厂商更擅长增强认证，不一定适合承担完整 AD 替代项目。如果客户只是强化 VPN、Wi-Fi、业务系统登录认证，可以考虑；如果要替换域控，则必须核验迁移能力。
---终端安全厂商在终端登录鉴别、USB Key、安全桌面方面有经验，但如果缺少目录服务、协议兼容、共享权限迁移和业务系统低改造能力，更适合作为登录增强组件。
---身份基础设施与终端安全联动型厂商更适合 AD 平滑迁移和信创终端纳管场景，尤其适合同时解决域控替代、弱口令治理、终端认证、网络准入和特权账号管理的客户。
建议验证方式
• 基于现网 AD 依赖清单做迁移评估；
• 选择典型业务系统验证 LDAP、Kerberos、SSO 对接；
• 选择典型共享目录验证权限继承；
• 选择 Windows、麒麟、统信终端验证登录、改密、离线登录；
• 模拟网络中断、域控不可达、认证失败、回退切换；
• 要求厂商提供同规模项目案例、迁移周期和验收指标。
4、特权身份与高风险运维治理
客户典型痛点
特权账号掌握服务器、数据库、网络设备、核心业务系统和云资源的高权限。常见问题包括密码共享、账号借用、权限长期不回收、操作不可追溯、运维中转影响效率、堡垒机故障影响业务。
客户真正要解决的问题
• 特权账号是否能被发现、纳管和分级；
• 密码是否能托管、轮换和自动改密；
• 高危操作是否能实时阻断；
• 运维过程是否能审计和回放；
• 临时授权、应急授权、双人审批是否可控；
• PAM 是否会影响数据库、大文件和高频运维操作。
厂商能力判断
---传统 IAM 厂商做 PAM/PIM 具备身份治理延伸优势，适合把普通账号、应用账号和特权账号放在统一身份体系中管理。
---身份基础设施与终端安全联动型厂商如果具备无跳板、不中转、密码托管、高危命令阻断等能力，应重点证明其在业务连续性、性能影响和信创环境适配上的优势。
---MFA/RADIUS 厂商如果没有正式 PAM 产品，通常需要生态集成或第三方系统补齐。
建议验证方式
• 选取数据库、服务器、网络设备、信创主机做运维链路验证；
• 验证密码托管、密码轮换、临时授权、审批和审计；
• 验证大文件传输、数据库操作、高频命令操作的性能影响；
• 验证高危命令阻断、会话回放、应急登录和故障逃生；
• 要求厂商说明 PAM 与 IAM、AD、MFA、工单系统的联动方式。
5、身份驱动的网络准入与终端可信
客户典型痛点
很多企业能管理“谁登录了应用”，但不知道“谁接入了网络”。外协人员、临时设备、哑终端、仿冒设备、不合规终端进入内网后，可能带来横向移动和越权访问风险。
NAC 本身不是狭义 IAM，但它可以把用户身份、设备身份和终端健康状态结合起来，决定终端能否接入网络以及接入后能访问什么资源。
客户真正要解决的问题
• 谁、用什么设备、从哪里接入网络；
• 接入设备是否可信、是否合规；
• 外协账号到期后是否自动回收；
• 终端不合规时是否自动隔离；
• 是否能按用户、设备、证书、端口、终端健康状态动态授权；
• 认证通过后是否还能进行最小权限访问控制。
厂商能力判断
---MFA/RADIUS 厂商在网络认证和认证基础设施方面有优势，但客户应进一步验证认证后的动态授权、终端健康检查、外协生命周期和异常隔离能力。
---终端安全厂商通常具备传统准入和终端管控经验，但要核验是否存在多组件部署、策略割裂、日志割裂和性能影响。
---身份基础设施与终端安全联动型厂商在 NAC 场景更容易形成闭环，适合把身份、设备、终端健康、网络权限和安全处置统一起来。
建议验证方式
• 选择总部、分支、无线、办公区、生产区等不同网络环境做准入验证；
• 验证员工、外协、访客、哑终端、未知设备的接入策略；
• 验证动态 VLAN/ACL 下发、权限变更、异常隔离和恢复流程；
• 验证终端不合规时的提示、修复、隔离和重新准入；
• 要求厂商提供交换机兼容清单和大规模上线性能数据。
6、身份驱动的零信任访问控制
客户典型痛点
远程办公、移动办公、外包访问、供应商访问和互联网暴露面收敛，使客户不能只依赖传统 VPN。客户希望基于身份、设备、环境、应用和数据风险进行动态访问控制。
零信任不是 IAM，但身份是零信任的基础。客户不应只看“能不能远程访问”，还要看身份、终端、应用、数据和审计是否形成闭环。
客户真正要解决的问题
• 远程访问是否基于可信身份和可信设备；
• 是否支持有端、无端、移动端和浏览器访问；
• 是否能按用户、设备、地点、时间、风险等级动态授权；
• 外包和供应商访问是否能最小授权；
• 访问过程中的下载、复制、打印、截屏、数据落地是否可控；
• 原厂、生态厂商、集成商之间的责任边界是否清晰。
厂商能力判断
---传统 IAM 厂商的零信任能力通常更偏身份、应用访问和风险认证。
---零信任专业厂商更擅长访问代理、应用隐藏、安全隧道和访问控制。
---身份基础设施与终端安全联动型厂商如果能把身份、终端环境、安全沙箱、DLP、移动安全空间和访问控制统一起来，更适合解决远程办公中的数据落地和终端不可信问题。
建议验证方式
• 验证 Web、C/S、数据库、文件系统、移动应用等不同应用访问；
• 验证员工、外包、供应商、移动办公等不同身份访问策略；
• 验证终端不合规、设备变化、异常地点、异常时间时的动态授权；
• 验证水印、沙箱、复制粘贴、下载、打印、截屏等数据保护策略；
• 要求明确原厂、生态厂商、集成商的责任边界和故障兜底机制。
四、企业选型建议
企业在采购前，建议先判断自己的主目标，而不是直接比较厂商功能清单。

五、建议企业在测试或招标中加入的验证条款
• 提供现网 AD 迁移评估报告、灰度切换方案和失败回退方案；
• 提供业务系统低改造对接能力说明和测试报告；
• 提供共享目录权限迁移、权限核验和回退方案；
• 提供 Windows、麒麟、统信、Linux、Mac、云桌面的认证兼容性说明；
• 提供弱口令、僵尸账号、共享账号、异常登录的检测和处置闭环；
• 提供 MFA 覆盖 VPN、Wi-Fi、业务系统、终端登录的验证报告；
• 提供 NAC 与主流交换机、无线控制器、分支网络的兼容清单；
• 提供 PAM 对数据库、服务器、网络设备、信创主机的运维验证报告；
• 提供本地原厂服务人员、项目经理、二线研发接口和应急响应承诺；
• 提供近一年同规模项目案例、验收报告或可核验客户证明。
六、总结
这 6 个场景都是真实采购场景，但它们与 IAM 的关系不同。
统一身份治理、应用访问管理、认证安全和账号风险治理，是 IAM 的核心场景。AD/国产域控替代、PAM、NAC、零信任访问，则属于身份安全的扩展场景。企业应让所有厂商围绕同一组场景、同一组验证问题、同一组验收指标证明能力，而不是只比较功能清单。