Belajar PKI - Key Management & Hardware Security

#Pendahuluan

Di episode 12 kalian menerbitkan sertifikat lewat Vault, dan di episode-episode sebelumnya kunci CA disimpan sebagai file di server. Episode 13 menjawab pertanyaan paling mendasar dalam PKI: bagaimana cara melindungi kunci privat itu sendiri? Sertifikat boleh dibagikan, tetapi kunci privat yang bocor berarti identitas CA jatuh ke tangan yang salah.

Ancaman terhadap kunci datang dari banyak arah: izin file yang longgar, backup yang lalai, karyawan yang keluar, sampai pencurian perangkat fisik. Semakin berharga sebuah kunci, semakin besar upaya yang layak dikeluarkan untuk melindunginya. Mulai dari praktik sederhana di filesystem hingga perangkat keras khusus bernama HSM.

Roadmap episode ini: kita bahas keamanan berbasis file dan passphrase, lalu HSM dan standar PKCS#11 dengan YubiKey PIV serta TPM, kemudian image HSM step-ca, dilanjutkan KMS seperti AWS KMS dan Azure Key Vault, dan ditutup split knowledge.

#Keamanan Berbasis File

Sebelum bicara perangkat mahal, pastikan dasar sudah benar. Banyak kunci CA terlanjur bocor hanya karena file dengan izin baca untuk semua pengguna, atau tersalin ke direktori yang salah saat backup.

#Izin File dan Kepemilikan

Kunci privat seharusnya hanya bisa dibaca oleh pemiliknya. Di lingkungan Unix, izin 600 adalah minimum, dan untuk kunci yang dipegang service, pemilik haruslah user khusus yang hanya menjalankan tugas tersebut.

chown root:ca-ops ca-key.pem
chmod 600 ca-key.pem

Selain izin, awasi cara kunci dibuat. Gunakan umask yang ketat agar file baru tidak tercipta dengan izin longgar, dan pastikan direktori tempat kunci disimpan tidak bisa diakses pengguna lain. Kebiasaan kecil ini mencegah kebocoran sebelum terjadi.

#Kunci Berpassphrase

Menjaga kunci tetap terenkripsi adalah lapisan berikutnya. Ketika kunci disimpan dengan enkripsi berbasis passphrase, kunci tidak berguna tanpa kata sandinya.

openssl genrsa -aes256 -out ca-key.pem 4096

openssl genrsa -aes256 meminta passphrase saat pembuatan dan menyimpan kunci dalam bentuk terenkripsi. Setiap kali dipakai, pemegang kunci harus memasukkan passphrase. Kelemahannya jelas: passphrase menjadi titik tunggal kegagalan, dan proses penandatanganan tidak lagi otomatis penuh.

#HSM dan Standar PKCS#11

Untuk perlindungan yang lebih kuat, kunci bisa dipindahkan dari filesystem ke perangkat keras khusus yang dirancang agar kunci tidak pernah keluar darinya. Perangkat ini disebut HSM, singkatan dari hardware security module.

#Apa itu HSM

HSM menyimpan kunci di dalam batas fisik yang terverifikasi. Operasi seperti penandatanganan terjadi di dalam perangkat, sehingga kunci privat tidak pernah terekspos ke memori sistem. Bahkan administrator HSM pun tidak bisa mengekstrak kunci mentahnya.

#PKCS#11

Cara aplikasi berbicara dengan HSM diatur standar PKCS#11. Standar ini mendefinisikan API untuk memuat modul, membuka sesi, dan melakukan operasi kriptografi. Banyak tool PKI modern mendukung PKCS#11, termasuk step-ca.

#YubiKey PIV

YubiKey adalah perangkat kecil yang bisa dipakai sebagai HSM murah. Fitur PIV-nya menyediakan slot kunci yang bisa menandatangani dan melakukan dekripsi. Kunci privat di dalam YubiKey tidak bisa diekstrak, dan setiap penggunaan biasanya butuh konfirmasi pemegang.

#TPM

Trusted Platform Module adalah chip yang tertanam di hampir semua laptop dan server modern. TPM mengunci kunci ke perangkat tertentu: kunci hanya bisa dipakai pada mesin tempat ia dibuat. Ini menjadikan TPM pilihan menarik untuk melindungi kunci mesin dari pencurian fisik.

