一、为什么身份孤岛是数字化的最大隐疾企业数字化转型进行到今天绝大多数组织的 IT 环境早已不是一个 AD 域打天下。典型的混合架构长这样本地数据中心跑着Windows AD 域承载办公网账号HR 系统里有一份真正的人员花名册但与 AD 不同步云上买了一堆 SaaS飞书、钉钉、企业微信、各类业务系统各自一套账号运维还有一批Linux / 网络设备用本地账号。结果是一个人离职HR 系统里销户了但 AD 没禁用、VPN 还能登、SaaS 还能看客户资料——这就是身份孤岛。等保 2.0 明确要求集中身份管理 全链路审计分散式账号恰恰是合规红线。二、统一身份底座以 HR 为唯一可信源安当 ASP 的思路很清晰不新建一套账号而是构建逻辑集中的统一身份底座把各系统的身份数据收敛到一个身份中台。核心原则是唯一可信源SoTHR系统(人员主数据) │ 入职/转岗/离职事件 ▼ ASP统一身份平台 ──同步──▶ AD域 / LDAP / 钉钉 / 企业微信 / SaaS │ └── 身份生命周期自动编排创建→启用→改组→禁用→删除人员从入职那一刻起ASP 就根据 HR 事件自动在统一身份库创建账号按部门 / 岗位自动归属到对应组织、用户组通过标准协议SAML / OIDC把账号下发到各类异构系统转岗时自动调整归属与权限继承离职时一键禁用并回收所有系统访问。把人工加账号变成策略驱动运维成本直接降一个数量级。三、异构身份融合一号通ASP 兼容AD、LDAP、钉钉、企业微信、微信等全主流身份源并支持用户自助把多个外部身份源绑定到同一个统一身份实现一号通。身份源接入方式典型用途Windows AD域账号无缝同步办公网统一认证LDAP标准目录协议各类目录服务钉钉 / 企业微信扫码登录移动端便捷登录微信扫码登录对外生态接入管理员侧可以配置应用账号自定义映射把统一身份下的字段如工号、邮箱映射到目标系统的登录标识避免各系统账号命名混乱。四、组织、用户组与 RBAC 权限继承身份治理不只是把人收拢更要把权限管好。ASP 提供多层级树形部门架构按行政组织建立部门树权限与策略可沿树继承用户组自定义把同类角色的人员归组统一赋权RBAC 模型角色定义 → 成员分配 → 权限分组用户继承角色的全部权限。部门树总公司 → 研发中心 → 平台组 └─ 平台组(用户组) ──继承──▶ 角色[研发只读] ──授权──▶ 代码仓库/CI系统这种人员 → 部门/组 → 角色 → 资源的链路让大型组织的授权从逐个配变成按规则配。五、等保 2.0 条款映射等保要求ASP 对应能力身份鉴别a 级统一身份、多因子可选、唯一标识访问控制b 级RBAC 角色授权、最小权限安全审计c 级管理员/用户/设备全量日志、Syslog 外发 SIEM集中管理三级统一身份中台、生命周期自动编排六、落地 checklist确认 HR 系统为唯一可信源梳理入职/转岗/离职事件接口列出全部身份源AD / LDAP / 钉钉 / 企微 / 微信配置同步设计部门树与用户组定义 RBAC 角色用 SAML / OIDC 接入自建与 SaaS 应用开启全链路审计日志并对接 SIEM做一次离职即回收的演练验证生命周期闭环。小结统一身份治理不是再建一套账号而是把散落在 AD、HR、钉钉、云上的身份收敛成一个可治理、可审计、可自动编排的中台。当身份有了唯一可信源和清晰的生命周期等保合规与运维效率会同时改善。安当 ASP 的异构身份融合与 RBAC 能力正是这套底座的关键支撑。