访问控制权限——RBAC技术文档

一、RBAC介绍

权限管理功能是信息管理系统不可或缺的重要组成部分，是保证信息系统安全性的前提和基础。权限管理可以对用户的登录进行验证，对系统的资源访问进行鉴权，防止用户对系统越权使用，保障数据在采集、存储和传输过程中的安全性。RBAC基于角色的权限访问控制(Role-Based Access Control) 是商业系统中最常见的权限管理技术之一。RBAC是一种思想，任何编程语言都可以实现，其成熟简单的控制思想越来越受广大开发人员喜欢。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。

二、需求分析

2.1 可行性分析

2.1.1 社会可行性

权限管理负责保护数据安全，防止其被破坏、篡改或泄露，是应用软件正常运行的基本安全保障。权限管理的基本原理是为系统中的每一个操作定义好所需要的权限，并根据用户工作内容的需要，为用户分配好特定的权限，以方便其对指定资源的访问。不同等级的权限可以访问的资源可能截然不同，当用户在业务系统中访问某个资源时，权限管理功能只需要判断，当前用户已分配的所有资源访问权限中是否包含当前访问所需要的权限。若包含，则允许用户继续执行对当前资源的访问，反之则拒绝用户的操作要求。权限管理根据职位分工的不同为不同用户分配不同的资源访问权限，并通过鉴权防止用户的越权操作，避免用户的失误操作或恶意访问，保障了系统资源的安全性。而对于包含多个业务应用的复杂系统，若针对每个应用设计一套权限管理功能则不仅开发过程十分繁琐，而且会增加系统上线后管理的复杂度，费时费力，容易造成人力和物力资源的极大浪费。因此，设计出一款通用的权限管理系统，让多个业务系统只需集成到通用权限管理系统，即可实现对业务系统权限功能的集中统一管理，便显得尤为重要。因此，设计一款通用的权限管理系统已成为信息系统开发中的重点需求，可以有效节约多业务应用系统的开发成本，促进社会信息化的发展。

2.1.2 技术可行性

本系统采用B/S架构，用户在使用本系统时无需安装客户端软件，只需要通过浏览器即可进行访问。系统运用MVC开发模式，实现前后端分离。其中后端以Java作为开发语言，由于Java具有高度的可移植性，因此系统可以部署在任意操作系统的服务器上。以Spring Boot+MyBatis 作为开发框架，采用MySQL 数据库技术来进行数据的存储，并使用 Maven 来进行系统资源的管理和项目的构建，采用GIT进行代码版本控制；前端采用Bootstrap+jQuery作为开发框架，并使用AJAX技术和后端进行数据交互。以上技术都是当前成熟且主流的技术，因此采用上述技术进行设计开发通用权限管理系统是可行的。

2.2 功能需求分析

权限管理功能让不同身份的用户，具有对系统资源的不同操作权限，以达到避免越权操作、提高系统资源安全性的目的。对于包含多个业务应用的信息系统，其权限管理必定十分复杂。通用权限管理系统能够集成到多个业务系统中，对业务系统中的权限控制进行统一的管理，节约开发及管理成本。系统总体功能有用户信息管理、角色信息管理、权限信息管理、组织机构管理、应用系统管理和菜单信息管理6个部分。并且，权限管理系统还应支持对用户令牌的验证、登录时账户密码的验证以及对用户操作的鉴权。

2.3 性能需求

2.3.1 数据安全性

系统数据安全是至关重要的，系统要保证系统敏感数据的安全，要求对一些安全级别较高的数据采用加密的方式，防止一些不法分子通过注入来获取甚至篡改数据，关闭通过HTTP方式实现数据访问模式，只允许系统超级管理员访问权限管理系统。

2.3.2 实时性

由于业务系统的所有访问都需要请求权限管理系统进行鉴权，当用户访问业务系统时，不仅要等待业务系统的响应，中间还要等待权限管理系统的鉴权响应。为了不让用户在操作时等待过长时间，必须提高权限管理系统的响应速度，鉴权响应时间不能超过1s。

2.3.3 可扩展性

随着时间的推移，系统往往会伴随着业务需求的变动。而如果对系统进行重新设计开发则容易造成人力、物力资源的浪费，因此往往会在原系统的基础上进行升级。为了保证能够顺利完成更新升级，系统必须要具有良好的可扩展性。首先系统在设计时需要采用MVC 模式，实现系统的业务逻辑层、数据层和表现层相分离，使得当某一层级发生改变时，其他层级不发生变动或者变动较小；其次遵循“高内聚、低耦合”的思路，对系统功能进行模块化设计，保持各个模块之间的相对独立性，当一个模块发生异常时，其他模块仍然可以正常使用，并且在维护时还可以快速定位到异常发生的位置。最后，在开发时必须严格按照标准化要求进行文档和代码的编写，充分考虑将来系统扩展的需求，预留好相应的接口和方法。

