“重建設 輕管理”一直是我國各行業信息化發展的主要困境，這個問題在數據庫系統的建設、管理工作中同樣存在。近年來，這種局面造成的后果已開始明顯顯現：各類來自內部或第三方外包人員的數據泄露、丟失和被篡改事件頻頻發生，由此導致的珍貴數據資產損失和相關系統功能癱瘓等情況，如同緊箍咒一般，三不五時地刺激著運維部門本就緊繃的神經。

數據庫運維安全現狀

數據庫運維人員需要承擔數據庫系統的權限分配、故障處理、性能優化、數據遷移備份等工作任務，這些關鍵環節中，如果出現任何紕漏，都可能導致不可逆的數據資產損失或其他不良后果。由于缺乏細粒度的管控手段，數據庫運維工作普遍存在內部人員、甚至第三方外包人員間的賬號共享、主機共享、高權限賬戶濫用等情況，加之人工操作無法保證100%的準確度，數據庫日常運維操作面臨以下一系列安全風險：

• 操作身份不明確
• 操作過程不透明
• 操作內容不可知
• 操作行為不可控
• 操作事故不可溯等

面向不同的數據庫運維場景，操作申請人、執行人、審批人、操作對象、操作內容各不相同，如何提高對數據庫運維操作的把控力?實現“透明化”管理是運維主管心目中的最佳答案。因此，專業的數據庫安全運維系統應運而生。

圖1.數據庫安全運維系統的全流程管控模式

事前審批-為運維管理者提供專業的統一平臺

為了規范內部人員及第三方外包人員對數據庫的訪問管控，不少企業的管理部門已制定相關要求，這里概括為以下幾個重點：

1、運維人員身份鑒別：通過雙因素認證機制，解決數據庫賬戶共享、運維主機共享的場景下的運維人員精準身份鑒別及權限劃分。認證機制包括：

• 審批口令碼：運維人員提交申請并通過后獲得審批碼，當運維人員登錄數據庫后，需提交審批碼，方可繼續執行獲準的運維操作。
• 動態令牌：運維人員在登錄數據庫后，通過輸入動態令牌顯示的數字，校驗自身身份，校驗通過后，方可執行與自身身份相符的運維操作。

2、涉及數據庫的批量操作(批量查詢、批量導入導出、批量為客戶開通、取消或變更業務等)，運維人員必須執行相應的審批流程，由相關主管審批后方可執行。涉及超權限的數據庫運維操作，運維人員需要額外提交申請，由相關主管審批后授權操作。

3、涉及業務投訴、統計取數、批量業務操作、批量數據修復等需求進行的客戶敏感數據查詢、變更等操作前，運維人員必須取得業務管理部門的相關公文，并執行審批流程。執行操作時，對極高敏感度的數據操作，需要保證多人在場、多人協作方式以確保操作安全性。

4、需要對所有審批流程的操作工單整理備案，記錄操作原因和工單編號，并由專人負責審核。

我們看到管理要求中對運維操作的事前審批進行了重點要求，在實際落地中，目前大多數單位的普遍做法是由運維人員通過紙質申請單或辦公OA系統填寫工單，說明運維操作事項，提交相關領導審批。純紙質化辦公模式存在的問題很明顯：效率低、成本高、資料保存和查詢困難、不便于多人協同辦公等，而類似OA系統的審批平臺，不僅功能細化程度不夠，對于數據庫運維操作的申請歸根結底還要依靠審批人的判斷，人工把握操作風險，OA系統僅僅解決了流程上的問題。

綜上，在審批環節中，專業的數據庫運維系統應該能夠提供兩方面的能力：其一，必須能夠整合審批流程，為內部運維人員、第三方外包人員、業務主管等多角色提供細致統一的審批平臺，能夠提供對操作人、操作對象、操作內容、操作時間、相關審批人等等細粒度的申請條件，使審批過程清晰、透明。

基于人性化設計，考慮審批人的職位不同，需要能夠支持技術化或業務化的申請模式，專業的安全運維系統需要支持多種申請提交方式，如：提交完整操作語句、提交“時間+對象+操作”的條件組合，以禁止某些高危操作和敏感表訪問的方式進行審批授權，提交指定時間和周期的執行腳本。此外，另一個重要能力是，應當能夠提供對申請內容的智能分析能力，能夠對操作申請進行風險預估和異常行為評測，為審批者提供決策依據，在操作前最大可能的降低運維事故概率。此外，在審批時應當提供對下一步操作執行過程的校驗機制，以確保操作人與操作內容的安全性。目前，使用校驗碼是最為周全的方法，審批通過后系統隨機生成一串口令，在后續的操作中，通過識別口令碼進行身份驗證，確保操作人的身份安全性。

