MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.3.3 レプリケーション権限チェック

9.1 English
9.0 English
8.4 English
8.0 English

MySQL 8.0 リファレンスマニュアル / ... / レプリケーション権限チェック

このページは機械翻訳したものです。

17.3.3 レプリケーション権限チェック

17.3.3.1 レプリケーション PRIVILEGE_CHECKS_USER アカウントの権限
17.3.3.2 グループレプリケーションチャネルの権限チェック
17.3.3.3 失敗したレプリケーション権限チェックからのリカバリ

デフォルトでは、別のサーバーによってすでに受け入れられたトランザクションがレプリカまたはグループメンバーに適用されている場合、MySQL レプリケーション (グループレプリケーションを含む) は権限チェックを実行しません。 MySQL 8.0.18 から、通常はチャネルでレプリケートされるトランザクションを適用する適切な権限を持つユーザーアカウントを作成し、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 の場合) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 の場合) を使用して、これをレプリケーションアプライアンスの PRIVILEGE_CHECKS_USER アカウントとして指定できます。次に、MySQL は各トランザクションをユーザーアカウント権限と照合してチェックし、そのチャネルに対する操作が認可されていることを確認します。管理者は、このアカウントを安全に使用して、チャネルのレプリケーションエラーからのリカバリなど、mysqlbinlog 出力からトランザクションを適用または再適用することもできます。

PRIVILEGE_CHECKS_USER アカウントを使用すると、権限のある操作または不要な操作の不正または誤った使用からレプリケーションチャネルを保護できます。 PRIVILEGE_CHECKS_USER アカウントは、次のような状況で追加のセキュリティレイヤーを提供します:

あなたは、組織のネットワーク上のサーバーインスタンスと、クラウドサービスプロバイダによって提供されるインスタンスなど、別のネットワーク上のサーバーインスタンスの間でレプリケートしています。
すべてのデプロイメントに対して 1 つの管理者アカウント権限を付与せずに、複数のオンプレミスデプロイメントまたはオフサイトデプロイメントを別々のユニットとして管理する場合。
管理者がサーバーインスタンスに対する広範囲の権限を持つのではなく、レプリケーションチャネルおよびレプリケーションチャネルがレプリケートするデータベースに直接関連する操作のみを実行できるようにする管理者アカウントが必要です。

チャネルの PRIVILEGE_CHECKS_USER アカウントを指定するときに、次のいずれかまたは両方のオプションを CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントに追加することで、権限チェックが適用されるレプリケーションチャネルのセキュリティを強化できます:

REQUIRE_ROW_FORMAT オプション (MySQL 8.0.19 から使用可能) は、レプリケーションチャネルが行ベースのレプリケーションイベントのみを受け入れるようにします。 REQUIRE_ROW_FORMAT が設定されている場合、ソースサーバーで行ベースのバイナリロギング (binlog_format=ROW) を使用する必要があります。 MySQL 8.0.18 では、REQUIRE_ROW_FORMAT は使用できませんが、セキュアなレプリケーションチャネルに行ベースのバイナリロギングを使用することを強くお薦めします。ステートメントベースのバイナリロギングでは、PRIVILEGE_CHECKS_USER アカウントがトランザクションを正常に実行するために、一部の管理者レベルの権限が必要になる場合があります。
REQUIRE_TABLE_PRIMARY_KEY_CHECK オプション (MySQL 8.0.20 から使用可能) は、レプリケーションチャネルが主キーチェックに独自のポリシーを使用するようにします。 ON を設定することは、主キーが常に必要であり、OFF を設定することは、主キーが不要であることを意味します。デフォルト設定の STREAM では、各トランザクションのソースからレプリケートされた値を使用して、sql_require_primary_key システム変数のセッション値が設定されます。 PRIVILEGE_CHECKS_USER が設定されている場合、REQUIRE_TABLE_PRIMARY_KEY_CHECK を ON または OFF に設定することは、sql_require_primary_key の値を変更するために必要な、制限されたセッション変数を設定するためのセッション管理レベルの権限をユーザーアカウントが必要としないことを意味します。また、様々なソースのレプリケーションチャネル間の動作を正規化します。

