DBA在传统企业数据库安全建设上能做些什么？
|
上面有很多数据都可以通过MOS文章一把拉出来.讲这个的主要原因是强调我们要紧跟着自身版本的PSU,这个不代表说本月发布的PSU,我们必须本月升级,而是应该有计划进行升级.比如以延迟半年为计划,或者延迟一个季度为计划.除了这方面,还有业内会经常爆出一些严重BUG,如像DBAplus这样的社群是会第一时间发出声明及处理方案,我们一定要时刻关注,不能等问题真的到我们头上了才知道,那样公司请你就没有价值了. 以上所述都是应对数据泄密的措施.简单来说,我认为数据泄密方面DBA和运维人员只是做了辅助作用,因为很多公司会有自己的安全团队,会从外面请一些公司去做整体的扫描,会给出一系列建议、配置性的更改,我们只需要针对数据库这方面调整,就够了. 前面说那么多东西是为什么呢?大家都知道了,去年下半年有比特币勒索,大家在网上了下载了一些破解工具,如PLSQL DEV、SCRT等,有一部分工具被放置恶意的脚本,然后当你通过很大的权限(如SYSDBA)连接到数据库,这些工具会自己创建一个存储过程,存过名字起跟真的一样,里面还给你加密.一定时期以后(如三年)这个函数会自己执行,把你的数据全部搞乱搞废掉,然后会在报错信息里面提供包含比特币链接的勒索信息,大致意思是你给我钱,我就给你把数据库恢复. 那么我们前面做的,收用户、收权限,就是保证,当我们DBA自身使用的工具是安全的情况下就能保证数据库不受勒索.如果你大的权限在下面飘着,就不能保证研发、应用的哥们究竟安全意识如何,到时候连防都不好防. 如果面对数据泄密是DBA是辅助类工作的话,面对数据丢失,DBA有无法推卸的责任,这个“锅”你是甩不出去的. 二、面对数据丢失,DBA能做什么?在平时运行维护时,总会有种种情况导致业务数据丢失或者损坏,无论丢失是多是少,我们DBA都应该尽量避免发生. 下列是我们平时遇到的4种可能会造成数据丢失的类型：
就Oracle本身来讲,它有自己的高可用体系产品及功能. 1、应对主机层面的故障这种故障正常来说是丢失未提交的数据,大部分情况我们是无需在意这些丢失数据的.这时候主要以恢复业务为目的来设计数据.我们通过使用主机层面高可用技术RAC,来解决这个问题,主机层面高可用指,两套内存、CPU等运算资源,但是使用同一套数据文件.当RAC中某主机损坏时,业务可以在下次连接的时候连入另外的节点. 在Oracle 9i之前,RAC的名称叫做OPS,而9i之前每次传输块的时候,需要先将数据刷入硬盘,然后另外的节点从硬盘上读取. RAC进化的最重要的一点,就是有了CACHE-FUSION的特性,最新的当前块数据可以通过私网进行传输了. 使用RAC的注意点：
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、应对误操作说实话靠个人是很难避免的,谁都有个精神不好的时候,犯迷糊的时候.这时候就需要通过规范和制度来保证这种事情不发生. （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |