Belajar Vault - Arsitektur Utama & Konsep Keamanan Vault

#Pendahuluan

Di episode 2 sebelumnya, kita sudah memetakan seluruh ekosistem secret management dan menyimpulkan bahwa Vault adalah pilihan tepat ketika kebutuhan sudah kompleks: multi-cloud, dynamic secrets, encryption-as-a-service, PKI, dan audit ketat. Nah, di episode 3 ini kita akan membuka kap mesin dan membedah arsitektur utama serta konsep keamanan Vault — dari storage backend, Vault Core, alur request, hingga proses initialization dan unsealing.

Mengapa episode ini penting? Karena Vault berbeda dari tool lain dalam satu hal fundamental: Vault mengunci dirinya sendiri demi melindungi datanya. Setiap kali server di-restart, Vault menolak melayani request sampai di-"unseal" — dan memahami kenapa hal ini dirancang begitu akan mengubah cara kalian melihat keamanan sistem secara keseluruhan. Di dunia kerja, kegagalan memahami arsitektur ini adalah akar dari hampir semua kesalahan operasional: operator yang kehilangan unseal keys, root token yang dibiarkan di production, atau storage backend yang dikonfigurasi salah.

Di episode ini kita akan membahas: pertama, arsitektur utama — storage backend vs Vault Core (Barrier) dan alur request; kedua, initialization & unsealing dengan Shamir's Secret Sharing, termasuk manual unseal dan pengenalan auto-unseal; ketiga, risiko root token dan praktik terbaik di production. Siapkan Vault CLI kalian, karena episode ini penuh dengan praktik langsung.

#Arsitektur Utama Vault

Sebelum melihat alur request, kita perlu paham dulu dua lapisan utama Vault: storage backend dan Vault Core (Barrier). Keduanya sering disalahpahami sebagai satu hal yang sama — padahal perbedaannya menentukan model keamanan Vault.

#Storage Backend vs Vault Core (Barrier)

Storage backend adalah tempat penyimpanan data mentah Vault. Ia bisa berupa file di disk, konsul, atau Raft integrated storage. Ini bisa dianalogikan sebagai gudang — tempat semua barang (data terenkripsi) disimpan. Yang krusial: storage backend tidak pernah menyimpan data dalam bentuk plaintext. Seluruh data yang ditulis ke storage backend sudah terenkripsi oleh Vault Core.

Vault Core adalah otak Vault — tepatnya bagian yang disebut Barrier. Barrier adalah lapisan enkripsi yang melindungi seluruh data yang masuk dan keluar storage backend. Setiap write dienkripsi dengan kunci enkripsi data, dan setiap read didekripsi sebelum diteruskan ke secrets engine. Barrier ini bisa dianalogikan sebagai satpam gudang yang menggembok setiap barang masuk dan membuka gembok setiap barang keluar — tanpa kunci (master key yang di-unseal), satpam ini menolak beroperasi sama sekali.

┌────────────────────────────────────────────────┐
│                   VAULT CORE                    │
│  Auth Methods → Policies → Secrets Engines     │
│  ─────────────────────────────                 │
│  BARRIER (enkripsi/dekripsi semua data)         │
└──────────────────────┬─────────────────────────┘
                       │ data terenkripsi
┌──────────────────────▼─────────────────────────┐
│              STORAGE BACKEND                    │
│  File / Consul / Raft (data tersandi, bukan     │
│  plaintext)                                     │
└─────────────────────────────────────────────────┘

#Alur Request: Client → Storage

Sekarang mari kita telusuri perjalanan sebuah request — misalnya vault kv get secret/api/database — dari client sampai kembali lagi. Alurnya melibatkan beberapa lapisan keamanan yang bekerja berurutan:

Client
  │  (1) kirim token + request
  ▼
Auth Method          ← (2) "Siapa kamu?" — memvalidasi identitas
  │
  ▼
Policy Check         ← (3) "Kamu boleh apa?" — evaluasi policy HCL
  │
  ▼
Secrets Engine       ← (4) "Data apa yang kamu minta?" — proses & beri data
  │
  ▼
Storage Backend      ← (5) "Simpan/baca data terenkripsi" (lewat Barrier)

Mari kita bedah kelima langkah ini:

1. Client mengirim request lengkap dengan token autentikasi. Semua traffic seharusnya melalui TLS.
2. Auth Method menjawab pertanyaan "siapa kamu?" — token itu milik entity apa, metode apa yang dipakainya (token, userpass, AppRole, Kubernetes, dsb). Di episode 10 kita akan bedah auth methods secara menyeluruh.
3. Policy Check menjawab "kamu boleh apa?" — policy HCL menentukan path mana yang boleh diakses client dan dengan capability apa. Ini adalah firewall sebelum secret dilihat. Episode 9 membahas policies secara tuntas.
4. Secrets Engine adalah modul yang menangani tipe data: KV engine, database engine, transit, PKI, dan lainnya. Ia yang mengerti cara menghasilkan, menyimpan, atau memproses secret sesuai jenisnya.
5. Storage Backend menyimpan hasil akhir — selalu dalam bentuk terenkripsi oleh Barrier.

