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

18.5.3.1 分散リカバリのためのセキュアなユーザー資格証明

18.5.3.1.1 キャッシュ SHA-2 認証プラグインを使用するレプリケーションユーザー

18.5.3.1.2 SSL を使用したレプリケーションユーザー

18.5.3.1.3 レプリケーションユーザー資格証明のセキュアな提供

バイナリログからの状態転送では、グループレプリケーションがメンバー間の直接レプリケーションチャネルを確立できるように、適切な権限を持つレプリケーションユーザーが必要です。 すべてのグループメンバーで分散リカバリに同じレプリケーションユーザーが使用されます。 MySQL 8.0.17 から使用可能な分散リカバリの一部としてリモートクローニング操作の使用をサポートするようにグループメンバーが設定されている場合、このレプリケーションユーザーはドナーのクローンユーザーとしても使用され、このロールに対する正しい権限も必要です。 このユーザーを設定する手順の詳細は、セクション18.2.1.3「分散リカバリのユーザー資格証明」 を参照してください。

ユーザー資格証明を保護するには、ユーザーアカウントとの接続に SSL を要求し、(MySQL 8.0.21 から) グループレプリケーションの起動時に、レプリカステータステーブルに格納するのではなく、ユーザー資格証明を指定できます。 また、キャッシュ SHA-2 認証を使用している場合は、グループメンバーに RSA キーペアを設定する必要があります。

18.5.3.1.1 キャッシュ SHA-2 認証プラグインを使用するレプリケーションユーザー

デフォルトでは、MySQL 8 で作成されたユーザーは セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」 を使用します。 分散リカバリ用に構成するレプリケーションユーザーがキャッシュ SHA-2 認証プラグインを使用し、分散リカバリ接続に SSL を使用しない場合、RSA キーペアがパスワード交換に使用されます。 RSA キーペアの詳細は、セクション6.3.3「SSL および RSA 証明書とキーの作成」 を参照してください。

この状況では、rpl_user の公開キーを結合メンバーにコピーするか、リクエスト時に公開キーを提供するようにドナーを構成できます。 よりセキュアなアプローチは、レプリケーションユーザーアカウントの公開キーを参加メンバーにコピーすることです。 次に、レプリケーションユーザーアカウントの公開キーへのパスを使用して、結合メンバーで group_replication_recovery_public_key_path システム変数を構成する必要があります。

安全性の低いアプローチは、メンバーに参加するためにレプリケーションユーザーアカウントの公開キーを提供するようにドナーに group_replication_recovery_get_public_key=ON を設定することです。 サーバーのアイデンティティを検証する方法はないため、中間者攻撃などによってサーバーアイデンティティが損なわれるリスクがないことが確実な場合にのみ、group_replication_recovery_get_public_key=ON を設定してください。

18.5.3.1.2 SSL を使用したレプリケーションユーザー

グループに参加するサーバー (参加メンバー) がドナーに接続する前に、SSL 接続を必要とするレプリケーションユーザーを作成する必要があります。 通常、これはサーバーをプロビジョニングしてグループに参加するときに設定されます。 SSL 接続を必要とする分散リカバリのレプリケーションユーザーを作成するには、グループに参加するすべてのサーバーで次のステートメントを発行します:

mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER 'rec_ssl_user'@'%' IDENTIFIED BY 'password' REQUIRE SSL;
mysql> GRANT replication slave ON *.* TO 'rec_ssl_user'@'%';
mysql> GRANT BACKUP_ADMIN ON *.* TO 'rec_ssl_user'@'%';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;

18.5.3.1.3 レプリケーションユーザー資格証明のセキュアな提供

レプリケーションユーザーのユーザー資格証明を指定するには、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用して、group_replication_recovery チャネルの資格証明として永続的に設定します。 または、MySQL 8.0.21 から、グループレプリケーションが開始されるたびに START GROUP_REPLICATION ステートメントで指定できます。 START GROUP_REPLICATION で指定されたユーザー資格証明は、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用して設定されたユーザー資格証明よりも優先されます。

CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO を使用して設定されたユーザー資格証明は、サーバー上のレプリケーションメタデータリポジトリにプレーンテキストで格納されますが、START GROUP_REPLICATION で指定されたユーザー資格証明はメモリーにのみ保存され、STOP GROUP_REPLICATION ステートメントまたはサーバーの停止によって削除されます。 したがって、START GROUP_REPLICATION を使用してユーザー資格証明を指定すると、不正なアクセスからグループレプリケーションサーバーを保護するのに役立ちます。 ただし、この方法は、group_replication_start_on_boot システム変数で指定された Group Replication の自動起動とは互換性がありません。

CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用してユーザー資格証明を永続的に設定する場合は、グループに参加するメンバーに対して次のステートメントを発行します:

mysql> CHANGE MASTER TO MASTER_USER='rec_ssl_user', MASTER_PASSWORD='password' 
            FOR CHANNEL 'group_replication_recovery';

Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rec_ssl_user', SOURCE_PASSWORD='password' 
            FOR CHANNEL 'group_replication_recovery';

START GROUP_REPLICATION でユーザー資格証明を指定するには、グループレプリケーションの初回起動時またはサーバーの再起動後に次のステートメントを発行します:

mysql> START GROUP_REPLICATION USER='rec_ssl_user', PASSWORD='password';

重要

START GROUP_REPLICATION を使用して、以前に CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO を使用して資格証明を提供したサーバー上のユーザー資格証明を指定するには、次のステップを実行して、この変更のセキュリティ上の利点を得る必要があります。

1. STOP GROUP_REPLICATION ステートメントを使用して、グループメンバーのグループレプリケーションを停止します。 グループレプリケーションの実行中に次の 2 つのステップを実行できますが、変更を実装するにはグループレプリケーションを再起動する必要があります。

2. group_replication_start_on_boot システム変数の値を OFF (デフォルトは ON) に設定します。

3. 次のステートメントを発行して、レプリカステータステーブルから分散リカバリ資格証明を削除します:

   mysql> CHANGE MASTER TO MASTER_USER='', MASTER_PASSWORD='' 
               FOR CHANNEL 'group_replication_recovery';
   
   Or from MySQL 8.0.23:
   mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='', SOURCE_PASSWORD='' 
               FOR CHANNEL 'group_replication_recovery';

4. 分散リカバリユーザー資格証明を指定する START GROUP_REPLICATION ステートメントを使用して、グループメンバーでグループレプリケーションを再起動します。

これらのステップを実行しないと、資格証明はレプリカステータステーブルに格納されたままになり、分散リカバリのリモートクローニング操作中に他のグループメンバーに転送することもできます。 その後、元のメンバーまたはそこからクローニングされたメンバーのいずれかで、group_replication_recovery チャネルが誤って格納された資格証明で起動される可能性があります。 サーバー起動時のグループレプリケーションの自動開始 (リモートクローニング操作後を含む) では、格納されたユーザー資格証明が使用され、オペレータが START GROUP_REPLICATION コマンドで分散リカバリ資格証明を指定しなかった場合にも使用されます。