Migrasi instans KMS 1.0 - Key Management Service

Jika Anda menggunakan Alibaba Cloud Key Management Service (KMS) 1.0, Anda dapat memigrasikan sumber daya ke instans manajemen kunci perangkat lunak KMS 3.0 atau instans manajemen kunci perangkat keras di wilayah yang sama guna meningkatkan kinerja dan pengalaman pengguna. Setelah migrasi, kunci dan kredensial akan disimpan di instans KMS. Kunci bersifat unik dalam satu wilayah, sedangkan kredensial bersifat unik dalam satu Akun Alibaba Cloud dan satu instans KMS di wilayah tersebut. Topik ini menjelaskan cara memigrasikan sumber daya dari KMS 1.0 ke instans KMS 3.0.

Mengapa melakukan migrasi

Untuk memberikan pengalaman produk yang lebih baik, Alibaba Cloud berencana memulai fase End of Support and Fixes (EOSF) untuk KMS 1.0 pada pukul 00:00:00 (GMT+8), 30 Maret 2025. KMS 1.0 kemudian akan memasuki fase End of Support (EOS) pada pukul 00:00:00 (GMT+8), 30 September 2025. Untuk mencegah gangguan bisnis, segera migrasikan sumber daya KMS 1.0 ke instans KMS 3.0. Migrasi ke instans KMS 3.0 memberikan manfaat berikut:

Keamanan tinggi: KMS 3.0 menggunakan arsitektur isolasi penyewa lanjutan dan instans khusus, sehingga menawarkan isolasi keamanan yang jauh lebih baik dibandingkan KMS 1.0.
Peningkatan fitur yang komprehensif: KMS 3.0 mendukung berbagi instans KMS antarbeberapa akun dan pencadangan sumber daya instans. Layanan ini juga terintegrasi dengan Simple Log Service dan sistem manajemen peringatan untuk memberikan pengalaman pengguna yang lebih kuat dan komprehensif.
Kontrol akses granular: KMS 3.0 mendukung kebijakan kontrol akses berbasis identitas maupun berbasis sumber daya, sehingga cocok untuk skenario yang melibatkan berbagai jenis sumber daya dengan properti berbeda.
Kinerja dan keandalan lebih tinggi:
- Enkripsi dan dekripsi berkinerja tinggi: Instans KMS 3.0 menawarkan kinerja yang lebih tinggi. Untuk operasi enkripsi dan dekripsi, KMS 1.0 menyediakan 1.000 permintaan per detik (QPS). Dengan instans KMS 3.0, Anda dapat memilih kapasitas 1.000, 2.000, atau 4.000 QPS sesuai kebutuhan kinerja.
- Redundansi dan toleransi kesalahan: Instans KMS 3.0 menggunakan arsitektur penyebaran multi-zona dan mendukung pencadangan data, sehingga mencapai stabilitas 99,95% dan ketersediaan data 99,9999%. Hal ini membantu mengatasi potensi kegagalan serta memastikan ketersediaan berkelanjutan KMS, sehingga mengurangi risiko kegagalan enkripsi atau dekripsi akibat gangguan sistem.

Dampak migrasi

Dampak bisnis

Migrasi memengaruhi aspek-aspek berikut dari bisnis Anda:
- Ketersediaan layanan: Migrasi KMS memisahkan operasi lapisan kontrol dari operasi bidang data. Proses migrasi itu sendiri tidak memengaruhi operasi bisnis Anda. Pemanggilan kredensial, enkripsi produk cloud, dan enkripsi aplikasi tetap berfungsi seperti biasa.
  Penting
  Selama jendela waktu migrasi, operasi lapisan kontrol tidak dapat dilakukan pada kunci, kredensial, atau instans KMS. Operasi tersebut mencakup pembuatan, modifikasi, atau penghapusan sumber daya. Pembatasan ini bertujuan mencegah kegagalan migrasi akibat ketidakkonsistenan data. Disarankan agar migrasi dilakukan di luar jam puncak.
