Arsitektur microservices membuat aplikasi terbagi menjadi banyak layanan yang saling berkomunikasi melalui jaringan. Kondisi tersebut meningkatkan fleksibilitas, tetapi juga menambah jumlah komunikasi yang harus diamankan.
Salah satu mekanisme yang banyak digunakan adalah Service Mesh Mutual TLS (mTLS). Teknologi ini mengenkripsi komunikasi sekaligus membantu memastikan bahwa layanan yang berkomunikasi benar-benar memiliki identitas yang dipercaya.
NIST menjelaskan bahwa service mesh dapat digunakan untuk membangun autentikasi mutual antar-service sebagai bagian dari pendekatan keamanan pada aplikasi microservices (dikutip dari: NIST SP 800-204B – Service Mesh Security).
Apa Itu Service Mesh mTLS?
Mutual TLS (mTLS) merupakan pengembangan dari TLS yang melakukan autentikasi pada kedua sisi komunikasi.
Pada TLS biasa, server umumnya memberikan sertifikat untuk membuktikan identitasnya kepada client. Sementara itu, mTLS membuat client dan server saling memverifikasi sertifikat sebelum komunikasi dilanjutkan.
Dalam service mesh, proses tersebut biasanya dikelola oleh proxy yang berjalan di sekitar workload. Dengan demikian, aplikasi tidak harus mengimplementasikan mekanisme TLS secara langsung pada setiap service.
Peran Service Mesh
Service mesh menyediakan lapisan infrastruktur untuk mengelola komunikasi antar-microservices.
Platform seperti Istio dapat mengatur autentikasi, enkripsi, dan kebijakan komunikasi melalui proxy. Dokumentasi Istio menjelaskan bahwa mTLS dapat digunakan untuk mengontrol autentikasi komunikasi antar-service dan dapat diterapkan secara bertahap ketika melakukan migrasi keamanan (dikutip dari: Istio – Authentication and Mutual TLS).
Secara umum, proses komunikasi mTLS dalam service mesh melibatkan beberapa komponen.
Service A mengirim request kepada Service B.
Proxy Service A menangani koneksi keluar.
Proxy melakukan proses TLS dengan proxy Service B.
Kedua proxy memverifikasi sertifikat masing-masing.
Setelah autentikasi berhasil, komunikasi dienkripsi menggunakan TLS.
Request kemudian diteruskan menuju service tujuan.
Dengan pendekatan tersebut, aplikasi dapat berkomunikasi melalui koneksi terenkripsi tanpa harus mengelola seluruh proses sertifikat secara manual.
Sertifikat dan Identitas Workload
mTLS membutuhkan sertifikat untuk membuktikan identitas endpoint. Dalam service mesh, pengelolaan sertifikat dapat dilakukan secara otomatis oleh control plane.
Sertifikat tersebut dapat digunakan untuk mengidentifikasi workload tertentu. Karena itu, identitas tidak hanya bergantung pada alamat IP atau hostname.
Pendekatan ini penting dalam lingkungan cloud-native karena workload dapat berpindah, dibuat ulang, atau memiliki alamat IP yang berubah.
Manfaat Service Mesh mTLS
1. Mengenkripsi Komunikasi
mTLS melindungi data yang dikirim antar-service dari penyadapan jaringan.
Hal ini sangat penting ketika microservices berkomunikasi melalui jaringan internal yang tidak sepenuhnya dapat dipercaya.
2. Mutual Authentication
Tidak hanya server yang membuktikan identitasnya. Client juga harus menunjukkan identitas melalui sertifikat.
Dengan demikian, service dapat membedakan komunikasi dari workload yang dipercaya dan workload yang tidak dikenal.
3. Mengurangi Beban Developer
Tanpa service mesh, setiap aplikasi harus menangani konfigurasi TLS, sertifikat, dan proses autentikasi sendiri.
Service mesh memindahkan sebagian tanggung jawab tersebut ke lapisan infrastruktur. Hasilnya, developer dapat lebih fokus pada logika bisnis aplikasi.
4. Mendukung Zero Trust
mTLS dapat membantu membangun prinsip zero trust karena komunikasi antar-service tidak otomatis dipercaya hanya karena berasal dari jaringan internal.
NIST menempatkan mutual authentication antar-service sebagai salah satu kebutuhan keamanan penting dalam arsitektur microservices berbasis service mesh.
mTLS Tidak Sama dengan Authorization
Meskipun mTLS memberikan autentikasi dan enkripsi, teknologi ini tidak otomatis menentukan apakah sebuah service boleh mengakses service lain.
Sebagai contoh, Service A mungkin memiliki sertifikat yang valid. Namun, belum tentu Service A memiliki izin untuk mengakses database atau API tertentu.
Karena itu, mTLS sebaiknya dikombinasikan dengan authorization policy. Istio juga menekankan bahwa mTLS saja tidak cukup untuk memberikan kontrol akses secara menyeluruh karena autentikasi dan authorization merupakan dua fungsi yang berbeda.
PERMISSIVE vs STRICT Mode
Dalam implementasi service mesh, konfigurasi mTLS perlu diperhatikan dengan baik.
PERMISSIVE Mode
Mode PERMISSIVE memungkinkan workload menerima koneksi plaintext maupun mTLS.
Mode ini berguna ketika organisasi sedang melakukan migrasi secara bertahap. Namun, koneksi plaintext masih dapat digunakan sehingga tingkat perlindungannya lebih rendah.
STRICT Mode
Mode STRICT mewajibkan koneksi menggunakan mTLS.
Istio menyediakan PeerAuthentication untuk menentukan apakah workload menerima plaintext, mTLS, atau hanya mTLS. Pada mode STRICT, koneksi harus menggunakan mTLS dan client harus memberikan sertifikat yang valid.
Karena itu, setelah seluruh workload siap menggunakan mTLS, mode STRICT lebih sesuai untuk meningkatkan keamanan komunikasi internal.
Meskipun memberikan banyak manfaat, mTLS juga memiliki beberapa tantangan.
Manajemen Sertifikat
Sertifikat memiliki masa berlaku dan harus diperbarui secara berkala. Jika proses rotasi tidak berjalan dengan baik, komunikasi antar-service dapat terganggu.
Kompleksitas Infrastruktur
Service mesh menambahkan komponen seperti proxy dan control plane. Karena itu, tim perlu memahami bagaimana traffic, sertifikat, dan policy dikelola.
Dampak Performa
Enkripsi dan proses handshake TLS membutuhkan resource tambahan. Namun, dampaknya perlu dievaluasi berdasarkan skala workload, konfigurasi proxy, serta kemampuan infrastruktur.
Risiko Salah Konfigurasi
Konfigurasi yang terlalu longgar dapat mengurangi manfaat keamanan mTLS. Sebaliknya, konfigurasi yang terlalu ketat tanpa proses migrasi yang baik dapat menyebabkan service gagal berkomunikasi.
Best Practice Service Mesh mTLS
Beberapa praktik yang dapat diterapkan antara lain:
Gunakan mTLS untuk komunikasi antar-workload yang membutuhkan perlindungan.
Migrasikan workload secara bertahap sebelum menerapkan mode STRICT.
Pastikan sertifikat memiliki mekanisme rotasi yang baik.
Gunakan authorization policy setelah autentikasi mTLS.
Pantau koneksi yang masih menggunakan plaintext.
Audit konfigurasi service mesh secara berkala.
Pisahkan identitas workload berdasarkan kebutuhan akses.
Dokumentasikan policy komunikasi antar-service.
Dengan pendekatan tersebut, mTLS tidak hanya menjadi fitur enkripsi. Teknologi ini dapat menjadi bagian dari strategi keamanan microservices yang lebih terstruktur.
Service Mesh Mutual TLS (mTLS) merupakan mekanisme untuk mengamankan komunikasi antar-microservices melalui enkripsi dan mutual authentication.
Teknologi ini membantu memastikan bahwa komunikasi tidak hanya terlindungi dari penyadapan, tetapi juga melibatkan workload yang identitasnya dapat diverifikasi. Selain itu, pengelolaan mTLS melalui service mesh dapat mengurangi kebutuhan developer untuk mengimplementasikan TLS pada setiap aplikasi secara manual.
Namun, mTLS bukan pengganti authorization. Karena itu, penerapannya sebaiknya dikombinasikan dengan authorization policy, identity management, monitoring, dan konfigurasi keamanan yang tepat.
Dengan penerapan yang baik, service mesh mTLS dapat menjadi salah satu lapisan penting dalam membangun komunikasi microservices yang aman dan mendukung prinsip zero trust.
Seorang Akademisi, Peneliti dan Praktisi TI, mengajar di beberapa perguruan tinggi, Authorized Training Center dan Lembaga Pengembangan SDM TI. Aktif berbagi di komunitas melalui event webinar & sharing session. aktifitas sehari-hari di isi dengan mengajar, menulis di blog, jurnal, media massa, buku dan juga membuat video tutorial. bidang ilmu yang didalami adalah cybersecurity, system administrator, programming, networking, linux, cloud computing, blockchain, data science, artificial intelligence. visit me at sulkiflysaid.com
