このページは機械翻訳したものです。
MySQL Enterprise Firewall を使用する前に、セクション6.4.7.2「MySQL Enterprise Firewall のインストールまたはアンインストール」 に記載されている手順に従ってインストールします。
このセクションでは、SQL ステートメントを使用して MySQL Enterprise Firewall を構成する方法について説明します。 または、MySQL Workbench 6.3.4 以上では、ファイアウォール制御用のグラフィカルインタフェースが提供されます。 MySQL Enterprise Firewall Interfaceを参照してください。
ファイアウォールを有効または無効にするには、mysql_firewall_mode
システム変数を設定します。 デフォルトでは、この変数はファイアウォールのインストール時に有効になります。 ファイアウォールの初期状態を明示的に制御するには、サーバーの起動時に変数を設定します。 たとえば、オプションファイルでファイアウォールを有効にするには、次の行を使用します:
[mysqld]
mysql_firewall_mode=ON
my.cnf
を変更したら、新しい設定を有効にするためにサーバーを再起動します。
または、実行時にファイアウォール設定を設定して永続化するには:
SET PERSIST mysql_firewall_mode = OFF;
SET PERSIST mysql_firewall_mode = ON;
SET PERSIST
は、実行中の MySQL インスタンスの値を設定します。 また、値が保存され、その後のサーバーの再起動に引き継がれます。 後続の再起動に引き継ぐことなく、実行中の MySQL インスタンスの値を変更するには、PERSIST
ではなく GLOBAL
キーワードを使用します。 セクション13.7.6.1「変数代入の SET 構文」を参照してください。
ファイアウォールがインストールされている状態で、それを管理する予定の MySQL アカウントに適切な権限を付与します。 権限は、アカウントが実行を許可するファイアウォール操作によって異なります:
完全な管理ファイアウォールアクセスを必要とする任意のアカウントに
FIREWALL_ADMIN
権限を付与します。 (一部のユーザー定義プロシージャは、個々の UDF の説明に示されているように、FIREWALL_ADMIN
または非推奨のSUPER
権限を持つアカウントによって起動できます。)独自のファイアウォールルールに対してのみ管理アクセス権を持つアカウントに
FIREWALL_USER
権限を付与します。mysql
システムデータベースのファイアウォールストアドプロシージャに対するEXECUTE
権限を付与します。 これらは UDF を呼び出す可能性があるため、ストアドプロシージャアクセスには、これらの UDF に必要な前述の権限も必要です。
FIREWALL_ADMIN
および FIREWALL_USER
権限は、ファイアウォールコンポーネントで定義されているため、ファイアウォールのインストール中にのみ付与できます。
MySQL サーバーを使用すると、クライアントはそれらの SQL ステートメントとの間で接続および受信を実行できます。 サーバーは、構文エラーですぐには失敗しない各受信ステートメントをファイアウォールに渡します。 ファイアウォールがステートメントを受け入れるかどうかに基づいて、サーバーはステートメントを実行するか、クライアントにエラーを返します。
ファイアウォール操作は、ステートメントの実行保護を適用できるプロファイルのレジストリに基づいています。 プロファイルには次の属性があります:
プロファイルで受け入れ可能なステートメントを定義するルール。 このルールセットは、プロファイル allowlist を形成します。
現在の操作モード。 このモードでは、プロファイルを様々な方法で使用できます。 次に例を示します: プロファイルをトレーニングモードにすると、許可リストを確立できます。許可リストは、ステートメントの実行または侵入の検出を制限するために使用できます。プロファイルは完全に無効にできます。
-
プロファイルが適用されるクライアント接続を示す適用範囲。
ファイアウォールは、各プロファイルが特定のクライアントアカウント (クライアントユーザー名とホスト名の組み合わせ) に一致するように、アカウントベースのプロファイルをサポートしています。 たとえば、許可リストが
admin@localhost
からの接続に適用されるアカウントプロファイルと、許可リストがmyapp@apphost.example.com
からの接続に適用される別のアカウントプロファイルを登録できます。MySQL 8.0.23 では、ファイアウォールは複数のアカウントをメンバーとして持つことができるグループプロファイルもサポートしています。 グループプロファイルを使用すると、管理が容易になり、特定の一連の許可リストルールを複数のアカウントに適用する必要があるデプロイメントの柔軟性が向上します:
アカウントプロファイルを使用して、アカウントごとに 1 つのプロファイルを登録し、各プロファイル間で許可リストを複製する必要があります。
より簡単な方法として、すべてのアカウントをメンバーとして持つグループプロファイルを使用できます。 グループプロファイル allowlist はすべてのメンバーアカウントに適用され、アカウントごとに複製する必要はありません。
クライアント接続ごとに、ファイアウォールはどのプロファイルを適用するかを決定し、プロファイルで許可されているステートメントのみを受け入れます。 (クライアントがプロファイルに一致しない場合、ファイアウォールはそれを無視し、すべてのステートメントを受け入れます。)
デフォルトでは、ファイアウォールはすべてのステートメントを受け入れ、MySQL アカウントが実行できるステートメントには影響しません。 ファイアウォール保護機能を適用するには、明示的なアクションを実行する必要があります:
ファイアウォールに 1 つ以上のプロファイルを登録します。 (これは、ファイアウォールがプロファイルに一致しないクライアントを無視するために必要です。)
ファイアウォールをトレーニングして、各プロファイルの許可リスト (つまり、プロファイルがクライアントに実行を許可するステートメントのタイプ) を確立します。
トレーニングされた各プロファイルを使用して MySQL を保護するようにファイアウォールに指示します。つまり、クライアントの接続時に受信ステートメントを適切な許可リストと照合します。
ファイアウォールによって実行されるステートメント照合では、クライアントから受信した SQL ステートメントは使用されません。 かわりに、サーバーは受信ステートメントを正規化されたダイジェスト形式に変換し、ファイアウォール操作はこれらのダイジェストを使用します。 ステートメントの正規化の利点は、単一のパターンを使用して同様のステートメントをグループ化および認識できることです。 たとえば、次のステートメントは互いに異なります:
SELECT first_name, last_name FROM customer WHERE customer_id = 1;
select first_name, last_name from customer where customer_id = 99;
SELECT first_name, last_name FROM customer WHERE customer_id = 143;
ただし、これらはすべて同じ正規化ダイジェストフォームを持ちます:
SELECT `first_name` , `last_name` FROM `customer` WHERE `customer_id` = ?
正規化を使用することで、ファイアウォールは、クライアントから受信した様々なステートメントにそれぞれ一致する許可ダイジェストに格納できます。 正規化およびダイジェストの詳細は、セクション27.10「パフォーマンススキーマのステートメントダイジェストとサンプリング」 を参照してください。
ファイアウォールに登録された各プロファイルには、次の値から選択された独自の操作モードがあります:
OFF
: このモードでは、プロファイルが無効になります。 ファイアウォールは非アクティブとみなし、無視します。-
RECORDING
: これはファイアウォールトレーニングモードです。 プロファイルと一致するクライアントから受信した受信ステートメントは、プロファイルで受け入れ可能とみなされ、その「「指紋」」の一部になります。 ファイアウォールは、各ステートメントの正規化されたダイジェスト形式を記録して、プロファイルの受け入れ可能なステートメントパターンを学習します。 各パターンはルールであり、ルールの和集合はプロファイル allowlist です。アカウントプロファイルとグループプロファイルの違いは、グループプロファイルのステートメントの記録を単一のグループメンバーから受け取ったステートメントに制限できることです。
PROTECTING
: このモードでは、プロファイルによってステートメントの実行が許可または防止されます。 ファイアウォールは、受信ステートメントをプロファイル allowlist と照合し、一致しないステートメントのみを受け入れて拒否します。RECORDING
モードでプロファイルをトレーニングした後、PROTECTING
モードに切り替えて、許可リストから逸脱するステートメントによるアクセスに対して MySQL を強化します。DETECTING
: このモードでは、侵入 (プロファイル allowlist 内で何にも一致しないため疑わしいステートメント) は検出されますが、ブロックされません。DETECTING
モードでは、ファイアウォールは疑わしいステートメントをエラーログに書き込みますが、アクセスを拒否せずに受け入れます。
プロファイルに前述のモード値のいずれかが割り当てられると、ファイアウォールはそのモードをプロファイルに格納します。 ファイアウォールモード設定操作では RESET
のモード値も許可されますが、この値は格納されません: プロファイルを RESET
モードに設定すると、ファイアウォールはプロファイルのすべてのルールを削除し、そのモードを OFF
に設定します。
次のセクションでは、ファイアウォールプロファイルの使用方法について説明します。 簡単にするために、この説明では単一のアカウントプロファイルと単一のグループプロファイルの設定について説明し、複数のプロファイルが同時に適用された場合にファイアウォールがどのように動作するかについて、より複雑なケースに移動します。
MySQL Enterprise Firewall では、個々のアカウントに対応するプロファイルを登録できます。
MySQL は、特定のユーザー名とホスト名の組合せに対して各クライアントセッションを認証します。 この組合せはセッションアカウントです。 ファイアウォールは、セッションアカウントを登録済アカウントプロファイルと照合して、セッションからの受信ステートメントの処理に適用されるプロファイルを決定します:
ファイアウォールは非アクティブなプロファイル (
OFF
モードのプロファイル) を無視します。セッションアカウントは、同じユーザーとホストを持つアクティブなアカウントプロファイルと一致します (存在する場合)。 そのようなアカウントプロファイルは最大 1 つあります。
つまり、特定のセッションには最大 1 つのアクティブなアカウントプロファイルを適用でき、ファイアウォールは各受信ステートメントを次のように処理します:
適用可能なプロファイルがない場合、制限はありません。 ファイアウォールはステートメントを受け入れます。
-
適用可能なプロファイルがある場合、そのモードによってステートメントの処理が決定されます:
RECORDING
モードでは、ファイアウォールはプロファイル allowlist ルールにステートメントを追加し、それを受け入れます。PROTECTING
モードでは、ファイアウォールはステートメントをプロファイル allowlist のルールと比較します。 ファイアウォールは、一致がある場合はステートメントを受け入れ、それ以外の場合は拒否します。mysql_firewall_trace
システム変数が有効になっている場合、ファイアウォールは拒否されたステートメントもエラーログに書き込みます。DETECTING
モードでは、ファイアウォールはアクセスを拒否せずに侵入を検出します。 ファイアウォールはステートメントを受け入れますが、PROTECTING
モードと同様にプロファイル allowlist にも一致します。 ステートメントが疑わしい (不一致) 場合、ファイアウォールはそれをエラーログに書き込みます。
この説明は、セッションアカウントが 1 つ以上の適用可能なアカウントプロファイルと一致することを前提としているため、簡略化されています。 複数プロファイルの場合については、複数の適用可能なプロファイルに対するファイアウォール操作 を参照してください。
ファイアウォールアカウントプロファイルを使用して、特定のアカウントからの受信ステートメントから MySQL を保護するには、次のステップに従います:
アカウントプロファイルを登録し、
RECORDING
モードにします。アカウントを使用して MySQL サーバーに接続し、学習するステートメントを実行します。 これにより、対応するアカウントプロファイルがトレーニングされ、プロファイル allowlist を形成するルールが設定されます。
アカウントプロファイルを
PROTECTING
モードに切り替えます。 クライアントがアカウントを使用してサーバーに接続すると、アカウントプロファイル allowlist によってステートメントの実行が制限されます。追加のトレーニングが必要な場合は、アカウントプロファイルを再度
RECORDING
モードに切り替え、新しいステートメントパターンで許可リストを更新してから、PROTECTING
モードに戻します。
プロファイルを維持することで、ファイアウォールは次のような保護戦略の実装を可能にします:
アプリケーションに一意の保護要件がある場合は、他の目的に使用されていないアカウントを使用するように構成し、対応するアカウントプロファイルを設定します。
-
関連アプリケーションで保護要件を共有する場合は、すべて同じアカウント (および同じアカウントプロファイル) を使用するように構成します。
または、各アプリケーションを独自のアカウントに関連付けてから、これらのアカウントを同じグループプロファイルに追加します。 ファイアウォールグループプロファイルの登録を参照してください。
ファイアウォール関連のアカウント参照については、次のガイドラインに従います:
-
アカウント参照が発生するコンテキストに注意してください。 ファイアウォール操作のアカウントに名前を付けるには、一重引用符で囲まれた文字列 (
'
) として指定します。 これは、アカウント名のユーザー部分とホスト部分を別々に引用符で囲むuser_name
@host_name
'CREATE USER
やGRANT
などのステートメントの通常の MySQL 規則とは異なります ('
)。user_name
'@'host_name
'ファイアウォール操作のために一重引用符で囲まれた文字列としてアカウントに名前を付ける要件は、ユーザー名に
@
文字が埋め込まれているアカウントを使用できないことを意味します。 -
ファイアウォールは、サーバーによって認証された実際のユーザー名とホスト名で表されるアカウントに対してステートメントを評価します。 アカウントプロファイルを登録する場合は、ワイルドカード文字またはネットマスクを使用しないでください:
me@%.example.org
という名前のアカウントが存在し、クライアントがそれを使用してホストabc.example.org
からサーバーに接続するとします。アカウント名には
%
ワイルドカード文字が含まれていますが、サーバーは、ユーザー名がme
でホスト名がabc.example.com
であること、つまりファイアウォールに表示されることとしてクライアントを認証します。したがって、ファイアウォール操作に使用するアカウント名は、
me@%.example.org
ではなくme@abc.example.org
です。
次の例では、アカウントプロファイルをファイアウォールに登録し、そのプロファイルの受入れ可能なステートメントをファイアウォールに指示し、そのプロファイルを使用して、アカウントによる受入れ不可能なステートメントの実行から MySQL を保護する方法を示します。 サンプルアカウント fwuser@localhost
は、sakila
データベース (https://dev.mysql.com/doc/index-other.html で入手可能) のテーブルにアクセスするアプリケーションで使用することを前提としています。
ファイアウォールに登録されたアカウントプロファイルに対応する fwuser@localhost
アカウントで実行するように指定されたステップを除き、管理 MySQL アカウントを使用してこの手順のステップを実行します。 このアカウントを使用して実行されるステートメントの場合、デフォルトのデータベースは sakila
である必要があります。 (指示を適宜調整することで、別のデータベースを使用できます。)
-
必要に応じて、ステートメントの実行に使用するアカウントを作成し (適切なパスワードを選択)、
sakila
データベースに対する権限を付与します:CREATE USER 'fwuser'@'localhost' IDENTIFIED BY 'password'; GRANT ALL ON sakila.* TO 'fwuser'@'localhost';
-
sp_set_firewall_mode()
ストアドプロシージャを使用して、アカウントプロファイルをファイアウォールに登録し、プロファイルをRECORDING
(トレーニング) モードにします:CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'RECORDING');
ストアドプロシージャは、実行時にファイアウォールのユーザー定義関数を起動し、独自の出力を生成できます。
-
登録済アカウントプロファイルをトレーニングするには、ファイアウォールに
fwuser@localhost
のセッションアカウントが表示されるように、サーバーホストからfwuser
としてサーバーに接続します。 次に、アカウントを使用して、プロファイルに対して正当とみなされるいくつかのステートメントを実行します。 例:SELECT first_name, last_name FROM customer WHERE customer_id = 1; UPDATE rental SET return_date = NOW() WHERE rental_id = 1; SELECT get_customer_balance(1, NOW());
プロファイルは
RECORDING
モードであるため、ファイアウォールは正規化されたダイジェスト形式のステートメントをルールとしてプロファイル allowlist に記録します。注記fwuser@localhost
アカウントプロファイルがRECORDING
モードでステートメントを受信するまで、その allowlist は空であり、これは「「すべて拒否」」と同等です。 空の allowlist に一致するステートメントはないため、次のような影響があります:アカウントプロファイルを
PROTECTING
モードに切り替えることはできません。 すべてのステートメントが拒否され、アカウントによるステートメントの実行が事実上禁止されます。アカウントプロファイルは
DETECTING
モードに切り替えることができます。 この場合、プロファイルはすべてのステートメントを受け入れますが、疑わしいステートメントとして記録します。
-
この時点で、アカウントプロファイル情報がキャッシュされます。 この情報を表示するには、ファイアウォール
INFORMATION_SCHEMA
テーブルをクエリーします:mysql> SELECT MODE FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_USERS WHERE USERHOST = 'fwuser@localhost'; +-----------+ | MODE | +-----------+ | RECORDING | +-----------+ mysql> SELECT RULE FROM INFORMATION_SCHEMA.MYSQL_FIREWALL_WHITELIST WHERE USERHOST = 'fwuser@localhost'; +----------------------------------------------------------------------------+ | RULE | +----------------------------------------------------------------------------+ | SELECT `first_name` , `last_name` FROM `customer` WHERE `customer_id` = ? | | SELECT `get_customer_balance` ( ? , NOW ( ) ) | | UPDATE `rental` SET `return_date` = NOW ( ) WHERE `rental_id` = ? | | SELECT @@`version_comment` LIMIT ? | +----------------------------------------------------------------------------+
注記@@version_comment
ルールは、アカウントプロファイルに対応するアカウントを使用してサーバーに接続したときに、mysql クライアントによって自動的に送信されるステートメントから取得されます。重要アプリケーションの使用に一致する条件でファイアウォールをトレーニングします。 たとえば、サーバーの特性と機能を判断するために、特定の MySQL コネクタが各セッションの開始時にサーバーにステートメントを送信する場合があります。 アプリケーションが通常そのコネクタを介して使用される場合は、コネクタを使用してファイアウォールもトレーニングします。 これにより、これらの初期ステートメントを、アプリケーションに関連付けられたアカウントプロファイルの許可リストの一部にすることができます。
-
sp_set_firewall_mode()
を再度起動します。今回は、アカウントプロファイルをPROTECTING
モードに切り替えます:CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'PROTECTING');
重要アカウントプロファイルを
RECORDING
モードから切り替えると、キャッシュされたデータが、基礎となる永続的な記憶域を提供するmysql
システムデータベーステーブルと同期されます。 記録されているプロファイルのモードを切り替えない場合、キャッシュされたデータは永続ストレージに書き込まれず、サーバーの再起動時に失われます。 -
アカウントを使用して、許容できるステートメントと許容できないステートメントを実行し、アカウントプロファイルをテストします。 ファイアウォールは、各ステートメントをプロファイル allowlist と照合し、それを受け入れるか拒否します:
-
このステートメントはトレーニングステートメントと同じではありませんが、いずれかのステートメントと同じ正規化ステートメントを生成するため、ファイアウォールはそれを受け入れます:
mysql> SELECT first_name, last_name FROM customer WHERE customer_id = '48'; +------------+-----------+ | first_name | last_name | +------------+-----------+ | ANN | EVANS | +------------+-----------+
-
これらのステートメントは allowlist 内の何も一致しないため、ファイアウォールはそれぞれエラーで拒否します:
mysql> SELECT first_name, last_name FROM customer WHERE customer_id = 1 OR TRUE; ERROR 1045 (28000): Statement was blocked by Firewall mysql> SHOW TABLES LIKE 'customer%'; ERROR 1045 (28000): Statement was blocked by Firewall mysql> TRUNCATE TABLE mysql.slow_log; ERROR 1045 (28000): Statement was blocked by Firewall
-
mysql_firewall_trace
システム変数が有効になっている場合、ファイアウォールは拒否されたステートメントもエラーログに書き込みます。 例:[Note] Plugin MYSQL_FIREWALL reported: 'ACCESS DENIED for fwuser@localhost. Reason: No match in whitelist. Statement: TRUNCATE TABLE `mysql` . `slow_log` '
これらのログメッセージは、必要に応じて攻撃の原因を特定する際に役立ちます。
-
ファイアウォールアカウントプロファイルは、fwuser@localhost
アカウントについてトレーニングされるようになりました。 クライアントがそのアカウントを使用して接続し、ステートメントを実行しようとすると、プロファイルによって、プロファイル allowlist で一致しないステートメントから MySQL が保護されます。
一致しないステートメントをアクセスを拒否せずに疑わしいステートメントとして記録することで、侵入を検出することもできます。 まず、アカウントプロファイルを DETECTING
モードにします:
CALL mysql.sp_set_firewall_mode('fwuser@localhost', 'DETECTING');
次に、アカウントを使用して、アカウントプロファイル allowlist と一致しないステートメントを実行します。 DETECTING
モードでは、ファイアウォールは一致しないステートメントの実行を許可します:
mysql> SHOW TABLES LIKE 'customer%';
+------------------------------+
| Tables_in_sakila (customer%) |
+------------------------------+
| customer |
| customer_list |
+------------------------------+
さらに、ファイアウォールはエラーログにメッセージを書き込みます:
[Note] Plugin MYSQL_FIREWALL reported:
'SUSPICIOUS STATEMENT from 'fwuser@localhost'. Reason: No match in whitelist.
Statement: SHOW TABLES LIKE ? '
DETECTING
モードでは、メッセージはノート (情報メッセージ) として書き込まれます。 このようなメッセージがエラーログに表示され、破棄されないようにするには、情報メッセージを記録するためにエラーロギングの冗長性が十分であることを確認します。 たとえば、セクション5.4.2.5「優先度ベースのエラーログのフィルタリング (log_filter_internal)」 で説明されている優先度ベースのログフィルタリングを使用している場合は、log_error_verbosity
システム変数の値を 3 に設定します。
アカウントプロファイルを無効にするには、そのモードを OFF
に変更します:
CALL mysql.sp_set_firewall_mode(user, 'OFF');
プロファイルのすべてのトレーニングを忘れて無効にするには、リセットします:
CALL mysql.sp_set_firewall_mode(user, 'RESET');
リセット操作により、ファイアウォールはプロファイルのすべてのルールを削除し、そのモードを OFF
に設定します。
MySQL Enterprise Firewall では、個々のアカウントに対応するサポートプロファイルに加えて、MySQL 8.0.23 の時点でグループプロファイルがサポートされています。 グループプロファイルは、そのメンバーとして複数のアカウントを持つことができます。
グループプロファイルは、次の点でアカウントプロファイルと異なります:
グループプロファイルの場合、その許可リストは、セッションアカウントがグループのいずれかのメンバーと一致するときに適用されます。 グループプロファイルを使用すると、アカウントごとに許可リスト内の各ルールを複製せずに、特定の許可リストを複数のアカウントに適用できます。
アカウントプロファイルは、それが適用される単一のアカウントを使用してのみトレーニングできます。 グループプロファイルは、グループメンバーアカウントのいずれかまたはすべてを使用してトレーニングすることも、それらのアカウントのいずれかに限定することもできます。
アカウントプロファイル名は、MySQL サーバーに接続するクライアントに依存する特定のユーザー名とホスト名の組合せに基づきます。 グループプロファイル名は、長さが 1 から 288 文字である必要があるという制約なしで選択されます。
その他の点では、アカウントプロファイルの使用に関する原則は、グループプロファイルの使用にも適用されます。 ここでは、これらの原則をよく理解していることを前提としています。ファイアウォールアカウントプロファイルの登録 を参照してください。
この説明は、セッションアカウントが 1 つ以上の適用可能なグループプロファイルと一致することを前提としているため、簡略化されています。 複数プロファイルの場合については、複数の適用可能なプロファイルに対するファイアウォール操作 を参照してください。
次の例では、グループプロファイルをファイアウォールに登録し、その許可リストをトレーニングし、それを使用して MySQL を許容できないステートメントの実行から保護し、メンバーを追加および削除する方法を示します。 この例では、mygrp
のグループプロファイル名を使用します。
管理 MySQL アカウントを使用して、この手順の手順を実行します。ただし、ファイアウォールグループプロファイルのメンバーアカウントによって実行されるように指定された手順は除きます。
-
必要に応じて、
mygrp
グループプロファイルのメンバーとなるアカウントを作成し、適切なアクセス権限を付与します。 1 つのメンバーに対するステートメントを次に示します (適切なパスワードを選択してください):CREATE USER 'member1'@'localhost' IDENTIFIED BY 'password'; GRANT ALL ON sakila.* TO 'member1'@'localhost';
-
sp_set_firewall_group_mode()
ストアドプロシージャを使用して、グループプロファイルをファイアウォールに登録し、そのプロファイルをRECORDING
(トレーニング) モードにします:CALL mysql.sp_set_firewall_group_mode('mygrp', 'RECORDING');
-
sp_firewall_group_enlist()
ストアドプロシージャを使用して、グループプロファイル許可リストのトレーニングに使用する初期メンバーアカウントを追加します:CALL mysql.sp_firewall_group_enlist('mygrp', 'member1@localhost');
-
グループプロファイルのトレーニングに初期メンバーアカウントを使用するには、サーバーホストから
member1
としてサーバーに接続し、ファイアウォールにmember1@localhost
のセッションアカウントが表示されるようにします。 次に、プロファイルに対して正当とみなされるいくつかのステートメントを実行します。 例:SELECT title, description FROM film WHERE film_id = 1; UPDATE actor SET last_update = NOW() WHERE actor_id = 1; SELECT store_id, COUNT(*) FROM inventory GROUP BY store_id;
ファイアウォールは、
member1@localhost
アカウントからステートメントを受け取ります。 このアカウントはRECORDING
モードのmygrp
プロファイルのメンバーであるため、ファイアウォールはステートメントをmygrp
に適用可能として解釈し、正規化されたダイジェスト形式のステートメントをmygrp
許可リスト内のルールとして記録します。 これらのルールは、mygrp
のメンバーであるすべてのアカウントに適用されます。 -
この時点で、名前、メンバーシップ、許可リストなどのグループプロファイル情報がキャッシュされます。 この情報を表示するには、ファイアウォールの「パフォーマンススキーマ」テーブルをクエリーします:
mysql> SELECT MODE FROM performance_schema.firewall_groups WHERE NAME = 'mygrp'; +-----------+ | MODE | +-----------+ | RECORDING | +-----------+ mysql> SELECT * FROM performance_schema.firewall_membership ORDER BY USERHOST; +------------+-------------------+ | GROUP_NAME | USERHOST | +------------+-------------------+ | mygrp | member1@localhost | +------------+-------------------+ mysql> SELECT RULE FROM performance_schema.firewall_group_allowlist WHERE NAME = 'mygrp'; +----------------------------------------------------------------------+ | RULE | +----------------------------------------------------------------------+ | SELECT @@`version_comment` LIMIT ? | | SELECT `title` , DESCRIPTION FROM `film` WHERE `film_id` = ? | | UPDATE `actor` SET `last_update` = NOW ( ) WHERE `actor_id` = ? | | SELECT `store_id` , COUNT ( * ) FROM `inventory` GROUP BY `store_id` | +----------------------------------------------------------------------+
-
sp_set_firewall_group_mode()
を再度起動して、グループプロファイルをPROTECTING
モードに切り替えます:CALL mysql.sp_set_firewall_group_mode('mygrp', 'PROTECTING');
-
メンバーである必要がある他のアカウントをグループプロファイルに追加します:
CALL mysql.sp_firewall_group_enlist('mygrp', 'member2@localhost'); CALL mysql.sp_firewall_group_enlist('mygrp', 'member3@localhost'); CALL mysql.sp_firewall_group_enlist('mygrp', 'member4@localhost');
member1@localhost
アカウントを使用してトレーニングされたプロファイル許可リストは、追加アカウントにも適用されるようになりました。 -
更新されたグループメンバーシップを確認するには、
firewall_membership
テーブルを再度クエリーします:mysql> SELECT * FROM performance_schema.firewall_membership ORDER BY USERHOST; +------------+-------------------+ | GROUP_NAME | USERHOST | +------------+-------------------+ | mygrp | member1@localhost | | mygrp | member2@localhost | | mygrp | member3@localhost | | mygrp | member4@localhost | +------------+-------------------+
グループ内の任意のアカウントを使用してファイアウォールに対してグループプロファイルをテストし、受け入れ可能なステートメントと受け入れられないステートメントを実行します。 ファイアウォールは、アカウントからの各ステートメントをプロファイル許可リストと照合し、それを受け入れるか拒否します。
-
グループプロファイルからメンバーを削除する必要がある場合は、
sp_firewall_group_enlist()
ではなくsp_firewall_group_delist()
ストアドプロシージャを使用します:CALL mysql.sp_firewall_group_delist('mygrp', 'member3@localhost');
前述の手順では、許可リストをトレーニングする前に、1 人のメンバーのみをグループプロファイルに追加しました。 こうすることで、新規の許容ステートメントを許可リストに追加できるアカウントを制限することで、研修期間をより適切に制御できます。 追加のトレーニングが必要な場合は、プロファイルを RECORDING
モードに戻すことができます:
CALL mysql.sp_set_firewall_group_mode('mygrp', 'RECORDING');
ただし、グループの任意のメンバーがステートメントを実行して許可リストに追加できるようになります。 追加のトレーニングを単一のグループメンバーに制限するには、sp_set_firewall_group_mode_and_user()
をコールします。これは sp_set_firewall_group_mode()
に似ていますが、RECORDING
モードでプロファイルのトレーニングを許可するアカウントを指定する引数を使用します。 たとえば、member4@localhost
によるトレーニングのみを有効にするには、次のようにします:
CALL mysql.sp_set_firewall_group_mode_and_user('mygrp', 'RECORDING', 'member4@localhost');
これにより、他のグループメンバーを削除せずに、指定したアカウントによる追加のトレーニングが可能になります。 ステートメントを実行できますが、そのステートメントは許可リストに追加されません。 (ただし、RECORDING
モードでは、他のメンバーが任意のステートメントを実行できることに注意してください。)
追加のトレーニングの後、グループプロファイルを PROTECTING
モードに戻します:
CALL mysql.sp_set_firewall_group_mode('mygrp', 'PROTECTING');
sp_set_firewall_group_mode_and_user()
によって確立されたトレーニングアカウントはグループプロファイルに保存されるため、後でさらにトレーニングが必要になった場合に備えて、ファイアウォールに保存されます。 したがって、sp_set_firewall_group_mode()
(トレーニングアカウント引数なし) をコールした場合、現在のプロファイルトレーニングアカウントである member4@localhost
は変更されません。
すべてのグループメンバーが RECORDING
モードでトレーニングを実行できるようにする必要がある場合にトレーニングアカウントをクリアするには、sp_set_firewall_group_mode_and_user()
をコールし、アカウント引数に NULL
値を渡します:
CALL mysql.sp_set_firewall_group_mode_and_user('mygrp', 'RECORDING', NULL);
特定のアカウントがグループプロファイルのトレーニングアカウントとして指定された場合の予期しない動作を回避するには、そのアカウントがグループのメンバーであることを常に確認してください。
アカウントプロファイルと同様に、侵入検出の場合は DETECTING
のモード、プロファイルを無効にする場合は OFF
、プロファイルルールを忘れてそのモードを OFF
に設定する場合は RESET
のモードをグループプロファイルに割り当てることができます。
簡単にするために、前のセクションでは、ファイアウォールがクライアントからの受信ステートメントを単一のプロファイル (アカウントプロファイルまたはグループプロファイル) に対してのみ照合する観点を説明しました。 ただし、ファイアウォール操作はより複雑になる可能性があります:
グループプロファイルには、複数のアカウントをメンバーとして含めることができます。
アカウントは、複数のグループプロファイルのメンバーになることができます。
複数のプロファイルを特定のクライアントに一致させることができます。
このセクションでは、複数のプロファイルが受信ステートメントに適用される場合のファイアウォールの動作について説明します。 この説明では、単一の適用可能なアカウントまたはグループプロファイルで前述したケースを含む、一般的なケースについて説明します。
MySQL は、特定のユーザー名とホスト名の組合せに対して各クライアントセッションを認証します。 この組合せはセッションアカウントです。 ファイアウォールは、セッションアカウントを登録済プロファイルと照合して、セッションからの受信ステートメントの処理に適用するプロファイルを決定します:
ファイアウォールは非アクティブなプロファイル (
OFF
モードのプロファイル) を無視します。セッションアカウントは、同じユーザーとホストを持つアクティブなアカウントプロファイルと一致します (存在する場合)。 そのようなアカウントプロファイルは最大 1 つあります。
セッションアカウントは、同じユーザーおよびホストを持つメンバーを含むすべてのアクティブなグループプロファイルと一致します。 そのようなグループプロファイルは複数存在できます。
つまり、セッションアカウントは、0 個または 1 個のアクティブなアカウントプロファイルと、0 個以上のアクティブなグループプロファイルと一致します。 つまり、0、1 または複数のファイアウォールプロファイルが特定のセッションに適用可能であり、ファイアウォールが各受信ステートメントを次のように処理することを意味します:
適用可能なプロファイルがない場合、制限はありません。 ファイアウォールはステートメントを受け入れます。
-
適用可能なプロファイルがある場合は、そのモードによってステートメントの処理が決まります:
ファイアウォールは、
RECORDING
モードの適用可能な各プロファイルの許可リストにステートメントを記録します。ファイアウォールは、
DETECTING
モードの適用可能な各プロファイルのエラーログにステートメントを書き込みます。少なくとも 1 つの適用可能なプロファイルが
RECORDING
モードまたはDETECTING
モードの場合 (これらのモードはすべてのステートメントを受け入れます)、あるいは少なくとも 1 つの適用可能なプロファイルの許可リストとPROTECTING
モードで一致する場合、ファイアウォールはそのステートメントを受け入れます。 そうでない場合、ファイアウォールはステートメントを拒否します (mysql_firewall_trace
システム変数が有効になっている場合はエラーログに書き込みます)。
ファイアウォールアクティビティを評価するには、そのステータス変数を調べます。 たとえば、前述の手順を実行して fwuser@localhost
アカウントをトレーニングおよび保護すると、変数は次のようになります:
mysql> SHOW GLOBAL STATUS LIKE 'Firewall%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Firewall_access_denied | 3 |
| Firewall_access_granted | 4 |
| Firewall_access_suspicious | 1 |
| Firewall_cached_entries | 4 |
+----------------------------+-------+
変数は、拒否されたステートメント、受け入れられたステートメント、疑わしいステートメントとして記録されたステートメントおよびキャッシュに追加されたステートメントの数をそれぞれ示します。 登録済アカウントを使用して接続した 3 回ごとに mysql クライアントによって送信される@@version_comment
ステートメントと DETECTING
モードでブロックされなかった SHOW TABLES
ステートメントのため、Firewall_access_granted
数は 4 です。