論資料庫運維的全流程管控技術

2021-09-23 04:24:00 字數 3138 閱讀 8077

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

資料庫運維安全現狀

資料庫運維人員需要承擔資料庫系統的許可權分配、故障處理、效能優化、資料遷移備份等工作任務。這些關鍵環節中,如果出現任何紕漏,都可能導致不可逆的資料資產損失或其他不良後果。

由於缺乏細粒度的管控手段,資料庫運維工作普遍存在內部人員、甚至第三方外包人員間的賬號共享、主機共享、高許可權賬戶濫用等情況;加之人工操作無法保證100%的準確度,資料庫日常運維操作面臨以下一系列安全風險:

操作身份不明確

操作過程不透明

操作內容不可知

操作行為不可控

操作事故不可溯等

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

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

通過認證機制進行運維人員身份鑑別,這是解決資料庫賬號共享、運維主機共享場景下,運維人員精準身份鑑別及許可權劃分的問題,認證機制可以包括發放口令碼及動態令牌兩種方式,雙因素認證機制相對更嚴謹。

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

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

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

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

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

基於人性化設計,考慮審批人的職位不同,需要能夠支援技術化或業務化的申請模式,專業的安全運維系統需要支援多種申請提交方式,如:提交完整操作語句、提交「時間+物件+操作」的條件組合,以禁止某些高危操作和敏感表訪問的方式進行審批授權,提交指定時間和週期的執行指令碼。此外,另乙個重要能力是,應當能夠提供對申請內容的智慧型分析能力,能夠對操作申請進行風險預估和異常行為評測,為審批者提供決策依據,在操作前最大可能的降低運維事故概率。

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

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

運維人員實際操作是否與申請一致?

實際操作人是誰?

出現誤操作,如何追溯?

如何管控來自內部或第三方運維人員有意無意的高危操作?

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

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

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

以上,針對運維人員的操作行為做出嚴格的事中控制,實現了對敏感資料操作的許可權控制,但是運維人員仍可以看到敏感資料,我們如何保證運維人員不會通過拍照、截圖等方式獲取敏感資料?在查詢結果中加入敏感資料遮蔽的功能正是基於這樣的考慮,重點在於遮蔽效果必須是動態的,對於具有不同許可權的訪問人員執行不同的遮蔽策略,在不影響正常運維、開發工作的前提下,防止運維人員洩露敏感資料。

事後追責——讓運維管理者有據可查

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

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

資料庫運維的一些操作

摘要 一般在管理資料庫的時候 一些會用到的操作 mysql oracle 檢視使用者所在的表空間 yitian20000的專欄 csdn部落格 oracle檢視建立了哪些儲存過程 大資料技術雜談 csdn部落格 檢視當前使用的資料庫 mysql show databases 可以檢視有哪些資料庫,返...

資料庫日常運維中的幾個操作建議

如果你去看其他dba的操作的時候,如果要判斷他們水平的高低,我想就是通過一些操作的差別來看了,而水平高低就體現於此。細節決定成敗,越是看起來簡單的操作越是要嚴謹,一絲不苟。1.停止資料庫 shutdown immediate應該是停止資料庫的首先方案,而如果你選擇shutdown abort的方式,...

哪些是資料庫智慧型化運維必踩的坑?

oracle ai 效能優化指南 現在我們絕大部分的運維工作還是集中在文件化定位 指令碼化 運維工具化,雖然這三大塊裡面已經有很多企業實現了部分的自動化運維,但是我相信很多時候還是靠人肉為主。運維發展的第乙個階段是無序化運維,也就是所謂的水來土淹,兵來將擋,有故障了就處理,沒故障就喝茶看報,文件也沒...