热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

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

讲师介绍代海鹏新炬网络资深数据库工程师擅长数据库性能优化、故障诊断,曾为中国人寿、中国移动、国家电网、太平洋保险等大型企业提供数据库技术支持服务。分享大纲࿱
讲师介绍  20170425103222298.jpg

代海鹏

新炬网络资深数据库工程师

 

  • 擅长数据库性能优化、故障诊断,曾为中国人寿、中国移动、国家电网、太平洋保险等大型企业提供数据库技术支持服务。

 

分享大纲:

  1. 面对数据泄密,DBA能做什么?

  2. 面对数据丢失,DBA能做什么?

  3. 数据库备份及演练

 

我把数据的安全事件简单分为两类,第一类是泄密事件,第二类是数据丢失事件。

 

先说说近年来影响比较大的数据泄密事件:

 

  1. 洲际酒店在内的10大酒店泄密大量客人开房的信息包括姓名、身份证被泄密,直接导致客人量下降;

  2. 下一个是韩国2000万信用卡信息泄露,引发“销户潮”;

  3. 某网数据泄漏,全国各地有39名用户被骗,诈骗金额高达140多万。像这类数据泄露,如果你的亲属朋友是被骗人之一,我相信感受一定与光看数字的感触不同;

  4. 某贷宝被脱裤,导致10G裸条泄露。

再说说近期影响较大的数据丢失事件:

 

  1. Gitlab99%数据丢失:1月份时,某外国工程师对自认为是空文件夹的文件夹做了一个删除,过了两秒他反应过来了,我是不是搞错服务器了,后果是几百G的数据文件被删得就剩下3个G;

  2. 炉石传说30%数据丢失:有4人在1月份提议把1月份作为数据安全月,也不至于。这是怎么回事呢?炉石传说的数据库哥们带病运行了两天以后又回滚到故障以前,导致几天的数据全部丢失。这里我们不去深究到底什么技术原因导致竟然无法修复。

 

对此,我想说的是:我们的运维团队并没有我们想象中那么牛逼,所以我们要对生产抱有敬畏之心。

 

一、面对数据泄密,DBA能做什么?

 

1、用户管理

 

清理和锁定无用的数据库帐号。进了一个新环境,核心库账户是必查项。

 

  • 将未被锁定的帐号列出来和开发进行确认,每个用户都找到具体作用和应用。

  • 如账户无人认领,则通过DBA_HIST_ACTIVE_SESS_HISTORY 配合dba_users 把这个用户的语句抓出来,继续确认,语句如下:

select  b.username,a.sql_id ,count(*)from

DBA_HIST_ACTIVE_SESS_HISTORY a,dba_users b where a.user_id=b.user_id

group by b.username,a.sql_id

order by count(*);

  • 如果无法抓出相关信息,这时候就进行汇报,然后申请锁定用户。

  • 11G有非常多的用户,附件word 有其中最常见的31个用户的详细信息,包括用户名字以及这个用户是哪个Oracle默认组件会使用到的。

    20170425103304610.jpg

    (点击文末链接下载查看)                           

 

2、用户Profile

 

除了用户本身以外,还有用户的profile要进行检查,首先就是密码的验证算法,11G默认是没有算法的,我们要用脚本@?/rdbms/admin/utlpwdmg.sql创建名叫VERIFY_FUNCTION_11G的验证函数。

 

VERIFY_FUNCTION_11G函数验证项如下:

 

  • 密码不能小于8位

  • 密码和用户名不能一样

  • 也不能是反过来的用户名

  • 不能和数据库的服务名一样

  • 检查是不是简单的字典用于,比如password之类的

  • 不能是Oracle

  • 必须包含1个数字,一个字母,在检查的时候顺便检查与之前的密码最少有3个字母不同

 

profile中有两类属性:

 

  1. 第一类是资源控制,控制逻辑读、SGA、空闲会话存活时长等等。这一类需要将参数resource_limit设置为TRUE才能生效;

  2. 第二类是密码策略,包括 错误几次、密码失效、密码可重用周期、最多可重用次数、验证函数、密码锁定时间、到期后缓期执行等,该类型无需resource_limit参数配置。

 

3、权限管理

 

权限管理很简单,就是最小化原则。

 

最小化应用账户,在工作中我个人经验为默认给开发及应用账户的权限,就connect、resource、创建视图的权限即可。

 

reousrce的权限是有很多,可以创建视图,我只给这么多,如果你还想要别的,可以向DBA团队申请,DBA团队来给你审批。然后是数据库字典,普通用户禁止访问。为了禁止普通用户的访问可以用下面的07-DICTIONARY-ACCESSIBILTY进行限制。安全和便利总是相对的,越安全,那么操作起来就越复杂,所以说这里是否进行限制就见仁见智。我们可以把权限汇集成Role,一类应用所需的权限可以归类为一个单独的role,以后只要是类似应用上线不要再管理。而应用下线也可以通过Role快速回收对应权限。通过Role赋权是我的建议之一。

 

