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.
に変更されました。現在は、プラグインによってファイル名は
XML ファイルであることを示す
TIMESTAMP
audit.log.
に変更されます。
TIMESTAMP
.xml
audit_log_format
の値を変更する場合は、次の手順を使用して、ある形式のログエントリが別の形式のエントリを含む既存のログファイルに書き込まれることを回避します。
サーバーを停止します。
現在の監査ログファイルの名前を手動で変更します。
新しい
audit_log_format
の値でサーバーを再起動します。監査ログプラグインによって、選択した形式のログエントリを含む新しいログファイルが作成されます。
監査プラグインを記述するための API
も変更されました。mysql_event_general
の構造には、クライアントのホスト名と IP
アドレス、コマンドのクラス、および外部ユーザーを表す新しいメンバーが含まれています。詳細については、セクション24.2.4.8「監査プラグインの作成」を参照してください。