MySQL 8.0 リファレンスマニュアル


6.4.5.5 監査ロギング特性の構成

このセクションでは、監査ログプラグインがイベントを書き込むファイル、書き込まれたイベントの形式、ログファイルの圧縮と暗号化を有効にするかどうかなど、監査ロギング特性を構成する方法について説明します。

注記

ここで説明する暗号化機能は、現在の暗号化機能を以前の制限付き機能と比較するセクションを除き、MySQL 8.0.17 の時点で適用されます。MySQL 8.0.17 より前の監査ログファイルの暗号化 を参照してください。

監査ロギングに影響するユーザー定義関数およびシステム変数の詳細は、監査ログ関数 および 監査ログのオプションおよび変数 を参照してください。

監査ログプラグインは、イベントの内容またはイベントの発生元のアカウントに基づいて、監査ログファイルに書き込む監査イベントを制御することもできます。 セクション6.4.5.7「監査ログのフィルタリング」を参照してください。

監査ログファイルのネーミング規則

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

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

  • 圧縮が有効な場合、プラグインは .gz の接尾辞を追加します。

  • 暗号化が有効な場合、プラグインは .pwd_id.enc の接尾辞を追加します。ここで、pwd_id はログファイル操作に使用する暗号化パスワードを示します。 監査ログプラグインは、暗号化パスワードを鍵リングに格納します。監査ログファイルの暗号化 を参照してください。

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

有効な機能 有効なファイル名
圧縮または暗号化なし audit.log
Compression audit.log.gz
暗号化 audit.log.pwd_id.enc
圧縮、暗号化 audit.log.gz.pwd_id.enc

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

  • pwd_timestamp は、パスワードがいつ作成されたかを示す YYYYMMDDThhmmss 形式の UTC 値です。

  • seq は順序番号です。 順序番号は 1 から始まり、同じ pwd_timestamp 値を持つパスワードに対して増加します。

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) を使用します:

  • 現在の暗号化パスワードを設定するには、audit_log_encryption_password_set() を起動します。 この関数は、キーリングに新しいパスワードを格納します。 暗号化が有効な場合は、現在のログファイルの名前を変更するログファイルローテーション操作も実行され、パスワードで暗号化された新しいログファイルが開始されます。 ファイル名の変更は、サイズベースの自動ログファイルローテーションの通常のルールに従って行われます。サイズベースの監査ログファイルのローテーション を参照してください。

    audit_log_password_history_keep_days システム変数がゼロ以外の場合、audit_log_encryption_password_set() を起動すると、古いアーカイブ監査ログの暗号化パスワードも期限切れになります。 パスワードのアーカイブや有効期限など、監査ログのパスワード履歴の詳細は、その変数の説明を参照してください。

  • 現在の暗号化パスワードを取得するには、引数を指定せずに audit_log_encryption_password_get() を起動します。 ID でパスワードを取得するには、現在のパスワードまたはアーカイブされたパスワードのキーリング ID を指定する引数を渡します。

    存在する監査ログ鍵リング ID を確認するには、パフォーマンススキーマ keyring_keys テーブルをクエリーします:

    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 |
    +-----------------------------+

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

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

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

監査ログファイルの手動での解凍および復号化

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

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

有効な機能 アーカイブファイル名
圧縮または暗号化なし audit.timestamp.log
Compression audit.timestamp.log.gz
暗号化 audit.timestamp.log.pwd_id.enc
圧縮、暗号化 audit.timestamp.log.gz.pwd_id.enc

監査ログファイルのネーミング規則 で説明されているように、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

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

  • 最初の 2 つのファイルのパスワード ID と順序番号は同じです (20190403T185337-1)。 これらの暗号化パスワードは同じです。

  • 2 つ目のファイルのパスワード ID (20190414T223342) は同じですが、順序番号 (12) が異なります。 これらのファイルの暗号化パスワードは異なります。

圧縮されたログファイルを手動で解凍するには、gunzipgzip -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 より前の監査ログファイルの暗号化

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

機能 MySQL 8.0.17 より前 MySQL 8.0.17 の時点
パスワードの数 単一パスワードのみ 複数のパスワードを許可
暗号化されたログファイル名 .enc 接尾辞 .pwd_id.enc 接尾辞
パスワードキーリング ID audit_log audit_log-pwd_id
パスワード履歴 いいえ はい

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

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

  • プラグインの初期化中に、プラグインはキーリング ID が audit_log の暗号化パスワードをチェックします。 見つかった場合、プラグインは audit_log-pwd_id 形式のキーリング ID を使用してパスワードを複製し、現在の暗号化パスワードとして使用します。 (pwd_id 構文の詳細は、監査ログファイルのネーミング規則 を参照してください。)

  • 既存の暗号化されたログファイルには、接尾辞 .enc が付きます。 プラグインは、接尾辞が .pwd_id.enc になるようにこれらの名前を変更しませんが、ID が audit_log のキーがキーリングに残っているかぎり読み取ることができます。

  • パスワードのクリーンアップが発生したときに、プラグインが audit_log-pwd_id 形式のキーリング ID を持つパスワードを期限切れにすると、audit_log のキーリング ID を持つパスワードも期限切れになります (存在する場合)。 (この時点で、.pwd_id.enc ではなく .enc という接尾辞を持つ暗号化されたログファイルはプラグインで読み取れなくなるため、不要になったと想定されます。)

