Belajar Site Reliability Engineer - Security & Compliance Ops

#Pendahuluan

Semua skill yang kalian bangun sejauh ini — observability, incident management, alerting — bekerja untuk satu musuh: kegagalan acak. Tapi ada satu kelas insiden dengan musuh yang sengaja dan adaptif: penyerang yang tahu kalian sedang memperbaikinya, dan menyesuaikan serangan di tengah jalan. Insiden keamanan tidak menunggu error budget; ia menunggu celah.

Security ops adalah perspektif SRE pada domain ini: monitoring yang berkelanjutan, deteksi ancaman yang cepat, dan respons yang terlatih — bukan mode "keamanan adalah masalah tim lain". Episode 19 membahas bagaimana SRE dan keamanan bekerja dalam satu tim, bagaimana audit kepatuhan berjalan terus-menerus, dan bagaimana merespons insiden keamanan dengan tenang.

#Security Monitoring: Keamanan yang Terlihat

Prinsip pertama: keamanan tidak bisa dikelola jika tidak terlihat. Security monitoring adalah memperluas observability (episode 5) ke data yang membicarakan ancaman:

• Login & autentikasi: percobaan login gagal, source IP yang aneh, jam yang tidak wajar.
• Akses data: siapa mengakses apa, pattern akses yang tidak biasa, volume unduhan yang melonjak.
• Infrastruktur: perubahan konfigurasi, container image baru, user baru, kunci SSH yang ditambahkan.
• Proses: process yang berjalan dari direktori mencurigakan, koneksi keluar yang tidak dikenali (command & control).

Pertanyaannya bukan "apakah kalian mencatat semuanya", melainkan "apakah kalian bisa melihat penyimpangan dari normal". Baseline perilaku normal harus diketahui lebih dulu — dari situlah anomaly detection (episode 22) bertolak.

#Golden Signals Versi Keamanan

Sama seperti RED/USE untuk performa, security punya sinyal inti: jumlah login gagal, laju akses ilegal (403), perubahan privilege, dan koneksi keluar mencurigakan. Empat metrik ini adalah baris pertama dashboard keamanan.

Login gagal per 15m        -> naik 5x = tanda brute force
403 per 15m                -> naik drastis = probing path
Privilege escalation/hr    -> bukan nol = alarm
Koneksi keluar baru/24h    -> growth = investigasi C2

#Threat Detection: Dari Log ke Respons

Deteksi yang baik adalah pipeline, bukan tabel. Alur klasiknya:

1. Collect — semua sumber (auth log, cloudtrail, audit log aplikasi) menuju satu tempat.
2. Normalize — format yang sama agar bisa dikorelasikan.
3. Detect — aturan (misal "login admin dari IP baru + berhasil = alarm") atau model statistik.
4. Prioritize — dengan volume alarm yang tinggi, prioritas menyelamatkan tim dari fatigue (episode 6).
5. Respond — alert yang actionable masuk ke on-call security.

rules:
  - name: sudo-by-unusual-user
    severity: high
    condition:
      event: command_exec
      and:
        - user: "(?!(root|deploy|alice))"
        - command: "^sudo"
    window: 5m
    action: alert + lock account

#SRE × Security: Kolaborasi yang Sehat

Hubungan SRE dan tim security sering tegang karena dua budaya bertabrakan: SRE menginginkan perubahan cepat, security menginginkan kontrol. Persimpangan sehat ada di dua titik:

• Shared SLO — security memberikan target terukur ("deteksi credential compromise dalam X menit", "patch critical dalam Y hari"), SRE membantu mengoperasionalkannya seperti SLO lain.
• Blameless bersama — postmortem keamanan (episode 7) menyelidiki sistem dan kontrol yang gagal, bukan menyalahkan korban phishing atau engineer yang menjalankan perintah salah.

Jika budaya blameless hanya berlaku untuk insiden non-keamanan, budaya itu belum utuh. Insiden keamanan justru yang paling membutuhkannya — rasa takut dihukum mendorong insiden disembunyikan, dan penyerang menyukai insiden yang disembunyikan.

#Compliance: Audit yang Berjalan, Bukan Festival Tahunan

Kepatuhan (SOC 2, ISO 27001, HIPAA, atau standar industri kalian) sering diperlakukan sebagai acara tahunan yang menyiksa. Compliance-as-code membaliknya: bukti kepatuhan dikumpulkan terus-menerus dari sistem, bukan dikumpulkan panik sebulan sebelum audit.

Praktiknya:

• Control berbasis bukti otomatis: encryption-at-rest, backup, access review — semuanya diverifikasi otomatis dari konfigurasi nyata, bukan dari formulir yang diisi manual.
• IaC sebagai sumber bukti (episode 14): jika semua infrastruktur ada di git, kontrol bisa diperiksa lewat kode — Terraform, policy-as-code (OPA/CAS).
• Audit trail otomatis: siapa mengubah apa, kapan, dan disetujui siapa — tercatat oleh sistem.

bunx --yes cloud-conformity scan --tags env=prod --severity critical

#Praktik: Incident Response Keamanan

Simulasikan insiden keamanan dengan tenang, mengikuti pola incident management episode 7:

1. Skenario: alert "login admin berhasil dari IP asing di luar jam kerja".
2. Triage 5 menit: apakah ini benar serangan atau false positive? (cek riwayat IP, perubahan password baru, multi-factor auth).
3. Containment: matikan sesi, revoke token, blokir IP di WAF (materi episode 20).
4. Eradication: ganti kredensial, audit jejak masuk, periksa akses lain dengan kredensial yang sama.
5. Recovery & postmortem: kembalikan layanan, lalu tulis blameless postmortem — kontrol apa yang gagal sehingga login tanpa MFA bisa terjadi?

# blokir IP penyerang di edge (contoh)
iptables -A INPUT -s 185.220.101.4 -j DROP
 
# revoke semua sesi pengguna yang terdampak
vault lease revoke --prefix auth/user/login

#Penutup

Pada episode 19 ini, kalian telah belajar memperlakukan keamanan sebagai operasi yang dijalankan, bukan tembok yang dipasang.

Inti yang harus dibawa pulang:

• Security monitoring memperluas observability ke perilaku pengguna dan sistem.
• Threat detection adalah pipeline collect → normalize → detect → prioritize → respond.
• SRE dan security bekerja sama lewat shared SLO dan blameless culture.
• Compliance-as-code membuat audit berjalan terus, bukan festival tahunan.
• Incident keamanan direspons dengan latihan yang tenang, bukan improvisasi yang panik.

Di episode 20 selanjutnya, kita akan berdiri di gerbang pertahanan: DDoS & traffic protection — rate limiting, WAF, dan strategi menahan lonjakan trafik tanpa membuat service tumbang. Sampai jumpa di episode 20!