【云和恩墨】一次 truncate 核心表衍生的安全管理思考

第一章 一次 truncate 核心表衍生的安全管理思考

云和恩墨 | 2016-05-06 17:56

本文编辑整理来自上周四晚云和恩墨大讲堂 黄嵩 关于数据安全问题的分享。安全问题涉及到信息系统的方方面面，尤其是其核心资产——数据的安全。无论是数据访问控制的裸露，数据操作权限的无序或者是人为的粗心大意，都将导致核心数据遭受破坏。本次分享的内容就是一起因编码不规范，直接在生产环境调试代码，导致新业务程序 truncate核心业务表，引起的数据丢失严重故障的案例。

前言

信息系统属于企业重要的信息基础设施，其安全问题涉及到核心数据资产，关乎企业生存与发展，涉及个人生存与生活，甚至触及国家和社会的稳定。因此，提升信息系统的安全、制定和实施企业信息系统安全战略，建立全方位动态、纵深防御的系统安全保障体系，成为系统信息化工作的一项重要内容。信息系统环境中的风险点和威胁点往往不是单一的，也不是静态的，简单的安全产品堆砌已被证明不是有效的解决途径。信息系统安全是涉及到技术、人员、组织、环境、法律及管理等多方面因素的系统性问题，应该采用信息保障的原理、技术和方法，以全局的、动态的眼光来研究、设计、实施与维护信息系统安全工作。

安全问题涉及到信息系统的方方面面，尤其是其核心资产——数据的安全，无论是数据访问控制的裸露，数据操作权限的无序或者是人为的粗心大意，都将导致核心数据遭受破坏，下面就是一起因编码不规范，直接在生产环境调试代码，加上数据库帐号混用导致新业务程序 truncate 核心业务表，引起的数据丢失严重故障的案例。

第一章 概述

xxx医院在2014年12月5日发现财务系统部分退费业务无法办理，进一步分析发现财务系统门诊收费汇总表MZ****自2014年12月5日7:10以前的数据全部丢失，导致与该表相关的业务办理异常。为进一步确定数据丢失原因，恢复丢失的数据，xxx医院医学情报研究所将故障反馈到我方技术服务团队，我方在接到服务请求以后，第一时间安排高级技术顾问到现场，恢复丢失数据，并分析数据丢失原因。

在xxx医院医学情报研究所的大力配合下，在财务系统开发商的协助下，经过我方技术顾问的不懈努力，丢失数据已全部找回，数据丢失原因已找到。以下操作记录对MZ****表进行了截断（truncate）操作，导致数据丢失。

根据 logmnr 挖掘的信息，对该核心业务表执行 truncate 的会话信息如下，从中我们可以发现一个新"程序" dtexec.exe（经确认这是一个新开发的接口程序）执行了该操作，而且多次重复执行：

login_username=PB_USERclient_info= OS_username=Administrator Machine_name=WORKGROUP\YUANZHANGCHAXUNOS_terminal=YUANZHANGCHAXUN OS_process_id=13136:12860OS_program_name=DtsDebugHost.exe（?--这个终端的程序执行）

login_username=PB_USERclient_info= OS_username=Administrator Machine_name=WORKGROUP\YUANZHANGCHAXUNOS_terminal=YUANZHANGCHAXUN OS_process_id=6260:1944OS_program_name=dtexec.exe

看到这些信息，我们不得不皱起眉头，在这个客户的信息化管理过程中，存在着不少的安全漏洞：

1） 这并不是原有的业务程序，这是什么程序？经过测试了吗？

2） 新程序直接在生产环境测试？难道没有程序发布管理规范呢？

3） 接口程序直接使用业务帐号，安全管理有规范吗？

……

问题很多，当然当前的首要问题是尽最大可能恢复业务数据，恢复业务的正常运行；

请注意，这是财务数据库，必须尽最大可能接近100%的找回数据，哪怕是一笔数字差异，对于财务核算也是不可接受的。

从前面的数据可以看出这例故障情况变得复杂：

1） 该核心业务表被多次 truncate；

2） 每次 truncate 的间歇还有业务数据写入；

3） 最后一次 truncate 以后，进入业务高峰期，有大量业务数据写入；

4） 没有可用的恢复环境，时间变得不可预期；

值得庆幸的是，该数据库至少还有全库备份和备份后的所有归档，这至少给了我们恢复数据的希望。经过仔细分析，最终我们决定采用在测试环境中通过基于时间的不完全恢复将该表数据还原到第一次 truncate 之前，然后再将每两次 truncate 之间该表的数据变化，通过 logminer 日志挖掘的方式获取，将这些挖掘出的 SQL 操作在不完全恢复的表上插入，最终将测试环境中完全恢复的数据导回生产库的方案。以下是恢复的过程。

