做了几年企业安全我发现一个规律几乎所有权限失控事故最后都能追溯到身份数据没有统一。某市级民政局的场景很典型——11 个异构业务系统社会救助、婚姻登记、殡葬服务、低保审核……分别由 5 家不同厂商在不同年份交付每套系统一个账号体系。一名科室人员上午要在 4 个系统之间切换密码记不住就写在便签上有人调岗半年原部门的系统权限还在等保测评时被问能否提供全局用户清单管理员只能一个系统一个系统导 Excel。这篇文章把统一身份认证平台从规划到落地的完整路径拆开讲包括身份源怎么选、异构系统怎么接、账号生命周期怎么自动化、等保条款怎么对应。案例基于安当 ASP 统一身份认证服务平台的真实实施。一、先想清楚统一身份认证到底统一什么很多项目一上来就问支持什么协议其实顺序错了。统一身份认证平台要统一的是四样东西协议只是第四层的实现手段统一层次统一内容不统一的后果统一身份管理一个人在企业内只有一个数字身份 ID张三在 A 系统是 zhangsan、B 系统是 zs001审计无法关联统一认证登录入口收敛一次认证全域通行每个系统各自校验密码弱口令面难以收口统一授权权限基于角色/部门下发而非逐系统手配调岗、离职权限回收靠人工必然有遗漏统一审计所有认证、授权、访问事件汇聚到一处安全事件无法溯源等保直接扣分安当把这套能力概括为5A 统一身份能力统一身份管理、统一认证、统一授权、统一审计、统一应用门户。落到产品上ASP 是一个集中式身份安全中台对上通过 SAML 2.0 / OAuth 2.0 / OIDC 对接业务系统对下通过 AD/LDAP/HR/钉钉/企微对接身份源中间是 SSO 认证中心、MFA 多因子引擎、RBAC 权限引擎和审计日志。一句话概括建设目标把每个系统各管各的账号改成一个身份底座供给所有系统。二、第一步确定唯一可信身份源这一步做错后面全白搭统一身份认证项目最容易翻车的地方不是技术对接而是没定清楚谁说了算。企业里常见的候选身份源有三个HR 系统、AD 域、各业务系统自建用户表。实施时必须明确优先级HR 系统人员主数据入职/转岗/离职 ↓ 每日增量同步 AD / LDAP账号与组织架构 ↓ 实时/定时同步 ASP 统一身份平台全局身份 ID 角色映射 ↓ SAML/OIDC/表单代填 11 个业务系统只消费身份不再自建账号推荐实践以 HR 为人员事实源AD/LDAP 为账号载体ASP 为身份中枢。ASP 的身份源管理模块支持这几种接入方式LDAP标准协议适用于 OpenLDAP 及各类目录服务Windows AD域账号无缝同步组织架构树自动映射为 ASP 部门树HR 系统对接通过 RESTful API 拉取人员异动数据钉钉 / 企业微信 / 微信扫码移动端登录入口同时作为身份源绑定手动创建 批量模板导入适合无 HR 系统的中小组织有个细节值得强调ASP 支持用户身份源多绑定——同一个人可以把 AD 账号、钉钉账号、微信账号都关联到同一个全局身份实现一号通。这解决了一个很实际的问题领导习惯钉钉扫码运维习惯 UKey一线人员习惯账号密码但审计日志里必须是同一个人。同步策略上建议这样配置事件触发动作时效要求入职HR 建档 → ASP 自动创建身份 → 按岗位模板授予角色T1 日内转岗部门变更 → 原部门角色自动撤销 → 新部门角色下发T1 日内离职HR 标记离职 → ASP 即时禁用身份 → 所有应用会话失效实时这条必须实时长期未登录90 天未登录 → 自动标记休眠 → 通知管理员复核定时任务离职这条要单独强调必须做到即时禁用。传统模式下管理员要挨个系统删账号11 个系统删完可能过了一周接入 ASP 后在平台上禁用身份所有走 SSO 的应用下一次令牌校验就会失败会话立即中断。三、第二步11 个异构系统怎么接分三类处理真实项目里的业务系统不可能都支持标准协议。实施时我习惯先做一次接入能力盘点把系统分成三类分别用不同策略第一类支持标准协议的系统约占 40%这类最省事。新建系统、主流 SaaS、开源系统基本都在此列。ASP 侧创建应用配置 Client ID / 回调地址 / 协议类型即可。以 OIDC 授权码模式为例业务系统侧的对接大致是这样# 1. 用户访问业务系统未登录 → 重定向到 ASP 授权端点 GET /oauth2/authorize ?client_idwelfare-system-01 response_typecode scopeopenid profile redirect_urihttps://welfare.gov.local/callback statexY7kP2 # 2. 用户在 ASP 完成认证含 MFAASP 回调业务系统 GET https://welfare.gov.local/callback?codeSplxlOBstatexY7kP2 # 3. 业务系统用 code 换 token服务端到服务端 POST /oauth2/token Content-Type: application/x-www-form-urlencoded grant_typeauthorization_code codeSplxlOB client_idwelfare-system-01 client_secret****** redirect_urihttps://welfare.gov.local/callback # 4. 拿到 id_token 后校验签名与 claims建立本地会话政务领域用 SAML 2.0 的也很多ASP 同样支持配置 IdP 元数据 断言消费地址即可。第二类可改造但不支持现代协议的系统约占 35%这类系统有源码、有厂商维护但用的是自研登录逻辑。两种做法API/SDK 集成ASP 提供 RESTful API 和前端 JavaScript SDK支持 Vue/React改造量通常在 1-2 人日隐藏式模式无用户源应用业务系统本身不维护用户表登录态完全由 ASP 下发第三类闭源老旧系统约占 25%也是最头疼的厂商跑路、源码丢失、C/S 架构——这类系统在政务和制造业里比例惊人。ASP 的处理方式是零改造旁路接入B/S 老系统浏览器插件 / 反向代理拦截登录页向平台申请解密后的凭据模拟输入完成登录。用户全程看不到真实密码平台还能定期轮换目标系统的密码C/S 客户端通过 SLA 安全登录代理接管终端登录入口强制先过统一认证共享账号系统交给 SYP 密码管理器托管授权到人、授权到时间段明文永不暴露这一类的价值在于把审计盲区补上——以前运营部三个人共用一个后台账号现在每次代填都绑定真实操作人。四、第三步权限模型别做太复杂RBAC 够用见过不少项目把 ABAC 那套搬进来结果管理员根本不会用。统一身份认证平台的权限模型建议就用 RBAC把复杂度留给角色定义。ASP 的 RBAC 结构是四层用户 → 角色 → 权限分组 → 资源/应用 ↑ 部门/用户组支持权限继承实操建议角色按岗位定义不按人定义。低保审核员是角色张三不是善用部门继承。多层级树形部门架构下上级部门的策略可以向下继承避免逐人配置权限分组做打包。把社会救助系统的查询录入导出打包成一个权限分组分配时一步到位多级管理员分权。超级管理员管平台各业务条线设子管理员只能管自己的应用和用户政务和集团型企业还会用到多租户ASP 支持创建多个相互独立的公司租户数据完全隔离适合局机关 下属事业单位这种架构。五、第四步认证强度按场景分级不要一刀切统一身份认证不等于所有场景都上最强认证。合理的做法是分级访问场景认证强度具体因子内网办公网访问 OA单因素账号密码 / 钉钉扫码访问含个人信息的业务系统双因素密码 OTP 动态口令管理员登录后台强双因素密码 UKey国密 SM2 证书互联网侧远程访问强双因素 设备校验密码 FIDO2/生物特征操作系统/服务器登录强双因素SLA 代理 UKey / 指纹ASP 的 MFA 模块支持的因子比较全FIDO2/WebAuthn指纹、人脸、硬件密钥、UKeyKeyId / 公钥 / 证书三种绑定方式、OTP 动态口令TOTP兼容谷歌/微软认证器支持国密 SM3、安全软锁 ID、短信/邮件验证码。用户可以自助绑定、解绑、切换设备减轻管理员负担。民政局那个项目最终选的是密码 UKey原因很实际工作人员年龄结构偏大手机装 App 推广成本高UKey 插上就能用而且符合政务领域对硬件密钥的偏好。六、等保 2.0 条款怎么对应做统一身份认证项目验收环节一定会被问合规。这里给一张对照表直接拿去写方案等保 2.0 三级要求平台对应能力应对登录用户进行身份标识和鉴别身份标识具有唯一性全局唯一身份 ID多身份源绑定至同一身份应采用两种或两种以上组合的鉴别技术MFA密码 OTP/UKey/FIDO2/生物特征应提供并启用登录失败处理功能失败锁定策略、异常登录告警应对分散在各个设备上的审计数据进行收集汇总和集中分析管理员日志 用户行为日志 设备日志支持 Syslog 外发 SIEM应实现特权用户的权限分离多级管理员、RBAC 权限分组应授予管理用户所需的最小权限角色最小化 权限继承 定期复核密码算法应符合国家密码管理规定国密 SM2/SM3/SM4 全支持引用的标准依据GB/T 22239-2019《网络安全等级保护基本要求》、GB/T 39786-2021《信息安全技术 身份鉴别相关标准》国密算法遵循 GM/T 0002/0003/0004。七、落地效果与实施周期参考民政局项目的最终数据单次登录时间从平均3 分钟缩短到 10 秒原来要在多个系统间反复输密码账号运维效率提升约80%权限分配错误率降为零等保 2.0 统一身份鉴别与集中访问控制两项合规通过11 个系统全部纳入统一审计可按人、按系统、按时间检索登录行为实施周期参考来自多个项目的经验值工作项典型周期AD 域 / LDAP 集成1-2 周标准协议应用SAML/OIDC单个对接1 天老旧系统旁路代理接入2-5 天/个VPN、堡垒机 RADIUS 对接 3 天整体项目10 系统规模6-10 周平台侧的性能容量最大注册用户 100 万、最大应用对接数 100 万、并发 2000 QPS、平均认证延迟 50ms、用户检索响应 0.5 秒。高可用采用 Keepalived 虚拟 IP 漂移 PostgreSQL/Repmgr 主从复制RTO 30 秒、RPO ≈ 0。八、常见问题Q已经有 AD 域了还需要统一身份认证平台吗AD 解决的是 Windows 生态内的域账号管理但它不解决三件事非 Windows 应用的 SSO、多因素认证、跨系统的集中审计。实际项目里 AD 通常作为 ASP 的身份源之一保留而不是被替换。Q老系统实在改不动怎么办用旁路代理或浏览器插件做表单代填不动一行源码。这是目前性价比最高的方案代价是要在客户端装轻量组件。Q统一身份平台会不会成为单点故障这是必须回答的问题。生产环境务必上双机热备或集群Keepalived 做 VIP 漂移PostgreSQL 用 Repmgr Pgpool 做主从复制与读写分离心跳检测自动故障转移非抢占式策略保证切换平滑。另外 SLA 终端组件支持离线令牌断网时终端仍可完成认证。Q项目要从哪个系统开始接建议从用户量大 改造容易的系统起步通常是 OA 或门户快速让员工感知到 SSO 的便利为后续推广积累支持。核心业务系统放第二批老旧系统放第三批。写在最后统一身份认证平台的价值不在于技术多先进而在于它把散落在几十个系统里的身份数据收敛成了一份可管、可控、可审计的资产。对安全团队来说这意味着终于能回答现在有多少活跃账号、谁访问了什么、离职的人权限清干净没有这三个问题对业务部门来说是少记 10 个密码、少填 10 次登录框。这两件事同时成立的时候项目才算真正落地。本文技术内容参考《安当 ASP 身份认证服务平台技术白皮书 V4.0》。安当技术专注身份安全与数据加密产品通过公安部第三研究所与国家密码局商用密码检测已服务 400 企业客户。