- Kompatibilitas Terraform: Jika Anda menggunakan Terraform untuk mengelola KMS, properti ID instans akan ditambahkan ke sumber daya Anda setelah migrasi. Untuk mencegah sumber daya dilepas saat Anda melakukan operasi lapisan kontrol berikutnya, Anda harus memperbarui konfigurasi Terraform setelah migrasi selesai. Untuk informasi selengkapnya, lihat Modifikasi konfigurasi dalam skenario Terraform setelah migrasi.
Migrasi tidak memengaruhi aspek-aspek berikut dari bisnis Anda:
- Kompatibilitas SDK: Setelah migrasi, aplikasi kustom dapat terus menggunakan kit pengembangan perangkat lunak (SDK) yang ada tanpa perubahan pada kode atau aplikasi. Jika Anda menggunakan SDK produk lain, seperti Function Compute, untuk enkripsi dan dekripsi bisnis, Anda tidak perlu memodifikasi SDK tersebut. Hal ini memastikan migrasi yang efisien, lancar, dan mulus.
- Dampak kinerja: Jika sebelum migrasi Anda mengakses kunci dan kredensial melalui jaringan publik, Anda dapat terus menggunakan SDK yang ada setelah migrasi tanpa perubahan kinerja. Untuk meningkatkan kinerja, Anda dapat beralih dari akses jaringan publik ke akses VPC. Setelah beralih, kinerja akan bergantung pada tipe instans.
- Kebijakan kontrol akses: Anda dapat terus menggunakan kebijakan kontrol akses yang ada setelah migrasi tanpa perubahan apa pun.
Dampak lainnya:
Setelah migrasi, ID versi kunci simetris dan asimetris berubah. Jika aplikasi kustom Anda memiliki logika validasi berdasarkan ID versi kunci, Anda harus mengevaluasi dan menghapus logika tersebut sebelum migrasi. Jika tidak, perubahan ID versi kunci akan menyebabkan validasi aplikasi gagal.
Catatan
Jika Anda menggunakan OpenAPI, pemanggilan yang menggunakan ID versi kunci lama tetap berhasil setelah migrasi. Anda tidak perlu mengubah kode bisnis Anda.

Dampak biaya

Logika penagihan untuk instans KMS 3.0 berbeda dari KMS 1.0. Sebelum melakukan migrasi, Anda harus memahami biaya yang terkait dengan instans KMS 3.0.Untuk informasi selengkapnya, lihat Penagihan langganan dan Bayar sesuai penggunaan.

Catatan tentang migrasi kunci

KMS memigrasikan metadata dan bahan kunci dari kunci master pelanggan (CMK). Metadata mencakup ID kunci, status kunci, perlindungan penghapusan, alias, dan tag. Data ini tetap tidak berubah setelah migrasi.

Kunci layanan

Kunci layanan tidak perlu dimigrasikan. Anda dapat terus menggunakannya seperti biasa dan melihatnya di konsol baru setelah login. Kunci layanan dibuat secara otomatis oleh produk cloud saat Anda mengonfigurasi enkripsi sisi server. Alias-nya menggunakan format alias/acs/<CloudProduct>.

Kunci master pelanggan

Hanya kunci dalam status Enabling yang dapat dimigrasikan. Kunci dalam status lain, seperti Disabled atau Schedule Deletion, tidak dapat dimigrasikan.

Tingkat perlindungan: Software

Tabel berikut menunjukkan tipe instans tujuan migrasi yang didukung.

Penting

Bring-Your-Own-Key (BYOK): Migrasi didukung. KMS langsung memigrasikan bahan kunci; Anda tidak perlu mengunggahnya secara manual.
Kunci multi-versi: Migrasi didukung. KMS memigrasikan semua versi kunci.
Jika rotasi otomatis diaktifkan untuk suatu kunci, Anda harus menonaktifkannya secara manual sebelum migrasi untuk memastikan konsistensi versi. Untuk informasi selengkapnya, lihat Rotasi kunci otomatis.
Pada instans manajemen kunci perangkat keras, kunci dapat disimpan di database atau HSM. Kunci yang dimigrasikan ke instans manajemen kunci perangkat keras disimpan di database secara default karena kunci yang disimpan di database mendukung rotasi. Pengaturan ini tidak dapat diubah.

Spesifikasi kunci yang akan dimigrasikan	Instans manajemen kunci perangkat lunak	Instans manajemen kunci perangkat keras
Aliyun_AES_256 (versi tunggal)	√	√
Aliyun_AES_256 (multi-versi)	√	√
RSA_2048 (versi tunggal)	√	×
EC_P256 (versi tunggal)	√	×
EC_P256K (versi tunggal)	√	×

Tingkat perlindungan: HSM

Penting

Hanya kunci di Daratan Tiongkok yang dapat dimigrasikan. Kunci di luar Daratan Tiongkok tidak dapat dimigrasikan. Jika Anda memiliki kunci yang tidak dapat dimigrasikan, hubungi kami.
BYOK: Migrasi tidak didukung.
Kunci multi-versi: Migrasi didukung untuk beberapa tipe kunci. KMS memigrasikan semua versi kunci.
Jika rotasi otomatis diaktifkan untuk suatu kunci, Anda harus menonaktifkannya secara manual sebelum migrasi untuk memastikan konsistensi versi. Untuk informasi selengkapnya, lihat Rotasi kunci otomatis.
Pada instans manajemen kunci perangkat keras, kunci dapat disimpan di database atau HSM. Kunci yang dimigrasikan ke instans manajemen kunci perangkat keras disimpan di database secara default karena kunci yang disimpan di database mendukung rotasi. Pengaturan ini tidak dapat diubah.

