为什么WAF（Web Aplication Firewalls）不能确保数据库安全？（为什么新版红绿灯会惹争议）

为什么WAF（Web Aplication Firewalls）不能确保数据库安全？（为什么新版红绿灯会惹争议）

Web 应用程序防火墙（WAF）现在已经成为许多商业 Web 网站与系统的基本保护措施，它的确在防范许多针对 Web 系统的安全攻击方面卓有成效，但是 WAF 在面对攻击方式多种多样的 SQL 注入方面还是显得束手无策。

背景知识：什么是 WAF？

Web 应用防火墙（WAF）是一种基础的安全保护模块，主要针对 HTTP 访问的 Web 程序保护，部署在 Web 应用程序前面，在用户请求到达 Web 服务器前对用户请求进行扫描和过滤，分析并校验每个用户请求的网络包，确保每个用户请求有效且安全，对无效或有攻击行为的请求进行阻断或隔离。

数据库暴露的访问点多种多样

从 WAF 的原理来看，WAF 并不能完全保护 Web 应用程序免受 SQL 注入攻击，因为它在 Web 应用程序外部，不了解应用程序的上下文，不知道目标数据库的类型，这就从根本上决定了 WAF 只能防范最常见的 SQL 注入方式。

即使 WAF 做的足够好，能够防范绝大多数从 Web 系统进入的 SQL 注入攻击，也不能断言数据库得到了全面的保护，因为能访问数据库的不仅仅是 Web 系统，还有许多其他途径。

除了 Web 系统外，还有三类主要的数据库访问途径：

组织内其他应用系统能访问数据库：比如在电子商务系统里，价格和库存可能会用一些自动化的脚本来定时更新。 一些内部管理程序可以访问系统，也可能是一些接口，方便雇员添加信息或者发送信息给客户。 还有就是数据库 DBA，IT 经理，QA，开发人员等等内部人员通过数据库管理工具可以访问数据库。

WAF 只监控通过 HTTP 方式来的数据，这些潜在的数据库访问源头 WAF 是毫不知情的，但是来自内部的攻击则更可怕。内部人员非常清楚数据库的结构和内容，目标性也更加明确，不是获取经济利益就是获取大量内部信息，造成的危害可以说是毁灭性的，比如前两年发生在银行客户数据库大规模泄露事件就很清晰地证明了这一点。同时现在黑客攻击手段越来越高明，翻墙技术已经非常成熟，而且在云时代有明显边界的网络拓扑结构越来越少。总之，WAF 对 SQL 注入攻击的防护作用越来越小。

多维度数据库保护是万全之策

既然数据库的访问途径很多，要想比较好的解决数据泄露的危险，多维度防护才是最佳方法，只有堵住每条可能泄露的攻击才能确保数据库的安全，可能的方法包括但不仅限于：

数据库防火墙 模式学习过程 职责分离 风险为基础的政策 敏感信息屏蔽 定期审计管理和访问敏感信息

运行时应用程序自我保护（RASP）

数据库防火墙

数据库防火墙技术是针对关系型数据库保护需求应运而生的一种数据库安全主动防御技术，数据库防火墙部署于应用服务器和数据库之间。用户必须通过该系统才能对数据库进行访问或管理。数据库防火墙所采用的主动防御技术能够主动实时监控、识别、告警、阻挡绕过企业网络边界（FireWall、IDS\IPS等）防护的外部数据攻击、来自于内部高权限用户（DBA、开发人员、第三方外包服务提供商）的数据窃取、破坏、损坏等，从数据库 SQL 语句精细化控制的技术层面，提供一种主动的安全防御措施。

模式匹配学习过程

基于自学习机制的风险管控模型，主动监控数据库活动，防止未授权的数据库访问、SQL 注入、权限或角色升级，与对敏感数据的非法访问等。

基于风险管理的策略

任何类型的数据库查询语句或命令，都可以用一些方法来评估。影响风险评估的因素包括白名单和黑名单，命令是从哪里过来的，在一定时间有多少个类似的命令等等，利用所有的信息，一个基于规则的系统可以借助一系列的规则来评估哪些命令是可疑的。

权责分明

为数据库访问分配适当的权限是非常必要的。基于 Web 的应用程序只应该有有限的查询权限，数据库管理员拥有更大的管理权限是有必要的。通过适当地执行职责分离，可以有效避免多种数据库攻击。

混淆敏感数据

定时审计对敏感数据的管理和访问行为

一致的和可靠的审计过程中，寻找可疑的活动和更新政策，不断提高数据库安全还有很长的路要走。今天的数据库安全产品可以根据可定制的规则对某些种类的访问提供警报服务。

让每个公司都能保护得起数据库安全