Sertifikat Client mTLS Mengautentikasi Peer, Bukan Hak Akses

Mutual TLS menambahkan autentikasi client pada koneksi TLS. Server meminta sertifikat, memvalidasi sertifikat yang disajikan berdasarkan trust policy yang dikonfigurasi, lalu memperoleh informasi sertifikat terautentikasi sebelum data aplikasi diterima melalui koneksi tersebut.

Hasil itu berguna, tetapi cakupannya lebih sempit daripada keputusan otorisasi. Sertifikat client yang valid dapat membuktikan bahwa sebuah peer menguasai private key yang terkait dengan sertifikat yang diterima. Sertifikat tersebut tidak dengan sendirinya menetapkan API method, data tenant, operasi administratif, atau resource service yang boleh digunakan peer itu.

Validasi sertifikat menetapkan peer terautentikasi

Alur mTLS sederhana dapat digambarkan sebagai:

sertifikat client disajikan
        |
        v
certificate path diterima
        |
        v
bukti penguasaan private key diterima
        |
        v
peer terautentikasi

Detail validation policy bergantung pada implementasi. Policy tersebut dapat mencakup certificate path construction, masa berlaku, batasan key usage, pemrosesan revocation jika dikonfigurasi, serta pemeriksaan identitas yang dipilih deployment.

Validasi yang berhasil menjawab pertanyaan autentikasi berdasarkan policy tersebut. Otorisasi memerlukan pemetaan tambahan:

peer terautentikasi
        |
        v
identitas aplikasi
        |
        v
role / atribut / resource policy
        |
        v
izinkan atau tolak

Menyatukan dua tahap itu membuat penerbitan sertifikat setara dengan pemberian privilege aplikasi, sering kali dengan cakupan yang lebih luas dari yang dimaksud.

Issuer tepercaya bukan role aplikasi

Server umumnya menerima sertifikat client yang chain-nya berujung pada satu atau beberapa trust anchor yang dikonfigurasi. Konfigurasi trust tersebut menentukan certificate chain yang dapat memasuki jalur autentikasi. Konfigurasi itu tidak otomatis menyandikan role aplikasi.

Jika satu CA internal menerbitkan sertifikat untuk deployment agent, monitoring service, operator, dan batch job, semua sertifikat dapat valid secara kriptografis di bawah trust anchor yang sama meski tindakan yang diizinkan sangat berbeda.

Aturan seperti “sertifikat valid dari CA ini berarti administrator” dengan demikian mendelegasikan admission administrator kepada setiap jalur penerbitan yang mampu menghasilkan sertifikat yang diterima aturan tersebut. Hal itu dapat disengaja pada PKI dengan cakupan sempit, tetapi harus menjadi policy eksplisit, bukan konsekuensi tak sengaja dari konfigurasi TLS.

Ekstraksi identitas memerlukan kontrak yang stabil

Aplikasi sering membentuk principal dari field atau extension sertifikat. Identifier yang dapat dipakai antara lain URI SAN, DNS SAN, atau identifier khusus deployment lainnya. Field yang dipilih memerlukan format, aturan keunikan, cakupan issuer, dan lifecycle yang jelas.

Subject common name merupakan kontrak implisit yang rapuh jika certificate profile tidak menjamin semantiknya. Dua issuer juga dapat memakai nama tekstual identik untuk principal yang berbeda. Karena itu, kode otorisasi perlu mengikat ekstraksi identitas pada certificate profile dan trust domain yang mendefinisikan identifier tersebut.

Contoh pemetaan konseptual:

accepted issuer set
        +
URI SAN: spiffe://prod.example/service/payments
        |
        v
principal: payments-service
        |
        v
policy: boleh memanggil POST /settlements

URI pada contoh ini hanya format identifier. Keberadaannya tidak memberikan izin yang ditampilkan di bawahnya; hubungan tersebut berasal dari authorization policy.

Rotasi sertifikat perlu mempertahankan semantik principal

Sertifikat client secara rutin diperbarui atau diganti. Jika otorisasi menggunakan fingerprint seluruh sertifikat sebagai key, setiap renewal dapat terlihat sebagai principal baru walaupun identitas service tidak berubah.

Fingerprint allowlist dapat tepat ketika trust memang sengaja diikat ke satu sertifikat tertentu, tetapi desain itu menciptakan dependency pada proses rotasi. Policy berbasis identitas stabil yang dibawa sertifikat tervalidasi dapat memisahkan lifecycle sertifikat dari lifecycle identitas aplikasi.

Pemisahan itu juga memperjelas keputusan revocation. Menghapus satu sertifikat dapat membatalkan satu credential tanpa menghapus definisi principal. Menghapus principal dari authorization policy dapat mencabut akses aplikasi untuk semua credential yang mewakili principal tersebut.

TLS terminator membentuk batas penting

Saat mTLS berakhir langsung di proses aplikasi, informasi sertifikat dapat diperoleh dari koneksi TLS yang terautentikasi. Pada deployment dengan reverse proxy atau load balancer, TLS dapat berakhir sebelum traffic mencapai aplikasi.

Backend tidak boleh menerima header buatan client secara sembarang sebagai bukti identitas sertifikat. Jika proxy tepercaya meneruskan identitas yang berasal dari sertifikat, hop antara proxy dan backend memerlukan mekanisme yang mencegah client tak tepercaya memalsukan atau melewati metadata tersebut. Desain yang umum antara lain mengisolasi jalur jaringan backend, menimpa identity header di proxy, atau mengautentikasi koneksi proxy ke backend.

Properti utamanya adalah provenance: otorisasi harus memakai data identitas yang terikat secara kriptografis atau operasional pada jalur terminasi TLS tepercaya, bukan sekadar teks dengan nama header yang dikenal.

Connection reuse tidak boleh mencampur principal

Autentikasi mTLS melekat pada koneksi TLS. Sistem yang melakukan pooling, proxying, atau multiplexing koneksi perlu mempertahankan hubungan antara client terautentikasi dan setiap request aplikasi.

Proxy yang menerima beberapa identitas client lalu meneruskan seluruh request melalui satu koneksi backend bersama tidak dapat mengandalkan identitas TLS peer di backend untuk mewakili client asal. Proxy memerlukan mekanisme propagasi identitas terautentikasi yang terpisah atau harus mempertahankan batas koneksi yang menjaga semantik principal yang dibutuhkan.

Perbedaan ini penting pada service mesh dan gateway berlapis karena identitas transport dapat berubah pada setiap hop. Policy aplikasi harus menetapkan identitas dari hop mana yang menjadi otoritas untuk tindakan yang sedang dievaluasi.

Otorisasi tetap merupakan policy aplikasi

mTLS paling tepat ketika tanggung jawabnya dibatasi dengan jelas. mTLS dapat mengautentikasi peer berdasarkan certificate policy dan TLS policy, melindungi kerahasiaan serta integritas transport, dan menyediakan material identitas kepada lapisan otorisasi tepercaya.

Hak akses tetap merupakan keputusan terpisah. Desain yang kuat mengekstrak principal stabil dari data sertifikat tervalidasi, mempertahankan provenance principal tersebut saat melintasi batas infrastruktur, lalu mengevaluasi policy eksplisit untuk operasi dan resource yang diminta.

Pemisahan autentikasi dan otorisasi mencegah sertifikat valid berubah menjadi capability universal yang tidak disengaja. Pemisahan ini juga memungkinkan rotasi sertifikat, administrasi PKI, dan privilege aplikasi berkembang tanpa diam-diam mendefinisikan ulang satu sama lain.