读数据安全架构设计与实践06访问控制

1. 访问控制

1.1. 是为降低攻击面而采取的控制措施，以及依据安全管理政策、业务规则或资源属性、授权表、专家知识，对主体访问客体的行为进行控制，确定是否放行，防止对资源进行未授权的访问

1.2. 基于属性的访问控制

• 1.2.1. Attribute-Based Access Control, ABAC

• 1.2.2. 通过比对待访问的资源对象的属性（如所有者、责任人、所属部门等）​，来决定是否允许访问

• 1.2.3. 允许用户访问自己名下的资源（设备、个人信息等）​，禁止用户访问他人的秘密空间

• 1.2.4. 只允许设备负责人运维自己名下的设备

• 1.2.5. 禁止员工A尝试SSH登录员工B名下的服务器

1.3. 基于角色的访问控制

• 1.3.1. Role-Based Access Control,RBAC

• 1.3.2. 授权是授给角色而不是直接授给用户或用户组，用户通过成为某个角色的成员，从而拥有该角色对应的权限

1.4. 基于任务的访问控制

• 1.4.1. Task-Based Access Control,TBAC

• 1.4.2. 是为保障流程任务完成而采取的动态访问控制机制

• 1.4.3. 流程各阶段的审批/处理权限

• 1.4.4. 快递员查看派单的收件人信息

• 1.4.5. 客服人员查看电话呼入的求助用户的资料

• 1.4.6. 在访问控制模块，会检查有没有任务（如派送单）作为决策依据，来决定是否放行

1.5. 基于ACL的访问控制

• 1.5.1. 自主访问控制（Discretionary Access Control, DAC）

• 1.5.2. 即资产的所有者，在符合整体安全政策的条件下，有权按照自己的意愿，授予其他主体访问这些资源的权限

• 1.5.3. 在访问控制模块，会检查有没有ACL作为决策依据，如果命中ACL规则，就会按照ACL设定的动作执行（放行或拒绝）​

• 1.5.4. 在基于ACL的访问控制场景中，白名单和黑名单是一个经常使用的访问控制机制

• 1.5.5. 白名单用于允许访问，黑名单用于拒绝访问，常用于简单、直接、快速地做出访问决策的场景

• 1.5.5.1. 如果同时存在白名单和黑名单，通常白名单的优先级高于黑名单

• 1.5.5.2. WAF系统往往会添加一些内部地址为白名单，用于测试目的，即使提交的参数带有非法指令，也会放行

• 1.5.6. 用户ID或用户名

• 1.5.7. IP地址

• 1.5.8. 电子邮件地址

• 1.5.8.1. 重要的邮件地址加入白名单

• 1.5.8.2. 垃圾邮件发送者加入黑名单

• 1.5.9. 文件路径或进程名

• 1.5.9.1. 常用于杀毒软件，加入白名单不再扫描

• 1.5.10. IP白名单机制，实际上就是一种限制访问者来源的访问控制机制，但是这种机制简单粗暴，实际防御中较为脆弱，一般只用于防火墙策略等少量场景中，不推荐将其作为应用系统中主要的控制手段，而是作为辅助的控制手段

• 1.5.11. IP地址限制可以帮助收缩来访者的来源范围，作为辅助性的访问控制措施

• 1.5.12. 有很多实际的数据泄露案例，把IP控制当作主要的控制措施，往往还会伴随着人为疏忽导致IP限制失效的情况

1.6. 基于专家知识的访问控制

• 1.6.1. 控制规则不便用非常简单的方法来实现，而需要借助一定的专家知识、经验、专业的解决方案才能完成时，归类为基于专家知识的访问控制

• 1.6.2. 参数控制

• 1.6.2.1. 参数化查询机制、检查参数的合法性等，防止引入缓冲区溢出、SQL注入、XSS等风险，常用于安全防御

• 1.6.3. 频率或总量控制

• 1.6.3.1. 只允许一分钟内访问5次

• 1.6.3.2. 在60分钟内请求次数不能超过300次

• 1.6.4. 行为控制

• 1.6.5. 业务规则

