作者 陳鬆威，18年碩士畢業於華中科技大學，目前在CDB/CynosDB資料庫核心團隊擔任TXSQL雲資料庫核心研發，開發過的功能包括企業級列加密函式、資料恢復工具、非同步審計等。

引言

一、什麼是資料庫審計

對於一個倉庫，如果要防盜，常見做法是出入口全裝上監控，一旦有問題了，調監控查詢異常情況。對資料庫來說也類似，資料庫也有出入口，對所有連接出入口監控，可以記錄下所有的動作，一旦有問題了，通過查詢歷史動作並進行分析，可以找到關鍵資訊。故資料庫審計可以理解為是記錄使用者訪問資料庫行為，定位非法動作，事後追根溯源，提高資料庫安全性的功能。

二、常見的審計方式

在應用系統中直接審計，語句還沒往資料庫後臺發就先做了審計，不影響資料庫效能，對底層用的是什麼資料庫也不關心，但對應用系統壓力比較大，並且應用系統需要解析語句，有一定複雜度。 往往抓包解析實現，對上下層都沒什麼影響，但同樣要解析語句，有一定複雜度，並且如果傳輸層是通過加密通訊，將無法解析。 直接在核心上實現，所有功能都能實現，也能將效能影響降到最低，但是對後臺穩定性會有影響，對開發人員要求高，不管是開源還是非開源資料庫，都會非常慎重考慮直接在核心上支援審計。 對於開源資料庫，通常都有提供外掛方式增加功能。審計可以以外掛直接嵌在核心上，當然會對資料庫效能有一定影響，但同樣因為直接嵌在核心，很多一手資訊能直接拿到，比方說上面沒辦法迴避的語法解析就不用做，而且還能直接拿更多的執行態資訊，能開發功能強大又靈活的審計功能。 其中外掛式審計由於對核心侵入小，可以動態安裝、解除安裝和升級等優點，是較受青睞的審計實現方式。MySQL上也有不少審計外掛，例如Macfee外掛，官方audit plugin，mariadb audit plugin，Percona audit plugin。 從功能上而言，審計外掛大同小異，只是展示的審計內容和格式略有差異。從實現方式而言，審計外掛的資料來源近乎相同，而在規則過濾和刷盤策略上有較大的差別。從效能上而言，除了macfee外掛外，其它幾個效能相差不多，宣稱都是15%左右影響，macfee則可能達到50%或更多。 總體而言，審計的效能影響不能一概而論，其與使用場景強相關。審計以query為單位記錄審計日誌，效能開銷與QPS成正比。在OLAP場景下，一條query執行幾秒，甚至幾十秒，此時審計對效能的影響幾乎可以忽略不計。如果場景被設定為簡單查詢語句，QPS高達幾十萬的話，可想而知對效能會造成一定影響。

三、MySQL官方審計外掛

MySQL支援了MYSQL_AUDIT_GENERAL_ALL、MYSQL_AUDIT_CONNECTION_ALL等十餘種審計外掛的型別，用於對客戶端連線、query處理、error log日誌落盤、general log落盤等場景進行審計，審計外掛的介面實現在sql目錄下的sql_audit.h和sql_audit.cc中。不同的外掛型別對應不同的程式碼觀察點。審計外掛的定義中需要選擇一種或多種註冊型別，審計外掛安裝後，相應的程式碼觀察點即可被啟用。當程式執行到被啟用的程式碼觀察點處時，將攜帶這些審計資訊跳轉至審計外掛定義的對應觀察點處理函式中，進行審計日誌的規則判斷，落盤等處理。

Query在執行過程中，程式會記錄諸如使用者名稱、客戶端ip、操作型別等審計資訊。以MYSQL_AUDIT_GENERAL_ALL為例，其記錄的審計資訊如下所示：

TXSQL審計的實現

TXSQL是騰訊雲資料庫團隊維護的 MySQL 核心分支，100%相容原生 MySQL 版本，TXSQL 提供了類似於 MySQL 企業版的諸多功能，如企業級透明資料加密、審計、執行緒池、加密函式、備份恢復等功能。

一、資料庫審計架構

騰訊雲資料庫MySQL提供了基於TXSQL核心外掛的資料庫審計服務，其沿用了官方審計外掛介面，並支援同步審計、非同步審計兩種審計架構。

1.同步審計模式

同步審計模式的架構如下圖所示，左側灰色部分對應資料庫伺服器mysqld，它採用執行緒池中相對固定的工作執行緒來處理所有使用者的連線。工作執行緒每執行一個query或處理一個新的連線會生成一個審計event。工作執行緒需要結合審計規則判斷當前event是否需要記錄，如果需要記錄，則將審計event按一定格式轉化為審計日誌，並拷貝到公共的Audit buffer中。Flush thread負責非同步將Audit buffer中的審計日誌落盤到本地。Audit agent負責將本地的audit log推送到CTSDB（騰訊雲推出的一款分散式、可擴充套件、支援近實時資料搜尋與分析的時序資料庫）上進行儲存，並提供查詢。

