在用户中心能力标准化的过程中，权限模型的选择不仅影响系统的灵活性与可扩展性，更决定了未来业务协同与角色治理的边界。本文将从产品视角出发，拆解几种主流权限模型的适配逻辑与演进路径，帮助你在复杂业务场景中做出更具前瞻性的架构决策。
回顾上篇“用户中心标准化能力设计（1）：用户类型定义”，提到权限管理是用户中心重要的一个环节。
权限管理的本质是，什么条件下，哪些用户对于哪些数据具备哪些操作权限。从而保证在正确的情况下，允许正确的身份，对正确的资源执行正确的操作。
再进一步拆分权限管理的维度，包括：
条件（When/Where）、身份（Who）、资源（What）、操作（How）。
下述主要介绍B端通用权限模型RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）。
其他模型如ACL（访问控制列表）、ReBAC（基于关系的访问控制）单一权限控制逻辑则不详细介绍，可单独了解。
核心思路：
通过角色解耦用户与权限，形成“用户→角色→权限”三层结构。
特征：
角色抽象：权限绑定角色，用户通过角色继承权限。
扩展模型：
适用场景：
企业后台系统、组织结构清晰的场景。
核心思路：
通过动态计算属性组合（用户、资源、环境）决定权限，规则形如：
用户类型=** and 所属机构=当前用户所属机构 THEN 允许访问。（规则内容可配置动态计算）
特征：
适用场景：
云平台（AWS IAM）、多租户SaaS系统、高合规要求场景。
权限模型RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）的优劣势如下：
在实际B端的权限管理模块设计时，通常需要根据管理需求、业务需求来决定，权限管理范围是否包括功能权限、数据权限。
若同时具备功能和数据权限管理需求，且从综合成本、优先级等角度考虑，可采用RBAC+ABAC混合的方式来进行权限管理。结合此前文章“B端标准化能力如何识别和管理”标准化能力识别示例中对于B端系统的拆分，抽象用户访问数据进行操作时的判断逻辑如下：
鉴权=身份认证通过后，判断用户是否具有功能权限（菜单/按钮）+数据权限（字段/数据）。
其中，“身份认证”、“RBAC是否具有功能权限（菜单/按钮）”、“ABAC是否具有数据权限（字段/数据）”在代码编译时可以拆分为单独的微服务来执行，这样可以按需先实现RBAC → 再实现ABAC。
阶段1：用RBAC快速搭建权限骨架，支撑业务从0到1先落地；
阶段2：待场景复杂时，用ABAC实现动态管控，两者接力；
这样既可以避免早期资源浪费，又可以为未来预留弹性拓展空间。
RBAC：若存在分级管理需求，可将角色管理权限下放，约定可管理数据范围；
ABAC：可引用规则引擎进行落地，但是支持哪些数据项可配置动态权限规则，需要经过详细需求分析和优先级识别后确定，对于不可自定义部分，需要考虑代码等方式来拓展实现；
对于RBAC、ABAC并存的情况，需要事先梳理可能存在的冲突情况，如RBAC仅约定角色可删除数据，但ABAC约定仅数据创建人可删除数据。需要引入冲突策略，按需开放配置。
因为“鉴权=身份认证通过后，判断用户是否具有功能权限（菜单/按钮）+数据权限（字段/数据）。”期间权限需要实时计算，甚至叠加高并发的情况，需要采用预处理、缓存等策略来避免长时间加载和反馈延迟的情况。
B端系统审计场景中，需要同时追踪角色分配与属性策略变更，日志结构复杂。
审计日志中主体、客体、操作等内容，记录信息需要包括角色-功能权限-数据权限等，再进一步按需细化至数据属性。
后续文章中将会对于B端系统构建中“用户中心标准化能力设计（3）：统一身份认证”进行介绍。
本文由 @西林 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。