일부 프록시 부하 분산기의 경우(표 1 참조) Google은 Google Cloud VPC 네트워크 내에 상주하는 백엔드에 대한 트래픽을 자동으로 암호화합니다. 이를 자동 네트워크 수준 암호화라고 합니다.
자동 네트워크 수준 암호화는 다음 유형의 백엔드를 포함하는 커뮤니케이션에만 적용됩니다.
일부 Google Cloud 부하 분산기는 Google 프런트엔드(GFE)를 백엔드에 대한 클라이언트로 사용하며, 다른 부하 분산기는 오픈소스 Envoy 프록시를 사용합니다.
모든 경우에 부하 분산기는 TLS 1.3의 RFC 8446, 섹션 9.1에 나열된 암호화 스위트를 지원합니다. TLS 1.2 이하의 경우 부하 분산기는 COMPATIBLE SSL 정책 프로필과 연결된 암호화 스위트를 지원합니다.
다음 표에서는 백엔드에 대한 트래픽을 암호화하는 프록시 부하 분산기를 요약해서 보여줍니다.
표 1. 부하 분산기와 백엔드 사이의 커뮤니케이션
프록시 부하 분산기
프록시(클라이언트에서 백엔드로)
자동 네트워크 수준 암호화
백엔드 서비스 프로토콜 옵션
전역 외부 애플리케이션 부하 분산기
GFE(고급 라우팅 기능을 위한 Envoy 소프트웨어 포함)
HTTP, HTTPS, HTTP/2
백엔드 전송에 감사 가능한 암호화가 필요하면 HTTPS 또는 HTTP/2를 선택합니다.
기본 애플리케이션 부하 분산기
GFE
HTTP, HTTPS, HTTP/2
백엔드 전송에 감사 가능한 암호화가 필요하면 HTTPS 또는 HTTP/2를 선택합니다.
리전별 외부 애플리케이션 부하 분산기
Envoy 프록시
HTTP, HTTPS, HTTP/2
백엔드 전송에 감사 가능한 암호화가 필요하면 HTTPS 또는 HTTP/2를 선택합니다.
리전 내부 애플리케이션 부하 분산기
Envoy 프록시
HTTP, HTTPS, HTTP/2
백엔드 전송에 감사 가능한 암호화가 필요하면 HTTPS 또는 HTTP/2를 선택합니다.
교차 리전 내부 애플리케이션 부하 분산기
Envoy 프록시
HTTP, HTTPS, HTTP/2
백엔드 전송에 감사 가능한 암호화가 필요하면 HTTPS 또는 HTTP/2를 선택합니다.
전역 외부 프록시 네트워크 부하 분산기
GFE(고급 라우팅 기능을 위한 Envoy 소프트웨어 포함)
SSL 또는 TCP
백엔드 전송에 감사 가능한 암호화가 필요하면 SSL을 선택합니다.
기본 프록시 네트워크 부하 분산기
GFE
SSL 또는 TCP
백엔드 전송에 감사 가능한 암호화가 필요하면 SSL을 선택합니다.
리전 외부 프록시 네트워크 부하 분산기
Envoy 프록시
TCP
리전 내부 프록시 네트워크 부하 분산기
Envoy 프록시
TCP
교차 리전 내부 프록시 네트워크 부하 분산기
Envoy 프록시
TCP
Cloud Service Mesh
클라이언트 측 프록시
HTTPS 및 HTTP/2
보안 백엔드 프로토콜 사용 사례
다음과 같은 경우 백엔드 인스턴스에 연결하기 위한 보안 프로토콜이 권장됩니다.
부하 분산기(또는 Cloud Service Mesh)에서 백엔드 인스턴스로 감사 가능하고 암호화된 연결이 필요한 경우
부하 분산기가Google Cloud (인터넷 NEG 사용) 외부에 있는 백엔드 인스턴스에 연결하는 경우. 인터넷 NEG 백엔드와의 통신은 공개 인터넷을 전송할 수 있습니다. 부하 분산기가 인터넷 NEG에 연결될 때 공개 CA 서명 인증서는 유효성 검사 요구사항을 충족해야 합니다.
보안 백엔드 프로토콜 고려사항
보안 백엔드 서비스 프로토콜을 사용할 때는 다음 사항에 유의하세요.
부하 분산기의 백엔드 인스턴스 또는 엔드포인트는 백엔드 서비스와 동일한 프로토콜을 사용하여 제공해야 합니다. 예를 들어 백엔드 서비스 프로토콜이 HTTPS이면 백엔드는 HTTPS 서버여야 합니다.
백엔드 서비스 프로토콜이 HTTP/2이면 백엔드는 TLS를 사용해야 합니다. 구성 안내는 백엔드 인스턴스 또는 엔드포인트에서 실행되는 소프트웨어에 대한 문서를 참조하세요.
백엔드 인스턴스 또는 엔드포인트가 HTTPS 또는 SSL 서버로 작동하도록 비공개 키와 인증서를 설치해야 합니다. 이러한 인증서는 부하 분산기의 프런트엔드 SSL 인증서와 일치하지 않아도 됩니다. 설치 안내는 백엔드 인스턴스 또는 엔드포인트에서 실행되는 소프트웨어에 대한 문서를 참조하세요.
인터넷 NEG 백엔드가 있는 HTTPS 부하 분산기를 제외하고, 부하 분산기는 백엔드 연결에 서버 이름 표시(SNI) 확장 프로그램을 사용하지 않습니다.
부하 분산기가 Google Cloud내의 백엔드에 연결할 때, 부하 분산기는 백엔드의 모든 인증서를 수락합니다. 이 경우 부하 분산기는 최소한의 인증서 검증만 실행합니다.
예를 들어 다음 상황에서도 인증서가 유효한 것으로 간주됩니다.
자체 서명된 인증서입니다.
인증서가 알 수 없는 인증 기관(CA)에 의해 서명됩니다.
인증서가 만료되었거나 아직 유효하지 않습니다.
CN 및 subjectAlternativeName 속성이 Host 헤더 또는 DNS PTR 레코드와 일치하지 않습니다.
RSA 인증서의 경우 2025년 4월 28일부터 부하 분산기에서는 X509v3 키 사용 확장 프로그램이 있고 디지털 서명 및 키 암호화 파라미터를 모두 포함된 RSA 인증서만 수락됩니다. 자세한 내용은 관련 2025년 1월 24일 출시 노트를 참조하세요.
보안 프런트엔드 프로토콜
대상 HTTPS 또는 대상 SSL 프록시를 구성의 일부로 사용할 경우Google Cloud 는 보안 프런트엔드 프로토콜을 사용합니다.
외부 애플리케이션 부하 분산기와 외부 프록시 네트워크 부하 분산기는 Google의 BoringCrypto 라이브러리를 사용합니다. FIPS 140-2에 대한 자세한 내용은 NIST 암호화 모듈 검증 프로그램 인증서 #3678를 참조하세요.
내부 애플리케이션 부하 분산기는 Google의 BoringSSL 라이브러리를 사용합니다. FIPS 140-2에 대한 자세한 내용은 Envoy 문서를 참조하세요.
Google은 FIPS 준수 모드에서 내부 애플리케이션 부하 분산기를 위한 Envoy 프록시를 빌드합니다.
Cloud Service Mesh는 FIPS 준수 모드로 빌드된 Envoy 프록시를 지원합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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."]]
