在數據庫領域工作了十幾年，我發現國內技術人員往往一直在充當救火員的角色，企業常常也認為隻有能夠力挽狂瀾、起死回生的技術人員，纔是好的技術人員。而實際上，能夠不犯錯誤、少犯錯誤、提前預防、規避災難的技術人員纔是企業技術環境的最有力保障，能夠未雨綢繆、防患於未然纔是更好的技術實踐。
我們每年都幫助很多企業挽救數據、拯救危機，本書寫作的契機正是因為2011年12月30日和31日，連續兩個整天，我們連續挽救了幾個用戶的數據庫災難，這些災難發生的原因之簡單，讓人不可思議，在邁入2012年這個神秘年份的一刻，深深觸動了我，我想，如果將這些案例描述出來，就可能幫助一些用戶警醒借鋻，避免再陷入這樣的困境。而從別人的挫折中學習、借鋻，進而在自我的環境中未雨綢繆，防患於未然，是每個數據庫管理人員和企業數據環境管理者應該具備的素質。
寫作這本書還和2011年底眾多席卷而來的密碼洩露事件有關，當我注視著最常用的幾個密碼都在互聯網上被公開時，除了手忙腳亂地在各大網站修改密碼，剩下的就是深深的遺憾。幾乎所有從事IT行業的人，都深知安全的重要性，可是在實際執行中，大家又往往習慣性失明，忽視了自己本應能夠達到的力所能及之安全，很多專業人士就以這樣或者那樣的僥幸心理忽略了風險的存在，並一步一步走向安全危機。
對於數據庫安全來說，通常我們認為缺乏的並非是技術手段，更多的是缺乏規範和安全認知，如果用戶都能夠嚴格遵循安全守則並應用現有的安全技術手段，數據庫的安全性就能夠大幅增強，我們的安全事故率也會大大降低。
所以我決定動筆，寫下自己多年來所遭遇到的安全案例以及對於數據安全的思考，如果本書中的內容能夠幫助一些企業規避錯誤，保全數據，挽救一些技術人員的時間，那麼我將感到無比欣喜，於我們的生命中，最為寶貴的就是時間，寸金難買寸光陰。
[信息安全]
在傳統的信息安全領域，存在三個基本的安全要素，分別是保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），縮寫為CIA。
這三個要素的基本定義如下：
保密性：指信息在存儲、使用和傳輸過程中的保密性，要確保信息在這些環節中不會洩露給非授權方。
完整性：指信息在存儲、使用和傳輸過程中不會被非授權用戶篡改、變更，同時需要防止授權用戶對繫統及信息進行非授權篡改，保持信息在整個過程中的內外一致性。
可用性：信息繫統因其服務使命，必須在用戶需要時，可以被正常訪問，授權用戶或實體對信息繫統的正常使用不應被異常拒絕或中斷，應當允許其可靠、及時地訪問和獲取信息及資源。高可用繫統要求所有時間可用，要確保繫統不因電源故障、硬件故障和繫統升級等因素影響服務的可用性。
信息安全的三要素是對安全的概括和提煉，不同機構和組織，因為需求不同，對CIA的側重也會有所不同，隨著信息安全的發展，CIA經過細化和補充，增加了許多新的內容，包括可追溯性（Accountability）、抗抵賴性（Non-repudiation）、真實性（Authenticity）、可控性（Controllable）等。與C組相反的一個概念是D組，即洩露（Disclosure）、篡改（Alteration）和破壞（Destruction），實際上DAD就是信息安全面臨的最普遍的三類風險，是信息安全實踐活動最終應該解決的問題。
從CIA理念出發，我們通過對信息安全範疇所有相關主題精煉整理得到了一個標準化的知識體繫，被稱為公共知識體繫——CBK（Common Body of Knowledge），CBK包括10個知識範疇（Domain），對安全進行了全面的概括，具有極強的指導意義，這10個範疇分別為：訪問控制，電信、網絡和互聯網安全，風險管理和業務連續性計劃，策略、標準和組織，計算機架構和繫統安全，法制、合規、調查和遵從，應用程序安全，密碼學，操作安全，物理環境安全。
[數據安全]
信息安全的核心是數據安全。
在數據安全的範疇內，也包含信息安全的諸多方面，根據多年的服務經驗與思考，我們將安全劃分為五大方面，分別是：軟件安全、備份安全、訪問安全、防護安全和管理安全。
這五大方面是信息安全在數據領域的引申和映射，在企業數據安全中，這五大方面相輔相成、互有交叉、共同存在，下圖是一張關於安全的思維導圖，本書中的案例涉及了這五大方面。
在這五大安全方向中，可能出現兩種性質的安全問題，第一，由於內部管理不善而導致的數據安全問題；第二，由於外部惡意攻擊入侵所帶來的安全安問題。通常我們把安全問題狹義化為後者，這實際上是片面的，在數據安全問題上，前者造成數據損失、數據損毀的概率和影響度都遠遠超過後者。
下面我們對數據安全的五大方面做一下簡要的分析和探討：
1．軟件安全是指數據庫和應用軟件產品、版本是否穩定安全；廠商所能提供的補丁集和BUG修正是否及時、基礎硬件與操作繫統是否經過認證。很多用戶在部署數據庫軟件時，僅僅選擇了最容易獲得的初始發布版本（如Oracle Database 11.2.0.1或者Oracle Database 12.0.1.0等），遺漏了可能已經存在的補丁修正，並且在運行維護中並不能夠及時跟蹤軟件更新，也無法獲得BUG信息、補丁修正和安全告警，這就使得軟件本身的很多風險隱患得不到修正。除了數據庫基礎軟件，如果應用軟件中存在漏洞或者後門，被惡意或未授權利用，用戶的數據也無法獲得安全保障。如果軟件安全無法保證，數據庫安全的基礎也就喪失了。
2．備份安全是指用戶數據能否得到及時有效的備份保全，能否在故障災難之後獲得及時的恢復和挽救。在數據庫運行期，最為重要的就是備份安全，如果沒有可靠的備份，將數據集中起來就隻能等待數據災難，所以我們將備份安全提升到核心地位，備份以及隨之衍生的備份加密、容災安全、高可用、數據脫敏等，都是企業整體數據架構應該考慮的因素。很多企業在數據災難發生之後因為缺乏有效備份而一蹶不振，根據Gartner 2007年發布的一份調查報告顯示，在經歷了數據完全丟失而導致繫統停運的企業中，有2/5再也沒能恢復運營，餘下的企業也有1/3在兩年內宣告破產，由此可見，由於備份安全問題導致的企業傷害可能遠遠大於黑客攻擊。
3．訪問安全是指用戶數據庫的訪問來源和訪問方式是否安全可控。通常數據庫繫統處於IT繫統的核心位置，其安全架構涉及主機、繫統、存儲、網絡等諸多方面，如果沒有明確的訪問控制，缺乏足夠的訪問分析與管理，那麼數據庫的安全將是混亂和無法控制的。在應用軟件使用和訪問數據庫時，要正確設置權限，控制可靠的訪問來源，保證數據庫的訪問安全，唯有保證訪問安全纔能夠確保數據不被越權使用、不被誤操作所損害，通常最基本的訪問安全要實現程序控制、網絡隔離、來源約束等。
4．安全防護是指通過主動的安全手段對數據庫通信、傳輸等進行增強、監控、防護、屏蔽或阻斷，諸如數據加密、審計、數據防火牆等技術都在這一範疇之內。我們必須認識到，在IT技術高度發展的今天，風險是無處不在、層出不窮的，我們從未思考過的安全問題可能每天都在不斷發生，所以在數據庫環境中采取主動式防護，可以幫助我們監控分析和屏蔽很多未知風險，已經有很多成熟的產品和技術可以用於安全防範。
5．管理安全是指在企業數據的日常管理維護範疇內，能否充分保證數據安全以及服務的高可用連續提供。諸如DBA的維護、文件的管理、參數或數據結構的變更等都可能引入數據風險，管理安全要求我們通過規範、制度以及技術手段去確保維護管理安全；另外，基於硬件、電力等基礎平臺的故障都可能影響數據庫服務的高可用性，在管理中要通過監控手段及時預警，通過集群、備庫等切換與服務保障服務的連續性。
這就是數據安全的五大方面。
[Oracle數據庫安全]
Oracle數據庫自1977年開始，就一直將安全置於首位，從強大的數據恢復機制，到不斷增強的加密以及安全防範措施。“Oracle”這個名字就是來自美國中央情報局投資的項目代碼，而美國中央情報局也正是Oracle最早期的用戶之一。
接觸過Oracle數據庫的人都應當熟悉一個類似如下圖所示的錯誤“ORA-00942：表或視圖不存在”，這個簡單的錯誤提示，最初就是在美國中央情報局的要求下作為一項安全防範設定的，這個提示的安全意義在於：避免提供任何具體的實質性提示性信息，以預防黑客的攻擊性嘗試。由此可見，安全防範可以從每一個細節入手，安全是一項全面整體的技術實現，並非孤立的存在。
受密碼事件影響，我們首先從Oracle數據庫的密碼機制上來深入了解一下Oracle的加密機制。雖然我們知道早在Oracle 數據庫版本8的年代，就已經提供了強大豐富的數據庫加密功能，但是直至今日，恐怕半數以上的數據庫中，仍然存放著用戶的明文密碼，並且未采用任何數據庫安全增強機制。這也是我認為最重要的安全問題：我們並不缺乏安全防範手段，但是缺乏對安全風險的認知。
誠然，我們對安全的認識是隨著不斷出現的安全事故逐步增強的，但是希望大家都能夠有計劃地逐步增強對數據庫的安全防範，主動規劃推進數據安全與從挫折中學習提高實有天壤之別。對於2011年底的密碼洩露事件，如果各大網站能夠采取基本的技術手段對用戶密碼進行一定的加密，那麼這次密碼洩露的安全事件就不會顯得那麼初級和讓人恐慌，想一想明文密碼和MD5（Message-Digest Algorithm 5，信息摘要算法5）散列值的區別？前者基本上意味著數據庫從未從安全角度進行過任何思考和增強。
Oracle數據庫的用戶信息及加密密碼存儲於一個名為USER$的數據表中（所有者為SYS用戶），我們可以通過基於USER$表建立的DBA_USERS視圖來查詢和獲得這些信息，包括密碼散列後的值。
在Oracle Database 11g之前，用戶口令遵循DES標準（Data Encryption Standard），通過對稱算法進行加密，用戶名為“Salt”，密碼最長為30個字符，所有字母被強制轉換為大寫。從Oracle 7 至 Oracle 10g，加密一直使用username和password串聯之後進行HASH運算，例如sys/temp1和system/p1將會獲得相同的HASH加密輸出。
從Oracle Database 11g開始，Oracle允許最多使用30個字符、大小寫混合方式作為密碼，同時支持DES和SHA-1算法進行加密（SHA-1算法支持大小寫混合，通過初始化參數SEC_CASE_SENSITIVE_LOGON開關），使用password||salt的方式進行HASH加密。
下圖展示了Oracle 9i數據庫中用戶密碼的加密形式，DBA_USERS視圖的PASSWORD字段顯示了加密後的密碼（Encrypted Password）：
在Oracle 11g中，密碼從DBA_USERS視圖中隱藏起來，這進一步增強了安全性，即便具有訪問視圖權限的用戶，也無法獲得口令的散列值如下圖所示，由此我們也可以看出Oracle數據庫軟件的安全增強歷程：
密碼的加密內容存儲在底層的核心表（USER$是Oracle數數據表之一）中，以下PASSWORD字段存儲的是DES標準加密值，SPARE4存儲的是SHA-1加密輸出：
關於口令的維護，Oracle支持各種約束性限制（通過utlpwdmg.sql 腳本啟用），諸如復雜程度、長度、有效期、失敗登錄次數等，通過這些增強，Oracle的口令限制可以定制出非常穩固的安全解決方案，如果你從未接觸和研究過這些手段，那麼可能說明你的數據庫還缺乏足夠的第一層安全防守。
如果我們能夠從Oracle的安全策略入手，學習一下Oracle的密碼安全解決方案，就能構建一套較為完善的基本安全解決方案。從Oracle的第一個Internet版本 Oracle 8i（1998年發布）開始，Oracle就提供了一個加密包DBMS_OBFUSCATION_TOOLKIT 用於數據安全防護，這個加密包支持DES、3DES 和 MD5散列算法。
通過非常簡單的封裝調用，DBMS_OBFUSCATION_TOOLKIT 包就能夠實現數據加密，下圖展示了一個簡單的示例輸出，對於給定字符串進行MD5散列，會以RAW方式返回結果（通過創建穩固的函數，可以實現用戶登錄時的即時散列、比較和認證）：
從Oracle Database 10g開始，DBMS_CRYPTO包被引入到數據庫中，該程序包支持更廣泛的加密算法，並用於替代DBMS_OBFUSCATION_TOOLKIT包，在新的版本中，諸如DES、3DES、AES、RC4、MD5、SHA-1、MD4、HMAC_MD5、HMAC_SH1等算法和加密方式都被支持。
通過選定的加密算法和加密方式，可以對重要數據進行加密和解密，我們不僅可以實現對密碼或數值、字符數據的加密，還可以對類似LOB等非結構化數據進行加密。下圖展示了使用DES算法的CBC模式和PKCS5補碼規則進行加密解密的實現，示例模擬了對信用卡卡號的處理過程，金融類企業數據的安全性更為突出，需要進行安全加密的類型更為豐富。
我想重申的是，對於不同的數據庫產品，都存在足夠成熟的安全實現手段，應用這些安全手段就能夠實現對於數據的基本保護，對於我們技術人而言，最重要的是認識和重視數據安全問題，並逐步推動企業或組織應用安全手段進行數據安全增強。重視數據、保護數據，這是每一位技術人的共同使命！
[本書使命]
本書所描述的所有恢復以及安全案例全部確有其事，但是基於用戶隱私的考慮，我們隱去了所有和客戶相關的信息，對於摘錄的內容涉及用戶判斷的，全部進行了處理，但是時間、故障內容一切屬實。多年來的災難挽救讓我積累了很多素材，所以寫作這本書是一次回顧的旅程，以一條主線，將眾多的災難挽救過程串聯起來。這本書中的很多案例，尚屬首次曝光，而你也許還會注意到，書中的某些技術細節和恢復方法你從未在其他地方看到。
本書中的很多案例的恢復過程非常艱難，拯救過程也花費了大量的人力、物力和時間，我們也因此贏得了價值不菲的商業合同，但是從內心上來說，我們永遠不希望用戶陷入這樣的境地，所以我寫了本書，使得這些曾經慘痛的教訓可以具備更廣泛的借鋻意義。
基於這些想法，我對每個案例的發生過程進行了描述，並且提出了供大家警示的規避法則。所以，我希望這是一本寫給大家看的數據安全之書，不僅僅是給技術人員，更重要的是給企業數據管理者，如果不了解這些案例，你也許永遠不會理解數據庫為何會遭遇滅頂之災，你也許永遠無法理解為何千裡之堤一朝潰於蟻穴。
當然，這仍然是一本相當深入的技術書，我將很多案例的詳細拯救過程記錄下來，包括一些相當深入的技術探討，這些技術探討一方面可以幫助讀者加深對Oracle數據庫技術的認知，另一方面又可以在你遇到類似案例時，做出同樣的營救工作。
對於我自身來說，年紀越長，就越是認識到這個世界上最為寶貴的就是時間，如果我的分享，從警示到技術，能夠幫助大家規避錯誤，少犯錯誤，在恢復時不走彎路，快速拯救數據，工程師們和用戶的時間，那麼這就是我最強烈的願望，拯救時間，即為功德，這世界上，寸金買不到寸光陰。
這本書是用他人的災難，為大家警示，但願我們都能夠從中吸取教訓，永遠不要遇到本書所描述的種種災難。
[致謝]
感謝我的朋友們，他們對我的幫助和支持使得本書的很多內容得以成型，劉磊在ACOUG上的演講《猜測的力量》幫助我豐富了關於REDO分析的案例；本書還引用了楊廷琨分析解決的一個ASM故障案例，此外，附錄中老楊提供的函數非常有用；感謝用戶，是他們的信賴使得我們能夠接觸種種艱難的案例，並幫助他們挽回數據；感謝支持幫助過我的朋友們以及一貫支持我的讀者們，書中真摯的內容就是我最好的回報。
感謝我的好友丁曉強，他在支付寶公司進行了多年的安全與運維體繫的建設與管理工作，他基於實踐而來的對於安全和運維的真知灼見給予了本書很多肯綮的建議，這些建議讓我對安全有了更加繫統全面的理解，從而也對本書的架構做出了調整，雖然有很多想法沒能在本書中體現，但是我相信，我仍然有機會在未來和大家繼續分享我從他那裡學來的寶貴經驗。
再次感謝楊廷琨，他在本書出版之前，通讀了全書書稿，細致到幫我修改敲錯的字母和寫錯的漢字，認真的態度讓我欽佩得無以復加；他還幫助我增加了兩個警示條目，內容來自他感觸最為深刻的技術經歷。老楊的工位和我相鄰，在工作中我無論何時請教都可以即刻得到他絕妙的提示，讓我了大量的工作時間，這是達成本書的另外一個重要助力。
我還要感謝我的太太、兒子及其他家人，因為寫這本書，我犧牲了很多陪伴他們的時間，也正因為有他們的支持，我纔能夠不斷地寫下去。
最後，但願書中這些看起來似乎遙遠的故事，能夠警醒你似曾相識的某些操作，並且永遠不要面對這樣的災難。
蓋國強（Eygle）
2012年1月20日 初稿
2012年3月1日 定稿於北京
