Belajar Vault - Audit Logging, Security Hardening & Compliance

#Pendahuluan

Setelah di episode 21 sebelumnya kita mengotomasi unseal dengan Cloud KMS sehingga Vault bangun sendiri setelah reboot — pada episode kali ini kita menaikkan standar keamanan Vault ke level yang dituntut di lingkungan produksi dan kepatuhan: Audit Logging, Security Hardening & Compliance.

Bayangkan ini: suatu hari ada insiden keamanan. Sebuah secret production bocor dan pihak manajemen bertanya, "siapa yang membaca secret ini terakhir kali? kapan? dari alamat IP mana? dengan token apa?" Jika Vault kalian tidak memiliki audit log yang teraktifkan, jawaban kalian adalah: "kami tidak tahu." Dan dalam konteks kepatuhan — PCI-DSS, SOC 2, HIPAA, ISO 27001 — kata "tidak tahu" adalah kegagalan yang bisa membuat kalian tidak lolos audit, terkena denda, atau kehilangan sertifikasi.

Di sisi lain, Vault adalah sistem yang menyimpan semua rahasia perusahaan — ia adalah salah satu target paling menarik bagi penyerang dan juga salah satu sistem yang paling tidak toleran terhadap kesalahan konfigurasi. Mematikan swap tanpa mlock, membiarkan endpoint API tanpa TLS, atau lupa mengatur ulang Root Token adalah kesalahan-kesalahan klasik yang sering berujung pada bencana. Episode ini akan membekali kalian dengan tiga lapis pertahanan: record everything (audit), harden the host & API (hardening), dan be ready for the worst (backup & DR).

#Pembahasan Utama

#Vault Audit Devices: Merekam Setiap Request dan Response

Vault memiliki fitur yang sangat kuat dan sederhana: audit devices. Ketika diaktifkan, setiap request HTTP yang masuk ke API Vault — beserta response-nya — direkam ke dalam log terstruktur. Ini termasuk: operasi login, pembacaan secret, pembuatan token, penerbitan sertifikat, semuanya tanpa terkecuali.

Tiga jenis audit device yang paling umum:

Mengaktifkan audit device file sangat mudah:

vault audit enable file file_path=/var/log/vault/audit.log

Vault mendukung beberapa audit device sekaligus (misalnya satu file lokal + satu syslog untuk ship ke SIEM). Setiap request yang masuk akan menghasilkan entri log seperti ini:

{
  "time": "2026-08-02T09:30:15.123456789Z",
  "type": "request",
  "auth": {
    "client_token": "hmac-sha256:REDACTED",
    "entity_id": "8a9f...",
    "token_type": "service",
    "policies": ["default", "app-backend"]
  },
  "request": {
    "id": "f2c1...",
    "path": "secret/data/production/database",
    "operation": "read",
    "remote_address": "10.0.4.21:51234",
    "data": {}
  },
  "response": {
    "data": {
      "data": {
        "username": "hmac-sha256:REDACTED",
        "password": "hmac-sha256:REDACTED"
      }
    }
  }
}

Perhatikan beberapa detail penting dari contoh di atas:

• Token dan data sensitif di-hash menggunakan HMAC-SHA256. Vault menampilkan digest, bukan nilai aslinya — sehingga audit log tidak menjadi "kebocoran secret kedua". Kunci HMAC-nya disimpan terpisah dan bisa dirotasi.
• Namun metadata seperti path, operation, remote_address, policies, dan entity_id tetap plaintext — inilah yang menjadi bahan investigasi dan analisis keamanan.
• Setiap baris adalah satu request dan satu response (ada dua entri per operasi: request dan response).

Untuk memeriksa audit device yang aktif:

vault audit list

Path     Type    Description
----     ----    -----------
file/    file    n/a

Dua hal operasional yang sering terlupakan soal audit log:

• HMAC key dan rotasinya — nilai sensitif di-hash dengan kunci HMAC yang dimiliki Vault. Kunci ini bisa dirotasi (vault audit disable file/ lalu enable ulang, atau memanfaatkan opsi yang tersedia), sehingga jika kunci HMAC diduga bocor, kalian bisa mengubahnya tanpa harus menghapus seluruh riwayat log.
• Rotasi file dan retensi — audit log yang tak pernah di-rotate akan tumbuh tanpa batas dan akhirnya memenuhi disk. Gunakan logrotate (atau pipeline log) dengan kebijakan retensi sesuai regulasi, misalnya 12 bulan sesuai kepatuhan yang berlaku:

/etc/logrotate.d/vault

/var/log/vault/audit.log {
    daily
    rotate 365
    compress
    delaycompress
    missingok
    notifempty
    create 0640 vault vault
    sharedscripts
}

#Hardening Best Practices: Mempersenjatai Host dan API

Audit log yang bagus tidak ada gunanya jika Vault sendiri bisa dikompromikan dengan mudah. Berikut hardening paling penting yang wajib kalian terapkan — ini hasil pengalaman lapangan, bukan sekadar daftar kosmetik.

#1. Matikan Swap dan Aktifkan Memory Locking (mlock)

Kunci enkripsi Vault (root key) hidup di memori. Jika sistem operasi melakukan memory swap (memindahkan halaman memori ke disk), kunci bisa saja tertulis ke disk dalam bentuk plaintext — dan disk lebih mudah dicuri daripada RAM. Vault menyediakan mekanisme mlock untuk mengunci halaman memori agar tidak di-swap.

disable_mlock = false