第二章 故障处理经过

以下图示我方对本次服务的处理经过：

2014年12月5日，8:30 接到服务请求电话；

2014年12月5日，9:30 到达现场，经过简短交流，了解事件经过后着手搭建测试环境（无可用的测试环境）

2014年12月5日，18:30 搭建完成测试环境

2014年12月5日，22:30 通过备份数据，完成数据恢复（restore）

2014年12月6日，01:00 通过归档日志，恢复备份以后的数据至2014年12月4日12:00（通过 logmnr 对在线日志的分析，确认的第一次 truncate 的时间点）

2014年12月6日，01:30 通过 logmnr，分析2014年12月4日12:00至2014年12月5日07:10 产生的业务数据，并确定数据丢失的原因，DtsDebugHost.exe 程序在2014年12月4日17:37 和17:39执行了截断表（truncate table）操作，清空了该表数据；后续 dtexec 程序反复多次执行同样的操作；

2014年12月6日，9:30 通过 logmnr 完成数据追加并验证；

2014年12月6日，13:00 开发商组织再次确认数据准确性以后，将测试环境的业务数据导入生产环境

第三章 恢复过程

1恢复控制文件

Rman target /

RMAN>restore controlfile from'/bakdata/backup/mzser/20141130/mzserscf_c-3701314014-20141130-00';

2恢复数据库

RUN

{

allocate channel d1 type disk;

allocate channel d2 type disk;

allocate channel d3 type disk;

allocate channel d4 type disk;

alter database mount;

set newname for datafile 3 to'/bakdata/yyser/datafile/sysaux.323.732371115';

set newname for datafile 2 to'/bakdata/yyser/datafile/undotbs1.262.732371115';

set newname for datafile 1 to'/bakdata/yyser/datafile/system.324.732371115';

set newname for datafile 5 to'/bakdata/yyser/datafile/undotbs2.256.732371199';

……;

set newname for datafile 8 to'/bakdata/yyser/dcwbarcodes2';

……;

restore datafile x;

restore datafile x1;

……

switch datafile all;

}

3备份生产系统归档日志

将生产系统归档日志备份拷贝到测试环境；

4在测试环境恢复归档日志

catalog start with '/bakdata/archbak';

run

{

SETARCHIVELOG DESTINATION TO '/bakdata/archlog';

sql 'altersession set nls_date_format="yyyy-mm-dd hh24:mi:ss"';

restorearchivelog from time '2014-11-30 00:00:00';

}

5应用归档日志

run

{

sql 'alter session setnls_date_format="yyyy-mm-dd hh24:mi:ss"';

SET UNTIL TIME '2014-12-04 14:00:00';

recover database ;

}

6确定需要分析的归档日志

在生产库上查询

SQL> select thread#,

sequence#,

to_char(first_time, 'yyyy-mm-dd hh24:mi:ss'),

to_char(next_time, 'yyyy-mm-dd hh24:mi:ss')

fromv$archived_log

wherenext_time > to_date('2014-12-04 13:50:00', 'yyyy-mm-dd hh24:mi:ss')

andfirst_time < to_date('2014-12-05 07:30:00', 'yyyy-mm-dd hh24:mi:ss')

order byfirst_time

7logmnr 解析归档日志

在备份库执行解析

execsys.dbms_logmnr.add_logfile(logfilename=>'/bakdata/archlog/4_11503_732371168.dbf');

execsys.dbms_logmnr.add_logfile(logfilename=>'/bakdata/archlog/2_23184_732371168.dbf');

……

execsys.dbms_logmnr.start_logmnr(options=>sys.dbms_logmnr.dict_from_online_catalog);

create table logoper tablespace users as select *from v$logmnr_contents;

exec sys.dbms_logmnr.end_logmnr;

8后续处理

经过以上处理，2014年12月4日 13:50到2014年12月5日7:30，在数据库内所有执行的 SQL 均记录在 logoper 表中，后续我们对其中记录中涉及到对 MZ****的表的所有操作 SQL 根据业务规则进行筛选，去除错误操作（truncate），然后将这些需要的 SQL 操作在测试库重新执行，最终恢复业务数据。

第四章 问题思考

讲到这里其实技术部分也就说完了，很简单不是么。呵呵，当然很简单，基于时间点的恢复加 logmnr 是 DBA 的基本功，前面讲的根本不是重点，更不是今天话题的终点，这仅仅是我们今天要讲的内容的引子而已。

