半年前在对某单位的生产系统实施风险评估与安全加固项目中，在对oracle安全加固时发生一次严重的事故，致使全省的打表业务全部瘫痪，现记录下来，希望对做信息安全的同仁敲醒警钟。
在完成对被测系统的物理环境、网络安全架构、网络安全设备、安全系统、操作系统、数据库、中间件、网络-主机-数据库日志分析、应用系统后台、数据备份与恢复、桌面终端、渗透测试、管理制度的安全评估检查之后，当然我这里就不说资产、威胁、脆弱性这评估三要素的问题了，直奔主题。接下来我们就开始针对系统存在的安全风险准备安全加固方案。并召开风险评估小结会和安全加固会，会上对存在的安全风险进行了分析，并讲解了安全加固的策略细节以及注意事项。其中讲到了oracle存在一个安全风险是未撤销PUBLIC角色对UTL_FILE、utl_http、UTL_TCP、utl_smtp的执行权限。判定的理由是如果控制数据库包UTL_FILE读写目录的参数被设为“*”（不包括引号），UTL_FILE包就可以被读写到机器上Oracle安装用户（通常是用户（ORACLE）访问的任何目录。一个有“ALTERSESSION”权限的用户就可能会复制库缓存（librarycathe）到一个跟踪文件，然后通过UTL_FILE读取文件的任何内容。如果添加任何用户或修改密码，那么清晰的文本密码都仍然会被看到（只要它不被从缓存中清除）。而且Oracle默认授权public角色能对这些包有执行权限，但是应用开发人员很少使用UTL_FILE来进行导入导出数据。当时会上开发厂商提出应用系统可能在用UTL_FILE，但是不确定。所以我们在会上就把暂停对撤销权限的这部分的加固。这里我们也犯了一个错误，我们以为他们内部会沟通这个问题，而且对方oracle运维人员是个OCM，应该了解应用，就没给在外地的数据库管理员说明会中具体细节。又因为他们数据库管理员在外面培训，没法配合我们现场加固，领导决定就让运维人员远程加固。第二天运维人员自己直接加固了，我们没参与数据库加固的工作。然后就是全省的该应用系统的打表业务全部瘫痪，营业厅打到业务部门咨询情况的电话快打爆了，速度把撤销权限的操作重新赋权限，数据库恢复正常。故障原因就是当初程序开发时使用了这个还不常用的UTL_FILE包来进行导入导出数据，public角色的权限回收后，相应的应用用户丧失了导出数据的权限，最终导致打表业务瘫痪，问题就是这样。
在这个事件中我们实施方的责任是没把会议结果和数据库管理员做好沟通，评估方的责任就是数据库管理员加固会议不在现场，开完会议内部不沟通，数据库管理员审核我们的脚本没发现问题，数据库管理员远程加固没和我们沟通。
透过这个事件我们吸取到的教训是：
第一：评估的启动会、小结会这种带有重要意义的会议最好全员参加，尤其是开发应用人员和数据库运维人员。
第二：做安全加固的配置一定要经过开发人员、运维人员、评估人员多方面组成的评审小组的评审，不确定的一概待定，并且保持消息共享，做好沟通工作。
第三：做信息安全一定要深入了解业务应用，通性配置加固可以减少顾虑，但是一旦贴近应用，譬如说部署了RAC的AIX小机的exec、login、shell等服务是否要禁用的问题，一定要谨慎小心。
第四:做信息安全一定要有业务至上的心，可以深度检查，但是加固一定要求稳。做加固工作一定要克制技术人追求极限的心，并非加固的项数越多越好。
