Ringkasan TLS yang diautentikasi backend dan mTLS backend

Saat load balancer terhubung ke backend yang berada dalam Google Cloud, load balancer menerima sertifikat apa pun yang diberikan backend Anda. Dalam kasus seperti itu, load balancer tidak melakukan validasi sertifikat apa pun.

Dengan TLS yang diautentikasi backend atau autentikasi backend, load balancer dapat memverifikasi identitas backend yang terhubung dengannya. Dengan mTLS backend, load balancer juga dapat membuktikan identitasnya ke backend dengan menggunakan sertifikat TLS klien.

Diagram berikut menunjukkan perbedaan antara mTLS frontend dan backend, dengan berfokus pada peran load balancer dalam setiap kasus. Dalam mTLS frontend, load balancer bertindak sebagai server, yang memverifikasi identitas klien. Dalam mTLS backend, load balancer bertindak sebagai klien, yang membuktikan identitasnya ke backend.

mTLS frontend dan backend.
mTLS frontend dan backend (klik untuk memperbesar).

mTLS beroperasi secara independen di frontend dan backend. Anda dapat mengonfigurasi mTLS di frontend, backend, atau keduanya.

Dokumen ini memberikan ringkasan TLS yang diautentikasi backend beserta mTLS backend. Untuk mempelajari mTLS frontend lebih lanjut, lihat Ringkasan Mutual TLS.

TLS yang diautentikasi backend dan mTLS backend dapat dikonfigurasi di resource layanan backend Load Balancer Aplikasi eksternal global.

Fitur

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). TLS yang diautentikasi backend dan mTLS backend menambahkan kemampuan berikut ke Load Balancer Aplikasi:

  • Load balancer dapat memvalidasi sertifikat yang diberikan oleh backend terhadap anchor kepercayaan Anda sendiri. Anda dapat mengupload beberapa anchor kepercayaan untuk mengaktifkan migrasi yang lancar dari PKI sebelumnya ke PKI baru tanpa periode nonaktif.

  • Load balancer dapat memvalidasi sertifikat TLS backend terhadap root tepercaya publik (PKI web).

  • Anda dapat mengonfigurasi sertifikat perantara selain anchor kepercayaan untuk membantu membuat jalur validasi sertifikat backend. Penggunaan sertifikat perantara berarti server backend Anda tidak perlu menyediakan rantai sertifikat lengkap.

  • Anda dapat mengonfigurasi nama host Indikasi Nama Server (SNI) TLS untuk layanan backend Anda. Selama handshake TLS, load balancer menyertakan nama host SNI ini dalam pesan ClientHello yang dikirim ke backend. Backend kemudian merespons dengan sertifikat TLS-nya, dan load balancer memverifikasi bahwa setidaknya salah satu kolom Nama Alternatif Subjek (SAN) sertifikat ini cocok dengan nama host atau salah satu kolom SAN yang dikonfigurasi untuk layanan backend.

  • Anda dapat mengonfigurasi layanan backend load balancer untuk menggunakan mTLS sehingga load balancer dapat membuktikan identitasnya ke backend. Autentikasi ini dilakukan menggunakan sertifikat klien (load balancer) yang ditampilkan load balancer ke backend.

Persyaratan sertifikat

Saat mengonfigurasi sertifikat untuk TLS yang diautentikasi backend dan mTLS backend, 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 kriptografi yang lebih kuat. Algoritma hashing seperti MD4, MD5, dan SHA-1 tidak didukung.

  • Sertifikat server leaf yang disediakan oleh backend memiliki persyaratan berikut:

  • Untuk sertifikat klien leaf (load balancer) yang digunakan dalam mTLS backend, sertifikat harus berupa resource sertifikat Pengelola Sertifikat. Cakupan sertifikat ini harus client-auth, yang menunjukkan bahwa sertifikat ini digunakan sebagai sertifikat klien dalam mTLS backend.

  • Sertifikat root dan perantara yang digunakan dengan TLS yang diautentikasi backend memiliki persyaratan berikut:

