Rotasi kunci otomatis - Key Management Service

Topik ini menjelaskan cara mengonfigurasi rotasi otomatis dari kunci master pelanggan (CMK) di Key Management Service (KMS).

Versi kunci

Sebuah CMK dapat memiliki beberapa versi kunci. Setiap versi kunci mewakili kunci yang dihasilkan secara independen. Versi kunci dari CMK yang sama tidak memiliki hubungan kriptografi satu sama lain. KMS secara otomatis merotasikan CMK dengan menghasilkan versi kunci baru.

Types of key versions

Versi kunci dibagi menjadi jenis berikut:

Versi Kunci Utama
- Versi kunci utama dari sebuah CMK adalah kunci enkripsi aktif. Setiap CMK hanya memiliki satu versi kunci utama pada satu waktu.
- Ketika Anda memanggil operasi enkripsi seperti GenerateDataKey atau Encrypt, KMS menggunakan versi kunci utama dari CMK yang ditentukan untuk mengenkripsi teks biasa.
- Anda dapat memanggil operasi DescribeKey untuk menanyakan atribut PrimaryKeyVersion.
Versi Kunci Non-Utama
- Versi kunci non-utama dari sebuah CMK adalah kunci enkripsi yang tidak aktif. Setiap CMK dapat memiliki nol hingga banyak versi kunci non-utama.
- Setiap versi kunci non-utama dulunya merupakan versi kunci utama dan bertindak sebagai kunci enkripsi aktif di masa lalu.
- Ketika versi kunci utama baru dibuat, KMS tidak menghapus atau menonaktifkan versi kunci non-utama karena mereka perlu digunakan untuk mendekripsi data.

Catatan Ketika Anda memanggil operasi enkripsi, versi kunci utama dari CMK yang ditentukan digunakan. Ketika Anda memanggil operasi dekripsi, versi kunci yang digunakan untuk enkripsi akan digunakan.

Generation of key versions

Anda dapat menghasilkan versi kunci melalui salah satu cara berikut:

Buat CMK.
Anda dapat memanggil operasi CreateKey untuk membuat CMK. Jika Anda mengatur parameter Origin ke Aliyun_KMS, KMS menghasilkan versi kunci awal dan mengaturnya sebagai versi kunci utama.
Jalankan kebijakan rotasi otomatis.
Setelah Anda mengonfigurasi kebijakan rotasi otomatis untuk CMK, KMS menjalankan kebijakan tersebut secara berkala untuk menghasilkan versi kunci.

Rotasi otomatis

Configure and query an automatic rotation policy

Ketika Anda memanggil operasi CreateKey untuk membuat CMK, Anda dapat menentukan kebijakan rotasi otomatis untuk CMK. Anda dapat memanggil operasi UpdateRotationPolicy untuk memperbarui kebijakan rotasi otomatis saat ini. Saat memanggil operasi tersebut, Anda harus mengonfigurasi parameter berikut:

EnableAutomaticRotation: menentukan apakah akan mengaktifkan rotasi otomatis.
RotationInterval: interval untuk rotasi otomatis.

Anda dapat memanggil operasi DescribeKey untuk melihat kebijakan rotasi otomatis yang dikonfigurasi. Parameter berikut dikembalikan:

AutomaticRotation: menunjukkan apakah rotasi otomatis diaktifkan. Untuk informasi lebih lanjut, lihat Dampak Status CMK terhadap Rotasi Otomatis.
- Disabled: menunjukkan bahwa rotasi otomatis dinonaktifkan.
- Enabled: menunjukkan bahwa rotasi otomatis diaktifkan.
- Suspended: menunjukkan bahwa KMS menangguhkan eksekusi rotasi otomatis meskipun rotasi otomatis diaktifkan.
RotationInterval: interval untuk rotasi otomatis.

Execute an automatic rotation policy

Ketika rotasi otomatis diaktifkan, KMS menghitung waktu rotasi berikutnya menggunakan rumus berikut:

<NextRotationTime> = <LastRotationTime> + <RotationInterval>

di mana:

