mTLS (Mutual TLS): Cara Kerja Autentikasi Dua Arah dan Kapan Dibutuhkan

HTTPS melindungi data saat melintasi jaringan dan membantu klien memverifikasi identitas server. Namun, pada komunikasi antarlayanan, pertanyaan lain sering muncul: bagaimana server memastikan bahwa klien yang terhubung memang layanan yang dipercaya? Di sinilah mutual TLS (mTLS) berguna. Mekanisme ini menambahkan autentikasi sertifikat dari kedua pihak, bukan hanya dari server.

mTLS banyak digunakan untuk API internal, komunikasi antarlayanan, gateway, lingkungan cloud, dan sistem yang perlu membatasi koneksi berdasarkan identitas mesin atau aplikasi. Meski kuat, mTLS bukan tombol ajaib: penerbitan sertifikat, penyimpanan kunci, aturan otorisasi, dan proses pencabutan tetap harus dirancang dengan baik.

Apa itu mTLS?

TLS biasa umumnya memungkinkan klien memeriksa sertifikat server untuk memastikan koneksi menuju endpoint yang benar. Dalam mTLS, server juga meminta sertifikat klien dan memvalidasinya terhadap otoritas sertifikat (CA) atau daftar identitas yang dipercaya. Dengan demikian, kedua sisi dapat membuktikan identitas kriptografisnya selama proses handshake.

Sertifikat berisi informasi identitas dan kunci publik. Kunci privat yang berpasangan disimpan oleh pemilik sertifikat dan digunakan untuk membuktikan kepemilikan, bukan dikirim ke pihak lain. Sertifikat tidak otomatis memberi hak untuk melakukan semua tindakan: setelah identitas diverifikasi, aplikasi masih perlu menerapkan otorisasi untuk menentukan endpoint atau data yang boleh diakses.

Bagaimana proses mTLS berlangsung?

1. Klien memulai koneksi. Klien dan server menegosiasikan parameter TLS yang didukung.
2. Server menunjukkan identitasnya. Klien memeriksa rantai sertifikat, nama host, masa berlaku, dan aturan validasi lain yang relevan.
3. Server meminta sertifikat klien. Jika autentikasi klien diwajibkan, klien mengirim sertifikat yang sesuai dan membuktikan bahwa ia memiliki kunci privatnya.
4. Kedua pihak memvalidasi. Server memeriksa apakah sertifikat klien berasal dari CA tepercaya, masih valid, dan memenuhi kebijakan identitas. Validasi tambahan dapat membatasi nama atau atribut yang diterima.
5. Koneksi aman digunakan. Jika pemeriksaan berhasil, komunikasi dilanjutkan dengan enkripsi dan integritas TLS. Jika gagal, koneksi seharusnya ditolak.

Detail pesan handshake berbeda menurut versi TLS dan konfigurasi implementasi. Prinsip utamanya tetap sama: sertifikat dan bukti kepemilikan kunci digunakan untuk autentikasi, sementara sesi TLS melindungi data yang dikirim setelah negosiasi selesai.

Kapan mTLS layak digunakan?

• Antarlayanan (service-to-service): sebuah API hanya menerima koneksi dari layanan yang identitasnya telah disetujui.
• API mitra atau B2B: organisasi dapat menerbitkan sertifikat khusus untuk setiap integrasi dan menonaktifkannya ketika kerja sama berakhir.
• Gateway dan backend: gateway dapat membuktikan identitasnya kepada layanan backend, bukan sekadar mengandalkan jaringan privat.
• Perangkat terkelola: perangkat IoT atau agen perangkat lunak dapat memakai sertifikat unik untuk mengidentifikasi dirinya ke layanan pusat.

Untuk situs publik yang melayani pengunjung umum, meminta sertifikat klien kepada setiap pengunjung biasanya menambah hambatan yang tidak diperlukan. mTLS lebih sesuai ketika organisasi mengendalikan klien, proses penerbitan sertifikat, dan siklus hidup identitasnya. Konsep ini melengkapi, bukan menggantikan, prinsip Zero Trust Security.

