Google Cloud의 전송 중 암호화

이 콘텐츠는 2025년 4월에 최종 업데이트되었으며, 작성 당시의 상황을 나타냅니다. Google이 지속적으로 고객 보호를 개선함에 따라 Google의 보안 정책 및 시스템은 향후 변경될 수 있습니다.

Google에서는 인터넷을 통해 전송되거나, Google 인프라 내에서 이동되거나, Google 서버에 저장되는 데이터를 포함해 모든 사용자 데이터를 보호하기 위해 노력하고 있습니다. Google 보안 전략의 핵심은 저장 데이터와 전송 중 데이터의 인증, 무결성, 암호화입니다. 이 문서에서는 인터넷에서 전송 중인 데이터와 Google 네트워크 내에서 전송 중인 데이터를 암호화하도록Google Cloud 를 설계한 방법을 설명합니다. 이 문서는 고객 데이터 센터 네트워크와 Google 데이터 센터 네트워크 간의 인터커넥트를 통해 전송되는 데이터에는 적용되지 않습니다.

전송 중 암호화는 전송 계층 보안 (TLS), BoringSSL, 애플리케이션 레이어 전송 보안(ALTS), PSP 보안 프로토콜을 비롯한 다양한 기술을 사용하여 데이터를 보호합니다. Google에서 제공하는 기본 보호 기능 외에도 IPsec, 관리형 TLS 인증서, Cloud Service Mesh와 같은 암호화 옵션을 추가하여 데이터를 더욱 안전하게 보호할 수 있습니다.

이 문서는 Google Cloud를 사용하거나 고려하는 보안 운영팀과 CISO를 대상으로 합니다. 이 문서에서는 암호화 및 암호화 기본 요소를 기본적으로 이해하고 있다고 가정합니다.

인증, 무결성, 암호화

Google은 전송 중인 데이터의 신뢰성, 무결성, 보안성을 보장하기 위해 다음과 같은 보안책을 강구하고 있습니다.

  • 인증은 연결의 피어 (사람 또는 프로세스)의 ID를 확인합니다.
  • 무결성은 전송하는 데이터가 소스와 대상 간에 전송되는 동안 변경되지 않도록 합니다.
  • 암호화는 암호화를 사용하여 전송 중에 데이터를 읽을 수 없게 처리하고 기밀로 유지합니다.

전송 중인 데이터 암호화는 최종 사용자와 Google Cloud 또는 두 서비스 간에 데이터가 이동하는 동안 통신이 가로채지는 경우 데이터를 보호하는 데 도움이 됩니다. 전송 중인 데이터 암호화는 전송 전에 엔드포인트를 인증하고 데이터를 암호화합니다. 도착 시 수신자는 데이터를 복호화하고 전송 중에 데이터가 수정되지 않았는지 확인합니다.

암호화는 광범위한 보안 전략 요소 중 하나입니다. 전송 중 암호화는 잠재적 공격으로부터 데이터를 보호하고 Google, Google Cloud 고객 또는 최종 사용자가 네트워크의 하위 레이어를 신뢰할 필요가 없습니다.

트래픽이 라우팅되는 방식

이 섹션에서는 요청이 최종 사용자에서 적절한Google Cloud 서비스 또는 고객 애플리케이션으로 전달되는 방법과 트래픽이 서비스 간에 라우팅되는 방법을 설명합니다.

Google Cloud 서비스는 Google이 고객에게 제공하는 모듈형 클라우드 서비스입니다. 컴퓨팅, 데이터 스토리지, 데이터 분석, 머신러닝 등의 서비스가 여기에 포함됩니다. 예를 들어 Cloud Storage는 Google Cloud 서비스입니다.

고객 애플리케이션은 Google 고객이 Google Cloud 서비스를 사용하여 빌드하고 배포할 수 있는 Google Cloud 에서 호스팅되는 애플리케이션입니다. Google CloudGoogle Cloud 에서 호스팅되는 고객 애플리케이션 또는 파트너 솔루션은 서비스로 간주되지 않습니다. Google Cloud 예를 들어 Cloud Run, Google Kubernetes Engine 또는 Compute Engine의 VM을 사용해 빌드한 애플리케이션은 고객 애플리케이션입니다.

