Amazon Aurora MySQL 8.4 が GA したので、接続・認証まわりの変更点を確認してみた
はじめに
2026年5月21日、Amazon Aurora MySQL 8.4 が GA になりました。
Aurora MySQL 8.4 はコミュニティ MySQL 8.4 LTS 互換のメジャーバージョンです。バージョニングモデルも変更され、従来の 8.0.mysql_aurora.3.x.y 形式から 8.4.mysql_aurora.8.4.7 形式になっています。
セキュリティ関連のデフォルト値が以下のとおり変わっています。
| 項目 | Aurora MySQL 3 (MySQL 8.0互換) | Aurora MySQL 8.4 (MySQL 8.4互換) |
|---|---|---|
| デフォルト認証（新規ユーザー） | mysql_native_password | caching_sha2_password |
| TLS強制（デフォルトパラメータ） | OFF（任意） | ON（require_secure_transport=ON） |
| TLSバージョン | TLS 1.0〜1.3 | TLS 1.2/1.3 のみ（※） |
| パスワードバリデーション | 手動有効化 | デフォルト有効（MEDIUM） |
| SHOW MASTER STATUS | 使用可 | 構文エラー |
※ TLSバージョンの制限は公式ドキュメントの記載に基づくものです。今回の検証では TLSv1.3 での接続を確認しましたが、TLS 1.0/1.1 の明示的な拒否テストは実施していません。
本記事では、東京リージョンで新規作成したクラスタのデフォルト挙動を確認しています。既存クラスタからのアップグレード時に、既存パラメータグループや既存ユーザーがどのように扱われるかは対象外です。
検証環境
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| エンジンバージョン | 8.4.mysql_aurora.8.4.7 |
| インスタンスクラス | db.r8g.large |
| 接続方法 | 踏み台EC2 (t4g.micro, AL2023) → SSM経由 |
| クライアント | mariadb 10.5.29 (AL2023 標準パッケージ) |
検証結果
| 検証項目 | 結果 | 影響 |
|---|---|---|
| バージョン表記 | VERSION() / AURORA_VERSION() ともに 8.4.7 |
通常の接続には影響なし。バージョン判定スクリプトは要確認 |
| デフォルト認証プラグイン | 新規ユーザーは caching_sha2_password（※ mysql_native_password も明示指定で利用可） |
古いドライバーでは接続影響の可能性 |
| TLS強制 | require_secure_transport=ON |
非TLS接続は ERROR 3159 で拒否 |
| パスワードバリデーション | デフォルト有効、MEDIUM | 弱いパスワードでユーザー作成不可 |
SHOW MASTER STATUS |
構文エラー | 監視・運用スクリプトに影響 |
バージョン確認
今回確認した 8.4.mysql_aurora.8.4.7 では、VERSION() と AURORA_VERSION() がいずれも 8.4.7 を返しました。Aurora MySQL 3 系では両者が異なる値を返していたため、バージョン判定を行っているスクリプトでは確認しておくとよさそうです。
SELECT VERSION(); -- 8.4.7
SELECT AURORA_VERSION(); -- 8.4.7
デフォルト認証プラグイン
SHOW VARIABLES LIKE 'authentication_policy';
-- *:caching_sha2_password
今回確認した Aurora MySQL 8.4 では *:caching_sha2_password と表示されました。少なくとも、この値から新規ユーザーのデフォルト認証プラグインが caching_sha2_password であることを確認できます。
新規ユーザーを作成して認証プラグインを確認しました。
CREATE USER 'testuser'@'%' IDENTIFIED BY 'TestPass123!';
SELECT user, plugin FROM mysql.user WHERE user IN ('admin','testuser');
+----------+-----------------------+
| user | plugin |
+----------+-----------------------+
| admin | caching_sha2_password |
| testuser | caching_sha2_password |
+----------+-----------------------+
管理者ユーザー・新規ユーザーともに caching_sha2_password が設定されていました。
一方、mysql_native_password の明示指定も確認しました。
CREATE USER 'nativeuser'@'%' IDENTIFIED WITH mysql_native_password BY 'NativePass123!';
SELECT user, plugin FROM mysql.user WHERE user = 'nativeuser';
+------------+-----------------------+
| user | plugin |
+------------+-----------------------+
| nativeuser | mysql_native_password |
+------------+-----------------------+
コミュニティ MySQL 8.4 では mysql_native_password がデフォルトで無効化されますが、Aurora MySQL 8.4 ではプラグインが有効な状態でした。今回の新規作成クラスタでは、新規ユーザー作成時にも明示指定すれば mysql_native_password を利用できました。公式ブログにも、既存アカウント継続利用の観点で "Aurora MySQL 8.4 keeps the plugin enabled so existing accounts that use it continue to work without interruption" と記載されています。
注意すべきは、新規ユーザー作成時のデフォルトが変わることと、アプリケーション側のドライバーが caching_sha2_password に対応している必要がある点です。
TLS強制
SHOW VARIABLES LIKE 'require_secure_transport'; -- ON
SHOW STATUS LIKE 'Ssl_version'; -- TLSv1.3
SHOW STATUS LIKE 'Ssl_cipher'; -- TLS_AES_256_GCM_SHA384
デフォルトで require_secure_transport=ON でした。実際の接続では TLSv1.3 で接続されていました。MariaDB クライアントで --skip-ssl を指定して非TLS接続を試みたところ、ERROR 3159 で拒否されました。
$ mysql -h <endpoint> -u admin -p --skip-ssl
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.
クライアント実装による差異ではなく、サーバー側で明確に拒否されていることが確認できます。TLS を無効化している接続設定がないか確認しておく必要があります。
パスワードバリデーション
SHOW VARIABLES LIKE 'validate_password%';
+--------------------------------------+--------+
| Variable_name | Value |
+--------------------------------------+--------+
| validate_password.policy | MEDIUM |
| validate_password.length | 8 |
| validate_password.mixed_case_count | 1 |
| validate_password.number_count | 1 |
| validate_password.special_char_count | 1 |
+--------------------------------------+--------+
デフォルトでパスワードバリデーションが有効でした。MEDIUM ポリシーでは、8文字以上・大文字小文字混在・数字・記号をそれぞれ1文字以上含む必要があります。設定値はパラメータグループで調整できます。
この制約は新規ユーザー作成やパスワード変更時に適用されるものです。少なくとも、パスワードバリデーション自体は既存アカウントを即座にログイン不可にするものではありません。
レプリケーション関連構文の変更
SHOW BINARY LOG STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000002 | (値省略) | | | |
+----------------------------+----------+--------------+------------------+-------------------+
SHOW MASTER STATUS; -- ERROR 1064 (42000): You have an error in your SQL syntax
新構文 SHOW BINARY LOG STATUS は正常に受け付けられました。一方、旧構文 SHOW MASTER STATUS は MySQL 8.4 で削除された構文のため、構文エラーになりました。監視スクリプトや管理ツールが内部的に旧構文を呼んでいる場合、Aurora MySQL 8.4 への移行後にエラーが発生する可能性があります。
注意事項
クラスタ作成時のエンジンバージョン指定は 8.4.mysql_aurora.8.4.7 です。8.4.7 単体で指定すると InvalidParameterCombination: Cannot find version 8.4.7 for aurora-mysql エラーになります。
AL2023 標準の mariadb 10.5.29 クライアントは --ssl-mode オプションが存在しません。TLS 接続には --ssl（デフォルト有効）、無効化には --skip-ssl を使用します。MySQL 8.0系公式クライアントの場合は --ssl-mode=REQUIRED / --ssl-mode=DISABLED です。
今回のように Secrets Manager によるマスターユーザーパスワード管理（--manage-master-user-password）を使う場合、生成されたパスワードにシェルで解釈される記号が含まれることがあります。CLI から手動接続する際はクォートに注意が必要です。
まとめ
Aurora MySQL 8.4 ではセキュリティ周りのデフォルトが大幅に強化され、TLS強制・認証プラグイン変更・パスワードポリシーが「設定しなくても安全」な方向に変わっています。一方で、新規作成時のデフォルトでは非TLS接続が拒否され、また旧レプリケーション構文は使用できません。アップグレード時の挙動は既存設定に依存するため、事前の確認が必要です。Aurora MySQL 3 の標準サポートは 2028年4月30日までなので、計画的なアップグレード準備を進めておくとよさそうです。
アップグレード前に最低限確認しておきたい点を挙げておきます。
- アプリケーションの MySQL ドライバーやコネクタが
caching_sha2_passwordに対応しているか - 接続設定で TLS を無効化していないか（
ssl-mode=DISABLED、useSSL=false、--skip-ssl等） - ユーザー作成・パスワード変更処理がパスワードポリシーを満たすか
- 監視スクリプトや運用ツールが
SHOW MASTER STATUSなどの旧構文を使っていないか
まずはアプリケーションや接続設定の修正で対応するのが基本です。TLS強制やパスワードポリシーなどは、要件によってはパラメータグループで調整できる場合があります。ただし、レプリケーション構文についてはパラメータグループでは対応できないため、スクリプトの修正が必要です。
参考リンク
