Sertifikat Client mTLS Mengautentikasi Peer, Bukan Policy

Mutual TLS menambahkan autentikasi client ke TLS handshake. Server menyajikan sertifikatnya seperti biasa, dan client juga menyajikan sertifikat ketika server memintanya. Handshake yang berhasil dapat menetapkan bahwa peer yang terhubung memiliki private key yang sesuai dengan certificate chain yang diterima.

Hasil tersebut penting, tetapi cakupannya lebih sempit daripada authorization aplikasi. Sertifikat yang valid tidak dengan sendirinya menetapkan tenant, operasi API, row database, tindakan administratif, atau capability service yang boleh digunakan peer. Keputusan tersebut berada pada layer policy yang memakai identity sertifikat yang telah diautentikasi.

Validasi sertifikat menetapkan identity pada transport

Untuk autentikasi client, server memvalidasi sertifikat berdasarkan trust dan aturan verifikasi yang dikonfigurasi. Pemeriksaan tepatnya bergantung pada TLS stack dan policy deployment, tetapi biasanya mencakup pembentukan chain ke trust anchor yang diterima, verifikasi signature, pemeriksaan masa berlaku, dan constraint sertifikat yang relevan.

Handshake juga membuktikan kepemilikan private key yang terkait dengan sertifikat yang disajikan. Salinan sertifikat publik saja karena itu tidak cukup untuk menyelesaikan autentikasi client berbasis sertifikat.

Boundary sederhananya berbentuk:

client
  |
  | sertifikat + bukti kepemilikan private key
  v
TLS endpoint
  |
  | identity sertifikat terverifikasi
  v
authorization aplikasi

Output layer TLS sebaiknya diperlakukan sebagai material identity yang telah diautentikasi, bukan sebagai keputusan akses yang lengkap.

Trust anchor menentukan issuer yang masuk ke boundary

Server yang menerima sertifikat client memerlukan trust store yang disengaja. Menambahkan CA ke store tersebut dapat memperluas populasi sertifikat yang mampu melewati autentikasi transport, bergantung pada path validation dan constraint sertifikat.

Karena itu, trust store untuk sertifikat client merupakan security boundary. Store tersebut tidak seharusnya otomatis menyalin trust store operating system yang luas dan ditujukan untuk web server publik. Autentikasi service private sering lebih tepat memakai kumpulan issuing authority yang lebih sempit dan khusus untuk environment atau kelas workload terkait.

Trust domain yang terpisah juga dapat mengurangi privilege coupling yang tidak disengaja. Sertifikat yang diterima untuk satu administrative plane tidak perlu menjadi valid untuk setiap internal service hanya karena semuanya memakai TLS.

Pemetaan identity harus memakai field sertifikat yang stabil

Setelah validasi TLS, aplikasi atau gateway masih perlu memetakan sertifikat ke principal. Aturan pemetaan harus eksplisit.

Deployment dapat memakai URI atau nama DNS pada Subject Alternative Name, identifier terstruktur lain yang diterbitkan berdasarkan policy terkontrol, atau workload identity khusus platform yang dibawa dalam sertifikat. Properti pentingnya adalah identifier yang dipilih memiliki arti yang ditentukan dan dikendalikan issuer.

Mengandalkan subject string yang mudah dibaca manusia tanpa contract yang presisi dapat menimbulkan ambiguitas. Beberapa field dapat hadir, format dapat berbeda, dan issuer yang berbeda dapat menerapkan aturan penamaan yang berbeda.

Pemisahan yang berguna adalah:

verified chain
     |
     v
ambil field identity yang disetujui
     |
     v
petakan identity ke principal
     |
     v
evaluasi authorization

Setiap transisi perlu fail closed ketika identity yang diharapkan tidak ada atau malformed.

Authentication dan authorization menjawab pertanyaan berbeda

Autentikasi sertifikat menjawab apakah peer dapat menyajikan credential yang diterima dan membuktikan kepemilikan private key. Authorization menjawab apakah principal hasil pemetaan boleh melakukan tindakan yang diminta pada suatu resource.

Sebagai contoh, dua service dapat memegang sertifikat dari internal CA yang sama:

service-a --> GET /inventory
service-b --> POST /billing/refund

Certificate trust yang sama tidak berarti application privilege yang sama. Layer authorization dapat memetakan setiap identity sertifikat ke role, capability, atau aturan policy yang berbeda.