Komponen utama TLS yang diautentikasi backend dan mTLS backend

Dengan TLS yang diautentikasi backend, load balancer dapat memverifikasi identitas backend yang terhubung dengannya. Anda dapat mengonfigurasi TLS yang diautentikasi backend di load balancer HTTP(S) yang menggunakan HTTPS atau HTTP/2 sebagai protokol layanan backend-nya. Jika Anda tidak mengonfigurasi TLS yang diautentikasi backend, load balancer akan menerima sertifikat apa pun dari backend. Dengan mTLS backend, Anda juga dapat mengonfigurasi load balancer untuk memberikan sertifikat kliennya sendiri ke backend, yang dapat digunakan backend untuk mengautentikasi load balancer.

Untuk mengonfigurasi TLS yang diautentikasi backend, Anda harus melakukan hal berikut:

  • Buat resource konfigurasi kepercayaan.
  • Buat resource Konfigurasi Autentikasi Backend.
  • Perbarui atribut setelan TLS di layanan backend, dengan mengarahkannya ke resource Konfigurasi Autentikasi Backend.

Untuk mengonfigurasi mTLS backend, Anda harus membuat sertifikat klien dan melampirkan sertifikat klien ke resource Konfigurasi Autentikasi Backend. Anda tidak dapat melampirkan sertifikat klien setelah resource Konfigurasi Autentikasi Backend dibuat.

Diagram berikut menunjukkan berbagai komponen, yang terpasang ke layanan backend Load Balancer Aplikasi, yang memungkinkan TLS yang diautentikasi backend dan mTLS backend.

Komponen TLS yang diautentikasi backend dan mTLS backend.
Komponen mTLS backend dan TLS yang diautentikasi backend (klik untuk memperbesar).

Informasi berikut memberikan ringkasan berbagai komponen yang digunakan untuk mengonfigurasi TLS yang diautentikasi backend dan mTLS backend.

Konfigurasi kepercayaan

Untuk mengautentikasi sertifikat server yang diberikan backend ke load balancer, load balancer harus dikonfigurasi dengan sertifikat X.509 yang membuat rantai kepercayaan ke penerbit sertifikat backend. Anda mengonfigurasi konfigurasi kepercayaan menggunakan resource TrustConfig, yang menyatakan seluruh konfigurasi kepercayaan dan berisi satu penyimpanan tepercaya.

Penyimpanan tepercaya merangkum trust anchor (sertifikat root) dan, secara opsional, satu atau beberapa sertifikat perantara. Trust anchor adalah sertifikat yang merepresentasikan root of trust. Sertifikat server yang valid harus menunjukkan rantai kepercayaan kembali ke beberapa anchor kepercayaan di penyimpanan kepercayaan.

Sertifikat perantara adalah sertifikat yang merupakan bagian dari rantai kepercayaan yang mengarah kembali ke trust anchor di trust store. Sertifikat ini digunakan, bersama dengan CA perantara tambahan yang disertakan dengan sertifikat leaf, untuk membangun rantai kepercayaan selama proses validasi. Membuat sertifikat perantara bersifat opsional.

Jika perlu menggunakan sertifikat yang ditandatangani sendiri, sudah tidak berlaku, tidak terhubung ke root of trust yang ditentukan, atau gagal divalidasi, Anda dapat menambahkan sertifikat tersebut ke daftar yang diizinkan dalam konfigurasi kepercayaan. Membuat sertifikat yang ditandatangani sendiri yang dapat ditambahkan ke daftar yang diizinkan juga bersifat opsional.

Trust store tidak berisi kunci pribadi karena hanya sertifikat yang diperlukan untuk memverifikasi rantai kepercayaan.

Resource Konfigurasi Autentikasi Backend

Resource Konfigurasi Autentikasi Backend (BackendAuthenticationConfig), yang terpasang ke layanan backend load balancer, memungkinkan hal berikut:

  • TLS yang diautentikasi backend (menggunakan konfigurasi tepercaya dan root tepercaya publik)
  • mTLS backend (menggunakan sertifikat klien)

