数据安全5A之访问控制

本博客地址：https://security.blog.csdn.net/article/details/121010969

一、引子

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

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

二、访问控制策略

要执行访问控制，至少应包含如下三个要素：

● 主体。包括用户、管理员、系统调用方等。
● 客体。包括资源、数据、文件、功能、设备、终端等。
● 控制策略。即主动访问客体的规则的集合。

其中，控制策略主要包括：

● 基于属性的访问控制
● 基于角色的访问控制
● 基于任务的访问控制
● 基于ACL的访问控制
● 基于专家知识的访问控制
● 基于IP的辅助访问控制

2.1、基于属性的访问控制

基于属性的访问控制（ABAC），通过对比待访问的资源对象的属性（如所有者、责任人、所属部门等），来决定是否允许访问。

一般场景包括：

● 允许用户访问自己名下的资源（设备、个人信息等），禁止用户访问他人的秘密空间。
● 只允许设备负责人运维自己名下的设备。
● 禁止员工A尝试SSH登录员工B名下的服务器（员工A不属于该服务器责任人，且未经责任人授权）。

2.2、基于角色的访问控制

基于角色的访问控制（RBAC），授权是授给角色而不是直接授给用户或用户组，用户通过成为某个角色的成员，从而拥有该角色对应的权限。

2.3、基于任务的访问控制

基于任务的访问控制（TBAC），是为保障流程任务完成而采取的动态访问控制机制。在访问控制模块，会检查有没有任务作为决策依据，来决定是否放行。

一般场景包括：

● 流程各阶段的审批/处理权限。
● 快递员查看派单的收件人信息。
● 客服人员查看电话呼入的求助用户的资料。

2.4、基于ACL的访问控制

不便使用上述ABAC或RBAC的情况下，直接向授权表插入授权记录，是最简单的做法，如运维权限、防火墙策略等。在访问控制模块，会检查有没有ACL作为决策依据，如果命中ACL规则，就会按照ACL设定的动作执行放行或拒绝。

在基于ACL的访问控制场景中，白名单和黑名单是一个经常使用的访问控制机制。其中白名单用于允许访问，黑名单用于拒绝访问，常用于简单、直接、快速地做出访问决策的场景。

一般的白名单或黑名单中的内容有：

● 用户ID或用户名（比如好友黑名单）。
● IP地址（比如某保密系统只允许从指定的IP地址发起访问、WAF中将攻击者IP加入黑名单）。
● 电子邮件地址（将重要的邮件地址加入白名单，垃圾邮件发送者加入黑名单）。
● 文件路径或进程名（常用于杀毒软件，加入白名单不再扫描）。

如果同时存在白名单和黑名单，通常白名单的优先级高于黑名单。比如WAF系统往往会添加一些内部地址为白名单，用于测试目的，即使提交的参数带有非法指令，也会放行。

2.5、基于专家知识的访问控制

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

一般场景包括：

● 参数控制。参数化查询机制、检查参数的合法性等，防止引入缓冲区溢出、SQL注入、XSS等风险。
● 频率或总量控制。例如只允许一分钟内访问5次、在60分钟内请求次数不能超过300次等。
● 行为控制。基于大数据或行为分析建模，得出信誉度，决定是否允许访问，可疑的行为记录下来继续观察等。
● 业务规则。例如免费用户只能使用30天等。

2.6、基于IP的辅助访问控制

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

如果业务需要部署数据库等高危服务，首先需要设置口令，不要使用空口令或默认口令。其次尽量不要部署在拥有外网网卡（或IP地址）的服务器上，如果需要在这样的服务器上部署，需要修改数据库的配置文件，只监听内网地址，防止无意中开放到互联网去了。

2.7、访问控制与授权的关系

访问控制与授权的关系：

● 授权是决策单元，是执行访问控制的依据或输入之一。
● 访问控制是执行单元，只能按授权的意志来确定放行与否；除此之外，还包括控制措施的实施。

在实践中，决策单元与执行单元也经常整合在一起，合称为授权与访问控制，或者省略授权，只提访问控制，将授权隐含在访问控制内，特别是：

● 基于属性的访问控制，已经不再需要授权表作为输入了。
● 基于专家知识的访问控制，将决策单元交给专业的解决方案了，可以视为动态授权。

但要把决策单元和执行单元分开的话，就需要保留两个术语了。

三、不信任原则

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