Pemisahan ini juga membatasi dampak penerbitan sertifikat di masa depan. Sertifikat baru dapat menjadi peer yang terautentikasi tanpa memperoleh permission aplikasi sampai identity-nya ditambahkan ke policy.

Masa berlaku sertifikat tidak sama dengan masa authorization

Sertifikat memiliki validity interval, tetapi akses aplikasi mungkin perlu berakhir lebih awal. Workload dapat dihentikan, role operator dapat berubah, atau credential dapat memerlukan emergency revocation.

Sertifikat berumur pendek mengurangi periode ketika credential lama tetap dapat dipakai setelah penerbitan berhenti, tetapi tidak menghapus kebutuhan lifecycle policy. Delay yang dapat diterima bergantung pada threat model dan kebutuhan operasional sistem.

Deployment dapat menggabungkan certificate expiry dengan mekanisme revocation, rotasi sertifikat yang cepat, atau authorization store yang dapat menolak identity dari sertifikat yang masih valid. Mekanisme yang tersedia bergantung pada implementasi PKI dan TLS, sehingga policy perlu sesuai dengan capability yang benar-benar digunakan.

Terminasi TLS memindahkan authentication boundary

Ketika mTLS berakhir di load balancer, ingress gateway, atau service proxy, proses aplikasi tidak lagi menjalankan client-certificate handshake asli. Aplikasi menerima koneksi baru dari intermediary.

client == mTLS ==> gateway ----> aplikasi

Jika aplikasi memerlukan identity client yang telah diautentikasi, gateway harus membawanya melewati hop kedua melalui mekanisme yang terlindungi. Menyalin detail sertifikat ke HTTP header saja tidak aman ketika caller yang tidak tepercaya dapat mencapai aplikasi secara langsung atau dapat mengirim header yang sama.

Aplikasi harus mempercayai identity metadata hanya dari intermediary yang berwenang, dan network path perlu mencegah bypass ketika arsitektur mengharuskan seluruh traffic melewati intermediary tersebut. Gateway sebaiknya mengganti identity field dari client, bukan mempertahankan nilai inbound arbitrary.

Rotasi memerlukan overlap tanpa memperluas identity

Rotasi sertifikat biasanya menghasilkan periode ketika credential lama dan baru sama-sama valid. Authorization sebaiknya terikat pada principal yang dimaksud, bukan pada satu serial number sertifikat kecuali pinning sertifikat tertentu memang menjadi requirement eksplisit.

Pemetaan identity yang stabil memungkinkan workload menerima sertifikat pengganti tanpa menulis ulang permission. Pada saat yang sama, issuance policy harus mencegah workload lain memperoleh identity yang sama.

Rotasi juga memerlukan disiplin clock. Pemeriksaan masa berlaku sertifikat bergantung pada waktu, dan clock skew yang parah dapat menolak sertifikat yang baru berlaku atau mempertahankan asumsi yang secara operasional diharapkan sudah berakhir.

Observability perlu mempertahankan provenance sertifikat

Security telemetry yang berguna mencatat principal hasil pemetaan bersama context sertifikat yang cukup untuk menyelidiki authentication event. Bergantung pada batasan privasi dan operasional, context itu dapat mencakup issuer, serial number, fingerprint, validity interval, dan titik terminasi TLS.

Log perlu membedakan autentikasi transport dari hasil authorization. Request dapat memiliki sertifikat client yang valid dan tetap ditolak karena principal hasil pemetaan tidak memiliki permission.

Pemisahan ini membuat kegagalan policy terlihat tanpa memperlakukan setiap authorization denial sebagai masalah TLS.

mTLS paling kuat dengan contract yang sempit

Deployment mTLS yang kuat menetapkan issuer yang diterima, field sertifikat yang dipakai sebagai identity, pemetaan identity tersebut ke principal, aturan authorization yang diterapkan pada principal, serta jalur lifecycle untuk rotasi dan revocation.

Transport dapat menyediakan autentikasi peer secara kriptografis. Transport tidak dapat menggantikan application policy. Boundary yang eksplisit menjaga penerbitan sertifikat, verifikasi TLS, dan authorization resource sebagai kontrol terpisah, bukan meleburkannya menjadi satu keputusan trust yang terlalu luas.

Referensi

Cybersecurity MTLS PKI Authorization