Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pertimbangan keamanan untuk upgrade dari Aurora MySQL versi 3 ke versi 8.4

Saat bermigrasi dari Aurora MySQL versi 3 (kompatibel dengan MySQL 8.0) ke Aurora MySQL versi 8.4, beberapa perubahan penting terkait keamanan memerlukan perencanaan dan pertimbangan yang cermat. Panduan ini menguraikan perubahan keamanan utama dan memberikan rekomendasi untuk kelancaran migrasi.

Kebijakan otentikasi (baru di 8.4)

Aurora MySQL versi 3 (kompatibel dengan MySQL 8.0) menggunakan default_authentication_plugin parameter untuk mengkonfigurasi plugin otentikasi default yang digunakan saat membuat pengguna database. Di Aurora MySQL versi 8.4, parameter ini diganti dengan parameter, diatur ke authentication_policy default. *:caching_sha2_password

Nilai yang didukung di Aurora MySQL:

Upgrade precheck usang DefaultAuth memperingatkan jika cluster sumber Anda telah disetel ke. default_authentication_plugin mysql_native_password Tinjau peringatan ini dan konfigurasikan authentication_policy parameter pada grup parameter cluster target Anda saat memutakhirkan.

Menguasai perilaku pengguna

Cluster baru

Pengguna master dibuat dengan plugin otentikasi yang ditetapkan oleh authentication_policy parameter pada waktu pembuatan cluster. Jika Anda menggunakan grup parameter default, pengguna master dibuat dengan plugin caching_sha2_password otentikasi. Jika Anda menggunakan grup parameter kustom dengan authentication_policy parameter disetel ke*:mysql_native_password, pengguna master dibuat dengan plugin mysql_native_password otentikasi.

Reset kata sandi pengguna master

Saat Anda mengatur ulang kata sandi pengguna utama - melalui Konsol Manajemen AWS, CLI (modify-db-cluster --master-user-password), atau API - Aurora menggunakan plugin default saat ini yang ditentukan oleh authentication_policy parameter pada saat reset.

Secrets Manager dan rotasi kata sandi

Saat menggunakan AWS Secrets Manager untuk mengelola kata sandi pengguna utama Anda, jika Anda memperbarui nilai authentication_policy parameter, rotasi kata sandi berikutnya akan mengatur plugin otentikasi pengguna master agar sesuai dengan nilai authentication_policy parameter baru.

Pengguna database dibuat setelah upgrade

Pengguna database yang ada yang menggunakan plugin mysql_native_password otentikasi terus bekerja setelah upgrade. Pengguna database yang Anda buat setelah upgrade tanpa menentukan IDENTIFIED WITH klausa menggunakan plugin otentikasi yang ditentukan oleh parameter. authentication_policy Ketika parameter berada pada nilai default*:caching_sha2_password, pengguna baru dibuat dengan plugin caching_sha2_password otentikasi.

Untuk mengubah plugin otentikasi default untuk semua pengguna baru, perbarui nilai. authentication_policy Untuk informasi selengkapnya tentang nilai yang didukung, lihatKebijakan otentikasi (baru di 8.4).

Untuk membuat pengguna dengan plugin otentikasi yang berbeda dari default, tentukan secara eksplisit dalam pernyataan: CREATE USER

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

Enkripsi dan perubahan TLS

Untuk meminta TLS untuk semua koneksi pengguna ke cluster DB MySQL Aurora Anda, gunakan parameter cluster DB. require_secure_transport Secara default, parameter ini diatur ke ON dalam Aurora MySQL versi 8.4.

Aurora MySQL versi 8.4 memberlakukan standar kriptografi yang lebih ketat yang selaras dengan persyaratan keamanan terbaru pada parameter cluster DB (TLS 1.2) dan ssl_ciphers (TLS 1.3). tls_ciphersuites Untuk informasi selengkapnya, lihat Keamanan dengan Amazon Aurora MySQL.

Untuk mencegah gangguan koneksi, verifikasi konfigurasi TLS untuk klien MySQL Anda dan kluster DB target Anda sebelum migrasi.

Migrasi komponen validasi kata sandi

