【认证授权】权限系统设计详解

世界尽头与你

已于 2024-10-08 16:10:42 修改

阅读量1.1k

点赞数 16

分类专栏： # 安全设计文章标签：系统设计系统架构 java

于 2024-07-08 16:43:49 首次发布

本文链接：https://blog.csdn.net/Gherbirthday0916/article/details/140272853

版权

安全设计专栏收录该内容

15 篇文章 0 订阅

订阅专栏

1.权限系统设计概述

权限管控可以通俗地理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。

主流的权限模型主要分为以下五种：

ACL 模型：访问控制列表
DAC 模型：自主访问控制
MAC 模型：强制访问控制
ABAC 模型：基于属性的访问控制
RBAC 模型：基于角色的权限访问控制

2.主流权限模型概述

ACL 模型：访问控制列表

ACL 是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有 ACL 的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式

原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。

例如：当用户 A 要对一篇文章进行编辑时，ACL 会先检查一下文章编辑功能的控制列表中有没有用户 A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。

缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。

DAC 模型：自主访问控制

DAC 是 ACL 的一种拓展

原理：在 ACL 模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。

例如：常见于文件系统，LINUX，UNIX、WindowsNT 版本的操作系统都提供 DAC 的支持。

缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。

MAC 模型：强制访问控制

MAC 模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件

原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。

例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

RBAC：基于角色的权限访问控制

在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
RBAC 三要素：

用户：系统中所有的账户
角色：一系列权限的集合（如：管理员，开发者，审计管理员等）
权限：菜单，按钮，数据的增删改查等详细权限。

角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。

角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。

优点：便于角色划分，更灵活的授权管理；最小颗粒度授权

以一个简单的场景（Gitlab 的权限系统）为例，用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。我们授予某个用户 Admin 这个角色，他就具备了创建代码仓库和删除代码仓库这两个权限。

ABAC 模型：基于属性的访问控制

是一种比 RBAC模型更加灵活的授权模型，它的原理是通过各种属性来动态判断一个操作是否可以被允许。这个模型在云系统中使用的比较多，比如 AWS，阿里云等

原理：在 ABAC模型中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。

通常有四类：

对象：对象是当前请求访问资源的用户。用户的属性包括 ID，个人资源，角色，部门和组织成员身份等
资源：资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至 API
操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”
环境：环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等

在 ABAC模型的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC模型决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。
例如：

考虑下面这些场景的权限控制：

授权某个人具体某本书的编辑权限
当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档
当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档
早上九点前禁止 A 部门的人访问 B 系统
在除了上海以外的地方禁止以管理员身份访问 A 系统
用户对 2022-06-07 之前创建的订单有操作权限

可以发现上述的场景通过 RBAC模型很难去实现，因为 RBAC模型仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，RBAC模型本身是没有这些限制的。但这恰恰是 ABAC模型的长处

缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用得很少。

3.RBAC 的深度拓展

RBAC 模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用 RBAC0 的模型就可以。另外，RBAC0 相当于底层逻辑，后三者都是在 RBAC0 模型上的拔高

1、RBAC0 模型

用户和角色、角色和权限多对多关系。简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有

2、RBAC1 模型

相对于 RBAC0 模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如 role1 根节点下有 role1.1 和 role1.2 两个子节点

角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），例如 BD 之间就有分级（经理、主管、专员），如果采用 RBAC0 模型做权限系统，可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有的权限。

而 RBAC1 模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。

3、RBAC2 模型

基于 RBAC0 模型，对角色增加了更多约束条件。

如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。

RBAC2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。

4、RBAC3 模型

同样是基于 RBAC0 模型，但是综合了 RBAC1 和 RBAC2 的所有特点

4.RBAC 权限管理的在实际系统中的应用

RBAC 权限模型由三大部分构成，即用户管理、角色管理、权限管理。

用户管理按照企业架构或业务线架构来划分，这些结构本身比较清晰，扩展性和可读性都非常好。

角色管理一定要在深入理解业务逻辑后再来设计，一般使用各部门真实的角色作为基础，再根据业务逻辑进行扩展。

权限管理是前两种管理的再加固，做太细容易太碎片，做太粗又不够安全，这里我们需要根据经验和实际情况来设计。

1、用户管理

用户管理中的用户，是企业里每一位员工，他们本身就有自己的组织架构，我们可以直接使用企业部门架构或者业务线架构来作为线索，构建用户管理系统
实际业务中的组织架构可能与企业部门架构、业务线架构不同，需要考虑数据共享机制，一般的做法为授权某个人、某个角色组共享某个组织层级的某个对象组数据

2、角色管理

一般角色相对于用户来说是固定不变的，每个角色都有自己明确的权限和限制，这些权限在系统设计之处就确定了，之后也轻易不会再变动。

角色管理注意：

a. 自动获得基础角色：当员工入职到某部门时，该名员工的账号应该自动被加入该部门对应的基础角色中，并拥有对应的基础权限。这种操作是为了保证系统安全的前提下，减少了管理员大量手动操作。使新入职员工能快速使用系统，提高工作效率