Nilai false berarti mlock aktif — Vault akan memanggil sistem call mlock() untuk mencegah dirinya di-swap. Namun mlock() memerlukan privilege khusus: Vault harus berjalan sebagai root atau memiliki capability CAP_IPC_LOCK. Di deployment container, kalian perlu menambahkan capability ini:

services:
  vault:
    image: hashicorp/vault:1.18.0
    cap_add:
      - IPC_LOCK
    security_opt:
      - no-new-privileges:true

#2. Strict TLS Enforcement pada API Endpoint

Tidak ada alasan untuk membiarkan traffic secret melewati jaringan tanpa enkripsi. Vault harus diakses melalui HTTPS, dan sebaiknya dengan sertifikat dari CA internal (ingat PKI dari episode 7!) atau CA publik.

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = false
  tls_cert_file = "/etc/vault.d/tls/vault.crt"
  tls_key_file  = "/etc/vault.d/tls/vault.key"
  tls_min_version = "tls12"
}

Enforce TLS juga di sisi client dengan menetapkan VAULT_CACERT atau VAULT_CAPATH saat menjalankan CLI, sehingga vault memverifikasi sertifikat server — bukan sekadar -tls-skip-verify.

#3. Least Privilege dan Policy Review

Dari episode 9 kita sudah belajar policy. Di fase produksi, prinsip ini diperkuat menjadi praktik berkelanjutan:

• Default deny — semua akses ditolak kecuali yang tertulis di policy. Selalu uji dengan vault token capabilities.
• Tidak ada token root — Root Token harus di-revoke segera setelah setup selesai (vault token revoke). Untuk operasi darurat yang butuh hak root, gunakan vault operator generate-root yang membutuhkan Recovery Keys (episode 21).
• Audit policy secara berkala — policy yang "lupa" dihapus adalah celah keamanan diam-diam. Jadwalkan review policy tiap kuartal.
• Token lifetime pendek — semua token harus punya TTL yang wajar, bukan period tak terbatas.

#Disaster Recovery dan Backup Raft

Vault menyimpan seluruh data di storage Raft. Bagaimana jika cluster kehilangan data karena bencana (data center terbakar, akun cloud dihapus, admin salah konfigurasi)? Jawabannya: Raft snapshot.

Membuat snapshot manual sangat mudah:

vault operator raft snapshot save /backup/vault-backup.snap

Untuk memulihkan:

vault operator raft snapshot restore /backup/vault-backup.snap

Otomatisasi adalah kuncinya. Vault menyediakan Vault Snapshot Agent — sebuah biner terpisah yang berjalan sebagai daemon dan menyimpan snapshot sesuai jadwal:

storage "file" {
  path = "/backup/vault-snapshots"
}
 
snapshot_agent {
  interval = "24h"
  lock     = true
}
 
exit_after = false

Snapshot agent juga mendukung pengiriman langsung ke storage cloud (AWS S3, GCS, Azure Blob) dan melakukan enkripsi di sisi client. Untuk pendekatan sederhana tanpa biner tambahan, kalian bisa memakai cron job yang membungkus perintah save, lalu mengunggah ke bucket terpisah:

# /etc/cron.d/vault-snapshot
0 2 * * *  vault /usr/local/bin/vault snapshot-save-and-upload.sh

#!/usr/bin/env bash
set -euo pipefail
 
export VAULT_ADDR=https://vault.internal:8200
export VAULT_TOKEN="$(vault login -method=approle -token-only role_id=... secret_id=...)"
 
DATE=$(date +%Y%m%d-%H%M%S)
SNAP="/backup/vault-${DATE}.snap"
 
vault operator raft snapshot save "$SNAP"
 
# Bucket terpisah, bukan bucket tempat app lain menyimpan data
aws s3 cp "$SNAP" "s3://acme-vault-backups/${DATE}.snap" \
  --sse aws:kms
 
find /backup -name '*.snap' -mtime +14 -delete

Pentingnya lock: snapshot yang diambil saat terjadi failover bisa tidak konsisten. Vault snapshot agent menangani ini dengan lock; di cron manual, gunakan mekanisme yang setara agar tidak ada dua snapshot berjalan bersamaan.

#Checklist Kepatuhan Vault Server

Berikut checklist yang bisa kalian jadikan alat bantu untuk menilai kesiapan kepatuhan Vault:

#Kesalahan Umum (Common Pitfalls)

#Penutup

Pada episode 22 ini kita telah memperkuat Vault dari tiga sisi: audit logging — merekam setiap request dan response dengan hash token serta metadata lengkap untuk investigasi dan kepatuhan; hardening — mlock dan mematikan swap agar kunci tidak bocor ke disk, TLS wajib di endpoint API, serta least privilege dengan revoke Root Token; dan disaster recovery — otomatisasi Raft snapshot beserta prosedur restore yang harus dilatih. Kita menutupnya dengan checklist kepatuhan yang bisa langsung kalian pakai sebagai alat audit.

Namun perjalanan belum selesai. Semua hal yang kita bangun sejauh ini — cluster, auto-unseal, hardening — masih berada dalam satu namespace tunggal. Bagaimana ketika Vault dipakai bersama oleh banyak tim dengan kebutuhan isolasi penuh: tim backend, tim data, tim keamanan? Dan apa batas fitur antara Vault Open Source dengan Vault Enterprise? Itulah topik menarik di episode 23: Vault Namespaces & Multi-Tenancy (Enterprise vs Open Source). Sampai jumpa di episode berikutnya! 🛡️