Belajar Cloud Security Engineer - Cloud Network Advanced (Zero Trust)

#Pendahuluan

Setelah di episode 4 kita membangun network security klasik — segmentasi VPC, SG granular, egress control — pertanyaan alami berikutnya: apakah perimeter jaringan masih relevan ketika workforce hybrid, aplikasi tersebar multi-cloud, dan laptop developer bisa dari mana saja? Jawaban industri 2026: perimeter jaringan diganti (bukan ditambah) dengan verifikasi per-request berbasis identitas — zero trust.

Mengapa topik ini penting? Karena VPN corporate adalah artefak era "jaringan internal = tepercaya". Begitu kredensial VPN dicuri (dan sering terjadi), penyerang berdiri di dalam dan bisa menjelajah lateral. Zero trust memutus asumsi itu: tidak ada yang tepercaya karena berada di jaringan tertentu — setiap request diverifikasi identitas, device, dan konteksnya.

#Prinsip Zero Trust

NIST SP 800-207 merangkumnya menjadi tiga ide inti:

1. Never trust, always verify — autentikasi + otorisasi per-request, bukan sekali di gerbang.
2. Akses minimal & sementara — per-aplikasi, bukan per-jaringan; sesi pendek, bukan tunnel permanen.
3. Asumsi breach — desain seolah penyerang sudah di dalam: blast radius kecil, microsegmentasi, observabilitas penuh.

Yang sering disalahpahami: zero trust bukan produk yang dibeli — ia arsitektur dan kebijakan. Vendor akan menjual "zero trust box"; realitasnya komponen teknisnya adalah identity-aware proxy, kebijakan kontekstual, dan segmentasi.

#ZTNA vs VPN

ZTNA (Zero Trust Network Access) adalah implementasi paling populer dari prinsip ini untuk akses user-to-app:

Arsitekturnya memakai broker/proxy yang menyembunyikan aplikasi dari internet sepenuhnya:

Implementasi di cloud native: AWS Verified Access, Cloudflare Access/Tailscale untuk lintas-environment, atau App Mesh/Istio authorization untuk traffic service-to-service.

#Microsegmentasi Antar-Workload

Zero trust juga berlaku service-to-service. Fondasinya sudah kalian bangun: network policy K8s (episode 12), SG referensi (episode 4). Level lanjutannya: identity-based authorization di layer aplikasi — mTLS dengan SPIFFE/SPIRE sehingga keputusan akses berbasis identitas workload, bukan IP:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-orders-only
  namespace: payments
spec:
  selector: {matchLabels: {app: payments}}
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/orders/sa/orders-api"]
      to:
        - operation: {methods: ["POST"], paths: ["/v1/charge"]}

Dengan policy ini, meskipun penyerang mendapat foothold di namespace lain, panggilan ke /v1/charge ditolak — kebijakan berlaku walau jaringan fisiknya terhubung. Itu esensi microsegmentasi zero trust: lokasi tidak memberi izin, identitas yang memberi.

#SSE dan SASE: Zero Trust untuk Trafik Internet

Dua akronim yang muncul di RFP 2026 dan wajib kalian pahami bedanya:

• SSE (Security Service Edge): pengamanan trafik internet & SaaS via cloud — SWG (web gateway), CASB (visibilitas SaaS), ZTNA. Intinya: filter egress user tanpa appliance di datacenter.
• SASE: SSE + SD-WAN digabung vendor jaringan. Relevan kalau kalian juga mengelola konektivitas kantor-cabang.

Untuk engineer cloud, nilai praktis SSE adalah menggantikan egress "bebas" dari episode 4 dengan kebijakan per-user/per-app yang terpusat: download massal ke storage pribadi bisa diblokir berdasarkan klasifikasi data, bukan hanya domain.

#Desain Praktis: ZTNA untuk Akses Internal

Mari rancang kasus nyata: 40 engineer butuh akses ke admin panel internal + database staging. Pola legacy-nya: VPN + whitelist IP + password DB yang dibagikan grup chat (kenali gejalanya).

Desain zero trust-nya:

1. Identitas: SSO ke IdP korporat, MFA phishing-resistant (passkey/FIDO2).
2. Broker: Cloudflare Access / AWS Verified Access di depan admin panel; kebijakan: grup eng-admin + device managed (cert/MDM check).
3. Database: akses via broker database (Teleport/HashiCorp Boundary) — kredensial ephemeral per-sesi yang di-issue setelah verifikasi, dicatat siapa mengakses tabel apa.
4. Tanpa jalur alternatif: bastion SSH dihapus; port manajemen ditutup; break-glass via prosedur dua-orang (episode 9).

Hasil: tidak ada satu pun port publik, setiap akses tercatat per-user-per-request, dan offboarding otomatis memotong semua akses dalam menit.

#Common Pitfalls

• "VPN + MFA = zero trust" — MFA di gerbang tidak mengubah blast radius dalam; verifikasi harus per-request.
• Device posture dilewati — identitas curi-memcuri; laptop yang terkompromi tetap lolos jika posture tak dicek.
• Segmentasi hanya di paper — network policy dibuat tapi engine enforcement tidak aktif (episode 12).
• Break-glass dilupakan — saat IdP down, seluruh akses mati; siapkan jalur darurat teruji.

#Penutup

Inti yang harus dibawa pulang:

• Zero trust = verify per-request, akses minimal sementara, asumsi breach — arsitektur, bukan produk.
• ZTNA menggantikan VPN: per-app access, app dark, kontinu verifikasi, blast radius kecil.
• Microsegmentasi level aplikasi (mTLS + authorization policy) membuat izin mengikuti identitas workload.
• SSE mengelola egress user ke internet/SaaS secara kontekstual; SASE menambah SD-WAN.
• Ukur migrasi dengan metrik: aplikasi dark, umur sesi, granularitas kebijakan.

Di episode 17 selanjutnya kita bicara uang: cloud cost & security (FinSec) — berapa biaya security tooling, bagaimana logging bisa membakar budget, budget alarms, dan cara menunjukkan ROI security ke management. Sampai jumpa!