一、引子

在专栏开篇作中我有提到数据安全架构中的5A概念，5A概念中的其中一个A是授权，因此，本篇我们来聊聊授权相关的东西。

授权的概念：向通过身份认证的主体（用户/应用等）授予或拒绝访问客体（数据/资源等）的特定权限。比如员工默认只能查询自己的薪酬数据，但指定级别以上的主管人员有权查询管辖范围内员工的薪酬数据。

二、授权的原则与方式

从安全意义上，默认权限越小越好（甚至没有任何权限），满足基本的需要即可。例如，在隐私保护越来越重要的今天，用户的个人信息应默认只能用户自己访问等等。授权一般有五种模式，分别是基于属性的授权、基于角色的授权、基于任务的授权、基于ACL的授权、动态授权。

2.1、基于属性的授权

基于属性的授权，是在规则明确的情况下，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则），比如是否为资源的所有者、责任人，来决定是否放行。

例如：

● 用户有权查询、修改、删除自己的个人信息，但用户无权查询、修改、删除其他用户的个人信息。
● 允许用户的好友查看其发表的内容，拒绝非好友的访问。
● 设备的负责人有权对自己名下的设备进行运维管理，其他没有权限的人则不能对该设备进行运维管理。

2.2、基于角色的授权

基于角色的授权，是在应用系统中先建立相应的角色，再将具体的用户ID或账号体系的群组纳入这个角色。

用户通过成为某种角色（或其所在的群组成为某种角色），从而拥有该角色所对应的权限。如果用户角色发生变化，不再属于某角色，则对应的权限就失效了。

角色典型的应用场景如下：

● 业务管理员角色。
● 审计员角色。
● 审批角色。
● 非自然人的组织账号（比如很多公司、机构拥有官方的社交网络账号），可将公司账号的维护管理权限授权给某个员工，从而该员工可以官方账号的名义发布信息。

如果不使用角色而是直接授权给指定的员工ID，则在人员转岗或职责变化、新的人员加入等情况发生时，需要频繁地维护权限表，而在这一点上往往做不到及时维护，导致转岗的人员仍然持有重要的权限。使用角色后，只需要维护该角色内的人员清单即可，维护工作量大大减少。

2.3、基于任务的授权

基于任务的授权，是为保障流程任务顺利完成而采取的临时授权机制，该授权需要一项正在进行的任务作为前提条件。

典型场景如下：

● 用户拨打客户服务电话，会生成一个工单，客户服务部的员工为了验证呼入用户的身份，或协助用户解决问题，有权获取该工单所对应用户的联系方式或资料。
● 如果快递包裹上不再允许直接展示完整的收件人的姓名、电话、地址（现在已经有部分快递开始使用脱敏的收件人信息），那么快递员就需要查看派单的收件人信息（或者通过APP间接拨打收件人的电话）。
● 某员工只能在流程某一环节查看申请单信息（比如自己审批的那个环节才能看），流程处于其他环节时就看不到了。

2.4、基于ACL的授权

ACL即访问控制列表，在执行访问控制的时候，访问控制模块会依据ACL设定的权限表来决定是否允许访问。ACL的主体可以是单个用户，也可以是一个群组。

ACL场景举例如下：

● A拥有防火墙策略审批系统的审批权（A在具有审批权的名单中）。
● B授权C登录自己名下的一台服务器（B将C纳入允许登录该服务器的名单中）。
● 防火墙上允许A系统跨区访问B系统（限定访问的源IP、目标IP、目标端口）。

2.5、动态授权

动态授权，是基于专家知识或人工智能的学习，来判断访问者的信誉度，以决策是否放行。比如分析某个请求，如果是正常的用户就允许访问，如果高度怀疑是入侵行为或未授权的抓取网站内容的爬虫，则可能拒绝访问或者需要额外的操作（如输入验证码等）。

三、典型的授权风险

典型的授权风险包括：

● 未授权访问，就是根本没有授权机制。
● 平行越权和垂直越权。
● 交叉越权，同时存在平行越权和垂直越权。
● 诱导授权，隐私保护不力或用户自主授权模式太宽松，导致用户很容易被误导或诱导，轻易授权给第三方应用，交出自己的个人隐私数据。
● 职责未分离，将不同的管理权限授给同一人。

以上基本都很好理解，就不做过多介绍了，这里我们单独介绍下诱导授权。

诱导授权的原因是权限管理过于宽松，容易被诱导授权也是一种风险。作为数据控制者，应严格控制默认权限，以及用户对外的授权机制，防止批量数据泄露。

当然，从法律合规的角度来看，主要问题之一在于没有获得用户显式的同意，包括两个关键动作：

1）选择框，即默认不能勾选，应由用户主动勾选；
2）用户点击同意。

四、授权问题的发现与改进

4.1、授权问题的发现

授权缺陷的发现方式一般是交叉测试法

简单地说，交叉测试法就是不同角色（或不同权限等级）的用户，以及同一角色内的不同用户，互相交换访问地址（含参数），把A使用的地址发给B，把B使用的地址发给A，看结果是否符合业务需要的权限规则。一般情况下，如果存在安全缺陷，业务在上线前需要完成修复。

4.2、授权问题的改进

授权缺陷的改进措施一般是应用内建立授权模块

如果一个业务默认只允许用户访问自己的资料，比如同一个URL地址配合不同的参数，需要在应用内建立授权模块。那么之后：

● 如果当前用户访问的资源是自己的，按规则放行。
● 如果当前用户访问的资源不是自己的，到授权表中检查是否存在对应的授权记录，如属于特定的允许访问的角色，如审批人员、客服人员，则在授权表指定的范围内受控地访问，包括只读权限、只能读取少量指定的资源等。
● 如既不是被授权的用户，也不属于任何被授权的角色，则拒绝访问。