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

  不久前国家信息安全漏洞共享平台正式发布通告“Oracle数据库勒索病毒RushQL死灰复燃”。事实上,RushQL勒索病毒已经不是第一次肆虐Oracle数据库,早在 2016 年 11 月就已经在全球掀起了一场血雨腥风。当然,那时候它有个更响亮的名字“比特币勒索病毒”。

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

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

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

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

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

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

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

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

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

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

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

  主动防御减少威胁

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

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

  权限控制解决拖库

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

  应用透明

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

  政策合规满足标准

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

  数据保密性

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

  访问控制性

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

  安全审计性

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

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


qq tel code back_top