应用层安全架构设计-访问控制

权限控制，或者说访问控制，广泛应用于各个系统中。抽象地说，是某个主体（subject）对某个客体（object）需要实施某种操作（operation），而系统对这种操作的限制就是权限控制。

在网络中，为了保护网络资源的安全，一般是通过路由设备或者防火墙建立基于IP和端口的访问控制。

在操作系统中，对文件的访问也要访问控制。比如在Linux系统中，一个文件可以执行的操作分为“读”、“写”、“执行”三种，这三种操作网站交易同时对应着三种主体：文件拥有者、文件拥有者所在的用户组、其他用户，主体、客体、操作这个三者之间的对应关系，构成了访问控制列表。

在Web应用中，根据访问客体的不同，常见的访问控制可以通过解决以下几个目标问题来实现：

他是谁？

他只能访问给他授予了权限的接口！

他不能查看别人的数据！

下面我们以前后端分离的项目为例，解释如何解决这几个目标问题：

他是谁？

在前后端分离项目中，前端用户登录后后端服务会给其颁发一个token，比如我们所熟知的JWT(JSON Web Token)，而后每次前端请求后端接口都会带上这个token。由于JWT上会带有用户信息，此时我们要做的就是校验这个token对应的用户是否为系统合法用户。

他只能访问给他授予了权限的接口！

光知道他是系统的合法用户还是不够，web应用还得保证当前用户只能访问他拥有权限的接口。

比如有个薪资查询的接口，业务上只允许部门领导角色访问。如果系统不做控制，张三知道了薪资查询接口，就拿着自己的token去调用此接口然后就能知道所有员工的薪资了，这种问题我们称之为"越权访问"。

处理这个问题现在应用广泛的一种方法就是“基于角色的访问控制（RBAC：Role-Based Access Control）”，也称“垂直权限管理”。

RBAC事先会在系统中定义出不同的角色，不同的角色拥有不同的权限，一个角色实际上就是一个权限的集合。而系统的所有用户都会被分配到不同的角色中，一个用户可能拥有多个角色。

当用户带着token请求后端服务时，我们还得通过token查询出当前用户所属的角色，然后根据角色查询出用户拥有的所有权限。权限框架 Spring Security 和  Shiro都很好的支持RBAC控制。

他不能查看别人的数据！

张三和李四都是部门领导，他们都可以查询员工薪资的权限。但是他们都只被允许查看自己部门员工的薪资。张三知道了接口调用规则，就可以通过修改调用参数获取李四部门员工的薪资了，这种情况当然也是不被允许的。

在RBAC模型下，系统只会验证用户A是否属于角色RoleX，而不会判断用户A是否能访问只属于用户B的数据DataB，因此发生了越权访问。这种问题我们称之为“水平权限管理问题”。

现在数据级权限管理并没有很通用的解决方案，一般是具体问题具体解决。

简单的做法是给接口请求加上秘钥，通过接口参数+当前系统登录人一起进行加密发送给后端服务，后端接受到请求后对加密内容进行解密，根据约定的规则解析出用户信息并与登录用户进行匹配，匹配上正常访问，匹配不上则拒绝访问。