Apakah mTLS berlebihan untuk aplikasi saya?

Tergantung pada skenarionya. Untuk aplikasi web yang dapat dilihat pengguna, OAuth/OIDC biasanya tepat. Untuk API internal dan lalu lintas layanan-ke-layanan di layanan mikro, mTLS menjadi standarnya. Untuk integrasi B2B dengan keamanan tinggi, mTLS sering kali merupakan jawaban yang tepat.

Apa perbedaan antara autentikasi klien mTLS dan TLS?

Hal yang sama, nama yang berbeda. Otentikasi klien TLS adalah fitur protokol; mTLS adalah istilah umum untuk menggunakannya. Mereka mengacu pada mekanisme yang sama.

Apakah browser mendukung mTLS?

Ya — mereka meminta pengguna ketika server meminta sertifikat klien. UXnya buruk; pengguna menganggapnya membingungkan. mTLS di browser berfungsi tetapi jarang untuk aplikasi konsumen. Aplikasi perusahaan dengan sertifikat perangkat yang dikeluarkan karyawan lebih umum menggunakannya.

Seberapa singkat masa pakai sertifikat mTLS?

Untuk identitas beban kerja dalam jerat layanan, jam hingga hari adalah hal yang umum. Rotasi dilakukan secara otomatis; masa pakai yang singkat membatasi dampak kompromi. Untuk identitas B2B jangka panjang, berhari-hari hingga berminggu-minggu. Sertifikat publik yang diterbitkan CA mengikuti siklus yang lebih panjang (saat ini hingga 397 hari).

Bisakah saya mencabut sertifikat mTLS?

Ya, melalui CRL (Daftar Pencabutan Sertifikat) atau OCSP (Protokol Status Sertifikat Online). Sertifikat yang berumur pendek sebagian menghilangkan kebutuhan tersebut — pencabutan tidak terlalu menjadi masalah jika masa berlaku sertifikat sudah habis dalam hitungan jam. Sebagian besar penerapan mTLS modern mengandalkan masa pakai yang singkat dibandingkan pencabutan aktif.

Penjelasan Mutual TLS (mTLS): Ketika Klien Memiliki Sertifikat Juga

HTTPS standar mengautentikasi server ke klien — browser memverifikasi sertifikat server. Mutual TLS menambahkan kebalikannya: klien juga memberikan sertifikat, yang diverifikasi oleh server. Hasilnya adalah identitas yang diautentikasi secara kriptografis untuk kedua sisi koneksi. mTLS semakin menjadi standar untuk otentikasi layanan-ke-layanan dalam arsitektur modern.

Badan artikel selengkapnya disediakan dalam bahasa Inggris di bawah ini.

Mutual TLS (mTLS) memperluas TLS standar dengan mengharuskan klien untuk menunjukkan sertifikat yang diverifikasi oleh server. Jabat tangan selesai dengan kedua belah pihak diautentikasi secara kriptografis satu sama lain. Dibandingkan dengan autentikasi berbasis kata sandi atau token, mTLS menawarkan jaminan identitas yang lebih kuat, rotasi kredensial otomatis melalui siklus hidup sertifikat, dan penghapusan masalah distribusi rahasia bersama.

Perbedaan jabat tangan

Dalam TLS standar, klien memverifikasi sertifikat server terhadap penyimpanan kepercayaan. Server tidak mengautentikasi klien secara kriptografis — server bergantung pada mekanisme lapisan aplikasi (cookie, token pembawa, autentikasi Dasar).

Di mTLS, server menambahkan CertificateRequest selama jabat tangan TLS. Klien harus merespons dengan sertifikatnya sendiri ditambah tanda tangan yang membuktikan kepemilikan kunci pribadi. Server memverifikasi sertifikat klien terhadap penyimpanan kepercayaannya sendiri. Jika verifikasi gagal, koneksi terputus.

Di mana mTLS diterapkan

