前言
在網際網路，雲計算，大資料快速發展的背景下，資料的規模也有了前所未有的增長，資料庫在企業資料中幾乎占有着核心地位。同時SQL注入，敏感操作，不規範使用等問題也一直伴随着資料庫的使用，資料庫安全也一直的資料庫管理的重要工作，主要包括資料庫漏掃，資料庫加密，資料庫防火牆，資料庫脫敏，資料庫安全審計等領域，本文将從資料庫審計角度來介紹資料庫審計的概念及審計資料的采集方案。
資料庫審計是什麼
先來看下百科對資料庫審計的描述：
資料庫審計（簡稱DBAudit）以安全事件為中心，以全面審計和精确審計為基礎，實時記錄網絡上的資料庫活動，對資料庫操作進行細粒度審計的合規性管理，對資料庫遭受到的風險行為進行實時告警。它通過對使用者通路資料庫行為的記錄、分析和彙報，來幫助使用者事後生成合規報告、事故追根溯源，同時通過大資料搜尋技術提供高效查詢審計報告，定位事件原因，以便日後查詢、分析、過濾，實作加強内外部資料庫網絡行為的監控與審計，提高資料資産安全。
從描述可以看出來，資料庫的審計是從安全角度出發，通過記錄資料庫的活動，發現資料庫中潛在或者正在發生的危險，并進行實時的告警，同時還可以生成各類審計報告，定位事件根因。
一個資料庫審計系統的工作流程可以概括為審計資料采集，審計報告生成，監控與告警，事後分析/故障定位等。下文主要調研審計過程的前半段，采集部分的技術。
資料庫要審計什麼
在審計中，經常會用到5W1H分析法，基本可以概括需要資料庫審計的内容：
- Who：資料庫的使用者和通路者，甚至可以關聯到業務系統中使用者
- Where：資料庫的用戶端資訊，服務端資訊，行為從哪個地方來，通路了哪個資料庫。
- When：通路資料庫行為的時間
- What：通路時操作對象是哪個表，哪行資料，傳回了哪些資料，耗時多久。
- How：執行的SQL語句或者其他指令，覆寫DDL，DML，Query，登入等活動。
- Why：通過分析SQL語句，對于有危險的SQL及時分辨出來，了解通路動機。
一些審計的例子：
- 敏感資訊洩露：比如使用者姓名手機号等資訊，通過對SQL的分析，識别傳回結果中的敏感資訊，及時告警。
- 業務人員誤操作：可能在業務系統中使用了不規範的SQL，權限濫用等。
- SQL注入：需要對SQL語句進行注入識别，并且找出是哪些使用者在注入。
資料庫審計采集實作方案
資料庫審計通過對資料庫的運作活動進行采集，然後進行風險分析，生成審計報告，告警通知等，審計資料的擷取有多種方案，接下來主要對審計資料的采集方案進行調研。主要包括插件方案和旁路方案，每種方案各有優劣。總體而言，旁路方案比較适合作為成熟的資料庫審計方案。
插件方案
插件是指在資料庫中增加使用使用審計插件，往往需要依賴資料庫本身的支援，例如對于MySQL為例，MySQL企業版提供了審計插件，社群版沒有直接提供審計插件，插件清單如下：
- MySQL Enterprice Audit Plugin（企業版）
- Percona Audit Plugin（三方插件）
- MariaDB Audit Plugin（三方插件）
- McAfee MySQL Audit Plugin（三方插件）
一些雲廠商内部也內建了三方插件，例如AWS RDS和京東雲RDS都使用了MariaDB Audit Plugin，由此可以看出審計插件還是一定的市場。
優點
- 資料庫原生支援，插件一般比較成熟，格式規整，利于分析。
- 實作簡單，不需要過多的開發量，開箱即用。
挑戰
- 資料庫支援不全，比如社群版MySQL，不提供原生審計插件，需要自行安裝，版本相容性及維護等是一個挑戰
- 由于插件是運作在資料庫伺服器程序中，對資料庫性能會産生一定影響。
- 插件的安裝一般由資料庫管理者安裝，并非審計人員可控，未起到職責分離的作用。
- 每種資料庫的插件需要單獨部署，在對多種資料庫進行審計時，維護成本較高。
除了插件之外，還會有一些資料庫内置方法來進行審計：
- General Log：MySQL中開啟General Log，會對MySQL的所有查詢更新操作進行記錄；可以對General Log進行分析，缺點是資料量通路量大的情況下，General Log會快速膨脹，并對資料庫性能産生影響。
- Binlog+init_connect：通過binlog來記錄對資料庫的操作資訊，但是沒有記錄使用者的登入資訊，借助init_connect可以記錄每個連接配接建立時的資訊，結合兩個資訊可以進行資料庫審計，缺點是binlog不會記錄select資訊，審計内容會産生一部分缺失，不能作為完整的審計方案。
旁路方案
旁路監聽
旁路監聽也可以叫流量鏡像模式，主要是通過抓取應用與資料庫互動過程中網絡包，對網絡包進行解析，可以将解析出SQL語句，執行延時，傳回結果行數等。然後将解析結果發送給審計系統。幾乎所有成熟的資料庫審計方案都支援旁路監聽的部署方式。
旁路監聽模式也是多資料庫審計系統的實作方式，在部署方式上一般部署在資料庫伺服器所在的主機或者交換機上進行流量監聽。
- 不需要在資料庫系統安裝審計插件，對資料庫性能不影響
- 無需與業務系統關聯，不需要提供資料庫的賬号密碼
- 可以支援多種資料庫，審計系統可以進行無損更新
- 對于抓包性能要求較高，在資料庫大流量通路時，丢包率過高會對審計結果産生影響。
- SQL解析能力要求較高，特别是對于長語句，綁定變量等複雜操作語句的解析及審計。
- 高性能的審計資料采集，在資料庫流量較高時，可以及時的采集到審計系統中。
代理模式
代理模式是指在應用系統與資料庫系統之間加一層代理，代理除了完成正常的指令分發和排程之外，還可以在代理上部署審計服務，通過對代理流量的攔截，也可以使用與旁路監聽的類似的實作方式。其優點和挑戰與旁路監聽類似，一些不同點如下：
- 可以進行全流量的攔截和解析。
- 可以有叢集部署的資料庫系統的拓撲結構。
- 對代理性能和穩定性要求極高，如果代理出現問題，會直接影響業務系統。
總結
通過對上述的審計采集方案的描述，可以看出旁路監聽的方式，對于資料庫審計的資料采集是比較理想的方式，由于資料庫系統和審計系統的分開部署模式，對兩者進行了解耦，也讓資料庫系統和審計系統分别的維護和更新更加便捷。
在旁路監聽的基礎上，還可以輔助其他的日志或者業務系統的可觀測性對資料庫審計進行增強，比如将慢日志，錯誤日志，性能資料也可以上傳到審計系統，可以對資料庫有更完整的審計和故障追溯時的排查。
文中主要介紹了資料審計方案的采集部分，對于後續風險識别，告警通知，故障根源追溯等沒有進行過多的介紹，這些也是資料庫審計方案不可缺少的重要組成部分。