讲师介绍  

代海鹏

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

 

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

 

分享大纲：

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默认组件会使用到的。

  

  （点击文末链接下载查看）                           

 

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。

 

 

 

上面有很多数据都可以通过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、应对误操作

 

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

 

经验分享：

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

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

• 执行危险命令时，一定要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