在我们看到这起事故解决思路的同时，更应该对这起事故的背后多一些思考，这实际上是一起典型的信息化安全事件，这也是我们众多客户或者 DBA 日常随时可能发生的事件。那么，让我们来看看，这里存在着哪些安全隐患：

1、 系统应急预案缺失，甚至不具备在紧急情况下用于数据恢复的测试环境；

2、开发人员可以直接连接生产系统，甚至用于调试环境。这在很多企业内部是常态，多见于系统功能不足够完善，企业领导临时需查阅需要的报表数据，但系统功能又不提供，开发人员"不得不"连接生产系统直接"操作"；这风险有多大，小则导致性能隐患，重则丢失数据，甚至是不可逆的损失；

3、权限规划混乱，这是一起典型的"共用帐号"引起的事故，如果为接口程序分配独立帐号，根据需要设定最小权限，这起事故完全可以避免。

那么如何来构建信息系统的安全管理体系呢？接下来是我们的设想。

第五章 信息系统安全的整体要求

1不同等级系统的安全要求

下面这部分参照了国家信息系统安全等级保护系列标准作的整理，大家可以参考，不必详究。

不同等级的信息系统应具备的基本安全保护能力如下：

安全级别

安全保护能力要求

第一级

能够防护系统免受来自个人的、拥有很少资源的威胁源发起的恶意攻击、一般的自然灾难、以及其他相当危害程度的威胁所造成的关键资源损害，在系统遭到损害后，能够恢复部分功能。

第二级

能够防护系统免受来自外部小型组织的、拥有少量资源的威胁源发起的恶意攻击、一般的自然灾难、以及其他相当危害程度的威胁所造成的重要资源损害，能够发现重要的安全漏洞和安全事件，在系统遭到损害后，能够在一段时间内恢复部分功能。

第三级

能够在统一安全策略下防护系统免受来自外部有组织的团体、拥有较为丰富资源的威胁源发起的恶意攻击、较为严重的自然灾难、以及其他相当危害程度的威胁所造成的主要资源损害，能够发现安全漏洞和安全事件，在系统遭到损害后，能够较快恢复绝大部分功能。

第四级

能够在统一安全策略下防护系统免受来自国家级别的、敌对组织的、拥有丰富资源的威胁源发起的恶意攻击、严重的自然灾难、以及其他相当危害程度的威胁所造成的资源损害，能够发现安全漏洞和安全事件，在系统遭到损害后，能够迅速恢复所有功能。

2基本技巧要求和基本管理要求

信息系统安全等级保护应依据信息系统的安全保护等级情况保证它们具有相应等级的基本安全保护能力，不同安全保护等级的信息系统要求具有不同的安全保护能力。

基本安全要求是针对不同安全保护等级信息系统应该具有的基本安全保护能力提出的安全要求，根据实现方式的不同，基本安全要求分为基本技术要求和基本管理要求两大类。技术类安全要求与信息系统提供的技术安全机制有关，主要通过在信息系统中部署软硬件并正确的配置其安全功能来实现；管理类安全要求与信息系统中各种角色参与的活动有关，主要通过控制各种角色的活动，从政策、制度、规范、流程以及记录等方面做出规定来实现。

基本技术要求从物理安全、网络安全、主机安全、应用安全和数据安全几个层面提出；基本管理要求从安全管理制度、安全管理机构、人员安全管理、系统建设管理和系统运维管理几个方面提出，基本技术要求和基本管理要求是确保信息系统安全不可分割的两个部分。

基本安全要求从各个层面或方面提出了系统的每个组件应该满足的安全要求，信息系统具有的整体安全保护能力通过不同组件实现基本安全要求来保证。除了保证系统的每个组件满足基本安全要求外，还要考虑组件之间的相互关系，来保证信息系统的整体安全保护能力

根据以上的要求，我们需要为信息系统设计安全模型。

对了，上述内容比较官方，仅供大家参考，如对上述无兴趣，可跳过，我们来看下面与我们数据库安全关系更为密切的部分。

第六章 信息系统安全模型

1信息系统安全目标

信息系统的最终安全目标就是保证信息的机密性、完整性、可用性、可控性、可确认性和可审性。通过保护系统的实体安全、实施各种安全保障措施和执行系统安全工程过程，来保护信息在其生命周期内的产生、传输、处理和存储的各个环节中不被破坏，从而保障企业的效率和效益，促进企业信息化的可持续发展。

2信息系统安全模型描述

根据上述安全目标和综合已有的信息安全经典模型和信息系统等级保护技术要求，同时强调信息安全防护的周期性特点，提出以下安全模型用于指导信息系统安全体系建设，如下图所示：

