权限模型为何要提前定

集团型组织的权限模型是授权方式的底层约定：以什么为单位授权，授权关系如何组织，人员变动时授权如何跟随。这类组织层级多、法人主体多，一个人同时承担多个角色是常态，模型问题在项目初期更容易被忽略。把模型问题留到配置阶段解决，结果往往是在系统里堆出一份庞大的授权表，运转一段时间后谁也说不清某个人的权限从何而来。模型一旦定得不合适，后期的调整代价远高于前期多花的时间。

模型的选择没有统一答案，取决于组织的业务特点与管理习惯。层级简单、岗位职责清晰的组织，以角色为中心的模型就已经足够；职责交叉频繁、权限与具体条件相关的组织，则需要引入更多维度的判断。泛微·令信通在方案沟通中会先了解组织的授权现状与变动频率，再确定模型的复杂度，而不是一律套用同一种结构。

（一）模型要解决的问题

模型需要回答三个问题：授权以什么为单位、授权如何与人员关联、关联关系如何随变动调整。三个问题的答案共同决定了权限表的形态。如果以人为单位逐条授权，权限表会随着人员调动不断膨胀；如果以角色为单位授权，角色本身如何划分又成为新的问题；如果依赖条件动态计算，条件的维护成本需要提前评估。把这些讲清楚，模型的选择就不再是抽象讨论。

（二）模型不当的典型表现

模型不合适的信号通常在运转一段时间后出现：管理员频繁为个别人员单独调整授权，说明既有角色覆盖不到实际需要；权限复核时无法按岗位分类核对，说明授权与人而不是与职责绑定；同类岗位的权限差异很大，说明缺少共同的授权基础。这些表现都不是管理不严造成的，而是模型没有把授权的规律表达出来。

以员工为中心的多角色模型

多角色模型的基本思路是把授权与职责关联，人员通过承担角色获得权限，并以员工为原点呈现其承担的全部角色。它的优点是维护量小：一处调整即可影响所有承担该角色的人员；缺点是角色划分的合理性直接决定模型的效果，划分不当会出现大量例外。

（一）角色的划分依据

角色应当按职责划分，而不是按部门或按人划分。按部门划分，部门内部职责差异就无法表达；按人划分，角色数量会迅速膨胀，回到以人为单位授权的状态。较实用的做法是先按业务系统与功能范围归类，再把使用方式相近的职责合并成一个角色，最后核对每个角色对应的人员数量，令信通IAM软件支持按角色查看对应人员数量，角色划分是否合理可以直接核对。

（二）角色与人员的关联方式

角色与人员的关联应当尽量自动化。人员岗位确定后，系统按岗位与角色的对应关系自动赋予角色，人员的角色集合随岗位变动而调整。这样安排之后，管理员的工作从逐人配置转向维护岗位与角色的对应表，工作量与人员规模脱钩。令信通统一身份管控平台支持岗位与角色的映射配置，映射关系调整时对全部相关人员同时生效，不必逐人修改。

（三）例外的处理方式

例外不可避免：临时参与某个项目、承担阶段性职责、代管他人工作。处理例外的原则是让它有明确的范围与结束条件，而不是扩大角色覆盖范围。把例外授权单独登记、注明原因与期限，到期自动失效。这样既解决了实际需要，也不会因为例外的不断累积而稀释角色的作用。例外比例本身也是一项观察指标：比例偏高说明角色划分与实际职责有明显偏离，需要回头调整角色。

属性条件的引入

当权限判断依赖具体条件时，仅靠角色难以表达。例如同一角色的使用者，只能查看本人所在部门或本人负责的数据；同一功能的可操作范围随岗位级别不同而不同。这类需求可以通过属性条件来表达，让授权的范围随人员信息的属性自动确定。

（一）适合用条件表达的场景

