朱永强 方 意 宫学庆

(华东师范大学计算机与软件工程学院 上海 200062)

0 引 言

访问控制是根据系统设定的访问权限授予认证通过的访问用户的过程，它作为信息系统的核心内容之一，直接影响着一个系统的安全与效率。随着互联网技术的快速迭代，微服务架构[1]以其灵活拓展、独立部署等优点在互联网应用中被广泛采用。一些流行的微服务框架比如Spring Cloud、Dubbo、HSF等在互联网公司的主要业务中扮演举足轻重的角色。与此同时，访问控制在微服务架构的信息系统中会变得更加复杂，因此研究该问题有较为重大的意义。

如图1(a)表示的是单体系统访问控制流程，单体系统的访问控制通常采用集中式的管理方式。第1步通过权限控制模块识别用户的身份信息，并进行身份认证；第2步根据已制定的访问规则来约束访问行为；第3步访问相应的功能的业务模块。单体系统的访问控制模块跟业务模块在同一进程中，通过维护有状态的用户登录信息进行访问控制，如Session等技术。图1(b)表示的是微服务架构下的访问控制方式。它将传统的单体系统根据业务内容被拆分成若干个不同的微服务实例，访问控制模块可以单独成为一个服务，也可以拆分到在各个业务服务中。相比较单体系统的访问控制方式痛点如下:

(1) 当访问者不仅仅是用户，还包括其他服务的调用时，单体系统架构下访问控制的管理方式就不再满足需求。要考虑访问入口适用的场景，会出现用户与服务间的鉴权、服务与服务间的鉴权等多种场景。

(2) 微服务架构下的访问请求一般是无状态的，导致用户的每次请求都需要进行访问控制，这样使得访问控制模块的访问压力变大。

(3) 微服务架构下的系统需要管理一些特有的资源信息，比如对服务实例信息的管理。该管理方式是在传统负载均衡技术的基础上可以增加对服务实例访问的管理，对不同访问请求设定提供服务的实例信息，从而提高系统管理的灵活性。

访问控制模型是用来表示访问者与访问资源间的关系，这种关系是访问中遵守的规则与策略。RBAC(Role-Based Access Control)是目前信息系统中广泛认可的访问控制模型，目前在微服务架构下基于RBAC访问控制模型还没有较为成熟的方案。微服务架构下，传统的权限管理模型不能满足微服务场景的需求，体现在对不同服务提供的Restful接口、服务实例信息、服务间调用权限等信息的管理。此外，用户权限管理数据库与资源数据库是分库存储设计，因此在进行权限的校验操作时需要对权限管理过程进行控制。

基于上述痛点，本文将在RBAC模型的基础上提出微服务下的权限管理模型MSAM。该模型可以提供一套微服务架构下包含服务间权限管理、服务实例信息管理等的细粒度权限管理机制。此外，下文还将介绍通过集中式权限数据库与分布式权限数据库两种方式来讨论基于微服务架构的访问控制设计方案。

1 访问控制模型及实现

本节研究并分析了RBAC模型及其衍生模型，并从库表设计、访问模块、认证与鉴权框架等方面介绍了相关的实现方案。

1.1 RBAC模型

RBAC模型最初是由D. Ferraiolo 和R. Kuhn提出[2]，引入了角色的概念并给出了基本的语义。其主要观点是将权限信息赋予给角色来管理，通过给用户分配不同的角色，从而实现将权限对用户的分配。

近年来RBAC模型的发展中，研究较为全面且公认的是美国国家标准与技术研究院于2001年制定出的NIST RBAC模型[3]，其中后者是对前者的抽象与概括。NIST RBAC模型分为4个层次，从基本到复杂依次为基本模型Flat RBAC、角色分级模型Hierarchical RBAC、角色限制模型Constrained RBAC和均衡对称模型Symmetric RBAC等4个等级，这4个等级的功能是递增的。

1.2 RBAC的衍生模型及实现

1.2.1 拓展型权限管理模型E-RBAC

E-RBAC(Extended Role-Based Access Control)[4]模型是在RBAC模型的基础上增加了用户授权的机制。如图2所示，E-RBAC模型通过用户和角色组合授权的方法，使得权限控制的方式变得更加灵活。

图2 E-RBAC模型图

该模型在库表设计中用户信息表与角色信息表为同一张数据库表，并在该表中设置“是否角色”的字段用来区分数据表中的元组是用户还是角色的元组。该模型考虑了对数据库空间的合理使用，与传统的RBAC模型比较，优势在于一方面将用户信息与角色信息放置在同一张表中管理，通过属性字段来加以区分，减少了数据库模式设计；另一方面提出了增加用户与权限进行关联的设计，使用用户和角色混合授权。

