Belajar PKI - Security Best Practices & Compliance

#Pendahuluan

Episode 15 membawa kalian ke paradigma Zero Trust, tempat identitas menjadi fondasi keamanan. Identitas yang kuat harus dikelola dengan baik. Tanpa praktik yang benar, CA yang kalian bangun justru bisa menjadi sumber masalah terbesar, karena satu private key yang bocor membatalkan semua kepercayaan. Episode 16 membahas sisi tata kelola PKI.

Kita akan membahas best practice yang berlaku di industri: memisahkan root CA dan intermediate, merotasi key secara berkala, menjaga private key agar tidak pernah menyentuh repo, serta mencatat setiap penerbitan. Setelah itu kita menghubungkannya dengan kerangka compliance yang sering menjadi syarat audit: PCI DSS, SOC 2, NIST SP 800-57, dan FIPS 140-3.

Tujuan episode ini sederhana: kalian tidak hanya bisa membangun CA, tapi juga mempertanggungjawabkannya. Sebab di lingkungan produksi, kepercayaan dibangun bukan hanya oleh kriptografi, tapi juga oleh proses.

#Prinsip Keamanan PKI di Produksi

Ada beberapa aturan main yang hampir selalu ditemui di organisasi yang serius mengelola PKI. Pertama, pisahkan peran root CA dengan intermediate CA. Kedua, rotasi key pada interval yang wajar. Ketiga, jangan pernah mencampur private key dengan source code. Keempat, catat semua aktivitas penerbitan dan pencabutan. Kelima, batasi siapa yang bisa menerbitkan sertifikat.

Prinsip-prinsip ini bukan sekadar formalitas. Banyak insiden besar bermula dari private key CA yang tersimpan di tempat yang salah. Setelah key itu dicuri, penyerang bisa menerbitkan sertifikat palsu atas nama organisasi, dan tidak ada yang bisa membedakannya dari sertifikat asli sampai key-nya dicabut secara global.

#Root CA Offline dan Intermediate Online

Pembagian dua lapis CA adalah standar industri. Root CA bertugas menandatangani intermediate CA saja. Karena ia jarang dipakai, ia bisa disimpan di mesin yang tidak tersambung jaringan, bahkan di dalam HSM atau brankas. Intermediate CA yang menandatangani sertifikat sehari-hari hidup secara online, karena ia harus selalu siap melayani permintaan.

Jika intermediate CA disusupi, kalian tinggal mencabut intermediate tersebut dan menerbitkan intermediate baru dari root. Root CA yang offline tetap aman, sehingga seluruh hierarki bisa dibangun ulang tanpa mengganti kepercayaan publik yang sudah tersebar. Inilah alasan model dua lapis dipakai hampir di semua CA komersial.

openssl req -x509 -newkey rsa:4096 \
  -keyout root-ca.key -out root-ca.crt \
  -days 3650 -nodes \
  -subj "/CN=Root CA Offline"

Contoh di atas membuat root CA baru langsung di mesin offline dengan key RSA 4096 dan masa berlaku 10 tahun. Perhatikan opsi -nodes: karena mesinnya offline, kalian bisa memutuskan apakah private key dienkripsi dengan passphrase atau tidak. Simpan key ini di tempat yang aman, lalu angkat mesinnya dari jaringan.

Kemudian intermediate CA dibuat dan ditandatangani oleh root.

openssl req -newkey rsa:4096 \
  -keyout intermediate.key -out intermediate.csr \
  -subj "/CN=Intermediate CA Online"
openssl x509 -req -in intermediate.csr \
  -CA root-ca.crt -CAkey root-ca.key \
  -CAcreateserial -out intermediate.crt -days 1825

Pola yang terlihat di fence adalah prinsip yang kita bicarakan: root tetap offline, sementara intermediate yang menandatangani sertifikat pengguna berjalan online. Jika kalian memakai step-ca, konsep ini bisa dipetakan dengan root CA sebagai sumber dan intermediate sebagai provisioner yang aktif.

#Key Rotation dan Lifecycle

Key rotation adalah penggantian pasangan key lama dengan yang baru dalam interval terjadwal. Rotasi bukan berarti key lama pasti disusupi; ia adalah pengendalian risiko. Semakin lama key dipakai, semakin besar peluang ia dianalisis atau bocor. Rotasi memastikan dampak kebocoran tetap terbatas.

Aturan praktis yang sering dipakai: root CA key bisa bertahan sangat lama, sedangkan intermediate key lebih sering dirotasi. Sertifikat leaf sebaiknya berumur pendek dan diperbarui otomatis, seperti yang kalian lihat di episode 10 dengan cert-manager dan renewBefore.

Saat merotasi, perhatikan masa tumpang tindih. Jangan langsung menghapus key lama, karena masih ada sertifikat yang berlaku dan memercayainya. Buat intermediate baru, biarkan yang lama menyelesaikan masa berlakunya, lalu pensiunkan setelah semua pemegang sertifikat beralih.

#Jangan Taruh Private Key di Repo

Ini aturan yang paling sering dilanggar pemula. File .env atau folder config yang ikut ter-commit ke Git adalah cara tercepat menyebarkan rahasia. Private key di repo berarti setiap orang yang punya akses repo, termasuk yang sudah keluar, bisa menerbitkan atau memalsukan identitas.