圖2.數據庫運維操作的申請方式

事中管控-實現透明化管理的關鍵發力點

我們都清楚運維人員的工作強度：他們真的太忙了!不是蹲在機房調試服務器，就是穿梭在各業務部門之間處理系統故障，自然，手頭的系統運維操作被突然打斷也是常有的事。同時兼顧多個數據庫的日常維護工作，運維人員的電腦界面總是鋪滿了多個工作窗口，這樣多交叉、多并行的工作性質，誤操作的發生在所難免。曾有運維人員向我們講述過自己最驚心動魄的運維事故：某天，在例行的數據庫表內數據刪除操作時，一個走神，語句中where條件后沒加“id=”，而是直接鍵入了某個數字，短短幾秒間，幾百萬條數據被刪除，事后的數據恢復工作進行了整晚，依然沒有搶救回全部數據，核心數據庫文件的丟失導致關鍵服務完全癱瘓。現在，運維部門同事都不敢在白天進行核心數據庫的運維操作，生怕忙中出錯。辛苦一整年，一鍵誤操作卻功虧一簣。

目前數據庫運維工作的管理模式重在事前審批，審批通過后則由運維人員自行安排操作執行，也可能由其他人員代操作，整個操作過程不定因素很多：

• 運維人員實際操作是否與申請一致?
• 實際操作人是誰?
• 出現誤操作，如何追溯?
• 如何管控來自內部或第三方運維人員有意無意的高危操作?

堡壘機是目前大多數企業的普遍解決方案。而事實上，由于缺乏對數據庫通訊協議的精確解析能力，堡壘機只能實現對操作人身份、操作目標庫等最基本的身份識別，這其中差了最關鍵的一環：對操作內容、操作過程的有效管控。因此，對執行過程進行透明化管控是數據庫安全運維系統的重要使命。

當申請人執行操作事項時，專業的數據庫運維系統應當能夠結合操作前的申請事項，通過與申請內容的細化匹配以及自身的智能分析，幫助管理者進行實時的運維過程監控;自動根據預設置的風險控制策略，結合對數據庫訪問的實時監控信息，進行語句特征檢測及審計規則檢測，任何嘗試的數據庫攻擊、違反安全策略或有悖于申請事項的疑似危險操作，都會被檢測到并實時阻斷或告警。

圖3.數據庫安全運維系統的工作架構

此外同樣重要的一點是，真正有價值的產品絕不能對用戶原有的工作習慣產生過多影響。比如當運維人員需要其他人進行代理操作時，用戶依然可以通過第三方工具登錄數據庫進行操作。通過運維系統提供的操作口令碼進行簡單認證，口令通過者只能執行其申請的操作內容，未經口令認證者同樣無法操作敏感數據;在不改變原有工作習慣的基礎上，防止越權操作及違規操作。

以上，針對運維人員的操作行為做出嚴格的事中控制，實現了對敏感數據操作的權限控制，但是運維人員仍可以看到敏感數據。所以，在此基礎上，DBController增加了敏感數據遮蔽功能，可以最大程度從運維側規避數據泄露風險，數據庫安全運維系統通過靈活的配置，實現敏感數據動態屏蔽，讓具有不同訪問數據庫權限的人員看到不同的數據，既不影響正常運維、開發工作，有防止了敏感數據泄露。

事后追責-讓運維管理者有據可查

事后追責和審查取證是數據庫運維管控的最后一環，這里需要運維系統對存儲的申請與執行的操作記錄進行數據分析，通過運維人員和審批人的行為記錄形成可視化的統計分析。提供各維度的報表系統，當出現安全事故后，能夠精確定位到違規操作的實際執行人、審批人，為事后追責和審察取證提供無可爭辯的準確依據。

圖4.數據庫安全運維系統的應用場景

至此，數據庫安全運維系統完成了對整個運維過程的全流程管控，通過引入這樣的專業運維管控系統，實現了事前審批、事中控制、事后追蹤三步重要環節的透明化管理，為企業數據庫系統“重建設輕管理”的現實問題，給出了令人滿意的答案。另一方面，這樣自動化的智能管控技術，更是對數據庫運維人員的解放，高強度的工作量硬撐了一年，別讓不經意間的數據安全事故成了壓垮運維人員的最后一根稻草。