在互联网项目中，权限设计是一个非常重要且基础的安全能力。
一个合理、清晰、可扩展的权限体系可以帮助企业或团队有效地进行用户、资源以及操作的管控。
当前主流的权限设计模型主要包括 RBAC（基于角色的访问控制） 和 ACL（访问控制列表）
一、RBAC（Role-Based Access Control，基于角色的访问控制）
1. 核心概念
RBAC 模型主要将权限与角色绑定，而不是直接将权限分配给用户。核心概念包括：
- 用户（User）：需要被授权操作系统资源的主体，一般是业务中的个人账号或系统账号。
- 角色（Role）：用户所扮演的身份，每种角色代表一组权限的集合。例如：管理员、运营人员、普通用户等。
- 权限（Permission）：可以执行的操作或可以访问的资源。例如：查看用户列表、编辑用户信息、删除用户数据等。
- 会话（Session）：用户与系统之间的一次交互会话，用户在会话过程中通过所具有的角色来访问资源。
在 RBAC 模型中，用户通过“被分配角色”来间接获得权限，这样就将权限管理和角色管理分离，提高了系统灵活性和可维护性。
2. 模型变体
RBAC 根据具体的业务复杂程度和安全需求，可进一步衍生出以下几种典型变体：
-
RBAC0（核心 RBAC）
只包含最基本的用户—角色—权限映射关系，适合简单的权限体系场景。 -
RBAC1（基于层次关系的 RBAC）
在 RBAC0 基础上增加了角色继承/层次结构（Role Hierarchies）。上级角色可以拥有下级角色的全部权限，方便管理者在角色需求多级化时快速复用权限。 -
RBAC2（基于约束的 RBAC）
增加了一些约束机制（Separation of Duties，Least Privilege 等），提高安全性。例如一个用户不能同时拥有关键操作的两个角色（如财务审批和财务审核角色）。 -
RBAC3（综合模型）
结合了 RBAC1 和 RBAC2 的特性，同时包含角色继承和更严格的访问约束，适用于对安全合规性要求较高、角色关系复杂的大型企业系统。
3. 优点与缺点
优点
- 易于管理：只需在角色上进行权限分配，然后将用户与角色关联即可，方便对角色进行统一授权和回收。
- 可扩展性强：新增需求时，可以只新增或修改角色和权限的映射关系，而不需频繁地更新对每个用户的权限。
- 适合组织化场景：尤其是公司内部或管理后台，有明显的岗位角色区分，RBAC 能更好地映射业务逻辑。
缺点
- 细粒度受限：对于精细化权限控制（例如，对同一资源的某些字段可以访问、某些字段不可以访问），RBAC 需要进一步结合其他方法或更细分的角色才能实现。
- 角色膨胀：当业务中需要细分的权限非常多，角色可能会被不断拆分，导致数量不断上升，运维成本加大。
二、ACL（Access Control List，访问控制列表）
1. 核心概念
ACL 模型是一种更细粒度的访问控制方法，用于定义对特定资源或对象的权限列表。在许多文件系统及网络层安全策略中常见到 ACL 的应用。在互联网项目中可用来做资源级或对象级的权限判定。
- 主体（Subject）：可发起访问请求的实体，比如用户、用户组或其他进程。
- 客体（Object / Resource）：被访问的资源，如文件、数据表、接口等。
- 权限（Permission）：可对资源执行的操作，如读取（Read）、写入（Write）、修改（Modify）、删除（Delete）等。
- 访问控制条目（ACE）：每个资源上都维护一份列表，记录了哪些主体拥有哪些具体的权限。
在 ACL 模型下，每个对象（资源）都有一个访问控制列表，列举了可以访问该对象的主体及其对应操作。如果某个用户不在列表中，则没有权限访问或执行对应操作。
2. 常见实现方式
文件系统中的 ACL
常见的如 UNIX 系统中的chmod、chown、chgrp等命令背后就是最基本的 ACL 实现，同时在现代操作系统中也支持更丰富的 ACL 机制以指定更细粒度的访问规则。数据库级或表级 ACL
数据库经常需要为不同用户或应用设置不同访问级别，比如某个数据表仅允许业务 A 读写，业务 B 只读，其他无权限等。微服务 API ACL
通过 API 网关或服务的配置来限制哪些客户端或 Token 可以访问哪些 API，以及对应的操作权限等。
3. 优点与缺点
优点
- 细粒度控制：能够做到对单一资源、单个操作的精确控制，满足更高的安全需求。
- 灵活性：可以针对不同对象设置单独的访问策略，多主体、多权限维度下依然可以灵活实现各种业务需求。
缺点
- 管理复杂度较高：在规模较大的系统中，每个资源都可能需要维护自己的权限列表，一旦资源或主体增多，维护难度会明显上升。
- 适用范围：ACL 更适合资源分散且要求逐一配置的场景，不太适合管理后台等对角色有较强需求的场合。
三、RBAC 与 ACL 的对比及应用场景
| 对比维度 | RBAC（基于角色） | ACL（访问控制列表） |
|---|---|---|
| 授权颗粒度 | 粗粒度，基于角色来分配权限 | 细粒度，可针对单一资源逐一授权 |
| 适用场景 | 组织化程度高、角色分明的业务后台、企业内部系统等 | 需要灵活定义不同资源权限，特别是文件、数据库或特定的微服务接口 |
| 维护成本 | 角色设计得当时整体管理成本较低 | 对资源和主体的数量敏感，资源/主体越多，ACL 配置管理越复杂 |
| 扩展性 | 新增角色、调整角色继承相对简单 | 新增或变更资源需要逐一修改 ACL 列表 |
| 安全性 | 通过角色继承、权限分离等方式满足安全需求 | 可以做更精细的权限设置，但要求更严格的维护和监控 |
在互联网项目中，RBAC 与 ACL 并非完全对立，在真实业务中经常会结合两者的优点来使用，比如：
- 基础采用 RBAC：先给用户分配合适的角色，确保大部分通用操作适配角色权限。
- 局部结合 ACL：针对少数需要更细粒度管控的核心资源（如文件、配置项、部分 API 端点等），用 ACL 做到更加精准的权限授予或限制。
四、实践建议
角色体系与组织结构保持一致
在设计 RBAC 时，可以先梳理组织架构或常见岗位，按业务需求将权限进行归纳分组，避免角色过度细分带来的管理复杂度。公共权限与差异化权限分离
对于多数用户都需要的通用权限，可放在公共角色；少部分特定人群需要的额外权限，可单独定义角色或使用 ACL 进行精细管控。分层管理
对大型系统可采用多层次或多级 RBAC 设计，在上层对大的角色进行定义，在下层再用细分权限或 ACL 针对特定资源或对象进行进一步控制。完善的审计和变更机制
不论是 RBAC 还是 ACL，在权限变更时都要做好审计、审批流程，留存操作记录，避免误操作或被恶意修改。安全与性能平衡
要同时关注系统性能与安全性，过度细粒度的权限检查会增加数据库或认证中心的查询压力；而过于粗放的权限则可能带来安全风险。可以借助缓存或智能权限引擎（如基于策略的 ABAC）来优化性能和灵活性。
总结
在互联网项目中，RBAC（基于角色的访问控制）和ACL（访问控制列表）是两种常见且主流的权限设计模型。
- RBAC：更关注组织化的角色定义和分配，适合大多数企业后台或内部管理系统，通常与组织架构紧密结合，易于维护和扩展。
- ACL：更关注资源的细粒度权限控制，适合对敏感或特定资源进行逐一配置、灵活度更高，但对规模和管理提出更高要求。
实际业务中常常将 RBAC 与 ACL 结合：用 RBAC 管理大部分通用权限，用 ACL 处理特定资源的精细化权限管控。通过合理的模型搭建和运维策略，可以在确保安全合规的同时，提升系统的管理效率和灵活性。
