Belajar Infrastructure Engineer - Secrets & Compliance

#Pendahuluan

Setelah di episode 18 kita mengamankan jaringan, kini dua hal yang membuat keamanan itu bisa dipertanggungjawabkan: secrets management dan compliance. Di episode 8 dan 17 kita menyinggung "simpan rahasia di secret manager" — episode ini membangunnya secara utuh.

Mengapa topik ini penting? Karena rahasia yang tersebar adalah risiko terbesar yang bisa dikendalikan: password di file config, API key di env variable yang di-commit, kredensial service account di script. Dan di dunia yang diatur regulasi, kalian tidak cukup aman — kalian harus bisa membuktikan aman lewat audit trail dan kebijakan yang terdokumentasi.

#Masalah Secrets: Mengapa Kredensial Bocor

Kebocoran kredensial hampir selalu bermula dari kebiasaan: hardcode di kode, commit ke Git, atau disimpan di server sebagai file biasa. Sekali bocor, penyerang bisa masuk diam-diam — dan tanpa audit, tidak ada yang tahu.

.env di repo Git            → semua orang yang clone dapat kredensial
password di config file     → siapa pun yang baca server bisa mengambil
key di command history      → tersimpan di shell history
secret di image container   → terekam permanen di layer image

Semua pola di atas adalah anti-pattern yang harus dihindari sejak hari pertama.

#Vault/OpenBao: Rumah Rahasia

Vault (HashiCorp) dan OpenBao (fork open-source) adalah tool standar penyimpanan secrets: terenkripsi, ter-audit, dan punya mekanisme rotasi.

#Konsep Inti

#Alur Kerja Dasar

export VAULT_ADDR=https://vault.lab.local:8200
vault kv put secret/app/database username=app_user password=$(openssl rand -hex 24)
vault kv get secret/app/database

Aplikasi mengambil rahasia saat dibutuhkan:

Aplikasi → autentikasi ke Vault → baca secret → gunakan → buang
Tidak ada secret di file config. Tidak ada secret di env var statis.

#Dynamic Secrets: Rahasia yang Lahir dan Mati

Kekuatan terbesar Vault adalah dynamic secrets — kredensial dibuat sesuai permintaan, bukan disimpan:

vault read database/creds/app-role

Vault membuat user database baru dengan lease singkat (misal 1 jam) yang otomatis di-revoke saat habis. Tidak ada lagi "password database yang dipakai 5 tahun tanpa diganti".

#OpenBao: Alternatif Open-Source

OpenBao adalah fork komunitas dari Vault (setelah HashiCorp berpindah lisensi), sintaks dan API-nya kompatibel. Pilih OpenBao jika menginginkan lisensi MPL 2.0 penuh; Vault jika menginginkan ekosistem resmi. Konsepnya identik — belajar satu, bisa memakai yang lain.

#Integrasi dengan Infrastructure

#Secrets untuk IaC

Terraform/OpenTofu tidak menyimpan secret di state jika memakai Vault sebagai data source:

data "vault_generic_secret" "db" {
  path = "secret/app/database"
}
 
resource "aws_db_instance" "app" {
  username = data.vault_generic_secret.db.data["username"]
  password = data.vault_generic_secret.db.data["password"]
}

#Secrets untuk Aplikasi

Di Kubernetes, secret bisa disuntikkan dari Vault ke pod tanpa masuk ke manifest Git (pola Vault Agent / External Secrets Operator):

Pola inject secret ke pod

Vault → External Secrets Operator → Kubernetes Secret → mounted ke pod
Secret di Git: placeholder. Secret asli: hanya di Vault.

#Audit Trail: Bukti, Bukan Klaim

Compliance menuntut kalian membuktikan siapa mengakses apa. Audit log adalah tulang punggungnya:

Siapa    : user / service account
Apa      : resource yang diakses
Kapan    : timestamp
Dari mana: IP / host
Hasil    : sukses / gagal

Sumber audit yang wajib diaktifkan:

1. Vault audit log — siapa membaca secret apa.
2. Cloud audit trail (CloudTrail/Stackdriver) — siapa membuat/mengubah resource cloud.
3. Linux auditd — akses file dan eksekusi perintah sensitif.
4. SSH/sudo log — login dan perintah admin.
5. Database audit — query yang menyentuh data sensitif.

sudo apt install auditd
sudo systemctl enable --now auditd
auditctl -w /etc/shadow -p wa -k identity_change
ausearch -k identity_change -ts today

Prinsipnya: jika tidak tercatat, dianggap tidak terjadi. Log audit yang tidak aktif = tidak ada bukti keamanan.

#Kerangka Regulasi yang Memengaruhi Infrastruktur

Compliance bukan "pekerjaan legal" — ia menentukan bentuk infrastruktur:

Pola umum yang dituntut regulasi — dan menjadi checklist infrastruktur:

1. Enkripsi data at-rest & in-transit (semua kerangka)
2. Least privilege + audit access
3. Backup yang teruji (data availability)
4. Incident response & breach notification plan
5. Data residency: data tertentu harus di lokasi tertentu
6. Retention & penghapusan data sesuai ketentuan
7. Dokumentasi & bukti audit yang bisa diproduksi

#Common Pitfalls Secrets & Compliance

• Secret di repo: sekali di-commit, selamanya ada di Git history.
• Audit log mati: "kita punya CloudTrail" tapi tidak pernah dibaca.
• Regulasi dianggap masalah tim legal: padahal mayoritas kontrol jatuh ke infrastruktur.
• Static secret tanpa rotasi: password 5 tahun = hak akses permanen yang tidak pernah dipertanyakan.
• Backup tidak sesuai retention regulasi: data harus disimpan 7 tahun — ternyata hanya 30 hari.
• Tidak bisa membuktikan: aman secara teknis tapi tanpa bukti = gagal audit.

#Penutup

Pada episode 19 ini kalian telah mengelola rahasia dan kepatuhan:

• Vault/OpenBao menyimpan secret terenkripsi; dynamic secrets dengan lease membuat kredensial lahir-mati otomatis.
• Integrasi: Terraform data source dan External Secrets Operator untuk K8s — secret tidak pernah di Git.
• Audit trail (Vault, cloud trail, auditd) adalah bukti yang dituntut compliance.
• Kerangka regulasi (ISO 27001, SOC 2, GDPR, UU PDP, PCI-DSS) menentukan bentuk infrastruktur: enkripsi default, data residency, retention.
• Kontrol yang sudah jadi kebiasaan mengubah audit dari drama menjadi formalitas.

Di episode 20 selanjutnya kita menyiapkan respons saat yang buruk terjadi: incident response infra — runbooks, deteksi, dan blameless post-mortem. Sampai jumpa di episode 20!