TLS Bersama, atau mTLS, adalah protokol standar industri untuk autentikasi bersama antara klien dan server. Hal ini memastikan bahwa klien dan server melakukan autentikasi satu sama lain dengan memverifikasi bahwa masing-masing memiliki sertifikat yang valid yang dikeluarkan oleh certificate authority (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mewajibkan klien dan server untuk menunjukkan sertifikat, yang mengonfirmasi identitas kedua belah pihak sebelum komunikasi dilakukan.
mTLS dikonfigurasi di resource proxy HTTPS target dari semua Load Balancer Aplikasi:
- Load Balancer Aplikasi eksternal global
- Load Balancer Aplikasi Klasik
- Load Balancer Aplikasi eksternal regional
- Load Balancer Aplikasi internal regional
- Load Balancer Aplikasi internal lintas region
mTLS menggunakan Infrastruktur Kunci Publik (PKI) untuk mengautentikasi identitas entitas yang berkomunikasi melalui jaringan. Infrastruktur ini mencakup tiga komponen: klien, server, dan Certificate Authority (CA). mTLS untuk load balancer mendukung fitur berikut:
Verifikasi bahwa klien yang menampilkan sertifikat memiliki kunci pribadinya.
Validasi sertifikat klien dalam salah satu dari dua mode:
Menolak sertifikat yang tidak valid: Menerapkan autentikasi ketat dengan menolak permintaan jika rantai sertifikat klien tidak dapat divalidasi.
Izinkan sertifikat yang tidak valid atau tidak ada: Memberikan fleksibilitas dengan meneruskan semua permintaan ke backend, meskipun sertifikat klien tidak ada atau tidak valid.
Memvalidasi sertifikat klien terhadap anchor PKI yang diupload (sertifikat root), dengan opsi untuk menambahkan beberapa anchor secara terpisah guna memungkinkan migrasi yang lancar dari PKI lama ke PKI baru tanpa periode nonaktif.
Berikan sertifikat perantara tambahan untuk membantu membuat jalur validasi sertifikat klien terhadap anchor PKI yang ditentukan (root certificate). Sertifikat perantara ini memungkinkan mTLS berfungsi dengan klien yang tidak menyediakan rantai sertifikat lengkap.
Buat dan teruskan sidik jari sertifikat ke backend sebagai header permintaan kustom.
Teruskan kolom yang dipilih yang diekstrak dari sertifikat ke backend menggunakan header kustom.
Teruskan hasil validasi dan error validasi apa pun ke backend menggunakan header kustom.
Persyaratan sertifikat
Saat mengonfigurasi sertifikat untuk mTLS, pastikan sertifikat tersebut mematuhi persyaratan berikut:
- Alat kriptografi modern membentuk dasar autentikasi mTLS. Sertifikat harus menggunakan algoritma RSA atau ECDSA untuk pertukaran kunci. Algoritma hashing harus menggunakan SHA-256 atau fungsi hash kriptografis yang lebih kuat. Algoritma hashing seperti MD4, MD5, dan SHA-1 tidak didukung.
- Untuk sertifikat klien (daun):
- Ekstensi Batasan Dasar
tidak boleh berisi
CA=true
. - Ekstensi Penggunaan Kunci yang Diperpanjang
harus berisi
clientAuth
. - Ekstensi Penggunaan Kunci yang Diperpanjang
tidak boleh berisi kolom
codeSigning
,timeStamping
, atauOCSPSigning
. - Masa berlaku sertifikat tidak boleh habis.
- Sertifikat klien tidak boleh berupa sertifikat yang ditandatangani sendiri.
- Ekstensi Batasan Dasar
tidak boleh berisi
- Untuk root certificate dan intermediate certificate:
- Ekstensi Basic Constraints
harus berisi
CA=true
. - Ekstensi Penggunaan Kunci
harus ditetapkan ke
keyCertSign
. - Ekstensi Extended Key Usage
harus berisi kolom
clientAuth
. - Masa berlaku sertifikat tidak boleh habis.
- Ekstensi Basic Constraints
harus berisi
Arsitektur deployment mTLS
Dengan mTLS, Anda dapat mengonfigurasi resource konfigurasi kepercayaan, yang berisi penyimpanan kepercayaan. Repositori kepercayaan mengenkapsulasi anchor kepercayaan (root certificate) dan, secara opsional, satu atau beberapa intermediate certificate. Saat load balancer menerima sertifikat klien, load balancer akan memvalidasinya dengan membuat rantai kepercayaan dari sertifikat klien kembali ke anchor kepercayaan yang dikonfigurasi.
Berikut adalah ringkasan singkat tentang berbagai resource yang perlu Anda konfigurasikan untuk menyiapkan mTLS untuk load balancer:
Konfigurasi kepercayaan. Berisi satu resource trust store, yang pada gilirannya mengenkapsulasi anchor kepercayaan (root certificate) dan, secara opsional, satu atau beberapa sertifikat perantara. Konfigurasi kepercayaan digunakan untuk membuat rantai kepercayaan antara sertifikat klien dan anchor kepercayaan. Untuk informasi selengkapnya, lihat Konfigurasi kepercayaan.
Secara opsional, jika Anda perlu menggunakan sertifikat yang telah ditandatangani sendiri, telah berakhir masa berlakunya, atau tidak valid, atau jika Anda tidak memiliki akses ke root dan sertifikat perantara, Anda dapat menambahkan sertifikat tersebut ke konfigurasi kepercayaan di kolom
allowlistedCertificates
. Anda tidak memerlukan trust store untuk menambahkan sertifikat ke daftar yang diizinkan.Menambahkan sertifikat ke daftar yang diizinkan berarti sertifikat tersebut selalu dianggap valid selama sertifikat dapat diuraikan, bukti kepemilikan kunci pribadi ditetapkan, dan batasan pada kolom SAN sertifikat terpenuhi.
Trust store. Berisi anchor kepercayaan dan sertifikat certificate authority (CA) perantara yang digunakan untuk membuat rantai kepercayaan dan memvalidasi sertifikat klien. CA digunakan untuk menerbitkan sertifikat tepercaya untuk klien. CA diidentifikasi oleh anchor kepercayaan load balancer (sertifikat root) atau sertifikat CA perantara.
Anda dapat mengupload jenis root certificate dan intermediate certificate berikut ke trust store:
- Sertifikat yang dikeluarkan oleh CA pihak ketiga pilihan Anda.
- Sertifikat yang diterbitkan oleh CA pribadi yang Anda kontrol, seperti yang dijelaskan dalam Menyiapkan TLS bersama dengan CA pribadi.
- Sertifikat yang diberikan pengguna, seperti yang dijelaskan dalam Menyiapkan TLS bersama dengan sertifikat yang diberikan pengguna.
Autentikasi Klien (juga dikenal sebagai
ServerTLSPolicy
). Menentukan mode validasi klien dan resource konfigurasi kepercayaan yang akan digunakan saat memvalidasi sertifikat klien. Saat klien menampilkan sertifikat yang tidak valid atau tidak ada sertifikat ke load balancer, mode validasi klien akan menentukan cara koneksi klien ditangani. Anda dapat menentukan semua parameter terkait autentikasi mTLS dalam kebijakan TLS server. Resource Autentikasi Klien (ServerTLSPolicy
) dilampirkan ke resource proxy HTTPS target.
Diagram berikut menunjukkan berbagai komponen mTLS yang dilampirkan ke resource proxy HTTPS target dari Application Load Balancer global dan regional.
global
Diagram berikut menunjukkan komponen deployment Load Balancer Aplikasi eksternal. Arsitektur ini juga berlaku untuk Load Balancer Aplikasi internal lintas-region, yang merupakan Load Balancer Aplikasi internal yang menggunakan komponen global.
regional
Diagram berikut menunjukkan komponen deployment Load Balancer Aplikasi internal regional. Arsitektur ini juga berlaku untuk Load Balancer Aplikasi eksternal regional, yang merupakan Load Balancer Aplikasi eksternal yang menggunakan komponen regional.
Mode validasi klien
Jika klien menampilkan sertifikat yang tidak valid atau tidak ada sertifikat ke load balancer, atribut clientValidationMode
pada resource Autentikasi Klien (ServerTLSPolicy
) akan menentukan cara load balancer menangani koneksi klien.
Nilai mode validasi klien adalah sebagai berikut:
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
. Mengizinkan koneksi dari klien meskipun validasi sertifikat klien gagal atau tidak ada sertifikat klien yang ditampilkan. Dalam mode ini, load balancer memungkinkan koneksi dari klien dan meneruskan semua permintaan ke backend terlepas dari apakah rantai kepercayaan dapat dibuat atau tidak.Bukti kepemilikan kunci pribadi selalu diperiksa saat sertifikat klien ditampilkan. Jika klien tidak dapat membuktikan kepemilikan kunci pribadi, handshake TLS akan dihentikan meskipun mode validasi klien mengizinkan sertifikat klien yang tidak valid atau tidak ada.
REJECT_INVALID
. Menolak koneksi jika klien tidak memberikan sertifikat atau jika validasi sertifikat gagal. Dalam mode ini, load balancer akan menghentikan koneksi dari klien jika tidak dapat membuat rantai kepercayaan dari sertifikat klien kembali ke anchor kepercayaan.
Mengonfigurasi mTLS di load balancer
Berikut adalah ringkasan tingkat tinggi tentang langkah-langkah utama yang perlu Anda ikuti untuk mengonfigurasi mTLS di load balancer:
Buat resource konfigurasi kepercayaan yang terdiri dari anchor kepercayaan (root certificate) dan sertifikat perantara yang berfungsi sebagai root kepercayaan.
Tautkan konfigurasi kepercayaan ke resource Autentikasi Klien (
ServerTLSPolicy
), yang menentukan mode validasi klienALLOW_INVALID_OR_MISSING_CLIENT_CERT
atauREJECT_INVALID
.Lampirkan resource Autentikasi Klien (
ServerTLSPolicy
) ke resource proxy HTTPS target load balancer.Opsional: Anda dapat menggunakan header mTLS kustom untuk meneruskan informasi tentang koneksi mTLS ke layanan backend atau peta URL.
Untuk mempelajari penyiapan ini lebih lanjut, lihat panduan berikut:
- Menyiapkan TLS bersama dengan sertifikat yang diberikan pengguna
- Menyiapkan TLS bersama dengan CA pribadi
Langkah-langkah validasi sertifikat klien
Saat memvalidasi sertifikat klien, load balancer melakukan hal berikut:
Verifikasi bahwa klien memiliki kunci pribadi.
Klien membuktikan kepemilikan kunci pribadi yang terkait dengan kunci publik dalam sertifikat dengan membuat tanda tangan selama proses handshake. Load balancer memverifikasi tanda tangan ini menggunakan kunci publik klien. Jika verifikasi tanda tangan gagal, artinya klien bukan pemilik sertifikat. Dalam hal ini, handshake TLS akan dihentikan meskipun konfigurasi Anda mengizinkan sertifikat klien yang tidak valid atau tidak ada. Tidak ada error yang dicatat ke dalam log untuk Load Balancer Aplikasi eksternal global, tetapi error TLS dicatat ke dalam log di kolom
proxyStatus
untuk Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal.Verifikasi rantai kepercayaan.
Load balancer memverifikasi rantai kepercayaan antara sertifikat klien dan konfigurasi kepercayaan yang dikonfigurasi. Pemeriksaan verifikasi mencakup hal berikut:
- Sertifikat klien, intermediate, dan root mematuhi persyaratan sertifikat.
- Kolom subjek dalam sertifikat induk cocok dengan kolom penerbit dalam sertifikat turunan. Verifikasi ini memastikan bahwa identitas sertifikat induk (subjek) sama dengan identitas yang tercantum sebagai penerbit dalam sertifikat turunan.
- ID Kunci Subjek (SKID) sertifikat induk cocok dengan ID Kunci Otoritas (AKID) dalam sertifikat turunan. Kecocokan ini mengonfirmasi bahwa sertifikat turunan dikeluarkan oleh root authority yang benar dan dapat dipercaya karena kunci publik root dirujuk dalam AKID untuk memverifikasi validitas sertifikat.
- Nama alternatif subjek (SAN) sertifikat turunan tidak melanggar kolom
NameConstraints
dalam sertifikat induk.
Teruskan permintaan ke backend.
Jika validasi sertifikat klien berhasil, permintaan akan diteruskan ke backend menggunakan header mTLS kustom.
Namun, jika validasi gagal, tindakan yang diambil bergantung pada nilai mode validasi klien:
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
: Permintaan diteruskan dengan header mTLS kustom yang menunjukkan alasan kegagalan validasi. Untuk Load Balancer Aplikasi internal lintas region, Load Balancer Aplikasi eksternal regional, dan Load Balancer Aplikasi internal regional, selain header mTLS kustom, Anda dapat mengonfigurasi kolom opsional mTLS untuk memeriksa alasan kegagalan.REJECT_INVALID
: Koneksi dihentikan dan error dicatat ke Cloud Logging.
Header mTLS kustom yang diteruskan ke backend
Tabel berikut menunjukkan header mTLS kustom yang diteruskan ke backend, baik saat sertifikat klien lulus validasi maupun saat gagal. Jika sertifikat klien gagal dalam validasi, header kustom
akan diteruskan ke backend hanya jika mode validasi klien ditetapkan ke
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
.
Status sertifikat klien | Mode validasi klien | Header khusus |
---|---|---|
Rantai sertifikat klien terlalu panjang (lebih dari 10 intermediate certificate yang disertakan dengan sertifikat klien). |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Sertifikat klien atau perantara memiliki ukuran kunci RSA yang tidak valid. Tidak ada validasi yang dilakukan. Kunci RSA dapat berkisar dari 2048 hingga 4096 bit. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Klien atau sertifikat perantara menggunakan kurva ekliptik yang tidak didukung. Tidak ada validasi yang dilakukan. Kurva elips yang valid adalah P-256 dan P-384. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Klien atau sertifikat perantara menggunakan algoritma non-RSA, non-ECDSA. Tidak ada validasi yang dilakukan. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
PKI yang akan digunakan untuk validasi memiliki lebih dari sepuluh sertifikat perantara yang memiliki Subjek dan Info Kunci Publik Subjek yang sama. Tidak ada validasi yang dilakukan. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Sertifikat intermediate yang diberikan untuk validasi memiliki lebih dari 10 batasan nama. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Sertifikat klien tidak memiliki
ekstensi |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Batas waktu terlampaui saat mencoba memvalidasi rantai sertifikat. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
client_cert_sha256_fingerprint: <cert hash>
|
Batas kedalaman atau iterasi tercapai saat mencoba memvalidasi rantai sertifikat. Kedalaman maksimum untuk rantai sertifikat adalah sepuluh, termasuk root certificate dan client certificate. Iterasi maksimumnya adalah 100 (sertifikat yang diperiksa untuk memvalidasi rantai sertifikat klien). |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Anda mengonfigurasi mTLS tanpa menyiapkan resource Tidak ada validasi yang dapat dilakukan, tetapi hash sertifikat diteruskan ke backend. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Tidak ada sertifikat klien. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Sertifikat klien gagal validasi terhadap resource TrustConfig .
|
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Sertifikat klien lulus validasi verifier sertifikat. | Tidak berlaku |
client_cert_error: <empty>
|
Penanganan error dan logging
Application Load Balancer menyediakan kemampuan logging mendetail yang memungkinkan Anda memantau validasi sertifikat klien, mengidentifikasi potensi masalah, dan memecahkan masalah koneksi. Bagian ini menguraikan berbagai jenis error yang dapat terjadi selama validasi mTLS dan cara error tersebut dicatat ke dalam log.
Error yang dicatat dalam mode REJECT_INVALID
Jika validasi sertifikat klien gagal, dan mode validasi klien ditetapkan ke REJECT_INVALID
, koneksi akan dihentikan dan error akan dicatat ke dalam log Cloud Logging. Error ini dijelaskan dalam tabel berikut.
Status sertifikat klien | Error yang dicatat dalam log |
---|---|
Rantai sertifikat klien terlalu panjang (lebih dari 10 intermediate certificate yang disertakan dengan sertifikat klien). |
client_cert_chain_exceeded_limit
|
Sertifikat klien atau perantara memiliki ukuran kunci RSA yang tidak valid. Tidak ada validasi yang dilakukan. Kunci RSA dapat berkisar dari 2048 hingga 4096 bit. |
client_cert_invalid_rsa_key_size
|
Klien atau sertifikat perantara menggunakan kurva ekliptik yang tidak didukung. Tidak ada validasi yang dilakukan. Kurva yang valid adalah P-256 dan P-384. |
client_cert_unsupported_elliptic_curve_key
|
Klien atau sertifikat perantara menggunakan algoritma non-RSA atau non-ECDSA. Tidak ada validasi yang dilakukan. |
client_cert_unsupported_key_algorithm
|
PKI yang akan digunakan untuk validasi memiliki lebih dari sepuluh sertifikat perantara yang memiliki Subjek dan Info Kunci Publik Subjek yang sama. Tidak ada validasi yang dilakukan. |
client_cert_pki_too_large
|
Sertifikat intermediate yang diberikan untuk validasi memiliki lebih dari 10 batasan nama. |
|
Sertifikat klien tidak memiliki ekstensi
|
|
Batas waktu terlampaui saat mencoba memvalidasi rantai sertifikat. |
client_cert_validation_timed_out
|
Batas kedalaman atau iterasi tercapai saat mencoba memvalidasi rantai sertifikat. Kedalaman maksimum untuk rantai sertifikat adalah sepuluh, termasuk root certificate dan client certificate. Jumlah maksimum iterasi adalah 100 (sertifikat yang diperiksa untuk memvalidasi rantai sertifikat klien). |
client_cert_validation_search_limit_exceeded
|
Anda mengonfigurasi mTLS tanpa menyiapkan resource TrustConfig .
|
client_cert_validation_not_performed
|
Klien tidak memberikan sertifikat yang diminta selama handshake. |
client_cert_not_provided
|
Sertifikat klien gagal validasi dengan resource TrustConfig .
|
client_cert_validation_failed
|
Error yang dicatat ke dalam log untuk koneksi yang ditutup
Jika mode validasi klien ditetapkan ke
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
atau REJECT_INVALID
, error tertentu
akan menyebabkan koneksi ditutup dan dicatat ke dalam log Cloud Logging. Error ini dijelaskan dalam tabel berikut.
Status sertifikat klien | Permintaan | Error yang dicatat ke dalam log |
---|---|---|
Sertifikat klien gagal mencocokkan tanda tangan selama handshake. | Menghentikan handshake SSL | Tidak ada |
Layanan tidak dapat melakukan validasi rantai sertifikat. | Menghentikan koneksi |
client_cert_validation_unavailable
|
Error internal saat memvalidasi rantai sertifikat. | Menghentikan koneksi |
client_cert_validation_internal_error
|
TrustConfig yang cocok tidak ditemukan.
|
Menghentikan koneksi |
client_cert_trust_config_not_found
|
Payload sertifikat klien (termasuk sertifikat perantara) terlalu besar (lebih dari 16 KB). | Menghentikan koneksi |
client_cert_exceeded_size_limit
|
Jika logging diaktifkan di layanan backend, Anda dapat melihat error yang dicatat untuk koneksi tertutup selama validasi sertifikat klien mTLS.
Batasan
Load balancer tidak melakukan pemeriksaan pencabutan pada sertifikat klien.
Application Load Balancer memungkinkan Anda mengupload konfigurasi kepercayaan dengan satu trust store yang berisi maksimal 100 anchor kepercayaan dan 100 sertifikat perantara serta 500 sertifikat yang ditambahkan ke daftar yang diizinkan. Semua sertifikat perantara tidak boleh memiliki lebih dari tiga sertifikat yang berbagi info Subjek dan Kunci Publik Subjek yang sama. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
Kedalaman maksimum untuk rantai sertifikat adalah sepuluh, termasuk root certificate dan client certificate. Jumlah maksimum sertifikat perantara yang dapat dievaluasi saat mencoba membuat rantai kepercayaan adalah 100. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
Kunci sertifikat yang diupload dan diteruskan dari klien dibatasi untuk hal berikut:
- Kunci RSA dapat berkisar dari 2048 hingga 4096 bit. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
- Kunci ECDSA dapat menggunakan kurva P-256 atau P-384.
Rantai sertifikat yang diterima dari klien dibatasi hingga 16 KB dan 10 sertifikat. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
Root certificate yang digunakan untuk validasi tidak boleh berisi lebih dari 10 batasan nama. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.