Zero-Trust API Security: From Internal Network ke Zero Trust dengan mTLS & OAuth 2.0

Runtuhnya Konsep Perimeter-Based Security

Dulu, arsitektur keamanan jaringan mengadopsi model castle-and-moat: siapa pun yang berada di dalam Virtual Private Network (VPN) internal dianggap terpercaya, sedangkan lalu lintas luar dibatasi firewall ketat. Model ini sudah usang. Sekali hacker berhasil menembus satu mesin di dalam VPN (misal via phishing atau supply-chain malware), mereka dapat bergerak bebas ke semua microservice secara lateral.

Prinsip Zero Trust berpegang pada semboyan: “Never Trust, Always Verify”. Setiap panggilan API—bahkan antar pod Kubernetes di server yang sama—harus diautentikasi dan dienkripsi.

1. Implementasi Mutual TLS (mTLS) Antar-Layanan

Pada mTLS, tidak hanya klien yang memverifikasi sertifikat server, tetapi server juga memvalidasi identitas klien melalui sertifikat digital X.509:

# Verifikasi handshake mTLS via OpenSSL
openssl s_client -connect billing-service.internal:8443 \
  -cert /etc/certs/client.crt \
  -key /etc/certs/client.key \
  -CAfile /etc/certs/internal-ca.crt

2. Token Exchange & Fine-Grained Authorization (OAuth 2.0 + SPIFFE)

Selain sertifikat mesin, kita membutuhkan token sesi berbasis pengguna (OAuth 2.0 Proof of Possession atau DPoP) untuk memastikan bahwa permintaan API benar-benar dipicu oleh aksi user yang valid, bukan sekadar bot internal nakal.

• SPIFFE / SPIRE: Standar identitas kriptografis untuk workload tanpa rahasia statis yang hardcoded.
• Micro-segmentation: Kebijakan jaringan (NetworkPolicy) yang membatasi Service A hanya boleh menghubungi Port tertentu pada Service B.

Kesimpulan

Zero Trust bukan sekadar produk yang dibeli dari vendor, melainkan pola pikir arsitektur menyeluruh yang memastikan setiap titik komunikasi memiliki perlindungan berlapis.