什么是数据库管理系统-彩铃库管理

本文主要对权限系统设计中涉及到的一些技术术语进行梳理。 从我们的 Windows 文件系统自主访问控制到基于角色的访问控制。

授权设计基本条款

后面会用到的词汇的简单说明

什么是权限（permission）

权限（Privilege/Permission）是指任职者为保证有效履行职责而必须具备的对某一事项的决策范围和程度。 它通常表示为“有权批准……”。 如预算外5000元以内的赠与费支出，有权核准。

在计算机系统中，权限是指特定的用户有权使用特定的系统资源。 在我们的后台管理系统中，资源是指系统中的所有内容，包括模块、菜单、页面、字段、操作功能（增删改查）等。权限大致可以分为：

功能级权限管理，在操作系统中的任何动作和交互都是一个功能权限，如增、删、改、查等。 数据级权限管理。 一般的业务管理系统都有数据隐私要求：哪些数据谁可以看到什么是数据库管理系统，哪些数据不可以看到。

从控制方向来看，权限管理也可以分为两类：

从系统获取数据，如查询订单、查询客户信息和向系统提交数据，如删除订单、修改客户信息权限管理

权限管理一般是指根据系统设定的安全规则或安全策略，用户可以访问并且只能访问被授权访问的资源。

权限管理几乎出现在任何系统中，只要有用户和密码的系统。 很多人经常将“用户身份认证”、“密码加密”、“系统管理”等概念与权限管理的概念混淆。

功能权限管理技术一般采用基于角色的访问控制技术RBAC（Role Based Access Control）。 该技术广泛应用于各种系统中。

访问控制列表（ACL：Access Control List）

用于描述权限规则或用户与权限关系的数据表。

权限编号

权限代号，例如使用“ARTICLE_ADD”表示“添加文章的动作”权限。 比如在linux文件分析中，rwx代表读、写、执行权限。

角色

角色是一定数量的权限的集合，是权限的载体。 一个角色可以包含多个用户，一个用户也可以属于多个角色，所以角色和用户之间是多对多的关系。 同一个角色可以包含多个用户组，一个用户组也可以属于多个角色，所以角色和用户组之间是多对多的关系；

一用户一角色：用户/角色/权限关系总结

在实际的集团业务中，可以对用户进行分类。 例如，对于一个薪酬管理系统，通常按照级别划分为：经理、高级工程师、中级工程师、初级工程师。 即根据一定的角色，具有相同角色的用户通常具有相同的权限。 这样修改之后，用户授权就可以转换为角色授权了。

我们可以用下图中的数据库设计模型来描述这样的关系。

一个用户具有一个或多个角色：用户/角色/权限关系的总结

但在实际应用系统中，一用户一角色远远不能满足要求。 如果我们想让一个用户暂时既是销售人员又是副总。 我该怎么做？ 为了增加系统设计的适用性，我们通常设计：

我们可以用下图中的数据库设计模型来描述这样的关系。

用户组

当平台的用户基数增加，角色种类增多时，如果直接给用户分配角色，管理员的工作量会很大。 如果有一类用户必须属于某个角色，我们一个一个给用户分配角色，重复性工作很多，所以我们对这样的用户进行分类。 这时候，我们可以引入一个概念“用户组”，就是把具有相同属性的用户归为一组。 也就是用户群。 在这种情况下，我们直接将角色分配给用户组，以减少重复工作。

例如：加入用户组的概念后，就可以把部门看成一个用户组，然后直接给这个部门分配角色（10000名员工可能有几十个部门），这样部门就有了部门权限，所以该部门的所有用户都可以拥有部门权限，无需为每个用户指定角色什么是数据库管理系统，大大减少了分配权限的工作量。

同时，还可以为特定的用户指定角色，使该用户不仅拥有所属用户组的所有权限，还拥有自己特定的权限。

用户组的优点，除了减少工作量外，更容易理解，增加多级管理关系。 例如：我们在配置机构时，除了添加部门外，还可以添加部门、职位等级别，以区分111111级别用户组内部成员的权限。

用户组的详细故障排除，请参见。 也非常感谢在这里解答我疑惑的朋友们！

通用设计模式

自主访问控制（DAC：Discretionary Access Control）

系统会识别用户，然后根据主体（主题），例如阅读或修改。

拥有对象权限的用户可以将对象权限分配给其他用户，因此称为“全权委托”控制。

这种设计最常见的应用是文件系统的权限设计，比如微软的NTFS。

DAC最大的缺陷是权限控制比较分散，不易管理。 例如，不可能简单地对一组文件设置统一的权限，并向指定的一组用户开放。

强制访问控制（MAC：Mandatory Access Control）

MAC的诞生是为了弥补DAC权限控制过于分散的问题。

在MAC的设计中，每个对象都有一些权限标识，每个用户也有一些权限标识，用户能否操作对象取决于双方权限标识的关系。 这种限制判断通常是不受系统限制的。 比如在影视作品中，我们经常可以看到特工查询机密文件时，屏幕提示“不可访问，需要一级安全权限”。 用户没有。

MAC非常适合保密机构或者其他层次感强的行业，但是对于类似的商业服务系统，由于不够灵活，无法应用。

由于DAC和MAC的诸多局限性，RBAC应运而生，成为目前最流行的权限设计模型。

什么是 RBAC？

RBAC，Role-based access control，基于角色的访问控制，通过将角色链接到用户和角色关联的权限，间接授予用户权限。

它是信息安全领域中一种较新的、应用广泛的访问控制机制。 不同于强制访问控制和自由选择访问控制，直接授予用户权限，而是将权限分配给角色。

1996年，Ravi Sandhu等人在前人理论的基础上提出了基于角色的访问控制模型，因此该模型也称为RBAC96。 之后，美国国家标准研究院重新定义了基于角色的访问控制模型，并将其纳入一个名为NIST RBAC的标准中。

RBAC认为权限授权其实是Who, What, How的问题。 在RBAC模型中，who、what、how构成了访问权限的三元组，即“Who performs How on What（Which）”，即“主体”对“客体”的操作，其中who—— ——是权限 拥有者或主体（如：User、Role）、什么——是资源或对象（Resource、Class）

为什么选择RBAC进行权限控制

一个系统中通常会有不同权限的用户，根据不同的业务需求，每个用户可以使用的功能和可以查看的内容也不同。 举个最简单的例子：在钉钉后台，普通员工和管理员看到的菜单和功能是不一样的。 管理员可以查看所有员工的考勤记录，普通员工不可以。

其实直接给用户分配权限是可以的，但是直接给用户分配权限没有一层关系，扩展性弱很多。 适用于用户数量少，角色类型少的平台。

例如对于一个普通的系统，如果有多个用户具有相同的权限，那么在分配时就需要为这些用户分配相同的权限，修改时要对这些用户的权限逐一进行修改。 有了角色后，我们只需要为角色指定权限，将具有相同权限的用户分配给同一个角色，方便权限管理。

批量用户权限调整，只需调整与用户关联的角色权限，无需为每个用户调整权限，不仅大大提高了权限调整的效率，也降低了漏权限的概率调整。

RBAC定义

在一个组织中，会为不同的工作职能创建不同的角色，并赋予特定角色执行某种操作的权限。 组织成员或工作人员（或其他系统用户）被赋予不同的角色，这些用户通过被赋予角色来获得执行某些计算机系统功能的权限。

因此，在集合论符号中：

参考文章：

RBAC模型：基于用户-角色-权限控制的一些思考

RBAC权限模型——项目实战

权限系统设计模型分析（DAC、MAC、RBAC、ABAC）

基于角色的访问控制模型RBAC图解