三、RBAC模型描述

RBAC模型主要存在以下核心元素：User、Role、Permission、Session、用户角色分配、权限角色分配、约束条件。
定义1：User，对数据或者资源进行访问的主体。用U来表示集合。U={ User1、User2、User3…Useri，Ui∈U}。
定义2：Role，每个角色代表一定的职责，用R表示集合。R={ Role1、Role2、Role3…Rolei，Ri∈R}。
定义3：Permission，对数据或资源进行访问的许可。用P表示集合。P={Permission1、…Pi，Pi∈P}。
定义4：Session，角色的初始化必须通过用户会话来完成。用S表示会话集。定义4.1：会话和用户之间的映射用S-U表示，对应关系为n-1。定义 4.2：会话和角色之间的映射用S-2R表示，对应关系为 n-n。
定义5：用户角色分配，具体实现方法是将用户集U与角色集R间做广义笛卡尔积，即U×R={tutr︱tu∈U∧tr∈S}，其中UA⊆ U×R。
定义6：权限角色分配。这种分配关系同样是将权限集P与角色集R间做广义笛卡尔积，即 P×R={tptr︱tp∈P∧tr∈R}，其中PA⊆ P×R。
定义7：约束关系(Constraints)指整个模型的一些列约束条件。典型的约束关系包括：权限互斥﹑角色互斥。定义7.1：权限互斥(Permission Mutual Exclusion)对任意两个互斥权限Pi和Pj以及用户A，若 Pi∈UA§，则Pj∉UA§。本文用符号“ ∅ ”表示权限互斥。定义7.2：角色互斥(Role Mutual Exclusion)对任意两个角色Ri和Rj以及权限P，若满足Ri§ ∅ Rj§，则称Ri和Rj角色互斥。RBAC模型的原理如图1所示。

图1 RBAC模型原理图

通常RBAC模型由4个子权限模型组成，分别是基本权限模型RBAC0、角色分级权限模型RBAC1、角色限制权限模型RBAC2和统一权限模型RBAC3。

3.1 RBAC0层分类

在系统中的所有最小粒度权限，可分为五个类别：用户类（U）、角色类（R）、对象类（O）、操作类（J）、许可类（P）。 这些最小粒度权限用RBAC0表示。 五个类别权限相互之间可定义1∶N，M∶N关系，如下：
(1) U∶R ＝ M∶N
(2) O∶J ＝ 1∶N
(3) R∶P ＝ 1∶N
(4) O∶P ＝ 1∶N
(5) J∶P ＝ M∶N
权限被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

3.2 RBAC1继承关系

RBAC1定义角色的继承关系，继承关系使得权限管理灵活性得到提升，从管理角度出发，管理者拥有普通员工的权限，也扩展相应职能特权，则管理者继承了普通员工权限。RBAC1也可实现多继承关系，进一步提升角色间权限赋予的灵活性。

3.3 RBAC2约束关系

RBAC2定义了权限约束关系，包括权限间继承的约束、用户指派角色的约束、活动用户行使的权限范围约束。 在RBAC2中，具体访问许可由用户、角色、权限三者关系决定。RBAC2约束关系使得权限管理安全性提升，但过多的约束关系会使得RBAC1的继承关系管理变得更加繁琐。因此，RBAC2约束关系的定义应从总体需求出发进行规划。

3.4 RBAC3复合关系模型

RBAC3是包含一系列复合关系的模型，是对角色-用户关系的定义，关系模型为M∶N；称为用户角色分配和角色许可分配。

3.5 RBAC⁃权限集模型分析

传统的RBAC只针对用户作为权限拥有者，用户具有对资源、数据、网络等操作的许可，RBAC1、RBAC2、RBAC3是用户权限关系的集合。 随着业务系统的复杂性增加，本文将系统中一些用户分组，提取分组用户所有权限，称为权限集，按照继承关系⁃约束关系⁃复合关系分析组内权限，计算复杂度，按复杂度进行权限修正。RBAC子权限集要满足安全性、灵活性、便捷性三个特点，进一步分析梳理，确定参与权限集复杂运算的主要包含对象有：用户数、角色、分组权限类别、RBAC层次权值、权限关系权重。主要的关系有：分配用户（组）角色、分配角色权限；将用户与权限通过角色隔离开，减少了用户权限赋值关系太多时带来的管理难度。用户⁃角色⁃组关系如图2所示。

图2 用户⁃角色⁃组关系

