Belajar Vault - Problem Statement, Secret Sprawl & Mengapa Membutuhkan Vault

#Pendahuluan

Di episode 0 sebelumnya, kita sudah menyiapkan fondasi teknis: menguasai skill dasar Linux CLI, konsep kriptografi, pemahaman REST API & JSON, serta menginstall Vault CLI dan menjalankan Vault server untuk pertama kali. Nah, di episode 1 ini kita akan mundur sejenak dari terminal dan membahas mengapa Vault ada di dunia ini — karena sebelum memahami cara kerja sebuah alat, kita harus paham dulu masalah apa yang ia pecahkan.

Mengapa ini penting? Karena tools keamanan bermunculan setiap tahun, dan keputusan "apakah tim ini butuh Vault" tidak bisa diambil hanya dari sekadar "Vault itu populer". Kalian harus bisa melihat praktik buruk di sekeliling kalian — API key di source code, file .env yang ter-commit, password database yang sudah 3 tahun tidak ganti — dan menyadari itu semua adalah luka yang sedang menunggu untuk dieksploitasi. Dengan pemahaman ini, kalian bukan hanya bisa memakai Vault, tapi juga bisa berargumen secara teknis mengapa tim kalian harus pindah ke secret management yang terpusat.

Di episode ini kita akan membahas tiga hal: pertama, apa itu secret sprawl dan kenapa ia begitu berbahaya; kedua, mengapa Vault menjadi jawaban atas masalah ini; ketiga, taksonomi tipe secret yang akan menjadi peta konsep untuk seluruh series.

#Apa Itu Secret Sprawl?

Secret adalah istilah untuk informasi rahasia yang memberi akses: password, API key, token, sertifikat, dan database credential. Secret sprawl (dari kata sprawl = menyebar tak terkendali) adalah kondisi ketika secret tersebar di mana-mana — di source code, di file konfigurasi, di spreadsheet, di chat grup, di log server — tanpa ada satu tempat pun yang mengontrolnya. Ibaratnya, kunci-kunci brankas kalian digantung di sembarang tempat: di bawah keset, di balik pot bunga, di kantong jaket, bahkan ditempel di layar monitor.

Masalahnya bukan pada satu secret yang bocor, melainkan pada ketidakterkendaliannya. Tidak ada yang tahu berapa banyak secret yang ada, di mana saja ia disimpan, siapa saja yang punya akses, dan kapan terakhir kali dirotasi. Inilah yang membuat satu kebocoran kecil bisa merembet menjadi bencana besar.

#Bentuk-Bentuk Secret Sprawl

Mari kita bedah pola-pola buruk yang paling umum ditemukan di dunia nyata:

1. Hardcoded API Keys & Password di Source Code. Inilah bentuk paling klasik dan paling parah. Developer yang terburu-buru menulis kredensial langsung di dalam kode agar aplikasi cepat jalan. Bahkan di era sekarang, scan GitHub menemukan ribuan secret baru yang ter-commit setiap hari.

const axios = require('axios');
 
const API_KEY = 'sk_live_51N3xK9qWtY8mP2cD4fG6hJ7kL0zX9cV8bN7mQ';
const DATABASE_PASSWORD = 'p@ssw0rd2023!';
 
axios.get('https://api.example.com/v1/orders', {
  headers: { Authorization: `Bearer ${API_KEY}` }
});

2. File .env yang Ter-commit ke Git. Alur kerja yang tampak rapi — memisahkan config dari kode via .env — berubah menjadi jebakan ketika file .env ikut ter-commit ke repository. History Git tidak menghilangkan apa pun: sekali ter-commit, secret itu akan selamanya ada di riwayat repo, bahkan setelah dihapus di commit berikutnya.

 # .gitignore
-# .env            ← sebelumnya tidak di-ignore
+.env              ← ditambahkan ke .gitignore (terlambat!)
+.env.local

3. Kredensial Statis yang Jarang Dirotasi. Password database yang dibuat saat setup server 3 tahun lalu dan tidak pernah diganti. Semua orang di tim — termasuk mantan karyawan yang sudah keluar — masih tahu password itu. Ini ibarat tetap memakai kunci rumah yang sama setelah karyawan lama dipecat: praktik yang absurd kalau dipikir, tapi luar biasa umum di dunia IT.

4. Secret di Spreadsheet, Chat, dan Config Files. Perusahaan mencatat semua kredensial di Google Sheet, men-share-nya lewat Slack/Telegram, atau menaruhnya di config file yang tersinkron ke semua mesin. Nyaman, ya. Aman, tidak. Setiap orang yang pernah melihat chat atau file itu membawa "kunci" dalam ingatan mereka.