Untuk mengaktifkan TLS yang diautentikasi backend dan mTLS backend, resource Konfigurasi Autentikasi Backend mengarah ke resource berikut:

  • Konfigurasi kepercayaan (trustConfig): konfigurasi kepercayaan terlampir yang digunakan untuk memvalidasi sertifikat server yang diberikan oleh backend.

  • Root tepercaya publik (wellKnownRoots): menunjukkan apakah load balancer memercayai sertifikat server backend yang dikeluarkan oleh CA publik, selain sertifikat yang dipercaya oleh konfigurasi kepercayaan. Untuk mempelajari lebih lanjut, lihat Menggunakan root tepercaya publik.

  • Sertifikat klien (clientCertificate): sertifikat klien yang digunakan load balancer untuk menyatakan identitasnya ke backend, jika koneksi ke backend menggunakan mTLS. Untuk TLS yang diautentikasi backend (autentikasi backend), kolom ini dapat kosong, yang dalam hal ini load balancer hanya mengautentikasi backend, tetapi bukan dirinya sendiri, ke backend.

Layanan backend

Dalam layanan backend, atribut tlsSettings mengarah ke resource berikut untuk memvalidasi sertifikat backend.

  • Konfigurasi Autentikasi Backend (authenticationConfig)
  • Nama host SNI (sni)
  • SAN yang diterima (subjectAltNames)

Kolom SNI (sni) dan SAN (subjectAltNames) dalam atribut tlsSettings mengontrol cara load balancer memvalidasi sertifikat backend berdasarkan nilai SAN sertifikat. Kolom ini memengaruhi proses validasi, terlepas dari apakah TLS yang diautentikasi backend dikonfigurasi atau tidak.

Jika kolom SNI ditetapkan (tlsSettings.sni), load balancer akan melakukan hal berikut:

  • Mengirimkan nama host SNI ke server backend selama TLS handshake.
  • Memverifikasi bahwa sertifikat TLS backend mencakup SAN yang cocok dengan nama host SNI.

Secara default, load balancer memeriksa apakah sertifikat TLS backend menyertakan SAN yang cocok dengan nama host SNI. Namun, jika SAN dikonfigurasi di layanan backend (tlsSettings.subjectAltNames), load balancer akan melakukan hal berikut:

  • Mengabaikan nama host SNI untuk verifikasi SAN.
  • Memverifikasi bahwa sertifikat TLS backend menyertakan SAN yang cocok dengan salah satu SAN yang diterima (subjectAltNames) yang dikonfigurasi di layanan backend.

Sertifikat klien

Selain TLS yang diautentikasi backend (autentikasi backend), Anda dapat mengonfigurasi layanan backend load balancer untuk menggunakan mTLS, sehingga load balancer dapat membuktikan identitasnya ke backend. Autentikasi ini menggunakan sertifikat klien (load balancer) yang ditampilkan load balancer ke backend.

Untuk mengonfigurasi mTLS backend, Anda harus melakukan hal berikut:

  • Buat resource sertifikat klien yang berisi sertifikat klien (load balancer) dan kunci pribadinya.
  • Lampirkan sertifikat klien ke resource Konfigurasi Autentikasi Backend.

mTLS backend juga kompatibel dengan identitas beban kerja terkelola Compute Engine saat Anda mengonfigurasi sertifikat terkelola melalui Certificate Manager. Sertifikat yang dikelola PKI publik tidak didukung, dan semua sertifikat klien harus memiliki cakupan client-auth dan mematuhi persyaratan sertifikat.

Jika backend meminta sertifikat klien, backend harus dikonfigurasi untuk menerima sertifikat klien. Jika backend menolak koneksi load balancer, load balancer akan menampilkan kode status HTTP 502 untuk permintaan yang di-proxy-nya dan mencatat status umum ke Cloud Logging.