Contoh pengujian dari terminal

Jika endpoint memang dikonfigurasi untuk mTLS, pengujian menggunakan curl dapat menyertakan sertifikat dan kunci klien. Contoh berikut hanya ilustrasi; nama berkas dan host harus disesuaikan dengan lingkungan sendiri.

curl --verbose \
  --cacert ca-server.pem \
  --cert client.crt \
  --key client.key \
  https://api.internal.example/health

--cacert menunjuk CA yang digunakan untuk memvalidasi sertifikat server, sedangkan --cert dan --key menunjuk sertifikat klien beserta kunci privatnya. Jangan mengirim kunci privat melalui chat, tiket dukungan, repositori kode, atau penyimpanan yang dapat diakses umum. Untuk pengujian produksi, gunakan secret manager atau mekanisme penyimpanan kunci yang disetujui organisasi.

Praktik aman mengelola mTLS

• Gunakan identitas terpisah. Hindari satu sertifikat bersama untuk banyak layanan. Sertifikat unik memudahkan audit, pembatasan, dan pencabutan.
• Batasi masa berlaku. Tetapkan masa berlaku sesuai risiko dan kemampuan otomatisasi. Sertifikat berumur pendek mengurangi jendela penyalahgunaan, tetapi memerlukan proses pembaruan yang andal.
• Lindungi kunci privat. Batasi izin berkas, hindari menaruh kunci di image container atau repositori, dan pertimbangkan HSM atau layanan pengelolaan kunci untuk kebutuhan sensitif.
• Rencanakan rotasi dan pencabutan. Pastikan sertifikat dapat diperbarui sebelum kedaluwarsa dan ada prosedur ketika kunci diduga bocor. Periksa bagaimana proxy dan aplikasi memuat perubahan sertifikat.
• Validasi identitas secara spesifik. Mempercayai CA saja dapat terlalu luas. Batasi Subject Alternative Name atau identitas lain sesuai kemampuan platform, lalu petakan identitas ke izin aplikasi.
• Amati kegagalan koneksi. Catat alasan validasi gagal tanpa menulis kunci atau data rahasia ke log. Uji pembaruan sertifikat, pergantian CA, dan pemulihan sebelum diterapkan luas.

Kesalahan yang sering terjadi

Kesalahan umum meliputi sertifikat kedaluwarsa, rantai CA yang tidak lengkap, nama identitas yang tidak cocok, jam sistem yang keliru, atau klien yang tidak mengirim sertifikat. Proxy yang menghentikan TLS juga perlu dikonfigurasi dengan jelas: aplikasi backend mungkin menerima identitas yang diteruskan oleh proxy, sehingga jalur antara proxy dan backend harus dilindungi serta header identitas tidak boleh dipercaya begitu saja dari koneksi sembarang.

Jangan mengatasi masalah dengan menonaktifkan verifikasi sertifikat secara permanen. Periksa log TLS, rantai sertifikat, nama host, CA tepercaya, dan konfigurasi klien-server. Untuk memahami dasar pemeriksaan sertifikat lebih lanjut, baca panduan HTTPS dan TLS di Nazuaf.

Kesimpulan

mTLS memungkinkan klien dan server memverifikasi identitas satu sama lain melalui sertifikat, sehingga cocok untuk komunikasi layanan dan API yang aksesnya perlu dibatasi. Keamanan akhirnya bergantung pada lebih dari handshake: identitas harus dipetakan ke izin yang tepat, kunci privat dijaga, sertifikat dirotasi, dan kegagalan dipantau. Mulailah pada satu jalur komunikasi yang jelas, uji pembaruan serta pencabutan sertifikat, lalu perluas setelah operasionalnya stabil.

Referensi

Dokumentasi teknis: Envoy Gateway — Backend Mutual TLS dan Envoy — Securing with mutual TLS.