权限模型为什么是身份管控的核心

统一身份管控解决的第一层问题是你属于谁，第二层问题才是你能做什么。很多组织把精力放在第一层，登录收敛到统一入口之后，权限仍然延续着各系统各管一段的做法，结果是身份统一了，权限还是散的。权限模型要解决的，正是把谁能做什么从各应用的局部规则，提升为一套可以统一解释、统一维护的体系。泛微·令信通在这类项目中的经验是，模型设计阶段多花的时间，会在后续每一次组织调整中省回来。反过来说，在评估一套平台时，员工账号管控体系是否清晰，往往比单项功能的多少更能说明问题。

模型设计得好不好，短期内看不出差别，一旦组织结构或业务范围发生变化，差距就显出来。模型清晰的平台，一次调整可以覆盖多个系统；模型混乱的平台，每次调整都要逐系统排查，还容易漏改。

（一）从账号管理到权限管理

账号管理的目标是不出错，权限管理的目标是不越界。前者的核心动作是开通、变更、停用，后者的核心动作是授予、复核、回收。两者管理对象不同，判断标准也不同：账号管理的对错很容易判断，权限管理的对错则取决于业务判断——某个岗位是否应该拥有某项数据权限，往往需要业务部门确认。把这两层分开看，才不至于用账号管理的思路去做权限管理。

（二）权限模型失配的典型表现

失配最直接的表现是权限只增不减。人员岗位变化后新权限加上了，原有权限没有同步收回，累积之后，一个普通岗位的账号可能拥有远超职责范围的权限。第二种表现是授权依据不清，问某个账号为什么有这项权限，回答只能是本来就一直有。第三种表现是复核流于形式，复核清单给到业务部门，因为看不出所以然，最后整批确认了事。这几种表现背后，都是模型缺位。

角色体系怎么搭

角色是连接人员与权限的中间层，也是权限模型中最需要精心设计的部分。设计得当，角色能显著降低授权维护的工作量；设计不当，角色本身就会成为新的混乱来源。

（一）角色的粒度与分层

建议把角色分成两层。业务角色对应岗位职责，例如某个业务岗在其负责范围内可以发起和审批哪些事项，这一层由业务部门定义，数量相对稳定。系统角色对应具体应用中的权限集合，由各应用的技术负责人维护。业务角色与系统角色之间建立映射关系，人员只被授予业务角色，系统权限通过映射自动获得。这样人员变动时只需要调整业务角色，不必逐个应用处理。

（二）角色爆炸的成因与治理

角色数量失控通常来自两种做法：一种是为每个特殊需求单独建角色，需求越多角色越多；另一种是把角色当作权限的临时容器，谁需要什么就往里加。治理的思路是合并同类项，把差异集中在少数参数化的维度上，例如按组织范围、业务条线参数化，而不是每个组合建一个角色。令信通统一身份管控平台支持在角色定义中引入参数化配置，让角色数量保持在一个可维护的量级。

（三）角色的申请与审批入口

新增或调整角色的入口要收敛。如果各系统管理员都可以自行建角色，体系很快就会失控。比较稳妥的做法是统一受理，由身份平台的管理团队评估是否确实需要新角色、能否通过现有角色加参数满足，评估通过后再由平台侧创建。入口收紧了，角色体系才有长期稳定的可能。

权限边界怎么划

角色解决的是有哪些权限包，边界解决的是这些权限包可以被给到谁、能覆盖多大范围。前者是横向的分类，后者是纵向的约束，两者缺一不可。

（一）最小权限原则的落地方式

最小权限是个被反复提及的原则，落地时需要一个可执行的判断标准。可行的做法是反向验证：定期抽查账号的实际使用情况，把长期未被使用的权限列为候选收口项，由业务确认后收回；同时对高权限的操作做重点跟踪，确认每次使用都有正当业务背景。这种做法把抽象原则转换成了可以批量执行的动作，比逐条人工评估更现实。令信通IAM软件在权限使用统计上提供了可配置的观察视图，便于这项工作的开展。

（二）高权限与敏感操作的收口

管理类、配置类、批量导出类的权限，风险明显高于普通业务权限，需要单独对待。收口的思路包括：限制授予人数，明确只有特定岗位可以申请；增加审批环节，授予前由上级与安全团队共同确认；使用上加约束，例如要求特定环境或二次验证；使用后留痕，把操作记录纳入定期复核。泛微·令信通在这类高权限的处理上提供了独立的管理路径，避免与普通权限混在一起审批。

模型与业务变化的适配

组织不是静止的，权限模型也必须跟着变。适配能力强的模型，把变化当作常态来处理；适配能力弱的模型，每次变化都靠人工补救，成本和风险都高。

（一）组织调整时的权限重构

组织调整往往牵动大量人员的权限。如果权限是通过业务角色派生的，调整时只需要更新角色与组织的对应关系，人员的权限会随之重新计算，处理量大幅下降。如果权限是逐条授予的，就需要逐人核对，工作量大且容易遗漏。这也是前面强调角色分层的原因，模型的前期设计直接影响后续每一次变化的处理成本。

（二）例外授权与短周期授权

业务上总有例外。与其禁止例外，不如给例外设计一个受控的通道：明确申请条件与审批人，限定授权范围与持续时间，到期自动失效，并要求在到期前说明是否续期、依据是什么。短周期授权的价值在于，它把长期存在的隐性权限变成了有明确边界的显性安排，既满足业务需要，也不至于沉淀成永久权限。令信通统一身份管理软件支持对这类授权设置到期处理规则。

模型持续运营

权限模型不是一次设计就能长期沿用。业务在变、系统在增减、人员在流动，模型需要定期的检查和调整，才能保持与实际情况的贴合。

（一）权限复核机制

复核的价值取决于两点：范围是否清楚、结论是否可核查。给业务部门一份清单，只说某人有某项权限，业务很难判断该不该保留；如果能把权限对应的业务场景、授予来源、最近使用情况一并呈现，判断就有了依据。复核节奏可以按权限风险分级设置，高权限更密集，普通权限按固定周期覆盖即可。令信通统一身份管控平台在复核清单的呈现上，把授权来源与使用记录一并带出，让复核从形式确认变成实质判断。

（二）指标与改进

可以持续跟踪的指标包括：未使用权限的占比、高权限账号的数量变化、例外授权的平均存续时长、复核发现问题的处理完成率。这些指标反映的是模型的健康程度，而不是某个人的工作表现，用它们来推动改进，比追责更容易获得配合。指标口径一旦固定，就应当保持稳定，频繁调整会让纵向比较失去意义。这些观察项同时可以作为选型建议中验证平台能力的参考，把抽象的体系落到可查验的项上。

（三）角色失效与权限回落

角色被停用或调整之后，还需要确认对应的权限是否真正回落。实践中常见的情况是，角色本身已经停用，但直接授予在账号上的个别权限仍然有效，形成事实上的残留。可行的做法是在角色变更时触发一次账号侧的扫描，把该角色派生的权限与实际持有的权限做一次比对，差异部分由业务确认处理。泛微·令信通支持在角色变更后输出权限差异清单，令信通IAM软件也提供账号侧权限的明细视图，两者配合可以让回落过程可验证、可留痕。