角色权限管理英文

aggressive：侵略的，攻击性的；有进取心的，积极的。如：aggressivepolicy侵略政策，或咄咄逼人的政策；aggressivewar侵略战争；Johnwasanaggressiveguy，whodidhisjobwell．约翰是一个很有上进心的小伙子，他的工作很出色imscheme：计划，方案；阴谋，奸策。如：Hesuggestedseveralschemestoincreasesales．他提出了好几种促销方案；Thatso－calledsaleisaschemetoswindletheconsumer．所谓的大贱卖只是个欺诈消费者的骗局；ambition：雄心、抱负、志向；野心，企图uyc如：Herambitionwastobeagreatactress．她的志向是成为一名伟大的演员；Hispoliticalambitionsstillburns．他的政治野心依然炽烈。envy：嫉妒，羡慕。如：Hisnewhousewastheenvyofallhisfriends．他的新居成了所有朋友羡慕的对象；SheenviedJohnforhissuccess．她妒忌约翰所取得的成功。overlook：俯视2862鸟瞰；忽略疏忽；宽恕，原谅；监视，看守。如：Ourgardenisoverlookedfromtheneighbour＆＃39；sbalcony．站在邻居家的阳台上可以俯瞰我家的花园；Herserviceshavebeenoverlookedbyhersuperiors．她的工作劳绩一直未得到上级的重视；Motheroverlookedherlittleson＆＃39；sfault．母亲原谅了稚子的过失；Hedidnotknowhewasbeingoverlookedbythelandlord．他并不知道他被房东所监视。

从本质来说，无论何种类型的权限管理模型都可以抽象出三个基本的要素——即：用户（user）、系统/应用（system/application）、策略（policy）。

策略决定了用户和不同功能应用之间如何交互。反过来，也就是说，无论设计何种权限管理的模型，都是基于这三个基本要素来展开。

本文聚焦于目前应用最广的RBAC模型，但在这里提出三个基本要素，主要是为了帮助大家更好的理解权限管理，不至于在众多权限模型中迷失。

不同的公司或软件提供商，设计了无数种控制用户访问功能或资源的方法。但无论哪种设计，都可归到四种经典权限模型里——自主访问控制(DAC，Discretionary Access Control)、强制访问控制 (MAC，Mandatory Access Control)、基于角色访问控制 (RBAC，Role-based Access Control) 和基于属性访问控制 (ABAC，Attribute-based Access Control).

（我觉得翻译不好，但也找不到更贴切的。本文下面内容均以英文首字母来代替：DAC，MAC，RBAC，ABAC）。

本文主要就RBAC展开分析该模型的使用场景，以及如何基于该模型设计出合适的权限管理体系。但从文章便于理解的完整性的角度来考虑，会对DAC，MAC和ABAC进行简要的介绍。

DAC： 被操作对象，根据访问控制规则，来判断操作主体可对操作对象做哪些操作，比如只读或者是可写的权限。而自主的含义，则是拥有某种权限的用户，可以把权限赋予其他用户。

MAC： 被操作对象及用户两方均有各自的权限标识，用户能否对对象进行操作，取决于权限标识的对照关系。这种模型多用于等级制度明显，信息访问安全性要求高的场景，比如军事。

ABAC和RBAC有很多相通的地方，而且相比较而言ABAC实际上更灵活，符合未来发展的方向。因此，我们分析完RBAC后，再回过头来看ABAC。

Role-based Access Control，基于角色的权限控制模型。

顾名思义，给用户定义角色，通过角色来控制权限。 目前来说基于角色权限控制模型是应用较广的一个。特别是2B方向SAAS领域，应用尤其常见。

如上图示，用户拥有角色，且可拥有多个角色，而每个角色对应不同权限。

这样的好处是：不必为每一个用户去配置权限，拥有极大的灵活性和便利性。而当用户及权限的量级又大到另一个级别时，又引入了角色组和权限组概念，此处不做延伸，有兴趣的读者可以去搜些资料来看。

我们已经知道什么是RBAC模型了，在分析怎么来根据此模型来设计权限体系之前，我们再把这个模型要素进行拆分一下。

首先是：用户、角色、权限。

而权限，具体到某个软件来说，实际上包含两个方面。一个是菜单权限，另一个是数据权限。