最小化DBA权限用户,一种是操作系统上面DBA组,其中操纵系统帐号最好就Oracle一个,因为DBA组所属用户可以通过操作系统验证直接以sysdba的权限登录到库里。另外一种,数据库里面有DBA角色,或者有大权限的帐号也一定要审查一下,如果有可疑的账户虽然没有DBA角色,但相关的权限却全部拥有的,更是一定要进行检查核对。

 

4、日志管理

 

日志管理主要是说审计,在后面发现问题时可以快速知道是之前谁做的操作。我们可以把审计配置好以后关闭审计,如果某天系统已经上生产后老板说你给我把这个库审计一下,我们只需一条命令就可以审计了,不需要再做一系列配置及资源申请。

 

审计涉及的参数:

 

  • AUDIT_TRAIL,有几种配置选项,将审计数据放在数据库中 或者放在文件系统中,是普通模式 还是 extend模式。详细的进reference一看便知,这个可自己调配

  • AUDIT_SYS_OPERATIONS参数建议打开,毕竟sysdba的威力其实是最大的

 

有几点注意事项:

 

  • 将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。

 

20170425103430760.jpg

 

20170425103438409.jpg

 

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

 

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

 

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

 

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

 

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

 

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

 

20170425103447671.jpg

 

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

 

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

 

  • 系统故障: CPU、内存、主板、等主机层面的故障

  • 存储故障:UPS掉电、控制器损坏、物理硬盘损坏等

  • 数据库BUG:因触发数据库BUG导致刷入存储的数据块逻辑损坏

  • 人为操作故障,错误执行删除数据命令

 

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

 

1、应对主机层面的故障

 

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

 

20170425103456858.jpg

 

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

 

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

 

使用RAC的注意点:

 

  • 尽量减少cache-fusion,通过应用切割的模式;

  • 第二个注意点,CPU、内存这些计算资源,最好不要上60,相对内存来说,CPU更是。如果平时跑每个节点的CPU就飙上60%,那么当发生故障的时候,存活节点是不是能抗住是要打问号的;

  • 如果资源吃紧,提前对业务进行提前梳理这套库上面哪些业务是重要的,哪些业务是较为不重要的,哪些最不重要。便于紧急时刻可停止非关键业务释放资源供给核心业务。

 

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

 

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

20170425103504582.jpg

当存储出现故障的时候,丢失多少数据都是有可能的,这时候如果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、应对误操作

 

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

 

经验分享:

  • 一定要有变更方案,详细列出每条要执行的命令,并且多人评审;

  • 具体实施过程中,除非排障,否则命令一律不得手敲;

  • 执行危险命令时,一定要ifconfig 查看一下IP,以防万一;

  • 生产和测试环境的窗口不要同时打开,如果非要打开,命名对应窗口,并使用不同的文字背景;

  • 变更方案要有对应的回退方案,如果执行变更的时候出现了问题,当时如状态并不好,建议直接回退,不要勉强自己排错。

 

三、数据库备份及演练

 

作为一个DBA,如果想要睡得踏实,那么备份一定要有。

 

当前数据库中数据越来越大,几十T的库屡见不鲜,有时候可能真的没那么大空间做演练 。经验小分享:调整备份手段,将业务表空间分散开,每份单独与system sysaux等组成一个备份集。分批采用进行全备。

 

最后验证时可以只验证一份,这样数据量就小很多了。不过很多地方为了保证安全,两地三中心都搞出来了,几十T空间并没有想象中贵,这点投入是完全值得的。

 

今天分享就到这儿了,希望大家的系统平安,做好防范。谢谢!

 

Q&A  

 

Q1:有一次客户那边的账户突然锁了,我查了其它的信息表空间,发现并没有因为多次密码登陆错,排除这个情况外还有什么原因?

A1:你说的是资源,profile分口令规则和资源限制,资源限制是需要和resource_limit参数进行配合的。有两种情况,第一种情况是有人直接进行手工锁定,第二种情况是密码试错过多导致被锁定的。

(接上问)

Q2:我的意思是排除密码输错,也不是人为锁的。

A2:到期了。

Q3:到期的时间不是没有限制吗?

A3:资源是没有限制的。

Q4:资源参数没打。

A4:资源参数部分是不生效,跟口令参数是无关的。

Q5:可以告诉我多长时间吗?

A5:默认180天。

 

Q6:PPT一开始rf删掉以后,我去年做过暴力测试,是可以恢复备份的。国外的那个没有吗?

A6:国外哥们的库是不一样的。他那边有三到四重的备份方案,各种各样的容灾,全部都没有用。最后恢复不是采用正常手段恢复的,是用其它系统的数据传回来的,非常佩服他们把恢复进度在推特上面进行公布,以每小时5%的进度慢慢恢复。当时这篇文章也炒得很火了。

原文发布时间为:2017-04-25

本文来自云栖社区合作伙伴DBAplus



推荐阅读
author-avatar
955单车小宏
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有