一、基础概念
1、越权访问
权限系统设计的目的是为了将系统使用者对系统的操作约束在一个合法的范围内，系统的使用者不一定是人，也可能是另外一个系统，如果操作不在合法范围内，就会发生越权访问行为，越权访问会造成非常严重的安全问题，被OWASP列为Web应用十大安全隐患的第二名。越权访问主要分为水平越权和垂直越权两种。
- 垂直越权垂直越权是一种权限非法提升的行为，比如说现在有个系统，它的普通用户使用的页面是xxx.com/user , 管理员使用的页面是xxx.com/manager ,但是后台系统并没有去做权限的控制，我们便可以在登陆之后带着普通用户的令牌直接跳到管理员的页面去做一些不可描述的事情，用一张图简单来描述如下：
即用户通过某种非法手段使自己的可操作范围提升
- 水平越权水平越权主要是因为服务端没有判断数据的归属所造成的越权行为，比如说，现在我们登陆了一个系统，进入了查看用户id为1的详细信息的页面，这个页面的url是这样子的：xxx.com/user/1 ,然后我使个坏，把最后面的1改成了2，这时候由于后端系统没有判断我是否可以查看id为2的用户，就把数据返回给了我。
即基于数据访问设计的漏洞所造成的越权访问。
站在服务端设计的角度我们可以很容易看出来，垂直越权指的是访问了不该访问的API，而水平越权则是访问到了不该访问的数据，这一点很重要。
2、鉴权
鉴权指的是在进行一个操作的时候，需要权限系统先去判断用户是否具有进行这个操作的权限，在某些复杂场景之下还会包括对请求数据的归属权的校验。
二、经典设计模型
在讲模型之前，我们首先要明白权限管控的真正含义是：判断请求者在某些条件下是否对请求数据具备某个操作（API） 的能力。
注意黑体的四个词，1、请求者，2、某些条件，3、请求数据，4、操作（API）
我们一个一个来解释一下，请求者一般来说是用户，也有可能是某个系统，亦或者是一段代码；某些条件，有可能是环境条件，比如说某个API只允许10.122.131.1这个ip来访问，或者说只能在晚上访问，或者说只能在周内访问此类；请求数据即本次请求要求操作的数据，比如说查看id为1的用户的具体信息；鉴权（api） 即对这个数据做的事情，是查看还是还是修改，注意修改其实也包含了删除。
1、RBAC（Role Based Access Control）
汉语译为基于角色的访问控制，这应该是当今IT系统使用的最多的权限管控模型，用一个图来简单描述如下：
上图是一个简单的业务场景中订单操作的相关场景
角色即为 操作（API） 的聚合 ，RBAC通过给用户绑定某个角色，使用户具备了某些操作的能力，这是最简单的RBAC模型，学术上也称为RBAC0，与之对应的还有RBAC1、RBAC2、RBAC3，RBAC1是引入了角色继承的关系，角色继承很容易理解，即角色B继承了角色A，那么当用户绑定了角色B的时候，也就具备了角色A的操作能力；RBAC2是引入了角色互斥的关系，比如如果用户绑定了角色A就不能绑定角色B，这是因为考虑到现实世界中如果是运动员就不能是裁判这样的业务场景；RBAC3则是结合了RBAC1和RBAC2的能力，同时拥有角色互斥和角色继承的功能。
在有的权限系统的中，为了方便用户的使用，还衍生出了权限组或者是用户组的实体模型，权限组是一类API的聚合，比如用户操作权限组就可以包含对用户数据的增删查改操作，使用权限组的时候，角色不是和api去绑定，而是去和权限组绑定；用户组是将某一类用户分组，这个分组和角色去绑定，而不是用户和角色绑定，这样只要用户加入了这个组，就具备了某些操作权限，现实世界中这个组也有可能是公司部门等实体。
我们可以看出来，在RBAC中，不管实体怎么变，角色（Role） 的本质其实就是一系列API操作的聚合，通过用户与角色的直接或者间接绑定，使用户具备了某些操作的能力，这也是RBAC的本质。
2、ABAC（Attribute Based Access Control）
ABAC 翻译过来意思是基于属性的权限访问控制 ，这个模型在如今的云系统中使用的比较多，比如AWS，阿里云，腾讯云，京东云等，它们都是用ABAC来管控IaaS以及PaaS的资源，曾经K8s也使用过这个模型来进行权限管控。
我们上面说过，RBAC的能力可以用这么一句话来描述：一个用户通过和角色绑定，具备了一些对数据操作的能力，往简单的说就是一个用户有了一些对数据操作的能力。但是，如果在复杂的权限管控场景中，RBAC显得有些力不从心，比如说：
- 用户在晚上不能访问这个系统，但是白天可以
- 用户只能在内网对订单具备修改权限，而在外网就只有查看权限
- 用户对2021-03-19日之前创建的订单有操作权限
- 用户只能在深圳进行查看订单，而去了国外就不可以
- 用户在公司内部可以访问所有数据，但是在外部就只能访问公开数据 我们很容易就发现，RBAC仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，模型本身是没有这些限制的，这也是由于其模型能力的不足所导致的，但这却恰恰是ABAC的长处，ABAC的思想是基于用户、以及将要访问的数据的属性、以及各种环境因素去动态计算用户是否有权限进行操作。我们先简单介绍一下NIST ABAC设计指引中的一些术语:
- subject 指的是系统的使用者，可以是用户(user),也可以是其他非服务的个体(non-person entity，NPE)
- object 泛指被访问的数据
- operation/action 指操作行为，一般对应系统中的API
- policy 访问策略，它规定了一个用户在什么条件下可以对哪些数据做什么，是ABAC系统核心实体之一
- pdp pdp是policy decision point，策略点，其实我理解这玩意就是一个policy的展示出来的形式而已
- pep pep是policy enforcement point,策略执行点，简单说就是根据policy来鉴权
- acm acm是access control mechanism,权限管控机制，一般来说就是权限系统本身
- attribute 它泛指各种属性，可以是subject的，也可以是object的
- condition 各种额外的限制条件 NIST的文章中，下图描述了上面术语之间的关系:
很容易发现，ABAC仅仅受限于可以用来计算的属性的数量，这也很容易让很多人产生误解，误认为ABAC什么类型的权限都可以来管控，事实上，权限系统仅仅擅长于管控垂直越权，即使ABAC具备一定的管控水平越权的能力，也不要妄想可以用它来管控所有的水平越权。
这一点放在其他方面的系统设计中也是被证明的，那就是从来没有哪个方案亦或者是架构设计能成为无所不能的银弹。
其他模型还有LBAC，IBAC，NGAC等，这里不再做介绍，读者可以自行了解
本篇仅仅做基础概念讲解，下一篇将会去和业界已存在的ABAC系统做对比，讲一讲京东北极星商业操作系统在ABAC方面的实践。
