Konteks: Mengapa Microservice Security Berbeda
Pada arsitektur microservice, satu aplikasi dipecah jadi banyak service kecil yang saling berkomunikasi lewat jaringan (biasanya HTTP/REST atau messaging). Ini mengubah attack surface dibanding monolith:
- Tiap service adalah titik masuk (entry point) tersendiri yang berpotensi diserang.
- Komunikasi antar service (east-west traffic) sama pentingnya untuk diamankan dengan komunikasi klien-ke-sistem (north-south traffic).
- Kompleksitas deployment (multi-cloud, container, orkestrasi) menambah permukaan risiko baru.
Masalah Keamanan Microservice
- Banyak titik masuk — tiap microservice punya API/endpoint sendiri yang bisa jadi target serangan, bukan hanya satu gateway terpusat seperti monolith.
- Kompleksitas komunikasi antar service — data sensitif berpindah lewat jaringan internal antar service, rentan disadap jika tidak dienkripsi.
- Database per service — tiap service idealnya punya database sendiri (database per service pattern), menyulitkan penerapan kebijakan keamanan & akses data yang konsisten di seluruh sistem.
- Multi-cloud / multi-environment — service bisa tersebar di berbagai cloud provider/environment berbeda, menyulitkan konsistensi kebijakan keamanan.
- Data persistence — memastikan integritas & keamanan data yang tersebar di banyak data store independen.
- Serverless considerations — fungsi serverless (FaaS) menambah lapisan abstraksi baru; kontrol keamanan tradisional (mis. firewall berbasis host) sulit diterapkan langsung karena tidak ada server yang dikelola secara eksplisit.
Strategi Keamanan: DSDI
Empat pilar strategi keamanan microservice:
| Strategi | Penjelasan |
|---|---|
| Defense in Depth | Menerapkan banyak lapisan kontrol keamanan (jaringan, aplikasi, data) sehingga jika satu lapisan gagal, lapisan lain tetap melindungi sistem |
| Secure by Design | Keamanan dipikirkan sejak tahap desain, bukan ditambahkan belakangan (security as an afterthought) |
| DevSecOps | Mengintegrasikan praktik keamanan ke dalam seluruh pipeline DevOps (CI/CD) — keamanan jadi tanggung jawab bersama, bukan hanya tim security terpisah |
| Isolation | Mengisolasi tiap service (mis. lewat container/namespace) agar kompromi pada satu service tidak menyebar ke service lain |
Best Practice #1 — Application & API Security
- API Security — tiap endpoint API microservice harus divalidasi input-nya, dibatasi rate limit-nya, dan diamankan dari serangan umum (injection, XSS, dsb).
- Dependency Scanning — memindai library/dependency pihak ketiga yang dipakai tiap service untuk mendeteksi kerentanan (vulnerability) yang sudah diketahui.
- Encrypted Communications — seluruh komunikasi antar service (east-west) maupun ke klien (north-south) harus dienkripsi (mis. TLS/mTLS), tidak hanya di batas luar sistem.
Best Practice #2 — Identity, Access, dan Monitoring
- Identity and Access Management (IAM) — memastikan tiap service dan pengguna diautentikasi & diotorisasi secara tepat sebelum mengakses resource, konsisten lintas seluruh microservice.
- Secrets Management — kredensial, API key, dan sertifikat tidak boleh di-hardcode dalam kode; harus dikelola lewat secrets manager terpusat (mis. Vault) dengan rotasi berkala.
Four Cs of Cloud-Native Security
Model keamanan berlapis untuk sistem cloud-native (termasuk microservice):
graph TD Cloud["Cloud<br/>(infrastruktur dasar: provider, region, network)"] --> Cluster["Cluster<br/>(keamanan konfigurasi cluster orkestrasi, mis. Kubernetes)"] Cluster --> Container["Container<br/>(image scanning, isolasi container, minimal privilege)"] Container --> Code["Code<br/>(keamanan kode aplikasi itu sendiri — input validation, dependency, dsb)"]
- Cloud — keamanan infrastruktur cloud tempat sistem berjalan.
- Cluster — keamanan konfigurasi cluster orkestrasi (kontrol akses, network policy).
- Container — keamanan image container (scanning kerentanan, tidak berjalan sebagai root, dsb).
- Code — keamanan pada level kode aplikasi (validasi input, penanganan secrets, dependency aman).
API Gateway sebagai Titik Kontrol Keamanan
API Gateway berfungsi sebagai titik masuk terpusat yang bisa menegakkan kebijakan keamanan sebelum request diteruskan ke service internal: autentikasi & otorisasi terpusat, rate limiting, request validation, serta logging/monitoring terpusat atas seluruh trafik yang masuk ke sistem microservice.
SAST & DAST
| Metode | Penjelasan |
|---|---|
| SAST (Static Application Security Testing) | Menganalisis source code aplikasi tanpa menjalankannya, untuk menemukan kerentanan sejak fase development (shift-left security) |
| DAST (Dynamic Application Security Testing) | Menguji aplikasi yang sedang berjalan (runtime) dari luar, mensimulasikan serangan nyata untuk menemukan kerentanan yang hanya muncul saat eksekusi |
Keduanya saling melengkapi dalam pipeline DevSecOps — SAST dijalankan lebih awal (saat commit/build), DAST dijalankan setelah deployment ke lingkungan staging/testing.
Rangkuman: Best Practice Keamanan Microservice
- Terapkan Defense in Depth — jangan andalkan satu lapisan proteksi saja.
- Amankan API & validasi seluruh input di tiap service.
- Enkripsi seluruh komunikasi (internal & eksternal).
- Kelola identitas & akses secara terpusat dan konsisten.
- Kelola secrets lewat mekanisme khusus, jangan hardcode.
- Terapkan model Four Cs (Cloud, Cluster, Container, Code) secara berlapis.
- Gunakan API Gateway sebagai titik kontrol kebijakan keamanan terpusat.
- Integrasikan SAST & DAST ke pipeline CI/CD (DevSecOps).
Flashcard
flashcards Mengapa attack surface microservice lebih besar dibanding monolith? :: Karena tiap microservice punya endpoint/API sendiri yang menjadi titik masuk tersendiri, ditambah kompleksitas komunikasi antar service (east-west traffic) yang juga harus diamankan, bukan hanya satu gateway terpusat. Apa singkatan DSDI dan sebutkan artinya :: Defense in Depth (banyak lapisan kontrol keamanan), Secure by Design (keamanan sejak desain), DevSecOps (integrasi security ke pipeline CI/CD), Isolation (mengisolasi service agar kompromi tidak menyebar). Sebutkan 4 lapisan pada model “Four Cs of Cloud-Native Security” :: Cloud (infrastruktur), Cluster (konfigurasi orkestrasi), Container (image & isolasi container), Code (keamanan kode aplikasi). Apa peran API Gateway dalam keamanan microservice? :: Sebagai titik kontrol terpusat untuk autentikasi/otorisasi, rate limiting, request validation, dan logging/monitoring sebelum request diteruskan ke service internal. Apa perbedaan SAST dan DAST? :: SAST menganalisis source code secara statis tanpa menjalankan aplikasi (shift-left, dijalankan saat development); DAST menguji aplikasi yang sedang berjalan (runtime) dengan mensimulasikan serangan nyata. Mengapa “database per service” menambah tantangan keamanan microservice? :: Karena tiap service punya database independen sendiri, menyulitkan penerapan kebijakan keamanan & kontrol akses data yang konsisten di seluruh sistem dibanding satu database terpusat pada monolith. Apa itu Secrets Management dan mengapa penting pada microservice? :: Pengelolaan kredensial/API key/sertifikat lewat mekanisme khusus (bukan hardcode dalam kode) dengan rotasi berkala — penting karena banyaknya service yang masing-masing butuh kredensial berbeda untuk saling berkomunikasi.