【雲和恩墨】一次 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