Mengonfigurasi TLS yang diautentikasi backend dan mTLS backend di load balancer

Anda dapat mengonfigurasi TLS terautentikasi backend dan mTLS backend di load balancer menggunakan PKI pribadi atau root kepercayaan publik.

Menggunakan PKI pribadi

Berikut adalah ringkasan tingkat tinggi dari langkah-langkah utama yang perlu Anda ikuti untuk mengonfigurasi TLS yang diautentikasi backend dan mTLS backend di load balancer menggunakan sertifikat yang dikeluarkan dari PKI pribadi Anda. PKI pribadi memiliki keuntungan karena sepenuhnya berada di bawah kendali Anda dan terisolasi dari sistem PKI internet publik.

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

  2. Untuk mengonfigurasi mTLS backend, buat sertifikat klien yang berisi sertifikat klien (load balancer) dan kunci pribadinya.

  3. Buat resource Konfigurasi Autentikasi Backend yang mereferensikan konfigurasi kepercayaan. Jika Anda ingin mengonfigurasi mTLS backend, resource Konfigurasi Autentikasi Backend mereferensikan konfigurasi kepercayaan dan sertifikat klien.

  4. Lampirkan resource Konfigurasi Autentikasi Backend ke layanan backend load balancer.

Untuk mempelajari penyiapan ini secara mendetail, lihat panduan berikut:

Menggunakan root of trust publik

Selain menggunakan sertifikat yang dikeluarkan dari PKI pribadi untuk mengaktifkan TLS yang diautentikasi backend, Anda juga dapat menggunakan root tepercaya publik untuk memvalidasi sertifikat backend.

Untuk menggunakan root tepercaya publik, Anda tidak perlu membuat konfigurasi kepercayaan dan melampirkannya ke resource Konfigurasi Autentikasi Backend. Sebagai gantinya, Anda harus menetapkan PUBLIC_ROOTS sebagai nilai di kolom wellKnownRoots pada resource Konfigurasi Autentikasi Backend. Namun, Anda juga dapat membuat konfigurasi kepercayaan yang secara eksplisit menyertakan root sertifikat yang dikeluarkan secara publik, selain sertifikat yang dipercayai oleh konfigurasi kepercayaan.

Setelan PUBLIC_ROOTS menggunakan sekumpulan CA root, mirip dengan sekumpulan CA root yang dipercaya oleh browser, yang dikelola oleh Google dan dapat berubah dari waktu ke waktu. Hal ini menimbulkan risiko sertifikat backend Anda menjadi tidak valid saat root ini berubah. Jika Anda perlu memvalidasi sertifikat yang diterbitkan secara publik, sebaiknya pilih CA yang sudah mapan dan tepercaya serta yang menggunakan penandatanganan silang perantara untuk menerbitkan sertifikat backend Anda guna memitigasi risiko sertifikat root yang akan habis masa berlakunya atau dicabut.

Langkah-langkah validasi sertifikat server

