Mutual TLS Mengautentikasi Kedua Sisi Koneksi
Koneksi HTTPS konvensional mengautentikasi server dengan certificate, sementara client biasanya membuktikan identitasnya kemudian melalui mekanisme aplikasi seperti session cookie, bearer token, atau password. Mutual TLS, yang umum disingkat mTLS, menambahkan autentikasi client berbasis certificate ke dalam exchange TLS.
Hasilnya adalah transport channel tempat setiap peer dapat memverifikasi certificate chain dan proof of possession atas private key dari sisi lainnya. Hal itu mengubah boundary autentikasi, tetapi tidak menjadikan certificate sebagai authorization policy. Identitas client yang valid tetap dapat ditolak saat mengakses resource tertentu.
Autentikasi client memperluas TLS handshake
Pada TLS dengan autentikasi server, server menyajikan certificate chain dan membuktikan kepemilikan private key terkait sebagai bagian dari handshake. Client memvalidasi identitas server sesuai konfigurasi trust dan aturan yang berlaku untuk koneksi tersebut.
Dengan mTLS, server juga meminta autentikasi client. Client kemudian dapat menyajikan certificate chain dan menghasilkan bukti handshake yang terikat pada private key miliknya. Server memvalidasi bukti tersebut terhadap trust anchor dan policy yang dikonfigurasi untuk identitas client.
Exchange sederhananya:
client server
| |
| -------- negosiasi TLS ---------> |
| <----- server certificate ------- |
| <----- permintaan client cert ----|
| ------ client certificate ------> |
| ------ bukti private key -------> |
| |
| ===== koneksi terlindungi ====== |Pesan handshake yang tepat berbeda menurut versi TLS dan parameter hasil negosiasi. Properti keamanan yang penting di sini adalah penyajian certificate disertai bukti kepemilikan kriptografis, bukan diterima sebagai klaim identitas tanpa autentikasi.
Trust store menentukan issuer yang dapat diterima
Certificate hanya berguna dalam konteks validation policy. Server memerlukan trust anchor untuk client certificate, sebagaimana browser atau client TLS lain memerlukan trust anchor ketika memvalidasi server certificate.
Deployment privat sering mengoperasikan certificate authority khusus untuk identitas workload atau device. Server dapat dikonfigurasi untuk menerima chain yang berakar pada authority tersebut, alih-alih memperlakukan setiap certificate dari Web PKI publik sebagai credential client yang memenuhi syarat.
Pemisahan itu penting. Server certificate dan client certificate dapat berada dalam trust domain berbeda walaupun keduanya memakai X.509. Deployment sebaiknya menetapkan issuer yang diterima secara eksplisit dan tidak memasukkan root yang tidak berkaitan ke trust store autentikasi client.
Constraint certificate juga tetap relevan. Chain validation, validity period, key usage, extended key usage, serta pemeriksaan policy yang spesifik terhadap implementasi dapat memengaruhi penerimaan certificate. Sekadar melakukan parsing certificate dan mengambil subject name tidak setara dengan validasi.
Pemetaan identitas memerlukan aturan yang stabil
Setelah certificate tervalidasi, aplikasi atau gateway biasanya perlu memetakan certificate terautentikasi ke principal internal. Input yang mungkin dipakai antara lain subject alternative name, URI identity, DNS name, atau field lain yang dipilih oleh policy deployment.
Aturan pemetaan perlu presisi. Memperlakukan display field dengan format longgar sebagai identifier account yang unik secara global dapat menimbulkan collision atau identitas ambigu. Certificate profile dan logic pemetaan di sisi aplikasi harus sepakat mengenai field yang membawa principal serta namespace tempat nilai itu berlaku.
Boundary yang umum:
client certificate tervalidasi
|
v
ambil field identitas yang disetujui
|
v
petakan ke principal internal
|
v
authorization policyTahap terakhir sengaja dipisahkan. Authentication menetapkan principal yang menyajikan credential. Authorization menentukan tindakan yang boleh dilakukan principal tersebut.
Private key adalah credential operasional
Certificate merupakan material publik. Credential sensitifnya adalah private key yang kepemilikannya dibuktikan selama autentikasi TLS.
Pada deployment service-to-service, penyimpanan key dapat berada pada file lokal proses, key store milik operating system, hardware-backed module, atau fasilitas signing lain yang didukung TLS stack. Pilihan yang sesuai bergantung pada threat model dan platform, tetapi akses ke private key seharusnya lebih sempit daripada akses ke certificate.
Menyalin satu client key dan certificate ke banyak workload memperlemah granularitas identitas. Jika setiap instance berbagi private key yang sama, server dapat mengautentikasi identitas bersama tersebut tetapi tidak dapat membedakan instance mana yang memilikinya. Kompromi juga berdampak pada seluruh peer yang memakai credential itu sampai material bersama diganti.
Credential per workload atau credential dengan scope lain yang sempit mempertahankan boundary identitas yang lebih kecil, selama sistem issuance dan lifecycle menegakkan scope tersebut.
Rotasi memiliki dua sisi
mTLS menambah pekerjaan lifecycle certificate untuk identitas server maupun client. Certificate kedaluwarsa, key dapat perlu diganti, trust anchor berubah, dan workload dapat dibuat atau dihapus dengan frekuensi tinggi.
Proses rotasi harus memperhitungkan overlap. Mengganti client certificate sebelum server mempercayai issuing chain barunya dapat memutus autentikasi. Menghapus CA lama sebelum seluruh certificate yang bergantung padanya berpindah dapat menghasilkan kegagalan yang sama dari arah sebaliknya.
Rotasi trust anchor karena itu sering memerlukan masa transisi ketika chain lama dan baru dapat divalidasi sesuai policy terkontrol. Rotasi private key memiliki perhatian berbeda: key lama seharusnya berhenti dapat digunakan setelah transisi, bukan bertahan sebagai fallback yang tidak terdokumentasi.
Certificate berumur pendek dapat memperkecil periode penggunaan credential yang telah diterbitkan, tetapi juga membuat issuance dan renewal otomatis yang andal semakin penting. Expiration bukan pengganti respons terhadap kompromi private key yang memerlukan invalidation lebih cepat.
Perilaku revocation harus dirancang secara eksplisit
Ekosistem X.509 menyediakan mekanisme seperti certificate revocation list dan OCSP, tetapi deployment mTLS privat tidak otomatis memperoleh revocation efektif hanya karena certificate memakai X.509. Verifier harus mendukung dan menegakkan mekanisme yang dipilih, sedangkan infrastruktur di sekitarnya harus menjaga informasi revocation tetap tersedia dan mutakhir.
Sebagian sistem lebih mengandalkan client certificate berumur pendek dan reissuance cepat. Pendekatan itu dapat menyederhanakan sebagian lifecycle, tetapi sisa validity window tetap merupakan pilihan policy. Private key yang dicuri bersama certificate yang belum kedaluwarsa dapat tetap berguna sampai verifier menolaknya melalui expiry, revocation, perubahan trust, atau kontrol lain.
Failure mode juga penting. Verifier yang diam-diam melewati status check wajib saat terjadi outage memiliki security posture berbeda dari verifier yang menolak autentikasi ketika status tidak dapat dipastikan.
Terminasi TLS memindahkan boundary identitas
Banyak deployment melakukan terminasi mTLS pada reverse proxy, ingress gateway, atau komponen service mesh, bukan di dalam proses aplikasi. Dalam desain ini, terminator menjalankan validasi certificate dan meneruskan identitas terautentikasi ke backend.
Backend tidak boleh menerima metadata identitas dari network peer sembarang. Jika sebuah HTTP header membawa principal client, proxy tepercaya perlu menimpa atau menghapus versi yang dikirim client, dan backend hanya menerima header tersebut melalui jalur terlindungi dari terminator yang ditetapkan.
Tanpa aturan itu, autentikasi certificate yang kuat di edge dapat dilemahkan oleh hop yang lebih longgar di belakangnya. Trust boundary yang relevan mencakup TLS verifier sekaligus mekanisme yang dipakai untuk meneruskan identitas terverifikasi.
mTLS melengkapi authorization aplikasi
mTLS sesuai untuk lingkungan yang mampu menerbitkan, melindungi, merotasi, dan memvalidasi credential client secara konsisten. Mekanisme ini dapat memberi service, device, atau managed client sebuah identitas pada level transport sebelum data aplikasi diproses.
mTLS tidak memuat seluruh access model. Role, tenant boundary, object permission, request context, dan business rule umumnya tetap menjadi urusan aplikasi. mTLS juga tidak dengan sendirinya memastikan workload terautentikasi bebas dari kompromi; yang dibuktikan adalah kepemilikan private key yang diterima berdasarkan certificate policy yang dikonfigurasi.
Deployment yang kuat menjaga boundary tersebut tetap eksplisit: PKI mengendalikan credential issuance, TLS memverifikasi kepemilikan dan validitas certificate, pemetaan identitas memilih principal, dan authorization menentukan tindakan yang diizinkan. Kekuatan mTLS muncul dari keterhubungan lapisan tersebut tanpa memperlakukan salah satunya sebagai pengganti lapisan lain.