Belajar DevSecOps Engineer - Audit & Incident Automation

#Pendahuluan

Fase 4 ditutup dengan dua kemampuan yang selalu dibutuhkan terlambat: audit trail dan incident response. Ketika alarm berbunyi — pod aneh muncul, secret diakses jam 3 pagi, image tak dikenal jalan di cluster — pertanyaan pertama tim selalu sama: siapa, apa, kapan, dari mana? Tanpa audit log, jawabannya adalah "tidak tahu". Dan tanpa runbook otomatis, respons tergantung pada siapa yang kebetulan online.

Episode ini membangun keduanya: audit logging yang informatif tapi tidak membakar storage, lalu IR automation dari alert → triage → containment otomatis → postmortem yang mengalir balik ke pipeline (loop episode 17).

#Kubernetes Audit Log

API server K8s mencatat setiap request — siapa, aksi apa, ke resource mana, hasilnya. Yang perlu kalian rancang adalah policy: log semua = puluhan GB/hari; log terlalu sedikit = buta saat investigasi. Policy selektif bertingkat:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # request gagal: metadata saja (ringan)
  - level: Metadata
    verbs: ["create", "update", "patch", "delete"]
  # secrets & configmaps sensitif: JANGAN catat body (mengandung nilai!)
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  # perubahan RBAC & SA: full request (penting untuk forensik)
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  # sisanya: none agar hemat
  - level: None

Tiga poin desain yang disorot:

1. Policy dievaluasi berurutan — rule pertama yang cocok menang.
2. Secrets dicatat Metadata saja — RequestResponse akan menyimpan isi secret di log, mengubah log menjadi sumber bocor.
3. Perubahan RBAC layak full-body karena jarang terjadi tapi krusial forensik ("siapa memberi dirinya cluster-admin?").

Ship log ini ke penyimpanan terpusat (Loki/Elastic/SIEM) dengan retensi sesuai regulasi — log di node saja hilang bersama node-nya. Integrasi SIEM mendalam kita bahas episode 24.

#Query Audit yang Berguna

Nilai audit log baru muncul saat bisa diquery cepat:

-- Siapa exec ke pod production dalam 24 jam terakhir?
verb="create" AND objectRef.resource="pods/exec"
AND objectRef.namespace="prod"
 
-- Secret apa saja yang diakses service account aneh?
user.username="system:serviceaccount:prod:mystery-sa"
AND objectRef.resource="secrets"

Simpan query-query ini sebagai saved search — saat insiden, investigator tinggal menjalankan, bukan menyusun sintaks di tengah tekanan.

#Incident Response Lifecycle

Siklus standar NIST yang disesuaikan platform engineering:

Dua fase yang paling sering gagal di organisasi tanpa automation:

• Containment — butuh 40 menit mencari command yang benar; padahal setiap menit attacker mengeksploitasi.
• Postmortem — temuan bagus tapi tidak menghasilkan perubahan permanen.

Automation menyasar keduanya.

#Runbook as Code

Runbook wiki punya masalah klasik: usang saat dibutuhkan. Solusinya: runbook sebagai script/executable workflow yang di-test seperti kode:

#!/usr/bin/env bash
# Isolasi pod bermasalah: label + network policy default-deny
set -euo pipefail
 
POD="$1"; NS="${2:-prod}"
 
kubectl label pod "$POD" -n "$NS" \
    quarantine=true --overwrite
 
cat <<EOF | kubectl apply -n "$NS" -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: quarantine-$POD
spec:
  podSelector:
    matchLabels:
      quarantine: "true"
  policyTypes: [Ingress, Egress]
EOF
 
echo "[OK] Pod $POD diisolasi dari jaringan."

Script versioned di repo, direview, dan diuji di staging game day. Saat insiden: satu command, bukan sepuluh langkah hafalan.

#Containment Otomatis End-to-End

Untuk alert prioritas CRITICAL, rangkai otomatis:

Prinsip penting automation IR:

1. Otomatis hanya untuk aksi aman-dibalik — isolasi pod bisa dibatalkan cepat; delete namespace jangan pernah otomatis.
2. Selalu ada jejak — tiap aksi otomatis membuat ticket dengan log eksekusi lengkap.
3. Circuit breaker — jika automation salah konteks (false positive), mudah dimatikan per-rule.

#Postmortem yang Mengubah Sistem

Postmortem blameless (budaya, episode 2) dengan output teknis wajib:

• Timeline dari audit log (bukan ingatan).
• Akar masalah sistemik.
• Minimal satu action item berupa gate/policy/rule baru — bukan sekadar "ingatkan tim".
• Link PR implementasinya; postmortem ditutup hanya saat PR merge.

Contoh nyata siklusnya: insiden secret bocor di log → action item: tambahkan rule gitleaks untuk pola token tersebut + masking library di template app → PR merged minggu itu → kelas kesalahan yang sama mustahil terulang.

#Penutup

Inti yang harus dibawa pulang:

• Audit policy bertingkat: metadata untuk secrets (jangan body!), full untuk RBAC, none untuk noise.
• Simpan audit log terpusat dengan saved search siap forensik.
• IR lifecycle: deteksi → triage → containment → eradication → recovery → postmortem.
• Runbook as code + containment otomatis untuk aksi reversible; postmortem harus melahirkan gate baru.

Di episode 21 selanjutnya kita masuk Fase 5 dengan topik paling hangat: AI-Powered DevSecOps — bagaimana LLM dipakai untuk triage ribuan temuan, auto-fix kerentanan lewat PR, dan security copilot di IDE — plus batas-batasnya yang wajib kalian kenali sebelum percaya buta. Sampai jumpa!