LastRotationTime: waktu ketika versi kunci terakhir dibuat. Anda dapat memanggil operasi DescribeKey dan memeriksa parameter LastRotationDate untuk mendapatkan waktu tersebut.
NextRotationTime: waktu ketika KMS melakukan tugas rotasi berikutnya untuk membuat versi kunci. Anda dapat memanggil operasi DescribeKey dan memeriksa parameter NextRotationDate untuk mendapatkan waktu tersebut.

Penting Ketika Anda memperbarui parameter RotationInterval dari kebijakan rotasi otomatis, nilai NextRotationTime mungkin merupakan titik waktu di masa lalu. Ini tidak memengaruhi eksekusi kebijakan rotasi otomatis. Versi kunci baru dihasilkan secara berkala. Jika situasi ini terjadi, KMS segera mengeksekusi kebijakan rotasi otomatis.

Dampak rotasi otomatis pada enkripsi dan dekripsi

Setelah CMK dirotasi, KMS menggunakan versi saat ini dari CMK untuk mengenkripsi data. Untuk data yang dienkripsi menggunakan versi historis CMK, Anda hanya dapat menggunakan versi historis untuk mendekripsi data. Rotation1

Anda dapat memanggil operasi ReEncrypt untuk mendekripsi ciphertext yang dienkripsi menggunakan versi historis CMK dan mengenkripsi data teks biasa yang diperoleh menggunakan versi saat ini dari CMK. Rotation2

Dampak status CMK terhadap rotasi otomatis

Versi kunci baru hanya dapat dibuat untuk CMK yang diaktifkan. Untuk mengaktifkan CMK, atur parameter KeyState ke Enabled. Perhatikan hal-hal berikut:

Jika CMK berada dalam status Disabled atau Pending Deletion, jangan panggil operasi UpdateRotationPolicy untuk memperbarui kebijakan rotasi otomatisnya.
Jika CMK masuk ke status Disabled atau Pending Deletion setelah Anda mengaktifkan rotasi otomatis untuk CMK, KMS menangguhkan eksekusi rotasi otomatis. Dalam kasus ini, jika Anda memanggil operasi DescribeKey, nilai yang dikembalikan dari parameter AutomaticRotation adalah Suspended. Ketika CMK kembali ke status Enabled, kebijakan rotasi otomatisnya menjadi aktif.

Batasan

Kunci-kunci berikut tidak mendukung beberapa versi kunci:

Kunci yang dikelola layanan: kunci default yang dikelola oleh KMS untuk layanan cloud tertentu. Kunci-kunci ini milik pengguna layanan cloud dan digunakan untuk memberikan perlindungan enkripsi dasar untuk data pengguna.
Kunci berdasarkan Bring Your Own Key (BYOK): kunci yang Anda impor ke KMS. Atribut Origin dari kunci-kunci ini adalah EXTERNAL. KMS tidak menghasilkan materi kunci atau memulai tugas rotasi untuk kunci-kunci ini. Untuk informasi lebih lanjut, lihat Impor Materi Kunci.

Kedua jenis kunci ini tidak mendukung rotasi kunci manual atau otomatis berbasis versi. Kunci berbasis BYOK tidak memiliki beberapa versi di KMS karena alasan berikut:

Pengguna memiliki kontrol kuat atas persistensi dan siklus hidup kunci berbasis BYOK. Hal ini membuat manajemen kunci menjadi sulit dan rentan terhadap kesalahan. Misalnya, Anda harus memiliki fasilitas manajemen kunci lokal, data harus disinkronkan antara fasilitas lokal dan cloud, dan tidak ada periode tenggang yang disediakan untuk penghapusan materi kunci di cloud. Kompleksitas pemeliharaan beberapa versi kunci berbasis BYOK membuat manajemen kunci jauh lebih berisiko.
Baik versi kunci utama maupun non-utama dapat menjadi tidak tersedia pada titik waktu yang berbeda. Misalnya, jika versi kunci dihapus oleh KMS atau diimpor kembali ketika kedaluwarsa, CMK mungkin tidak disinkronkan dan data terenkripsi mungkin tidak dapat didekripsi menggunakan CMK yang benar. Hal ini memengaruhi integritas sistem.