Pola Penerapan TLS Mutual (mTLS)

TLS standar hanya mengautentikasi server kepada klien melalui sertifikat. TLS timbal balik (mTLS) memperluasnya: kedua pihak menyajikan dan memverifikasi sertifikat. Klien menyajikan sertifikat klien setelah server memintanya (melalui CertificateRequest dalam jabat tangan TLS). Server memverifikasi sertifikat klien terhadap CA tepercaya. mTLS merupakan dasar jaringan tanpa kepercayaan: alih-alih mengandalkan keamanan perimeter jaringan, layanan saling mengautentikasi secara kriptografis pada setiap koneksi. Mesh layanan seperti Istio, Linkerd, dan Consul Connect menerapkan mTLS secara transparan di antara layanan mikro.

Jabat tangan mTLS memperluas TLS 1.3 sebagai berikut: setelah ServerHello dan sertifikat server/Finished, server mengirim pesan CertificateRequest yang menentukan otoritas sertifikat dan algoritma tanda tangan yang dapat diterima. Klien merespons dengan Certificate (rantai sertifikat klien) dan CertificateVerify (tanda tangan atas transkrip menggunakan kunci privat klien). Server memverifikasi rantai sertifikat klien terhadap penyimpanan CA tepercaya dan memvalidasi tanda tangan CertificateVerify. Jika kedua verifikasi berhasil, koneksi saling terautentikasi. Klien tidak dapat memalsukan CertificateVerify tanpa kunci privat yang sesuai dengan sertifikat tersebut.

Dalam lingkungan mesh layanan, sertifikat klien biasanya diterbitkan oleh CA internal. Istio menggunakan SVID SPIFFE (Kerangka Identitas Produksi Aman untuk Semua Orang): setiap beban kerja memperoleh sertifikat dengan SAN URI SPIFFE (Nama Alternatif Subjek) seperti spiffe://cluster.local/ns/default/sa/payment-service. Sertifikat ini berumur pendek (24 jam) dan diputar secara otomatis oleh bidang kendali mesh (istiod). Dalam mTLS yang berhadapan dengan pengguna (misalnya VPN perusahaan, klien API), sertifikat dapat diterbitkan oleh CA perusahaan dengan masa berlaku lebih panjang dan dikirimkan melalui MDM (Manajemen Perangkat Seluler) untuk perangkat karyawan.

Verifikasi mTLS di sisi server melibatkan beberapa langkah: (1) Validasi rantai — verifikasi bahwa rantai sertifikat klien berujung pada CA akar tepercaya di penyimpanan CA klien milik server. (2) Pemeriksaan masa berlaku — pastikan sertifikat belum kedaluwarsa dan sudah berlaku. (3) Pemeriksaan pencabutan — verifikasi melalui OCSP atau CRL bahwa sertifikat belum dicabut. (4) Pencocokan SAN/CN — ekstrak klaim identitas dari SAN sertifikat (URI SPIFFE, nama DNS, atau alamat surel). (5) Otorisasi — periksa bahwa identitas terautentikasi berwenang mengakses sumber daya yang diminta. Langkah 4 dan 5 memerlukan logika tingkat aplikasi di luar konfigurasi TLS dasar.

Sertifikat berumur pendek menghilangkan kebutuhan akan pencabutan eksplisit: jika sertifikat kedaluwarsa dalam 24 jam, dampak kompromi memiliki jendela waktu terbatas. Rotasi memerlukan: (1) Pra-rotasi — terbitkan sertifikat baru sebelum sertifikat lama kedaluwarsa (lakukan rotasi pada 80% masa berlaku). (2) Pergantian tanpa waktu henti — layanan harus menerima sertifikat lama dan baru selama masa transisi. (3) Muat ulang secara bertahap — tumpukan TLS harus memuat ulang kredensial tanpa memutus koneksi yang sudah ada (nginx: nginx -s reload; Envoy: pembaruan sertifikat xDS dinamis). API Beban Kerja SPIFFE (diimplementasikan oleh SPIRE) mengotomatiskan pengiriman dan rotasi sertifikat melalui API soket domain Unix.

Istio menerapkan mTLS secara transparan melalui proksi pendamping Envoy yang disisipkan ke setiap pod. Bidang kendali (istiod) bertindak sebagai CA menggunakan sertifikat perantara yang ditandatangani oleh CA akar mesh. Setiap pod menerima SVID SPIFFE melalui API SDS (Layanan Penemuan Rahasia). Kebijakan PeerAuthentication mengonfigurasi mode mTLS: STRICT (mTLS diwajibkan), PERMISSIVE (mTLS dan teks biasa sama-sama diterima, untuk migrasi), atau DISABLE. Sumber daya AuthorizationPolicy menentukan layanan mana yang boleh berkomunikasi, berdasarkan identitas SPIFFE dalam sertifikat klien. Hal ini menerapkan model tanpa kepercayaan dalam klaster tanpa perubahan pada kode aplikasi.