但随着用户信息的增加，这种设计方式会导致数据库表字段出现大量的空值，不利于数据库表的维护与处理。另外，这种设计形式会增加额外判断条件的处理，影响访问控制的效率。

1.2.2 USAM通用权限管理模型

USAM(Universal Scheme of Authority Management)模型[5]提出了一种管理功能权限和数据权限更加有效的方式。如图3所示，该模型在传统RBAC的功能权限的基础上根据实际业务场景增加了数据权限的管理。该模型拓展了RBAC基本模型，包含用户、角色、组织表、资源、功能权限、数据类型、数据对象、操作类型等8个实体。

图3 USAM模型图

该模型相比传统RBAC模型的优势在于一方面将权限信息拆分为资源信息与操作类型信息，使得权限信息更加细化，方便用户对权限信息的管理；另一方面在用户、角色、权限实体中增加了用户与角色间对权限屏蔽关系的设计，可以灵活修改需要屏蔽的角色权限。

该模型的缺点在于对角色权限出现重复的情况未进行分析说明，这种情况下权限屏蔽操作的维护信息较难处理。此外，数据权限的管理过于复杂，影响系统处理效率。

这两种RBAC的衍生模型虽然在传统的权限管理系统都能实现访问控制模型的功能，但是在微服务场景下仍会出现对服务间权限功能以及数据权限不满足等问题。所以在微服务场景下需要提出相应的访问控制模型来实现对应场景的访问控制方案。

1.3 微服务架构下的访问控制方案

1.3.1 单点登录

在微服务场景下，访问请求往往是无状态的，这就意味着每次请求需要进行权限校验，但是系统需要单个身份认证的访问入口。单点登录(SSO)[6]使得每个提供资源的服务都必须与认证服务交互，这会产生大量的网络开销，在微应用的个数增多时，这种方案的弊端会尤为明显。

1.3.2 分布式Session方案

分布式Session[7]方案原理是将用户认证的信息存储在共享内存中，通常由用户Session实现方式是简单的分布式哈希映射。当用户登录微服务系统后，用户信息可以从共享存储中获取，下一次请求中以Session ID的方式请求，便可获取用户信息。该方案是支持高可用且可扩展，缺点在于共享存储需要一定保护机制，需要建立安全的链接进行访问，这便提高了系统复杂性。

1.3.3 令牌与API网关结合

随着微服务、Docker等技术的兴起，基于令牌的认证方式已经越来越流行。相比较传统Session中的Session ID，Token不仅仅是一个key，它包含了用户的身份信息，通过验证令牌就可以完成身份校验。像微博、QQ等服务的API很多都是使用该方式进行认证的。

用户在首次登录系统身份信息校验通过后，微服务授权服务会提供该用户权限信息令牌。该令牌由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加在每一次访问请求中，在API网关进行令牌解析，权限校验通过的请求会路由之指定提供服务去处理。

1.4 微服务架构下的访问控制相关实现技术

1.4.1 认证协议

认证协议是处理系统验证用户身份的协议。OAuth[8]是目前主流的认证协议，OAuth 2.0是OAuth的新版本，更具有简单易用性。系统开发者可以通过组织在资源拥有者和服务提供商之间的交互动作来代表用户，也可以允许授权给第三方应用以获得访问的权限。同时为Web应用、桌面应用等场景下提供特定的认证流程。

1.4.2 认证机制

JWT(Json web token)[9]是一种基于JSON格式的访问令牌标准，该标准适用于分布式系统中的单点登录的场景中。JWT的声明一般被用在系统访问者和服务资源拥有者间传递认证的访问者身份信息的载体，从而根据用户信息对应的权限获取资源服务器的资源。此外，JWT也可直接被用于通过加密进行认证，从而保证信息的安全性。

JWT的主要优势在于使用无状态、可扩展的方式处理应用中的用户会话。服务端可以通过内嵌的的声明信息，很容易地获取用户的会话信息，而不需要去访问用户或会话的数据库，从而降低数据库的访问压力。

1.4.3 鉴权框架

鉴权框架Spring Cloud Security[10]基于OAuth2 和OpenID协议的可配置的单点登录机制，并且使用Token保障资源访问安全。此外，该框架引入UAA鉴权服务[11]。UAA是一种权限控制的Web服务，该服务用于管理账户、客户端和访问控制的问题令牌(Issue Token)。UAA实现了OAuth2授权框架和通过运用基于JWT的Issue Token来实现对访问控制中权限传输载体的功能。