角色：一定数量的权限的集合。角色权限分配的原则是：不与其他角色所拥有的权限产生交集。在本模型中，角色权限来源于RBAC0层。
用户组：用户组与角色是M∶N的关系，即用户组可以有多个角色，角色可以有多个用户组。按照角色权限分配原则，在遇到1∶N关系时，用户组需要进行并集运算，提取权限元素，避免角色之间产生权限交集。

3.6 RBAC分层模型分析

3.6.1 便于授权管理

在传统的访问控制中，用户或其职能发生变化时，需要进行大量的授权更改工作。 在RBAC中，用户的职能改变时，重新指定相关角色即可，而角色的权限一旦定义好，就很少去更改。 要对角色的权限进行更改，只需要修改角色的功能或定义新角色，而不必更新每一个用户的权限设置。

3.6.2 角色划分

RBAC将角色组织起来，能够很自然地反映组织内部人员之间的职权、责任、赋予关系，也可以使用类似PowerDesigner的工具，导出权限关系，为系统权限设置优化提供参考。

3.6.3 赋予最小权限原则

权限的分配应以实际业务需求为标准，即用户尽可能分配职责规则的权限，避免用户拥有冗余权限而带来安全问题。本文分析了RBAC权限继承、约束、复合关系，定义了关系间的分配原则，从不同维度解释权限关系。

3.6.4 职责分离

在一些业务场景，往往需要多个不同角色的用户完成一项业务，例如企业流程审批，需要多个用户参与。如果让某一个用户完成该业务处理，则该用户需要赋予较大权限，这在一些金融、政府、军队等行业容易造成人为的安全事故。因此，对于某些特定的操作，需要进行职责分离，RBAC较为灵活地提供了该支持。

四、系统功能设计与实现

4.1 系统功能设计

4.1.1 用户信息管理模块设计

管理员登录系统后，可以对用户信息进行维护：包括添加用户信息、修改用户信息、查询用户信息、删除用户信息和冻结/解冻用户等操作。用户管理模块中包含了所有能够访问业务系统的用户信息，用户信息中包含了用户登录系统的账号和密码。当用户被创建时，系统将会为用户指定一个初始密码，初始密码是一个随机字符组合，初始密码将以邮箱的形式发送给用户。当用户首次登录系统时，需要修改密码。当用户忘记密码时，系统支持用户根据邮箱找回密码。只有当用户账户被创建后，该用户才能访问业务系统，若用户被删除则无法再使用系统。同时，系统支持对用户账户的冻结和解冻，管理员可以对任意账户进行冻结和解冻。用户被冻结后，将无法使用系统，直至解冻后方可继续使用系统。

4.1.2 组织机构管理模块设计

为了使系统适应不同规模的管理需要，保障系统在规模庞大、组织机构复杂的单位中顺利运行。系统在RBAC的基础上，还添加了对组织机构的管理。管理员登录系统后可以对组织机构进行维护，包括添加组织机构信息、修改组织机构信息、查询组织信息以及删除组织机构信息等操作。同时，系统还支持树形结构的机构管理，以构建组织机构的层级关系，即每个组织机构下可以创建若干个子组织机构，而每个子组织机构依然可以根据需要创建下属机构，使得管理者可以方便快捷地根据组织规模需要添加下属公司、单位、机构和部门等。

4.1.3 角色信息管理模块设计

基于角色的访问控制是目前比较流行的一种权限管理方案，实现了用户与权限之间的逻辑分离。所有角色创建在组织机构下，每个组织机构根据需要可以创建不同的角色信息。管理员登录系统后，可以对角色信息进行维护，包括添加角色信息、修改角色信息、查询角色信息和删除角色信息等操作。此外，管理员还可以给用户分配角色，一个用户可以分配多个角色，并且这些角色可以属于不同的组织机构，同一个角色也可以分配给多个不同的用户。

4.1.4 应用信息管理模块设计

除了本权限管理系统外，系统还需要支持添加若干业务应用系统。为了支持不同的应用拥有不同的菜单及权限，并方便对多个应用的登录及鉴权进行统一管理，系统添加了对业务应用系统的管理，包括添加应用信息、修改应用信息和删除应用信息等操作。

4.1.5 菜单信息管理模块设计

为了保证不同角色的用户登录后会进入到不同的页面，执行不同的操作，首先需要让不同用户拥有不同的菜单。所有菜单信息都创建在应用下，每个应用根据需要可以创建不同的菜单信息。管理员登录系统后，可以对菜单信息进行维护，包括添加菜单信息、修改菜单信息、查询菜单信息和删除菜单信息。管理员还可以为角色分配菜单，一个角色可以分配多个菜单，并且这些菜单可以属于不同的应用。

4.1.6 权限信息管理模块设计