b. 临时角色与失效时间：公司业务有时需要外援来支持，他们并不属于公司员工，也只是在某个时段在公司做支持。此时我们需要设置临时角色，来应对这种可能跨多部门协作的临时员工。

如果公司安全级别较高，此类账号默认有固定失效时间，到达失效时间需再次审核才能重新开启。避免临时账号因为流程不完善，遗忘在系统中，引起安全隐患。

c. 虚拟角色：部门角色中的等级，可以授权同等级的员工拥有相同的权限，但某些员工因工作原因，需要调用角色等级之外的权限，相同等级不同员工需要使用的权限还不相同。

这种超出角色等级又合理的权限授予，我们可以设置虚拟角色。这一虚拟角色可集成这一工作所需的所有权限，然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色，也可以满足工作中特殊情况的权限需求。

d. 黑白名单：

白名单：某些用户自身不拥有某部门的顶级角色，但处于业务需求，需要给他角色外的高级权限，那么我们可以设计限制范围的白名单，将需要的用户添加进去即可。
在安全流程中，我们仅需要对白名单设计安全流程，即可审核在白名单中的特殊用户，做到监控拥有特殊权限的用户，减少安全隐患。

黑名单：比较常见的黑名单场景是某些犯了错误的员工，虽然在职，但已经不能给他们任何公司权限了。这种既不能取消角色关联，也不能完全停用账号的情况，可以设置黑名单，让此类用户可以登录账号，查看基本信息，但大多数关键权限已经被黑名单限制。

3、权限管理

权限管理一般从三个方面来做限制。页面/菜单权限，操作权限，数据权限。

a. 页面/菜单权限

对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。

b. 操作权限

操作权限通常是指对同一组数据，不同的用户是否可以增删改查。对某些用户来说是只读浏览数据，对某些用户来说是可编辑的数据。

c. 数据权限

对于安全需求高的权限管理，仅从前端限制隐藏菜单，隐藏编辑按钮是不够的，还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据，服务器端会识别、记录并限制访问。

4、用户管理系统权限设计中的更多实践细节

a. 超级管理员

超级管理员是用来启动系统，配置系统的账号。这个账号应该在配置好系统，创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限，可穿梭查看各部门数据，如果使用不恰当，是系统管理的安全隐患。

b. 互斥角色如何处理

当用户已经有用的角色和即将添加的角色互相互斥时，应该在添加新角色时，提示管理员因角色互斥的原因，无法进行新角色添加。如需添加，要先撤销掉前一个角色，再添加新角色。

c. 用户管理权限系统设计一定要简单清晰

在设计权限系统之处，一定要理清思路，一切从简，能不增加的多余角色和权限逻辑，就一定不要增加。因为随着公司业务的扩大，权限和角色也会随之增多，如果初期设计思路不严谨，那么权限系统会随着业务的扩大而无限混乱下去，此时再来整理权限，已经太晚了。所以初期设计就一定要条理清晰，简单明了，能避免后续非常多不必要的麻烦。

5.企业案例：转转新权限系统设计

基本思想

标准的 RBAC模型是完全遵守 用户 -> 角色 -> 权限 这个链路的，也就是用户的权限完全由他所拥有的角色来控制，但是这样会有一个缺点，就是给用户加权限必须新增一个角色，导致实际操作起来效率比较低。所以转转在 RBAC模型的基础上，新增了给用户直接增加权限的能力，也就是说既可以给用户添加角色，也可以给用户直接添加权限。最终用户的权限是由拥有的角色和权限点组合而成。

新权限系统的权限模型：用户最终权限 = 用户拥有的角色带来的权限 + 用户独立配置的权限，两者取并集。

基础三步：

首先，将集团所有的用户（包括外部用户），通过统一登录与注册功能实现了统一管理，同时与公司的组织架构信息模块打通，实现了同一个人员在所有系统中信息的一致，这也为后续基于组织架构进行权限管理提供了可行性。
其次，因为新权限系统需要服务集团所有业务，所以需要支持多系统权限管理。用户进行权限管理前，需要先选择相应的系统，然后配置该系统的菜单权限和数据权限信息，建立好系统的各个权限点。
最后，创建该系统下的不同角色，给不同角色配置好权限点。比如店长角色，拥有店员操作权限、本店数据查看权限等，配置好这个角色后，后续只需要给店长增加这个角色，就可以让他拥有对应的权限。

完成上述配置后，就可以进行用户的权限管理了。有两种方式可以给用户加权限：

先选用户，然后添加权限。该方式可以给用户添加任意角色或是菜单/数据权限点。
先选择角色，然后关联用户。该方式只可给用户添加角色，不能单独添加菜单/数据权限点。

权限系统自身的权限管理

对于权限系统来说，首先需要设计好系统自身的权限管理，也就是需要管理好 ”谁可以进入权限系统，谁可以管理其他系统的权限“，对于权限系统自身的用户，会分为三类：

