Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Enkripsi di semua Google Cloud wilayah
Semua traffic VM-ke-VM dalam jaringan VPC dan jaringan VPC yang di-peering
dienkripsi.
Enkripsi antara load balancer proxy dan backend
Untuk beberapa load balancer proxy (lihat tabel 1), Google otomatis mengenkripsi traffic ke backend yang berada dalam jaringan VPC. Google Cloud Tindakan ini disebut enkripsi tingkat jaringan otomatis.
Enkripsi tingkat jaringan otomatis hanya berlaku untuk komunikasi dengan
jenis backend berikut:
Beberapa Google Cloud load balancer menggunakan Google Front End
(GFEs) sebagai
klien ke backend, sedangkan yang lain menggunakan proxy
Envoy open source.
Dalam semua kasus, load balancer mendukung cipher suite yang tercantum dalam
RFC 8446, bagian 9.1
untuk TLS 1.3. Untuk TLS 1.2 dan yang lebih lama, load balancer mendukung cipher suite
yang terkait dengan profil kebijakan SSL
COMPATIBLE.
Tabel berikut memberikan ringkasan load balancer proxy yang mengenkripsi traffic ke backend.
Tabel 1. Komunikasi antara load balancer dan backend
Load balancer proxy
Proxy (klien ke backend)
Enkripsi tingkat jaringan otomatis
Opsi protokol layanan backend
Load Balancer Aplikasi eksternal global
GFE (dengan software Envoy untuk fitur perutean lanjutan)
HTTP, HTTPS, dan HTTP/2
Pilih HTTPS atau HTTP/2 jika Anda memerlukan enkripsi yang dapat diaudit dalam pengiriman ke
backend.
Load Balancer Aplikasi Klasik
GFE
HTTP, HTTPS, dan HTTP/2
Pilih HTTPS atau HTTP/2 jika Anda memerlukan enkripsi yang dapat diaudit dalam pengiriman ke
backend.
Load Balancer Aplikasi eksternal regional
Proxy Envoy
HTTP, HTTPS, dan HTTP/2
Pilih HTTPS atau HTTP/2 jika Anda memerlukan enkripsi yang dapat diaudit dalam pengiriman ke
backend.
Load Balancer Aplikasi internal regional
Proxy Envoy
HTTP, HTTPS, dan HTTP/2
Pilih HTTPS atau HTTP/2 jika Anda memerlukan enkripsi yang dapat diaudit dalam pengiriman ke
backend.
Load Balancer Aplikasi internal lintas region
Proxy Envoy
HTTP, HTTPS, dan HTTP/2
Pilih HTTPS atau HTTP/2 jika Anda memerlukan enkripsi yang dapat diaudit dalam pengiriman ke
backend.
Load Balancer Jaringan proxy eksternal global
GFE (dengan software Envoy untuk fitur perutean lanjutan)
SSL atau TCP
Pilih SSL untuk protokol layanan backend jika Anda memerlukan enkripsi yang dapat diaudit
dalam pengiriman ke backend.
Load Balancer Jaringan proxy klasik
GFE
SSL atau TCP
Pilih SSL untuk protokol layanan backend jika Anda memerlukan enkripsi yang dapat diaudit
dalam pengiriman ke backend.
Load Balancer Jaringan proxy eksternal regional
Proxy Envoy
TCP
Load Balancer Jaringan proxy internal regional
Proxy Envoy
TCP
Load Balancer Jaringan proxy internal lintas region
Proxy Envoy
TCP
Mesh Layanan Cloud
Proxy sisi klien
HTTPS dan HTTP/2
Kasus penggunaan protokol backend yang aman
Protokol aman untuk terhubung ke instance backend direkomendasikan dalam
kasus berikut:
Jika Anda memerlukan koneksi terenkripsi yang dapat diaudit dari load balancer (atau Cloud Service Mesh) ke instance backend.
Saat load balancer terhubung ke instance backend yang berada di luar
Google Cloud (dengan NEG internet). Komunikasi
ke backend NEG internet mungkin melalui internet publik. Saat load
balancer terhubung ke NEG internet, sertifikat yang ditandatangani CA publik harus
memenuhi persyaratan
validasi.
Pertimbangan protokol backend aman
Saat menggunakan protokol layanan backend yang aman, perhatikan hal berikut:
Instance atau endpoint backend load balancer Anda harus ditayangkan menggunakan protokol yang sama dengan layanan backend. Misalnya, jika protokol layanan backend
adalah HTTPS, backend harus berupa server HTTPS.
Jika protokol layanan backend adalah HTTP/2, backend Anda harus menggunakan TLS. Untuk
petunjuk konfigurasi, lihat dokumentasi untuk software yang berjalan
di instance atau endpoint backend Anda.
Anda harus menginstal kunci pribadi dan sertifikat di instance atau endpoint backend agar dapat berfungsi sebagai server HTTPS atau SSL. Sertifikat ini tidak perlu cocok dengan sertifikat SSL frontend load balancer. Untuk petunjuk penginstalan, lihat dokumentasi untuk
software yang berjalan di instance backend atau endpoint Anda.
Dengan pengecualian load balancer HTTPS dengan backend NEG internet, load balancer tidak menggunakan ekstensi Server Name Indication (SNI) untuk koneksi ke backend.
Saat load balancer terhubung ke backend yang berada dalam Google Cloud, load balancer akan menerima sertifikat apa pun yang ditampilkan backend Anda. Dalam hal ini, load balancer hanya melakukan validasi sertifikat minimum.
Misalnya, sertifikat diperlakukan sebagai valid bahkan dalam keadaan
berikut:
Sertifikat ditandatangani sendiri.
Sertifikat ditandatangani oleh certificate authority (CA) yang tidak dikenal.
Masa berlaku sertifikat telah berakhir atau belum valid.
Atribut CN dan subjectAlternativeName tidak cocok dengan header Host atau data PTR DNS.
Untuk sertifikat RSA, mulai 28 April 2025, load balancer hanya akan
menerima sertifikat RSA yang memiliki ekstensi Penggunaan Kunci X509v3 dan
menyertakan parameter Tanda Tangan Digital dan Enkripsi Kunci. Untuk informasi
selengkapnya, lihat catatan rilis terkait pada 24 Januari
2025.
Protokol frontend aman
Saat Anda menggunakan proxy HTTPS target atau proxy SSL target sebagai bagian dari konfigurasi,
Google Cloud akan menggunakan protokol frontend yang aman.
Load Balancer Aplikasi Internal menggunakan library BoringSSL Google. Untuk mengetahui detail FIPS 140-2, lihat dokumentasi Envoy.
Google membuat proxy Envoy untuk Load Balancer Aplikasi internal dalam mode yang mematuhi FIPS.
Cloud Service Mesh mendukung proxy Envoy yang dibuat dalam mode
yang mematuhi FIPS.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Encryption from the load balancer to the backends\n\nEncryption in all Google Cloud regions\n--------------------------------------\n\nAll VM-to-VM traffic within a VPC network and peered\nVPC networks is encrypted.\n\nEncryption between proxy load balancers and backends\n----------------------------------------------------\n\nFor some proxy load balancers (see table 1), Google automatically encrypts\ntraffic to the backends that reside within Google Cloud VPC\nnetworks. This is called *automatic network-level encryption*.\nAutomatic network-level encryption is only applicable to communications with\nthese types of backends:\n\n- Instance groups\n- Zonal NEGs (`GCE_VM_IP_PORT` endpoints)\n\nIn addition, Google Cloud provides [secure protocol options to\nencrypt communication with the backend\nservice](/load-balancing/docs/backend-service#protocol_to_the_backends).\n\nSome Google Cloud load balancers use [Google Front Ends\n(GFEs)](/security/infrastructure/design#google_front_end_service) as the\nclient to the backends whereas others use the open source [Envoy\nproxy](https://www.envoyproxy.io/).\nIn all cases, the load balancer supports the cipher suites listed in\n[RFC 8446, section 9.1](https://datatracker.ietf.org/doc/html/rfc8446#section-9.1)\nfor TLS 1.3. For TLS 1.2 and earlier, the load balancer supports the cipher suites\nassociated with the COMPATIBLE\n[SSL policy profile](/load-balancing/docs/ssl-policies-concepts#defining_an_ssl_policy).\n\nThe following table provides a summary of the proxy load balancers that encrypt traffic to the backends.\n\n### Secure backend protocol use cases\n\nA secure protocol to connect to backend instances is recommended in the\nfollowing cases:\n\n- When you require an auditable, encrypted connection from the load balancer (or\n Cloud Service Mesh) to the backend instances.\n\n- When the load balancer connects to a backend instance that is outside of\n Google Cloud (with an [internet\n NEG](/load-balancing/docs/negs/internet-neg-concepts)). Communication\n to an internet NEG backend might transit the public internet. When the load\n balancer connects to an internet NEG, the public CA-signed certificate must\n [meet the validation\n requirements](/load-balancing/docs/negs/internet-neg-concepts#ssl_server_certification_validation_and_san_validation).\n\n### Secure backend protocol considerations\n\nWhen using a secure backend service protocol, keep the following in mind:\n\n- Your load balancer's backend instances or endpoints must serve using the same\n protocol as the backend service. For example, if the backend service protocol\n is HTTPS, the backends must be HTTPS servers.\n\n- If the backend service protocol is HTTP/2, your backends must use TLS. For\n configuration instructions, see the documentation for the software running\n on your backend instances or endpoints.\n\n- You must install private keys and certificates on your backend instances or\n endpoints in order for them to function as HTTPS or SSL servers. These\n certificates don't need to match the load balancer's frontend SSL\n certificates. For installation instructions, see the documentation for the\n software running on your backend instances or endpoints.\n\n- With the exception of HTTPS load balancers with [internet NEG\n backends](/load-balancing/docs/negs/internet-neg-concepts), load balancers\n don't use the Server Name Indication (SNI) extension for connections to the\n backend.\n\n- When a load balancer connects to backends that are within Google Cloud,\n the load balancer accepts any certificate your backends present. In this case,\n the load balancer performs only minimum certificate validation.\n\n For example, certificates are treated as valid even in the following\n circumstances:\n - The certificate is self-signed.\n - The certificate is signed by an unknown certificate authority (CA).\n - The certificate has expired or is not yet valid.\n - The `CN` and `subjectAlternativeName` attributes don't match a `Host` header or DNS PTR record.\n\n For RSA certificates, starting April 28, 2025, the load balancer will only\n accept RSA certificates that have the X509v3 Key Usage extension present and\n include both the Digital Signature and Key Encipherment parameters. For more\n information, see the associated [release note on January 24,\n 2025](/load-balancing/docs/release-notes#January_24_2025).\n\nSecure frontend protocols\n-------------------------\n\nWhen you use a target HTTPS or target SSL proxy as part of your configuration,\nGoogle Cloud uses a secure frontend protocol.\n\nExternal Application Load Balancers and external proxy Network Load Balancers use Google's\nBoringCrypto library. For FIPS 140-2 details, see [NIST Cryptographic Module\nValidation Program Certificate #3678](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3678).\n\nInternal Application Load Balancers use Google's BoringSSL library. For FIPS 140-2\ndetails, see the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl).\nGoogle builds Envoy proxies for internal Application Load Balancers in FIPS compliant\nmode.\nCloud Service Mesh supports Envoy proxies that are built in FIPS-compliant mode."]]
