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

有几点注意事项：

• 将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进行存储保护.

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!