Untuk klien API eksternal, mTLS menyediakan autentikasi yang lebih kuat daripada kunci API atau token OAuth. Klien menyimpan kunci privat di penyimpanan aman (HSM, penyimpanan kunci OS, atau kunci perangkat lunak dengan frasa sandi). Sertifikat klien disematkan pada CA yang diharapkan oleh titik akhir API. Setiap permintaan API diautentikasi pada lapisan TLS—tidak diperlukan tajuk Authorization terpisah. API Shield milik Cloudflare, sertifikat klien AWS API Gateway, dan mTLS akun layanan Google Cloud semuanya menerapkan model ini. Kunci API yang dibobol dapat digunakan dari mana saja; kunci privat mTLS yang dibobol juga mengharuskan penyerang mencuri perangkat yang menjalankan klien.

Penerapan mTLS menghadapi beberapa tantangan operasional. (1) Distribusi sertifikat—mengirimkan sertifikat klien secara aman ke semua layanan, terutama di lingkungan dinamis tempat jumlah pod bertambah dan berkurang. (2) Kompromi CA—CA internal merupakan target bernilai tinggi; jika dibobol, semua sertifikat layanan harus dianggap tidak berlaku. CA yang didukung HSM dan CA akar luring mengurangi risiko ini. (3) Penelusuran kesalahan—lalu lintas mTLS terenkripsi tidak dapat dipahami oleh alat penelusuran kesalahan standar; observabilitas mesh layanan (Jaeger, Kiali) diperlukan. (4) Kompatibilitas perantara jaringan—proksi pemeriksaan TLS merusak mTLS kecuali dikonfigurasi secara khusus untuk meneruskan sertifikat klien. (5) Insiden kedaluwarsa sertifikat—kegagalan rotasi dapat menyebabkan seluruh layanan tidak tersedia.

SPIFFE (Kerangka Identitas Produksi Aman untuk Semua Orang) mendefinisikan standar identitas beban kerja menggunakan SVID X.509. SPIRE (Lingkungan Waktu Jalan SPIFFE) adalah implementasi acuannya. SPIRE Server bertindak sebagai otoritas pendaftaran dan CA. SPIRE Agents berjalan di setiap simpul, membuktikan identitas beban kerja menggunakan pengesah simpul (identitas instans AWS, JWT akun layanan Kubernetes, TPM) dan pengesah beban kerja (PID Unix, metadata waktu jalan kontainer). API Workload mengirimkan SVID kepada beban kerja melalui soket domain Unix menggunakan antarmuka gRPC sederhana. SPIRE terintegrasi dengan Envoy, Nginx, dan mesh layanan utama sebagai sumber sertifikat.

Untuk penerapan mTLS dengan keamanan tinggi, kunci privat sebaiknya berada di Modul Keamanan Perangkat Keras (HSM), bukan di penyimpanan kunci perangkat lunak. Pustaka TLS (OpenSSL, BoringSSL) memuat kunci privat melalui antarmuka PKCS#11, yang mengalihkan operasi penandatanganan ke HSM. Kunci privat tidak pernah meninggalkan batas HSM dalam bentuk teks biasa. Pilihan HSM awan mencakup AWS CloudHSM, Azure Dedicated HSM, dan Google Cloud HSM. Untuk mTLS tingkat perangkat (IoT, laptop perusahaan), TPM 2.0 menyediakan fungsi serupa—kunci klien TLS terikat pada TPM dan penandatanganan memerlukan otorisasi TPM, sehingga ekstraksi kunci dari perangkat yang dibobol menjadi sangat sulit.

Pengujian mTLS memerlukan alat yang mendukung penyajian sertifikat klien. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Untuk pengujian mesh layanan, istioctl proxy-config secret pod/name menampilkan sertifikat saat ini dan waktu kedaluwarsanya. Jalankan kubectl exec ke dalam pod, lalu gunakan curl pada titik akhir administratif sidecar (localhost:15000) untuk memeriksa listener aktif dan konfigurasi mTLS-nya. Pengujian rotasi otomatis harus memastikan bahwa koneksi tetap stabil selama peristiwa rotasi sertifikat.

Langkah tambahan apa yang ditambahkan mTLS dibandingkan TLS standar?

mTLS menambahkan autentikasi sertifikat klien ke TLS—kedua pihak memverifikasi sertifikat satu sama lain. SVID SPIFFE menyediakan identitas beban kerja terstandar melalui URI SPIFFE dalam SAN sertifikat. Istio menerapkan mTLS secara transparan melalui sidecar Envoy dengan mode STRICT/PERMISSIVE. Sertifikat berumur pendek (24 jam) menghilangkan kebutuhan pencabutan dan membatasi jendela waktu kompromi. SPIRE mengotomatiskan penerbitan dan rotasi sertifikat melalui API Workload. Kunci privat mTLS sebaiknya berada di HSM atau TPM untuk penerapan dengan keamanan tinggi. Tantangan operasional mencakup perlindungan kunci CA, kompatibilitas perantara jaringan, dan rotasi tanpa waktu henti.