Belajar Secret Management - Audit Logging, Security Hardening dan Compliance

#Pendahuluan

Di episode 16 kalian memastikan server OpenBao terbuka otomatis setelah maintenance dengan auto-unseal berbasis AWS KMS, GCP Cloud KMS, dan Azure Key Vault. Episode 17 ini melanjutkan ke arah yang berbeda: bukan bagaimana cluster bangun, melainkan bagaimana cluster berbicara dan meninggalkan jejak. Kita membahas audit logging yang merekam seluruh aktivitas, hardening untuk menutup celah fisik dan jaringan, serta backup raft snapshot untuk kesiapan bencana — tiga hal yang hampir selalu menjadi syarat wajib ketika server OpenBao diaudit oleh tim compliance atau penilai keamanan eksternal.

Bagi kalian yang sudah menjalankan OpenBao di produksi, episode ini adalah momen untuk mengecek kembali: apakah setiap operasi operator tercatat? Apakah kunci enkripsi aman dari swap ke disk? Apa rencana jika seluruh node hilang? Jika jawabannya belum jelas, materi berikut akan menjawabnya.

#Audit Device: Jendela ke Setiap Request dan Response

OpenBao adalah sistem yang menangani data paling sensitif di organisasi kalian. Ketika sesuatu salah — entah token bocor, policy keliru, atau akses mencurigakan — kalian membutuhkan bukti yang akurat. Di sinilah peran audit device: mekanisme bawaan yang merekam setiap request dan response API yang masuk ke server, termasuk siapa yang memanggil, token apa yang dipakai, path mana yang diakses, dan apa hasilnya.

Satu hal yang harus dipahami sejak awal: audit log bukan sekadar log aplikasi biasa. Setiap entry dibentuk dari data mentah request dan response, lalu di-hash dan dienkripsi sebelum ditulis, sehingga isinya tidak bisa dimodifikasi tanpa terdeteksi. Karena itu, perlakuan terhadap file audit log harus seketat perlindungan terhadap secret itu sendiri.

#Mengaktifkan Audit Device File

Cara paling sederhana untuk mulai merekam adalah dengan mengaktifkan audit device tipe file yang menulis log ke path tertentu:

bao audit enable file file_path=/var/log/openbao/audit.log
bao audit list

Perintah bao audit enable file file_path=/var/log/openbao/audit.log mendaftarkan device baru. Setelah itu, setiap request dan response API langsung direkam ke file tersebut. Perhatikan bahwa perintah ini membutuhkan kapabilitas sudo pada path sys/audit, sehingga hanya operator dengan akses penuh yang bisa melakukannya — dan itu memang seharusnya begitu.

File audit log bisa tumbuh sangat cepat pada cluster yang sibuk. Karena itu pertimbangkan rotasi log dengan logrotate, atau arahkan audit ke perangkat yang memang dirancang untuk menampung volume tinggi seperti syslog atau socket yang meneruskan ke SIEM.

#Membaca dan Memahami Isi Audit Log

Sekali audit device aktif, setiap operasi tertulis sebagai entry JSON. Jika kalian membuka file audit, satu request aplikasi yang membaca secret akan terlihat kira-kira seperti berikut:

{
  "type": "response",
  "auth": { "token_type": "service", "policies": ["web-app"] },
  "request": {
    "path": "secret/data/myapp",
    "remote_address": "10.0.4.22"
  },
  "response": { "data": { "data": { "key": "vault:v1:..." } } }
}

Saat membaca audit log, perhatikan tiga hal: siapa pemanggilnya lewat auth, path apa yang diakses lewat request, dan apakah responsnya berisi data atau error. Pola yang mencurigakan — banyak permission denied dari satu address, atau path policy yang diakses di luar jam kerja — adalah sinyal awal yang layak dikejar. Ingat, data sensitif seperti nilai secret tetap muncul di audit log sebagai ciphertext, sehingga analisis bisa dilakukan tanpa membocorkan isi aslinya.

#Hardening: Memory Locking dengan disable_mlock

