Manajemen Kunci Cloud KMS: Review Akses dan Siklus Hidup
Enkripsi saat data diam bukan bukti bahwa decrypt terkendali. Review manajemen kunci harus mengidentifikasi owner key, workload yang dilindungi, administrator, pengguna kriptografis, jalur policy, status siklus hidup, dan dependensi pemulihan. Pisahkan pihak yang mengadministrasi key dari workload yang dapat encrypt atau decrypt. Satu identitas untuk keduanya melemahkan pemisahan tugas.
Susun inventaris dan kepemilikan key
Inventaris customer-managed key, alias atau key version, region/lokasi, tujuan, tingkat perlindungan, integrasi, klasifikasi data, owner, serta dependensi pemulihan. AWS customer managed key memberi kendali atas policy, lifecycle, rotation, dan audit. AWS managed maupun AWS owned key memiliki batas kendali berbeda. Google Cloud KMS mendukung customer-managed key, HSM, external key, dan integrasi CMEK. Azure Key Vault menangani key, secret, dan certificate dengan otorisasi Azure RBAC atau Key Vault access policy.
Tandai enkripsi default provider terpisah dari kebutuhan kendali pelanggan. Default encryption tetap melindungi data, tetapi belum tentu memberi policy, lifecycle, atau catatan pemakaian yang dipilih pelanggan. Jangan menyatakan key dapat dipulihkan sebelum aplikasi diuji memulihkan ciphertext dengan key version lama.
Review policy, grant, dan context
Di AWS, key policy, IAM policy, dan grant dievaluasi bersama. Grant berlaku untuk satu KMS key dan satu grantee pada operasi yang disebutkan; grant tidak dapat menolak akses. Review kms:CreateGrant dengan ketat karena principal yang dapat membuat grant dapat mendelegasikan penggunaan key. Untuk kebutuhan layanan sementara, batasi operasi dan constraint, tetapkan retiring principal, simpan grant ID, lalu retire atau revoke setelah selesai.
Encryption context adalah konteks non-rahasia yang diautentikasi pada enkripsi KMS simetris. Context yang sama dibutuhkan saat decrypt dan AWS mencatatnya di CloudTrail. Gunakan label stabil seperti aplikasi, environment, dan tenant ID; jangan gunakan kredensial, email, atau isi pelanggan. Ikat condition policy atau grant bila context menjadi bagian otorisasi.
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:role/payments-app"},
"Action": ["kms:Decrypt"],
"Resource": "*",
"Condition": {"StringEquals": {"kms:EncryptionContext:App": "payments"}}
}Ini pola awal, bukan key policy lengkap. Uji decrypt dengan context benar, context salah, principal salah, dan environment salah. Uji juga bahwa aplikasi yang hanya memerlukan GenerateDataKey tidak dapat mendekripsi ciphertext sembarang.
Untuk key eksternal atau HSM, tambahkan availability provider, prosedur eskalasi, dan dampak kegagalan decrypt ke runbook. Kontrol kriptografis lebih kuat dapat menambah dependensi operasional; owner layanan harus menerima trade-off tersebut sebelum data produksi dipindahkan.
Kelola rotasi dan penghapusan sebagai perubahan produksi
Dokumentasikan metode rotasi, jadwal, pemicu, dukungan decrypt version lama, rollout aplikasi, dan rollback. Rotasi menghasilkan material baru untuk enkripsi baru; material lama mungkin masih diperlukan untuk data sebelumnya. CMEK Google Cloud memberi kendali atas rotasi serta lifecycle key version. Azure Key Vault mendukung logging dan otorisasi per aplikasi agar pemakaian key dapat direview. Rencana rotasi tanpa uji consumer dapat menimbulkan outage.
Penghapusan bersifat destruktif. AWS dapat menjadwalkan penghapusan customer managed key; lakukan hanya setelah approval owner, inventaris dependensi, uji backup/restore, dan jalur pembatalan terdokumentasi. Disable atau destroy key version di platform lain wajib melalui change control sama. “Tidak ada trafik sekarang” bukan bukti aman karena arsip, snapshot, queue tertunda, dan retensi dapat masih membutuhkan ciphertext lama.
| Pemeriksaan | Field bukti | Owner | Pass/fail | Pengecualian | Perbaikan |
|---|---|---|---|---|---|
| Akses key | key ID, versi policy/grant, hasil uji | owner key | pass/fail | partner scoped, expiry | hapus decrypt/grant luas |
| Context | nilai diizinkan, uji negatif, event CloudTrail | owner layanan | pass/fail | format lama, tanggal migrasi | tambah condition dan deploy |
| Rotasi | riwayat version, uji consumer, rollback | owner platform | pass/fail | integrasi tidak mendukung | dokumentasikan kontrol kompensasi |
| Penghapusan | dependensi, approval, bukti restore | owner risiko | pass/fail | retention hold | batalkan schedule dan pertahankan key |
Artefak selesai memuat timestamp, environment, reviewer, referensi policy immutable, hasil uji, approver dan expiry pengecualian, owner perbaikan, serta tanggal retest. Simpan juga output decrypt yang ditolak; happy path yang berhasil tidak membuktikan least privilege. Review ulang saat aplikasi pindah region, mengganti account/project, atau menambahkan layanan terintegrasi karena key lama sering tertinggal sebagai jalur decrypt. Pengujian infrastruktur dapat memvalidasi jalur akses kriptografis yang disetujui.
Kasus kerja: pemisahan encryption context
Buat dua record uji di bawah key sama dengan nilai encryption context berbeda untuk tenant dan tujuan. Output dekripsi diharapkan berhasil hanya ketika pemanggil memberi context tepat yang diizinkan key policy serta record aplikasi. Coba tukar ciphertext, hilangkan context, ubah tenant, nonaktifkan key, dan cabut grant. Catat kelas error tanpa menjadikan teks error sebagai perilaku untuk pelanggan. Verifikasi run recovery hanya dapat mendekripsi cakupan terdokumentasi dan memakai principal yang disetujui terpisah.
Bukti penutupan menghubungkan alias pengenal key, versi policy, keputusan rotasi, inventaris grant, hash ciphertext uji, dan review perlindungan penghapusan. Pengecualian darurat harus menyebut key, caller, tujuan, waktu mulai dan akhir, lalu mendapat pemeriksaan kedaluwarsa independen. Uji ulang setelah edit policy dan upgrade library perangkat lunak; encrypt yang sukses saja tidak membuktikan decrypt tanpa izin telah diblokir.
Tambahkan uji pemisahan context untuk caller lintas tenant dan jalur recovery. Hasil harus memperlihatkan izin sesuai konteks atau penolakan, tanpa menulis nilai rahasia ke log bukti. Owner menandatangani hasil setelah memeriksa policy efektif.