Bila sudah terlanjur ter-commit, anggap key itu bocor. Cabut dari semua pemakaian, putar ulang, dan perbaiki sejarah repo bila perlu. Ingat, menghapus file di commit terakhir tidak cukup; riwayat Git masih menyimpan versi lama. Untuk masa depan, gunakan secret manager, ciptakan kebijakan agar repo di-scan, dan jangan pernah menyalin key ke image Docker.

Bahkan image pun bukan tempat yang aman. Image di registry bisa diunduh siapa saja yang punya akses, dan layer image tidak bisa dihapus secara praktis. Private key sebaiknya di-inject saat runtime dari secret store, bukan dibakar ke dalam image.

#Audit dan Monitoring

CA adalah aset yang aktivitasnya harus bisa dipertanggungjawabkan. Audit di sini berarti mencatat setiap peristiwa: siapa menerbitkan sertifikat, untuk apa, kapan, dan lewat provisioner mana. Catatan ini berguna untuk investigasi, kepatuhan, dan juga untuk mendeteksi anomali.

Monitoring melengkapi audit. Pantau masa berlaku sertifikat yang mendekati kedaluwarsa, perhatikan lonjakan penerbitan yang tidak wajar, dan pasang alert ketika intermediate CA mendekati akhir umurnya. Sertifikat yang kedaluwarsa di tengah jalan lebih menyakitkan daripada kebanyakan insiden lain, karena menyebabkan outage yang tidak jelas penyebabnya.

openssl x509 -in server.crt -noout \
  -startdate -enddate -subject

openssl x509 -noout -enddate menampilkan tanggal kedaluwarsa sebuah sertifikat. Dalam skala besar, skrip seperti ini dijadwalkan untuk memindai semua sertifikat yang dikelola, dan hasilnya dibandingkan dengan ambang batas peringatan.

#Compliance: PCI DSS, SOC 2, NIST, dan FIPS

Compliance adalah jembatan antara praktik keamanan dan kewajiban hukum atau kontrak. Empat kerangka yang paling relevan untuk PKI: PCI DSS untuk kartu pembayaran, SOC 2 untuk penyedia layanan, NIST untuk standar teknis, dan FIPS untuk modul kripto.

#PCI DSS

PCI DSS adalah standar untuk organisasi yang menangani data kartu pembayaran. PKI masuk ke dalamnya karena transport data kartu harus dienkripsi, dan kunci kripto harus dikelola dengan baik. Persyaratan seperti penggunaan kunci yang kuat, rotasi berkala, dan pembatasan akses ke kunci adalah bagian dari praktik yang kita bahas di atas.

#SOC 2

SOC 2 menilai kontrol internal penyedia layanan berdasarkan lima prinsip: keamanan, ketersediaan, integritas pemrosesan, kerahasiaan, dan privasi. Untuk PKI, auditor melihat bagaimana CA dikelola: siapa yang punya akses, apakah ada pemisahan tugas, dan bagaimana lifecycle sertifikat dicatat. Dokumentasi dan audit trail yang rapi adalah kunci kelulusan.

#NIST SP 800-57

NIST SP 800-57 adalah publikasi yang paling sering dirujuk untuk manajemen kunci. Ia memberikan panduan tentang pemilihan algoritma, panjang kunci, umur kriptografis, dan periode penggunaan. Misalnya, rekomendasi bahwa key signing harus dibedakan dari key encryption, dan setiap tujuan menggunakan pasangan kunci yang berbeda.

#FIPS 140-3 dan OpenSSL FIPS Provider

FIPS 140-3 mengatur modul kripto yang digunakan lembaga pemerintah AS dan organisasi yang harus mengikutinya. Fokusnya pada modul: algoritma yang disetujui, mekanisme deteksi kesalahan, dan batas keamanan fisik. Bagi kalian yang memakai OpenSSL, ada mode FIPS yang membatasi OpenSSL hanya pada algoritma yang disetujui.

openssl list -providers
openssl fipsinstall -out /etc/ssl/fipsmodule.cnf

openssl list -providers menampilkan provider yang aktif. Setelah instalasi modul FIPS selesai, konfigurasi OpenSSL diarahkan ke modul tersebut sehingga hanya algoritma FIPS yang diizinkan.

#Penutup

Episode 16 membawa kalian dari cara membangun CA menuju cara mengelola CA secara bertanggung jawab. Kalian memahami pemisahan root CA offline dan intermediate online, pentingnya key rotation, larangan menyimpan private key di repo atau image, serta kebutuhan audit dan monitoring. Di sisi compliance, kalian mengenal PCI DSS, SOC 2, NIST SP 800-57, dan FIPS 140-3.

Inti yang harus dibawa pulang:

• Pisahkan root CA offline dari intermediate online untuk membatasi dampak insiden.
• Rotasi key dilakukan terjadwal, bukan hanya saat terjadi kecurigaan.
• Private key tidak pernah boleh masuk repo atau image; gunakan secret store saat runtime.
• Catat semua penerbitan dan pantau masa berlaku sertifikat secara berkala.
• PCI DSS, SOC 2, dan NIST SP 800-57 memberi kerangka pengelolaan kunci yang bisa diaudit.
• FIPS 140-3 mengatur modul kripto, dan OpenSSL menyediakan provider khusus untuk itu.

Di episode 17 kita menyelami format dan detail teknis X.509: PEM, DER, PKCS 12, JKS, konversi antar format, Certificate Transparency, Extended Key Usage, name constraints, dan seluk-beluk RFC 5280. Sampai jumpa!