#step-ca dengan HSM

step-ca dari episode 9 mendukung penyimpanan kunci di luar filesystem melalui antarmuka KMS. Untuk HSM, kalian memakai modul PKCS#11, misalnya SoftHSM untuk percobaan atau YubiKey untuk produksi kecil.

Image resmi smallstep menyediakan runtime yang dilengkapi modul PKCS#11. Konfigurasi dilakukan lewat URI KMS pada ca.json.

{
  "kms": {
    "type": "pkcs11",
    "uri": "pkcs11:token=smallstep?module-path=/usr/lib/softhsm/libsofthsm2.so",
    "pin": "1234"
  }
}

Dengan konfigurasi ini, kunci CA step-ca hidup di dalam HSM. Kunci tidak pernah ditulis ke disk sebagai file biasa, sehingga mengambil file backup saja tidak cukup untuk mencuri CA.

#KMS untuk Skala Cloud

Kunci CA juga bisa disimpan di KMS cloud. Pendekatan ini populer karena operasionalnya ditangani penyedia, dan kebijakan akses diatur lewat IAM.

#AWS KMS

AWS KMS mengelola kunci dengan perlindungan berlapis dan audit lengkap. step-ca mendukung AWS KMS sebagai backend, sehingga CA di infrastruktur AWS bisa memakai kunci yang sepenuhnya dikelola AWS.

#Azure Key Vault

Azure Key Vault menawarkan kemampuan serupa dengan integrasi mendalam ke ekosistem Azure. Pemilihan antara AWS KMS dan Azure Key Vault umumnya mengikuti penyedia cloud yang sudah dipakai tim kalian.

Keuntungan KMS: tidak perlu membeli perangkat fisik, ada manajemen akses berbasis identitas, dan audit terpusat. Pertimbangan utamanya adalah ketergantungan pada penyedia dan biaya per permintaan.

#Split Knowledge

Melindungi kunci dengan satu orang saja terlalu rapuh. Split knowledge membagi kemampuan menggunakan kunci ke beberapa pihak, sehingga tidak ada satu orang pun yang bisa menggunakan kunci sendirian.

Prinsip M-of-N membagi kunci menjadi N bagian, dan hanya M bagian yang dibutuhkan untuk memulihkan atau menggunakan kunci. Teknik ini dikenal sebagai secret sharing. Misalnya dengan aturan 3-dari-5, tiga dari lima pemegang bagian harus hadir sebelum kunci bisa dipakai.

Praktik ini sangat cocok untuk operasi sensitif seperti membuka kunci root CA yang disimpan offline. Tidak ada satu individu pun yang memiliki kuasa penuh, dan kehilangan satu bagian tidak membuat kunci tidak dapat dipulihkan.

#Penutup

Episode 13 menutup lapisan terakhir perlindungan PKI: kunci privat. Kalian memahami keamanan berbasis file dan passphrase, mengenal HSM dan standar PKCS#11 dengan YubiKey PIV serta TPM, mengonfigurasi step-ca dengan modul PKCS#11, mempertimbangkan KMS cloud, dan menerapkan split knowledge.

Inti yang harus dibawa pulang:

• Kunci privat yang bocor berarti seluruh CA jatuh ke pihak yang salah.
• Izin file 600 dan umask ketat adalah dasar yang tidak boleh dilewatkan.
• Passphrase menambah lapisan enkripsi, tetapi menciptakan titik tunggal kegagalan.
• HSM dan PKCS#11 menjaga kunci tidak pernah keluar dari perangkat keras.
• step-ca mendukung HSM lewat URI KMS dengan modul PKCS#11.
• KMS cloud dan split knowledge menjawab kebutuhan skala dan keamanan kolektif.

Di episode 14 kita merangkai semuanya menjadi satu alur: siklus hidup sertifikat. Kalian akan belajar enrollment hingga revocation, pemantauan kedaluwarsa, sertifikat short-lived 24 jam hingga 7 hari, SPIFFE dan SPIRE untuk mTLS di service mesh, serta observability dengan cert-monitor dan cert-manager cainjector. Sampai jumpa!