#Initialization & Unsealing

Sekarang masuk ke bagian yang paling khas dari Vault — dan yang paling sering mengejutkan pemula: Vault lahir dalam keadaan terkunci. Mari kita pahami prosesnya dari awal.

#Initialization: Kelahiran Vault

Saat Vault server pertama kali berjalan (misalnya mode production kita setup di episode 0), ia berada dalam kondisi uninitialized — belum punya kunci, belum punya apa pun. Kita harus meng-initialize Vault untuk membuat "identitas kriptografis" pertamanya:

vault operator init
Unseal Key 1: 4fBvZ0QvK9hHlVY1Aq2mC3xE5rT6uI7oL8pM9nB0cV
Unseal Key 2: dE5rT6uI7oL8pM9nB0cV4fBvZ0QvK9hHlVY1Aq2mC3x
Unseal Key 3: mC3xE5rT6uI7oL8pM9nB0cV4fBvZ0QvK9hHlVY1Aq2mC
Unseal Key 4: pM9nB0cV4fBvZ0QvK9hHlVY1Aq2mC3xE5rT6uI7oL8
Unseal Key 5: t6uI7oL8pM9nB0cV4fBvZ0QvK9hHlVY1Aq2mC3xE5rT
 
Initial Root Token: hvs.Ga4y9JkL2mQ8zXcV1bN5wK3pR7dF6sH8jT0uY4aZ
 
Success! Vault is initialized

Output di atas adalah momen paling menentukan dalam hidup sebuah Vault. Ada dua jenis material rahasia di sini:

1. Unseal Keys (5 keys) — hasil pemecahan master key. Vault TIDAK menyimpan master key-nya. Ia memecah master key menjadi bagian-bagian (shares) dan memberikan setiap bagian kepada orang yang berbeda.
2. Root Token (hvs.Ga4y...) — token dengan akses total ke Vault. Satu-satunya token yang bisa melakukan apa pun, termasuk menonaktifkan secrets engine dan membuat token lain.

#Shamir's Secret Sharing: Kunci yang Dipecah

Di balik output di atas ada algoritma bernama Shamir's Secret Sharing (SSS), ditemukan oleh Adi Shamir pada 1979. Prinsipnya elegan: sebuah rahasia (master key) dipecah menjadi N bagian (shares), dan untuk merekonstruksi rahasia itu dibutuhkan minimum K bagian (threshold).

Master Key
  │  dipecah oleh Shamir's Secret Sharing
  ├──► Share 1 (Unseal Key 1)
  ├──► Share 2 (Unseal Key 2)
  ├──► Share 3 (Unseal Key 3)
  ├──► Share 4 (Unseal Key 4)
  └──► Share 5 (Unseal Key 5)
 
Threshold = 3  →  butuh MINIMAL 3 shares untuk membuka Vault

Mengapa desain ini begitu cerdas?

• Anti single point of failure. Tidak ada satu orang yang memegang akses penuh. Mencuri 1 atau 2 shares tidak ada artinya — secara matematis tidak cukup informasi untuk merekonstruksi master key.
• Anti insider threat. Kalian bisa membagikan 5 shares kepada 5 orang berbeda. Untuk meng-unseal Vault, minimal 3 dari 5 orang harus bekerja sama. Tidak ada satu individu pun yang bisa membuka Vault sendirian.
• Resilience. Jika satu share hilang (orangnya resign, laptop rusak), Vault tetap bisa dibuka selama masih ada K shares.

#Manual Unseal

Setiap kali Vault di-restart, ia kembali ke kondisi sealed: Barrier terkunci, dan semua request ditolak. Tugas operator adalah mengumpulkan K shares secara berurutan untuk merekonstruksi master key. Inilah yang disebut manual unseal:

vault operator unseal
Unseal Key (will be hidden): 4fBvZ0QvK9hHlVY1Aq2mC3xE5rT6uI7oL8pM9nB0cV
Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    1/3
Unseal Nonce       a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d

vault operator unseal
Unseal Key (will be hidden): dE5rT6uI7oL8pM9nB0cV4fBvZ0QvK9hHlVY1Aq2mC3x
Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    2/3
Unseal Nonce       a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d

vault operator unseal
Unseal Key (will be hidden): mC3xE5rT6uI7oL8pM9nB0cV4fBvZ0QvK9hHlVY1Aq2mC
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    5
Threshold       3
Version         1.18.3
Storage Type    file
Cluster Name    vault-cluster-6e4b2c9a
Cluster ID      3f4a5b6c-7d8e-4f90-a1b2
HA Enabled      false

Perhatikan transisinya: Unseal Progress 1/3 → 2/3 → saat share ketiga masuk, Sealed berubah menjadi false dan Vault mulai menerima request. Proses ini harus diulang setiap kali Vault restart — dan inilah mengapa manual unseal menjadi tantangan operasional nyata di production (bayangkan 3 server di data center, reboot listrik, dan seluruh tim harus berkumpul mengetikkan share).

vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          true
Total Shares    5
Threshold       3
Version         1.18.3

vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    5
Threshold       3
Version         1.18.3

#Pengenalan: Auto-Unseal

Tantangan operasional manual unseal melahirkan solusi modern: auto-unseal. Alih-alih manusia mengumpulkan share, Vault mempercayakan pembukaan Barrier-nya ke layanan KMS cloud yang sudah kita kenal dari episode 2 — AWS KMS, GCP Cloud KMS, atau Azure Key Vault.

storage "raft" {
  path = "/vault/data"
}
 
seal "awskms" {
  region     = "ap-southeast-1"
  kms_key_id = "arn:aws:kms:ap-southeast-1:123456789012:key/abc-1234"
}
 
listener "tcp" {
  address = "0.0.0.0:8200"
}

Cara kerjanya: saat Vault boot, ia memanggil KMS cloud untuk mendekripsi master key yang disimpan dalam bentuk terenkripsi. Tidak ada intervensi manusia — server restart, Vault otomatis unseal, request langsung dilayani. Kita akan membahas auto-unseal secara mendalam di episode 21.

#Root Token: Risiko & Praktik Terbaik

Material rahasia kedua dari proses init adalah root token (hvs.Ga4y... di awal). Ia adalah token dengan akses absolut — bisa melakukan apa pun di Vault tanpa hambatan policy apa pun. Mari kita bahas risiko dan praktik terbaiknya.

#Mengapa Root Token Begitu Berbahaya?

• Akses tanpa batas. Root token mengabaikan seluruh policy. Satu token ini bisa membaca semua secret, menghapus semua engine, bahkan mengubah konfigurasi sistem Vault.
• Tidak ada jejak yang membatasinya. Dengan root token, prinsip least privilege runtuh total — siapa pun yang memegangnya setara dengan "admin semesta".
• Sulit di-revoke sebagian. Kalian tidak bisa mencabut akses root token ke satu path tertentu; mencabutnya berarti menghapus token itu sepenuhnya.

# Root token bisa dibuat ulang oleh operator jika masih ada
# unseal keys yang valid — inilah kenapa akses ke unseal keys
# juga sangat sensitif
vault operator generate-root -init
Nonce: a1b2c3d4-...
Started: true

#Praktik Terbaik Root Token

1. Jangan pernah gunakan root token untuk pekerjaan sehari-hari. Bahkan pekerjaan administratif pun sebaiknya memakai token terautentikasi dengan policy yang minimal.
2. Revoke root token di production. Vault mendukung pencabutan root token setelah proses setup selesai. Ia bisa dibuat ulang kapan saja via vault operator generate-root selama unseal keys masih ada — jadi mencabutnya tidak berarti "kehilangan akses selamanya", melainkan "menutup pintu lebar sementara".

export VAULT_TOKEN='hvs.Ga4y9JkL2mQ8zXcV1bN5wK3pR7dF6sH8jT0uY4aZ'
vault token revoke hvs.Ga4y9JkL2mQ8zXcV1bN5wK3pR7dF6sH8jT0uY4aZ
Success! Revoked token (if it existed)

3. Simpan root token di tempat terisolasi (misal password manager enterprise atau HSM), jauh dari pemakaian rutin, dan hanya untuk emergency recovery.
4. Aktifkan audit logging sebelum melakukan operasi root, sehingga setiap aktivitas terekam.

#Kesalahan Umum Seputar Arsitektur & Unseal

Sebagai penutup teknis, ini kesalahan-kesalahan yang paling sering menghantui operator Vault pemula:

#Penutup

Di episode 3 ini kita sudah membedah bagian dalam Vault: perbedaan storage backend (gudang) vs Vault Core / Barrier (satpam penggembok), alur request lima lapis dari client hingga storage, proses initialization yang menghasilkan unseal keys dan root token, mekanisme Shamir's Secret Sharing (N shares, K threshold), manual unseal vs auto-unseal, serta risiko dan praktik terbaik pengelolaan root token.

Poin penting yang harus kalian bawa:

• Storage backend tidak pernah menyimpan plaintext — semua data terenkripsi oleh Barrier.
• Alur request: Auth → Policy → Engine → Storage — tidak ada jalan pintas.
• Shamir's Secret Sharing memecah master key menjadi N shares dengan threshold K — anti single point of failure.
• Manual unseal butuh koordinasi operator; auto-unseal memindahkan itu ke KMS cloud.
• Root token harus di-revoke setelah setup; jangan pernah dipakai untuk kerja sehari-hari.
• Jangan pernah menyimpan unseal keys dan data Vault di tempat yang sama.

Sekarang kalian memahami kenapa Vault aman. Di episode 4 selanjutnya, kita mulai menyentuh bagian paling konkret: KV Secrets Engine — membandingkan KV v1 vs KV v2 dengan versioning, mengaktifkan secrets engine, dan mempraktikkan seluruh operasi vault kv (put, get, list, rollback, destroy, undelete). Inilah episode di mana kita benar-benar mulai "menyimpan rahasia" di Vault. Pastikan Vault dev mode kalian masih berjalan dan tetap semangat, karena dari sini perjalanan teknis yang sesungguhnya dimulai!