一种基于角色访问控制模型的设计与实现

雷惊鹏

（安徽国防科技职业学院信息技术学院，安徽 六安 237011）

Web服务是互联网提供的主要服务类型之一。用户需求的多元化和技术的不断演进，使Web站点所提供的内容类型日趋丰富，由此带来的诸如计算、存储、网络等资源要求也更加严格。Web站点的架构越来越多地采用复杂的集群环境。在此背景下，快速而有效地实施项目开发、运维、管理，也变得更加困难。近年来，随着云计算技术的发展、成熟，业务系统可以被迁移到云平台，以此减轻开发和运维人员的压力。在业务系统的迁移过程中，应首要考虑安全问题。内容提供商注重数据隐私的保护，而云平台提供商则具有自身的安全规则，二者之间需要找到合适的平衡点才能发挥出最好的效果。

为了限制访问者（例如用户、服务等）对被访问者（资源）的访问权限，避免因为越权、误操作等带来的数据风险，对业务系统进行合理、合适的权限配置，是一项必要的工作。访问控制一般包含两个主要过程，即“鉴别”（Authentication）和“授权”（Authorization），前者用以检验访问主体身份的合法性，后者用以设置对资源的访问能力。

1 访问控制系统及其模型

访问控制技术是保证Web服务组合增值应用安全性和可靠性的关键技术［1］，也是实现保密性、完整性的主要方式。对权限访问控制技术的研究可追溯到20世纪70年代，其主要思想是对用户设置必要的系统资源访问权，让合法用户可以访问并且只能访问被授权的资源，并拒绝非法用户的访问企图，从而保障数据安全。一个完整的访问控制系统，包括“主体”“客体”“策略”三个主要元素［2］。其中，主体作为可直接访问系统的实体，以进程为主要形式，也可以是用户或其他子系统；客体通常是资源对象，是可被访问的被动实体，典型的客体形式是存放在系统中的各类数据资源；策略是一组行为规则集，用来描述主体如何访问客体，代表特定的授权行为。

由于可以对访问者的身份进行有效鉴别以防止非法访问，访问控制被广泛应用于各种业务系统的登录过程。目前学术界对访问控制的研究将权限管理分为系统权限和数据权限，前者适用于系统级别的权限管理，如操作系统权限、数据库系统访问权限等，后者一般根据具体的业务需求来进行设置。从实施的角度分类，访问控制采用的三种典型模型分别是MAC模型（Mandatory Access Control，强制访问控制）、DAC模型（Discretionary Access Control，自主访问控制）、RBAC模型（Role-Based Access Control，基于角色的访问控制）。三种模型的对比如表1所示。

表1 访问控制模型对比

1.1 MAC模型

MAC模型对恶意程序攻击（比如木马程序）具有一定的防护能力，最早由美国军方于20世纪70年代提出。

MAC模型为每个主体和客体赋予一个固定的安全属性（见图1）作为标记安全的特征，并根据此特征确定主体对客体的访问权。访问控制遵循两个基本原则以实现数据的机密性：一是“上写”原则，主体只能写入安全等级大于该主体安全等级的客体；二是“下读”原则，主体只能读取那些安全等级小于该主体安全等级的客体［3］。

图1 MAC模型

在MAC模型的实现上，D.Elliott Bell和Leonard J.LaPadula在1973年 提 出 了Bell-LaPadula模型（简称BLP模型）［4］，用来设定安全级别。尽管BLP安全模型在单向传输系统机密性的问题上提供了有效的解决措施，但其缺少对数据传输可靠性的保障，具有一定的局限性。

1.2 DAC模型

DAC模型允许用户针对客体制定个性化保护策略。该模型为每个主体设置一个用户名（用户隶属于用户组或具有特定的角色）。主体可以针对客体设置ACL（Access Control List，访问控制列表），该ACL用于在每次访问发生时检查用户标志，并根据标志定义实现权限控制。

DAC模型允许资源所有者将自身拥有的权限授予其他用户。一方面,这一特征使主体能对不同客体设置不同的访问权限，另一方面，不同的主体也可以对同一客体设置不同的访问权限。

1.3 RBAC模型

RBAC模型使用户角色（Role）与访问权限关联。根据用户角色决定用户在系统中的访问权限，以便实施授权和安全约束。该模型通过增加角色这一概念，将权限与角色之间、角色与用户之间建立关联，提高了授权的灵活性，更容易实现权限的最小化原则，以及职责分离等各种安全策略。

在众多研究中，以美国乔治梅森大学信息安全技术实验室（LIST）提出的RBAC96模型簇最具代表性［5］，其包括从RBAC0到RBAC3的四个概念性模型，RBAC0模型是核心部分，也是其他模型建立和改进的基础。RBAC0模型中的权限分配有用户与角色的分配、角色和权限的分配两种最基本的分配关系（见图2）［6］。