Saat memvalidasi sertifikat server selama TLS yang diautentikasi backend, atau autentikasi backend, load balancer melakukan hal berikut:

  1. Verifikasi bahwa server memiliki kunci pribadi sertifikat.

    Server membuktikan kepemilikan kunci pribadi yang terkait dengan sertifikat yang disajikannya ke load balancer dengan menandatangani sepotong informasi menggunakan kunci pribadinya dan mengirimkannya ke load balancer sebagai bagian dari pesan CertificateVerify. Load balancer kemudian memverifikasi tanda tangan ini menggunakan kunci publik dari sertifikat server. Jika verifikasi tanda tangan gagal, hal ini menunjukkan bahwa server backend tidak memiliki kunci pribadi yang sesuai dengan sertifikat. Dalam kasus seperti itu, load balancer menghentikan handshake TLS tanpa mencatat error apa pun.

  2. Verifikasi rantai kepercayaan.

    Jika konfigurasi tepercaya menyertakan setidaknya satu trust anchor atau memiliki atribut wellKnownRoots yang disetel ke PUBLIC_ROOTS, load balancer akan mencoba memverifikasi rantai kepercayaan antara sertifikat server dan trust anchor yang dikonfigurasi. Pemeriksaan verifikasi mencakup hal-hal berikut:

    • Sertifikat server backend, sertifikat perantara (jika diberikan), dan sertifikat root yang dikonfigurasi mematuhi persyaratan sertifikat.
    • Untuk semua sertifikat dalam rantai kepercayaan, kolom subjek dalam sertifikat induk cocok dengan kolom penerbit dalam sertifikat turunan. Verifikasi ini membantu memastikan bahwa identitas (subjek) sertifikat induk sama dengan identitas yang tercantum sebagai penerbit dalam sertifikat turunan.
    • Untuk semua sertifikat dalam rantai kepercayaan, ID kunci subjek (SKID) sertifikat induk cocok dengan ID kunci otoritas (AKID) dalam sertifikat turunan. Kecocokan ini mengonfirmasi bahwa sertifikat turunan dikeluarkan oleh otoritas root yang benar dan dapat dipercaya karena kunci publik root dirujuk dalam AKID untuk memverifikasi validitas sertifikat.

  3. Buat koneksi dengan backend.

    Jika validasi sertifikat berhasil, load balancer akan melanjutkan koneksi ke backend.

    Namun, jika validasi sertifikat gagal, load balancer akan menghentikan koneksi ke backend, mengirimkan kode status HTTP 502 ke klien, dan mencatat alasan penghentian ke Cloud Logging. Jika terjadi error validasi sertifikat, permintaan masuk berikutnya akan memicu load balancer untuk memulai ulang koneksi backend.

    Koneksi backend juga dapat gagal jika server backend menolak koneksi. Dengan mTLS backend, hal ini dapat terjadi karena sertifikat klien dianggap tidak valid. Jika koneksi ke backend gagal, load balancer akan merespons permintaan yang di-proxy dengan kode status HTTP 502 dan mencatat alasan error umum ke Cloud Logging.

Penanganan dan logging error

Load Balancer Aplikasi menyediakan kemampuan logging mendetail yang memungkinkan Anda memantau validasi sertifikat server, mengidentifikasi potensi masalah, dan memecahkan masalah koneksi. Bagian ini menguraikan berbagai jenis error yang dapat terjadi selama validasi mTLS dan cara mencatatnya.

Jika validasi sertifikat server gagal, koneksi akan dihentikan dan kesalahan akan dicatat ke Cloud Logging. Error ini dijelaskan dalam tabel berikut.

Status sertifikat server Error yang dicatat
Rantai sertifikat server terlalu panjang (lebih dari 10 intermediate certificate disertakan dengan sertifikat server). server_cert_chain_exceeded_limit

Server atau sertifikat perantara memiliki ukuran kunci RSA yang tidak valid.

Tidak ada validasi yang dilakukan.

Kunci RSA dapat berkisar dari 2048 hingga 4096 bit.

 server_cert_invalid_rsa_key_size

Server atau sertifikat perantara menggunakan kurva elips yang tidak didukung.

Tidak ada validasi yang dilakukan.

Kurva yang valid adalah P-256 dan P-384.

 server_cert_unsupported_elliptic_curve_key

Server atau sertifikat perantara menggunakan algoritma non-RSA atau non-ECDSA.

Tidak ada validasi yang dilakukan.

 server_cert_unsupported_key_algorithm

PKI yang akan digunakan untuk validasi memiliki lebih dari sepuluh sertifikat perantara yang memiliki Subject dan Subject Public Key Info yang sama.

Tidak ada validasi yang dilakukan.

 server_cert_pki_too_large

Intermediate certificate yang diberikan untuk validasi memiliki lebih dari 10 batasan nama.

server_cert_chain_max_name_constraints_exceeded

