NAME

フィルタ名。

FILTER

フィルタ名に関連付けられたフィルタ定義。 定義は JSON 値として格納されます。

USER

アカウントのユーザー名部分。 アカウント user1@localhost の場合、USER 部分は user1 です。

HOST

アカウントのホスト名部分。 アカウント user1@localhost の場合、HOST 部分は localhost です。

FILTERNAME

アカウントに割り当てられたフィルタの名前。 フィルタ名は、アカウントを audit_log_filter テーブルで定義されているフィルタに関連付けます。

audit_log_encryption_password_get([keyring_id])

この関数は、監査ログの暗号化パスワードを MySQL キーリングからフェッチします。このキーリングは有効にする必要があり、有効にしないとエラーが発生します。 どのキーリングプラグインも使用できます。手順については、セクション6.4.4「MySQL キーリング」 を参照してください。

引数を指定しない場合、関数は現在の暗号化パスワードをバイナリ文字列として取得します。 取得する監査ログ暗号化パスワードを指定する引数を指定できます。 引数は、現在のパスワードまたはアーカイブされたパスワードのキーリング ID である必要があります。

監査ログの暗号化の詳細は、監査ログファイルの暗号化 を参照してください。

引数:

keyring_id: MySQL 8.0.17 では、このオプションの引数は取得するパスワードのキーリング ID を示します。 最大許容長は 766 バイトです。 省略すると、現在のパスワードが取得されます。

MySQL 8.0.17 より前では、引数は使用できません。 この関数は、常に現在のパスワードを取得します。

戻り値:

成功のパスワード文字列 (最大 766 バイト)、または NULL と失敗のエラー。

例:

現在のパスワードを取得します:

mysql> SELECT audit_log_encryption_password_get();
+-------------------------------------+
| audit_log_encryption_password_get() |
+-------------------------------------+
| secret                              |
+-------------------------------------+

ID でパスワードを取得するには、パフォーマンススキーマ keyring_keys テーブルをクエリーすることによって、存在する監査ログ鍵リング ID を確認できます:

mysql> SELECT KEY_ID FROM performance_schema.keyring_keys
       WHERE KEY_ID LIKE 'audit_log%'
       ORDER BY KEY_ID;
+-----------------------------+
| KEY_ID                      |
+-----------------------------+
| audit_log-20190415T152248-1 |
| audit_log-20190415T153507-1 |
| audit_log-20190416T125122-1 |
| audit_log-20190416T141608-1 |
+-----------------------------+
mysql> SELECT audit_log_encryption_password_get('audit_log-20190416T125122-1');
+------------------------------------------------------------------+
| audit_log_encryption_password_get('audit_log-20190416T125122-1') |
+------------------------------------------------------------------+
| segreto                                                          |
+------------------------------------------------------------------+

audit_log_encryption_password_set(password)

現在の監査ログ暗号化パスワードを引数に設定し、パスワードを MySQL キーリングに格納します。 MySQL 8.0.19 では、パスワードは utf8mb4 文字列として格納されます。 MySQL 8.0.19 より前は、パスワードはバイナリ形式で格納されます。

暗号化が有効な場合、この関数は、現在のログファイルの名前を変更するログファイルローテーション操作を実行し、パスワードで暗号化された新しいログファイルを開始します。 キーリングを有効にする必要があり、有効にしないとエラーが発生します。 どのキーリングプラグインも使用できます。手順については、セクション6.4.4「MySQL キーリング」 を参照してください。

監査ログの暗号化の詳細は、監査ログファイルの暗号化 を参照してください。

引数:

password: パスワード文字列。 最大許容長は 766 バイトです。

戻り値:

成功の場合は 1、失敗の場合は 0。

例:

mysql> SELECT audit_log_encryption_password_set(password);
+---------------------------------------------+
| audit_log_encryption_password_set(password) |
+---------------------------------------------+
| 1                                           |
+---------------------------------------------+

audit_log_filter_flush()

