Belajar Software Architect - Zero Trust Software

#Pendahuluan

Setelah di episode 17 kalian menjadikan biaya dimensi desain yang sadar — unit economics, trade-off model komputasi, dan cost model konkret studi kasus — pada episode ini kita kembali ke security dengan kedalaman penuh: zero trust software.

Episode 10 sudah meletakkan fondasinya: never trust, always verify. Kali ini kita turun ke implementasi arsitekturalnya — karena zero trust yang berhenti sebagai slide presentasi tidak mengamankan apa pun. Fokus kita tiga hal: bagaimana sistem memverifikasi identitas (bukan lokasi jaringan), bagaimana service saling membuktikan diri lewat mTLS, dan bagaimana least privilege ditegakkan sampai ke lapisan data.

#Dari Perimeter ke Identitas

Model lama membagi dunia menjadi dalam (dipercaya) dan luar (tidak). Masalahnya terbukti berulang: satu phishing, satu laptop karyawan terinfeksi, atau satu container jebol di DMZ — dan penyerang berjalan bebas di "dalam" yang dipercaya penuh.

Zero trust membalik aksioma:

Konsekuensi desainnya besar bagi architect: setiap komponen — manusia maupun mesin — harus punya identitas yang bisa diverifikasi dan kebijakan otorisasi yang menempel pada identitas itu, bukan pada alamat.

#Service Identity: Paspor Setiap Workload

Fondasi teknis zero trust antar mesin adalah service identity: setiap workload mendapat identitas kriptografis yang diterbitkan infrastruktur, bukan dikonfigurasi manual.

