前段接收到一则数据库被攻击的案例,客户的数据库开放在公网上,结果遭遇到黑客的攻击,导致数据库损毁无法访问。客户的描述是:无论如何,没法登陆到数据库中。请求我们的紧急援助。
工程师赶到现场,发现数据库文件已经被删除,好在找到一个逻辑备份,通过重建数据库帮助用户恢复了数据,Oracle数据库环境为Redhat linux上的10.2.0.1版本。
上面的案例告诉我们,将Oracle数据库直接开放在公网上是极其危险的,特别是陈旧的数据库版本中可能存在很多已知的安全漏洞,可能被轻易的攻击渗透。常规的做法是将数据库隐藏在应用服务器的后端,同时要确保及时修正Oracle数据库严重警告的安全漏洞,还有及时的备份是确保数据留存的最后手段。
如果不可避免的将Oracle数据库置于公网,那么以下几点需要谨记:
1.更改缺省端口,限制访问来源和访问工具;
2.及时应用安全补丁更新;
3.锁定不必要的用户并更改所有缺省口令;
4.做好备份;
在网络的世界里,绝对不要对安全掉以轻心!
【数据库的风险逐渐升级】
最近有客户遇到了一则数据库故障,起因是当进行一个数据表创建时遭遇到限制约束。
该数据表来自Oracle数据库,在Oracle中,表名的长度限制是64个字符,但是Oracle的表名( table_name )无法超过30个字符,这是数据库的内在限制。
然后如何解决呢?应该说是数据库知识已经足够普及了,程序员们找到了数据字典表,将限制字段的长度 改掉了。大家能够评估后果么?数据字典被修改,整个数据库开始出现ORA-600错误,就此触发一次故障。
很多时候我们说,无知者无畏,当动手能力太过于强大时,也会使数据库遭遇不测。而对于企业数据库环境来说,内部的风险往往大于外部。
不以规矩,不成方圆。做任何事都要遵循一定的守则和规范。
【OracleRaid 并非安全无忧】
最近两周,收到了两则关于OracleRaid损坏的数据恢复请求。都是来自较为偏远的地区,客户使用OracleRAID5磁盘冗余,但是没有数据备份。时至今日,仍然有很多客户相信仅仅凭借磁盘级别的OracleRaid保护就已经足够保障数据安全了。而现实是残酷的。
在技术快速发展的今天,一方面是大城市、中心地区的IT技术更新及时,另一方面则是很多二三线城市的信息和技术传播严重滞后。
这两个案例,一个是OracleRaid5中损坏了2块硬盘,只能从残存的盘片上恢复局部的数据;另一则是Raid 5中损坏了1块硬盘,但是恢复后发现Windows上的文件部分变为0字节,无法打开,这种情况可以通过底层扫描恢复文件,再校验完好性进行数据级别的恢复。
但是无论如何,在Raid的保护之外,有效的备份和容灾机制是必不可少的,无论我们技术人身在何处,不要忘了及时更新自己的技术知识。