Mengelola kunci enkripsi dari pembuatan hingga pencabutan

Apa yang perlu dikelola selain algoritma?

Tim perlu tahu kunci mana yang melindungi data, siapa yang boleh memakainya, dan apa yang terjadi ketika kunci diganti atau hilang. Memilih algoritma enkripsi belum menjawab pekerjaan itu. Pengantar enkripsi dan pemakaian data uji tetap di panduan dasarnya.

Panduan ini terutama membahas kunci untuk data tersimpan. Kunci penandatanganan, kunci TLS dan token API mempunyai tujuan berbeda; jangan menggabungkan aturan cadangannya begitu saja. NIST SP 800-57 Part 1 Rev. 5 menjadi rujukan teknis. Halaman Rev. 6 yang diperiksa pada 2 Oktober 2026 masih berstatus Initial Public Draft, sehingga usulannya tidak diperlakukan sebagai versi final atau kewajiban hukum Indonesia.

Mulai dengan inventaris tanpa isi kunci

Gunakan inventaris kunci enkripsi. Catat ID dan versi, tujuan, aplikasi pemakai, pemilik, lokasi pengelolaan serta data/cadangan yang masih memerlukannya. ID membantu menemukan kunci; ID bukan pengganti pemeriksaan izin.

Pisahkan kewenangan memakai kunci dari mengelola, mengekspor atau menghapusnya. Untuk layanan pengelolaan kunci (KMS) atau perangkat pengaman kriptografi (HSM), periksa batas layanan dan hak yang benar-benar diberikan. Jangan menyalin nilai kunci ke spreadsheet, log atau tiket.

Tentukan kebutuhan perlindungan dan masa penggunaan bersama penanggung jawab sistem. Jangan memberi aturan “ganti setiap 90 hari” pada semua kunci tanpa alasan. Catat pula apakah perubahan hanya mengganti alias/versi aktif, membungkus ulang kunci data, atau benar-benar mengenkripsi ulang data; ketiganya menghasilkan pekerjaan berbeda.

Bedakan penggantian normal dengan dugaan kebocoran

Pada penggantian normal, tentukan kapan penulisan baru memakai versi baru dan sampai kapan data lama masih boleh dibaca dengan versi lama. Buktikan pembaca cadangan juga mengenali versi tersebut. Jangan menghapus kunci lama hanya karena aplikasi sudah memakai versi baru untuk dokumen baru.

Jika kunci diduga bocor, pembatasan akses perlu disertai penilaian data dan salinan yang terdampak. Status “dicabut” pada aplikasi tidak membuat salinan kunci yang sudah diambil berhenti bekerja. Periksa kebutuhan penggantian, pemrosesan ulang data, pemberitahuan serta pemulihan sesuai kasus; jalur insiden tetap mengikuti prosedur organisasi.

Contoh yang dijalankan: dua versi kunci

Unduh source dan hasil lab operasi infrastruktur 1.0. Jalankan contoh dengan data buatan:

node operations-lab.mjs --out operations-results.json

Contoh dijalankan 2 Oktober 2026, Node 24.21.0 pada macOS arm64. Bagian kunci menjalankan 11 kasus dengan AES-256-GCM, kunci acak 32 byte, IV acak 12 byte per enkripsi, dan penanda pemilik sebagai data tambahan yang diperiksa (AAD). Semua kunci tinggal dalam memori dan tidak diekspor ke hasil atau ZIP.

Kasus aktual	Hasil
K1 aktif dipakai pada dokumen buatan A	Enkripsi dan pembacaan berhasil.
K2 dibuat; K1 menjadi baca-saja	Penulisan memakai K1 ditolak; dokumen lama tetap dapat dibaca.
Dokumen baru memakai K2	Pembacaan dengan K2 berhasil; rotasi tidak mengubah dokumen K1.
Pemilik/AAD, tag atau kunci diganti	Dekripsi ditolak. Ini pemeriksaan konteks buatan, bukan seluruh izin aplikasi.
Status K1 dicabut pada registry contoh	Jalur aplikasi menolak, tetapi salinan nilai kunci masih dapat mendekripsi langsung.
K2 dihapus dari registry lalu salinan memori dikembalikan	Pembacaan gagal saat hilang, lalu berhasil setelah pemulihan.

Jangan memakai registry dalam memori ini sebagai KMS produksi. Contoh tidak menguji HSM, module FIPS tervalidasi, ekspor terlindungi, re-enkripsi massal, konkurensi, IV pada skala produksi atau penghapusan aman RAM/disk. Penolakan pada fungsi contoh bukan bukti semua jalur sistem menolak.

Uji pemulihan sebelum kunci dihentikan

Pulihkan data buatan beserta versi kunci dan metadata yang diperlukan. Pisahkan izin pemulihan dari akses umum; catat persetujuan, pemakai dan hasil. Kehilangan kunci yang dibutuhkan dapat membuat cadangan terenkripsi tidak terbaca.

Pemulihan dalam lab memakai salinan memori. Untuk layanan nyata, rencana berikut masih perlu dijalankan: kegagalan akses KMS, cadangan di lingkungan terpisah, pemulihan versi lama, pembatalan penghapusan sesuai fitur layanan, dan akses pengguna yang tidak berwenang. Cadangan kunci harus mengikuti tujuan kuncinya; kebutuhan memulihkan data terenkripsi tidak berarti semua kunci penandatanganan harus diarsipkan.

Kapan pekerjaan bisa ditutup?

Pemilik menyetujui versi aktif; penulisan dan pembacaan yang sah berhasil; penggunaan yang dilarang ditolak pada jalur yang diuji; dan pemulihan mempunyai hasil serta batas yang dicatat. Sebelum memusnahkan kunci, periksa ketergantungan data, cadangan dan retensi. Menghapus alias atau baris registry belum membuktikan semua salinan kunci musnah.

Simpan bukti di catatan verifikasi dan referensikan dari inventaris. Pengelolaan sertifikat dan titik TLS tetap mengikuti panduan TLS.

Bagian panduan yang diringkas dari OWASP mengikuti CC BY-SA 4.0, dengan perubahan bahasa dan contoh. Kode, worksheet dan hasil contoh orisinal Kompli memakai CC0 1.0.