監査ログファイル名を構成するには、サーバーの起動時に audit_log_file システム変数を設定します。 サーバーデータディレクトリのデフォルト名は audit.log です。 セキュリティを最適化するには、MySQL サーバーおよびログを表示する正当な理由があるユーザーのみがアクセスできるディレクトリに監査ログを書き込みます。

プラグインは、audit_log_file 値を、オプションの先頭ディレクトリ名、ベース名、およびオプションの接尾辞で構成されるものとして解釈します。 圧縮または暗号化が有効になっている場合、有効なファイル名 (ログファイルの作成に実際に使用される名前) は、追加の接尾辞があるため、構成されたファイル名とは異なります:

有効な監査ログファイル名は、構成されたファイル名に適用可能な圧縮および暗号化接尾辞を追加した結果の名前です。 たとえば、構成された audit_log_file 値が audit.log の場合、有効なファイル名は次のテーブルに示す値のいずれかになります。

pwd_id は、ファイルの暗号化または復号化に使用されるパスワードの ID を示します。pwd_id 形式は pwd_timestamp-seq です。ここでは:

pwd_id パスワード ID の値の例を次に示します:

20190403T142359-1
20190403T142400-1
20190403T142400-2

パスワードをキーリングに格納するための対応するキーリング ID を構築するために、監査ログプラグインは audit_log- の接頭辞を pwd_id 値に追加します。 前述のパスワード ID の例では、対応するキーリング ID は次のとおりです:

audit_log-20190403T142359-1
audit_log-20190403T142400-1
audit_log-20190403T142400-2

監査ログプラグインによって暗号化に現在使用されているパスワードの ID は、pwd_timestamp 値がもっとも大きいパスワードです。 複数のパスワードにその pwd_timestamp 値がある場合、現在のパスワード ID は順序番号が最も大きいものになります。 たとえば、前述のパスワード ID のセットでは、パスワード ID のうち 2 つの ID のタイムスタンプが最大の 20190403T142400 であるため、現在のパスワード ID は順序番号 (2) が最も大きいものになります。

監査ログプラグインは、有効な監査ログファイル名に基づいて、初期化および終了時に特定のアクションを実行します:

監査ログファイル形式を構成するには、サーバーの起動時に audit_log_format システム変数を設定します。 デフォルトでは、フォーマットは NEW (新しいスタイルの XML フォーマット) です。 各形式についての詳細は、セクション6.4.5.4「監査ログファイル形式」を参照してください。

audit_log_format を変更する場合は、audit_log_file も変更することをお薦めします。 それ以外の場合は、ベース名は同じで形式が異なる 2 つのログファイルのセットが存在します。

監査ログファイルの圧縮は、任意のロギング形式に対して有効にできます。

監査ログファイルの圧縮を構成するには、サーバーの起動時に audit_log_compression システム変数を設定します。 許可される値は、NONE (圧縮なし、デフォルト) および GZIP (GNU Zip 圧縮) です。

圧縮と暗号化の両方が有効な場合、圧縮は暗号化の前に行われます。 元のファイルを手動でリカバリするには、最初に復号化してから解凍します。 監査ログファイルの手動での解凍および復号化を参照してください。

監査ログファイルの暗号化は、任意のロギング形式に対して有効にできます。 暗号化は、ユーザー定義のパスワードに基づきます (監査ログプラグインによって生成される初期パスワードを除く)。 この機能を使用するには、監査ロギングでパスワード記憶域に使用されるため、MySQL キーリングを有効にする必要があります。 どのキーリングプラグインも使用できます。手順については、セクション6.4.4「MySQL キーリング」 を参照してください。

監査ログファイルの暗号化を構成するには、サーバーの起動時に audit_log_encryption システム変数を設定します。 許可される値は、NONE (暗号化なし、デフォルト) および AES (AES-256-CBC 暗号化) です。

実行時に暗号化パスワードを設定または取得するには、次のユーザー定義関数 (UDF) を使用します:

監査ログの暗号化 UDF の詳細は、監査ログ関数 を参照してください。

監査ログプラグインが初期化されるときに、ログファイルの暗号化が有効になっていることが判明すると、鍵リングに監査ログの暗号化パスワードが含まれているかどうかがチェックされます。 そうでない場合、プラグインはランダムな初期暗号化パスワードを自動的に生成し、キーリングに格納します。 このパスワードを検出するには、audit_log_encryption_password_get() を起動します。