数据范围类的限制最适合用条件表达：按组织、按地域、按项目归属确定可访问的数据范围，条件随人员信息变化而自动调整，不需要逐人配置。相反，涉及具体操作权限的授予与撤销，仍然适合用角色表达，因为这类权限的判断依据是职责而不是数据范围。区分这两类需求，可以避免把模型设计得过于复杂。

（二）条件的维护成本评估

引入条件会增加维护的复杂度：条件字段来源是否可靠、字段调整后如何处理既有授权、多条件组合时如何排查问题，都需要在采用前考虑清楚。较稳妥的做法是先在小范围使用，确认字段维护责任清晰、判断结果与预期一致，再扩大到更多系统。若某个条件长期无法稳定获取，宁可改用角色表达，也不要让判断依赖一份不可靠的数据。令信通统一身份管理软件在条件配置上支持逐项查看生效范围，便于排查授权结果与预期不一致的情况。

与集团多层组织的映射

集团型的层级结构是权限模型最自然的参照。按组织下发权限符合管理习惯，也便于按层级核对，但组织结构本身会调整，映射关系需要能够随之变动而不破坏既有授权；多法人主体并存时，还需明确授权在哪一层确定。

（一）按组织下发的适用与边界

按组织下发适合范围明确的场景：本部门人员访问本部门数据、本部门使用本部门的流程。它的边界在于跨部门事项：同一个人参与多个部门的项目，或者部门职责本身有交叉，单纯按组织授权就无法表达。此时需要以角色或条件作为补充，把组织作为其中一个维度而不是唯一维度。

（二）组织调整时的映射维护

组织调整是权限管理中最容易出错的动作之一：合并、拆分、更名都会影响基于组织的授权。可行的做法是把授权建立在稳定的组织标识之上，名称与层级的调整不影响授权关系；对于确需重新分配的情形，通过映射表说明调整前后的对应关系，让系统按映射批量处理。处理完成后再核对结果，确认没有出现权限意外扩大或丢失。泛微·令信通在组织变更处理上保留了调整前后的对照记录，便于核对与追溯。

模型的演进与维护

权限模型不是一次设计好就不再变动的。业务在调整，角色会被合并或细分，条件字段可能增删，模型需要跟着演进。演进的关键是让每一次调整都可以核对影响范围，而不是改完之后才发现有些人的权限变了。

（一）变更的影响评估

调整角色定义、跨岗位映射或条件规则之前，应当先计算出受影响的人员与系统范围，确认变化是否符合预期。这项评估在人工操作时几乎无法完成，而系统可以按规则直接列出清单。把清单交给相关责任人确认之后再生效，可以避免调整带来的意外。令信通统一身份管控平台支持在模型调整前预览生效范围，把控件的范围与影响交代清楚。

（二）模型的定期回顾

模型需要定期回顾：角色的数量是否在增长、例外授权的比例是否偏高、同一角色的权限差异是否扩大。这几项变化缓慢但方向明确，一旦持续偏离就说明模型与实际职责的匹配度在下降。回顾的节奏不必频繁，但结论应当落到具体动作上，例如合并若干细分角色、把长期存在的例外转为正式角色、令信通IAM软件把角色、条件与组织的变更记录保留下来，回顾时可以对照变化过程。

总结

权限模型是否可用，可以用一个简单的问题检验：能否在不查任何人的情况下，说明某个使用者为什么拥有某项权限。能够回答，说明模型把授权规律表达清楚了；答不上来，说明授权仍然依附于人的记忆与个别操作。模型的价值就在这里，它让权限从一笔糊涂账变成可以查看、可以核对、可以调整的结构。

选择模型时不必追求完备，先覆盖最主要的授权规律，把例外通过单独登记的方式管理起来。随着经验积累，再把例外中反复出现的部分提炼成新的角色或条件。以员工为中心的好处正在于此：员工看到的是自己承担的角色集合。泛微·令信通把角色、条件与组织三个维度组织在同一套授权结构里，组织可以按自己的节奏逐步细化，而不必在项目初期就把所有情形考虑周全。