Aurora MySQL versi 8.4 memperkenalkan parameter aurora_enable_validate_password_component cluster untuk mengaktifkan atau menonaktifkan validate_password komponen, menghilangkan kebutuhan untuk menginstal atau menghapus instalannya secara manual. Jika sebelumnya Anda telah menginstal validate_password plugin dan sejak itu mengaktifkan komponen setelah memutakhirkan, hanya komponen yang efektif - plugin diabaikan.

Mulai dari Aurora MySQL versi 8.4, jika sebelumnya Anda telah menginstal validate_password plugin melalui INSTALL PLUGIN perintah, Anda dapat bermigrasi ke validate_password komponen dengan mengaktifkan parameter aurora_enable_validate_password_component dan kemudian menghapus plugin melalui perintah pada instance penulis Anda. UNINSTALL PLUGIN

Jika sebelumnya Anda menginstal validate_password komponen secara manual menggunakanINSTALL COMPONENT 'file://component_validate_password', pastikan Anda mengatur aurora_enable_validate_password_component parameter dalam grup parameter cluster DB target Anda saat memutakhirkan. Setelah upgrade, komponen tidak akan lagi tercantum dalam mysql.component tabel. Anda dapat menggunakan variabel aurora_enable_validate_password_component global untuk memverifikasi status komponen.

Pada startup mesin DB pertama setelah upgrade, Anda akan melihat pesan berikut di log kesalahan MySQL Anda jika sebelumnya Anda telah menginstal komponen secara manual:

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.

Upgrade precheck aurora ValidatePasswordPluginCheck memperingatkan jika validate_password plugin diinstal pada cluster sumber Anda. Peringatan ini tidak memblokir pemutakhiran, tetapi Anda harus berencana untuk beralih ke komponen setelah memutakhirkan.

Hak istimewa dinamis baru

Aurora MySQL versi 8.4 mendukung hak istimewa baru berikut:

Hak istimewa ini secara otomatis diberikan kepada Hak akses akun pengguna master untuk akun pengguna master Anda saat upgrade.

Penegakan hukum pengguna yang dilindungi untuk rdsproxyadmin

Dimulai di Aurora MySQL versi 8.4.7, adalah pengguna yang dilindungi. rdsproxyadmin Mesin menolakCREATE,,,DROP,RENAME,, GRANTREVOKE, dan SET PASSWORD beroperasi terhadap host mana rdsproxyadmin pun. Untuk daftar lengkap operasi yang ditolak dan contoh kesalahan, lihatPengguna yang dipesan di Aurora MySQL.

Aurora MySQL versi 3 tidak mencadangkan nama. rdsproxyadmin Jika Anda membuat pengguna database bernama rdsproxyadmin dalam versi 3 (daripada membiarkan sistem membuatnya saat Anda mendaftarkan target proxy), tinjau bagian ini sebelum memutakhirkan ke versi 8.4.

Sebelum Anda meng-upgrade

Jika Anda membuat rdsproxyadmin pengguna di klaster versi 3 Anda, ganti nama atau jatuhkan akun sebelum Anda meningkatkan ke versi 8.4. Anda dapat menggunakan koneksi versi 3 untuk menjalankan salah satu pernyataan berikut:

-- 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';

Perbarui aplikasi apa pun atau kredensyal tersimpan yang mereferensikan nama pengguna lama sebelum memulai pemutakhiran.

Jika Anda tidak mengganti nama atau menjatuhkan pengguna sebelum memutakhirkan

Jika Anda memutakhirkan klaster yang sudah memiliki rdsproxyadmin pengguna yang Anda buat, pemutakhiran berhasil diselesaikan. Akun dipertahankan dengan kata sandi dan hak istimewa yang ada, dan Anda masih dapat terhubung ke cluster seperti rdsproxyadmin dengan menggunakan kata sandi asli.

Namun, setelah upgrade, Anda tidak dapat mengubah akun. Jika Anda mencoba untuk menghapus, mengganti nama, mengubah hak istimewa, atau mengubah kata sandi untukrdsproxyadmin, pernyataan tersebut mengembalikan kesalahan.

Jika Anda ingin menghapus akun setelah upgrade, atau merebut kembali rdsproxyadmin nama untuk RDS Proxy untuk digunakan, hubungi Support.AWS AWS Support dapat menghapus rdsproxyadmin pengguna yang sudah ada sebelumnya yang dibawa maju dari versi 3.