gihyo.jpサイトのロゴ

MySQL道普請便り

第218回MySQLレプリカのレプリケーション権限チェックについて

2024-03-26

MySQLのレプリケーション機能において、レプリカはソースから送信されたトランザクションをそのまま実行し、ソースと同じデータ状態を保つように設計されています。レプリケーションを設定する際には、REPLICATION SLAVE権限を持つアカウントがソースに存在する必要があります。このアカウントを使用して、レプリカはソースに接続し、レプリケーションを開始することができます。このプロセスでは、レプリカはソースから受け取ったトランザクションの権限のチェックをせずに適用します。

MySQL 8.0.18とそれ以降から、セキュリティを強化するために、レプリカがトランザクションを適用する際に権限チェックを行う機能が導入されました。この機能を利用することで、ソースから送られてくるトランザクションが適切な権限に基づいているかどうかをレプリカが確認できるようになります。今回はこの新しいセキュリティ機能の設定方法について説明します。

PRIVILEGE_CHECKS_USERアカウントの作成と設定

MySQL 8.0.18とそれ以降では、レプリケーションを設定するステートメント（CHANGE REPLICATION SOURCE TOまたはCHANGE MASTER TO）のオプションにPRIVILEGE_CHECKS_USERアカウントを指定できます。

PRIVILEGE_CHECKS_USERアカウントにはユーザーアカウントを指定します。デフォルトはNULLであり、指定なしです。ソースから受け取ったトランザクションをレプリカが適用するときに、ここに指定されたユーザーアカウント権限と照合してチェックし、そのトランザクションの適用が認可されていることを確認します。

また、PRIVILEGE_CHECKS_USERアカウントを指定するときは、REQUIRE_ROW_FORMATオプションを1に指定することをおすすめします。これは行ベースレプリケーションのトランザクションのみを受けていれるようにするオプションです。ステートメントベースレプリケーションであると、トランザクションによっては管理者レベルの権限が必要になるときがあるためです。よりセキュアにするために、この指定を行います。

PRIVILEGE_CHECKS_USERアカウント設定例
mysql> CHANGE REPLICATION SOURCE TO
         PRIVILEGE_CHECKS_USER = 'repl_priv_user'@'%',
         REQUIRE_ROW_FORMAT = 1;

PRIVILEGE_CHECKS_USERアカウントに指定するアカウントにはREPLICATION_APPLIER権限が必要です。それと、予想されるすべてのトランザクションを適用するのに十分な追加の権限の付与を行います。

次の例では、前述の例でPRIVILEGE_CHECKS_USERアカウントに指定した'repl_priv_user'@'%'ユーザアカウントに対して、REPLICATION_APPLIER権限の付与とdb1データベースの全テーブルにINSERTできるように指定しています。

PRIVILEGE_CHECKS_USERアカウント作成例
mysql> CREATE USER 'repl_priv_user'@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION_APPLIER 'repl_priv_user'@'%';
mysql> GRANT INSERT ON db1.* TO 'repl_priv_user'@'%';

以上の設定を行うと、db1データベースの全テーブルに対するINSERTのみレプリケーションされます。それ以外のトランザクションがくると、レプリケーションは停止するようになります。

PRIVILEGE_CHECKS_USERアカウントの用途

PRIVILEGE_CHECKS_USERアカウントの用途としては、以下の2つがあります。

  • セキュリティの向上
  • ヒューマンエラーからの保護

「セキュリティの向上」としては、予期せぬ不正な操作からレプリケーションを保護できます。レプリケーションは管理者権限が必要な不正な更新操作であってもこれを受け入れてしまいます。このため、実行されるべき正当な権限を確認し、適切な権限のみをPRIVILEGE_CHECKS_USERアカウントに付与することで、不正な操作からレプリカを保護することができます。

「ヒューマンエラーからの保護」では、たとえば、削除する予定のないテーブルに対してDROP権限を剥奪したPRIVILEGE_CHECKS_USERアカウントを用意します。ミスにより誤ってテーブルを削除したとしても、レプリカでは削除されず残ることになります。ただし、これは複雑な構成になり、イレギュラーな作業時にレプリケーション停止のリスクがあるため、実運用には適さないと考えます。このようなヒューマンエラーに対してはバックアップからリストアするのがいいでしょう。

失敗したトランザクションへの対応方法

PRIVILEGE_CHECKS_USER アカウントに対する権限チェックが失敗した場合、トランザクションは実行されず、レプリケーションは停止します。

停止後に失敗したトランザクションを確認して対応方法を検討します。失敗したトランザクションの確認方法はmysqlbinlogコマンドを利用して、該当のトランザクションを特定します。

該当のトランザクションを特定し、それがセキュリティ上の問題がないことを確認します。問題ないことが確認できたら、以下のような対応方法があります。

まとめ

今回はレプリカのレプリケーション権限チェックについて紹介しました。17.3.3 レプリケーション権限チェックを参考にしていますので、詳しく知りたい方はこちらをご確認ください。

おすすめ記事

記事・ニュース一覧