圧縮と暗号化の両方が有効な場合、圧縮は暗号化の前に行われます。 元のファイルを手動でリカバリするには、最初に復号化してから解凍します。 監査ログファイルの手動での解凍および復号化を参照してください。

監査ログファイルは、標準ツールを使用して圧縮解除および復号化できます。 これは、閉じられた (アーカイブされた) 使用されなくなったログファイルに対してのみ実行してください。監査ログプラグインが現在書き込んでいるログファイルに対しては実行しないでください。 アーカイブログファイルは、ベース名の直後のファイル名にタイムスタンプを含めるように監査ログプラグインによって名前が変更されているため、認識できます。

この説明では、audit_log_file が audit.log に設定されていると仮定します。 その場合、アーカイブされた監査ログファイルには、次のテーブルに示すいずれかの名前が付けられます。

監査ログファイルのネーミング規則 で説明されているように、pwd_id 形式は pwd_timestamp-seq です。 したがって、アーカイブされた暗号化ログファイルの名前には、実際には 2 つのタイムスタンプが含まれています。 1 つ目はファイルのローテーション時間を示し、2 つ目は暗号化パスワードが作成された時間を示します。

次のアーカイブ暗号化ログファイル名のセットについて考えてみます:

audit.20190410T205827.log.20190403T185337-1.enc
audit.20190410T210243.log.20190403T185337-1.enc
audit.20190415T145309.log.20190414T223342-1.enc
audit.20190415T151322.log.20190414T223342-2.enc

各ファイル名には、一意のローテーション時間タイムスタンプがあります。 対照的に、パスワードのタイムスタンプは一意ではありません:

圧縮されたログファイルを手動で解凍するには、gunzip、gzip -d または同等のコマンドを使用します。 例:

gunzip -c audit.timestamp.log.gz > audit.timestamp.log

暗号化されたログファイルを手動で復号化するには、openssl コマンドを使用します。 例:

openssl enc -d -aes-256-cbc -pass pass:password -md sha256
    -in audit.timestamp.log.pwd_id.enc
    -out audit.timestamp.log

このコマンドを実行するには、暗号化パスワードである password を取得する必要があります。 これを行うには、audit_log_encryption_password_get() を使用します。 たとえば、監査ログファイル名が audit.20190415T151322.log.20190414T223342-2.enc の場合、パスワード ID は 20190414T223342-2 で、キーリング ID は audit-log-20190414T223342-2 です。 次のようなキーリングパスワードを取得します:

SELECT audit_log_encryption_password_get('audit-log-20190414T223342-2');

圧縮と暗号化の両方が監査ロギングに対して有効になっている場合、圧縮は暗号化の前に行われます。 この場合、ファイル名には、これらの操作が発生する順序に対応する .gz および .pwd_id.enc 接尾辞が追加されます。 元のファイルを手動でリカバリするには、操作を逆に実行します。 つまり、最初にファイルを復号化してから解凍します:

openssl enc -d -aes-256-cbc -pass pass:password -md sha256
    -in audit.timestamp.log.gz.pwd_id.enc
    -out audit.timestamp.log.gz
gunzip -c audit.timestamp.log.gz > audit.timestamp.log

このセクションでは、パスワード履歴 (パスワードのアーカイブと有効期限を含む) が実装されたときの、MySQL 8.0.17 の前後の監査ログファイルの暗号化機能の違いについて説明します。 また、監査ログプラグインが 8.0.17 より前のバージョンから MySQL 8.0.17 以上へのアップグレードを処理する方法も示します。

MySQL 8.0.17 より前ではパスワード履歴がないため、新しいパスワードを設定すると古いパスワードにアクセスできなくなり、MySQL Enterprise Audit は古いパスワードで暗号化されたログファイルを読み取ることができなくなりました。 これらのファイルを手動で復号化する必要があると予想される場合は、以前のパスワードのレコードを保持する必要があります。

下位バージョンから MySQL 8.0.17 以上にアップグレードするときに監査ログファイルの暗号化が有効になっている場合、監査ログプラグインは次のアップグレードアクションを実行します:

監査ログファイルは、非常に大きくなり、大量のディスク領域を消費する可能性があります。 ログファイルで使用される領域の管理を有効にするために、監査ログプラグインでは、ファイルサイズに基づいて手動または自動でログファイルをローテーションできます。 MySQL 8.0.24 では、このプラグインは JSON 形式のログファイルのログファイルプルーニングもサポートしています。

監査ログファイルの領域管理機能では、audit_log_rotate_on_size、audit_log_flush および audit_log_prune_seconds システム変数が使用され、次のように組み合されています:

次の各セクションでは、ログファイルのローテーションとプルーニングについて詳しく説明します。

手動監査ログファイルローテーション

audit_log_rotate_on_size が 0 (デフォルト) の場合、手動で実行しないかぎり、ログローテーションは発生しません。 この場合、audit_log_flush の値が無効から有効に変更されると、監査ログプラグインはログファイルを閉じてから再度開きます。 ログファイル名の変更は、サーバーの外部で実行される必要があります。 ログファイル名が audit.log で、audit.log.3 を介して audit.log.1 という名前を循環して、最新の 3 つのログファイルを保持するとします。 Unix 上で、次のように手動でローテーションを実行します。

サイズベースの監査ログファイルのローテーション

audit_log_rotate_on_size が 0 よりも大きい場合は、audit_log_flush を設定しても効果がありません。 代わりに、現在のログファイルへの書き込みによってそのサイズが audit_log_rotate_on_size 値を超えるたびに、監査ログプラグインは自動的にファイルを閉じて名前を変更し、新しいログファイルを開きます。

自動サイズベースローテーションは、次の条件下でも発生します:

プラグインは、ベース名の直後にタイムスタンプを挿入して、元のファイルの名前を変更します。 たとえば、ファイル名が audit.log の場合、プラグインはその名前を audit.20190115T140633.log などの値に変更します。 タイムスタンプは、YYYYMMDDThhmmss 形式の UTC 値です。 タイムスタンプは、XML ロギングのローテーション時間と、JSON ロギングのためにファイルに最後に書き込まれたイベントのタイムスタンプを示します。

監査ログファイルのプルーニング

MySQL 8.0.24 では、監査ログプラグインは JSON 形式の監査ログファイルのプルーニングをサポートしています。 この機能を有効にするには:

ログファイルのプルーニングは、次の条件下で発生します:

プルーニングポイントは、現在の時間から audit_log_prune_seconds の値を引いた値です。 ローテーションされた JSON 形式のログファイルでは、各ファイル名のタイムスタンプ部分は、ファイルに最後に書き込まれたイベントのタイムスタンプを示します。 プルーニングが発生すると、監査ログプラグインはファイル名のタイムスタンプを使用して、プルーニングポイントより古いイベントのみを含むファイルを特定し、それらを削除します。

監査プラグインは、ログの書き込みに関する複数の戦略のいずれかを使用できます。 戦略に関係なく、ロギングはベストエフォートベーシスで発生するため、一貫性は保証されません。

書込み戦略を指定するには、サーバーの起動時に audit_log_strategy システム変数を設定します。 デフォルトでは、戦略の値は ASYNCHRONOUS であり、プラグインは非同期的にログをバッファーに記録し、バッファーがいっぱいの場合は待機します。 ファイルシステムのキャッシュ処理を使用するか (SEMISYNCHRONOUS)、各書き込みリクエストのあとに sync() を呼び出して出力を強制すれば (SYNCHRONOUS)、待機しないように (PERFORMANCE)、または同期的にログを記録するようにプラグインに指示できます。

非同期書込み戦略の場合、audit_log_buffer_size システム変数はバイト単位のバッファサイズです。 バッファサイズを変更するには、サーバー起動時にこの変数を設定します。 このプラグインでは、初期化時に割り当てられ、終了時に削除される単一のバッファーが使用されます。 プラグインは、このバッファーを非同期でない書き込み戦略に割り当てません。

非同期ロギングの戦略には、次のような特性があります。

非同期ロギングでは、ファイルへの書込み中に問題が発生した場合、またはプラグインが正常に停止しない場合 (サーバーホストが予期せず終了した場合など)、ログファイルの整合性が損なわれる可能性があります。 このリスクを減らすには、同期ロギングが使用されるように audit_log_strategy を設定します。

PERFORMANCE 戦略のデメリットは、バッファーがいっぱいの場合にイベントが破棄される点です。 負荷の高いサーバーの場合、監査ログにイベントが欠落している可能性があります。