Microservices. Kerangka kerja mesh layanan seperti Istio, Linkerd, dan Consul Connect menggunakan mTLS untuk autentikasi layanan-ke-layanan. Setiap layanan mikro memiliki sertifikat yang mengidentifikasi identitasnya; mesh memberlakukan siapa yang dapat memanggil siapa.Gateway
API. API internal semakin memerlukan sertifikat klien daripada kunci API. Identitas yang lebih kuat, rotasi otomatis melalui sertifikat yang berumur pendek. Produk
VPN dan Zero Trust. Cloudflare Access, Tailscale, BeyondCorp menggunakan sertifikat perangkat untuk autentikasi.
API pemerintah dan keuangan. Open Banking, sistem yang sesuai dengan FedRAMP, dan API militer sering kali diamanatkan mTLS.
IoT. Sertifikat per perangkat menetapkan identitas untuk manajemen armada. AWS IoT, Azure IoT Hub, Google Cloud IoT semuanya menggunakan mTLS.
WebHooks dan integrasi B2B. Pengiriman webhook dengan keamanan lebih tinggi memverifikasi kedua sisi melalui sertifikat.

Mengapa mTLS melalui kata sandi atau token

Tidak ada rahasia bersama. Masing-masing pihak hanya memiliki kunci pribadinya sendiri. Kompromi pada penyimpanan di satu sisi tidak mengekspos sisi yang lain.
Identitas yang kuat. Sertifikat memverifikasi bahwa pemegangnya mengontrol kunci pribadi yang sesuai, yang diikat oleh CA tepercaya ke identitas terverifikasi.
Rotasi otomatis. Sertifikat berumur pendek (jam hingga hari) membatasi jendela apa pun kompromi.
Tidak ada penggunaan kembali kata sandi. Setiap layanan memiliki sertifikatnya sendiri; tidak ada konsep penggunaan ulang kata sandi di seluruh layanan.
Tidak ada pemutaran ulang. Sertifikat saja tidak berguna tanpa kunci pribadi, yang tidak pernah berpindah.
Otentikasi timbal balik kriptografi yang terpasang di dalamnya. Kedua belah pihak memverifikasi satu sama lain dalam satu perjalanan pulang pergi selama jabat tangan.

Bagaimana sertifikat diterbitkan

Kisah penerapan mTLS berkisar pada penerbitan sertifikat:

PKI internal. Organisasi menjalankan Otoritas Sertifikatnya sendiri. Setiap layanan atau klien mendapat sertifikat yang dikeluarkan oleh CA tersebut. Kepercayaan bersifat internal.
SPIFFE / SPIRE. Kerangka identitas cloud-native. Menerbitkan sertifikat berumur pendek untuk beban kerja yang diidentifikasi oleh pengidentifikasi gaya URI. Jejaring layanan menggunakan pola ini.
HashiCorp Vault. Vault dapat bertindak sebagai CA untuk mTLS internal, mengeluarkan sertifikat berumur pendek sesuai permintaan untuk beban kerja yang diautentikasi.
Step CA / smallstep. Otoritas sertifikat gaya ACME sumber terbuka untuk penggunaan internal. Mengurangi kompleksitas operasional.
CA Publik. Untuk mTLS B2B yang kedua belah pihak memerlukan identitas tepercaya secara global, CA komersial menerbitkan sertifikat mTLS.

Tantangan operasional

mTLS tidak gratis:

Manajemen sertifikat. Setiap klien memerlukan sertifikat, diterbitkan, dirotasi, dicabut bila diperlukan. PKI menjadi infrastruktur penting.
Distribution. Mendapatkan sertifikat ke klien yang tepat dengan aman — bootstrapping adalah masalah yang berulang.
Debugging.Kegagalan mTLS lebih sulit untuk di-debug daripada kegagalan kata sandi. Alat dan kemampuan observasi itu penting. Dukungan perpustakaan
L. Sebagian besar pustaka HTTP modern mendukung mTLS, namun konfigurasinya lebih kompleks daripada autentikasi dasar.
Batasan browser. Dukungan browser untuk mTLS ada (perintah sertifikat klien) tetapi janggal; mTLS dalam konteks web lebih umum terjadi antar-server daripada browser-ke-server.

mTLS dalam jerat layanan

Kasus penggunaan modern yang utama. Mesh layanan seperti Istio:

Setiap layanan mendapatkan identitas beban kerja (ID SPIFFE).
Bidang kontrol mesh mengeluarkan sertifikat berumur pendek (biasanya valid selama beberapa jam).
Proksi sidecar (Utusan) menangani mTLS untuk aplikasi — aplikasi berbicara HTTP biasa ke localhost; sespan membungkusnya dalam mTLS untuk jalan keluar jaringan.
Sespan sisi penerima menghentikan mTLS, memverifikasi identitas sumber, dan meneruskan HTTP biasa ke aplikasi tujuan.
Kebijakan menentukan beban kerja mana yang dapat memanggil yang mana — diterapkan di sespan berdasarkan identitas sertifikat.

Aplikasi mendapatkan autentikasi berbasis identitas yang kuat tanpa perubahan kode apa pun. Mesh menangani semua kompleksitas operasional sertifikat dan kripto.

mTLS vs OAuth/OIDC untuk API

Dua model autentikasi berbeda:

OAuth/OIDC — berbasis pembawa token. Token tersebut berisi klaim identitas. Token dapat dieksfiltrasi dan diputar ulang jika tidak terikat ke klien.
mTLS — berbasis sertifikat. Sertifikat saja tidak ada gunanya tanpa kunci privat. Jaminan identitas yang lebih kuat.

Untuk autentikasi layanan-ke-layanan internal, mTLS semakin disukai. Untuk autentikasi yang dihadapi pengguna, OAuth/OIDC tetap menjadi standar. Pendekatan hibrid (OAuth dengan pengikatan token, token OAuth terikat mTLS) menggabungkan kekuatan.

Untuk pengembang

Menambahkan mTLS ke tumpukan Anda melibatkan:

Menyiapkan CA (Langkah CA adalah opsi sumber terbuka yang paling ramah untuk memulai)
Menerbitkan sertifikat ke klien dan server
Mengonfigurasi server untuk memerlukan sertifikat klien
Mengonfigurasi klien untuk menyajikan sertifikat
Menangani rotasi sertifikat (otomatis melalui setara ACME untuk CA internal)

Hambatan untuk masuk telah menurun secara signifikan selama 5 tahun terakhir. mTLS kini layak secara operasional untuk tim kecil; itu sebelumnya sebagian besar merupakan domain perusahaan dengan infrastruktur keamanan khusus.

Pertanyaan yang sering diajukan

Apakah mTLS berlebihan untuk aplikasi saya?: Tergantung pada skenarionya. Untuk aplikasi web yang dapat dilihat pengguna, OAuth/OIDC biasanya tepat. Untuk API internal dan lalu lintas layanan-ke-layanan di layanan mikro, mTLS menjadi standarnya. Untuk integrasi B2B dengan keamanan tinggi, mTLS sering kali merupakan jawaban yang tepat.
Apa perbedaan antara autentikasi klien mTLS dan TLS?: Hal yang sama, nama yang berbeda. Otentikasi klien TLS adalah fitur protokol; mTLS adalah istilah umum untuk menggunakannya. Mereka mengacu pada mekanisme yang sama.
Apakah browser mendukung mTLS?: Ya — mereka meminta pengguna ketika server meminta sertifikat klien. UXnya buruk; pengguna menganggapnya membingungkan. mTLS di browser berfungsi tetapi jarang untuk aplikasi konsumen. Aplikasi perusahaan dengan sertifikat perangkat yang dikeluarkan karyawan lebih umum menggunakannya.
Seberapa singkat masa pakai sertifikat mTLS?: Untuk identitas beban kerja dalam jerat layanan, jam hingga hari adalah hal yang umum. Rotasi dilakukan secara otomatis; masa pakai yang singkat membatasi dampak kompromi. Untuk identitas B2B jangka panjang, berhari-hari hingga berminggu-minggu. Sertifikat publik yang diterbitkan CA mengikuti siklus yang lebih panjang (saat ini hingga 397 hari).
Bisakah saya mencabut sertifikat mTLS?: Ya, melalui CRL (Daftar Pencabutan Sertifikat) atau OCSP (Protokol Status Sertifikat Online). Sertifikat yang berumur pendek sebagian menghilangkan kebutuhan tersebut — pencabutan tidak terlalu menjadi masalah jika masa berlaku sertifikat sudah habis dalam hitungan jam. Sebagian besar penerapan mTLS modern mengandalkan masa pakai yang singkat dibandingkan pencabutan aktif.