第 10 章 访问控制
10.1 What Can I Do?
权限控制,或者说访问控制,广泛应用于各个系统中。抽象的说,都是某个主体( subject )对某个客体( object )需要实施某种操作( operation ),而系统对这种操作的限制就是权限控制。
在一个安全系统中,确定主体的身份是“认证”解决的问题;而客体是一种资源,是主体发起的请求的对象。在主体对客体进行操作的过程中,系统控制主体不能“无限制”的对客体进行操作,这个过程中就是“访问控制”。
主体“能够做什么”,就是权限。权限可以细分成不同的能力( capability )。
在 Web 应用中,根据访问客体的不同,常见的访问控制可以分为“基于 URL 的访问控制”、“基于方法( method )的访问控制”和“基于数据的访问控制”。
10.2 垂直权限管理
访问控制实际上是建立用户与权限之间的对应关系,现在应用广泛的一种方法,就是“基于角色的访问控制( Role-Based Access Control )”,简称 RBAC 。
权限管理其实是业务需求上的一个问题,需要根据业务的不同需求来实现不同的权限管理。因此很多时候,系统都需要自己定制权限管理。定制一个简单的权限管理系统,不妨选择 RBAC 模型作为依据。
这种基于角色的权限管理( RBAC 模型 ),我们可以称之为“垂直权限管理”。
不同角色的权限有高低之分。高权限角色访问低权限角色的资源往往是被允许的,而低权限角色访问高权限角色的资源往往则被禁止。如果一个本属于低权限角色的用户通过一些方法能够获得高权限角色的能力,则发生了“越权访问”。
在配置权限时,应当使用“最小权限原则”,并使用“默认拒绝”的策略,只对有需要的主体单独配置“允许”的策略。这在很多时候能够避免发生“越权访问”。
10.3 水平权限管理
相对于垂直权限管理来说,水平权限问题出在同一个角色上。系统只验证了能访问数据的角色,既没有对角色内的用户做细分,也没有对数据的子集做细分,因此缺乏一个用户到数据之间的对应关系。由于水平权限管理是系统缺乏一个数据级的访问控制所造成的,因此水平权限管理又可以称之为“基于数据的访问控制”。
首先,对于一个大型的复杂系统来说,难以通过扫描等自动化测试方法将这些问题全部找出来。
其次,对于数据的访问控制,与业务结合得十分紧密。有的业务有数据级访问控制的需求,有的业务则没有。要理清楚不同业务的不同需求,也不是件容易的事情。
最后,如果在系统已经上线后再来处理数据级访问控制问题,则可能会涉及跨表、跨库查询,对系统的改动较大,同时也可能会影响到性能。
这种种原因导致了现在数据级权限管理并没有很通用的解决方案,一般是具体问题具体解决。一个简单的数据级访问控制,可以考虑使用“用户组(Group)”的概念。比如一个用户组的数据只属于该组内的成员,只有同一用户组的成员才能实现对这些数据的操作。
10.4 OAuth 简介
OAuth 是一个在不提供用户名和密码的情况下,授权第三方应用访问 Web 资源的安全协议。
OAuth 与 OpenID 都致力于让互联网变得更加的开放。OpenID 解决的是认证问题, OAuth 则更注重授权。
10.5 小结
无论选择哪种访问控制方式,在设计方案时都应该满足“最小权限原则”,这是权限管理的黄金法则。