Oracle数据库勒索病毒卷土重来，安全厂商要做什么

不久前国家信息安全漏洞共享平台正式发布通告“Oracle数据库勒索病毒RushQL死灰复燃”。

事实上，RushQL勒索病毒已经不是第一次肆虐Oracle数据库，早在2016年11月就已经在全球掀起了一场血雨腥风。当然，那时候它有个更响亮的名字“比特币勒索病毒”。

目光回溯到2016年11月，全国多家企事业单位遭受比特币勒索通知“你的数据库已被锁死，发送5个比特币到这个地址！”。用户在登陆Oracle数据库时出现如下勒索警告信息，被要求上交5个比特币来换取解锁数据库的服务。

尽管这场战役防守方取得了胜利，但时隔两年，RushQL勒索病毒卷土重来，发动新一轮的肆虐。

不少围观群众情不自禁反问，为什么我们会遭到同一勒索病毒连续攻击？数据库安全厂商能帮助数据库用户做些什么？在不久前安华金和发布的《2017-2018数据库安全应用指南》似乎可以寻找到一些技能。

简单说，企业对数据库安全的需求共同点有如下四点：

数据库运维人员，拥有高权限账号可以直接对数据库进行信息检索、查询和修改。

第三方人员可能会在业务系统及数据库系统中留有后门程序，长期监控、窃取数据。

黑客利用攻击手段盗取敏感数据。

数据库安全现状未知，无法掌握数据库漏洞情况、配置情况、敏感数据分布等内容。

而针对这些情况安全厂商应该做的是什么？

周期防护构建纵深防护体系

为了解决数据库在防攻击、防篡改、防丢失、防泄密、防超级权限、内部高危操作等问题。数据库的安全防护应从数据库安全的三维角度，构建事前-事中-事后的全生命周期数据安全过程，并结合多层次安全技术防护能力，形成整体的数据库纵深防护体系。

主动防御减少威胁

通过事中主动防御手段在数据库前端对入侵行为做到有效的控制，通过强大特征库和漏洞防御库，主动防御内外部用户的违规操作以及黑客的入侵行为。

对IP/MAC等要素进行策略配置，确保应用程序的身份安全可靠。通过黑白名单对敏感数据访问控制，定义非法用户行为的方式定义安全策略，有效通过SQL注入特征识别库。

权限控制解决拖库

从数据库级别应进行最小化权限控制，杜绝超级管理员的产生，通过数据库防火墙和数据库加密措施进行从根源上彻底控制 数据信息的泄露，为信息化打好底层基础。有效防止存储文件和备份文件被“拖库”的风险。

应用透明

技术的实施应对于现有应用系统基本透明，对原有数据库特性、原有应用无改造，不改变应用及用户使用习惯。

政策合规满足标准

在等级保护、分级保护基本要求中，数据库安全是主机安全的一个部分，数据库的测评指标是从“主机安全”和“数据安全及备份恢复”中根据数据库的特点映射得到的。对等保三级、分保秘密级以上系统中，关键敏感数据的安全防护要求满足了标准特性：

数据保密性

满足了“实现系统管理数据、鉴别信息和重要业务数据的存储保密性”。

访问控制性

实现了最小授权原则，使得用户的权限最小化，同时要求对重要信息资源设置敏感标记。

安全审计性

完成了“对用户行为、安全事件等进行记录”。

从数据库安全的时代沿革来看，我们走过了系统安全主导的DBMS1.0时代，这个阶段是以网络安全思想作数据库安全，强调防护与防入侵；正在经历以数据为中心，由场景化安全主导的2.0时代，这个阶段强调数据在使用、流动、共享等场景中的安全；而接下来在国家战略政策层面驱动下，组织将更加强调内部流程、规范与技术的整合，在整体体系化安全的建设需求驱动下，以数据安全治理为核心的3.0时代即将到来。