Aurora MySQL バージョン 3 からバージョン 8.4 にアップグレードする際のセキュリティ上の考慮事項

Aurora MySQL バージョン 3 (MySQL 8.0 互換) から Aurora MySQL バージョン 8.4 に移行する場合、いくつかの重要なセキュリティ関連の変更には、慎重な計画と考慮が必要です。このガイドでは、主要なセキュリティ変更の概要と、スムーズな移行のための推奨事項を示します。

認証ポリシー (8.4 の新機能)

Aurora MySQL バージョン 3 (MySQL 8.0 互換) では、default_authentication_plugin パラメータを使用して、データベースユーザーの作成時に使用するデフォルトの認証プラグインを設定します。Aurora MySQL バージョン 8.4 では、このパラメータは authentication_policy パラメータに置き換えられ、デフォルトで *:caching_sha2_password に設定されています。

Aurora MySQL でサポートされている値:

アップグレードの事前チェック deprecatedDefaultAuth は、ソースクラスターで default_authentication_plugin が mysql_native_password に設定されている場合に警告を発します。アップグレード時には、この警告を確認し、ターゲットクラスターパラメータグループで authentication_policy パラメータを設定します。

マスターユーザーの動作

新しいクラスター

マスターユーザーは、クラスターの作成時に authentication_policy パラメータによって設定された認証プラグインを使用して作成されます。デフォルトのパラメータグループを使用する場合、マスターユーザーは caching_sha2_password 認証プラグインを使用して作成されます。authentication_policy パラメータを *:mysql_native_password に設定してカスタムパラメータグループを使用する場合、マスターユーザーは mysql_native_password 認証プラグインを使用して作成されます。

マスターユーザーパスワードのリセット

AWS マネジメントコンソール、CLI (modify-db-cluster --master-user-password)、または API を使用してマスターユーザーのパスワードをリセットする場合、Aurora はリセット時に authentication_policy パラメータで定義された現在のデフォルトプラグインを使用します。

Secrets Manager とパスワードのローテーション

AWS Secrets Manager を使用してマスターユーザーのパスワードを管理する場合、authentication_policy パラメータの値を更新すると、次のパスワードローテーションでマスターユーザーの認証プラグインが新しい authentication_policy パラメータ値と一致するように設定されます。

アップグレード後に作成されたデータベースユーザー

mysql_native_password 認証プラグインを使用する既存のデータベースユーザーは、アップグレード後も引き続き利用できます。IDENTIFIED WITH 句を指定せずにアップグレード後に作成するデータベースユーザーは、authentication_policy パラメータで定義された認証プラグインを使用します。パラメータがデフォルト値の *:caching_sha2_password の場合、caching_sha2_password 認証プラグインを使用して新しいユーザーが作成されます。

すべての新規ユーザーのデフォルトの認証プラグインを変更するには、authentication_policy の値を更新します。サポートされている値の詳細については、「認証ポリシー (8.4 の新機能)」を参照してください。

デフォルトとは異なる認証プラグインを使用してユーザーを作成するには、CREATE USER ステートメントで明示的に指定します。

CREATE USER 'username'@'host' IDENTIFIED WITH authentication-plugin BY 'password';

暗号化と TLS の変更

require_secure_transport DB クラスターパラメータを使用して、Aurora MySQL DB クラスターへのすべてのユーザー接続に TLS を必須にします。デフォルトでは、このパラメータは Aurora MySQL バージョン 8.4 で ON に設定されています。

Aurora MySQL バージョン 8.4 では、ssl_ciphers (TLS 1.2) および tls_ciphersuites (TLS 1.3) DB クラスターパラメータに関する最新のセキュリティ要件に準拠した、より厳格な暗号化標準が適用されます。詳細については、「Amazon Aurora MySQL でのセキュリティ」を参照してください。

接続の中断を防ぐため、移行前に MySQL クライアントとターゲット DB クラスターの TLS 設定を確認してください。

パスワード検証コンポーネントの移行