Konsep keamanan yang sering terlewat: secrets harus tetap di RAM, bukan di-swap ke disk. Proses yang berjalan normal akan dipindahkan sementara ke swap space di disk ketika RAM menipis. Bagi OpenBao, itu berarti data master key, token, dan kunci enkripsi bisa saja mengendap di disk — dan bisa dibaca siapa pun yang mendapatkan akses ke disk tersebut.

Untuk mencegahnya, OpenBao mendukung memory locking lewat mlock pada sistem POSIX. Nilai disable_mlock di konfigurasi mengontrol perilaku ini: true berarti membolehkan swapping, false berarti memaksa OpenBao me-lock memori-nya sehingga tidak pernah di-swap.

Konfigurasi mlock di config.hcl

disable_mlock = false

Dengan disable_mlock = false, OpenBao mengunci halaman memori yang digunakan sehingga kernel tidak bisa memindahkannya ke swap. Perlu dicatat, mlock tidak bisa dijalankan oleh proses tanpa kapasitas IPC_LOCK. Ketika menjalankan OpenBao dengan service manager seperti systemd, pastikan LimitMEMLOCK=infinity ditetapkan — dan jangan jalankan OpenBao sebagai root jika bisa dihindari.

#Strict TLS Enforcement pada API Endpoint

Server yang menerima secret lewat HTTP polos sama saja dengan membagikan semua kunci lewat kabel yang bisa disadap. Karena itu, hardening berikutnya adalah memaksa seluruh komunikasi ke API menggunakan TLS dengan konfigurasi listener:

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = "false"
  tls_cert_file = "/etc/openbao/tls/server.crt"
  tls_key_file  = "/etc/openbao/tls/server.key"
}

Selain memasang sertifikat, strict TLS berarti menolak semua varian yang tidak aman. Rangkuman kontrol hardening dalam episode ini:

Dengan kombinasi ini, seluruh lalu lintas menuju API dipaksa lewat saluran terenkripsi, dan klien yang tidak bisa membuktikan identitasnya akan ditolak sejak awal. Untuk meringankan pekerjaan, sertifikat internal bisa diterbitkan otomatis oleh PKI secrets engine yang sudah kalian pelajari di episode 6.

#Disaster Recovery: Otomatisasi Backup Raft Snapshot

Semua hardening di atas tidak berguna jika kalian kehilangan seluruh node. Raft integrated storage menyimpan data terdistribusi, tetapi snapshot yang diambil berkala tetap menjadi jaring pengaman terakhir — satu-satunya cara memulihkan data jika semua node rusak sekaligus.

bao operator raft snapshot save /backups/backup.snap

Snapshot bisa diambil tanpa menghentikan layanan. Untuk keperluan compliance dan DR, jadwalkan snapshot harian melalui cron atau systemd timer, kirim salinannya ke lokasi terpisah (bucket object storage, atau lokasi off-site), lalu uji pemulihannya secara berkala di lingkungan staging. Snapshot yang tidak pernah diuji restorasi-nya hanyalah ilusi perlindungan.

#Penutup

Pada episode 17 kalian membangun lapisan pengaman ketiga dari cluster OpenBao: audit device yang merekam setiap request dan response API ke file terenkripsi, hardening dengan disable_mlock agar secrets tidak berpindah ke swap, TLS wajib pada endpoint API, serta backup raft snapshot sebagai tulang punggung disaster recovery. Ketiganya adalah jawaban standar ketika tim audit bertanya bagaimana kalian melacak akses, melindungi kunci, dan menjamin pemulihan.

Inti yang harus dibawa pulang:

• Audit device merekam segalanya — hash dan enkripsi membuat log tidak bisa diubah tanpa terdeteksi.
• disable_mlock = false melindungi kunci enkripsi dari terjatuh ke swap disk.
• TLS wajib pada endpoint API, dan pertimbangkan mutual TLS untuk internal.
• Snapshot tanpa uji restore bukan backup — otomatisasi dan uji berkala adalah kuncinya.

Di episode 18 berikutnya, kalian akan memakai seluruh pemahaman ini untuk langkah yang cukup menantang: migrasi dari HashiCorp Vault ke OpenBao di produksi — memindahkan data dan konfigurasi tanpa downtime, dan memvalidasi kompatibilitas sepanjang jalan.