不同的行业会有不同的使用场景，用户角色权限模型也会有不同程度上的变化。但归到底层来说，还是离不开上面我画的这个图。

上面这个图是从官网看到的，销售自动化领域十分典型的用户权限管理设计。

接下来，我们来抽象一个场景或者说案例，来辅助我们理解整个权限管理设计的过程。假设A公司是个中大型的生产制造公司，公司有OA、HR、CRM、ERP一系列管理软件。公司员工以万计，不同人员职责不同，体现在管理软件上，就是会需要使用不同的功能来完成工作。

帐号是人和软件进行交互时的一个身份的转化。账号的背后，代表了这个操作的人。账号管理应该是所有需要和系统交互的人的统一管理，包含基础信息，比如：这个人的名字，性别、手机号、部门以及其他属性。

角色管理，就是要从实际场景出发，比如：使用系统的企业或者团体，有哪几类使用的角色——也就是说，有哪几类人，是需要有不同的业务菜单和业务数据的。

说到底，角色管理，就是把这个角色对应的人平时工作需要的菜单、功能给划到一个组里。给这一个个的操作组定义不同的名称——即角色名称。

当然，这个角色管理除了规定了该角色的人平时可对哪些功能进行查看操作，还需规定这个角色，能看到哪些范围内的数据。也就是前面提到的，权限实际上包含的是菜单权限和数据权限两部分。

系统内功能控制的颗粒度越细，对使用者来说配置角色便越灵活，但对系统的设计者来说，系统的复杂度自然也会上升，成本也会增加。

因此，到底控制到哪一层级，就要视具体业务场景来定，比如：有些行业的系统，可能控制到一级菜单就可以（某些SAAS工具），但有些系统，不仅需要控制所有的子级菜单，每一个按钮操作，甚至还会需要控制到不同的字段（比如Salesforce的权限控制系统）。

不过，我们抽象出了基本的模型，根据实际业务再去发散，就不是最困难的事了。

至此，我们可以了解到：RBAC模型实际上能解决大部分的权限设计问题了。

那么，ABAC到底是什么呢？它存在的意义在哪里？关于未来的权限设计趋势，它能带给我们什么启发呢？

带着这些问题，我们先来看看到底什么是ABAC模型。

ABAC，Attribute-based Access Control. 基于属性的访问控制。而属性，总的来说有三类：用户属性、系统或应用被访问属性（数据和操作）、环境属性。

也就是说，系统根据一组或多组属性是否满足预设规则来动态的控制，谁可以访问哪些功能数据和操作。RBAC模型，其实可以看成是静态的、单组属性的ABAC模型。

用例子来理解这个模型就是：只有当用户角色为Admin，在工作时间内，且处在C栋大楼B实验室，才可以访问D文件。

实际上，ABAC是个可以以最细颗粒度来管理权限的模型。它可以让设计者，利用任何一个用户属性、环境属性，或者多个属性之间的交集、并集等来组合出动态的权限判断逻辑。

它是这么强大，既可以有效的帮助信息辨别能力差的用户过滤垃圾信息。也可以让商家用到营销广告填满你生活的每个角落却不自知。

但我一直坚信， 科技 绝对是让生活更美好。

权限管理，可能是每个2B产品经理需要面对的问题。但无论C端还是B端的产品，了解权限管理的设计法则，让自己更好的理解产品的架构，让产品的每次迭代都心里有数。

题图来自Unspalsh, 基于CC0协议。

1、Permission：权限，包括动作和客体，比如：添加文档，“添加”是动作，“文档”是客体。相近的也有：Access Control。扩展：Privilege：权力，在 Permission 的基础上加一个主体，比如：小张可以添加文档，多了个主体小张。相近的也有：Entitlement、Authority。

2、permissions或者right. ”阅读权限“可以翻译为”the permission/right to read"，就是用户的权利，即用一个帐户登录后,有些功能可以使用，有些功能无法使用，这就是管理员对其设置的权限,只有附合权限的人才可以使用对应的功能。权限就是权利的限制范围。

3、权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。权限管理几乎出现在任何系统里面，只要有用户和密码的系统。 很多人，常将“用户身份认证”、“密码加密”、“系统管理”等概念与权限管理概念混淆。