UAA基于OAuth2[12]的认证协议实现，当用户访问应用时，生成并发放Token给目标客户端。UAA认证服务包含如下几个方面的内容: 1) 认证对象。如用户、代理客户端以及资源提供服务器。2) 认证类型。主要有授权码模式、客户端模式、密码模式等类型。3) 认证权限，并作为一个参数附加到Access Token上，用于权限的查询与鉴别。

2 微服务架构下的权限管理模型MSAM

本节中提出了微服务架构下权限模型MSAM，并与上文提到的两种基于RBAC模型改进的权限模型进行对比。

2.1 模型设计

MSAM模型在RBAC模型的基础上将权限分为了功能权限与数据权限，如图4所示。功能权限表示访问者对服务中提供的功能访问的权限，数据权限表示访问功能时拥有对哪些数据集信息以及服务实例的访问权限。

图4 MSAM模型图

其中该模型将功能权限细化到服务层面，直接管理服务内的权限信息，比如服务A拥有服务B中接口1的权限，从而实现了对服务间调用场景的权限管理。该模型还在角色权限赋予的基础上添加了用户权限的赋予与屏蔽功能，用户权限可以在角色权限的基础上灵活变更。

此外，该模型将数据权限细化到数据集与服务实例信息层面，用于微服务架构下服务信息的管理。实现方式上通过将数据权限授予给组织，其中组织与实际的机构信息相关。数据权限还与用户进行关联，支持用户根据需求灵活地添加或者屏蔽数据权限。

2.2 权限管理模型间对比

MSAM模型与上文两种基于RBAC模型改进的权限模型的功能对比分析如表1所示。MSAM模型基于微服务架构将权限信息分为功能权限与数据权限。功能权限新增了服务层面上的功能权限管理，服务信息中包含了服务实例信息与服务权限信息，相同的服务会拥有若干个服务实例与相同的服务权限。数据权限新增了服务实例与数据集两个维度，某一条数据权限可以实现控制对不同服务实例的管理。数据集指的是某一功能权限对可访问数据范围的集合，比如，数据权限A包含了对服务甲中服务实例1、2、3的访问权限，数据集包含了id值在[100，200]的数据范围。此外，实际环境下数据权限往往与不同组织以及用户相关，所以将数据权限与组织机构以及用户关联，用户可以在组织机构的基础上实现对数据权限的动态管理。

表1中资源数据指的是访问者能够调用某接口时访问的数据。一般功能权限指的是对资源数据的操作功能。新增用户特殊权限与屏蔽用户特殊权限指的是用户能否在角色的基础上动态管理权限内容。微服务架构数据库分库设计指的是在实现权限信息时可支持分库设计。微服务架构服务权限设计指的是支持微服务架构下一些特有的资源访问功能，比如服务实例管理功能等信息。

3 MSAM模型的实现

3.1 表结构设计

用户权限管理数据库库表设计如图5所示，图中给出了一些主要属性。这个模型有若干实体表与关联表，实体表中包含用户表、角色表、功能权限表、权限信息表、组织表、资源表、服务实例表、数据信息表、服务信息表、服务权限表等。关联表包括用户角色关联表、角色权限关联表、用户权限屏蔽关联表、用户权限新增关联表、组织资源关联表、用户资源增加表、用户资源屏蔽表、用户组织关联表等。下面从具体三方面介绍拓展的内容。

图5 MSAM模型数据库模式图

3.1.1 功能权限控制的拓展

在权限复杂的管理系统中，角色的权限内容经常随时间和业务发生变化，不同角色的权限往往会出现相互交叉的情况。为了在不变更角色权限信息的条件下适应这种变化，权限管理需要灵活的基于用户的权限管理方式。如图5(A)所示，在用户表与权限表间增加用户屏蔽权限关联表和用户增加权限关联表，用于实现用户灵活的权限管理。于是，通过定义用户与权限表的关联来实现动态权限管理，来满足细粒度的权限管理场景。例如，用户甲拥有角色A，但角色A未包含对接口a的访问权限，此时只需要在用户权限增加关联表中新增该权限记录即可。同理，需要去除某一权限时在用户权限屏蔽关联表中操作。此外，功能权限设计采用分层的方式，低级别权限采用前置权限的编号方法，高级别权限采用后置权限的编号方法。比如对某一接口的访问权限的id是100开头，而对此接口GET方法的权限id是10001，PUT方法的权限id是10002，从而实现了分层权限管理功能。

3.1.2 数据权限控制的拓展