レプリケーションアプライヤスレッドの PRIVILEGE_CHECKS_USER としてユーザーアカウントを表示できるようにし、mysqlbinlog で使用される内部使用 BINLOG ステートメントを実行するには、REPLICATION_APPLIER 権限を付与します。 PRIVILEGE_CHECKS_USER アカウントのユーザー名とホスト名は、セクション6.2.4「アカウント名の指定」で説明されている構文に従う必要があり、ユーザーは匿名ユーザー (ユーザー名が空白) または CURRENT_USER であってはなりません。新しいアカウントを作成するには、CREATE USER を使用します。このアカウントに REPLICATION_APPLIER 権限を付与するには、GRANT ステートメントを使用します。たとえば、example.com ドメイン内の任意のホストから管理者が手動で使用でき、暗号化された接続が必要なユーザーアカウント priv_repl を作成するには、次のステートメントを発行します:

mysql> SET sql_log_bin = 0;
mysql> CREATE USER 'priv_repl'@'%.example.com' IDENTIFIED BY 'password' REQUIRE SSL;
mysql> GRANT REPLICATION_APPLIER ON *.* TO 'priv_repl'@'%.example.com';
mysql> SET sql_log_bin = 1;

SET sql_log_bin ステートメントは、アカウント管理ステートメントがバイナリログに追加されず、レプリケーションチャネルに送信されないように使用されます (セクション13.4.1.3「SET sql_log_bin ステートメント」を参照)。

重要

caching_sha2_password 認証プラグインは、MySQL 8.0 から作成された新規ユーザーのデフォルトです (詳細は、セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」を参照)。このプラグインで認証するユーザーアカウントを使用してサーバーに接続するには、セクション17.3.1「暗号化接続を使用するためのレプリケーションの設定」の説明に従って暗号化された接続を設定するか、RSA キーペアを使用したパスワード交換をサポートするように暗号化されていない接続を有効にする必要があります。

ユーザーアカウントを設定した後、GRANT ステートメントを使用して追加の権限を付与し、サーバーに保持されている特定のテーブルの更新など、アプライヤスレッドが実行する予定のデータベース変更をユーザーアカウントが実行できるようにします。レプリケーションチャネルでこれらのトランザクションのいずれかを手動で実行する必要がある場合、管理者はこれらの同じ権限を使用できます。適切な権限を付与しなかった予期しない操作が試行された場合、操作は許可されず、レプリケーションアプライヤスレッドはエラーで停止します。セクション17.3.3.1「レプリケーション PRIVILEGE_CHECKS_USER アカウントの権限」では、アカウントに必要な追加の権限について説明します。たとえば、priv_repl ユーザーアカウントに db1 の cust テーブルに行を追加する INSERT 権限を付与するには、次のステートメントを発行します:

mysql> GRANT INSERT ON db1.cust TO 'priv_repl'@'%.example.com';

レプリケーションチャネルの PRIVILEGE_CHECKS_USER アカウントは、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 の場合) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 の場合) を使用して割り当てます。 PRIVILEGE_CHECKS_USER が設定されている場合は、行ベースのバイナリロギングを使用することを強くお勧めします。また、MySQL 8.0.19 から、このステートメントを使用して REQUIRE_ROW_FORMAT を設定してこれを強制できます。レプリケーションが実行中の場合は、CHANGE MASTER TO ステートメントの前に STOP REPLICA | SLAVE を発行し、その後に START REPLICA | SLAVE を発行します。たとえば、実行中のレプリカでチャネル channel_1 に対する権限チェックを開始するには、次のステートメントを発行します:

mysql> STOP SLAVE FOR CHANNEL 'channel_1';
mysql> CHANGE MASTER TO
         PRIVILEGE_CHECKS_USER = 'priv_repl'@'%.example.com',
         REQUIRE_ROW_FORMAT = 1 FOR CHANNEL 'channel_1';
mysql> START SLAVE FOR CHANNEL 'channel_1';

Or from MySQL 8.0.22 / 8.0.23:
mysql> STOP REPLICA FOR CHANNEL 'channel_1';
mysql> CHANGE REPLICATION SOURCE TO
         PRIVILEGE_CHECKS_USER = 'priv_repl'@'%.example.com',
         REQUIRE_ROW_FORMAT = 1 FOR CHANNEL 'channel_1';
mysql> START REPLICA FOR CHANNEL 'channel_1';

レプリケーションチャネルを再起動すると、その時点から権限チェックが適用されます。チャネルを指定せず、他のチャネルが存在しない場合は、ステートメントがデフォルトチャネルに適用されます。チャネルの PRIVILEGE_CHECKS_USER アカウントのユーザー名とホスト名は、パフォーマンススキーマの replication_applier_configuration テーブルに表示されます。ここでは、パフォーマンススキーマが適切にエスケープされているため、個々のトランザクションを実行するために SQL ステートメントに直接コピーできます。

