Ringkasan TLS yang diautentikasi backend dan mTLS backend

Saat load balancer terhubung ke backend yang berada dalam Google Cloud, load balancer akan menerima sertifikat apa pun yang ditampilkan backend Anda. Dalam kasus tersebut, load balancer tidak menjalankan validasi sertifikat apa pun.

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

Diagram berikut menunjukkan perbedaan antara mTLS frontend dan backend, yang 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 frontend dan backend.

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 autentikasi backend dan mTLS backend menambahkan kemampuan berikut ke Load Balancer Aplikasi:

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

  • Load balancer dapat memvalidasi sertifikat TLS backend terhadap root kepercayaan 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 Server Name Indication (SNI) TLS untuk layanan backend. Selama TLS handshake, 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 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 kriptografis 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 di mTLS backend, sertifikat harus berupa resource sertifikat Pengelola Sertifikat. Cakupan sertifikat ini harus client-auth, yang menunjukkan bahwa sertifikat ini digunakan sebagai sertifikat klien di mTLS backend.

  • Root certificate dan intermediate certificate yang digunakan dengan TLS autentikasi backend memiliki persyaratan berikut:

Komponen utama TLS yang diautentikasi backend dan mTLS backend

Dengan TLS backend yang diautentikasi, load balancer dapat memverifikasi identitas backend yang terhubung. 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 menggunakan mTLS backend, Anda juga dapat mengonfigurasi load balancer untuk menampilkan sertifikat kliennya sendiri ke backend, yang dapat digunakan backend untuk mengautentikasi load balancer.

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

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

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 mengaktifkan TLS autentikasi backend dan mTLS backend.

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

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

Konfigurasi kepercayaan

Untuk mengautentikasi sertifikat server yang ditampilkan backend Anda ke load balancer, load balancer perlu 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 kepercayaan.

Repositori kepercayaan mengenkapsulasi anchor kepercayaan (root certificate) dan, secara opsional, satu atau beberapa intermediate certificate. Trust anchor adalah sertifikat yang mewakili root of trust. Sertifikat server yang valid harus menampilkan rantai kepercayaan kembali ke beberapa anchor kepercayaan di penyimpanan kepercayaan.

Sertifikat intermediate 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 membuat rantai kepercayaan selama proses validasi. Membuat sertifikat perantara adalah opsional.

Jika Anda perlu menggunakan sertifikat yang ditandatangani sendiri, habis masa berlakunya, tidak tertaut ke root trust yang ditentukan, atau gagal validasi, Anda dapat menambahkan sertifikat tersebut ke daftar yang diizinkan dalam konfigurasi trust. Membuat sertifikat yang ditandatangani sendiri yang dapat ditambahkan ke daftar yang diizinkan juga bersifat opsional.

Repositori kepercayaan tidak berisi kunci pribadi apa pun karena hanya sertifikat yang diperlukan untuk memverifikasi rantai kepercayaan.

Resource Konfigurasi Autentikasi Backend

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

  • TLS yang diautentikasi backend (menggunakan konfigurasi kepercayaan dan root kepercayaan 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 disediakan oleh backend.

  • Root kepercayaan 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 kepercayaan publik.

  • Sertifikat klien (clientCertificate): sertifikat klien yang digunakan load balancer untuk menyatakan identitasnya ke backend, jika koneksi ke backend menggunakan mTLS. Untuk TLS autentikasi backend (autentikasi backend), kolom ini dapat kosong, sehingga load balancer hanya mengautentikasi backend, tetapi tidak mengautentikasi 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 Disetujui (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.

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

  • Mengirim nama host SNI ke server backend selama TLS handshake.
  • Memverifikasi bahwa sertifikat TLS backend menyertakan 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 perlu melakukan hal berikut:

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

mTLS backend juga kompatibel dengan identitas workload yang dikelola Compute Engine saat Anda mengonfigurasi sertifikat yang dikelola melalui Pengelola Sertifikat. 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 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 of trust publik.

Menggunakan PKI pribadi

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

  1. Buat resource konfigurasi kepercayaan yang terdiri dari anchor kepercayaan (root certificate) 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 lebih lanjut, lihat panduan berikut:

Menggunakan root of trust publik

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

Untuk menggunakan root kepercayaan publik, Anda tidak perlu membuat konfigurasi kepercayaan dan melampirkan konfigurasi tersebut ke resource Konfigurasi Autentikasi Backend. Sebagai gantinya, Anda perlu menetapkan PUBLIC_ROOTS sebagai nilai di kolom wellKnownRoots dari resource Konfigurasi Autentikasi Backend. Meskipun demikian, Anda juga dapat membuat konfigurasi kepercayaan yang secara eksplisit menyertakan root sertifikat yang diterbitkan secara publik, selain sertifikat yang dipercaya oleh konfigurasi kepercayaan.

Setelan PUBLIC_ROOTS menggunakan kumpulan root CA, yang mirip dengan kumpulan root CA 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, pertimbangkan untuk memilih CA yang mapan dan tepercaya serta menggunakan penandatanganan silang intermediate untuk menerbitkan sertifikat backend Anda guna mengurangi risiko masa berlaku sertifikat root berakhir 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. Pastikan server memiliki kunci pribadi sertifikat.

    Server membuktikan kepemilikan kunci pribadi yang terkait dengan sertifikat yang ditampilkan ke load balancer dengan menandatangani bagian 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 akan menghentikan handshake TLS tanpa mencatat error apa pun.

  2. Verifikasi rantai kepercayaan.

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

    • Sertifikat server backend, sertifikat perantara (jika disediakan), dan root certificate 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 root authority yang benar dan dapat dipercaya karena kunci publik root di referensikan 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, mengirim kode status 502 HTTP 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 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.

Batasan

  • TLS yang diautentikasi backend dan mTLS backend hanya dapat dikonfigurasi untuk Load Balancer Aplikasi eksternal global. Load Balancer Aplikasi Klasik tidak mendukung TLS autentikasi 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 autentikasi backend.

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

  • Pemeriksaan kesehatan 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 hal berikut:

    • 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 kepercayaan dapat menyimpan hingga 200 anchor kepercayaan dan sertifikat antara, dengan batas terpisah 100 untuk sertifikat antara. Tidak lebih dari tiga sertifikat perantara yang 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 membuat rantai kepercayaan adalah 100.

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

  • Root certificate 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