超级管理员：拥有权限系统的全部操作权限，可以进行系统自身的任何操作，也可以管理接入权限的应用系统的管理操作。
权限操作用户：拥有至少一个已接入的应用系统的超级管理员角色的用户。该用户能进行的操作限定在所拥有的应用系统权限范围内。权限操作用户是一种身份，无需分配，而是根据规则自动获得的。
普通用户：普通用户也可以认为是一种身份，除去上述 2 类人，其余的都为普通用户。他们只能申请接入系统以及访问权限申请页面。

权限类型的定义

新权限系统中，把权限分为两大类，分别是：

菜单功能权限：包括系统的目录导航、菜单的访问权限，以及按钮和 API 操作的权限
数据权限：包括定义数据的查询范围权限，在不同系统中，通常叫做 “组织”、”站点“等，在新权限系统中，统一称作 ”组织“ 来管理数据权限

默认角色的分类

每个系统中设计了三个默认角色，用来满足基本的权限管理需求，分别如下：

超级管理员：该角色拥有该系统的全部权限，可以修改系统的角色权限等配置，可以给其他用户授权。
系统管理员：该角色拥有给其他用户授权以及修改系统的角色权限等配置能力，但角色本身不具有任何权限。
授权管理员：该角色拥有给其他用户授权的能力。但是授权的范围不超出自己所拥有的权限。

举个栗子：授权管理员 A 可以给 B 用户添加权限，但添加的范围小于等于 A 用户已拥有的权限。

经过这么区分，把 拥有权限 和 拥有授权能力 ，这两部分给分隔开来，可以满足所有的权限控制的场景。

操作日志

系统操作日志会分为两大类：

操作流水日志：用户可看、可查的关键操作日志
服务 Log 日志：系统服务运行过程中产生的 Log 日志,其中，服务 Log 日志信息量大于操作流水日志，但是不方便搜索查看。所以权限系统需要提供操作流水日志功能。

在新权限系统中，用户所有的操作可以分为三类，分别为新增、更新、删除。所有的模块也可枚举，例如用户管理、角色管理、菜单管理等。明确这些信息后，那么一条日志就可以抽象为：什么人(Who)在什么时间(When)对哪些人(Target)的哪些模块做了哪些操作。

这样把所有的记录都入库，就可以方便的进行日志的查看和筛选了。

6.转转新权限系统设计：后端技术案例

权限系统框架

权限系统主要解决两个问题：

前端渲染：接入系统用户登录后，获取自己有权限的菜单，也就是前端sdk请求权限系统获取有权限的菜单并进行自动渲染。
后端鉴权：用户请求接入系统后端，拒绝没有权限的接口访问，防止无权限用户获取后端接口地址后直接访问无权限的接口。

为了解决这两个问题，必然需要引入一些配套内容，其中重要的功能点如下：

用户管理：统一登录系统，支撑权限系统识别登录用户。
权限管理：系统管理、角色管理、菜单管理、数据管理、角色人员绑定等功能，方便为用户绑定相应的权限。
后端鉴权：访问接入系统接口调用时使用。

用户管理

统一登录利用浏览器携带Cookie特点：不同二级域名可以携带一级域名的Cookie。统一登录系统为接入系统种植一级域名Cookie，例如OA系统oa.zhuanspirit.com、权限系统自身id.zhuanspirit.com统一种植域名为*.zhuanspirit.com的Cookie，这样OA、权限系统等接入统一登录系统的系统就可以做到一处登录处处访问

ngix会对*.zhuanspirit.com域名的请求做Cookie合法校验，校验不通过跳转到登录页，同时携带原url信息。校验合法性是通过Cookie<sso_uid,sso_code>的值是否和Redis中一致，不一致就需要重新登录。

后端鉴权

后端鉴权sdk通过切面编程的思想，对请求url或者code进行拦截鉴权，如果登录用户没有权限，则返回错误：

核心方法：

AuthResult res = authentication.check(new AppCodeAuthParmBuilder(APP_CODE, CODE, request));

APP_CODE：系统的系统编号
CODE：权限编码（可为空，为空时根据url鉴权）
request：HttpServletRequest（从中获取Cookie信息解析出登录用户，以及url信息判断用户是否有此url权限）

使用demo：

利用Spring Interceptor切面技术，下面是架构管理平台关于ZZLock后台操作的一个例子：

@Component
public class ZZLockInterceptor implements HandlerInterceptor {
    @Resource
    private Authentication authentication;
    private static final String APP_CODE = "arch_ipms";
    private static final String CODE = "ro_zzlock";
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
            throws Exception {

        AuthResult res = authentication.check(new AppCodeAuthParmBuilder(APP_CODE, CODE, request));

        if (res.isSuccess() && res.getCode() == ResultCodeEnum.SUCCESS.getCode()) {
            return true;
        } else {
            UserDTO user = authentication.parseUser(request);
            logger.info("菜单 zzlock_get user {} 鉴权结果 code {} msg {}", user.getLoginName(), res.getCode(), res.getMsg());
            response.getWriter().write("user: " + user.getLoginName() + " no auth");
            response.getWriter().close();
        }

        return false;
    }
}