다음 다이어그램은 최종 사용자에서 Google로의 트래픽 경로, Google 네트워크 내 경로, 각 연결의 보안을 보여줍니다. 다음과 같은 트래픽 경로가 표시됩니다.

  • 인터넷의 최종 사용자 - Google Cloud 서비스 (다이어그램의 라벨: A)
  • 인터넷의 최종 사용자 -Google Cloud 에 호스팅되는 고객 애플리케이션(다이어그램에서 B로 라벨이 지정됨)
  • 가상 머신 간 (다이어그램에서 C로 라벨이 지정됨)
  • 가상 머신-Google 프런트엔드 (GFE) (다이어그램에서 D로 라벨이 지정됨)
  • GFE에서 Google API 및 서비스로의 연결 (다이어그램에서 E로 라벨이 지정됨)
  • Google Cloud 서비스와 Google Cloud 서비스 간 (다이어그램에서 F로 라벨이 지정됨)

Google의 트래픽 경로

최종 사용자와 Google 간의 전송 중 암호화

다음 섹션에서는 앞의 다이어그램에 표시된 최종 사용자 라우팅 요청에 대해 자세히 설명합니다.

Google Cloud 서비스 최종 사용자

Cloud Storage 또는 Compute Engine과 같은Google Cloud 서비스는 Google에서 고객에게 제공하고 프로덕션 환경에서 실행되는 클라우드 서비스입니다.Google Cloud 서비스는 Google 프런트엔드(GFE)라는 글로벌 분산 시스템을 통해 전 세계에서 수신되는 요청을 허용합니다. GFE는 수신되는 HTTP(S), TCP, TLS 연결에 대한 트래픽을 종료하고, DDoS 공격에 대응하고, 트래픽을Google Cloud 서비스 자체로 라우팅하고 부하를 분산합니다. 유니캐스트 또는 Anycast를 사용하여 공지된 경로를 사용하는 GFE 접속 지점이 전 세계에 있습니다.

GFE는 최종 사용자의 트래픽을 Google 네트워크를 통해Google Cloud 서비스로 라우팅하고 최종 사용자의 트래픽을 Google Cloud 에서 호스팅되고 Cloud Load Balancing을 사용하는 고객 애플리케이션으로 라우팅합니다.

클라이언트가 HTTPS, HTTP/2 또는 HTTP/3을 통해 Google Cloud 서비스로 전송하는 요청은 TLS로 보호됩니다. GFE의 TLS는 TLS 프로토콜의 Google에서 유지관리하는 오픈소스 구현인 BoringSSL로 구현됩니다. BoringSSL의 핵심인 BoringCrypto는 FIPS 140-3 Level 1 인증을 받았습니다.

GFE는 전방 보안 키 협상을 비롯하여 업계 표준 암호화 매개변수를 클라이언트와 협상합니다. 기능이 더 약한 이전 클라이언트의 경우 GFE는 클라이언트가 제공하는 가장 강력한 기존 암호화 원시를 선택합니다.

Google Cloud에서 호스팅되는 고객 애플리케이션의 최종 사용자

직접 연결을 사용하거나 부하 분산기를 통해 Google Cloud 에서 호스팅되는 고객 애플리케이션으로 인터넷에서 최종 사용자 트래픽을 라우팅할 수 있습니다. 트래픽이 직접 라우팅되면 애플리케이션을 호스팅하는 VM 서버의 외부 IP 주소로 라우팅됩니다.

외부 애플리케이션 부하 분산기 또는 외부 프록시 네트워크 부하 분산기와 함께 TLS를 사용하여 Google Cloud에서 실행 중인 애플리케이션에 연결할 수 있습니다. 레이어 7 부하 분산기를 사용하면 최종 사용자와 부하 분산기 간의 연결이 기본적으로 TLS를 사용하여 암호화됩니다 (최종 사용자의 클라이언트 애플리케이션이 TLS를 지원하는 경우). GFE는 자체 관리형 또는 Google 관리형 TLS 인증서를 사용하여 최종 사용자의 TLS 연결을 종료합니다. 인증서 맞춤설정에 대한 자세한 내용은 SSL 인증서 개요를 참조하세요. 부하 분산기와 고객 애플리케이션을 호스팅하는 VM 간에 암호화를 사용 설정하려면 부하 분산기에서 백엔드로의 암호화를 참고하세요.

상호 TLS (mTLS)를 구성하려면 상호 TLS 개요를 참고하세요. GKE 및 Compute Engine 워크로드의 경우 상호 인증 (클라이언트 및 서버)에 mTLS를 사용하고 관리하는 인증서를 사용하여 전송 중인 통신을 암호화할 수 있도록 Cloud Service Mesh를 사용하는 것이 좋습니다.