应用系统不能假设用户都是好人，也不能假设内部员工都是好人。这需要应用系统从一开始就考虑如下因素：

● 身份认证。包括对人的认证、对后台系统（调用方）的认证，如有更高的安全要求，还需要对设备进行认证。
● 授权。无论采用何种授权模型（基于角色或基于资源属性等），坚持最小化授权的原则。
● 访问控制。不信任任何传递过来的参数，确认其合法性才能放行；执行来源限制（如防火墙策略或指定源IP）作为辅助性访问控制手段。

四、输入参数的访问控制

4.1、缓冲区溢出防护

对用户的输入不执行边界检查会导致缓冲区溢出问题。

对于缓冲区溢出的防护，所有接收外部数据的缓冲区都需要在接收数据前执行边界检查，防止收到超出自身容量的数据。

应用系统除了自身需要安全编码之外，它所依赖的操作系统、运行环境、第三方开源组件也可能引入此类漏洞，这就要求我们关注操作系统及运行环境的补丁管理、开源组件的版本管理等。

4.2、SQL注入防护

对用户的输入不执行预编译或参数化查询会导致SQL注入问题。

对于SQL注入的防护，所有拼接SQL语句的字符串输入，都应该先进行预编译或参数化处理。

另外，当不得不使用拼接字符串充当SQL语句的时候，如果接受的参数能够强制使用整型，就尽量事先声明整型变量，因为将字符串赋值给整型变量的时候，会产生异常，从而让程序中断。如果语言不支持事先声明变量类型，可以考虑使用强制类型转换。

4.3、XSS防护

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

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

4.4、CSRF防护

同样是来自用户的不安全输入造成的问题。

防范CSRF漏洞最常使用的方法一般有：

● 第一种方法，就是为表单添加一个隐藏的字段，这个字段的名称没有特别的要求，但通常会使用csrftoken、csrf、token、csrf-token等字段名，字段值是临时生成的，仅使用一次，或在较短的时间窗内针对该用户重复使用，只在用户浏览器和服务器之间共享。如果提交后没有这个隐藏的字段，或者字段值不匹配，服务器就可以认为是CSRF攻击，从而拒绝响应该请求。而黑客无法提前知道这个值，从而无法伪造出一个合法的请求。

● 第二种方法，就是配合验证码使用，原理跟CSRF Token基本一致，但在用户体验上，多一个手工输入的过程。

● 第三种方法，就是再次身份认证，可以跟首次身份认证相同，也可以不同，比如在正常的口令之外，设置第二次口令。再次身份认证常用于用户登录后访问特别重要的功能时使用，如修改口令、购物支付、转账确认、发送红包、查询工资等场景。

4.5、跨目录操纵防护

对于跨目录操纵（用户通过../实现跨目录）的防护一般是：

● 在实际的业务设计中，要尽可能避免使用服务器侧的路径或文件名。
● 如果业务无法避免，需要限定目录，并尽量使用整型的ID进行操作。

4.6、SSRF防护

SSRF（服务器端请求伪造），通常是由用户提交经过构造的内网地址及参数，常用于攻击内部系统。

对于SSRF的防护，一般是：

● 断绝该业务服务器跟内网的网络通路，例如部署在与内网隔离的网络区域，如DMZ或外网区。针对互联网行业来说，通常没有专用的外网区，可以考虑购置云主机来解决。
● DNS只查询一次，比如基于IP自行构建请求包（内置的基于域名的函数库，由于不能指定IP地址，就不能直接使用了）。

4.7、上传漏洞的防护

上传漏洞一般是由于系统对用户上传的内容没有做安全的处置导致的问题。

对于上传漏洞的防护，一般是：

● 对于上传请求，不能信任请求头部声称的文件类型。
● 用户上传的文件只能存放在固定的目录或其子目录下面（如果用户指定目录则可能会将用户上传的文件放在可解析目录下），且该目录不得由应用服务器提供解析执行功能。
● 用户上传的文件只能按静态文件处理，只能由处理静态内容的静态服务器（如Nginx、Apache）直接解析，而不能由处理动态内容的应用服务器（PHP、JSP、ASPX等）来解析，防止恶意内容被解析执行。
● 不能使用原始文件名，防止其他环节失效时，恶意提交者直接使用原始文件名发起访问。

4.8、遍历查询的防护

遍历查询一般是由于权限控制没有做好导致的安全问题。

防止通过遍历查询的一般措施是：

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