在傳統(tǒng)的數(shù)據(jù)庫安全防護思路中，通常認為IT運維側(cè)是安全的。事實上，從近年來暴露的一些安全事件中，我們發(fā)現(xiàn)除了主要的外部黑客攻擊，內(nèi)部運維人員的誤操作、高危操作可能對核心數(shù)據(jù)造成更壞的影響。就數(shù)據(jù)庫層面來看，DBA等運維人員擁有高權(quán)限用戶，可以根據(jù)業(yè)務需要對數(shù)據(jù)庫系統(tǒng)中的底層數(shù)據(jù)進行增、刪、改、查等操作，誰來確保這部分人群的操作執(zhí)行準確度？由于一個關鍵語句的參數(shù)輸入錯誤，導致的整列或整表刪除、被修改等運維事故可能為企業(yè)帶來不可逆轉(zhuǎn)的影響，尤其對于關鍵業(yè)務系統(tǒng)的底層數(shù)據(jù)，稍有閃失就可能導致業(yè)務系統(tǒng)報錯、停轉(zhuǎn)，繼而對企業(yè)造成直接的品牌或經(jīng)濟損失。

目前在運維側(cè)防護中，大多用戶采用事前審批平臺+堡壘機對運維操作進行審批和監(jiān)控，但在實際運行中，這種方式并不能對運維人員的實時操作進行管控。首先事前審批平臺（比如OA系統(tǒng)或紙質(zhì)審批單）只能對運維人員的操作申請做審核，確保提交的申請符合業(yè)務需求。堡壘機的的事中管控雖然能夠?qū)�網(wǎng)絡通信協(xié)議進行解析和識別，審批實際操作的準確性，但由于其并不具備對SQL語句的精確解析能力，因此對于DBA等數(shù)據(jù)庫運維人員提交的具體操作是否準確執(zhí)行，無法判斷，其能夠做到的只是對系統(tǒng)操作進行統(tǒng)一錄屏，在出現(xiàn)運維事故后，需要調(diào)取特定時間的數(shù)據(jù)庫操作記錄，一一核對錯誤語句的提交者和操作內(nèi)容。鮮切不談這種追溯方式的操作有多大難度，即使能夠找到責任人，但事故已經(jīng)發(fā)生，損失也無法逆轉(zhuǎn)。

綜上，運維側(cè)的傳統(tǒng)數(shù)據(jù)庫防護手段弊端比較明顯。在數(shù)據(jù)庫安全越發(fā)重要的今天，對數(shù)據(jù)庫運維操作的實時管控需求應運而生，這里需要能夠?qū)崿F(xiàn)對數(shù)據(jù)庫操作實時管控的技術手段，能夠避免運維人員的高危操作或誤操作帶來的業(yè)務影響，我們將在后面文章中對數(shù)據(jù)庫運維操作的實時管控手段進行解析。