レプリケーションチャネルに REQUIRE_ROW_FORMAT が設定されている場合、レプリケーションアプライアンスは一時テーブルを作成または削除しないため、pseudo_thread_id セッションシステム変数は設定されません。 LOAD DATA INFILE 命令は実行されないため、(Format_description_log_event としてログに記録された) データロードに関連付けられた一時ファイルへのファイル操作のアクセスまたは削除は試行されません。 INTVAR、RAND および USER_VAR イベントは実行されません。これらは、ステートメントベースレプリケーションのクライアント接続状態を再現するために使用されます。 (例外は、実行される DDL クエリーに関連付けられた USER_VAR イベントです。) DML トランザクション内に記録されるステートメントは実行されません。トランザクションのキューイングまたは適用の試行中にレプリケーションアプライアンスがこれらのタイプのイベントのいずれかを検出した場合、イベントは適用されず、レプリケーションはエラーで停止します。

PRIVILEGE_CHECKS_USER アカウントを設定するかどうかに関係なく、レプリケーションチャネルに REQUIRE_ROW_FORMAT を設定できます。このオプションを設定すると、権限チェックなしでもレプリケーションチャネルのセキュリティが向上します。 mysqlbinlog の使用時に --require-row-format オプションを指定して、mysqlbinlog 出力で行ベースのレプリケーションイベントを強制することもできます。

セキュリティコンテキスト. デフォルトでは、レプリケーションアプライヤスレッドが PRIVILEGE_CHECKS_USER として指定されたユーザーアカウントで起動されると、セキュリティコンテキストはデフォルトロールを使用して作成されるか、activate_all_roles_on_login が ON に設定されている場合はすべてのロールを使用して作成されます。

次の例に示すように、ロールを使用して、PRIVILEGE_CHECKS_USER アカウントとして使用されるアカウントに一般権限セットを提供できます。ここでは、前述の例のように、db1.cust テーブルに対する INSERT 権限をユーザーアカウントに直接付与するかわりに、この権限が REPLICATION_APPLIER 権限とともに priv_repl_role ロールに付与されます。このロールは、権限セットを 2 つのユーザーアカウントに付与するために使用され、その両方を PRIVILEGE_CHECKS_USER アカウントとして使用できるようになります:

mysql> SET sql_log_bin = 0;
mysql> CREATE USER 'priv_repa'@'%.example.com'
                  IDENTIFIED BY 'password'
                  REQUIRE SSL;
mysql> CREATE USER 'priv_repb'@'%.example.com'
                  IDENTIFIED BY 'password'
                  REQUIRE SSL;
mysql> CREATE ROLE 'priv_repl_role';
mysql> GRANT REPLICATION_APPLIER TO 'priv_repl_role';
mysql> GRANT INSERT ON db1.cust TO 'priv_repl_role';
mysql> GRANT 'priv_repl_role' TO
                  'priv_repa'@'%.example.com',
                  'priv_repb'@'%.example.com';
mysql> SET DEFAULT ROLE 'priv_repl_role' TO
                  'priv_repa'@'%.example.com',
                  'priv_repb'@'%.example.com';
mysql> SET sql_log_bin = 1;

レプリケーションアプライヤスレッドがセキュリティコンテキストを作成する場合、PRIVILEGE_CHECKS_USER アカウントの権限はチェックされますが、パスワード検証は実行されず、アカウントがロックされているかどうかのチェックなど、アカウント管理に関連するチェックは実行されません。作成されたセキュリティコンテキストは、レプリケーションアプライヤスレッドの存続期間中は変更されません。

制限. MySQL 8.0.18 でのみ、RESET REPLICA | SLAVE ステートメントを発行した直後にレプリカ mysqld が再起動された場合 (予期しないサーバー終了または意図的な再起動のため)、mysql.slave_relay_log_info テーブルに保持されている PRIVILEGE_CHECKS_USER アカウント設定は失われ、再指定する必要があります。そのリリースで権限チェックを使用する場合は、必ず再起動後に権限チェックが設定されていることを確認し、必要に応じて再指定します。この状況では、MySQL 8.0.19 から PRIVILEGE_CHECKS_USER アカウント設定が保持されるため、テーブルから取得され、チャネルに再適用されます。

PREV HOME UP NEXT