Firebase 호스팅 및 Cloud Run 커스텀 도메인의 경우 무료 자동화 TLS 인증서를 사용하는 것이 좋습니다. Cloud Run 커스텀 도메인을 사용하면 자체 SSL 인증서를 제공하고 HSTS (HTTP 엄격한 전송 보안) 헤더를 사용할 수도 있습니다.

Google 네트워크 내 전송 중인 데이터 암호화

Google Cloud 는 이 섹션에서 달리 설명하지 않는 한 Google 네트워크 내에서 전송 중인 고객 데이터를 암호화합니다.

Google의 AI 슈퍼컴퓨터 내에서 TPU 또는 GPU를 연결하는 특수한 초고성능 상호 연결은 이 문서에 설명된 네트워크와 별개입니다. Google Cloud에서 이러한 초고성능 상호 연결은 TPU의 경우 ICI이고 GPU의 경우 NVLink입니다. 자세한 내용은 TPU 아키텍처 및 GPU 머신 유형을 참고하세요.

외부 IP 주소를 사용하는 VM 연결을 통한 트래픽은 Google 네트워크를 벗어납니다. 이러한 연결에 대한 자체 암호화를 구성할 책임은 개발자에게 있습니다.

Google Cloud 가상 네트워크 인증 및 암호화

Google Cloud의 가상 네트워크는 VM 간의 트래픽을 암호화하고 무결성을 보호하며 인증합니다.

동일한 VPC 내 또는 Google Cloud의 가상 네트워크 내 피어링된 VPC 네트워크 전반에서 비공개 IP 트래픽의 암호화는 네트워크 레이어에서 수행됩니다.

통신 호스트 쌍마다 인증되고 무결성이 보호되며 암호화된 통신을 위해 ALTS로 보호되는 제어 채널을 사용하여 세션 키를 설정합니다. 세션 키는 호스트 간의 VM 간 통신을 암호화하는 데 사용되며 세션 키는 주기적으로 순환됩니다.

Google의 프로덕션 네트워크 내에서 VPC 네트워크 및 피어링된 VPC 네트워크 내에서 VM 간 연결은 무결성이 보호되고 암호화됩니다. 이러한 연결에는 고객 VM 간 연결과 고객 VM과 Cloud SQL과 같은 Google 관리 VM 간의 연결이 포함됩니다. 트래픽 라우팅 방식의 다이어그램에는 이 상호작용 (연결 C)이 나와 있습니다. Google은 내부 IP 주소 사용에 따라 자동 암호화를 활성화하므로 외부 IP 주소를 사용하는 VM 간의 연결은 자동으로 암호화되지 않습니다.

Google Cloud의 가상 네트워크는 VM 간의 모든 트래픽을 인증합니다. 이러한 인증은 보안 토큰을 사용하여 이루어지며 손상된 호스트가 네트워크에서 패킷을 스푸핑하지 못하도록 방지합니다.

보안 토큰은 발신자 및 수신자의 인증 정보가 포함된 터널 헤더에 캡슐화됩니다. 발신 호스트의 제어 영역에서 토큰을 설정하고 수신 호스트에서 토큰의 유효성을 검사합니다. 보안 토큰은 모든 흐름에서 사전 생성되며 토큰(발신자 정보 포함)과 호스트 보안 비밀로 구성됩니다.

Google API 및 서비스에 연결

트래픽 처리는 Google Cloud 서비스가 호스팅되는 위치에 따라 다릅니다.

대부분의 Google API 및 서비스는 GFE에 호스팅됩니다. VM-GFE 트래픽은 외부 IP 주소를 사용하여 Google Cloud 서비스에 연결되지만 비공개 액세스를 구성하여 외부 IP 주소를 사용하지 않을 수 있습니다. GFE에서 서비스로의 연결이 인증되고 암호화됩니다.

Cloud SQL과 같은 일부 서비스는 Google 관리 VM 인스턴스에서 호스팅됩니다. 고객 VM이 외부 IP 주소를 사용하여 Google 관리 VM 인스턴스에 호스팅된 서비스에 액세스하는 경우 트래픽은 Google의 프로덕션 네트워크에 유지되지만 외부 IP 주소가 사용되므로 자동으로 암호화되지 않습니다. 자세한 내용은 Google Cloud 가상 네트워크 인증 및 암호화를 참고하세요.

