Key management — kenapa .env plaintext berbahaya
Kamu sudah tahu dari Fase 0: siapa yang pegang private key, dialah pemilik aset — titik, tanpa admin yang bisa membatalkan. Materi ini memetakan bagaimana private key produksi seharusnya disimpan, dari yang paling naif sampai yang dipakai institusi finansial sungguhan.
Intisari
- Private key produksi tidak boleh pernah ada sebagai string plain text — bukan di kode, bukan di
.env, bukan di log, bukan di environment variable container yang bisa dibaca lewatdocker inspect. - HSM/KMS (Hardware/Key Management Service) menyimpan key di dalam modul kriptografi yang tidak pernah mengeluarkan key mentah — permintaan sign dikirim ke modul, hasil tanda tangan yang keluar, key-nya sendiri tidak pernah 'keluar'.
- AWS KMS adalah salah satu opsi paling praktis untuk tim yang sudah di AWS — dibahas implementasinya di Fase 5.
- HashiCorp Vault adalah alternatif populer yang cloud-agnostic, sering dipakai tim yang perlu portabilitas lintas provider.
- Rotasi key dan IAM/access policy least-privilege (siapa boleh meminta signing, bukan cuma siapa yang tahu key) adalah bagian dari strategi ini, bukan detail opsional.
Kenapa .env plaintext adalah bom waktu
Untuk kredensial database biasa, kalau bocor, kamu bisa mengganti password dalam hitungan menit. Private key blockchain berbeda secara fundamental: tidak ada otoritas pusat yang bisa membatalkannya. Begitu private key bocor — lewat repositori git yang salah commit, log aplikasi yang terlalu detail, atau container image yang bocor — siapa pun yang menemukannya memiliki kontrol penuh atas aset yang dikendalikannya, selamanya, sampai dana dipindahkan (kalau sempat).
| Tempat penyimpanan | Key pernah "keluar" sebagai string? | Risiko utama |
|---|---|---|
| Hardcoded di kode / commit ke git | Selalu | Terlihat siapa saja yang akses repo, termasuk riwayat commit lama |
.env plain text | Ya, saat dibaca aplikasi | Terekspos lewat backup, log, container image, akses server |
| Environment variable container | Ya, saat proses berjalan | Terlihat lewat docker inspect, /proc/<pid>/environ, dump memory |
| Secret manager terenkripsi (mis. AWS Secrets Manager) | Ya, saat aplikasi mengambilnya | Lebih baik dari .env, tapi key tetap sempat jadi plain text di memori aplikasi |
| HSM / KMS | Tidak pernah | Permintaan signing dikirim ke modul; yang kembali cuma tanda tangan, bukan key-nya |
| Hardware wallet (Ledger, dst.) | Tidak pernah | Butuh perangkat fisik — kurang cocok untuk signing otomatis backend |
Cara berpikir tentang HSM/KMS: "sign as a service"
Perbedaan konsepnya sederhana tapi krusial. Pola naif: aplikasi memuat private key ke memori, lalu menandatangani transaksi sendiri di dalam proses aplikasi. Pola HSM/KMS: aplikasi mengirim permintaan "tolong tanda tangani hash ini dengan key bernama X", modul kriptografi terpisah yang melakukan operasi penandatanganan di dalam dirinya sendiri, dan yang dikembalikan ke aplikasi hanyalah hasil tanda tangan — key mentahnya tidak pernah meninggalkan modul, bahkan operator sistem sekalipun tidak bisa mengekstraknya dalam kondisi normal.
| Opsi | Karakteristik |
|---|---|
| AWS KMS | Terkelola penuh, terintegrasi IAM, dukungan kurva secp256k1 — dibahas implementasinya di Fase 5 |
| HashiCorp Vault | Bisa self-hosted atau HCP Cloud, cloud-agnostic, populer untuk tim multi-cloud |
| HSM fisik (mis. AWS CloudHSM) | Kontrol penuh atas modul kriptografi, kebutuhan compliance paling ketat, biaya operasional lebih tinggi |
| MPC (Multi-Party Computation) | Key "terpecah" di beberapa pihak, tidak pernah utuh di satu tempat — dipakai beberapa custodian institusional |
Prinsip pendukung: least-privilege dan rotasi
Menyimpan key dengan aman baru separuh pekerjaan. Pertanyaan berikutnya: siapa yang boleh meminta modul itu menandatangani sesuatu? Kebijakan IAM (di AWS KMS) atau policy (di Vault) harus membatasi ini seketat mungkin — service account backend yang butuh signing rutin, bukan setiap developer yang punya akses AWS console. Dan sama seperti kredensial lain, key produksi sebaiknya punya rencana rotasi — meski untuk private key blockchain, "rotasi" berarti memindahkan aset ke key/address baru, bukan sekadar mengganti nilai seperti API key biasa.
Konsekuensi ke kode yang sudah kamu tulis
Ingat contoh Credentials.create("PRIVATE_KEY_TESTNET_SAJA") di Fase 3? Itu hanya
untuk belajar dan testnet. Di produksi, pola itu diganti dengan implementasi custom
TransactionManager (web3j) atau layer signing setara di PHP yang memanggil KMS/Vault untuk
setiap operasi tanda tangan — private key tidak pernah menjadi argumen string di kode aplikasimu sama
sekali. Implementasi konkretnya dengan AWS KMS ada di Fase 5.
Latihan: audit kode sendiri (atau kode contoh Fase 3) — cari setiap tempat private key disebutkan sebagai string, environment variable, atau parameter fungsi. Untuk masing-masing, tuliskan: kalau file/log/container ini bocor, apa dampaknya? Ini latihan berpikir yang akan langsung dipakai saat merancang alur signing produksi di Fase 5.
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.