#Skenario Horor: Satu .env yang Bocor

Bayangkan skenario berikut, yang terinspirasi dari insiden yang sangat-sangat umum terjadi di industri:

Seorang developer bernama Budi sedang mengerjakan fitur pembayaran. Karena harus tes API gateway dengan credential asli, ia menyalin key production ke file .env.local-nya. Suatu hari, dalam kondisi buru-buru, ia menjalankan git add . dan git commit — tanpa menyadari file .env.local tidak ter-ignore di cabang kerjaannya. Commit itu lalu di-push dan masuk Pull Request.

Dua minggu kemudian, sebuah bot pemindai GitHub otomatis menemukan pola sk_live_... di repository tersebut. Bot ini menjual informasi itu. Dalam hitungan jam, akun perusahaan di-request sebanyak ribuan transaksi fiktif. Tagihan cloud dan payment processor meledak dalam semalam. Tim security baru sadar ketika anomaly detection berbunyi — dan saat itu, damage sudah terjadi.

Yang paling menyakitkan: Budi bahkan bukan karyawan yang lalai. Ia hanya tidak punya sistem yang memaksanya menyimpan secret dengan aman.

Pola di atas bukan fiksi — ia adalah gabungan dari ribuan insiden nyata yang terjadi setiap tahun di seluruh dunia. Perhatikan bahwa tidak ada satu pun titik kegagalan yang terlihat dramatis: satu commit, satu key, satu bot. Tapi dampaknya berlapis: kehilangan uang, kehilangan reputasi, dan waktu berbulan-bulan untuk pemulihan serta audit forensik.

#Dampak Nyata Secret Sprawl

Jika dirangkum, secret sprawl menimbulkan kerusakan di beberapa lapisan sekaligus:

#Mengapa HashiCorp Vault?

Setelah melihat lukanya, sekarang kita lihat obatnya. Vault menjawab secret sprawl bukan dengan satu fitur, melainkan dengan empat kemampuan inti yang saling melengkapi. Empat inilah yang akan menjadi benang merah seluruh series ini.

#1. Centralized Secret Storage

Vault menjadi satu tempat terpusat untuk semua rahasia. API key, database credential, sertifikat, token — semuanya hidup di satu sistem dengan satu kebijakan akses dan satu log audit. Alih-alih menyebar di 10 file .env, 3 spreadsheet, dan 5 chat grup, secret sekarang punya satu alamat. Ini bukan sekadar "merapikan", melainkan mengubah secret dari barang tak terkendali menjadi aset yang terkelola.

vault kv get secret/api/database          # credential database
vault kv get secret/api/payment-gateway   # API key payment
vault read transit/keys/app-key           # encryption key
vault read pki/issue/api-server           # sertifikat TLS

#2. Dynamic Secrets

Inilah fitur yang paling membedakan Vault dari "brankas digital" biasa. Secret statis (yang kita tulis sekali dan dipakai selamanya) bisa bocor dan dipakai terus-menerus. Dynamic secret adalah kredensial yang dibuat saat diminta oleh Vault, memiliki umur terbatas (TTL), dan otomatis hancur setelah masa berlakunya habis.

Bayangkan perbedaannya lewat analogi kartu hotel:

Konsekuensinya revolusioner: secret yang bocor tidak lagi berbahaya. Kalau database credential aktif hanya 1 jam dan sudah lewat, penyerang yang memegangnya akan gagal total. Kita akan membangun dynamic secrets secara hands-on di episode 5 (Dynamic Database Secrets Engine).

#3. Data Encryption-as-a-Service (EaaS)

Banyak aplikasi harus mengenkripsi data sensitif (nomor kartu kredit, NIK, data kesehatan) — dan di situlah jebakan klasik muncul: di mana menyimpan kunci enkripsinya? Kalau kunci disimpan di aplikasi, satu serangan ke aplikasi = kunci ikut bocor.

Vault menjawabnya dengan Transit Secrets Engine: Vault melakukan enkripsi/dekripsi di Vault, sedangkan data tetap berada di aplikasi. Aplikasi cukup mengirim plaintext dan menerima ciphertext, tanpa pernah melihat atau memegang kunci enkripsi. Kunci terpusat di Vault, dirotasi tanpa mengganggu aplikasi, dan bisa diaudit. Kita akan membedahnya di episode 6.

#4. Fine-Grained Access Control & Full Audit Logging

Dua hal yang hampir mustahil dicapai di era file .env:

• Access control granular: Vault memakai policies untuk menentukan siapa boleh mengakses path secret mana, dengan kemampuan apa (read, write, delete, dsb). Aplikasi A tidak akan pernah bisa membaca secret milik aplikasi B.
• Audit log lengkap: setiap request ke Vault tercatat — siapa, kapan, dari mana, mengakses apa, dengan hasil apa. Saat insiden terjadi, kalian bisa menjawab pertanyaan "siapa yang mengakses secret ini terakhir kali?" dengan data, bukan tebakan.

vault audit enable file file_path=/var/log/vault/audit.log
Success! Enabled the file audit device at: file/

#Taksonomi Tipe Secret

Sebelum melangkah lebih jauh ke episode-episode teknis, kita perlu peta. Vault menangani empat tipe rahasia utama, dan masing-masing ditangani oleh secrets engine yang berbeda:

#1. Static Secrets — KV Secrets Engine

Rahasia yang disimpan apa adanya dan relatif statis: API key, token, password aplikasi. Ini kategori paling sederhana dan paling umum. Di Vault ditangani oleh KV (Key-Value) Secrets Engine — yang akan kita bedah tuntas di episode 4.

vault kv put secret/api/payment-gateway key="sk_live_xxxx" 
Success! Data written to: secret/api/payment-gateway

#2. Dynamic Secrets — Database/Cloud Secrets Engines

Kredensial yang di-generate Vault secara on-demand dengan umur terbatas: user database sementara, IAM credentials cloud sementara. Ditangani oleh Database Secrets Engine dan Cloud Secrets Engines (AWS, GCP, Azure). Kita pelajari di episode 5.

#3. Encryption Keys — Transit Secrets Engine

Kunci kriptografi yang dipakai untuk enkripsi/dekripsi data tanpa menyimpan data itu sendiri di Vault. Ditangani oleh Transit Secrets Engine, dibahas di episode 6.

#4. PKI Certificates — PKI Secrets Engine

Sertifikat X.509 (TLS/SSL) yang diterbitkan Vault sebagai Certificate Authority, dengan umur pendek dan rotasi otomatis. Ditangani oleh PKI Secrets Engine, dibahas di episode 7.

#Mengapa Dynamic Lebih Baik dari Static?

Pertanyaan yang sering muncul: "Kalau static secret lebih simpel, kenapa tidak pakai itu saja?" Jawaban singkatnya: karena static secret adalah bom waktu, sedangkan dynamic secret adalah kartu hotel yang otomatis kedaluwarsa.

Ini bukan berarti static secret tidak punya tempat — banyak secret memang tidak bisa dibuat dinamis (misalnya API key vendor pihak ketiga). Justru karena itu Vault mendukung keduanya: pakai static untuk yang memang statis, dan pakai dynamic untuk yang bisa dibuat sementara. Keputusan desain ini, dan kapan memilih yang mana, akan sangat membantu kalian di episode 5 nanti.

#Penutup

Di episode 1 ini kita sudah membuka mata terhadap masalah yang Vault pecahkan: secret sprawl. Kita melihat bagaimana secret bocor lewat hardcoded key, file .env yang ter-commit, kredensial statis yang tak pernah dirotasi, dan spreadsheet/chat yang penuh rahasia. Kita juga melihat empat kemampuan inti Vault — centralized storage, dynamic secrets, encryption-as-a-service, dan fine-grained access control dengan audit logging — serta taksonomi empat tipe secret yang akan menemani kita sepanjang series.

Poin penting yang harus kalian bawa:

• Secret sprawl adalah masalah sistemik — kesalahan manusia akan selalu ada, jadi sistemlah yang harus aman.
• Vault menawarkan empat pilar: terpusat, dinamis, enkripsi sebagai layanan, dan akses ter-audit.
• Kenali empat tipe secret: static (KV), dynamic (DB/Cloud), encryption keys (Transit), dan PKI certs.
• Dynamic secret mengubah paradigma: secret yang bocor menjadi tidak berbahaya karena otomatis hancur.
• Vault melengkapi, bukan mengganti, praktik baik keamanan dasar lainnya.

Sekarang konsep sudah matang. Di episode 2 selanjutnya, kita akan melebarkan pandangan ke ekosistem secret management secara menyeluruh — membandingkan Vault dengan cloud-native secret manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) dan tools open-source lain (SOPS, Passbolt, Vaultwarden, OpenBao) — sehingga kalian bisa berargumen kapan Vault adalah pilihan yang tepat, dan kapan bukan. Pastikan tetap semangat, karena perbandingan ini akan menjadi modal penting saat kalian berdebat di meeting kerja!