他のフィルタリング UDF を呼び出すと、操作監査ログのフィルタリングにただちに影響し、監査ログテーブルが更新されます。 かわりに、INSERT、UPDATE および DELETE などのステートメントを使用してこれらのテーブルの内容を直接変更しても、変更はフィルタリングにすぐには影響しません。 変更をフラッシュして操作可能にするには、audit_log_filter_flush() をコールします。

この関数が失敗すると、エラーメッセージが返され、次に audit_log_filter_flush() が正常にコールされるまで監査ログは無効になります。

引数:

なし

戻り値:

操作が成功したかどうかを示す文字列。 OK は成功を示します。 ERROR: message は失敗を示します。

例:

mysql> SELECT audit_log_filter_flush();
+--------------------------+
| audit_log_filter_flush() |
+--------------------------+
| OK                       |
+--------------------------+

audit_log_filter_remove_filter(filter_name)

フィルタ名を指定すると、現在のフィルタセットからフィルタが削除されます。 フィルタが存在しない場合はエラーではありません。

削除されたフィルタがいずれかのユーザーアカウントに割り当てられている場合、それらのユーザーはフィルタ処理を停止します (audit_log_user テーブルから削除されます)。 フィルタリングの終了には、それらのユーザーの現在のセッションが含まれます: フィルタからデタッチされ、ログに記録されなくなります。

引数:

戻り値:

操作が成功したかどうかを示す文字列。 OK は成功を示します。 ERROR: message は失敗を示します。

例:

mysql> SELECT audit_log_filter_remove_filter('SomeFilter');
+----------------------------------------------+
| audit_log_filter_remove_filter('SomeFilter') |
+----------------------------------------------+
| OK                                           |
+----------------------------------------------+

audit_log_filter_remove_user(user_name)

ユーザーアカウント名を指定すると、ユーザーはフィルタに割り当てられなくなります。 ユーザーにフィルタが割り当てられていない場合は、エラーになりません。 ユーザーの現在のセッションのフィルタリングは影響を受けません。 ユーザーの新しい接続は、デフォルトのアカウントフィルタ (存在する場合) を使用してフィルタされ、それ以外の場合はログに記録されません。

名前が % の場合、関数は、明示的にフィルタが割り当てられていないユーザーアカウントに使用されるデフォルトのアカウントフィルタを削除します。

引数:

戻り値:

操作が成功したかどうかを示す文字列。 OK は成功を示します。 ERROR: message は失敗を示します。

例:

mysql> SELECT audit_log_filter_remove_user('user1@localhost');
+-------------------------------------------------+
| audit_log_filter_remove_user('user1@localhost') |
+-------------------------------------------------+
| OK                                              |
+-------------------------------------------------+

audit_log_filter_set_filter(filter_name, definition)

フィルタ名と定義を指定すると、現在のフィルタセットにフィルタが追加されます。 フィルタがすでに存在し、現在のセッションで使用されている場合、それらのセッションはフィルタからデタッチされ、ログに記録されなくなります。 これは、新しいフィルタ定義に以前の ID とは異なる新しいフィルタ ID があるために発生します。

引数:

戻り値:

操作が成功したかどうかを示す文字列。 OK は成功を示します。 ERROR: message は失敗を示します。

例:

mysql> SET @f = '{ "filter": { "log": false } }';
mysql> SELECT audit_log_filter_set_filter('SomeFilter', @f);
+-----------------------------------------------+
| audit_log_filter_set_filter('SomeFilter', @f) |
+-----------------------------------------------+
| OK                                            |
+-----------------------------------------------+

audit_log_filter_set_user(user_name, filter_name)

ユーザーアカウント名とフィルタ名を指定すると、ユーザーにフィルタが割り当てられます。 ユーザーには 1 つのフィルタのみを割り当てることができるため、ユーザーにフィルタがすでに割り当てられている場合は、割り当てが置き換えられます。 ユーザーの現在のセッションのフィルタリングは影響を受けません。 新しい接続は、新しいフィルタを使用してフィルタ処理されます。

特殊なケースとして、% という名前はデフォルトのアカウントを表します。 フィルタは、フィルタが明示的に割り当てられていないユーザーアカウントからの接続に使用されます。

引数:

戻り値:

操作が成功したかどうかを示す文字列。 OK は成功を示します。 ERROR: message は失敗を示します。

例:

mysql> SELECT audit_log_filter_set_user('user1@localhost', 'SomeFilter');
+------------------------------------------------------------+
| audit_log_filter_set_user('user1@localhost', 'SomeFilter') |
+------------------------------------------------------------+
| OK                                                         |
+------------------------------------------------------------+

audit_log_read([arg])

監査ログを読み取り、JSON 文字列の結果を返します。 監査ログ形式が JSON でない場合は、エラーが発生します。

引数または JSON ハッシュ引数を指定しない場合、audit_log_read() は監査ログからイベントを読み取り、監査イベントの配列を含む JSON 文字列を返します。 hash 引数の項目は、あとで説明するように、読み取りの発生方法に影響します。 返される配列内の各要素は、JSON ハッシュとして表されるイベントですが、最後の要素が JSON null 値であり、次のイベントを読み取ることができないことを示す例外があります。

JSON null 値で構成される引数を使用すると、audit_log_read() は現在の読取り順序をクローズします。

監査ログの読取りプロセスの詳細は、セクション6.4.5.6「監査ログファイルの読取り」 を参照してください。

引数:

最後に書き込まれたイベントのブックマークを取得するには、audit_log_read_bookmark() をコールします。

arg: 引数はオプションです。 省略すると、関数は現在の位置からイベントを読み取ります。 引数が存在する場合は、読取り順序をクローズする JSON null 値または JSON ハッシュを指定できます。 ハッシュ引数内では、項目はオプションであり、読取りを開始する位置や読み取るイベントの数など、読取り操作の側面を制御します。 次の項目は重要です (他の項目は無視されます):

開始位置を audit_log_read() に指定するには、start アイテムまたは timestamp アイテムと id アイテムで構成されるブックマークを含むハッシュ引数を渡します。 ハッシュ引数に start アイテムとブックマークの両方が含まれている場合は、エラーが発生します。

ハッシュ引数で開始位置が指定されていない場合、読取りは現在の位置から続行されます。

タイムスタンプ値に時間部分が含まれていない場合は、00:00:00 の時間部分が想定されます。

戻り値:

コールが成功した場合、戻り値は監査イベントの配列を含む JSON 文字列、または読取りシーケンスをクローズする引数として渡された場合は JSON null 値です。 コールが失敗すると、戻り値は NULL になり、エラーが発生します。

例:

mysql> SELECT audit_log_read(audit_log_read_bookmark());
+-----------------------------------------------------------------------+
| audit_log_read(audit_log_read_bookmark())                             |
+-----------------------------------------------------------------------+
| [ {"timestamp":"2020-05-18 22:41:24","id":0,"class":"connection", ... |
+-----------------------------------------------------------------------+
mysql> SELECT audit_log_read('null');
+------------------------+
| audit_log_read('null') |
+------------------------+
| null                   |
+------------------------+

メモ:

MySQL 8.0.19 より前では、文字列の戻り値はバイナリ JSON 文字列です。 このような値を非バイナリ文字列に変換する方法については、セクション6.4.5.6「監査ログファイルの読取り」 を参照してください。

audit_log_read_bookmark()

最後に書き込まれた監査ログイベントのブックマークを表す JSON 文字列を返します。 監査ログ形式が JSON でない場合は、エラーが発生します。

ブックマークは、監査ログ内のイベントの位置を一意に識別する timestamp および id アイテムを含む JSON ハッシュです。 audit_log_read() に渡して、その関数に読取りを開始する位置を示すのに適しています。

監査ログの読取りプロセスの詳細は、セクション6.4.5.6「監査ログファイルの読取り」 を参照してください。

引数:

なし

戻り値:

成功のためのブックマーク、または失敗のための NULL とエラーを含む JSON 文字列。

例:

mysql> SELECT audit_log_read_bookmark();
+-------------------------------------------------+
| audit_log_read_bookmark()                       |
+-------------------------------------------------+
| { "timestamp": "2019-10-03 21:03:44", "id": 0 } |
+-------------------------------------------------+

メモ:

MySQL 8.0.19 より前では、文字列の戻り値はバイナリ JSON 文字列です。 このような値を非バイナリ文字列に変換する方法については、セクション6.4.5.6「監査ログファイルの読取り」 を参照してください。

--audit-log[=value]

このオプションは、サーバーの起動時に audit_log プラグインをロードする方法を制御します。 プラグインが以前に INSTALL PLUGIN に登録されているか、--plugin-load または --plugin-load-add にロードされている場合にのみ使用できます。 セクション6.4.5.2「MySQL Enterprise Audit のインストールまたはアンインストール」を参照してください。

セクション5.6.1「プラグインのインストールおよびアンインストール」で説明したように、オプションの値は、プラグインのロードオプションに指定可能な値のいずれかである必要があります。 たとえば、--audit-log=FORCE_PLUS_PERMANENT は、プラグインをロードし、それがサーバーの実行時に削除されることを回避するようにサーバーに指示します。

audit_log_buffer_size

監査ログプラグインが非同期的にイベントをログに書き込むと、イベントの内容を書き込む前に、バッファーを使用してそれらを格納します。 この変数は、そのバッファーのサイズ (バイト単位) を制御します。 サーバーは、この値を 4096 の倍数に調整します。 このプラグインでは、初期化時に割り当てられ、終了時に削除される単一のバッファーが使用されます。 このプラグインは、ロギングが非同期の場合にのみ、このバッファーを割り当てます。

audit_log_compression

監査ログファイルの圧縮のタイプ。 許可される値は、NONE (圧縮なし、デフォルト) および GZIP (GNU Zip 圧縮) です。 詳細は、監査ログファイルの圧縮を参照してください。

audit_log_connection_policy

監査ログプラグインが接続イベントをそのログファイルに書き込む方法を制御するポリシーです。 次の表は、許可される値を示しています。

audit_log_current_session

現在のセッションで監査ロギングが有効になっているかどうかを示します。 この変数のセッションの値は、読み取り専用です。 セッションの開始時に、audit_log_include_accounts および audit_log_exclude_accounts システム変数の値に基づいて設定されます。 監査ログプラグインはこのセッション値を使用して、そのセッションでイベントを監査するかどうかを決定します。 (グローバル値もありますが、このプラグインでは使用されません。)

audit_log_encryption

監査ログファイルの暗号化のタイプ。 許可される値は、NONE (暗号化なし、デフォルト) および AES (AES-256-CBC 暗号化) です。 詳細は、監査ログファイルの暗号化を参照してください。

audit_log_exclude_accounts

イベントのログが記録されないアカウント。 この値には、NULL またはカンマで区切った 1 つ以上のアカウント名のリストを含む文字列を指定するようにしてください。 詳細は、セクション6.4.5.7「監査ログのフィルタリング」を参照してください。

audit_log_exclude_accounts の変更は、変更後に作成された接続にのみ影響し、既存の接続には影響しません。

audit_log_file

監査ログプラグインがイベントを書き込むファイルのベース名と接尾辞。 ロギング形式に関係なく、デフォルト値は audit.log です。 名前接尾辞をフォーマットに対応させるには、別の接尾辞を選択して、名前を明示的に設定します (たとえば、XML フォーマットの場合は audit.xml、JSON フォーマットの場合は audit.json)。

audit_log_file の値が相対パス名の場合、プラグインはデータディレクトリを基準にした相対パス名を解釈します。 値がフルパス名の場合、プラグインは値をそのまま使用します。 フルパス名は、監査ファイルを別のファイルシステムまたはディレクトリに配置することをお勧めします。 セキュリティ上の理由から、MySQL サーバーおよびログを表示する正当な理由を持つユーザーのみがアクセスできるディレクトリに監査ログファイルを書き込みます。

監査ログプラグインが audit_log_file 値を解釈する方法と、プラグインの初期化および終了時に発生するファイル名変更の規則の詳細は、監査ログファイルのネーミング規則 を参照してください。

監査ログプラグインは、読み取り可能な監査ログファイルを検索する場所として、(audit_log_file の値から決定された) 監査ログファイルを含むディレクトリを使用します。 これらのログファイルと現在のファイルから、プラグインは監査ログのブックマークおよび読み取り関数で使用される対象のもののリストを構築します。 セクション6.4.5.6「監査ログファイルの読取り」を参照してください。

audit_log_filter_id

この変数のセッション値は、現在のセッションの監査フィルタの内部的に保持されている ID を示します。 値 0 は、セッションにフィルタが割り当てられていないことを意味します。

audit_log_flush

この変数が有効になるよう (1 または ON) に設定されている場合、監査ログプラグインはそのログファイルを閉じてから再度開いて、フラッシュします。 (この値は、別のフラッシュを実行するために再度有効にする前に、明示的に無効にする必要がないように、OFF のままになっています。) audit_log_rotate_on_size が 0 である場合を除いて、この変数を有効にしても効果はありません。 詳細は、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。

audit_log_format

監査ログファイルの形式。 許可される値は、OLD (古いスタイルの XML)、NEW (新しいスタイルの XML。デフォルト) および JSON です。 各形式についての詳細は、セクション6.4.5.4「監査ログファイル形式」を参照してください。

audit_log_include_accounts

イベントのログが記録されるアカウント。 この値には、NULL またはカンマで区切った 1 つ以上のアカウント名のリストを含む文字列を指定するようにしてください。 詳細は、セクション6.4.5.7「監査ログのフィルタリング」を参照してください。

audit_log_include_accounts の変更は、変更後に作成された接続にのみ影響し、既存の接続には影響しません。

audit_log_password_history_keep_days

監査ログプラグインは、MySQL 鍵リングに格納されている暗号化パスワードを使用してログファイルの暗号化を実装します (監査ログファイルの暗号化 を参照)。 このプラグインは、パスワードのアーカイブと有効期限 (削除) を含むパスワード履歴も実装します。

監査ログプラグインは、新しい暗号化パスワードを作成するときに、以前のパスワード (存在する場合) をあとで使用するためにアーカイブします。 audit_log_password_history_keep_days 変数は、期限切れのアーカイブ済パスワードの自動削除を制御します。 この値は、アーカイブ監査ログの暗号化パスワードが削除されるまでの日数を示します。 デフォルトの 0 は、パスワードの有効期限を無効にします: パスワードの保存期間は永久的です。

新しい監査ログ暗号化パスワードは、次の状況で作成されます:

いずれの場合も、プラグインは新しいパスワードをキーリングに格納し、それを使用して新しいログファイルを暗号化します。

期限切れの監査ログ暗号化パスワードの削除は、次の状況で発生します:

パスワードの削除が発生すると、audit_log_password_history_keep_days の現在の値によって、削除するパスワードが決まります:

通常、パスワードの有効期限を無効のままにすると (つまり、audit_log_password_history_keep_days の値が 0 の場合)、変数にゼロより大きい値を一時的に割り当てることで、オンデマンドクリーンアップ操作を実行できます。 たとえば、365 日より古いパスワードを期限切れにするには、次のようにします:

SET GLOBAL audit_log_password_history_keep_days = 365;
SET GLOBAL audit_log_password_history_keep_days = 0;

audit_log_password_history_keep_days のランタイム値を設定するには、グローバルシステム変数のランタイム値を設定するために通常必要な SYSTEM_VARIABLES_ADMIN 権限 (または非推奨の SUPER 権限) に加えて、AUDIT_ADMIN 権限が必要です。

audit_log_policy

監査ログプラグインがイベントをそのログファイルに書き込む方法を制御するポリシーです。 次の表は、許可される値を示しています。

audit_log_policy は、サーバーの起動時にのみ設定できます。 実行時は、読み取り専用の変数です。 他の 2 つのシステム変数 (audit_log_connection_policy および audit_log_statement_policy) は、ロギングポリシーをより細かく制御し、起動時または実行時に設定できます。 起動時に他の 2 つの変数ではなく audit_log_policy を使用する場合、サーバーはその値を使用してこれらの変数を設定します。 ポリシーの変数とそれらの相互作用についての詳細は、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。

audit_log_prune_seconds

この変数は、JSON 形式のログファイルでのみサポートされている監査ログファイルのプルーニングに関連します。

audit_log_rotate_on_size が 0 より大きい場合を除き、audit_log_prune_seconds は効果がありません。 true であると仮定した場合:

プルーニングを有効にすると、監査ログファイルの領域管理 で説明されている条件で実行されます。

audit_log_read_buffer_size

監査ログファイルから読み取るバッファサイズ (バイト単位)。 audit_log_read() 関数は、このバイト数以下を読み取ります。 ログファイルの読取りは、JSON ログ形式でのみサポートされます。 詳細は、セクション6.4.5.6「監査ログファイルの読取り」を参照してください。

MySQL 8.0.12 では、この変数のデフォルトは 32KB で、実行時に設定できます。 各クライアントは、audit_log_read() を使用するために audit_log_read_buffer_size のセッション値を適切に設定する必要があります。 MySQL 8.0.12 より前では、audit_log_read_buffer_size のデフォルトは 1MB で、すべてのクライアントに影響し、サーバーの起動時にのみ変更できます。

audit_log_rotate_on_size

audit_log_rotate_on_size が 0 の場合、監査ログプラグインはサイズベースのログファイルの自動ローテーションを実行しません。 代わりに、audit_log_flush 使用して、要求に応じてログを閉じてから再度開きます。 この場合は、フラッシュする前に、ファイルの名前をサーバーの外部に手動で変更します。

audit_log_rotate_on_size が 0 より大きい場合、サイズベースのログファイルの自動ローテーションが発生します。 ログファイルへの書き込みによってそのサイズが audit_log_rotate_on_size 値を超えるたびに、監査ログプラグインは現在のログファイルを閉じて名前を変更し、新しいログファイルを開きます。

audit_log_rotate_on_size を 4096 の倍数でない値に設定すると、最も近い倍数に切り捨てられます。 (このため、4096 未満の値に設定すると 0 に設定され、手動以外は回転は発生しません。)

MySQL 8.0.24 では、audit_log_rotate_on_size は監査ログファイルのプルーニングを有効にできるかどうかも制御します:

監査ログファイルのローテーションおよびプルーニングの詳細は、監査ログファイルの領域管理 を参照してください。

audit_log_statement_policy

監査ログプラグインがステートメントイベントをそのログファイルに書き込む方法を制御するポリシーです。 次の表は、許可される値を示しています。

audit_log_strategy

監査ログプラグインで使用されるロギング方法。 次の戦略値を使用できます:

Audit_log_current_size

現在の監査ログファイルのサイズ。 この値は、イベントがログに書き込まれると増加し、ログがローテーションされると 0 にリセットされます。

Audit_log_event_max_drop_size

パフォーマンスロギングモードで破棄された最大イベントのサイズ。 ロギングモードについては、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。

Audit_log_events

フィルタリングのポリシーに基づいてログに書き込まれたかどうかに関係なく、監査ログプラグインによって処理されたイベントの数 (セクション6.4.5.5「監査ロギング特性の構成」を参照してください)。

Audit_log_events_filtered

フィルタリングのポリシーに基づいて、監査ログプラグインによってフィルタリングされた (ログに書き込まれなかった) イベントの数 (セクション6.4.5.5「監査ロギング特性の構成」を参照してください)。

Audit_log_events_lost

イベントが使用可能な監査ログバッファー領域よりも大きかったために、パフォーマンスロギングモードで失われたイベントの数。 この値は、audit_log_buffer_size を設定して、パフォーマンスモード用にバッファーのサイズを調整する方法を評価する際に役立つことがあります。 ロギングモードについては、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。

Audit_log_events_written

監査ログに書き込まれたイベントの数。

Audit_log_total_size

すべての監査ログファイルに書き込まれたイベントの合計サイズ。 Audit_log_current_size とは異なり、Audit_log_total_size の値は、ログがローテーションされたときにも増加します。

Audit_log_write_waits

非同期ロギングモードでイベントが監査ログバッファー内の領域を待機する必要があった回数。 ロギングモードについては、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。