Tabel berikut menunjukkan tipe instans tujuan migrasi yang didukung.

Spesifikasi kunci yang akan dimigrasikan	Instans manajemen kunci perangkat lunak	Instans manajemen kunci perangkat keras
Aliyun_AES_256 (versi tunggal)	√	√
Aliyun_AES_256 (multi-versi)	√	√
Aliyun_SM4 (versi tunggal)	×	√
Aliyun_SM4 (multi-versi)	×	√
RSA_2048 (versi tunggal)	√	√
EC_P256 (versi tunggal)	√	√
EC_P256K (versi tunggal)	√	√
RSA_3072 (versi tunggal)	√	√
EC_SM2 (versi tunggal)	×	√

Catatan tentang migrasi kredensial

Semua jenis kredensial dapat dimigrasikan.

Penting

Di KMS 3.0, kredensial harus unik dalam satu Akun Alibaba Cloud dan satu instans KMS di satu wilayah. Jika beberapa kredensial di KMS 1.0 memiliki nama yang sama, atau jika kredensial dengan nama yang sama sudah ada di instans KMS 3.0 tujuan, migrasi tidak didukung.

KMS memigrasikan metadata dan semua versi kredensial. Metadata mencakup nama kredensial, status, dan tag. Data ini tetap tidak berubah setelah migrasi.

Kredensial dengan rotasi otomatis yang diaktifkan dapat dimigrasikan. Untuk memastikan konsistensi versi, Anda harus menonaktifkan rotasi otomatis secara manual sebelum migrasi.
Saat Anda memigrasikan kredensial, Anda juga harus memigrasikan kunci master yang mengenkripsinya.
Kredensial yang dienkripsi dengan kunci yang dikelola sistem dapat dimigrasikan. Namun, fitur pencadangan data tidak didukung untuk kredensial ini setelah migrasi. Untuk informasi selengkapnya tentang fitur pencadangan data, lihat Manajemen pemulihan bencana.

Periksa dengan cepat sumber daya yang akan dimigrasikan

Catatan

Metode ini hanya menampilkan kunci yang dapat dimigrasikan. Untuk kunci yang tidak dapat dimigrasikan, Anda dapat melihat kunci yang tersisa di konsol lama setelah migrasi dan menghubungi dukungan teknis Alibaba Cloud untuk bantuan.

Login ke konsol Key Management Service lama. Di panel navigasi sebelah kiri, klik Migration Tool.
Jika tombol Migrate tersedia, ini menunjukkan bahwa terdapat kunci atau kredensial yang perlu dimigrasikan di wilayah saat ini.
Penting
Data ditampilkan berdasarkan wilayah. Pastikan untuk memeriksa data di semua wilayah agar tidak melewatkan sumber daya apa pun.
Klik angka pada kolom Unmigrated Keys, Migrated Keys, Unmigrated Credentials, dan Migrated Credentials untuk melihat ID kunci dan nama kredensial tertentu.

Pilih instans KMS 3.0 yang sesuai

Evaluasi aspek-aspek berikut untuk memilih instans KMS 3.0 yang sesuai.

Nilai kebutuhan bisnis: Pilih instans KMS yang sesuai berdasarkan tipe instans tujuan migrasi kunci Anda.
Nilai kebutuhan kinerja: Pertimbangkan frekuensi operasi enkripsi dan dekripsi data dalam bisnis Anda. Misalnya, jika bisnis Anda adalah platform E-dagang berlalu lintas tinggi yang memproses banyak pesanan setiap hari, Anda perlu mengenkripsi informasi pembayaran pengguna (seperti nomor kartu bank dan kata sandi pembayaran) serta data pesanan. Anda mungkin memerlukan instans KMS dengan QPS tinggi. Dalam hal ini, pilih instans KMS yang mendukung 2.000 atau 4.000 QPS untuk memastikan operasi enkripsi dan dekripsi selesai tepat waktu serta menghindari penundaan atau kegagalan transaksi.
Nilai kebutuhan kepatuhan: Jika bisnis Anda perlu mematuhi sertifikasi FIPS, Anda harus membeli instans manajemen kunci perangkat keras.
Nilai anggaran biaya: Instans KMS menawarkan dua metode penagihan: langganan dan bayar sesuai penggunaan. Metode bayar sesuai penggunaan hanya direkomendasikan jika bisnis Anda menggunakan KMS semata-mata untuk enkripsi produk cloud. Untuk semua skenario lainnya, kami merekomendasikan penggunaan instans langganan.