Google Cloud의 전송 중인 데이터 암호화

이 콘텐츠는 2025년 4월에 마지막으로 업데이트되었으며 작성 당시의 상황을 나타냅니다. Google이 지속적으로 고객 보호를 개선함에 따라 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 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는 Google에서 유지관리하는 TLS 프로토콜의 오픈소스 구현인 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 워크로드의 경우 Cloud Service Mesh를 사용하면 상호 인증(클라이언트 및 서버)에 mTLS를 사용하고 관리하는 인증서를 사용하여 전송 중에 통신을 암호화할 수 있습니다.

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

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 간 통신을 암호화하는 데 사용되며 주기적으로 순환됩니다.

VPC 네트워크 내 VM 간 연결과 Google의 프로덕션 네트워크 내에서 피어링된 VPC 네트워크는 무결성이 보호되고 암호화됩니다. 이러한 연결에는 고객 VM 간, 고객과 Google 관리 VM(예: Cloud SQL) 간의 연결이 포함됩니다. 트래픽이 라우팅되는 방식의 다이어그램에서는 이 상호작용(연결 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 서비스에서 다른 Google Cloud 서비스로의 연결에 대한 인증, 무결성, 암호화에 ALTS를 사용합니다.

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

ALTS는 Google 프로덕션 환경에서 실행되는 서비스 간에 그리고 GFE에서 서비스로 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)입니다. 자세한 내용은 포스트 퀀텀 암호화를 참조하세요.

  • 레코드 프로토콜: 서비스 간 데이터는 공유 트래픽 키를 사용하여 전송 중에 암호화됩니다. 기본적으로 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에 저장됩니다.

다음 단계