2. 身份与账号模型
在身份治理工程中，最容易混淆的不是技术实现，而是概念边界。很多项目失败并非因为工具能力不足，而是因为把“人”“身份”“账号”“凭证”混为一谈，导致权限归属无法追溯、离职回收不彻底、审计证据链断裂。本节先厘清六个核心对象，再给出可落地的建模方法。
六个核心对象及其边界
自然人是现实世界中具有法律主体地位的个体，是身份治理的最终归属点。它不随系统变化，但会随雇佣关系、合同关系、学籍关系发生变化。自然人本身不直接持有权限，权限必须通过数字身份与账号间接获得。
数字身份是自然人在特定治理域内的抽象表示，通常由唯一标识（如员工号、学号、统一身份ID）和一组属性（姓名、部门、岗位、状态）构成。数字身份是“谁”的问题，它回答的是“这个主体在组织中被认定为什么角色的人”。
账号是数字身份在某个具体系统中的登录实体，是“用什么进入系统”的问题。一个数字身份可以对应多个账号（如邮箱账号、ERP账号、VPN账号），但每个账号必须能回溯到唯一数字身份。账号是权限的直接载体。
凭证是证明账号归属的认证材料，包括密码、密钥、证书、生物特征、一次性令牌等。凭证是“凭什么证明你是这个账号”的问题。凭证泄露不等于身份被盗，但会导致账号被冒用，因此凭证生命周期必须与账号状态联动。
角色是权限的集合，是连接账号与资源的中间层。角色解决的是“批量授权”问题：把一组权限打包，再授予一批账号。角色可以按岗位、职责、项目、临时任务划分，但必须避免角色爆炸和角色重叠。
权限是对资源执行特定操作的权利，通常表示为“资源+操作”的二元组，如“订单表+读取”“财务系统+审批”。权限是原子化的，角色是权限的容器，账号通过角色获得权限。
资源是被访问的对象，包括应用系统、API、数据库表、文件、设备、云服务等。资源是权限的客体，也是审计的最终目标。
关系模型：从自然人 to 资源
六个对象之间不是简单的一对一关系，而是一条带分支的授权链：自然人拥有一个或多个数字身份；数字身份绑定一个或多个账号；账号持有凭证用于认证；账号被授予一个或多个角色；角色包含一组权限；权限作用于具体资源。这条链上任何一环断裂，都会导致权限无法回收或审计无法定位。
建模方法：从关系图到可执行模型
关系图只是概念层，落地时需要把每个对象变成可存储、可查询、可审计的数据结构。推荐采用“主体—身份—账号—授权—资源”五层模型，每层都有唯一标识和状态字段。
第一层是主体表，记录自然人信息，主键为人员ID，字段包括姓名、证件类型、证件号、状态（在职/离职/冻结）。第二层是身份表，主键为身份ID，外键指向人员ID，字段包括身份类型（员工/外包/学生）、所属组织、生效时间、失效时间。第三层是账号表，主键为账号ID，外键指向身份ID，字段包括系统标识、登录名、账号状态、创建时间、最后登录时间。第四层是授权表，记录账号与角色的关联，字段包括账号ID、角色ID、授予时间、授予人、过期时间。第五层是角色权限表，记录角色与权限的关联，字段包括角色ID、权限ID、资源ID、操作类型。
这套模型的关键约束是：账号表的外键必须非空，即不允许存在没有身份归属的账号；授权表必须记录授予人和过期时间，避免永久授权；角色权限表必须定期复核，防止权限漂移。
实操示例：一个员工入职的建模过程
假设某公司新员工张三入职，工号 E10086，部门为财务部，岗位为会计。系统需要为他创建数字身份、账号、凭证，并授予角色。
第一步，在主体表插入记录：人员ID=P001，姓名=张三，状态=在职。第二步，在身份表插入记录：身份ID=ID001，人员ID=P001，身份类型=员工，组织=财务部，生效时间=2025-06-01。第三步，在账号表插入三条记录：邮箱账号 ACC001、ERP账号 ACC002、VPN账号 ACC003，均外键指向 ID001。第四步，为每个账号生成初始凭证，密码采用一次性随机值，强制首次登录修改。第五步，在授权表插入记录：ACC002 授予角色 R_FIN_ACCOUNTANT，过期时间=2026-06-01。第六步，在角色权限表中确认 R_FIN_ACCOUNTANT 包含权限：凭证录入、凭证查询、报表查看，对应资源分别为财务系统凭证模块、查询模块、报表模块。
当张三转岗到审计部时，只需更新身份表的组织字段，并撤销 R_FIN_ACCOUNTANT，授予 R_AUDITOR。账号和凭证不变，但权限链路自动切换。当张三离职时，将主体表状态改为离职，身份表失效，账号表全部禁用，凭证全部吊销，授权表记录全部标记为失效。审计时，从资源访问日志中的账号ID，可以逐层回溯到角色、身份、自然人，形成完整证据链。
常见建模陷阱
第一个陷阱是账号与身份合并。有些系统直接用登录名作为人员唯一标识，导致一个人多个系统账号无法关联，离职时漏删。正确做法是账号表必须外键指向身份表，身份表再指向主体表。
第二个陷阱是角色即权限。把角色直接写成具体权限，导致角色数量膨胀，无法复用。正确做法是角色只做权限打包，权限保持原子化，角色可以组合。
第三个陷阱是凭证与账号状态脱节。账号已禁用但凭证仍有效，攻击者仍可通过API密钥访问。正确做法是凭证表增加状态字段，账号禁用时级联吊销所有凭证。
第四个陷阱是资源粒度太粗。权限只到系统级，无法控制到具体数据行或字段。正确做法是资源表支持层级结构，权限可以绑定到资源节点，实现细粒度授权。
掌握这六个对象的关系与建模方法后，后续的账号生命周期管理、权限评审、审计追溯才有稳定的数据基础。建模不是一次性工作，而是随着组织变化持续演进的治理资产。