Sertifikat server memiliki kolom ekstensi Extended Key Usage (EKU), tetapi kolom tersebut tidak menyertakan serverAuth.

server_cert_chain_invalid_eku
Batas waktu terlampaui saat mencoba memvalidasi rantai sertifikat. server_cert_validation_timed_out

Batas kedalaman atau iterasi tercapai saat mencoba memvalidasi rantai sertifikat.

Kedalaman maksimum untuk rantai sertifikat adalah sepuluh, termasuk sertifikat root dan server. Jumlah maksimum iterasi adalah 100 (sertifikat yang diperiksa untuk memvalidasi rantai sertifikat server).

 server_cert_validation_search_limit_exceeded

Anda mengonfigurasi mTLS tanpa menyiapkan resource TrustConfig.

 server_cert_validation_not_performed

Server tidak memberikan sertifikat yang diminta selama handshake.

 server_cert_not_provided

Sertifikat server gagal diverifikasi dengan resource TrustConfig.

 ssl_certificate_verification_failed

Layanan tidak dapat melakukan validasi rantai sertifikat.

 server_cert_validation_unavailable
Error internal saat memvalidasi rantai sertifikat. server_cert_validation_internal_error

TrustConfig yang cocok tidak ditemukan.

 server_cert_trust_config_not_found
Payload sertifikat server (termasuk sertifikat perantara) terlalu besar (lebih dari 16 KB). server_cert_exceeded_size_limit

Batasan

  • TLS yang diautentikasi backend dan mTLS backend hanya dapat dikonfigurasi untuk Load Balancer Aplikasi eksternal global. Load Balancer Aplikasi Klasik tidak mendukung TLS yang diautentikasi backend dan mTLS backend.

  • TLS yang diautentikasi backend dan mTLS backend tidak didukung untuk jenis backend berikut:

    • Backend NEG internet global

    • Backend App Engine

  • Untuk mengaktifkan mTLS backend, Anda juga harus mengonfigurasi TLS yang diautentikasi backend.

  • Jika ingin mengaktifkan mTLS backend, Anda harus membuat sertifikat klien sebelum mengonfigurasi resource Konfigurasi Autentikasi Backend.

  • Health check yang digunakan oleh backend tidak menerapkan autentikasi TLS atau kemampuan mTLS. Anda harus mengonfigurasi backend dengan endpoint health check yang dapat merespons permintaan HTTP atau HTTPS.

  • Load balancer tidak meneruskan nama host SNI klien dari koneksi TLS frontend saat terhubung ke backend. Namun, backend dapat mengakses nama host SNI klien menggunakan header permintaan kustom.

  • Untuk mTLS backend, kunci sertifikat klien dibatasi untuk berikut ini:

    • Kunci RSA dapat berkisar dari 2048 hingga 4096 bit.
    • Kunci ECDSA dapat menggunakan kurva P-256 atau P-384.

  • TLS yang diautentikasi backend tidak mendukung pemeriksaan pencabutan sertifikat.

Kuota dan batas

  • Satu penyimpanan tepercaya dapat menyimpan hingga 200 anchor tepercaya dan sertifikat perantara secara gabungan, dengan batas terpisah 100 untuk sertifikat perantara. Tidak lebih dari tiga sertifikat perantara dapat berbagi informasi Subjek dan Kunci Publik Subjek yang sama.

  • Kedalaman maksimum rantai sertifikat adalah 10 sertifikat, termasuk sertifikat root dan leaf. Jumlah maksimum sertifikat perantara yang dapat dievaluasi saat mencoba membangun rantai kepercayaan adalah 100.

  • TLS yang diautentikasi backend membatasi rantai sertifikat yang diterima dari backend hingga tidak lebih dari 16 KB dan 10 sertifikat.

  • Sertifikat root yang digunakan untuk validasi tidak boleh berisi lebih dari 10 batasan nama.

  • Jumlah maksimum nama alternatif subjek yang diizinkan di kolom tlsSettings.subjectAltNames[] adalah 5.

Langkah berikutnya