为了支持不同角色的用户拥有不同的操作权限，系统添加了对具体操作权限的定义和维护，包括添加权限信息、修改权限信息、查询权限信息和删除权限信息。每个权限代表对系统中不同资源的操作功能，当用户具有某项权限时，便能对指定资源执行对应的操作。所有权限信息都创建在应用下，每个应用根据需要可以创建不同的权限信息。此外，管理员还可以为角色分配权限，一个角色可以分配多个权限，并且这些权限可以属于不同的应用。

4.2 权限控制设计

4.2.1 用户登录过程设计

为了保证系统运行的安全性，避免数据被恶意获取和篡改。系统所有功能都必须在用户成功登录后才能访问，并使用SHA-256哈希算法对数据库中的用户密码进行加密，防止用户密码泄露。当用户访问业务系统时，业务系统首先判断用户是否登录，若未登录，则判断当前用户的Cookie中是否包含令牌，若不包含令牌，则强制跳转到登录页面，提示用户先输入用户名密码进行登录才能访问系统。若用户包含令牌，则业务系统将请求权限管理系统判断用户令牌是否有效，若无效，则跳转到登录页面，提示用户输入用户名密码。用户输入用户名和密码后，业务系统将请求权限管理系统进行验证，验证通过即可登录成功。

4.2.2 用户操作权限控制

为了控制不同用户的操作权限，防止越权访问，系统对于用户的每一个操作都要进行鉴权。当用户登录成功时，权限管理系统将从数据库中读取用户的所有操作权限信息，并将这些权限信息作为集合存储到内存中，并使用用户的身份信息作为索引，建立起用户身份信息和权限集合信息的对应关系。当用户在业务系统中发出执行某项操作的请求时，业务系统将首先请求通用权限管理系统进行鉴权。业务系统只需要将用户的身份信息和指定操作所需的权限信息传入到通用权限管理系统的鉴权接口，然后根据其返回结果即可确定用户是否具有执行该项操作的权限。通用权限管理系统接收到业务系统的鉴权请求后，则根据用户的身份信息获取前用户存储在内存中的权限信息集合，判断该集合中是否包含执行当前操作所需的指定操作权限，并将鉴权结果返回给业务系统。若当前用户包含对应的操作权限，业务系统则允许用户进行操作，反之则禁止用户执行当前操作，并强制用户退出当前系统。

4.3 数据库设计

本系统采用开源的MySQL数据库系统进行数据存储。完成系统功能所需的数据表有用户信息表、组织机构信息表、角色信息表等。数据表结构设计为：用户信息表（用户id、用户名、密码、昵称、性别、联系电话、电子邮箱地址、角色编码、删除标志位、创建人id、创建时间、修改人id和修改时间）；组织机构信息表（组织机构id、组织机构编码、组织机构名称、删除标志位、创建人id、创建时间、修改人id和修改时间）；角色信息表（角色id、角色编码、角色名称、父角色id、组织机构id、删除标志位、创建人id、创建时间、修改人id和修改时间）；应用信息表（应用id、应用编码、应用名称、删除标志位、创建人id、创建时间、修改人id和修改时间）；菜单信息表（菜单id、应用id、菜单标题、父菜单id、菜单级别、菜单url、菜单类型、删除标志位、创建人id、创建时间、修改人id和修改时间）；权限信息表（权限id、操作名称、操作编码、删除标志位、创建人id、创建时间、修改人id和修改时间）；用户角色关联表（用户id、角色id）；角色菜单关联表（角色id、菜单id）；角色权限关联表（角色id、权限id）。

五、RBAC模型分析

首先，RBAC模型减少了授权管理中大量重复性的操作。其次，RBAC模型确保了对系统资源的有效访问控制，用户不可以将访问权限共享给其他用户，提高了安全性。最后，它为企业安全策略的变化提供了发展空间，管理者可以根据实际情况来定义需要的角色，并为之分配用户与权限。

参考文献：
[1] 鞠博,边臻.RBAC模型在访问控制中的应用[J].福建电脑,2022,(09):37-40.
[2] 杨福军,丁涛,付眸等.基于RBAC的权限复杂性与可靠性控制模型研究[J].计算机应用与软件,2022,39(01):30-38+59.
[3] 张丽丽,邬锡江,杨玉梅等.基于RBAC的权限管理设计与自主开发应用[J].现代信息科技,2020,4(16):88-91.
[4] 杨晟,罗奇.基于RBAC的通用权限管理系统设计[J].科技创新与应用,2022,(09):123-126.
[5] 苏兵.基于Spring Security的权限管理系统的设计与实现[J].电脑与电信,2023,(09):24-31
[6] 周超,任志宇.结合属性与角色的访问控制模型综述[J].小型微型计算机系统,2018,39(04):782-786.