整个安全的架构体系非常庞大，咱们分享的时间有限，一一论述三天三夜也说不完；各位都从事数据相关的工作，最关心的莫过于与数据相关的安全，我们选择数据全作为今天讨论的重点；在数据安全的范畴内，包含诸多方面，大体可划分为五大方面，分别是：软件安全、备份安全、访问安全、防护安全、管理安全。

这些隐患，你是否也面临？不止是生产数据库，还有非生产环境（比如仿真测试环境），备份数据，数据安全面临诸多风险。

针对数据安全这五个方面，我们建议建立端到端的数据安全防护体系：

A）通过物理隔离，只允许合法请求登录；

B）通过职权角色、权限管理，来控制合理的数据访问；通过加密对数据存储，备份及传输途径进行保护；通过数据屏蔽来保护仿真测试环境的敏感数据；

C）在数据访问过程中，通过拦截非法操作，来阻止违反规则的请求；

D）所有行为进行审计记录，操作行为可追溯。

1）总体解决方案

从安全管理制度到安全管理技术实现，根据我方的最佳实践结合产品功能，建议方案如下：

2）软件安全监测，为安全"隐患"全方位评估

3）数据库防火墙是数据库的第一道防线，防止对数据库的内部及外部攻击

大家知道针对数据库的防火墙都有哪些产品吗？

我们对 Imperva 和 Oracle AVDF 研究和应用比较多，以其中的 Oracle 产品为例：

白名单策略：遇到该名单认可的 SQL 语句时，防火墙就将其看作正常语句，让其通过，而其余语句则禁止通过

黑名单策略：专门禁止该名单未授权的 SQL 语句通过

例外策略： 可以灵活地让适用的安全政策无效，以支持软件修补、定制的成批作业和/或"打碎玻璃型管理控制

运用各种属性的策略：如一天中的时间、IP 地址、应用、用户和 SQL 类等属性

4）敏感数据加密存储，保证数据存储及备份数据安全

哪些数据需要加密保护？这是业务数据分类分级的范畴，首先以企业的任务和业务功能划分为依据识别信息类型，然后查找和设定与该信息类型相应的安全要求初始值，最后根据需要调整安全要求取值并计算安全级别，这个评估模型比较复杂，不在这里加以论述。

加密在写入数据文件以前完成，在检索数据是解密，应用程序无须修改

生产数据的备份别忘了保护，通过对备份的加密保护，让未经授权的人员即便获取了加密备份，也无法读取这些备份。

透明模式：只要所需的 Oracle 密钥管理基础结构可用，透明加密就可以创建和还原加密备份，而无需其它干预。透明加密最适合日常备份操作，这些备份的还原操作在执行备份的数据库中执行。透明加密是 RMAN 加密的默认模式。

口令模式：口令加密需要在创建和还原加密备份时提供口令。还原用口令加密的备份需要创建该备份时使用的同一口令。口令加密对于在远程位置还原的备份非常有用，但必须在传输过程中保证备份的安全。口令加密不能永久性配置。如果要完全使用口令加密，则不需要配置 Oracle Wallet.

双重模式：双重模式加密的备份可以通过透明方式或通过指定口令来还原。双重模式加密的备份对以下情况非常有用：创建的备份通常需要使用 Wallet 在现场还原，但有时需要进行无法使用 Wallet 的非现场还原。还原双重模式加密的备份时，可以使用 Oracle Wallet 或口令进行解密。

对于网络传输中的数据也需要进行加密保护，防止通过网络截获数据包，导致数据泄密：

5）权限管理细化

针对各种数据库用户，均应具有：

适当的身份验证

合适的角色

严格的帐号管理策略

资源限制（ PROFILE）

权限最小化：是指应为该系统的每个用户仅授予完成其预定任务或职能所需的最小一组权限

– 授予用户或角色权限时，授予所需的特定对象权限，而不是授予允许访问数据库中所有对象的广泛系统权限

– 创建角色时应仅包含完成特定职能所需的少量权限，而不是创建像内置的 DBA角色这样非常强大的角色

不共用帐号，职责分离

–应让权限分配给多个用户，而不是创建一个超级用户

– 采用这种方式划分管理权限可加强责任界定，而且还可避免受信任的管理员滥用权限

6）Data Masking，非生产数据库敏感数据（数据脱敏）保护

7）通过 Oracle Database Valut 配置访问规则、控制访问域，避免违规访问

8）通过 Oracle Audit Valut 记录操作行为，所有操作可追溯

About Me