為了使稽核日誌篩選能如本文所述般運作,必須安裝稽核日誌外掛程式和隨附的稽核表格及函數。如果安裝外掛程式時,沒有安裝規則式篩選所需的隨附稽核表格及函數,則外掛程式會在舊版篩選模式中運作,詳述於章節 8.4.5.10,「舊版模式稽核日誌篩選」。舊版模式 (已棄用) 是 MySQL 5.7.13 之前的篩選行為;亦即,在引入規則式篩選之前。
稽核日誌外掛程式具有透過篩選來控制稽核事件記錄的功能
可以使用以下特性來篩選稽核事件
使用者帳戶
稽核事件類別
稽核事件子類別
稽核事件欄位,例如指示操作狀態或執行的 SQL 陳述式之欄位
稽核篩選是規則式的
篩選定義會建立一組稽核規則。可以設定定義,以便根據剛才描述的特性,包含或排除用於記錄的事件。
篩選規則除了現有的事件記錄功能之外,還可以封鎖 (中止) 符合條件的事件執行。
可以定義多個篩選器,並且任何指定的篩選器都可以指派給任意數量的使用者帳戶。
可以定義一個預設篩選器,以便用於沒有明確指派篩選器的任何使用者帳戶。
稽核日誌篩選用於實作元件服務。若要取得該版本中可用的選用查詢統計資訊,您可以使用服務元件將它們設定為篩選器,該服務元件會實作將統計資訊寫入稽核日誌的服務。有關設定此篩選器的說明,請參閱新增離群值偵測的查詢統計資訊。
有關撰寫篩選規則的資訊,請參閱第 8.4.5.8 節「撰寫稽核日誌篩選定義」。
可以使用基於函式呼叫的 SQL 介面來定義和修改稽核篩選器。若要顯示稽核篩選器,請查詢
mysql.audit_log_filter
表格。稽核篩選器定義儲存在
mysql
系統資料庫的表格中。在給定的工作階段中,唯讀的
audit_log_filter_id
系統變數值會指示是否有篩選器指派給該工作階段。
依預設,基於規則的稽核日誌篩選不會記錄任何使用者的任何稽核事件。若要記錄所有使用者的所有稽核事件,請使用以下陳述式,這些陳述式會建立一個簡單的篩選器來啟用記錄並將其指派給預設帳戶。
SELECT audit_log_filter_set_filter('log_all', '{ "filter": { "log": true } }');
SELECT audit_log_filter_set_user('%', 'log_all');
指派給 %
的篩選器用於來自任何沒有明確指派篩選器的帳戶的連線(最初對於所有帳戶都是如此)。
如先前所述,稽核篩選控制的 SQL 介面是以函式為基礎。以下清單簡要總結了這些函式。
audit_log_filter_set_user()
:開始篩選使用者帳戶。audit_log_filter_remove_user()
:停止篩選使用者帳戶。audit_log_filter_flush()
:刷新對篩選器表格的手動變更,以影響進行中的篩選。
有關篩選函式的使用範例和完整詳細資訊,請參閱使用稽核日誌篩選函式和稽核日誌函式。
稽核日誌篩選函式受限於以下限制。
若要使用任何篩選函式,必須啟用
audit_log
外掛程式,否則會發生錯誤。此外,稽核表格必須存在,否則會發生錯誤。若要安裝audit_log
外掛程式及其隨附的函式和表格,請參閱第 8.4.5.2 節「安裝或解除安裝 MySQL Enterprise Audit」。若要使用任何篩選函式,使用者必須擁有
AUDIT_ADMIN
SUPER
權限,否則會發生錯誤。若要將其中一個權限授予使用者帳戶,請使用此陳述式:GRANT privilege ON *.* TO user;
或者,如果您希望避免授予
AUDIT_ADMIN
或SUPER
權限,同時仍允許使用者存取特定的篩選函式,則可以定義 「包裝函式」 儲存的程式。此技術在金鑰環函式的內容中描述,請參閱使用通用金鑰環函式;它可以適用於篩選函式。如果已安裝
audit_log
外掛程式,但未建立隨附的稽核表格和函式,則該外掛程式會以舊版模式運作。外掛程式會在伺服器啟動時將這些訊息寫入錯誤日誌:[Warning] Plugin audit_log reported: 'Failed to open the audit log filter tables.' [Warning] Plugin audit_log reported: 'Audit Log plugin supports a filtering, which has not been installed yet. Audit Log plugin will run in the legacy mode, which will be disabled in the next release.'
在已淘汰的舊版模式中,篩選只能根據事件帳戶或狀態進行。有關詳細資訊,請參閱第 8.4.5.10 節「舊版模式稽核日誌篩選」。
理論上,擁有足夠權限的使用者可能會錯誤地在稽核日誌篩選器中建立 「中止」 項目,以阻止自己和其他管理員存取系統。
AUDIT_ABORT_EXEMPT
權限可用於允許使用者帳戶的查詢始終執行,即使 「中止」 項目會阻止它們。因此,具有此權限的帳戶可用於在稽核錯誤組態後重新取得對系統的存取權。查詢仍然記錄在稽核日誌中,但由於權限,它被允許而不是被拒絕。以
SYSTEM_USER
權限建立的帳戶在建立時會自動指派AUDIT_ABORT_EXEMPT
權限。當您執行升級程序時,如果沒有現有帳戶被指派該權限,則AUDIT_ABORT_EXEMPT
權限也會指派給具有SYSTEM_USER
權限的現有帳戶。
在使用稽核日誌函式之前,請依照第 8.4.5.2 節「安裝或解除安裝 MySQL Enterprise Audit」中提供的指示安裝它們。使用其中任何函式都需要 AUDIT_ADMIN
或 SUPER
權限。
稽核日誌篩選函式透過提供介面來建立、修改和移除篩選器定義,並將篩選器指派給使用者帳戶,來啟用篩選控制。
篩選器定義是 JSON
值。有關在 MySQL 中使用 JSON
資料的資訊,請參閱第 13.5 節「JSON 資料類型」。本節顯示一些簡單的篩選器定義。有關篩選器定義的更多資訊,請參閱第 8.4.5.8 節「撰寫稽核日誌篩選定義」。
當連線到達時,稽核日誌外掛程式會透過在目前的篩選器指派中搜尋使用者帳戶名稱來決定新工作階段要使用的篩選器。
如果篩選器已指派給使用者,稽核日誌會使用該篩選器。
否則,如果沒有使用者特定的篩選器指派,但有篩選器指派給預設帳戶 (
%
),則稽核日誌會使用預設篩選器。否則,稽核日誌不會選取工作階段中的任何稽核事件進行處理。
如果工作階段期間發生變更使用者操作 (請參閱 mysql_change_user()),則會使用相同的規則更新工作階段的篩選器指派,但適用於新使用者。
依預設,沒有任何帳戶被指派篩選器,因此任何帳戶都不會發生任何稽核事件處理。
假設您想要將預設值變更為僅記錄與連線相關的活動(例如,查看連線、變更使用者和中斷連線事件,但不查看使用者在連線時執行的 SQL 陳述式)。為了達成此目的,請定義一個篩選器(此處顯示的名稱為 log_conn_events
),該篩選器僅啟用 connection
類別中事件的記錄,並將該篩選器指派給以 %
帳戶名稱表示的預設帳戶。
SET @f = '{ "filter": { "class": { "name": "connection" } } }';
SELECT audit_log_filter_set_filter('log_conn_events', @f);
SELECT audit_log_filter_set_user('%', 'log_conn_events');
現在,稽核日誌會對來自任何沒有明確定義篩選器的帳戶的連線使用此預設帳戶篩選器。
若要明確地將篩選器指派給特定使用者帳戶或多個帳戶,請定義篩選器,然後將其指派給相關的帳戶。
SELECT audit_log_filter_set_filter('log_all', '{ "filter": { "log": true } }');
SELECT audit_log_filter_set_user('user1@localhost', 'log_all');
SELECT audit_log_filter_set_user('user2@localhost', 'log_all');
現在,已為 user1@localhost
和 user2@localhost
啟用完整記錄。來自其他帳戶的連線會繼續使用預設帳戶篩選器進行篩選。
若要取消使用者帳戶與其目前篩選器的關聯,請取消指派篩選器或指派不同的篩選器。
若要取消指派使用者帳戶的篩選器:
SELECT audit_log_filter_remove_user('user1@localhost');
該帳戶目前工作階段的篩選不受影響。來自該帳戶的後續連線會使用預設帳戶篩選器進行篩選(如果有的話),否則不會記錄。
若要將不同的篩選器指派給使用者帳戶:
SELECT audit_log_filter_set_filter('log_nothing', '{ "filter": { "log": false } }'); SELECT audit_log_filter_set_user('user1@localhost', 'log_nothing');
該帳戶目前工作階段的篩選不受影響。來自該帳戶的後續連線會使用新的篩選器進行篩選。對於此處顯示的篩選器,這表示
user1@localhost
的新連線沒有記錄。
對於稽核日誌篩選,使用者名稱和主機名稱的比較區分大小寫。這與權限檢查的比較不同,對於權限檢查,主機名稱的比較不區分大小寫。
若要移除篩選器,請執行此操作:
SELECT audit_log_filter_remove_filter('log_nothing');
移除篩選器也會將其從指派給它的任何使用者中取消指派,包括這些使用者的任何目前工作階段。
剛才描述的篩選函式會立即影響稽核篩選,並更新 mysql
系統資料庫中儲存篩選器和使用者帳戶的稽核日誌表格 (請參閱稽核日誌表格)。也可以使用 INSERT
、UPDATE
和 DELETE
等陳述式直接修改稽核日誌表格,但此類變更不會立即影響篩選。若要刷新您的變更並使其運作,請呼叫 audit_log_filter_flush()
。
SELECT audit_log_filter_flush();
只有在直接修改稽核資料表後,才應使用 audit_log_filter_flush()
,以強制重新載入所有篩選器。否則,應避免使用此函式。實際上,它是一個簡化版的卸載和重新載入 audit_log
外掛程式的操作,如同使用 UNINSTALL PLUGIN
加上 INSTALL PLUGIN
。
audit_log_filter_flush()
會影響所有當前的工作階段,並將它們與先前的篩選器分離。除非當前工作階段斷開連線並重新連線,或者執行變更使用者的操作,否則它們將不再被記錄。
若要判斷篩選器是否已指派給當前工作階段,請檢查唯讀系統變數 audit_log_filter_id
的工作階段值。如果值為 0,則表示未指派任何篩選器。非零值表示已指派篩選器的內部維護 ID。
mysql> SELECT @@audit_log_filter_id;
+-----------------------+
| @@audit_log_filter_id |
+-----------------------+
| 2 |
+-----------------------+