风险从来都不是臆想和草木皆兵，就在你不经意的时刻，可能风险就突然降临到我们的身边。
2016年年底，国内很多用户的 Oracle 数据库遭遇突如其来的比特币攻击事件，大家种种猜测、揣摩、重试，引发了一次小小的数据恐慌。直至今日，还有用户爆发出该问题。现在我们再次回顾与总结，与中国的数据库用户们共为警醒。
我们知道，几乎绝大多数数据库的客户端工具，在访问数据库时，都可以通过脚本进行一定的功能定义，而这些脚本往往就是安全问题的漏洞之一，黑客通过 JOB、触发器、存储过程对数据库进行修改和破坏，手段非常初级，但是也非常巧妙。
问题症状
很多用户在录数据库时发现该问题，数据库应用弹出“锁死”提示，并且威胁说需要向黑客发送5个比特币方可获得解锁。
在客户端，可能获得类似的提示信息：
除了这些警示和勒索信息，真正的攻击是在数据库中创建了大量的攻击程序。
若攻击的核心代码包含以下语句，则会 Truncate 数据表：STAT：='truncate table '||USER||'.'||I.TABLE_NAME。
我们对事件进行了深入分析，找到问题的根本原因是用户从互联网上下载的盗版PL/SQL Developer 工具（尤其是各种绿色版、破解版），在使用工具的過程中用户的权限自然被附体地进行了入侵。
受感染文件
在该软件的安装目录有一个脚本文件 AfterConnect.sql， 正版软件的这个文件为空，此时 AfterConnect.sql 开头被伪装成一个 login.sql 的脚本内容，有清晰的注释代码：
实质内容被加密，用户只能通过 unwrap 进行解密（要留意解密程序也可能存在恶意代码）：
无疑，黑客是非常了解 Oracle 数据库的，其脚本代码的核心部分，解密后如下（做了删减）：
同时，黑客非常专业，在程序的开端做了以下判断：
也就是，判断数据库创建时间大于1200天，才开始动作（这个判断相当有见地，小库和新库，数据少不重要，先放长线钓大鱼），如果你的数据库还没有爆发，那可能是因为时间还没有到。
如何应对
如果数据库遭遇到这个问题，可以将 JOB 参数 job_queue_processes 设置为 0 ，屏蔽掉 JOB 的执行，然后重启数据库。可以清除注入对象，这些对象可能包括以下同名触发器和存储过程：
数据安全的十六条军规
安全防范 请从今日开始
这次数据库安全事故，因为受害者众多，引发了企业的普遍关注。有的企业甚至要求停用PL/SQL Developer这一工具。但是我们知道数据库类似的门如此之多，如何能够从根本上提升数据库管理的安全，减少数据运维风险呢？
我曾在《数据安全警示录》一书中总结了种种数据安全风险，提出了很多预防措施和手段，在此整理其中一些建议供大家参考。
数据安全可以基于五个纬度来梳理：软件安全、备份安全、访问安全、防护安全、管理安全。并据此建立相应的安全防护措施。
在这五大方向中，可能出现两种性质的安全问题，第一，由于内部管理不善而导致的数据安全问题；第二，由于外部恶意攻击入侵所带来的安全问题。通常我们把安全问题狭义化为后者，这实际上是片面的，在数据安全问题上，前者造成的数据损失、数据损毁，其发生率和影响度都远远超过后者。
在企业数据安全中，这五大方面是相辅相成、互有交叉、共同存在的，其中软件安全是数据库安全的基础，而备份安全是最重要却最容易被忽略的方面。有效备份才能在故障之后获得及时的恢复和挽救。很多历史事件表明，备份安全问题导致的企业伤害可能远远大于黑客攻击。
针对本次的比特币勒索事件，我抽取书中的观点，总结提升数据库安全的“16条军规”供大家参考。
■备份重于一切：我曾经在总结的DBA四大守则的第一条就指出，备份重于一切。对于重要的生产环境，适当建立备库进行数据保护，查询分担，会减少生产库的风险；而在故障发生时，有效备份可以保证系统获得及时的恢复和挽救；
如果有什么会让DBA们从梦中惊醒，那就是没有备份！ 所以对于数据库运维来说，第一重要的是做好备份，有备方能无患；
■严格管控权限：在进行用户授权时一定要遵循最小权限授予原则，避免因为过度授权而带来的安全风险。本次安全风险，如果用户不具备DDL权限，那么也不会遭到风险；
■明确用户职责：明确不同的数据库用户能够用于的工作范围，职权相称，最大限度避免错误，降低风险。 即便是拥有管理员职责的用户，也应当遵循以不同身份执行不同任务的习惯；
■密码策略强化：毫无疑问，数据库用户应当使用强化的密码规则，确保弱口令带来的安全风险，很多数据泄露问题来自弱口令攻击和提权；
■限制登录工具：明确限制不同工具的使用场景，规定工具的准确来源，或者通过堡垒机等来限制数据库访问。对于工具也可以做出相应规则和限制，以减少安全风险甚至误操作风险；
■禁止远程DDL：可以限制DDL操作仅能在数据库服务器本地进行，禁止远程连接执行DDL操作，这一手段在很多公司被严格执行，如果具备这一规则，此次的事故可以被直接屏蔽掉；
■使用绑定变量：在开发过程中，严格使用绑定变量，可以防范SQL注入攻击，减少数据库安全风险；这次安全事故，很多用户一开始都猜测是SQL注入，走了很多分析上的弯路；
■监控监听日志：监听日志记录了数据库访问的来源、程序等信息，包括恶意扫描，密码尝试等，一定要重视监听日志的作用，并对其进行分析和监控，以清楚的汇制数据库访问图谱；
■数据网络隔离：数据库的网络环境应该一直隐藏在最后端，避免将数据库置于直接的访问连接之下，由此可以减少数据库的访问风险；
■测试和生产隔离：互通就意味着同时可以访问，也就可能带来很多意想不到的风险，企业应当进行分离部署，一方面可以降低误操作的可能性，也可以屏蔽一些无关的访问，从而从网络链路上保证数据安全；
■密码差异设置：有些测试环境或者非产品环境是利用产品环境恢复得到的，DBA在建立了测试环境后，就没有修改数据库用户的登录密码，而也习惯在所有环境中设置通用的密码。这些习惯为系统带来了很多风险。 建议用户在不同环境中采用不同的密码设置，进一步降低了DBA在错误的环境下执行命令的可能性；
■重要数据加密：很多重要数据需要加密存储，最典型的就是用户和密码信息，大量的泄密事件本质上是因为缺乏最基本的加密防范，对重要数据实施一定的安全防护加密，是应当予以适时考虑的安全方面之一；
■适时的软件升级：这里的软件指数据库软件，尤其是当Oracle已经发布了安全补丁，已知的安全漏洞被黑客利用，则更可能对数据库产生致命的伤害；
■防范内部风险：不可否认，绝大部分安全问题都来自于企业内部，来自最紧密、最轻易的接触和访问，企业的人员变动、岗位变更，都可能导致数据安全问题的出现，单存依靠对管理员的信任不足以保障数据安全，必须通过规章、制度与规 范的约束才能够规避安全风险；
■树立安全意识：安全问题最大的敌人是侥幸，很多企业因为侥幸造成了数据的损失。一点一滴加强安全意识，逐步完善安全措施；
■开始安全审计：以Oracle数据库为例，数据库已经提供了很多安全防范的手段和方法，我们建议用户适当展开安全防范措施，开启部分任务审计，定期分析数据库风险，由此逐步完善数据库安全。
