Ringkasan TLS bersama

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):
  • Untuk root certificate dan intermediate certificate:

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:

  • 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.

TLS bersama dengan komponen Load Balancer Aplikasi eksternal global.
TLS bersama dengan komponen Load Balancer Aplikasi eksternal global (klik untuk memperbesar).

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.

TLS bersama dengan komponen Load Balancer Aplikasi internal regional.
TLS bersama dengan komponen Load Balancer Aplikasi internal regional (klik untuk memperbesar).

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:

  1. Buat resource konfigurasi kepercayaan yang terdiri dari anchor kepercayaan (root certificate) dan sertifikat perantara yang berfungsi sebagai root kepercayaan.

  2. Tautkan konfigurasi kepercayaan ke resource Autentikasi Klien (ServerTLSPolicy), yang menentukan mode validasi klien ALLOW_INVALID_OR_MISSING_CLIENT_CERT atau REJECT_INVALID.

  3. Lampirkan resource Autentikasi Klien (ServerTLSPolicy) ke resource proxy HTTPS target load balancer.

  4. 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:

Langkah-langkah validasi sertifikat klien

Saat memvalidasi sertifikat klien, load balancer melakukan hal berikut:

  1. 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.

  2. 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.
  3. 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

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_exceeded_limit

client_cert_sha256_fingerprint: <cert hash>

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

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_invalid_rsa_key_size

client_cert_sha256_fingerprint: <cert hash>

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

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_unsupported_elliptic_curve_key

client_cert_sha256_fingerprint: <cert hash>

Klien atau sertifikat perantara menggunakan algoritma non-RSA, non-ECDSA.

Tidak ada validasi yang dilakukan.

ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_unsupported_key_algorithm

client_cert_sha256_fingerprint: <cert hash>

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

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_pki_too_large

client_cert_sha256_fingerprint: <cert hash>

Sertifikat intermediate yang diberikan untuk validasi memiliki lebih dari 10 batasan nama.

ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_max_name_constraints_exceeded

client_cert_sha256_fingerprint: <cert hash>

Sertifikat klien tidak memiliki ekstensi Extended Key Usage (EKU) yang menyertakan clientAuth.

ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_invalid_eku

client_cert_sha256_fingerprint: <cert hash>

Batas waktu terlampaui saat mencoba memvalidasi rantai sertifikat. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_timed_out

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

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_search_limit_exceeded

client_cert_sha256_fingerprint: <cert hash>

Anda mengonfigurasi mTLS tanpa menyiapkan resource TrustConfig.

Tidak ada validasi yang dapat dilakukan, tetapi hash sertifikat diteruskan ke backend.

ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_not_performed

client_cert_sha256_fingerprint: <cert hash>

Tidak ada sertifikat klien. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: false

client_cert_chain_verified: false

client_cert_error: client_cert_not_provided

client_cert_sha256_fingerprint: <empty>

Sertifikat klien gagal validasi terhadap resource TrustConfig. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_failed

client_cert_sha256_fingerprint: <cert hash>

Sertifikat klien lulus validasi verifier sertifikat. Tidak berlaku

client_cert_present: true

client_cert_chain_verified: true

client_cert_error: <empty>

client_cert_sha256_fingerprint: <cert hash>

client_cert_serial_number: <serial_number>

client_cert_valid_not_before: <date>

client_cert_valid_not_after: <date>

client_cert_uri_sans: <list>

client_cert_dnsname_sans: <list>

client_cert_issuer_dn: <issuer>

client_cert_subject_dn: <subject>

client_cert_leaf: <certificate>

client_cert_chain: <list>

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.

client_cert_chain_max_name_constraints_exceeded

Sertifikat klien tidak memiliki ekstensi Extended Key Usage (EKU) yang menyertakan clientAuth.

client_cert_chain_invalid_eku

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.

Langkah selanjutnya