通过定义资源表、组织机构表以及组织-资源关联表等，实现添加数据权限管理功能。在大型组织机构内部，数据权限往往跟部门机构相关联，本机构只有访问本机构以及下属机构的数据信息，所以设计将机构、资源表与用户表相关联，来实现动态管理数据权限信息。此外，在功能权限表中添加资源ids字段，表示该权限对应的数据资源内容，从而实现在访问指定接口时不同种数据权限管理的功能。

针对微服务场景，如图5(B)所示，数据资源在传统信息系统之外增加对服务实例信息的管理，使得不同机构的不同用户可以在同服务实例负载均衡功能之上实现灵活配置调用实例信息，提高服务调用的灵活性与可靠性。例如，用户甲希望手动选择处理某个调用的请求服务实例时，通过在请求信息中添加对应实例id，在该类型数据权限的管理模块中予以控制。

3.1.3 服务间权限控制的拓展

定义服务间调用权限管理模块。服务间权限控制数据库表设计如图5(C)所示。通过定义服务信息表与服务权限表一对多的关联关系进行服务间权限的管理。在微服务应用场景下，除了需要管理用户访问指定服务的接口权限，还需要对服务间调用做权限管理，从而保证服务间调用的安全性。

3.2 访问控制实现方式

3.2.1 集中式访问控制

基于微服务架构的信息系统一般对外需要一个访问入口来实现访问控制与路由转发的网关功能。网关与权限管理服务关联或者直接访问权限数据库，不同的访问请求在网关处统一进行权限校验，校验通过会路由到指定的服务。

集中式访问控制的关键在于有独立于其他服务的访问控制服务，该服务负责管理其他服务对外提供的接口内容的权限内容。如图6所示，通过该服务校验的请求可以路由到指定服务上去；未通过校验，则返回客户端没有访问权限。该种管理方式的优势在于: 一方面访问控制更加集中，有统一对外的权限校验入口，可以将非法请求隔离在系统的外部；另一方面方便访问控制，可以统一进行权限管理以及维护，提高管理效率。但同时在大量访问请求进入系统时，鉴权服务需要承担过大的处理压力，容易出现性能瓶颈，甚至单点故障。

图6 集中式访问控制架构图

这种方式适用于在微服务系统中服务实例相对较少的场景，在服务实例过多时统一的权限服务会承担过大的访问压力，从而影响整个系统的性能。此外，由于权限统一管理，当不同服务的权限信息需要随着业务改变时，需要对统一的权限服务进行修改，会出现权限管理数据库的信息变更甚至权限服务的重新部署。所以这种实现方式适用于访问权限相对比较固定的场景。

3.2.2 分布式访问控制

微服务架构下分布式访问控制的关键在于每个服务拥有独立的访问控制模块，如图7所示。针对浏览器或者其他服务发来的请求，通过路由到处理该请求的指定服务，并在服务内部进行权限校验，来判断该请求是否有访问权限。此外，不同的服务可以访问同一个权限数据库，从而减轻维护成本。与集中式访问控制方式对比，分布式权限管理将权限的校验功能分布在每个功能的服务内部，可以提高权限管理的灵活性。

图7 分布式访问控制架构图

这种方式更适用于服务实例庞杂且权限灵活多变的场景，不同的服务实例维护自己的权限信息，独立进行访问控制，在权限不要变更的情况下不会对其他服务产生影响。

3.3 访问控制流程

微服务架构下信息管理系统完成鉴权过程主要分为用户身份认证、用户权限查询匹配、校验权限是否合法3个过程，下面详细介绍项目中的权限校验过程。

整体的流程如图8所示: 首先用户在登录页面通过输入用户名与密码组合，如果提交的用户密码信息与后台数据库存储的MD5加密过的密码信息吻合，则视为身份认证通过。接下来授权服务通过计算该用户角色的权限与用户权限的并集获取该用户的权限信息。UAA服务根据用户与权限信息生成该用户Token信息，通过发放Token信息给客户端从而实现访问控制。

最后，浏览器将Token信息存至本地Cookie中，在下次请求中将Cookie中的Token信息放至HTTP请求的头部。在鉴权服务获取到Token信息后，获取出此用户的权限信息，并将请求的功能权限与数据信息进行比对，信息一致的请求路由至指定的服务，不一致则向客户端回复没有访问权限。其中集中式权限管理是路由网关服务，分布式访问控制是具体提供功能的服务。

图8 权限校验流程

4 结 语

本文基于微服务架构的信息管理系统改进了RBAC模型，形成了一套用户鉴权模型MSAM的数据权限的控制，并且增加了服务间权限管理处理，可以满足对权限管理要求的灵活性与拓展性。