📚 课程目录第3章身份源与权威数据

3. 身份源与权威数据

身份治理工程的第一条铁律是：不要自己造身份，而是从已经存在且被业务承认的地方把身份接进来。这些“已经存在且被承认的地方”就是身份源（Identity Source）。身份源决定了账号从哪里来、属性由谁说了算、离职或失效时由谁触发回收。如果身份源选错，后面所有的权限模型、审批流、审计报表都会建立在流沙之上。

本节要解决三个层层递进的问题：有哪些典型身份源、每个身份源里哪些属性是权威的、以及当多个身份源对同一属性给出不同值时如何映射与裁决。

一、四类典型身份源及其权威边界

HR系统是员工身份的根。它通常提供工号、姓名、部门、岗位、职级、直属主管、入职日期、离职日期、用工类型（正式/外包/实习）。HR系统的权威性体现在“雇佣关系”这一事实上：只要雇佣关系成立，账号就应存在；雇佣关系终止，账号就应被禁用。因此员工身份的生命周期触发信号几乎全部来自HR系统，而不是来自IT自己判断。

客户系统（CRM、会员中心、电商前台）是外部自然人身份的根。它提供客户ID、手机号、邮箱、实名信息、会员等级、注册渠道。客户身份的权威性在于“业务关系”，其生命周期由注册、注销、风控封禁驱动，而不是由雇佣关系驱动。客户系统的一个典型难点是同一自然人多账号（多手机号、多邮箱），需要靠实名信息或设备指纹做归并。

合作方系统（供应商门户、渠道管理、合同系统）是B2B身份的根。它提供合作方编号、企业名称、统一社会信用代码、联系人、合同有效期、合作状态。合作方身份的权威性来自“合同与协议”，其账号往往需要“企业主体+联系人”两级结构，且有效期与合同强绑定，合同到期即应触发复核或停用。

设备与API身份源是机器身份的根。设备身份来自MDM、IoT平台、资产管理系统，提供设备序列号、MAC、证书指纹、所属组织；API身份来自API网关、服务注册中心、密钥管理系统，提供客户端ID、应用名称、负责人、回调地址、密钥有效期。机器身份没有“人”的雇佣关系，其权威性来自“资产归属”和“应用归属”，生命周期由资产变更和应用上下线驱动。

二、权威属性识别：谁说了算

一个属性是否“权威”，不取决于它在哪个系统里看起来最全，而取决于该属性所描述的事实由谁负责产生和变更。判断方法可以归纳为三问：

事实归属：这个事实的业务责任方是谁？员工部门由HR负责，客户手机号由客户自己维护，合同有效期由法务/采购负责。
变更触发：这个属性变化时，谁最先知道？HR最先知道转岗，CRM最先知道换绑手机号。
错误代价：如果这个属性错了，哪个系统会出问题？部门错了会导致权限错配，手机号错了会导致MFA失效。

据此可以给每个属性标注一个权威源。例如员工身份中，employeeId、department、manager、status的权威源是HR；而email、phone虽然HR也存，但员工可能更常在IT自助门户更新，此时需要明确“HR为初始权威，IT门户为变更权威”，并规定变更后是否回写HR。

三、属性映射与冲突裁决

不同身份源对同一逻辑属性的字段名、格式、编码往往不同。映射要解决“字段对齐”，裁决要解决“值冲突”。

以一个员工身份为例，HR给出dept_code = "D-1024"，而AD中部门字段是OU=研发中心,DC=corp,DC=com。映射规则需要把HR的部门编码翻译成AD的OU路径，这通常依赖一张部门编码—OU路径对照表，而不是硬编码在同步脚本里。对照表应作为受控数据维护，部门新增或调整时先改表再同步。

冲突裁决遵循三条优先级原则：

生命周期状态以HR为准：只要HR显示离职，无论其他系统是否仍标记为活跃，IGA都应立即禁用账号。
联系属性以“最近确认”为准：手机号、邮箱若在多个源存在，取最近一次经本人确认的值，并记录确认时间戳。
组织归属以HR为准，项目归属以项目系统为准：两者维度不同，不应互相覆盖，而应作为两个独立属性并存。

权威属性一旦确定，应在IGA中形成“属性—权威源—映射规则—冲突策略”四元组，并纳入变更评审。任何下游系统都只能读取，不能反向写入权威属性，否则会出现“回写污染”。

四、一个可执行的映射配置示例

下面是一段简化的属性映射配置，用于把HR员工数据映射到统一身份目录。字段含义：source为权威源，target为目标属性，transform为转换方式，onConflict为冲突策略。

identitySource: HR
syncMode: incremental
attributeMappings:
  - source: emp_no
    target: employeeId
    transform: trim
    onConflict: reject
  - source: dept_code
    target: orgUnit
    transform: lookup(dept_code_to_ou)
    onConflict: hr_wins
  - source: email
    target: mail
    transform: lowercase
    onConflict: latest_confirmed
  - source: hire_date
    target: startDate
    transform: toISO8601
    onConflict: hr_wins
  - source: term_date
    target: endDate
    transform: toISO8601
    onConflict: hr_wins
lifecycleRules:
  - when: term_date <= today
    action: disableAccount
    gracePeriodDays: 0
  - when: dept_code changed
    action: recalculateAccess

这段配置的关键点在于：emp_no冲突直接拒绝，因为工号重复意味着数据质量事故；dept_code通过对照表转换，避免把编码直接写进OU；email采用最近确认策略，兼顾HR初始值与员工自助更新；term_date到达当天即禁用，不留宽限期，防止离职后账号仍可访问。

五、落地时的常见判断依据

判断身份源接入是否成功，可以观察四个信号：一是覆盖率，HR在册员工是否100%在IGA中有对应身份；二是时效性，从HR变更到IGA生效的延迟是否在可接受窗口内（例如15分钟）；三是一致性，抽样比对IGA与HR的部门、状态字段是否一致；四是可追溯，每条属性值能否回答“来自哪个源、何时同步、依据哪条规则”。