图2 RBAC0模型

以RBAC0为基础并将继承的概念引入角色中，可形成RBAC1。它将角色实施了进一步划分，形成不同的等级，且每个等级的权限有所区别，通过这种方式实现权限的细化。

RBAC2同样建立在RBAC0的基础上，但是添加了权限、角色和用户之间的限制，这种限制被称作“责任分离”，包括动态责任分离和静态责任分离（见表2）。而由RBAC1和RBAC2整合而成的RBAC3则适用于对权限要求非常高的系统，既具有RBAC1的角色特征，也具备RBAC2的各种限制。

表2 RBAC2责任分离特征

通过以上对不同权限控制模型的分析和比较，不难看出，RBAC模型通过灵活的角色映射机制，在很大程度上提升了系统的可扩展性，降低了管理上的复杂性。该模型在分配权限时，遵循三条最基本的安全原则：

（1）只赋予角色完成任务必需的最小权限集合，即权限的最小化；

（2）任一用户都不可能同时是互斥角色的成员，即职责分离；

（3）借助抽象许可的概念，实现在不同的层次对权限进行不同的定义，即数据抽象。

在一个典型的Web应用系统中，不同用户执行某些模块化的操作，如对文件内容的删改、对某些菜单或按钮等素材的访问，采用基于角色的授权模型更便捷、扩展能力更强。我们的系统也采用该方案设计和实践。

2 基于角色的权限管理系统

随着各类业务系统向云平台迁移，数据安全成为管理人员关注的首要问题，基于角色的访问实施权限控制成为热门研究方向。

2.1 权限管理系统的模块设计

基于角色实施访问控制的模型，不再直接面向用户分配权限，而是面向角色实施权限分配，将用户与角色、角色与权限建立关联，更加便于权限的分配、回收。在相对更大一些的系统中，可以通过“用户组”把特征、权限相同或相似的用户纳入到同一个组，以增加权限控制的灵活性。根据上述思路，我们设计了三个模块：用户（组）管理模块、角色管理模块、权限管理模块（见表3）。

表3 权限管理系统模块

在具体的系统层面，该模型把角色划分为管理者角色和访问者角色，前者具备管理用户（组）权限，以及创建、编辑和删除Web站点内容的权限，后者具备浏览内容的权限。

2.2 前后端设计

主要的功能模块确定后，我们在数据库服务器端进行功能实践。MySQL是很多Linux 发行版都能有效支持的数据库，例如本系统测试用的CentOS 7。对权限进行判断的逻辑为：通过识别用户标识符（ID），获得用户角色；如果该用户（组）属于超级用户（系统管理员），则该角色不受任何限制，可执行任何操作；如果是其他用户（组），则获得角色所属权限，并根据权限取得访问列表。

依据上述权限判断逻辑，设计并实现user表、role表及access表，分别对应用户、角色和权限。设计并实现user_role表、role_access表，调用前三张表中的ID字段对其建立关联。

我们基于SpringBoot框架设计数据库系统结构，开 发DAO层、Entity层、Service层、Controller层四个模块。每个模块实现一定的功能：DAO层负责实现对上述数据表内容的增、删、改、查等基本数据操作；Entity层作为实体层，包含实体类的属性和对应属性方法，例如set方法、get方法；Service层主要负责业务模块的逻辑应用设计，实现业务逻辑的独立性和功能复用，通过本层调用DAO层的接口，并接收由DAO层返回的数据；Controller层负责流程控制，实现前后端交互，处理前端请求并向客户端返回响应页面及数据。

权限管理系统的前端采用HTML/CSS/Javascript结构，通过Ajax函数向后端传值，而后端向前端返回JSON对象。利用Apache Shiro安全框架，设计并实现身份验证、授权等权限控制管理。获取用户权限信息这个过程是在Realm中完成的，包括继承AuthorizingRealm，重写接口获取用户的权限信息。

执行认证过程：

protected AuthenticationInfo doGet-AuthenInfo（AuthenToken authenToken）throws AuthenException {

//用户登录平台提交的用户名信息和密码数据封装在Token中

Log_Username_Password_Token username_Password_Token =（Username_Password_Token） authenticationToken；

//提交用户输入至数据库进行查询，获得用户信息

Log_User user = userService.queryByName（Username_Password_Token.getName（））；

if（user==null）{

return null；

}

return new NewAuthenInfo（log_user，log_user.GetPassword（），″″

）；

}

执行授权过程：

protected AuthorizationInfo doGetAuthorInfo（PrincipalCollection principalCollection）

{

Subject subject = SecurityUtils.getSubject（）；

Log_User currentUser = （Log_User）subject.getPrincipal（）；

//角色设置

Set roles = new HashSet<>（）；

roles.add（currentUser.getRole（））；

//角色权限设置

SimpleAuthorInfo info = new SimpleAuthorInfo（roles）；

}

