为什么WAF（WebApplicationFirewall）不能确保数据库安全？
(window.slotbydup=window.slotbydup || []).push({
id: '2611110',
container: s,
size: '240,200',
display: 'inlay-fix'
您当前位置： &
[ 所属分类
作者 红领巾 ]
警告：不要认为有了WAF的保护，数据库安全就可以高枕无忧了，数据库仍然有很大的暴露风险。Web应用程序防火墙（WAF）现在已经成为很多商业Web网站和系统的基本保护措施了，它的确在防范很多针对Web系统的安全攻击有比较好的效果，但是WAF在面对攻击方式多种多样的SQL注入方面还是显得束手无策。背景知识：什么是WAF？Web应用防火墙（WAF）是一种基础的安全保护模块，主要针对HTTP访问的Web程序的保护，放在Web应用程序前面，在用户请求到达Web服务器前对用户请求进行扫描和过滤，分析和校验每个用户请求的网络包，确保每个用户请求是有效并安全的，对无效或者有攻击行为的请求进行阻断或隔离。WAF可以通过定义一些常见的SQL注入的特征码对常见SQL注入提供防护，比如SQL注入代码加入到某些命令或某些输入，这些WAF是没有问题的。但是市面上的关系型数据的种类非常多，虽然有统一的SQL结构化数据查询语言，但是每个数据库的具体实现有非常多的不一样，这些不一样就导致了多种多样的SQL注入攻击方式的产生。因此也就导致了像WAF这样安全保护系统在不理解应用程序的上下文，不熟悉数据库类型，命令，结构的情况下，仅仅靠分析网络数据包，加上定义一些数据库特殊字符黑名单，去防护多种多样的SQL注入攻击是远远不够的。笔者非常认可WAF在Web应用安全防护方面能起比较大的作用，能防护很多Web攻击，也非常鼓励每个企业去使用WAF为Web应用程序提供安全保障，但是千万不要天真的认为，有了WAF你的数据库就安全了，这种想法非常的危险。数据库暴露的访问点多种多样从WAF的原理来看，WAF并不能完整的保护Web应用程序免受SQL注入攻击，因为它在Web应用程序外部，不了解应用程序的上下文，不知道目标数据库的类型，这就从根本上决定了WAF只能防范最通用的SQL注入方式。即使WAF做的足够好能够防范绝大多数从Web系统进入的SQL注入攻击，也不能说数据库就得到了很好的保护，因为能访问数据库的源头不仅仅是Web系统，还有很多其他途径能访问数据库。除了Web系统外还有三类主要的数据库访问途径：组织内其他应用系统能访问数据库：比如在电子商务系统里，价格和库存可能会用一些自动化的脚本来定时更新。 一些内部管理程序可以访问系统，也可能是一些接口，方便雇员添加信息或者发送信息给客户。 还有数据库DBA，IT经理，QA，开发人员等等内部人员通过数据库管理工具可以访问数据库。WAF只监控通过HTTP方式将来的数据，这些潜在的数据库访问源头WAF是毫不知情的，但来自内部的攻击更可怕，内部人员非常清楚数据库的结构和内容，目标性也更加明确，不是获取经济利益就是获取大量内部信息，造成的危害可以说是毁灭性的，比如前两年发生在银行客户数据库大规模泄露事件就很清楚的证明了这一点。同时现在攻击手段越来越高明，技术已经非常成熟，而且在云时代有明显边界的网络拓扑结构越来越少。总之WAF对SQL注入攻击的防护作用越来越小。多维度数据库保护是完全之策既然数据库的方面途径很多，要想比较好的解决数据泄露的的危险，多维度防护是最佳方法，只有堵住每条可能泄露的攻击才能确保数据库的安全，可能的方法包括但不仅限于：运行时应用程序自我保护（RASP）。 数据库防火墙。 模式学习过程。 职责分离。 风险为基础的政策。 敏感信息屏蔽。 定期审计管理和访问敏感信息。运行时应用程序自我保护（RASP）RASP针对应用程序保护，不仅仅是对Web应用测试，它将代码扫描工具的漏洞发现功能和WAF的实时攻击拦截能力结合起来，将这些防护功能像疫苗一样注入到应用程序中，让应用程序像人体拥有疫苗一样对攻击拥有免疫能力，他可以找到所有已知漏洞，像一个虚拟的大补丁将所有的已知漏洞修补起来，免于大多数漏洞攻击，同时它和应用程序一起运行是同一个进程，拥有应用程序的上下文，了解应用程序的每一个动作，因此他能精确的了解每一个攻击并能够实时对攻击进行防御。比如SQL注入，它在每个数据库的JDBC的statement具体实现里，根据对每个数据的不同，有针对性的将SQL注入保护程序注入，这样就能确保各种可能的SQL注入攻击得到有效的防范，并且这个防护是在应用程序访问数据库的必经之路，是不可绕过的。这两个优势是WAF无法企及的。如果每个应用程序都进行RASP保护，至少无论内外通过应用进行SQL注入基本上是不可能的，这样就可以堵住应用程序访问数据库的漏洞。目前RASP是比较新的概念，国外有HP在做，国内好像有一个初创安全OneASP在做类似的产品，大家有有兴趣可以关注一下。数据库防火墙数据库防火墙技术是针对关系型数据库保护需求应运而生的一种数据库安全主动防御技术，数据库防火墙部署于应用服务器和数据库之间。用户必须通过该系统才能对数据库进行访问或管理。数据库防火墙所采用的主动防御技术能够主动实时监控、识别、告警、阻挡绕过企业网络边界（FireWall、IDS\IPS等）防护的外部数据攻击、来自于内部的高权限用户（DBA、开发人员、第三方外包服务提供商）的数据窃取、破坏、损坏等，从数据库SQL语句精细化控制的技术层面，提供一种主动安全防御措施。模式匹配学习过程基于自学习机制的风险管控模型，主动监控数据库活动，防止未授权的数据库访问、SQL注入、权限或角色升级，以及对敏感数据的非法访问等。基于风险管理的策略任何类型的数据库查询语句或命令，都可以用一些方法来评估。影响风险评估的因素包括白名单和黑名单，命令是从哪里过来的，在一定时间有多少个类似的命令等等，利用所有的信息，一个基于规则的系统可以使用这些信息来通过一系列的规则来评估那些命令是可疑的。权责分明为数据库访问分配适当的权限是非常必要的。基于Web的应用程序只应该有有限的查询权限，数据库管理员拥有更大的管理权限是有必要的。通过适当的执行职责分离，可以有效的避免多种数据库攻击。混淆敏感数据所有人都应该能查看敏感数据，甚至包括数据库管理员，程序员，以及高管。DBA可以执行一些数据库管理任务，但是没有必要让他们能看到数据库中个人的敏感数据，为了达到这个目的，使用一个非常强大的和实时的数据混淆解决方案是非常重要的。一些组织使用离线的“生产”系统进行屏蔽，但随着实时数据的混淆的成熟，实时数据混淆系统在成本和避免数据更新方面有更大的优势，所有改变都可以实时在数据库中体现。定时审计对敏感数据的管理和访问行为一致的和可靠的审计过程中，寻找可疑的活动和更新政策，不断提高数据库安全有很长的路要走。今天的数据库安全产品可以根据可定制的规则对某些种类的访问提供警报服务。让每个公司都能保护得起数据库安全在以前数据库安全保护只有少数大公司能够花大价钱才能搞好，数据库防火墙非常昂贵，制定规则，审计行为都需要大量的人力去解决，小公司基本没有能力去做。现在RASP是一种非常好的解决方案，只要制定简单规则，比如只有管理员能访问生产数据库等，其他所有数据库访问都通过应用程序访问，而每个应用程序都安装RASP保护程序，这样数据库的安全是有保障的。
本文业界资讯相关术语:网络安全论文 网络安全密钥 网络安全工程师 网络安全技术与应用 网络安全概念股 网络安全知识 网络安全宣传周 网络安全知识竞赛 网络安全事件
转载请注明本文标题：本站链接：
分享请点击：
1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责；
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性，不作出任何保证或承若；
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
CodeSecTeam微信公众号
优秀是一种习惯！
手机客户端为什么WAF（Web Aplication Firewalls）不能确保数据库安全？
时间： 14:52:51
&&&& 阅读：76
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&警告：不要以为有了&&的保护，数据库安全就万无一失了。事实上，数据库仍然存在很大的安全隐患。
Web 应用程序防火墙（WAF）现在已经成为许多商业 Web 网站与系统的基本保护措施，它的确在防范许多针对 Web 系统的安全攻击方面卓有成效，但是 WAF 在面对攻击方式多种多样的 SQL 注入方面还是显得束手无策。
背景知识：什么是 WAF？
Web 应用防火墙（WAF）是一种基础的安全保护模块，主要针对 HTTP 访问的 Web 程序保护，部署在 Web 应用程序前面，在用户请求到达 Web 服务器前对用户请求进行扫描和过滤，分析并校验每个用户请求的网络包，确保每个用户请求有效且安全，对无效或有攻击行为的请求进行阻断或隔离。
WAF 可通过定义一些常见的 SQL 注入特征码对常见 SQL 注入攻击提供防护，比如 SQL 注入代码加入到某些命令或某些输入，这些 WAF 是没有问题的。但是市面上的关系型数据总类非常多，虽然有统一的 SQL 结构化数据查询语言，但是每个数据库的具体实现有非常多的差异，这些差异就导致了多种 SQL 注入攻击方式的产生。因此也就导致了像 WAF 这类安全保护系统在不理解应用程序的上下文，不熟悉数据库类型、命令、结构的情况下，仅仅通过分析网络数据包，加上定义一些数据库特殊字符黑名单，远远不足以防护多种多样的&。
WAF 在 Web 应用安全防护方面的作用的确值得认可，它能有效防护多种 Web 攻击，每个企业都应该使用 WAF 为 Web 应用程序提供安全保障。但是，千万不要天真地以为，有了 WAF 你的数据库就安全了，这种想法非常的危险。
数据库暴露的访问点多种多样
从 WAF 的原理来看，WAF 并不能完全保护 Web 应用程序免受 SQL 注入攻击，因为它在 Web 应用程序外部，不了解应用程序的上下文，不知道目标数据库的类型，这就从根本上决定了 WAF 只能防范最常见的 SQL 注入方式。
即使 WAF 做的足够好，能够防范绝大多数从 Web 系统进入的 SQL 注入攻击，也不能断言数据库得到了全面的保护，因为能访问数据库的不仅仅是 Web 系统，还有许多其他途径。
除了 Web 系统外，还有三类主要的数据库访问途径：
组织内其他应用系统能访问数据库：比如在电子商务系统里，价格和库存可能会用一些自动化的脚本来定时更新。
一些内部管理程序可以访问系统，也可能是一些接口，方便雇员添加信息或者发送信息给客户。
还有就是数据库 DBA，IT 经理，QA，开发人员等等内部人员通过数据库管理工具可以访问数据库。
WAF 只监控通过 HTTP 方式来的数据，这些潜在的数据库访问源头 WAF 是毫不知情的，但是来自内部的攻击则更可怕。内部人员非常清楚数据库的结构和内容，目标性也更加明确，不是获取经济利益就是获取大量内部信息，造成的危害可以说是毁灭性的，比如前两年发生在银行客户数据库大规模泄露事件就很清晰地证明了这一点。同时现在黑客攻击手段越来越高明，FQ技术已经非常成熟，而且在云时代有明显边界的网络拓扑结构越来越少。总之，WAF 对 SQL 注入攻击的防护作用越来越小。
多维度数据库保护是万全之策
既然数据库的访问途径很多，要想比较好的解决数据泄露的危险，多维度防护才是最佳方法，只有堵住每条可能泄露的攻击才能确保数据库的安全，可能的方法包括但不仅限于：
运行时应用程序自我保护（RASP）
数据库防火墙
模式学习过程
风险为基础的政策
敏感信息屏蔽
定期审计管理和访问敏感信息
运行时应用程序自我保护（RASP）
RASP 针对应用程序保护的，不仅仅是对 Web 应用测试，它将代码扫描工具的漏洞发现功能和 WAF 的实时攻击拦截能力结合起来，将这些防护功能像疫苗一样注入到应用程序中，让应用程序像人体拥有疫苗一样对攻击拥有免疫能力，找到所有已知漏洞，像一个虚拟的大补丁一样修补所有已知漏洞，免于大多数漏洞攻击，同时它和应用程序一起运行同一个进程，拥有应用程序的上下文，了解应用程序的每一个动作，因此能精确了解每一个攻击并能够实时对攻击进行防御。比如 SQL 注入，它在每个数据库 JDBC 的 statement 具体实现里，根据每个不同的数据，有针对性地将 SQL 注入保护程序注入，这样就能确保各种可能的 SQL 注入攻击得到有效的防范，并且这个防护是在应用程序访问数据库的必经之路，是不可绕过的。这两个优势是 WAF 无法企及的。如果每个应用程序都进行 RASP 保护，至少无论内外通过应用进行 SQL 注入基本上是不可能的，这样就可以堵住应用程序访问数据库的漏洞。目前 RASP 是比较新的概念，国外有 HP 在做，国内有一个初创安全&&在做类似的产品，大家有有兴趣可以关注一下。
数据库防火墙
数据库防火墙技术是针对关系型数据库保护需求应运而生的一种数据库安全主动防御技术，数据库防火墙部署于应用服务器和数据库之间。用户必须通过该系统才能对数据库进行访问或管理。数据库防火墙所采用的主动防御技术能够主动实时监控、识别、告警、阻挡绕过企业网络边界（FireWall、IDS\IPS等）防护的外部数据攻击、来自于内部高权限用户（DBA、开发人员、第三方外包服务提供商）的数据窃取、破坏、损坏等，从数据库 SQL 语句精细化控制的技术层面，提供一种主动的安全防御措施。
模式匹配学习过程
基于自学习机制的风险管控模型，主动监控数据库活动，防止未授权的数据库访问、SQL 注入、权限或角色升级，与对敏感数据的非法访问等。
基于风险管理的策略
任何类型的数据库查询语句或命令，都可以用一些方法来评估。影响风险评估的因素包括白名单和黑名单，命令是从哪里过来的，在一定时间有多少个类似的命令等等，利用所有的信息，一个基于规则的系统可以借助一系列的规则来评估哪些命令是可疑的。
为数据库访问分配适当的权限是非常必要的。基于 Web 的应用程序只应该有有限的查询权限，数据库管理员拥有更大的管理权限是有必要的。通过适当地执行职责分离，可以有效避免多种数据库攻击。
混淆敏感数据
所有人都应该能查看敏感数据，甚至包括数据库管理员，程序员，以及高管。DBA 可以执行一些数据库管理任务，但是没有必要让他们能看到数据库中个人的敏感数据，为了达到这个目的，使用一个非常强大的和实时的数据混淆解决方案是非常重要的。一些组织使用离线的&生产&系统进行屏蔽，但随着实时数据的混淆的成熟，实时数据混淆系统在成本和避免数据更新方面有更大的优势，所有改变都可以实时在数据库中体现。
定时审计对敏感数据的管理和访问行为
一致的和可靠的审计过程中，寻找可疑的活动和更新政策，不断提高数据库安全还有很长的路要走。今天的数据库安全产品可以根据可定制的规则对某些种类的访问提供警报服务。
让每个公司都能保护得起数据库安全
在以前，数据库安全保护只有少数大公司花大价钱才能搞好，数据库防火墙非常昂贵。制定规则，审计行为都需要大量的人力去解决，小公司基本没有能力去做。现在&RASP&是一种非常好的解决方案，只要制定简单规则，比如只有管理员能访问生产数据库等，其他所有数据库访问都通过应用程序进行，而每个应用程序都安装 RASP 保护程序，这样数据库的安全才是有保障的。
（实时应用自我保护）是一种基于云的应用程序自我保护服务， 可以为软件产品提供实时保护，使其免受漏洞所累。
转自：/waf-onerasp-dba/
更多：/标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&原文：/qijiayi/p/4997543.html
教程昨日排行
&&国之画&&&& &&&&&&
&& &&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！(window.slotbydup=window.slotbydup || []).push({
id: '2014386',
container: s,
size: '234,60',
display: 'inlay-fix'
&&|&&0次下载&&|&&总51页&&|
您的计算机尚未安装Flash，点击安装&
阅读已结束，如需下载到电脑，请使用积分（）
下载：20积分
0人评价38页
0人评价17页
0人评价44页
0人评价3页
0人评价31页
所需积分：（友情提示：大部分文档均可免费预览！下载之前请务必先预览阅读，以免误下载造成积分浪费！）
（多个标签用逗号分隔）
文不对题，内容与标题介绍不符
广告内容或内容过于简单
文档乱码或无法正常显示
若此文档涉嫌侵害了您的权利，请参照说明。
我要评价：
下载：20积分为什么 WAF 不能确保数据库安全？ - 推酷
为什么 WAF 不能确保数据库安全？
Web 应用程序防火墙（WAF）现在已经成为许多商业 Web 网站与系统的基本保护措施，它的确在防范许多针对 Web 系统的安全攻击方面卓有成效，但是 WAF 在面对攻击方式多种多样的 SQL 注入方面还是显得束手无策。所以，不要以为有了 WAF 的保护，数据库安全就万无一失了。事实上，数据库仍然存在很大的安全隐患。
背景知识：什么是 W AF？ ?
Web 应用防火墙（WAF）是一种基础的安全保护模块，主要针对 HTTP 访问的 Web 程序保护，部署在 Web 应用程序前面，在用户请求到达 Web 服务器前对用户请求进行扫描和过滤，分析并校验每个用户请求的网络包，确保每个用户请求有效且安全，对无效或有攻击行为的请求进行阻断或隔离。
WAF 可通过定义一些常见的 SQL 注入特征码对常见 SQL 注入攻击提供防护，比如 SQL 注入代码加入到某些命令或某些输入，这些 WAF 是没有问题的。但是市面上的关系型数据总类非常多，虽然有统一的 SQL 结构化数据查询语言，但是每个数据库的具体实现有非常多的差异，这些差异就导致了多种 SQL 注入攻击方式的产生。因此也就导致了像 WAF 这类安全保护系统在不理解应用程序的上下文，不熟悉数据库类型、命令、结构的情况下，仅仅通过分析网络数据包，加上定义一些数据库特殊字符黑名单，远远不足以防护多种多样的 SQL 注入攻击。
WAF 在 Web 应用安全防护方面的作用的确值得认可，它能有效防护多种 Web 攻击，每个企业都应该使用 WAF 为 Web 应用程序提供安全保障。但是，千万不要天真地以为，有了 WAF 你的数据库就安全了，这种想法非常的危险。
数据库暴露的访问点多种多样
从 WAF 的原理来看，WAF 并不能完全保护 Web 应用程序免受 SQL 注入攻击，因为它在 Web 应用程序外部，不了解应用程序的上下文，不知道目标数据库的类型，这就从根本上决定了 WAF 只能防范最常见的 SQL 注入方式。
即使 WAF 做的足够好，能够防范绝大多数从 Web 系统进入的 SQL 注入攻击，也不能断言数据库得到了全面的保护，因为能访问数据库的不仅仅是 Web 系统，还有许多其他途径。
除了 Web 系统外，还有三类主要的数据库访问途径：
1.组织内其他应用系统能访问数据库：比如在电子商务系统里，价格和库存可能会用一些自动化的脚本来定时更新。
2.一些内部管理程序可以访问系统，也可能是一些接口，方便雇员添加信息或者发送信息给客户。
3.还有就是数据库 DBA，IT 经理，QA，开发人员等等内部人员通过数据库管理工具可以访问数据库。
WAF 只监控通过 HTTP 方式来的数据，这些潜在的数据库访问源头 WAF 是毫不知情的，但是来自内部的攻击则更可怕。内部人员非常清楚数据库的结构和内容，目标性也更加明确，不是获取经济利益就是获取大量内部信息，造成的危害可以说是毁灭性的，比如前两年发生在银行客户数据库大规模泄露事件就很清晰地证明了这一点。同时现在黑客攻击手段越来越高明，翻墙技术已经非常成熟，而且在云时代有明显边界的网络拓扑结构越来越少。总之，WAF 对 SQL 注入攻击的防护作用越来越小。
多维度数据库保护是万全之策
既然数据库的访问途径很多，要想比较好的解决数据泄露的危险，多维度防护才是最佳方法，只有堵住每条可能泄露的攻击才能确保数据库的安全，可能的方法包括但不仅限于：
运行时应用程序自我保护（RASP）
1.数据库防火墙
2.模式学习过程
3.职责分离
4.风险为基础的政策
5.敏感信息屏蔽
6.定期审计管理和访问敏感信息
运行时应用程序自我保护（RASP）
RASP 针对应用程序保护的，不仅仅是对 Web 应用测试，它将代码扫描工具的漏洞发现功能和 WAF 的实时攻击拦截能力结合起来，将这些防护功能像疫苗一样注入到应用程序中，让应用程序像人体拥有疫苗一样。
对攻击拥有免疫能力，找到所有已知漏洞，像一个虚拟的大补丁一样修补所有已知漏洞，免于大多数漏洞攻击，同时它和应用程序一起运行同一个进程，拥有应用程序的上下文，了解应用程序的每一个动作，因此能精确了解每一个攻击并能够实时对攻击进行防御。比如 SQL 注入，它在每个数据库 JDBC 的 statement 具体实现里，根据每个不同的数据，有针对性地将 SQL 注入保护程序注入，这样就能确保各种可能的 SQL 注入攻击得到有效的防范，并且这个防护是在应用程序访问数据库的必经之路，是不可绕过的。这两个优势是 WAF 无法企及的。如果每个应用程序都进行 RASP 保护，至少无论内外通过应用进行 SQL 注入基本上是不可能的，这样就可以堵住应用程序访问数据库的漏洞。目前 RASP 是比较新的概念，国外有 HP 在做，国内有一个初创安全
在做类似的产品，有兴趣可以关注一下。
数据库防火墙
数据库防火墙技术是针对关系型数据库保护需求应运而生的一种数据库安全主动防御技术，数据库防火墙部署于应用服务器和数据库之间。用户必须通过该系统才能对数据库进行访问或管理。数据库防火墙所采用的主动防御技术能够主动实时监控、识别、告警、阻挡绕过企业网络边界（FireWall、IDS\IPS等）防护的外部数据攻击、来自于内部高权限用户（DBA、开发人员、第三方外包服务提供商）的数据窃取、破坏、损坏等，从数据库 SQL 语句精细化控制的技术层面，提供一种主动的安全防御措施。
模式匹配学习过程
基于自学习机制的风险管控模型，主动监控数据库活动，防止未授权的数据库访问、SQL 注入、权限或角色升级，与对敏感数据的非法访问等。
基于风险管理的策略
任何类型的数据库查询语句或命令，都可以用一些方法来评估。影响风险评估的因素包括白名单和黑名单，命令是从哪里过来的，在一定时间有多少个类似的命令等等，利用所有的信息，一个基于规则的系统可以借助一系列的规则来评估哪些命令是可疑的。
为数据库访问分配适当的权限是非常必要的。基于 Web 的应用程序只应该有有限的查询权限，数据库管理员拥有更大的管理权限是有必要的。通过适当地执行职责分离，可以有效避免多种数据库攻击。
混淆敏感数据
所有人都应该能查看敏感数据，甚至包括数据库管理员，程序员，以及高管。DBA 可以执行一些数据库管理任务，但是没有必要让他们能看到数据库中个人的敏感数据，为了达到这个目的，使用一个非常强大的和实时的数据混淆解决方案是非常重要的。一些组织使用离线的“生产”系统进行屏蔽，但随着实时数据的混淆的成熟，实时数据混淆系统在成本和避免数据更新方面有更大的优势，所有改变都可以实时在数据库中体现。
定时审计对敏感数据的管理和访问行为
一致的和可靠的审计过程中，寻找可疑的活动和更新政策，不断提高数据库安全还有很长的路要走。今天的数据库安全产品可以根据可定制的规则对某些种类的访问提供警报服务。
让每个公司都能保护得起数据库安全
在以前，数据库安全保护只有少数大公司花大价钱才能搞好，数据库防火墙非常昂贵。制定规则，审计行为都需要大量的人力去解决，小公司基本没有能力去做。现在 RASP 是一种非常好的解决方案，只要制定简单规则，比如只有管理员能访问生产数据库等，其他所有数据库访问都通过应用程序进行，而每个应用程序都安装 RASP 保护程序，这样数据库的安全才是有保障的。
*本文作者：ONEASP（团队账户），转载须注明来自FreeBuf黑客与极客（）
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致