• 1.6.5.1. 费用户只能使用30天

1.7. 强制访问控制

• 1.7.1. Mandatory Access Control,MAC

• 1.7.2. 主体和客体都分配安全标签用于标识安全等级，基于主体和客体的安全标签所标明的等级，来决定主体是否能够访问客体

1.8. 无论是在哪里部署，都需要首先设置身份认证

• 1.8.1. 如果业务需要部署数据库等高危服务，首先需要设置口令，不要使用空口令或默认口令

• 1.8.2. 建议默认为所有服务器只配置内网IP，需要对外提供服务时，可通过统一的接入网关，这样高危服务就不会误开放到外网去了

1.9. 访问控制是执行单元，只能按司令官的意志来确定放行与否；除此之外，还包括控制措施的实施

2. 不信任原则与输入参数的访问控制

2.1. 基于身份的信任原则

• 2.1.1. 应用应该默认不信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护

• 2.1.2. 不能假设用户都是好人，也不能假设内部员工都是好人

• 2.1.3. 身份认证，包括对人的认证、对后台系统（调用方）的认证，如有更高的安全要求，还需要对设备进行认证

• 2.1.4. 授权，无论采用何种授权模型（基于角色或基于资源属性等）​，坚持最小化授权的原则

• 2.1.5. 访问控制，不信任任何传递过来的参数，确认其合法性才能放行；执行来源限制（如防火墙策略或指定源IP）​，作为辅助性访问控制手段

2.2. 缓冲区溢出

• 2.2.1. 执行边界检查防止缓冲区溢出

• 2.2.1.1. 系统崩溃

• 2.2.1.2. 让黑客获取到系统root权限

• 2.2.1.3. 内存数据泄露

• 2.2.1.4. 载荷本来只是数据的一部分，但通过精心构造里面的ShellCode（作为最终执行的代码）的内容和位置，溢出后ShellCode由数据变成了可执行的代码

• 2.2.1.5. 为了防止缓冲区溢出，所有接收外部数据的缓冲区，都需要在接收数据前执行边界检查，防止收到超出自身容量的数据

• 2.2.1.6. 应用系统除了自身需要安全编码之外，它所依赖的操作系统、运行环境、第三方开源组件也可能引入此类漏洞，这就要求我们关注操作系统及运行环境的补丁管理（补丁通常修复了已被发现的缓冲区溢出等漏洞）​、开源组件的版本管理等

2.3. SQL注入

• 2.3.1. 参数化查询防止SQL注入漏洞

• 2.3.1.1. 体现在SQL语句上，一个重要的原则就是“不要拼接SQL语句”

• 2.3.1.2. 基于预编译（Prepare）和参数绑定（Bind）的参数化查询机制，否则就会出现“数据变指令”的情况，导致风险发生

2.4. XSS

• 2.4.1. Cross-site Scripting，跨站脚本攻击

• 2.4.2. 攻击者构建特殊的输入作为参数传入服务器，将恶意代码植入到其他用户访问的页面中，可造成盗号、挂马、DDoS、Web蠕虫（自动关注指定的用户，或自动发送消息等）​、公关删帖等后果

• 2.4.3. 真正威胁比较大的XSS，是存储型XSS（或持久性XSS）​，也就是黑客提交的恶意内容，被写入数据库，并最终能够影响到几乎所有的用户，所有浏览到含有恶意内容页面的用户浏览器

• 2.4.4. 造成跨站脚本（XSS）的主要原因是来自用户侧创建的不安全内容，经业务处理后，又出现在用户侧

• 2.4.5. 防止XSS的方法就是服务器应检查并拒绝接收不安全的内容，或者对这部分内容进行转义（无害化处理）​：凡是用户提交的内容，只要返回到用户侧（包括用户本人及其他用户）​，就需要执行转义处理

• 2.4.6. 采用何种转义方式，取决于该内容出现的位置

• 2.4.7. 采用CSP策略（Content Security Policy，内容安全政策）可缓解XSS风险

2.5. Path Traversal（路径遍历）​

• 2.5.1. 路径操纵（Path Manipulation）​

