MariaDBの監査プラグインは、MariaDBだけでなく、MySQL（バージョン5.5.34および10.0.7以降）およびPerconaサーバーの監査機能を提供します。 MariaDBは、デフォルトでバージョン10.0.10および5.5.37からの監査プラグインの組み込みを開始し、MariaDB5.5.20からの任意のバージョンにインストールできます。
MariaDB監査プラグインの目的は、サーバーのアクティビティをログに記録することです。クライアントセッションごとに、サーバーに接続したユーザー（ユーザー名とホスト）、実行されたクエリ、アクセスされたテーブル、変更されたサーバー変数が記録されます。この情報はローテーションログファイルに保存されるか、ローカルのsyslogdに送信される場合があります。
このブログ投稿では、MariaDBサーバーの監査ログを構成するためのベストプラクティスの調整とヒントを紹介します。この記述は、MariaDB 10.5.9に基づいており、最新バージョンのMariaDB AuditPlugin1.4.4が含まれています。
監査ログを有効にするための推奨される方法は、MariaDB構成ファイル内に次の行を設定することです。
[mariadb]
plugin_load_add = server_audit # load plugin
server_audit=FORCE_PLUS_PERMANENT # do not allow users to uninstall plugin
server_audit_file_path=/var/log/mysql/mariadb-audit.log # path to the audit log
server_audit_logging=ON # enable audit logging「server_audit=FORCE_PLUS_PERMANENT」を設定して監査ログを適用し、UNINSTALLSONAMEステートメントを使用して他のユーザーが監査ログをアンインストールできないようにすることを忘れないでください。デフォルトでは、ロギング先はMariaDBデータディレクトリ内のログファイルです。 datadirが消去される可能性があるため（Galera Clusterの場合はSST）、MariaDB Backupから取得したバックアップを復元するときに、datadirスワッピングなどの物理的な復元に置き換えられる可能性があるため、監査ログをこのディレクトリの外に置く必要があります。
次のセクションに示すように、さらに調整する必要があります。
MariaDB Auditプラグインは、プラグインのバージョンに応じていくつかのログ設定を利用します。次の監査イベントは、最新のプラグインバージョン1.4.4で使用できます。
| | |
| | 接続、切断、接続の失敗（エラーコードを含む） |
| | 実行されたクエリとその結果（構文エラーまたは権限エラーによるクエリの失敗を含む）はプレーンテキストで表示されます |
| | |
| QUERY_DDL | QUERYに似ていますが、DDLタイプのクエリ（CREATE、ALTER、DROP、RENAME、TRUNCATEステートメント-CREATE / DROP [PROCEDURE / FUNCTION /USER]とRENAMEUSERを除く）のみをフィルタリングします（これらは'DDLではありません） |
| QUERY_DML | QUERYに似ていますが、DMLタイプのクエリ（DO、CALL、LOAD DATA / XML、DELETE、INSERT、SELECT、UPDATE、HANDLER、REPLACEステートメント）のみをフィルタリングします。 |
| QUERY_DML_NO_SELECT | QUERY_DMLに似ていますが、SELECTクエリをログに記録しません。 （バージョン1.4.4以降）（DO、CALL、LOAD DATA / XML、DELETE、INSERT、UPDATE、HANDLER、およびREPLACEステートメント） |
| QUERY_DCL | QUERYに似ていますが、DCLタイプのクエリ（CREATE USER、DROP USER、RENAME USER、GRANT、REVOKE、SET PASSWORDステートメント）のみをフィルタリングします。 |
server_audit_events変数はデフォルトで空に設定されるため、デフォルトではすべてを追跡します。ここに示すように、古いバージョンでは上記の操作タイプのサポートが少ないことに注意してください。したがって、特定のフィルタリングを実行する場合は、最新バージョンで実行していることを確認してください。
クエリキャッシュが有効になっていて、クエリがクエリキャッシュから返された場合、サーバーがテーブルを開いたりアクセスしたりせず、代わりにキャッシュに依存していたため、TABLEレコードはログに表示されません。結果。したがって、クエリキャッシュを無効にすることをお勧めします。
特定のイベントを除外するには、MariaDB構成ファイル内に次の行を設定します（再起動が必要です）：
server_audit_events = 'CONNECT,QUERY,TABLE'または、SET GLOBALを使用してランタイムで動的に設定します（再起動は必要ありませんが、永続的ではありません）：
MariaDB> SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0このログのエントリは、次の情報を含むコンマで区切られた一連の情報で構成されます。
-
タイムスタンプ
-
MySQLホスト（SELECT @@ hostnameの値と同じ）
-
データベースユーザー
-
ユーザーが接続していたホスト
-
接続ID
-
スレッドID
-
操作
-
データベース
-
SQLステートメント/コマンド
-
リターンコード。 0は、操作が成功応答（空であっても）を返すことを意味し、ゼロ以外の値は、構文エラーまたはアクセス許可エラーが原因でクエリが失敗したなど、操作の実行中にエラーが発生したことを意味します。
エントリをフィルタリングするときは、単純なgrepを実行して、特定のパターンを探します。
$ grep -i global /var/lib/mysql/server_audit.log
20210325 04:19:17,ip-172-31-0-44,root,localhost,14,37080,QUERY,,'set global server_audit_file_rotate_now = 1',0
20210326 00:46:48,ip-172-31-0-44,root,localhost,35,329003,QUERY,,'set global server_audit_output_type = \'syslog\'',0デフォルトでは、すべてのパスワード値はアスタリスクでマスクされます：
20210326 05:39:41,ip-172-31-0-44,root,localhost,52,398793,QUERY,mysql,'GRANT ALL PRIVILEGES ON sbtest.* TO [email protected] IDENTIFIED BY *****',0すべてを追跡すると、以下の例に示すように、サンプリングの責任のために監視ユーザーが殺到する可能性があります。
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,227,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,228,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,229,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,230,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,231,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,232,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,233,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,234,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,235,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,236,QUERY,information_schema,'SET GLOBAL SLOW_QUERY_LOG=0',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,237,QUERY,information_schema,'FLUSH /*!50500 SLOW */ LOGS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,6,238,QUERY,information_schema,'SHOW GLOBAL STATUS',01秒間に、「cmon」と呼ばれる監視ユーザーの監査プラグインによって記録された14のQUERYイベントを確認できます。テストワークロードでは、ロギングレートは1分あたり約32 KBであり、1日あたり最大46MBが累積されます。ストレージサイズとIO容量によっては、これは一部のワークロードでは過剰になる可能性があります。したがって、監査ログから監視ユーザーを除外する方がよいでしょう。そうすれば、よりクリーンな出力が得られ、監査と分析がはるかに簡単になります。
セキュリティと監査のポリシーに応じて、MariaDB構成ファイル内の次の変数を使用して、監視ユーザーなどの不要なユーザーを除外できます（再起動が必要）：
server_audit_excl_users='cmon'または、SET GLOBALを使用してランタイムで動的に設定します（再起動は必要ありませんが、永続的ではありません）：
MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'$ tail -f /var/log/mysql/mysql-audit.log
20210325 04:16:06,ip-172-31-0-44,cmon,172.31.1.119,6,36218,QUERY,information_schema,'SHOW GLOBAL STATUS',0
20210325 04:16:06,ip-172-31-0-44,root,localhost,13,36219,QUERY,,'set global server_audit_excl_users = \'cmon\'',0
20210325 04:16:09,ip-172-31-0-44,root,localhost,13,36237,QUERY,,'show global variables like \'%server_audit%\'',0
20210325 04:16:12,ip-172-31-0-44,root,localhost,13,0,DISCONNECT,,,0監査ログは膨大な数のイベントをキャプチャするため、適切なログローテーションを構成することをお勧めします。そうしないと、ログファイルのサイズが非常に大きくなり、分析が非常に困難になります。サーバーの実行中、server_audit_output_type =fileの場合、次のステートメントを使用してログファイルのローテーションを強制できます。
MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;自動ログローテーションの場合、MariaDB構成ファイル内に次の変数を設定する必要があります。
server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30または、SET GLOBALを使用してランタイムで動的に設定します（再起動は不要）：
MariaDB> SET GLOBAL server_audit_file_rotate_size=1000000;
MariaDB> SET GLOBAL server_audit_file_rotations=30;監査ログローテーションを無効にするには、server_audit_file_rotationsを0に設定します。デフォルト値は9です。ログローテーションは、指定されたしきい値に達すると自動的に実行され、最後の30ログを保持します。過去30日間の監査ログ。
SyslogまたはRsyslog機能を使用した監査
syslogまたはrsyslog機能を使用すると、中央リポジトリ内のさまざまなタイプのシステムからのロギングが可能になるため、ログ管理が容易になります。別のログコンポーネントを維持する代わりに、MariaDBAuditにsyslogにログを記録するように指示できます。これは、Splunk、LogStash、Loggly、AmazonCloudWatchなどのログアナライザーサービス用のログコレクター/ストリーマーがある場合に便利です。
これを行うには、MariaDB構成ファイル内に次の行を設定します（再起動が必要です）：
server_audit_logging = 'syslog'
server_audit_syslog_ident = 'mariadb-audit'または、ランタイムで変更する場合（再起動は不要ですが、永続的ではありません）：
MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';$ grep mariadb-audit /var/log/syslog
Mar 26 00:48:49 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,36,329540,QUERY,,'SET GLOBAL server_audit_syslog_ident = \'mariadb-audit\'',0
Mar 26 00:48:54 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,36,0,DISCONNECT,,,0一元化されたログリポジトリ用にリモートログサービスを設定する場合は、rsyslogを使用できます。秘訣は、以下のように、ロギングを容易にするフィルターを作成できる変数server_audit_syslog_facilityを使用することです。
MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';
MariaDB> SET GLOBAL server_audit_syslog_facility = 'LOG_LOCAL6';ただし、事前にいくつかの前提条件の手順があります。一元化されたrsyslogサーバーを備えた次のMariaDBマスタースレーブレプリケーションアーキテクチャを検討してください。
この例では、すべてのサーバーがUbuntu20.04で実行されています。 rsyslog宛先サーバーでは、/ etc/rsyslog.conf内に次のように設定する必要があります。
module(load="imtcp")
input(type="imtcp" port="514")
$ModLoad imtcp
$InputTCPServerRun 514
if $fromhost-ip=='172.31.0.44' then /var/log/mariadb-centralized-audit.log
& ~
if $fromhost-ip=='172.31.0.82' then /var/log/mariadb-centralized-audit.log
& ~「＆〜」の部分は重要であり、それを見逃さないように注意してください。基本的に、ログ機能に/var/log/mariadb-centralized-audit.logにログインし、その直後にそれ以上の処理を停止するように指示します。
次に、正しいファイル所有権と権限で宛先ログファイルを作成します：
$ touch /var/log/mariadb-centralized-audit.log
$ chown syslog:adm /var/log/mariadb-centralized-audit.log
$ chmod 640 /var/log/mariadb-centralized-audit.log
rsyslogを再起動します：
$ systemctl restart rsyslogTCPポート514でアクセス可能なすべてのIPアドレスをリッスンしていることを確認してください：
$ netstat -tulpn | grep rsyslog
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 3143247/rsyslogd
tcp6 0 0 :::514 :::* LISTEN 3143247/rsyslogd$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName queue1 # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g # 1GB space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList # run asynchronously
$ActionResumeRetryCount -1 # infinite retries if rsyslog host is down
local6.* action(type="omfwd" target="172.31.6.200" port="514" protocol="tcp")最初のセクションの設定は、ディスク上のキューの作成に関するものです。これは、ログエントリが失われないようにすることをお勧めします。最後の行は重要です。監査プラグインの変数server_audit_syslog_facilityをLOG_LOCAL6に変更しました。ここでは、TCPプロトコルを介してポート514のrsyslogサーバー172.31.6.200で実行されているrsyslogにファシリティlocal6を使用してSyslogエントリのみを転送するフィルターとして「local6。*」を指定しました。
rsyslogの変更をアクティブ化するには、最後のステップは、MariaDBサーバーでrsyslogを再起動して、変更をアクティブ化することです。
$ systemctl restart rsyslogこれで、rsyslogがソースノードで正しく構成されました。 MariaDBサーバーにアクセスしてテストし、監査イベントを生成するためのいくつかのアクティビティを実行できます。監査ログエントリがここに転送されるのを確認する必要があります：
$ tail -f /var/log/mariadb-centralized-audit.log
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,0,CONNECT,,,0
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,489413,QUERY,,'select @@version_comment limit 1',0
Mar 26 12:56:19 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,489414,QUERY,,'show databases',0
Mar 26 12:56:37 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,0,DISCONNECT,,,0MariaDB監査プラグインは、セキュリティおよび監査ポリシーに合わせてさまざまな方法で構成できます。監査情報は、パフォーマンスやアプリケーションの問題のトラブルシューティングに役立ち、処理されているSQLクエリを正確に確認できます。