監査ログファイルの領域管理

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

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

  • audit_log_rotate_on_size が 0 (デフォルト) の場合:

    • 自動ログファイルローテーションが無効です。 手動で実行しないかぎり、ローテーションは発生しません。

    • 手動で名前を変更した後、audit_log_flush を使用して現在のログファイルを閉じ、再度開きます。

    • ログファイルのプルーニングを有効にできず、audit_log_prune_seconds は無効です。

  • audit_log_rotate_on_size が 0 より大きい場合:

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

    • ログファイルのプルーニングを有効にでき、audit_log_prune_seconds はプルーニングが行われるかどうかを判断します。

    • audit_log_flush には影響はありません。

  • 自動サイズベースローテーションは、後で説明する他のいくつかの条件下でも発生します。

注記

名前が変更されたログファイルは自動的に削除されません。 たとえば、サイズベースのログファイルローテーションでは、名前が変更されたログファイルは名前シーケンスの最後からローテーションされません。 かわりに、一意の名前を持ち、無期限に蓄積されます。 過剰な領域使用を回避するには:

  • MySQL 8.0.24 以降 (JSON 形式のログファイル用): 監査ログファイルのプルーニング の説明に従って、ログファイルのプルーニングを有効にします。

  • それ以外の場合 (JSON 以外のファイルの場合、またはすべてのログ形式について MySQL 8.0.24 より前の場合): 古いファイルを定期的に削除し、必要に応じて最初にバックアップします。 バックアップされたログファイルが暗号化されている場合は、後でファイルを復号化する必要があるときに、対応する暗号化パスワードも安全な場所にバックアップします。

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

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

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

  1. コマンド行から、現在のログファイル名を変更します。

    mv audit.log.2 audit.log.3
    mv audit.log.1 audit.log.2
    mv audit.log audit.log.1

    この方法では、現在の audit.log.3 コンテンツが上書きされ、アーカイブログファイルの数とそれらが使用する領域にバインドが配置されます。

  2. この時点で、プラグインは引き続き、audit.log.1 に名前が変更された現在のログファイルに書き込みます。 サーバーに接続し、ログファイルをフラッシュします。これにより、プラグインはログファイルを閉じて、新しい audit.log ファイルログを再度開きます。

    SET GLOBAL audit_log_flush = ON;

    audit_log_flush は、その値が OFF のままであるため、別のフラッシュを実行するために再度有効にする前に明示的に無効にする必要がないという点で特殊です。

注記

圧縮または暗号化が有効になっている場合、ログファイル名には、有効な機能を示す接尾辞と、暗号化が有効になっている場合はパスワード ID が含まれます。 ファイル名にパスワード ID が含まれている場合は、復号化操作に使用するパスワードを決定できるように、手動で名前を変更するファイルの名前に ID を保持してください。

注記

JSON 形式のロギングの場合、監査ログファイルの名前を手動で変更すると、監査ログプラグインはログファイル順序の一部であると判断できなくなるため、ログ読取り機能で使用できなくなります (セクション6.4.5.6「監査ログファイルの読取り」 を参照)。 かわりに、サイズベースのローテーションを使用するように 0 より大きい audit_log_rotate_on_size を設定することを検討してください。

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

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

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

  • プラグインの初期化中に、監査ログファイル名を持つファイルがすでに存在する場合 (監査ログファイルのネーミング規則 を参照)。

  • プラグインの終了時。

  • 暗号化が有効になっている場合に、audit_log_encryption_password_set() 関数をコールして暗号化パスワードを設定するとき。 (暗号化が無効になっている場合、ローテーションは行われません。)

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

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

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

  • audit_log_formatJSON に設定します。

  • audit_log_rotate_on_size を 0 より大きい値に設定して、ログファイルのローテーションが発生するサイズを指定します。

  • 0 より大きい audit_log_prune_seconds を設定して、ログファイルがプルーニングの対象になるまでの秒数を指定します。

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

  • プラグインの初期化中。

  • 現在のログファイルがローテーションサイズを超えたためにサイズベースの自動ローテーションが発生した場合。

  • SET GLOBAL audit_log_prune_seconds が実行時に実行される場合。

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

監査ロギングの書込み戦略

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

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

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

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

  • サーバーのパフォーマンスと拡張性への影響が最小限です。

  • できるかぎり最短の時間 (つまり、バッファーを割り当てる時間とそのバッファーにイベントをコピーする時間を足した時間) で、監査イベントを生成するスレッドをブロックします。

  • 出力はバッファーに書き込まれます。 個別のスレッドがバッファーからログファイルへの書き込みに対処します。

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

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


関連キーワード:  監査, audit, パスワード, ローテーション, 変更, ログ, 名前, 圧縮, 形式, enc