6.4.5.7 監査ログのフィルタリング

注記

このセクションでは、監査ログプラグインおよび付随する監査テーブルと UDF がインストールされている場合の監査ログのフィルタリングの動作について説明します。プラグインがインストールされているが、付随する監査テーブルおよび UDF がインストールされていない場合、プラグインはレガシーフィルタリングモードで動作します (セクション6.4.5.9「レガシーモード監査ログのフィルタリング」を参照)。レガシーモードは、MySQL 5.7.13 より前、つまりルールベースのフィルタリングの導入前のフィルタリング動作です。

監査ログプラグインには、監査対象イベントのロギングをフィルタリングして制御する機能があります:

監査イベントは、次の特性を使用してフィルタできます:
- ユーザーアカウント
- 監査イベントクラス
- 監査イベントサブクラス
- 操作ステータスや実行された SQL ステートメントを示すイベントフィールドなどのイベントフィールドの値
監査フィルタリングはルールベースです:
- フィルタ定義によって、一連の監査ルールが作成されます。定義は、前述の特性に基づいてロギングのイベントを含めるか除外するように構成できます。
- フィルタルールには、イベントロギングの既存の機能に加えて、適格なイベントの実行をブロック (中断) する機能があります。
- 複数のフィルタを定義でき、任意の数のユーザーアカウントに任意のフィルタを割り当てることができます。
- フィルタが明示的に割り当てられていないユーザーアカウントで使用するデフォルトフィルタを定義できます。
監査フィルタは、ユーザー定義関数 (UDF) に基づく SQL インタフェースを使用して定義、表示および変更できます。
監査フィルタ定義は、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 インタフェースを実装する UDF の概要を示します:

audit_log_filter_set_filter(): フィルタの定義
audit_log_filter_remove_filter(): フィルタの削除
audit_log_filter_set_user(): ユーザーアカウントのフィルタリングの開始
audit_log_filter_remove_user(): ユーザーアカウントのフィルタリングの停止
audit_log_filter_flush(): フィルタテーブルへの手動変更をフラッシュして、進行中のフィルタリングに影響を与えます

使用例およびフィルタリング関数の詳細は、監査ログフィルタリング関数の使用および監査ログ関数を参照してください。

監査ログのフィルタリング関数には、次の制約があります:

フィルタリング関数を使用するには、audit_log プラグインを有効にする必要があります。有効にしないと、エラーが発生します。また、監査テーブルが存在する必要があり、存在しない場合はエラーが発生します。 audit_log プラグインとそれに付随する UDF およびテーブルをインストールするには、セクション6.4.5.2「MySQL Enterprise Audit のインストールまたはアンインストール」を参照してください。
フィルタリング機能を使用するには、ユーザーが SUPER 権限を持っている必要があり、持っていない場合はエラーが発生します。 SUPER 権限をユーザーアカウントに付与するには、次のステートメントを使用します:
```
GRANT SUPER ON *.* TO user;
```
または、ユーザーに特定のフィルタリング関数へのアクセスを許可しながら SUPER 権限を付与しないようにする場合は、「「ラッパー」」ストアドプログラムを定義できます。この手法については、汎用キーリング関数の使用での UDF のキー設定のコンテキストで説明されています。UDF のフィルタリングでの使用に適応できます。
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.'
```
レガシーモードでは、フィルタリングはイベントアカウントまたはステータスにのみ実行できます。詳細は、セクション6.4.5.9「レガシーモード監査ログのフィルタリング」を参照してください。

監査ログフィルタリング関数の使用

監査ログフィルタリング関数の使用

監査ログのユーザー定義関数 (UDF) を使用する前に、セクション6.4.5.2「MySQL Enterprise Audit のインストールまたはアンインストール」の指示に従ってインストールします。これらの関数を使用するには、SUPER 権限が必要です。

監査ログのフィルタリング機能を使用すると、フィルタ定義を作成、変更および削除し、ユーザーアカウントにフィルタを割り当てるためのインタフェースを提供することで、フィルタリングを制御できます。

フィルタ定義は JSON 値です。 MySQL での JSON データの使用の詳細は、セクション11.5「JSON データ型」を参照してください。このセクションでは、単純なフィルタ定義をいくつか示します。フィルタ定義の詳細は、セクション6.4.5.8「監査ログフィルタ定義の書込み」を参照してください。

接続が到着すると、監査ログプラグインは、現在のフィルタ割り当てでユーザーアカウント名を検索して、新しいセッションに使用するフィルタを決定します:

フィルタがユーザーに割り当てられている場合、監査ログはそのフィルタを使用します。
それ以外の場合、ユーザー固有のフィルタ割当てが存在せず、デフォルトアカウント (%) にフィルタが割り当てられていると、監査ログではデフォルトフィルタが使用されます。
それ以外の場合、監査ログはセッションから処理する監査イベントを選択しません。

セッション中に変更ユーザー操作が発生した場合 (mysql_change_user() を参照)、セッションのフィルタ割当ては同じルールを使用して更新されますが、新規ユーザーの場合です。

デフォルトでは、アカウントにフィルタが割り当てられていないため、どのアカウントに対しても監査可能なイベントの処理は行われません。

かわりに、デフォルトで接続関連のアクティビティのみをログに記録するとします (たとえば、接続、変更ユーザーおよび切断イベントは表示しますが、接続中にユーザーが実行する SQL ステートメントは表示しません)。これを実現するには、connection クラスのイベントのみのロギングを有効にするフィルタ (ここでは log_conn_events という名前) を定義し、そのフィルタを % アカウント名で表されるデフォルトアカウントに割り当てます:

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');

フィルタを削除すると、そのフィルタが割り当てられているユーザー (それらのユーザーの現在のセッションを含む) からもフィルタの割当てが解除されます。

ここで説明したフィルタ UDF は、監査フィルタリングにすぐに影響し、フィルタおよびユーザーアカウントを格納する mysql システムデータベースの監査ログテーブルを更新します (監査ログテーブルを参照)。 INSERT、UPDATE、DELETE などのステートメントを使用して監査ログテーブルを直接変更することもできますが、このような変更はフィルタリングにすぐには影響しません。変更をフラッシュして操作可能にするには、audit_log_filter_flush() をコールします:

SELECT audit_log_filter_flush();

警告

audit_log_filter_flush() は、すべてのフィルタを強制的にリロードするために、監査テーブルを直接変更した後にのみ使用してください。それ以外の場合は、この関数を使用しないでください。実際には、UNINSTALL PLUGIN と INSTALL PLUGIN を使用した audit_log プラグインのアンロードおよびリロードの簡略化されたバージョンです。

audit_log_filter_flush() は、現在のすべてのセッションに影響を与え、以前のフィルタからデタッチします。現在のセッションは、切断して再接続するか、ユーザー変更操作を実行しないかぎり、ログに記録されなくなります。

フィルタが現在のセッションに割り当てられているかどうかを確認するには、読取り専用 audit_log_filter_id システム変数のセッション値を確認します。値が 0 の場合、フィルタは割り当てられません。ゼロ以外の値は、割り当てられたフィルタの内部的に保持されている ID を示します:

mysql> SELECT @@audit_log_filter_id;
+-----------------------+
| @@audit_log_filter_id |
+-----------------------+
|                     2 |
+-----------------------+