バイナリログの暗号化が有効になっている場合は、ALTER INSTANCE ROTATE BINLOG MASTER KEY を発行することで、サーバーの実行中いつでもバイナリログマスターキーをローテーションできます。 このステートメントを使用してバイナリログマスターキーを手動でローテーションすると、新規および後続のファイルのパスワードは新しいバイナリログマスターキーを使用して暗号化され、既存の暗号化バイナリログファイルおよびリレーログファイルのファイルパスワードも新しいバイナリログマスターキーを使用して再暗号化されるため、暗号化は完全に更新されます。 バイナリログマスターキーを定期的にローテーションして、組織のセキュリティーポリシーに準拠できます。また、現在のバイナリログマスターキーまたは以前のバイナリログマスターキーのいずれかが危険にさらされている疑いがある場合も同様です。
バイナリログマスターキーを手動でローテーションすると、MySQL Server は次のアクションを順番に実行します:
新しいバイナリログ暗号化鍵は、次に使用可能なシーケンス番号で生成され、鍵リングに格納され、新しいバイナリログマスターキーとして使用されます。
バイナリログおよびリレーログファイルは、すべてのチャネルでローテーションされます。
新しいバイナリログマスターキーは、新しいバイナリログファイル、リレーログファイル、および鍵が再度変更されるまで後続のファイルのファイルパスワードを暗号化するために使用されます。
サーバー上の既存の暗号化バイナリログファイルおよびリレーログファイルのファイルパスワードは、新しいバイナリログマスターキーを使用して、最新のファイルから順に再暗号化されます。 暗号化されていないファイルはスキップされます。
再暗号化プロセス後にファイルに使用されなくなったバイナリログ暗号化キーは、キーリングから削除されます。
ALTER INSTANCE ROTATE BINLOG MASTER KEY を発行するには BINLOG_ENCRYPTION_ADMIN 権限が必要であり、binlog_encryption システム変数が OFF に設定されている場合、このステートメントは使用できません。
バイナリログマスターキーローテーション処理の最終ステップとして、保持されているバイナリログファイルまたはリレーログファイルに適用されなくなったすべてのバイナリログ暗号化鍵が鍵リングからクリーンアップされます。 保持されているバイナリログファイルまたはリレーログファイルを再暗号化のために初期化できない場合、将来ファイルを回復できるように、関連するバイナリログ暗号化鍵は削除されません。 たとえば、バイナリログインデックスファイルにリストされているファイルが現在読み取れない場合や、チャネルの初期化に失敗した場合などです。 たとえば、MySQL Enterprise Backup を使用して作成されたバックアップを使用して新しいレプリカを設定するためにサーバー UUID が変更された場合、新しいサーバーで ALTER INSTANCE ROTATE BINLOG MASTER KEY を発行しても、元のサーバー UUID を含む以前のバイナリログ暗号化キーは削除されません。
バイナリログマスターキーローテーション処理の最初の 4 つの手順のいずれかを正しく完了できない場合は、状況とバイナリログファイルおよびリレーログファイルの暗号化ステータスの結果を説明するエラーメッセージが発行されます。 以前に暗号化されたファイルは常に暗号化された状態のままですが、そのファイルのパスワードは古いバイナリログマスターキーを使用して暗号化される場合があります。 これらのエラーが表示された場合は、まず ALTER INSTANCE ROTATE BINLOG MASTER KEY を再発行してプロセスを再試行してください。 次に、個々のファイルのステータスを調べて、特に現在または以前のバイナリログマスターキーのいずれかが危険にさらされている可能性があると疑われる場合に、プロセスをブロックしている内容を確認します。
バイナリログマスターキーローテーション処理の最終ステップを正しく完了できない場合は、状況を説明する警告メッセージが発行されます。 警告メッセージは、バイナリログマスターキーをローテーションするための鍵リング内の補助鍵をプロセスがクリーンアップできなかったか、または未使用のバイナリログ暗号化鍵をクリーンアップできなかったかを示します。 キーが補助キーであるか使用されなくなったため、メッセージを無視するか、ALTER INSTANCE ROTATE BINLOG MASTER KEY を再発行してプロセスを再試行できます。
サーバーが停止し、バイナリログマスターキーローテーション処理中にバイナリログ暗号化が ON に設定されたままで再起動された場合、再起動後の新しいバイナリログファイルとリレーログファイルは新しいバイナリログマスターキーを使用して暗号化されます。 ただし、既存のファイルの再暗号化は続行されないため、サーバーが停止する前に再暗号化されなかったファイルは、以前のバイナリログマスターキーを使用して暗号化されたままになります。 再暗号化を完了し、未使用のバイナリログ暗号化キーをクリーンアップするには、再起動後に ALTER INSTANCE ROTATE BINLOG MASTER KEY を再発行します。
ALTER INSTANCE ROTATE BINLOG MASTER KEY アクションはバイナリログに書き込まれず、レプリカでは実行されません。 したがって、バイナリログマスターキーローテーションは、MySQL バージョンの混在を含むレプリケーション環境で実行できます。 適用可能なすべてのソースサーバーおよびレプリカサーバーでバイナリログマスターキーの定期ローテーションをスケジュールするには、各サーバーで MySQL イベントスケジューラを有効にし、CREATE EVENT ステートメントを使用して ALTER INSTANCE ROTATE BINLOG MASTER KEY ステートメントを発行します。 現在または以前のバイナリログマスターキーのいずれかが危険にさらされている可能性があるためにバイナリログマスターキーをローテーションした場合は、該当するすべてのソースおよびレプリカサーバーでステートメントを発行します。 個々のサーバーでステートメントを発行すると、遅延しているレプリカ、複数のレプリケーショントポロジに属しているレプリカ、またはレプリケーショントポロジで現在アクティブではないがバイナリログファイルとリレーログファイルがあるレプリカの場合でも、即座にコンプライアンスを検証できます。
binlog_rotate_encryption_master_key_at_startup システム変数は、サーバーの再起動時にバイナリログマスターキーを自動的にローテーションするかどうかを制御します。 このシステム変数が ON に設定されている場合、新しいバイナリログ暗号化鍵が生成され、サーバーが再起動されるたびに新しいバイナリログマスターキーとして使用されます。 OFF(デフォルト) に設定されている場合は、再起動後に既存のバイナリログマスターキーが再度使用されます。 バイナリログマスターキーが起動時にローテーションされると、新しいバイナリログおよびリレーログファイルのファイルパスワードは新しいキーを使用して暗号化されます。 既存の暗号化バイナリログファイルおよびリレーログファイルのファイルパスワードは再暗号化されないため、鍵リングで引き続き使用できる古い鍵を使用して暗号化されたままになります。