Aurora MySQL バージョン 8.4 では、validate_password コンポーネントを有効または無効にする aurora_enable_validate_password_component クラスターパラメータが導入されているため、手動でインストールまたはアンインストールする必要はありません。以前に validate_password プラグインをインストールしていて、アップグレード後にコンポーネントを有効にした場合、コンポーネントのみが有効です。プラグインは無視されます。

Aurora MySQL バージョン 8.4 以降では、以前に INSTALL PLUGIN コマンドを使用して validate_password プラグインをインストールていた場合、aurora_enable_validate_password_component パラメータを有効にしてから、ライターインスタンスで UNINSTALL PLUGIN コマンドを使用してプラグインを削除することで、validate_password コンポーネントに移行できます。

以前に INSTALL COMPONENT 'file://component_validate_password' を使用して validate_password コンポーネントを手動でインストールした場合は、アップグレード時にターゲット DB クラスターのパラメータグループで aurora_enable_validate_password_component パラメータを設定してください。アップグレード後、コンポーネントは mysql.component テーブルに表示されなくなります。aurora_enable_validate_password_component グローバル変数を使用して、コンポーネントのステータスを確認できます。

アップグレード後の最初の DB エンジンの起動時に、以前にコンポーネントを手動でインストールしていた場合、MySQL エラーログに次のメッセージが表示されます。

Component 'file://component_validate_password' is being removed from mysql.component table.
validate_password component can be enabled/disabled through 'aurora_enable_validate_password_component' cluster parameter.

アップグレードの事前チェック auroraValidatePasswordPluginCheck は、validate_password プラグインがソースクラスターにインストールされている場合に警告を発します。この警告はアップグレードを妨げるものではありませんが、アップグレード後にコンポーネントへの移行を計画する必要があることを示しています。

新しい動的権限

Aurora MySQL バージョン 8.4 は、以下の新しい権限をサポートしています。

これらの権限は、アップグレード時にマスターユーザーアカウントの マスターユーザーアカウント権限 に自動的に付与されます。

rdsproxyadmin に対する保護ユーザーの適用

Aurora MySQL バージョン 8.4.7 以降、rdsproxyadmin は保護されたユーザーです。エンジンは、どのホストにおいても、rdsproxyadmin に対する CREATE、DROP、RENAME、GRANT、REVOKE、および SET PASSWORD オペレーションを拒否します。拒否されるオペレーションの完全なリストとエラーの例については、「Aurora MySQL の予約済みユーザー」を参照してください。

Aurora MySQL バージョン 3 では rdsproxyadmin という名前は予約されていません。バージョン 3 で rdsproxyadmin という名前のデータベースユーザーを作成した場合 (プロキシターゲットの登録時にシステムに作成させるのではなく)、バージョン 8.4 にアップグレードする前にこのセクションを確認してください。

アップグレード前の注意点

バージョン 3 クラスターで rdsproxyadmin ユーザーを作成した場合は、バージョン 8.4 にアップグレードする前にアカウントの名前を変更するか削除します。バージョン 3 の接続を使用して、次のいずれかのステートメントを実行できます。

-- Rename the existing account to a non-reserved name
RENAME USER 'rdsproxyadmin'@'host' TO 'new_user'@'host';

-- Or drop the account if it is no longer needed
DROP USER 'rdsproxyadmin'@'host';

アップグレードを開始する前に、古いユーザー名を参照するアプリケーションや保存された認証情報を更新します。

アップグレード前にユーザーの名前を変更または削除しない場合

作成した rdsproxyadmin ユーザーが既に存在するクラスターをアップグレードする場合、アップグレードは正常に完了します。アカウントは既存のパスワードと権限で保持され、元のパスワードを使用して rdsproxyadmin としてクラスターに接続できます。

ただし、アップグレード後にアカウントを変更することはできません。rdsproxyadmin の削除、名前の変更、権限の変更、またはパスワードの変更を試みると、ステートメントはエラーを返します。

アップグレード後にアカウントを削除する場合、または RDS Proxy が使用する rdsproxyadmin 名を再利用する場合は、AWS サポートにお問い合わせください。AWSサポートは、バージョン 3 から引き継がれた既存の rdsproxyadmin ユーザーを削除できます。