读数据安全架构设计与实践05授权

1. 授权

1.1. 向通过身份认证的主体（用户/应用等）授予或拒绝访问客体（数据/资源等）的特定权限

1.2. 在正常情况下，普通用户不能拥有管理特权，未付费用户无法享受付费用户才能享受的资源

1.3. 授权是决策单元，是司令官，是执行访问控制的依据或输入之一

2. 授权的原则与方式

2.1. 从安全意义上，默认权限越小越好（甚至没有任何权限）​，满足基本的需要即可

2.2. 基于属性的授权

• 2.2.1. Attribute-Based Authorization

• 2.2.2. 属性就是对一个客体或对象（object）的抽象刻画

• 2.2.3. 基于属性的授权​，是在规则明确的情况下，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则）​

• 2.2.4. 用户有权查询、修改、删除自己的个人信息，但用户无权查询、修改、删除其他用户的个人信息

• 2.2.5. 允许用户的好友查看其发表的内容，拒绝非好友的访问

• 2.2.6. 设备的负责人有权对自己名下的设备进行运维管理

2.3. 基于角色的授权

• 2.3.1. Role-Based Authorization

• 2.3.2. 群组，通常是指账号体系的群组

• 2.3.3. 角色，是应用系统内的不同权限等级的用户群体划分

• 2.3.4. 角色可以用应用内的群组来管理，将账号体系的用户或群组加入进来

• 2.3.5. 在应用系统中先建立相应的角色（可以用群组）​，再将具体的用户ID或账号体系的群组纳入这个角色

• 2.3.6. 使用角色后，只需要维护该角色内的人员清单即可，维护工作量大大减少

• 2.3.7. 业务管理员角色

• 2.3.8. 审计员角色

• 2.3.9. 审批角色

• 2.3.10. 非自然人的组织账号

2.4. 基于任务的授权

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

• 2.4.2. 用户拨打客户服务电话，会生成一个工单，客户服务部的员工为了验证呼入用户的身份，或协助用户解决问题，有权获取该工单所对应用户的联系方式或资料

2.5. 基于ACL的授权

• 2.5.1. Access Control List

• 2.5.2. 访问控制列表，在执行访问控制的时候，访问控制模块会依据ACL设定的权限表来决定是否允许访问

• 2.5.3. ACL的主体可以是单个用户，也可以是一个群组（group）

• 2.5.4. 授权与访问控制的关系可以理解为：授权是司令官，是执行访问控制的依据；访问控制只能按司令官的意志来执行放行与否

2.6. 动态授权

• 2.6.1. 动态授权是基于专家知识或人工智能的学习，来判断访问者的信誉度，以决策是否放行

3. 典型的授权风险

3.1. 未授权访问（就是根本没有授权机制）

3.2. 平行越权和垂直越权

• 3.2.1. 平行越权

• 3.2.1.1. 通常是指一个用户可以访问到另一个用户才能访问的资源

• 3.2.2. 垂直越权

• 3.2.2.1. 通常是低权限角色的用户获得了高权限角色所具备的权限

3.3. 交叉越权（同时存在平行越权和垂直越权）​

3.4. 诱导授权

• 3.4.1. 隐私保护不力或用户自主授权模式太宽松，导致用户很容易被误导或诱导，轻易授权给第三方应用，交出自己的个人隐私数据

• 3.4.2. 权限管理过于宽松，容易被诱导授权也是一种风险

• 3.4.3. 作为数据控制者，应严格控制默认权限，以及用户对外的授权机制，防止批量数据泄露

3.5. 职责未分离

• 3.5.1. 将不同的管理权限授给同一人

• 3.5.1.1. 职责的分离，*主要依靠管理手段来主动规避

• 3.5.2. 公司财务管理中，会计和出纳如果由一人担任，会出现贪腐现象（私吞公款再把账抹平）​，因此会计和出纳应由两人担任

• 3.5.3. 开发人员和运维人员由一人担任，会出现随意变更生产环境，数据无意中泄露的情况

• 3.5.4. 操作系统管理员、数据库管理员、业务后台管理员如果由同一人担任，他就具备了把全部数据拿出来的权限，并且在日志上看不出异常

• 3.5.5. 业务流程审核时，如果负责审批权限的人和负责执行的人由同一人担任，他就可能审核自己的单据，获取更多的权限或收益

4. 授权漏洞的发现与改进

4.1. 交叉测试法

• 4.1.1. 是否具有授权机制，访谈业务团队中的软件设计人员是最快速的方法，但也有局限性，特别是考虑到沟通不畅、理解分歧与配合不力的情况，业务团队往往更希望有一个操作性非常强的方法可供重复开展工作

• 4.1.2. 安全团队可以使用输出交叉测试法，交给业务的安全测试团队，来辅助发现授权漏洞

• 4.1.3. 交叉测试法就是不同角色（或不同权限等级）的用户，以及同一角色内的不同用户，互相交换访问地址

4.2. 漏洞改进

• 4.2.1. 应用内建立授权模块

• 4.2.1.1. 如果一个业务默认只允许用户访问自己的资料，典型的场景是同一个URL地址配合不同的参数，需要在应用内建立授权模块

• 4.2.1.2. 如果当前用户访问的资源不是自己的，到授权表中检查是否存在对应的授权记录，如属于特定的允许访问的角色，如审批人员、客服人员，则在授权表指定的范围内受控地访问，包括只读权限、只能读取少量指定的资源等

• 4.2.1.3. 如既不是被授权的用户，也不属于任何被授权的角色，则拒绝访问

• 4.2.2. 使用外部权限管理系统

• 4.2.2.1. 如果要访问的资源不是用户自己的数据，或者跟用户自身没有关系，比如某种功能的使用权限，典型的场景是用URL地址进行区分，除了可以使用应用内的授权表之外，还可以使用应用外的权限管理系统

5. DMZ

5.1. Demilitarized Zone，非军事区

5.2. 一个安全等级介于服务器内网和互联网之间的网络区域，常用于部署直接对外提供服务的服务器，如Web业务的前端服务器

5.3. 在IDC（互联网数据中心）模式下，通常没有DMZ这个网络区域，而采用双网卡机制，一张网卡用于内网，另一张网卡用于外网，外网网卡可视为虚拟化的DMZ