Tempat Penyimpanan Secret: Dari File Konfigurasi ke Vault

Anda sedang menyiapkan aplikasi baru. Anda membuat file .env berisi kredensial database, API key, dan alamat server. Semua berjalan lancar di mesin Anda. Anda commit file tersebut ke Git agar rekan setim bisa menjalankan setup yang sama. Beberapa bulan kemudian, aplikasi sudah berjalan di produksi, dan seseorang tidak sengaja mendorong file .env itu ke repositori publik. Dalam hitungan menit, password database produksi Anda sudah tersebar di internet.

Skenario ini tidak jarang terjadi. Ini terjadi karena cara termudah untuk menyimpan secret juga merupakan cara paling berbahaya. Perjalanan dari menyimpan secret di file konfigurasi hingga menggunakan alat manajemen secret khusus adalah perjalanan yang dilalui setiap tim, seringkali setelah belajar dari pengalaman pahit.

Masalah dengan File Konfigurasi

Saat pertama kali belajar membuat aplikasi, meletakkan semuanya dalam satu file konfigurasi terasa alami. File .env, config.json, atau application.properties Anda menjadi campuran. Alamat server yang tidak sensitif bersebelahan dengan password database yang sangat sensitif. Seluruh file masuk ke Git, dan siapa pun dengan akses repositori bisa melihat semuanya.

Pendekatan ini berfungsi baik saat Anda satu-satunya pengembang dan aplikasi berjalan di laptop Anda. Namun begitu tim Anda bertambah atau aplikasi mencapai pengguna nyata, celah mulai terlihat. Setiap pengembang yang meng-clone repositori bisa melihat password produksi. Meskipun repositori bersifat privat, secret tetap tersimpan permanen di riwayat Git. Menghapus file dari commit terbaru tidak akan menghapusnya dari commit lama. Secret itu ada selamanya, dapat diakses oleh siapa pun yang tahu cara menjelajahi riwayat Git.

Langkah selanjutnya yang biasanya diambil tim adalah memisahkan secret dari konfigurasi biasa. File konfigurasi tetap di Git, tetapi nilai sensitif menjadi placeholder seperti DB_PASSWORD=changeme. Nilai asli disimpan di tempat lain: file yang tidak di-commit, variabel lingkungan di server, atau dokumen yang dibagikan melalui chat. Ini lebih baik daripada menyimpan secret di Git, tetapi memunculkan masalah baru. Tidak ada catatan siapa yang mengakses secret. Memutar password berarti memperbaruinya di banyak tempat secara manual. Jika file secret hilang atau rusak, tidak ada cadangan terkelola untuk memulihkannya.

Apa yang Diubah oleh Penyimpanan Secret Khusus

Tim yang menangani banyak aplikasi dan lingkungan pada akhirnya mencari alat yang dibangun khusus untuk secret. Vault, AWS Secrets Manager, Azure Key Vault, dan GCP Secret Manager dirancang untuk menangani data sensitif dengan benar. Secret tidak lagi berupa file di disk. Mereka menjadi objek yang diambil aplikasi melalui API.

Pergeseran dari file ke penyimpanan secret mengubah tiga hal mendasar:

Berikut contoh singkat cara menyimpan dan mengambil password database menggunakan HashiCorp Vault:

# Menyimpan secret
vault kv put secret/myapp DB_PASSWORD=supersecret

# Mengambil secret
vault kv get secret/myapp

# Output:
# ====== Data ======
# Key              Value
# ---              -----
# DB_PASSWORD      supersecret

Kontrol akses. Dengan file konfigurasi, siapa pun yang bisa membaca file bisa melihat secret. Dengan vault, Anda menentukan aplikasi atau pipeline mana yang dapat mengakses secret tertentu. Pipeline CI untuk lingkungan staging bisa mengambil kredensial staging tetapi tidak bisa menyentuh secret produksi. Granularitas ini tidak mungkin dilakukan dengan file.

Jejak audit. File tidak mencatat siapa yang membacanya. Vault mencatat setiap permintaan akses: siapa yang meminta, secret apa yang diminta, dan kapan itu terjadi. Jika secret bocor, Anda bisa melacak aplikasi atau pengguna mana yang mengaksesnya sekitar waktu kejadian.

