MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
次の各セクションでは、MySQL Enterprise Audit 要素のリファレンスを示します:
監査ログのテーブルおよび関数をインストールするには、セクション6.4.5.2「MySQL Enterprise Audit のインストールまたはアンインストール」 で提供されている手順を使用します。 これらのオブジェクトがインストールされていないかぎり、audit_log
プラグインはレガシーモードで動作します。 セクション6.4.5.9「レガシーモード監査ログのフィルタリング」を参照してください。
MySQL Enterprise Audit では、フィルタおよびユーザーアカウントデータの永続的な格納に mysql
システムデータベースのテーブルが使用されます。 テーブルにアクセスできるのは、そのデータベースに対する権限を持つユーザーのみです。 これらのテーブルは、InnoDB
ストレージエンジンを使用します。
これらのテーブルがない場合、audit_log
プラグインはレガシーモードで動作します。 セクション6.4.5.9「レガシーモード監査ログのフィルタリング」を参照してください。
audit_log_filter
テーブルには、フィルタ定義が格納されます。 テーブルには次のカラムがあります。
NAME
フィルタ名。
FILTER
フィルタ名に関連付けられたフィルタ定義。 定義は JSON
値として格納されます。
audit_log_user
テーブルには、ユーザーアカウント情報が格納されます。 テーブルには次のカラムがあります。
USER
アカウントのユーザー名部分。 アカウント user1@localhost
の場合、USER
部分は user1
です。
HOST
アカウントのホスト名部分。 アカウント user1@localhost
の場合、HOST
部分は localhost
です。
FILTERNAME
アカウントに割り当てられたフィルタの名前。 フィルタ名は、アカウントを audit_log_filter
テーブルで定義されているフィルタに関連付けます。
このセクションでは、監査ログのユーザー定義関数 (UDF) ごとに、その目的、コール順序および戻り値について説明します。 これらの UDF を起動できる条件の詳細は、セクション6.4.5.7「監査ログのフィルタリング」 を参照してください。
各監査ログ UDF は、操作が成功したかどうかを示す文字列を返します。 OK
は成功を示します。 ERROR:
は失敗を示します。
message
MySQL 8.0.19 の時点では、監査ログ UDF は文字列引数を utf8mb4
に変換し、文字列戻り値は utf8mb4
文字列です。 MySQL 8.0.19 より前では、監査ログ UDF は文字列引数をバイナリ文字列として扱い (大文字と小文字を区別しない)、文字列の戻り値はバイナリ文字列です。
次の監査ログ UDF を使用できます:
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(
+---------------------------------------------+ | audit_log_encryption_password_set(password
);password
) | +---------------------------------------------+ | 1 | +---------------------------------------------+
他のフィルタリング UDF を呼び出すと、操作監査ログのフィルタリングにただちに影響し、監査ログテーブルが更新されます。 かわりに、INSERT
、UPDATE
および DELETE
などのステートメントを使用してこれらのテーブルの内容を直接変更しても、変更はフィルタリングにすぐには影響しません。 変更をフラッシュして操作可能にするには、audit_log_filter_flush()
をコールします。
audit_log_filter_flush()
は、すべてのフィルタを強制的にリロードするために、監査テーブルを直接変更した後にのみ使用してください。 それ以外の場合は、この関数を使用しないでください。 実際には、UNINSTALL PLUGIN
と INSTALL PLUGIN
を使用した audit_log
プラグインのアンロードおよびリロードの簡略化されたバージョンです。
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
テーブルから削除されます)。 フィルタリングの終了には、それらのユーザーの現在のセッションが含まれます: フィルタからデタッチされ、ログに記録されなくなります。
引数:
filter_name
: フィルタ名を指定する文字列。
戻り値:
操作が成功したかどうかを示す文字列。 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
)
ユーザーアカウント名を指定すると、ユーザーはフィルタに割り当てられなくなります。 ユーザーにフィルタが割り当てられていない場合は、エラーになりません。 ユーザーの現在のセッションのフィルタリングは影響を受けません。 ユーザーの新しい接続は、デフォルトのアカウントフィルタ (存在する場合) を使用してフィルタされ、それ以外の場合はログに記録されません。
名前が %
の場合、関数は、明示的にフィルタが割り当てられていないユーザーアカウントに使用されるデフォルトのアカウントフィルタを削除します。
引数:
user_name
:
形式の文字列としてのユーザーアカウント名、またはデフォルトアカウントを表す user_name
@host_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 があるために発生します。
引数:
filter_name
: フィルタ名を指定する文字列。
definition
: フィルタ定義を指定する JSON
値。
戻り値:
操作が成功したかどうかを示す文字列。 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 つのフィルタのみを割り当てることができるため、ユーザーにフィルタがすでに割り当てられている場合は、割り当てが置き換えられます。 ユーザーの現在のセッションのフィルタリングは影響を受けません。 新しい接続は、新しいフィルタを使用してフィルタ処理されます。
特殊なケースとして、%
という名前はデフォルトのアカウントを表します。 フィルタは、フィルタが明示的に割り当てられていないユーザーアカウントからの接続に使用されます。
引数:
user_name
:
形式の文字列としてのユーザーアカウント名、またはデフォルトアカウントを表す user_name
@host_name
%
。
filter_name
: フィルタ名を指定する文字列。
戻り値:
操作が成功したかどうかを示す文字列。 OK
は成功を示します。 ERROR:
は失敗を示します。
message
例:
mysql> SELECT audit_log_filter_set_user('user1@localhost', 'SomeFilter');
+------------------------------------------------------------+
| audit_log_filter_set_user('user1@localhost', 'SomeFilter') |
+------------------------------------------------------------+
| OK |
+------------------------------------------------------------+
監査ログを読み取り、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
ハッシュを指定できます。 ハッシュ引数内では、項目はオプションであり、読取りを開始する位置や読み取るイベントの数など、読取り操作の側面を制御します。 次の項目は重要です (他の項目は無視されます):
start
: 最初に読み取るイベントの監査ログ内の位置。 位置はタイムスタンプとして指定され、タイムスタンプ値以降に発生する最初のイベントから読取りが開始されます。 start
アイテムの形式は次のとおりです。ここで、value
はリテラルのタイムスタンプ値です:
"start": { "timestamp": "value
" }
start
品目は、MySQL 8.0.22 で許可されています。
timestamp
, id
: 最初に読み取るイベントの監査ログ内の位置。 timestamp
アイテムと id
アイテムは、特定のイベントを一意に識別するブックマークで構成されます。 audit_log_read()
引数にいずれかの項目が含まれている場合、位置を完全に指定するには両方を含める必要があります。そうしないと、エラーが発生します。
max_array_length
: ログから読み取るイベントの最大数。 この項目を省略した場合、デフォルトでは、ログの最後まで、または読取りバッファがいっぱいになるまで (いずれか早い方まで) 読み取られます。
開始位置を 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「監査ログファイルの読取り」 を参照してください。
最後に書き込まれた監査ログイベントのブックマークを表す 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「監査ログファイルの読取り」 を参照してください。
表 6.37 「監査ログオプションおよび変数リファレンス」
このセクションでは、MySQL Enterprise Audit の操作を構成するコマンドオプションおよびシステム変数について説明します。 起動時に指定された値が正しくない場合、audit_log
プラグインが正しく初期化されず、サーバーがロードしない可能性があります。 この場合、サーバーは他の監査ログ設定を認識しないため、エラーメッセージを生成することもあります。
監査ログプラグインのアクティブ化を構成するには、このオプションを使用します:
コマンド行形式 | --audit-log[=value] |
---|---|
型 | 列挙 |
デフォルト値 | ON |
有効な値 |
|
このオプションは、サーバーの起動時に audit_log
プラグインをロードする方法を制御します。 プラグインが以前に INSTALL PLUGIN
に登録されているか、--plugin-load
または --plugin-load-add
にロードされている場合にのみ使用できます。 セクション6.4.5.2「MySQL Enterprise Audit のインストールまたはアンインストール」を参照してください。
セクション5.6.1「プラグインのインストールおよびアンインストール」で説明したように、オプションの値は、プラグインのロードオプションに指定可能な値のいずれかである必要があります。 たとえば、--audit-log=FORCE_PLUS_PERMANENT
は、プラグインをロードし、それがサーバーの実行時に削除されることを回避するようにサーバーに指示します。
監査ログプラグインが有効になっている場合、ロギングの制御を許可するいくつかのシステム変数が公開されます:
mysql> SHOW VARIABLES LIKE 'audit_log%';
+-----------------------------+--------------+
| Variable_name | Value |
+-----------------------------+--------------+
| audit_log_buffer_size | 1048576 |
| audit_log_connection_policy | ALL |
| audit_log_current_session | OFF |
| audit_log_exclude_accounts | |
| audit_log_file | audit.log |
| audit_log_filter_id | 0 |
| audit_log_flush | OFF |
| audit_log_format | NEW |
| audit_log_include_accounts | |
| audit_log_policy | ALL |
| audit_log_rotate_on_size | 0 |
| audit_log_statement_policy | ALL |
| audit_log_strategy | ASYNCHRONOUS |
+-----------------------------+--------------+
これらの変数のいずれも、サーバーの起動時 (一部は実行時) に設定できます。 レガシーモードの監査ログフィルタリングでのみ使用可能なものは、このように記載されています。
コマンド行形式 | --audit-log-buffer-size=# |
---|---|
システム変数 | audit_log_buffer_size |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 1048576 |
最小値 | 4096 |
最大値 (64 ビットプラットフォーム) | 18446744073709547520 |
最大値 (32 ビットプラットフォーム) | 4294967295 |
監査ログプラグインが非同期的にイベントをログに書き込むと、イベントの内容を書き込む前に、バッファーを使用してそれらを格納します。 この変数は、そのバッファーのサイズ (バイト単位) を制御します。 サーバーは、この値を 4096 の倍数に調整します。 このプラグインでは、初期化時に割り当てられ、終了時に削除される単一のバッファーが使用されます。 このプラグインは、ロギングが非同期の場合にのみ、このバッファーを割り当てます。
コマンド行形式 | --audit-log-compression=value |
---|---|
システム変数 | audit_log_compression |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | NONE |
有効な値 |
|
監査ログファイルの圧縮のタイプ。 許可される値は、NONE
(圧縮なし、デフォルト) および GZIP
(GNU Zip 圧縮) です。 詳細は、監査ログファイルの圧縮を参照してください。
コマンド行形式 | --audit-log-connection-policy=value |
---|---|
システム変数 | audit_log_connection_policy |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | ALL |
有効な値 |
|
この変数は、レガシーモードの監査ログフィルタリングにのみ適用されます (セクション6.4.5.9「レガシーモード監査ログのフィルタリング」 を参照)。
監査ログプラグインが接続イベントをそのログファイルに書き込む方法を制御するポリシーです。 次の表は、許可される値を示しています。
値 | 説明 |
---|---|
ALL |
接続イベントのログをすべて記録します |
ERRORS |
失敗した接続イベントのログのみを記録します |
NONE |
接続イベントのログを記録しません |
セクション6.4.5.5「監査ロギング特性の構成」で説明したように、audit_log_policy
も指定されている場合は、サーバーの起動時に、audit_log_connection_policy
に明示的に指定された値がオーバーライドされる可能性があります。
システム変数 | audit_log_current_session |
---|---|
スコープ | グローバル、セッション |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | depends on filtering policy |
現在のセッションで監査ロギングが有効になっているかどうかを示します。 この変数のセッションの値は、読み取り専用です。 セッションの開始時に、audit_log_include_accounts
および audit_log_exclude_accounts
システム変数の値に基づいて設定されます。 監査ログプラグインはこのセッション値を使用して、そのセッションでイベントを監査するかどうかを決定します。 (グローバル値もありますが、このプラグインでは使用されません。)
コマンド行形式 | --audit-log-encryption=value |
---|---|
システム変数 | audit_log_encryption |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | NONE |
有効な値 |
|
監査ログファイルの暗号化のタイプ。 許可される値は、NONE
(暗号化なし、デフォルト) および AES
(AES-256-CBC 暗号化) です。 詳細は、監査ログファイルの暗号化を参照してください。
コマンド行形式 | --audit-log-exclude-accounts=value |
---|---|
システム変数 | audit_log_exclude_accounts |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 文字列 |
デフォルト値 | NULL |
この変数は、レガシーモードの監査ログフィルタリングにのみ適用されます (セクション6.4.5.9「レガシーモード監査ログのフィルタリング」 を参照)。
イベントのログが記録されないアカウント。 この値には、NULL
またはカンマで区切った 1 つ以上のアカウント名のリストを含む文字列を指定するようにしてください。 詳細は、セクション6.4.5.7「監査ログのフィルタリング」を参照してください。
audit_log_exclude_accounts
の変更は、変更後に作成された接続にのみ影響し、既存の接続には影響しません。
コマンド行形式 | --audit-log-file=file_name |
---|---|
システム変数 | audit_log_file |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | ファイル名 |
デフォルト値 | audit.log |
監査ログプラグインがイベントを書き込むファイルのベース名と接尾辞。 ロギング形式に関係なく、デフォルト値は 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 |
---|---|
スコープ | グローバル、セッション |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
この変数のセッション値は、現在のセッションの監査フィルタの内部的に保持されている ID を示します。 値 0 は、セッションにフィルタが割り当てられていないことを意味します。
システム変数 | audit_log_flush |
---|---|
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Boolean |
デフォルト値 | OFF |
この変数が有効になるよう (1 または ON
) に設定されている場合、監査ログプラグインはそのログファイルを閉じてから再度開いて、フラッシュします。 (この値は、別のフラッシュを実行するために再度有効にする前に、明示的に無効にする必要がないように、OFF
のままになっています。) audit_log_rotate_on_size
が 0 である場合を除いて、この変数を有効にしても効果はありません。 詳細は、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。
コマンド行形式 | --audit-log-format=value |
---|---|
システム変数 | audit_log_format |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | NEW |
有効な値 |
|
監査ログファイルの形式。 許可される値は、OLD
(古いスタイルの XML)、NEW
(新しいスタイルの XML。デフォルト) および JSON
です。 各形式についての詳細は、セクション6.4.5.4「監査ログファイル形式」を参照してください。
ログ形式を変更する際に考慮する問題の詳細は、監査ログファイル形式の選択 を参照してください。
コマンド行形式 | --audit-log-include-accounts=value |
---|---|
システム変数 | audit_log_include_accounts |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 文字列 |
デフォルト値 | NULL |
この変数は、レガシーモードの監査ログフィルタリングにのみ適用されます (セクション6.4.5.9「レガシーモード監査ログのフィルタリング」 を参照)。
イベントのログが記録されるアカウント。 この値には、NULL
またはカンマで区切った 1 つ以上のアカウント名のリストを含む文字列を指定するようにしてください。 詳細は、セクション6.4.5.7「監査ログのフィルタリング」を参照してください。
audit_log_include_accounts
の変更は、変更後に作成された接続にのみ影響し、既存の接続には影響しません。
audit_log_password_history_keep_days
コマンド行形式 | --audit-log-password-history-keep-days=# |
---|---|
導入 | 8.0.17 |
システム変数 | audit_log_password_history_keep_days |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 0 |
最小値 | 0 |
最大値 | 4294967295 |
監査ログプラグインは、MySQL 鍵リングに格納されている暗号化パスワードを使用してログファイルの暗号化を実装します (監査ログファイルの暗号化 を参照)。 このプラグインは、パスワードのアーカイブと有効期限 (削除) を含むパスワード履歴も実装します。
監査ログプラグインは、新しい暗号化パスワードを作成するときに、以前のパスワード (存在する場合) をあとで使用するためにアーカイブします。 audit_log_password_history_keep_days
変数は、期限切れのアーカイブ済パスワードの自動削除を制御します。 この値は、アーカイブ監査ログの暗号化パスワードが削除されるまでの日数を示します。 デフォルトの 0 は、パスワードの有効期限を無効にします: パスワードの保存期間は永久的です。
新しい監査ログ暗号化パスワードは、次の状況で作成されます:
プラグインの初期化中に、プラグインがログファイルの暗号化が有効であることを検出すると、キーリングに監査ログの暗号化パスワードが含まれているかどうかをチェックします。 そうでない場合、プラグインはランダムな初期暗号化パスワードを自動的に生成します。
特定のパスワードを設定するために audit_log_encryption_password_set()
関数がコールされた場合。
いずれの場合も、プラグインは新しいパスワードをキーリングに格納し、それを使用して新しいログファイルを暗号化します。
期限切れの監査ログ暗号化パスワードの削除は、次の状況で発生します:
パスワードの削除が発生すると、audit_log_password_history_keep_days
の現在の値によって、削除するパスワードが決まります:
値が 0 の場合、プラグインはパスワードを削除しません。
値が N
> 0 の場合、プラグインは N
日より古いパスワードを削除します。
アーカイブされた暗号化ログファイルの読取りに必要な古いパスワードを期限切れにしないように注意してください。
通常、パスワードの有効期限を無効のままにすると (つまり、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=value |
---|---|
システム変数 | audit_log_policy |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | ALL |
有効な値 |
|
この変数は、レガシーモードの監査ログフィルタリングにのみ適用されます (セクション6.4.5.9「レガシーモード監査ログのフィルタリング」 を参照)。
監査ログプラグインがイベントをそのログファイルに書き込む方法を制御するポリシーです。 次の表は、許可される値を示しています。
値 | 説明 |
---|---|
ALL |
イベントのログをすべて記録します |
LOGINS |
ログインイベントのログのみを記録します |
QUERIES |
クエリーイベントのログのみを記録します |
NONE |
ログを何も記録しません (監査ストリームを無効にします) |
audit_log_policy
は、サーバーの起動時にのみ設定できます。 実行時は、読み取り専用の変数です。 他の 2 つのシステム変数 (audit_log_connection_policy
および audit_log_statement_policy
) は、ロギングポリシーをより細かく制御し、起動時または実行時に設定できます。 起動時に他の 2 つの変数ではなく audit_log_policy
を使用する場合、サーバーはその値を使用してこれらの変数を設定します。 ポリシーの変数とそれらの相互作用についての詳細は、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。
コマンド行形式 | --audit-log-prune-seconds=# |
---|---|
導入 | 8.0.24 |
システム変数 | audit_log_prune_seconds |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 0 |
最小値 | 0 |
最大値 | 4294967295 |
単位 | seconds |
この変数は、JSON 形式のログファイルでのみサポートされている監査ログファイルのプルーニングに関連します。
audit_log_rotate_on_size
が 0 より大きい場合を除き、audit_log_prune_seconds
は効果がありません。 true であると仮定した場合:
audit_log_prune_seconds
が 0 (デフォルト) の場合、プルーニングは無効になり、サイズベースのローテーションの結果として作成されたログファイルは無期限に蓄積されます。
audit_log_prune_seconds
が 0 より大きい場合、プルーニングは有効で、値は監査ログファイルがプルーニングの対象になるまでの秒数です。
プルーニングを有効にすると、監査ログファイルの領域管理 で説明されている条件で実行されます。
コマンド行形式 | --audit-log-read-buffer-size=# |
---|---|
システム変数 | audit_log_read_buffer_size |
スコープ (≥ 8.0.12) | グローバル、セッション |
スコープ (8.0.11) | グローバル |
動的 (≥ 8.0.12) | はい |
動的 (8.0.11) | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 (≥ 8.0.12) | 32768 |
デフォルト値 (8.0.11) | 1048576 |
最小値 (≥ 8.0.12) | 32768 |
最小値 (8.0.11) | 1024 |
最大値 | 4194304 |
監査ログファイルから読み取るバッファサイズ (バイト単位)。 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 |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | Integer |
デフォルト値 | 0 |
単位 | bytes |
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_rotate_on_size
が無効 (0) の場合、プルーニングは有効にできず、audit_log_prune_seconds
は無効になります。
audit_log_rotate_on_size
が有効になっている (0 より大きい) 場合は、プルーニングを有効にでき、audit_log_prune_seconds
によってプルーニングが行われるかどうかが決定されます。
監査ログファイルのローテーションおよびプルーニングの詳細は、監査ログファイルの領域管理 を参照してください。
コマンド行形式 | --audit-log-statement-policy=value |
---|---|
システム変数 | audit_log_statement_policy |
スコープ | グローバル |
動的 | はい |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | ALL |
有効な値 |
|
この変数は、レガシーモードの監査ログフィルタリングにのみ適用されます (セクション6.4.5.9「レガシーモード監査ログのフィルタリング」 を参照)。
監査ログプラグインがステートメントイベントをそのログファイルに書き込む方法を制御するポリシーです。 次の表は、許可される値を示しています。
値 | 説明 |
---|---|
ALL |
ステートメントイベントのログをすべて記録します |
ERRORS |
失敗したステートメントイベントのログのみを記録します |
NONE |
ステートメントイベントのログを記録しません |
セクション6.4.5.5「監査ロギング特性の構成」で説明したように、audit_log_policy
も指定されている場合は、サーバーの起動時に、audit_log_statement_policy
に明示的に指定された値がオーバーライドされる可能性があります。
コマンド行形式 | --audit-log-strategy=value |
---|---|
システム変数 | audit_log_strategy |
スコープ | グローバル |
動的 | いいえ |
SET_VAR ヒントの適用 |
いいえ |
型 | 列挙 |
デフォルト値 | ASYNCHRONOUS |
有効な値 |
|
監査ログプラグインで使用されるロギング方法。 次の戦略値を使用できます:
ASYNCHRONOUS
: 非同期でログを記録します。 出力バッファ内の領域を待機します。
PERFORMANCE
: 非同期でログを記録します。 出力バッファに十分な領域がないリクエストを削除します。
SEMISYNCHRONOUS
: 同期的にログを記録します。 オペレーティングシステムによるキャッシュを許可します。
SYNCHRONOUS
: 同期的にログを記録します。 各リクエストの後に sync()
をコールします。
監査ログプラグインが有効になっている場合は、操作情報を提供するいくつかのステータス変数が公開されます。 これらの変数は、レガシーモードの監査フィルタリングおよび JSON モードの監査フィルタリングに使用できます。
現在の監査ログファイルのサイズ。 この値は、イベントがログに書き込まれると増加し、ログがローテーションされると 0 にリセットされます。
パフォーマンスロギングモードで破棄された最大イベントのサイズ。 ロギングモードについては、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。
フィルタリングのポリシーに基づいてログに書き込まれたかどうかに関係なく、監査ログプラグインによって処理されたイベントの数 (セクション6.4.5.5「監査ロギング特性の構成」を参照してください)。
フィルタリングのポリシーに基づいて、監査ログプラグインによってフィルタリングされた (ログに書き込まれなかった) イベントの数 (セクション6.4.5.5「監査ロギング特性の構成」を参照してください)。
イベントが使用可能な監査ログバッファー領域よりも大きかったために、パフォーマンスロギングモードで失われたイベントの数。 この値は、audit_log_buffer_size
を設定して、パフォーマンスモード用にバッファーのサイズを調整する方法を評価する際に役立つことがあります。 ロギングモードについては、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。
監査ログに書き込まれたイベントの数。
すべての監査ログファイルに書き込まれたイベントの合計サイズ。 Audit_log_current_size
とは異なり、Audit_log_total_size
の値は、ログがローテーションされたときにも増加します。
非同期ロギングモードでイベントが監査ログバッファー内の領域を待機する必要があった回数。 ロギングモードについては、セクション6.4.5.5「監査ロギング特性の構成」を参照してください。