사용자가 Google Cloud 서비스에 요청을 전송하면 Google은 웹 (공용) 인증 기관의 인증서와 함께 HTTPS를 사용하여 전송 중 데이터를 보안 (인증, 무결성, 암호화 제공)합니다. 사용자가 GFE에 전송하는 모든 데이터는 TLS 또는 QUIC를 통해 전송 중에 암호화됩니다. GFE는 클라이언트에서 가능한 지원에 따라 특정 암호화 프로토콜을 클라이언트와 협상하며 가능한 경우 GFE는 최신 암호화 프로토콜을 협상합니다.

서비스 간 인증, 무결성, 암호화

Google 인프라는 GFE에서 Google Cloud 서비스로 연결되는 연결과 Google Cloud 서비스 간에 연결되는 연결의 인증, 무결성, 암호화에 ALTS를 사용합니다. Google Cloud

ALTS는 인증에 서비스 기반 ID를 사용합니다. Google의 프로덕션 환경에서 실행되는 서비스에는 서비스 기반 ID를 주장하는 사용자 인증 정보가 발급됩니다. 다른 서비스에서 RPC를 생성하거나 수신할 경우 서비스는 자체 사용자 인증 정보를 사용하여 인증합니다. ALTS는 이러한 사용자 인증 정보가 Google의 내부 CA에서 발급되었는지 확인합니다. Google의 내부 CA는 Certificate Authority Service와 무관하며 독립적입니다.

ALTS는 GFE에서 서비스로, 또는 Google의 프로덕션 환경에서 실행 중인 서비스 간에 데이터를 전송하는 트래픽에 암호화 및 암호화 무결성 보호를 사용합니다. Google Cloud

ALTS는 GFE와 Google Cloud 서비스 간의 트래픽을 위한 RPC 메커니즘에서 HTTP와 같은 다른 레이어 7 프로토콜을 캡슐화하는 데도 사용됩니다. 이 보호는 애플리케이션 레이어를 격리하는 데 도움이 되며 네트워크 경로의 보안에 대한 종속 항목을 삭제합니다.

전송 중인 데이터 암호화 방법

다음 섹션에서는 Google이 전송 중인 데이터를 암호화하는 데 사용하는 몇 가지 기술을 설명합니다.

PSP를 사용한 네트워크 암호화

PSP는 연결당 보안을 사용 설정하고 스마트 네트워크 인터페이스 카드 (SmartNIC) 하드웨어로 암호화 오프로드를 지원하는 전송에 독립적인 프로토콜입니다. SmartNIC를 사용할 수 있을 때마다 ALTS는 PSP를 사용하여 네트워크 간에 전송 중 데이터를 암호화합니다.

PSP는 대규모 데이터 센터 트래픽 요구사항이 충족되도록 설계되었습니다. Google 인프라는 PSP를 사용하여 데이터 센터 내부와 데이터 센터 간의 트래픽을 암호화합니다. PSP는 UDP와 같은 비TCP 프로토콜도 지원하며 연결마다 고유한 암호화 키를 사용합니다.

애플리케이션 레이어 전송 보안

ALTS는 Google에서 개발한 상호 인증 및 암호화 시스템입니다. ALTS는 Google의 프로덕션 환경에서 실행되는 서비스 간에 전송 중인 데이터에 인증, 비밀 유지, 무결성을 제공합니다. ALTS는 다음 프로토콜로 구성됩니다.

  • 핸드셰이크 프로토콜: 클라이언트가 결합된 타원 곡선 및 양자 안전 키 교환을 시작합니다. 핸드셰이크가 끝나면 관련 서비스는 서명된 인증서를 교환하고 확인하여 서로의 ID를 인증하고 공유 트래픽 키를 계산합니다. 공유 트래픽 키를 파생하는 데 지원되는 알고리즘 중에는 NIST 포스트 퀀텀 알고리즘인 ML-KEM (FIPS 203)이 있습니다. 자세한 내용은 포스트 퀀텀 암호화를 참고하세요.

  • Record 프로토콜: 서비스 간 데이터는 공유 트래픽 키를 사용하여 전송 중에 암호화됩니다. 기본적으로 ALTS는 모든 트래픽에 AES-128-GCM 암호화를 사용합니다. Google의 최하위 스토리지 시스템 내에서 전송되는 데이터는 AES-256 암호화를 사용하고 ALTS는 AES 메시지 인증을 제공합니다. ALTS의 암호화는 BoringSSL 또는 PSP에서 제공합니다. 이 암호화는 FIPS 140-2 Level 1 또는 FIPS 140-3 Level 1에서 검증됩니다.

ALTS 인증서의 루트 서명 키는 Google의 내부 CA에 저장됩니다.

다음 단계