Standar yang berkembang adalah SPIFFE (Secure Production Identity Framework For Everyone): identitas dinyatakan sebagai URI (spiffe://acme/ns/prod/sa/inventory), disertifikasi dalam dokumen bernama SVID, dan didistribusikan otomatis ke workload lewat agent.

Prinsip praktisnya tanpa harus memakai SPIFFE penuh:

1. Diterbitkan otomatis saat workload lahir
2. Berumur pendek & dirotasi otomatis
3. Terikat lifecycle workload (mati = identitas hangus)
4. Bisa diverifikasi oleh peer tanpa lookup manual

Implementasi umum: sertifikat client dari PKI internal (Vault PKI, cert-manager) dengan TTL 24 jam; cloud-native alternatifnya workload identity bawaan provider (IRSA/GKE Workload Identity) yang memetakan service account Kubernetes ke role cloud.

#Mutual TLS: Verifikasi Dua Arah

TLS biasa hanya klien memverifikasi server. mTLS menambahkan arah sebaliknya — server juga memverifikasi klien. Hasilnya dua jaminan sekaligus: kerahasiaan kanal dan autentikasi kedua belah pihak.

Perhatikan urutan adopsi yang realistis untuk monolith modular kita:

1. TLS edge + plaintext internal     ← titik awal banyak tim
2. TLS internal (server verif saja)  → anti sniffing dasar
3. mTLS antar komponen utama         → DB, broker, API
4. mTLS universal via mesh           ← saat microservices luas

Langkah 3 bisa dilakukan hari ini tanpa service mesh: PostgreSQL dan Kafka keduanya mendukung client certificate authentication — DB user ordering_app hanya menerima koneksi dengan sertifikat yang diterbitkan untuk modul ordering. Ini menyatukan dua cerita kita: identitas service menjadi cara login database, sehingga pelanggaran boundary data episode 7 semakin mustahil.

Service mesh (Istio/Linkerd/Cilium mesh) mengotomasi seluruh mTLS — sidecar atau eBPF menerbitkan dan merotasi sertifikat, policy dikelola deklaratif. Harganya kompleksitas operasional; aturan keputusan kita konsisten dengan episode 12: mesh masuk saat jumlah workload membuat manajemen sertifikat manual tak lagi sanggup.

#Least Privilege End-to-End

Least privilege mudah diucapkan, sulit ditegakkan — karena ia harus konsisten di semua lapisan:

#Lapisan Cloud IAM

Role per service, scoped minimal: instance role modul payment hanya boleh baca secret prefix payment/* dan tulis bucket audit tertentu — bukan secrets/* semuanya. Kebocoran satu pod membatasi kerusakan pada scope role-nya.

#Lapisan Database

Penerjemahan langsung dari episode 7-8: user DB per modul dengan hak eksplisit.

CREATE USER ordering_app;
GRANT USAGE ON SCHEMA ordering TO ordering_app;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES
    IN SCHEMA ordering TO ordering_app;
-- TIDAK ADA grant ke schema inventory/payment:
-- pelanggaran boundary gagal di level SQL,
-- bukan hanya di code review

#Lapisan Aplikasi

Otorisasi per operasi dengan konteks (ReBAC episode 10): bukan "user admin boleh", melainkan "CS on-shift boleh refund order milik region-nya maksimal Rp500 ribu". Policy as code (OPA/OpenFGA) membuat aturan ini testable seperti logika bisnis lain.

#Lapisan CI/CD & Infrastruktur

Pipeline deploy memakai identity ephemeral (OIDC federation), bukan long-lived key di secrets store. Siapa boleh deploy ke produksi, dari branch mana, dengan approval siapa — semuanya kebijakan, bukan konvensi.

#Praktik: Peta Adopsi Zero Trust Studi Kasus

Mari susun roadmap realistis untuk modular monolith kita:

kuartal_1:
  - oidc provider terpusat (users + CS + ops)
  - secret via vault, rotasi otomatis
  - DB user per module + schema grants ketat
  - audit trail append-only (STRIDE-R ep10)
kuartal_2:
  - TLS internal semua hop (DB, redis, kafka)
  - workload identity: SA per modul di K8s
  - IAM cloud scoped per service account
kuartal_3:
  - client-cert auth: DB & kafka verifikasi
    identitas modul (mTLS hop kritis)
  - policy-as-code otorisasi (OPA) di jalur uang
  - pipeline deploy via OIDC federation
kuartal_4:
  - review: cakupan mTLS vs biaya mesh
    (ekstraksi shipping/payment ep15 -> evaluasi ulang)
  - chaos security drill: revoke credential acak,
    ukur MTTR deteksi & pemulihan
prinsip_pengukur:
  - "setiap request punya identitas terverifikasi?"
  - "setiap credential berumur pendek & dirotasi?"
  - "setiap izin scoped minimum & ter-audit?"

Perhatikan desain roadmanya: tidak ada langkah "install mesh" di awal — nilai terbesar (identitas, least privilege, rotasi) dicapai dengan komponen yang sudah kita miliki. Mesh hanyalah otomasi yang menyusul saat skala menuntut.

#Kesalahan Umum

• Zero trust sebagai produk yang dibeli — membeli mesh/ztna lalu menganggap selesai; tanpa identity dan least privilege di aplikasi, itu perimeter baru yang lebih mahal.
• Long-lived credentials di mana-mana — static API key tahunan di config; rotasi mustahil, pencurian permanen.
• mTLS lalu lengah di otorisasi — kanal aman membawa request berbahaya sama rata; verifikasi identitas ≠ izin.
• Shared service account — sepuluh modul memakai satu SA agar "praktis"; blast radius kembali selebar sistem.
• Policy tersebar sebagai if statement — aturan otorisasi hidup di puluhan controller; tanpa policy engine terpusat, audit butuh arkeologi kode.
• Break-glass tanpa jejak — akses darurat superuser tanpa logging & expiry adalah pintu belakang yang menunggu hari buruk.

#Penutup

Inti yang harus dibawa pulang:

• Zero trust membalik aksioma: jaringan hostile, identitas kriptografis per workload, verifikasi tiap request.
• Service identity kriteria utamanya otomatis, berumur pendek, terikat lifecycle — SPIFFE/SVID atau workload identity provider.
• mTLS memberi autentikasi dua arah; adopsi bertahap mulai dari hop kritis (DB/Kafka), mesh menyusul saat skala menuntut otomasi.
• Least privilege harus konsisten lima lapis: IAM, database, aplikasi, CI/CD, break-glass — contoh konkret: DB user per modul membuat boundary data episode 7 gagal keras di SQL.
• Studi kasus kini punya roadmap zero trust empat kuartal tanpa mesh day-one, plus metrik blast radius sebagai ukuran kemajuannya.

Di episode 19 selanjutnya kita keluar dari runtime ke rantai pasok: supply chain & compliance — SBOM, signing artefak, SLSA levels, serta cara merancang sistem yang compliant sejak desain, bukan diretrofit saat audit datang. Sampai jumpa!