Enkripsi saat diam dan dalam perjalanan. File konfigurasi menyimpan secret dalam teks biasa di disk. Vault mengenkripsi secret saat menyimpannya dan saat mengirimkannya melalui jaringan. Bahkan jika seseorang mendapatkan akses ke penyimpanan yang mendasarinya, mereka tidak bisa membaca secret tanpa kunci enkripsi.

Biaya Operasional Menggunakan Vault

Alat manajemen secret tidak gratis, dan biayanya tidak hanya bersifat moneter. Tim Anda perlu mempelajari cara mengoperasikan alat tersebut. Jika vault mati, aplikasi tidak bisa mengambil secret dan mungkin berhenti berfungsi sama sekali. Anda memerlukan strategi untuk ketersediaan tinggi, caching, atau mekanisme fallback agar pemadaman vault tidak menghentikan sistem produksi Anda.

Penyimpanan secret yang dikelola cloud mengurangi beban operasional tetapi memperkenalkan harga per-permintaan atau per-secret. Tim yang membuat ribuan permintaan secret per menit perlu mempertimbangkan apakah biayanya berkelanjutan. Opsi self-hosted seperti Vault memberi Anda lebih banyak kendali tetapi memerlukan upaya khusus untuk memelihara, meningkatkan, dan mengamankannya.

Memilih yang Sesuai dengan Tim Anda

Tidak ada satu jawaban benar untuk tempat menyimpan secret. Pilihan yang tepat tergantung pada ukuran tim, jumlah aplikasi, dan toleransi risiko.

Diagram alur berikut dapat membantu Anda memutuskan pendekatan mana yang sesuai dengan situasi Anda saat ini:

flowchart TD A[Mulai: Berapa banyak aplikasi dan pengembang?] --> B{Ukuran tim & kompleksitas} B -->|Tim kecil, satu aplikasi| C[Gunakan file .env tidak di-commit ke Git] B -->|Tim berkembang, banyak aplikasi| D[Gunakan variabel lingkungan dari CI] B -->|Tim besar, teregulasi| E[Gunakan vault khusus mis. HashiCorp Vault] C --> F[Resiko: rotasi manual, tanpa audit] D --> G[Lebih baik: konfigurasi terpusat, ada audit] E --> H[Terbaik: kontrol akses, audit, enkripsi]

Tim kecil dengan satu aplikasi dan beberapa lingkungan dapat menggunakan file terpisah yang tidak di-commit ke Git, selama semua orang memahami risikonya. Kuncinya adalah bersikap sengaja tentang pilihan tersebut, bukan terjebak secara default.

Tim dengan banyak aplikasi, beberapa lingkungan, dan banyak pengembang akan mendapat manfaat dari penyimpanan secret khusus. Biaya pengaturannya akan terbayar lunas pertama kali Anda perlu memutar kredensial di semua lingkungan atau menyelidiki siapa yang mengakses secret yang kemudian bocor.

Prinsip pentingnya adalah konsistensi. Metode apa pun yang Anda pilih, terapkan secara seragam. Mencampur pendekatan, beberapa secret di file, beberapa di variabel lingkungan, beberapa di vault, menciptakan kebingungan dan meningkatkan kemungkinan paparan yang tidak disengaja.

Daftar Periksa Praktis untuk Penyimpanan Secret

  • Apakah secret dipisahkan dari konfigurasi biasa?
  • Apakah secret dikecualikan dari version control (periksa .gitignore)?
  • Bisakah Anda memutar kredensial tanpa mengubah kode aplikasi?
  • Apakah Anda tahu aplikasi dan pipeline mana yang dapat mengakses setiap secret?
  • Apakah Anda memiliki log yang menunjukkan siapa yang mengakses secret dan kapan?
  • Jika penyimpanan secret Anda mati, bisakah aplikasi Anda tetap mulai atau gagal dengan baik?

Apa Selanjutnya

Mengetahui di mana menyimpan secret hanyalah setengah dari pekerjaan. Pertanyaan selanjutnya adalah bagaimana pipeline Anda mengambil secret tersebut tanpa menyimpannya di dalam konfigurasi pipeline itu sendiri. Pipeline CI/CD yang mencetak secret ke log, menyimpannya di variabel lingkungan yang terlihat oleh semua langkah, atau menyimpannya di file workspace tidak lebih baik dari file konfigurasi yang di-commit ke Git. Metode penyimpanan itu penting, tetapi bagaimana secret mengalir melalui proses pengiriman Anda sama pentingnya.