6.3.12 MySQL Enterprise Audit ログプラグイン

6.3.12.1 監査ログプラグインのインストール

6.3.12.2 監査ログプラグインのセキュリティーに関する考慮事項

6.3.12.3 監査ログファイル

6.3.12.4 監査ログプラグインのロギング制御

6.3.12.5 監査ログプラグインのオプションおよび変数のリファレンス

6.3.12.6 監査ログプラグインのオプションおよびシステム変数

6.3.12.7 監査ログプラグインのステータス変数

6.3.12.8 監査ログプラグインの制限事項

注記

MySQL Enterprise Audit は、商用の拡張機能です。商用の製品 (MySQL Enterprise Edition) についてさらに学習するには、https://www.mysql.com/products/ を参照してください。

MySQL 5.6.10 の時点で、MySQL Enterprise Edition には、audit_log という名前のサーバープラグインを使用して実装された MySQL Enterprise Audit が含まれています。MySQL Enterprise Audit では、特定の MySQL サーバーで実行される接続およびクエリーアクティビティーのポリシーベースの標準モニタリングおよびロギングを有効にする際に、MySQL Audit API が使用されます。MySQL Enterprise Audit は、オラクルの監査仕様を満たすように設計されており、内部および外部の規制ガイドラインの両方に管理されているアプリケーションに対して、そのままで簡単に使用できる監査およびコンプライアンスのソリューションを提供しています。

インストール時に監査プラグインを使用すると、MySQL サーバーはサーバーアクティビティーの監査レコードを含むログファイルを生成できます。ログの内容には、クライアントが接続および切断したとき、および接続中に実行されたアクション (アクセスされたデータベースやテーブルなど) が含まれます。

プラグインをインストールすると (セクション6.3.12.1「監査ログプラグインのインストール」を参照してください)、監査ログファイルが書き込まれます。デフォルトでは、そのファイルはサーバーのデータディレクトリ内の audit.log という名前です。ファイルの名前を変更するには、サーバーの起動時に audit_log_file システム変数を設定します。

監査ログファイルの内容は暗号化されません。セクション6.3.12.2「監査ログプラグインのセキュリティーに関する考慮事項」を参照してください。

監査ログファイルは、<AUDIT_RECORD> 要素としてエンコードされた監査可能なイベントとともに、XML 形式で書き込まれます。ファイル形式を選択するには、サーバーの起動時に audit_log_format システム変数を設定します。ファイルの形式および内容についての詳細は、セクション6.3.12.3「監査ログファイル」を参照してください。

audit_log によってログファイルに書き込まれる情報の内容を制御するには、audit_log_policy システム変数を設定します。この変数はデフォルトで、ALL (監査可能なイベントをすべて書き込む) に設定されていますが、ログインまたはクエリーイベントのログのみを記録する LOGINS または QUERIES や、ロギングを無効にする NONE の値も許可されています。

ロギングが発生する方法の制御についての詳細は、セクション6.3.12.4「監査ログプラグインのロギング制御」を参照してください。監査ログプラグインを構成する際に使用されるパラメータについては、セクション6.3.12.6「監査ログプラグインのオプションおよびシステム変数」を参照してください。

audit_log プラグインが有効になっている場合は、パフォーマンススキーマ (第22章「MySQL パフォーマンススキーマ」を参照してください) に監査ログプラグイン用のインストゥルメンテーションが追加されます。関連するインストゥルメントを識別するには、次のクエリーを使用します。

SELECT NAME FROM performance_schema.setup_instruments
WHERE NAME LIKE '%/alog/%';

古い監査ログプラグインのバージョンからの変更

MySQL 5.6.14 では、Oracle Audit Vault との互換性を高くするために、監査ログプラグインにいくつかの変更が行われました。

新しい監査ログファイルの形式が実装されました。audit_log_format システム変数を使用すれば、古い形式または新しい形式を選択できます。この変数では、OLD および NEW (デフォルトは OLD) の値が許可されています。2 つの形式の相違点は次のとおりです。

• 属性を使用した古い形式で書き込まれた <AUDIT_RECORD> 要素内の情報は、サブ要素を使用した新しい形式で書き込まれます。

• 新しい形式には、<AUDIT_RECORD> 要素の詳細な情報が含まれています。各要素には、一意の識別子を提供する RECORD_ID 値が含まれています。TIMESTAMP 値には、タイムゾーンの情報が含まれています。クエリーレコードには、HOST、IP、OS_LOGIN、USER の情報、および COMMAND_CLASS と STATUS_CODE の値が含まれています。

古い <AUDIT_RECORD> 形式の例:

<AUDIT_RECORD
 TIMESTAMP="2013-09-15T15:27:27"
 NAME="Query"
 CONNECTION_ID="3"
 STATUS="0"
 SQLTEXT="SELECT 1"
/>

新しい <AUDIT_RECORD> 形式の例:

<AUDIT_RECORD>
 <TIMESTAMP>2013-09-15T15:27:27 UTC</TIMESTAMP>
 <RECORD_ID>3998_2013-09-15T15:27:27</RECORD_ID>
 <NAME>Query</NAME>
 <CONNECTION_ID>3</CONNECTION_ID>
 <STATUS>0</STATUS>
 <STATUS_CODE>0</STATUS_CODE>
 <USER>root[root] @ localhost [127.0.0.1]</USER>
 <OS_LOGIN></OS_LOGIN>
 <HOST>localhost</HOST>
 <IP>127.0.0.1</IP>
 <COMMAND_CLASS>select</COMMAND_CLASS>
 <SQLTEXT>SELECT 1</SQLTEXT>
</AUDIT_RECORD>

監査ログプラグインによって監査ログファイルがローテーションされると、別のファイル名形式が使用されます。audit.log という名前のログファイルの場合、以前はプラグインによってファイル名が audit.log.TIMESTAMP に変更されました。現在は、プラグインによってファイル名は XML ファイルであることを示す audit.log.TIMESTAMP.xml に変更されます。

audit_log_format の値を変更する場合は、次の手順を使用して、ある形式のログエントリが別の形式のエントリを含む既存のログファイルに書き込まれることを回避します。

1. サーバーを停止します。

2. 現在の監査ログファイルの名前を手動で変更します。

3. 新しい audit_log_format の値でサーバーを再起動します。監査ログプラグインによって、選択した形式のログエントリを含む新しいログファイルが作成されます。

監査プラグインを記述するための API も変更されました。mysql_event_general の構造には、クライアントのホスト名と IP アドレス、コマンドのクラス、および外部ユーザーを表す新しいメンバーが含まれています。詳細については、セクション24.2.4.8「監査プラグインの作成」を参照してください。