接下來，詳細聊一下同步審計的實現。下圖左側是一條query的執行過程，包括連線，語句解析、分析、語句重寫、語句優化、語句執行、語句返回和資源釋放等幾個步驟。為了能獲取query執行的影響行數、執行時間、錯誤碼等內容，TXSQL審計選擇了在語句返回之後，資源釋放之前的觀察點處理審計邏輯。下圖右側是同步審計的具體流程，工作執行緒在語句返回之後、進入審計觀察點，如果例項沒有開啟審計，則直接進入資源釋放步驟。如果使用者開啟了審計，進一步判斷當前審計event是否需要記錄。如果需要則獲取審計內容並計算審計內容的長度。計算完審計日誌長度後，加鎖在公共Audit buffer中進行記憶體佔位，接下來立刻釋放鎖，在無鎖的情況下將審計event轉化為json格式的審計日誌並拷貝到公共Audit buffer中已佔領的位置處。Flush執行緒非同步將Audit buffer中的審計日誌落盤到本地，等待Audit agent進行消費。

2. 非同步審計模式

同步審計模式在絕大多數場景下效能優異，但是在配置了多個正則審計匹配規則並且QPS非常高的場景下將出現大幅的效能下降。效能下降的根因是正則匹配的過程中需要malloc記憶體，在高併發高壓力下malloc系統呼叫在核心態出現鎖瓶頸，影響了整體效能。為了解決同步審計在個別場景下的效能問題，TXSQL還支援了非同步審計模式。

上圖是非同步審計的架構圖，由圖可見，工作執行緒只需要將audit event交付給審計event佇列後即可返回。新增write thread負責消費審計event佇列，並完成剩餘的審計規則判斷、記憶體拷貝等工作。由於每個時間點併發malloc的執行緒數大幅下降，因此malloc系統呼叫的鎖瓶頸不復存在。下圖是非同步審計的具體實現。write thread負責觀察審計event佇列，如果有需要處理的audit event，則將其摘下進行審計規則判斷，如果需要記錄該審計event則進一步進行審計內容長度計算、加鎖進行記憶體佔位、無鎖內容轉換和記憶體拷貝等工作。

二、資料庫審計規則

目前TXSQL的資料庫審計支援以下型別設定：客戶端IP，資料庫帳戶，資料庫名。支援的匹配方式為：包含，不包含，等於，不等於，正則 方式匹配。每條規則為一個結構物件，多條規則為一個連結串列，規則儲存在記憶體中，全域性共享，審計啟動時從規則配置檔案載入，修改、增加、刪除時重新載入。

Rule list: 規則連結串列，每個規則對應前臺配置的一個或多個，不能合併的多個規則之間是或（||）關係。

Content list: 單個審計規則，規則內容包含username，host, database3項。在Content規則內部，不同內容項之間是與（&&）的關係。

結構簡圖如下：

三、資料庫審計效能

TXSQL提供的資料庫審計開啟後，對使用者的資料庫例項會有少許效能損耗，但遠低於業內的其他解決方案。（業務使用場景、QPS、規則設定等均會影響資料庫審計的效能開銷）

同步審計模式的最大的特點在於工作執行緒在生產審計日誌的過程中，計算審計內容長度、內容json轉換和Audit buffer拷貝都是在無鎖的情況下進行的。整個過程只有記憶體佔位需要持有鎖，臨界區足夠小，使得Audit buffer的寫鎖沒有成為系統瓶頸，從而在絕大多數場景下保持了極高的效能。平均的效能影響只有6%。

非同步審計模式對資料庫審計效能有了進一步的提升，對例項的效能損耗更低。不論在正則規則下，還是在普通規則下，效能損耗最高只有3%左右，其能力領先於業界其它的資料庫審計外掛。

四、資料庫審計最佳實踐

理論上可以不對規則條數和語法進行做限制，但必須說明資料庫審計的規則對整體效能消耗會產生一定的影響，為了能夠在相同的規則下降低對資料庫資料庫例項的效能影響，提升資料庫審計能力，在這裡提出以下幾點審計規則的最佳實踐：

1. 規則合併：多個規則之間如果指定的型別相同，應該嘗試合併規則。如A規則審計資料庫db1的select操作，B規則審計資料庫db1的update操作，應當合併成審計db1的select和update操作。

2. 優先原則：對同個例項上不能合併的多個審計規則，優先使用命中率高的特徵。只要有一個規則匹配上就會對該SQL進行審計，其它規則不需要再進行判斷，因此需要把命中率最高的規則放前面優先用。

3. 正則表示式最後匹配：在規則內部，容易否定的規則項優先匹配，精確範圍值優先匹配，然後精確值，然後不包含和包含值，最後正則表示式值。

總結

TXSQL提供了同步和非同步兩種審計模式，內建豐富的審計規則，滿足不同使用者的個性化需求，同時在效能損耗方面把控得十分優秀，一般情況下的記憶體損耗只有3%，遠低於業界其他外掛。

有了TXSQL的審計功能，DBA就能夠實時檢視資料庫活動，對於資料庫的所有操作都會有跡可循，當資料庫遇到疑似風險行為時，及時進行處理，對攻擊行為進行阻斷。同時，藉助TXSQL審計不同的審計模式，豐富的規則和超低的效能損耗，可以讓DBA專注於運維本身，通過對使用者訪問資料庫行為的記錄、分析和彙報，進行事後生成合規報告、事故追根溯源，最終加強內外部資料庫網路行為記錄，提高資料資產安全。

本文由部落格一文多發平臺 OpenWrite 釋出！