3 利用Docker部署权限管理系统

3.1 Web站点架构的演进

传统的Web站点架构采用单机架构。由于业务系统数量与访问用户数量少，可以在同一台服务器上部署Web服务器和数据库系统。此时的访问流程是：浏览器访问某域名（例如web.test.com）时，通过DNS服务器（域名系统）的解析，把目标域名转换为Web服务器的真实IP，随后客户端浏览器转而访问该IP对应的Web站点。这种架构实现起来非常直观、简单，但是随着用户数的增长，其性能已不足以支撑业务需求。

通过将诸如管理、鉴权等功能代码进行抽象，形成单独的服务进行管理，是近年来“微服务”的主要思路。“微服务”架构是一项在云中部署应用和服务的新技术［7］。服务和应用之间通过不同形式的请求（例如HTTP形式、RPC形式等）访问公共服务，并通过解耦服务和应用的各个组件，实现更加便利的升级与扩张。

3.2 利用Docker实现系统部署

Docker为“微服务”架构提供了落地实施方案。目前云计算技术以IaaS（Infrastructure as a Service，基 础 设 施 即 服 务）、SaaS（Software as a Service，软件即服务）、PaaS（Platform as a Service，平台即服务）为主要形式。Docker属于PaaS，是一种操作系统级别的虚拟化技术。Docker作为目前最流行的一种业务系统部署方式，解决了复杂的环境配置要求、不同平台下的运维测试、较低的资源利用等问题，实现“一次开发、多处应用”的目标，为软件开发人员和网络管理人员都带来了极大的便利。

Docker的工作结构采用了典型的C/S （Client/Server）架构。Docker守护进程（Daemon）提供服务端功能，响应客户端需求，采取本地部署或远程部署方式，通过Rest API与客户端实现通信。图3显示了Docker的架构和工作流程。

图3 C/S架构的Docker

容器、镜像、仓库是Docker技术三个最重要的概念。镜像提供了软件及其运行环境，并以只读文件系统的形式出现；容器是运行的镜像，是在原有只读文件系统之上再挂载了一层可写的文件系统；仓库则提供了镜像的存储场所，可以是本地仓库或是置于互联网上。

镜像底层采用引导文件系统（Bootfs），包括用于初始化处理工作的启动引导程序Bootloader和被调用的系统内核Kernel。进行必要的初始化之后，在Bootfs之上挂载只读型根文件系统Rootfs（Root Filesystem）。Rootfs层包含有基础镜像层，以及可在基础镜像层之上继续挂载的多个只读层。每个只读层包含运行容器所需的文件系统（即目录及文件）。容器即以此种层层“叠加”而成的镜像为基础，由Docker Daemon程序在只读层上构建一个可写的文件系统层，从而实现读写功能。

接着编写Dockerfile定义项目运行所需的镜像。Dockerfile由多条指令构成，根据UnionFS 的设计理念，Dockerfile中的每条指令在上一层镜像之上生成一个新的文件系统层（除了首条FROM指令），同时原镜像被新镜像覆盖。典型的关键指令如表4所示。

表4 Dockerfile典型指令集

按照规定的格式和命令集编制配置文件，实现个性化的镜像定制。图4所示代码显示了通过基础镜像CentOS 7定制Web服务器程序及其运行环境。

图4 通过Dockerfile定制镜像

Docker 引擎调用build程序实现从 Dockerfile 构建镜像。图5显示了这一过程。每一个Step的顺利执行，都是在原有镜像基础上覆盖一层新的只读文件系统，直至正常结束。

图5 镜像形成过程

实际的业务系统往往需要多个镜像、多个容器的支持才能正常运行，因此需要有实现容器编排功能的组件。Docker-Compose承担了这一功能。通过对容器进行编排，用户可以定义和运行多个容器。Docker-Compose 依靠YAML文件实现编排功能，图6显示了本系统数据库容器的YAML文件，该文件有严格的语法要求。图7则显示了YAML文件被调用的方法。

图6 实现容器编排的YAML文件

图7 调用和执行YAML文件

完成系统部署后，测试用户提交登录请求，服务端程序首先执行认证过程，负责解析用户请求内容，并根据请求内容、参数等信息调用授权过程；全部响应过程处理完成后访问页面反馈处理结果。

4 结语

我们结合权限分配和管理的问题，分析了三种典型的权限控制模型，通过对三种模型的特征分析，设计并实现RBAC模型系统。在测试该系统的功能时，为了解决开发环境依赖、部署过程复杂、资源使用效率低下的问题，我们选择了通过云计算技术进行部署测试，并在Docker容器中实际部署和测试了系统的有效性。

实验结果同时表明，以Docker为代表的容器技术，在实现业务系统一次构建、多处运行的目标方面，能有效提高工作效率。