• 2.5.2. 典型的场景就是将路径或文件名作为参数进行传递，如果处理不当，可能被恶意利用，使用．./../等形式进行路径遍历，读取敏感系统文件如/etc/passwd

2.6. CSRF

• 2.6.1. Cross-Site Request Forgery，跨站请求伪造

• 2.6.2. ​是一种操纵用户浏览器自动提交请求的攻击方法

• 2.6.3. CSRF由用户的浏览器自动发起，使用的是用户已认证通过的凭据，在Web应用上提交的请求或操作不是出自用户的本意

• 2.6.4. 为表单添加一个隐藏的字段，这个字段的名称没有特别的要求，但通常会使用csrftoken、csrf、token、csrf-token等字段名，字段值是临时生成的，仅使用一次，或在较短的时间窗内针对该用户重复使用，只在用户浏览器和服务器之间共享，可以视为用户浏览器和服务器之间的约定，或共同的背景知识

• 2.6.5. 配合验证码（CAPTCHA）使用，原理跟CSRF Token基本一致，但在用户体验上，多一个手工输入的过程

• 2.6.6. 再次身份认证，可以跟首次身份认证相同，也可以不同，比如在正常的口令之外，设置第二次口令

2.7. SSRF

• 2.7.1. Server-Side Request Forgery，服务器端请求伪造

• 2.7.2. 通常是由黑客提交经过构造的内网地址及参数，但由服务器侧发起的针对内网进行探测的请求，常用于攻击内部系统

• 2.7.3. URL地址如果作为参数进行传递，也是高风险的参数类型，黑客可能提交内部域名或内部IP，造成对内网的探测扫描，构成SSRF漏洞

• 2.7.4. DNS Rebinding（DNS重新绑定）的技术，其原理就是利用了自建DNS对两次查询返回不同的IP地址来绕过内外网检测

• 2.7.5. 断绝该业务服务器跟内网的网络通路

• 2.7.6. DNS只查询一次

• 2.7.7. 使用主机防火墙（如iptables）封禁对内网的出向请求，但这要求对主机防火墙非常熟悉才能配置，并需要在配置之后进行内网连通性测试

2.8. 上传脚本文件漏洞（WebShell）​

• 2.8.1. 主要是防止WebShell文件被上传，以及防止WebShell文件上传后被解析执行

• 2.8.2. 所谓WebShell，就是以脚本网页文件（如PHP、JSP、ASP、ASPX或其他CGI）形式出现的命令执行环境，也称为网页木马，可通过浏览器访问，在界面上可跟服务器端交互，在服务器上执行操作系统命令或脚本

• 2.8.3. 对于上传请求，不能信任请求头部声称的文件类型

• 2.8.4. 用户上传的文件只能存放在固定的目录或其子目录下面（如果用户指定目录则可能会将用户上传的文件放在可解析目录下）​，且该目录不得由应用服务器提供解析执行功能

• 2.8.5. 用户上传的文件只能按静态文件处理，只能由处理静态内容的静态服务器（如Nginx、Apache）直接解析，而不能由处理动态内容的应用服务器（PHP、JSP、ASPX等）来解析，防止恶意内容被解析执行

• 2.8.6. 不能使用原始文件名，防止其他环节失效时，恶意提交者直接使用原始文件名发起访问

2.9. Method控制

• 2.9.1. 即提交HTTP请求的方法

• 2.9.2. 使用得最多的方法就是GET和POST

• 2.9.2.1. 不要使用GET方法传递敏感数据

• 2.9.2.2. 当需要传输敏感数据时，建议使用POST方法

2.10. 防止遍历查询

• 2.10.1. 遍历查询是导致数据批量泄露的主要原因之一，其他可能的原因还有数据库被拖库、SQL注入等

• 2.10.2. 身份认证是前提

• 2.10.3. 应用接口不能信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制

• 2.10.4. 可以通过频率和总量控制缓解（但没有从根本上解决问题）

• 2.10.5. 可以通过监控告警和审计，识别数据泄露（事后措施，没有从根本上解决问题）