Belajar Application Security Engineer - Zero Trust untuk Apps

#Pendahuluan

Setelah di episode 18 kita menempatkan WAF secara jujur dalam strategi, episode ini membahas pendekatan arsitektur yang mengubah asumsi dasar keamanan jaringan: Zero Trust. Model lama berasumsi "dalam firewall = aman" — begitu penyerang masuk ke network internal, ia berjalan bebas. Zero Trust membaliknya: tidak ada trust berbasis lokasi; setiap request harus membuktikan identitas, konteks, dan otorisasinya, apa pun sumbernya.

Untuk AppSec engineer, zero trust bukan produk yang dibeli tapi seperangkat kontrol konkret: identity-aware access, mTLS service-to-service, least privilege per request, dan microsegmentation. Kita bahas satu per satu dengan implementasi praktis.

#Prinsip Inti dan Penerjemahannya

NIST SP 800-207 mendefinisikan konsepnya; inilah penerjemahan langsung ke pekerjaan aplikasi:

Kalimat "API kami internal kok, tidak perlu auth" adalah pelanggaran paling umum dari prinsip ini — episode 6 sudah menandainya sebagai pitfall; sekarang ia punya nama formal.

#Identity-Aware Access untuk Aplikasi Internal

Masalah klasik enterprise: admin dashboard, Grafana, dan tooling internal dilindungi VPN — artinya siapa pun di dalam VPN masuk tanpa verifikasi kedua. Pendekatan zero trust menggantinya dengan Identity-Aware Proxy (IAP): aplikasi internal tidak terekspos sama sekali; akses melewati proxy yang memverifikasi identitas + device + konteks per request:

Implementasi populer:

• Cloud-native: Google IAP, Cloudflare Access, AWS Verified Access.
• Self-hosted: Pomerium, Ory Oathkeeper, oauth2-proxy di depan app.

Aplikasi di belakang proxy menerima header identitas terverifikasi (misal X-Forwarded-User + JWT). Dua aturan penting agar arsitektur ini tidak bocor:

1. Aplikasi hanya boleh menerima trafik dari proxy — network policy/firewall menutup jalur langsung; kalau ada bypass path, semua verifikasi bisa dilewati.
2. Header identitas hanya valid dari trusted proxy — strip header tersebut di edge publik; beberapa framework punya opsi trust proxy yang harus dikonfigurasi benar.

name: admin-dashboard
type: self_hosted
domain: admin.internal.example.com
policies:
  - name: eng-admins
    decision: allow
    include:
      - email_domain: example.com
    require:
      - groups: [engineering-admin]
      - device_posture: managed   # perangkat terkelola saja
session_duration: 8h

#mTLS: Identitas Service-to-Service

User butuh autentikasi; service juga. Di mesh microservices, siapa yang memastikan pod A benar-benar service pembayaran, bukan penyerang yang sudah menguasai pod lain? Jawaban zero trust: mTLS dengan workload identity — sertifikat pendek-hidup diterbitkan otomatis per workload:

• Service mesh (Istio, Linkerd) menyuntikkan sidecar proxy yang menangani mTLS transparan — kode aplikasi tak berubah.
• Alternatif ringan: SPIFFE/SPIRE untuk identitas workload standar, atau mTLS native di level load balancer.

Hasilnya dua properti sekaligus: enkripsi in-transit internal dan identitas terverifikasi antar service — yang kemudian dipakai untuk otorisasi:

from: payment-service (spiffe://cluster/ns/prod/sa/payment)
to:   orders-service /api/v1/refund
method: POST only
semua identitas lain → DENY

Ini microsegmentation versi layer 7: bukan cuma "network A boleh ke port B", tapi "service X dengan identitas tertentu boleh memanggil endpoint Y dengan method Z".

#Authorization Per Request

Zero trust menuntut keputusan otorisasi pada setiap request, berdasar identitas terverifikasi — bukan sesi panjang yang diasumsikan aman selamanya. Pola penerapannya di aplikasi:

1. Token pendek + konteks: access token 5–15 menit (episode 5); refresh mengevaluasi ulang risiko (device baru? lokasi anomali?).
2. Centralized policy engine untuk keputusan lintas service: OPA/Rego, Cedar, atau OpenFGA untuk relasi fine-grained ("editor dokumen", bukan sekadar "role editor").
3. Step-up authentication untuk aksi sensitif: konfirmasi transfer besar minta MFA ulang meski sesi aktif.

package app.refund
 
default allow = false
 
allow {
    input.action == "refund"
    input.user.id == input.order.userId          # ownership
    time.diff(input.order.createdAt, input.now) < 86400e9  # window 24 jam
}

Keputusan terpusat + teruji seperti unit test — perubahan aturan bisnis terlihat di review, bukan tersebar if ratusan handler.

#Microsegmentation Bertahap

Segmentasi jaringan internal adalah zero trust versi infrastruktur. Jalur adopsi realistis:

1. Petakan alur: siapa memanggil siapa (service graph dari mesh/CDP/netflow). Tanpa peta, policy hanya tebakan.
2. Deny-by-default untuk namespace/app tier baru: mulai dari service baru, jangan big-bang cluster lama.
3. Monitor mode dulu (episode 15): log pelanggaran policy tanpa blokir, tuning dua minggu, baru enforce.
4. Ketatkan bertahap ke tier sensitif: database dan payment dulu — mereka tujuan akhir setiap lateral movement.

#Common Pitfalls

• Beli produk = zero trust selesai: konsol vendor menyala tapi aplikasi internal masih "trust all di VPN"; nilai nyata ada di kontrol per-request, bukan label.
• Lupa device posture: identitas user valid di laptop terinfeksi tetap risiko; konteks perangkat bagian dari verify-explicitly.
• mTLS tanpa authorization: enkripsi antar service tapi semua service boleh memanggil semua endpoint — itu VPN mini, bukan zero trust.
• Break-glass tanpa audit: jalur darurat melewati proxy wajib ada, tapi harus ber-alarm dan ber-review otomatis; pintu belakang yang sunyi adalah pintu utama penyerang.

#Penutup

Inti yang harus dibawa pulang:

• Zero trust = hilangkan trust berbasis lokasi: verifikasi identitas+konteks+otorisasi tiap request.
• Aplikasi internal dilindungi identity-aware proxy, dengan jalur bypass ditutup via network policy.
• mTLS + workload identity memberi enkripsi dan autentikasi antar service; policy mesh menerjemahkannya jadi otorisasi layer 7.
• Authorization per request: token pendek, policy engine terpusat, step-up untuk aksi sensitif.
• Microsegmentation adopsi bertahap: petakan → monitor → enforce, mulai dari tier sensitif.

Di episode 20 kita hadapi dunia regulasi: Compliance untuk Aplikasi — GDPR dan privasi by design, PCI-DSS untuk aplikasi yang menyentuh kartu, dan cara menerjemahkan requirement compliance menjadi kontrol teknis konkret di kode dan pipeline tanpa menjadi formalitas dokumen. Sampai jumpa di episode 20!