DBA在传统企业数据库安全建设上能做些什么？(2)

有几点注意事项：

• 将aud$表挪出SYSTEM表空间
• AUDIT_FILE_DEST审计文件存放位置设置一个单独的lv,严禁与根目录,ORACLE_HOME目录放在一起
• 默认使用命令noaudit create session 先停止审计,在需要的时候再开启

11G新参数ENABLE_DDL_LOGGING,开这个参数可以在alert日志中记录所有的DDL语句,不过记录的内容相对简单,只有时间和语句.

在11.2.0.4之前,这个功能是有bug的,rename操作是不做记录的.

到12C 这个参数更加完善了,如图右,除了语句以外 还有IP 、机器名等信息,在我们不开审计的情况下,也能获取DDL执行信息.

5、漏洞管理

及时的升级对应的PSU,尤其是修复的重要安全bug的PSU.

关于漏洞,我简单地贴了一个文章,1454618.1.

上面有很多数据都可以通过MOS文章一把拉出来.讲这个的主要原因是强调我们要紧跟着自身版本的PSU,这个不代表说本月发布的PSU,我们必须本月升级,而是应该有计划进行升级.比如以延迟半年为计划,或者延迟一个季度为计划.除了这方面,还有业内会经常爆出一些严重BUG,如像DBAplus这样的社群是会第一时间发出声明及处理方案,我们一定要时刻关注,不能等问题真的到我们头上了才知道,那样公司请你就没有价值了.

以上所述都是应对数据泄密的措施.简单来说,我认为数据泄密方面DBA和运维人员只是做了辅助作用,因为很多公司会有自己的安全团队,会从外面请一些公司去做整体的扫描,会给出一系列建议、配置性的更改,我们只需要针对数据库这方面调整,就够了.

前面说那么多东西是为什么呢?大家都知道了,去年下半年有比特币勒索,大家在网上了下载了一些破解工具,如PLSQL DEV、SCRT等,有一部分工具被放置恶意的脚本,然后当你通过很大的权限(如SYSDBA)连接到数据库,这些工具会自己创建一个存储过程,存过名字起跟真的一样,里面还给你加密.一定时期以后(如三年)这个函数会自己执行,把你的数据全部搞乱搞废掉,然后会在报错信息里面提供包含比特币链接的勒索信息,大致意思是你给我钱,我就给你把数据库恢复.

那么我们前面做的,收用户、收权限,就是保证,当我们DBA自身使用的工具是安全的情况下就能保证数据库不受勒索.如果你大的权限在下面飘着,就不能保证研发、应用的哥们究竟安全意识如何,到时候连防都不好防.

如果面对数据泄密是DBA是辅助类工作的话,面对数据丢失,DBA有无法推卸的责任,这个“锅”你是甩不出去的.

二、面对数据丢失,DBA能做什么?

在平时运行维护时,总会有种种情况导致业务数据丢失或者损坏,无论丢失是多是少,我们DBA都应该尽量避免发生.

下列是我们平时遇到的4种可能会造成数据丢失的类型：

• 系统故障： CPU、内存、主板、等主机层面的故障
• 存储故障：UPS掉电、控制器损坏、物理硬盘损坏等
• 数据库BUG：因触发数据库BUG导致刷入存储的数据块逻辑损坏
• 人为操作故障,错误执行删除数据命令

就Oracle本身来讲,它有自己的高可用体系产品及功能.

1、应对主机层面的故障

这种故障正常来说是丢失未提交的数据,大部分情况我们是无需在意这些丢失数据的.这时候主要以恢复业务为目的来设计数据.我们通过使用主机层面高可用技术RAC,来解决这个问题,主机层面高可用指,两套内存、CPU等运算资源,但是使用同一套数据文件.当RAC中某主机损坏时,业务可以在下次连接的时候连入另外的节点.

在Oracle 9i之前,RAC的名称叫做OPS,而9i之前每次传输块的时候,需要先将数据刷入硬盘,然后另外的节点从硬盘上读取.

RAC进化的最重要的一点,就是有了CACHE-FUSION的特性,最新的当前块数据可以通过私网进行传输了.

使用RAC的注意点：

• 尽量减少cache-fusion,通过应用切割的模式；
• 第二个注意点,CPU、内存这些计算资源,最好不要上60,相对内存来说,CPU更是.如果平时跑每个节点的CPU就飙上60%,那么当发生故障的时候,存活节点是不是能抗住是要打问号的；
• 如果资源吃紧,提前对业务进行提前梳理这套库上面哪些业务是重要的,哪些业务是较为不重要的,哪些最不重要.便于紧急时刻可停止非关键业务释放资源供给核心业务.

2、应对存储层面发生故障或损坏

这个层面的故障和损坏RAC是无法保护的,因此Oracle提供了DG进行存储保护.

当存储出现故障的时候,丢失多少数据都是有可能的,这时候如果DG存在,我们可以激活备库,将应用的IP调整为备库及时的恢复应用,并且可以做到尽量不丢失数据,这里可以给大家分享的经验是,建立内网域名服务器,将IP都设置为对应的域名,以后发生容灾切换的时候 只需要调整域名服务器的映射即可,无需每个应用单独调整.

在11G以后DG的standby端可以以readonly的模式进行打开,并对外提供只读服务.这也是尽量将物理资源利用起来.

3、应对BUG导致的数据丢失

两种情况,一种是归档好着,只是刷块的时候有问题,导致刷坏了.这种普通DG就可以搞定,另外一种归档被写坏,而传到standby 应用也会导致备库数据块坏掉.

这时候我们就需要讲DG进行延时应用,注意这里只是延时应用,日志还是会自动传输的.哪怕生产坏掉了,除了需要追一定时间的归档外,不会有数据丢失,延时语句如下：

alter database recover managed standby database delay 120 disconnect from session;

120的单位是分.

这里2小时只是代表standby 和生产端真实时间差距,并不代表生产发生down机,standby 必须两个小时才能追平归档.

4、应对误操作

说实话靠个人是很难避免的,谁都有个精神不好的时候,犯迷糊的时候.这时候就需要通过规范和制度来保证这种事情不发生.

（编辑：ASP站长网）