전송 중인 데이터 암호화

이 문서는 Google이 암호화를 사용하여 데이터를 보호하는 방법을 다룬 세 번째 백서입니다. 이 백서에서는 Google Cloud 및 Google Workspace의 전송 중 데이터 암호화에 대한 자세한 내용을 설명합니다.

모든 Google 제품에 대해 Google은 고객 데이터를 확실하게 보호하고 데이터 보안 방식을 가능한 한 투명하게 유지하기 위해 노력하고 있습니다.

이 콘텐츠는 2022년 9월에 마지막으로 업데이트되었으며 작성된 당시의 상황을 나타냅니다. Google의 보안 정책 및 시스템은 고객 보호를 지속적으로 개선함에 따라 앞으로도 계속 변경될 수 있습니다.

CIO 수준 요약

Google은 전송 중인 데이터의 신뢰성, 무결성, 보안성을 보장하기 위해 다양한 보안책을 강구하고 있습니다.
이 백서에서 다루는 사용 사례에서는 데이터가 Google 또는 Google의 대리인이 통제하지 않는 물리적 경계 외부로 이동할 때 Google이 하나 이상의 네트워크 레이어에서 전송 중인 데이터를 암호화하고 인증합니다. VPC 네트워크 및 피어링된 VPC 네트워크 내의 모든 VM 간 트래픽이 암호화됩니다.
Google은 연결 방식에 따라 전송 중인 데이터에 기본적인 보호 조치를 적용합니다. 예를 들어 사용자와 Google 프런트엔드(GFE) 간의 통신은 TLS를 사용하여 보호합니다.
WAN을 통한 데이터 암호화가 추가로 필요한 Google Cloud 고객은 사용자의 데이터를 애플리케이션으로 전송하거나 가상 머신 간에 데이터를 전송할 때 추가적인 데이터 보호 조치를 구현할 수 있습니다. 이와 같은 보호 조치에는 IPSec 터널, Gmail S/MIME, 관리형 SSL 인증서, Istio 등이 있습니다.
Google은 어디든 모두에게 전송 중인 데이터 암호화를 제공하기 위해 업계와 협력하고 있습니다. Google은 인증서 투명성, Chrome API, 보안 SMTP를 비롯해 인터넷 전반에서 전송 중 암호화 및 데이터 보안 사용을 독려하는 여러 오픈소스 프로젝트를 진행하고 있습니다.
Google은 전송 중 암호화 기술 부문에서 계속 업계 선두를 유지할 것입니다. 이를 위해 암호화 기술 개발 및 개선에 리소스를 투자하고 있으며 이에 일환으로 키 투명성 및 포스트 퀀텀 암호화 혁신을 추구하고 있습니다.

소개

보안은 퍼블릭 클라우드 제공업체 선정 시 가장 중요한 요소입니다. Google은 보안을 가장 중시하며 인터넷을 통해 전송되거나 Google 인프라 내에서 이전되거나 Google 서버에 저장되는 데이터를 포함해 모든 사용자 데이터를 보호하기 위해 끊임없이 노력하고 있습니다.

Google 보안 전략의 핵심은 저장 데이터 및 전송 중인 데이터의 인증, 무결성, 암호화입니다. 이 백서에서는 Google Cloud의 전송 중 암호화에 대한 Google의 접근 방식을 설명합니다.

저장 데이터의 경우 Google Cloud Platform의 저장 데이터 암호화를 참조하세요. 모든 Google 보안에 대한 개요는 Google 인프라 보안 설계 개요를 참조하세요.

대상: 이 문서는 Google Cloud를 사용 중이거나 사용을 고려하고 있는 CISO 및 보안 운영팀을 대상으로 작성되었습니다.

기본 요건: 이 소개 외에도 암호화 및 암호화 기본 요소에 대한 기본적인 지식이 있다고 가정합니다.

인증, 무결성, 암호화

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

인증: 데이터 소스의 사용자 또는 프로세스 및 대상을 확인합니다.
무결성: 전송한 데이터가 변경되지 않고 대상에 도착하는지 확인합니다.
암호화: 전송 중에 데이터를 읽을 수 없게 처리해 비공개로 유지합니다. 데이터 소유자가 승인한 대상만 일반 텍스트에 액세스할 수 있도록 암호화를 통해 판독 가능한 데이터(일반 텍스트)를 알아볼 수 없게(암호문) 만듭니다. 암호화 프로세스에는 공개 알고리즘이 사용되지만 암호문을 복호화하려면 비공개 키가 필요합니다. 전송 중 암호화에서는 주로 타원 곡선 디피-헬만(DH)과 같은 비대칭 키 교환을 사용해 데이터 암호화에 사용되는 공유 대칭 키를 설정합니다. 암호화에 대한 자세한 내용은 현대 암호화 기술 소개를 참조하세요.

암호화를 사용하면 3가지 상태의 데이터를 보호할 수 있습니다.

저장 데이터 암호화는 저장된 데이터를 암호화해 시스템 손상 또는 데이터 무단 반출로부터 보호합니다. 저장 데이터의 암호화에는 주로 AES(Advanced Encryption Standard)가 사용됩니다.
전송 중 암호화: 사이트와 클라우드 제공업체 간 또는 2가지 서비스 간에 데이터가 이전되는 동안 통신 가로채기 시도가 발생하는 경우 데이터를 보호합니다. 전송 전에 데이터를 암호화하고 엔드포인트를 인증하며 도착 시 데이터가 수정되지 않았는지 복호화하고 확인하는 방식으로 보호가 이루어집니다. 예를 들어 전송 계층 보안(TLS)은 전송 보안을 위해 전송 중 데이터를 암호화하는 데 사용되고 Secure/Multipurpose Internet Mail Extensions(S/MIME)는 주로 이메일 메시지 암호화를 위해 사용됩니다.
사용 중 암호화: 처리 중인 데이터를 암호화하여 메모리의 데이터를 손상 또는 데이터 무단 반출을 방지합니다. 자세한 내용은 컨피덴셜 컴퓨팅을 참조하세요.

암호화는 광범위한 보안 전략 요소 중 하나입니다. 전송 중 암호화는 연결이 설정 및 인증된 후 다음과 같이 잠재적 공격으로부터 데이터를 보호합니다.

제3자가 일반적으로 제공하는 네트워크 하위 계층을 신뢰할 필요성을 없앱니다.
잠재적 공격에 대한 노출을 줄입니다.
통신에서 가로채기 시도가 발생하면 공격자의 데이터 액세스를 차단합니다.

적절한 인증, 무결성, 암호화를 통해 사용자, 기기 또는 프로세스 간에 이전되는 데이터를 위험한 환경에서 보호할 수 있습니다. 이 백서의 나머지 부분에서는 전송 중 데이터의 암호화에 대한 Google의 접근 방식과 이러한 접근 방식이 적용되는 상황을 설명합니다.

Google의 네트워크 인프라

물리적 경계

물리적 경계란 Google이나 Google 대리인이 통제하는 물리적 공간을 보호하는 장벽으로서 Google의 엄격한 보안 조치가 적용됩니다. 여기에는 물리적 액세스가 제한되며 철저하게 모니터링됩니다. 소수의 Google 직원만이 하드웨어에 접근할 수 있습니다. 일반적으로 이러한 물리적 경계 내에서 전송 중 데이터는 인증되지만 기본적으로 암호화되지 않을 수 있습니다.

전 세계를 아우르는 인터넷의 규모로 인해 Google의 WAN 광섬유 링크 또는 Google이나 Google 대리인이 통제하는 물리적 경계를 벗어난 모든 곳에 이와 동일한 물리적 보안 제어를 똑같이 적용하기란 불가능합니다. 이 때문에 Google에서는 물리적 신뢰 경계 외부에 추가적인 보호 조치를 자동으로 적용하고 있습니다. 이러한 보호 조치에는 물리적 경계를 벗어나는 모든 트래픽에 대해 전송 중 데이터 암호화가 포함됩니다.

트래픽이 라우팅되는 방식

Google의 전송 중인 데이터 암호화가 어떻게 작동하는지 완전히 이해하려면 인터넷을 통해 트래픽이 라우팅되는 방식부터 이해해야 합니다. 이 섹션에서는 최종 사용자에서 적절한 Google Cloud 서비스 또는 고객 애플리케이션으로 요청이 전달되고 서비스 간에 트래픽이 라우팅되는 방법을 살펴봅니다.

Google Cloud 서비스는 Google이 고객에게 제공하는 모듈형 클라우드 서비스입니다. 컴퓨팅, 데이터 저장, 데이터 분석, 머신러닝 등이 이 서비스에 해당합니다. 예를 들어 Cloud Storage는 Google Cloud 서비스입니다. 고객 애플리케이션은 Google 고객이 Google Cloud 서비스를 사용해 빌드하고 배포할 수 있는, Google Cloud에서 호스팅되는 애플리케이션입니다. Google Cloud에서 호스팅되는 고객 애플리케이션 또는 파트너 솔루션은 Google Cloud 서비스¹로 간주되지 않습니다. 예를 들어 Google App Engine, Google Kubernetes Engine 또는 Google Compute Engine의 VM을 사용해 빌드한 애플리케이션은 고객 애플리케이션입니다.

그림 1에는 아래에 설명된 5가지 라우팅 요청 유형이 나와 있습니다. 이 그림에는 다양한 네트워크 구성요소 간의 상호작용과 각 연결에 적용되는 보안 조치가 나와 있습니다.

최종 사용자(인터넷)-Google Cloud 서비스

Google Cloud 서비스는 Google 프런트엔드(GFE)라는 글로벌 분산 시스템을 통해 전 세계에서 수신되는 요청을 허용합니다. GFE는 들어오는 HTTP(S), TCP, TLS 프록시 트래픽을 종료하고 DDoS 공격을 저지하며 Google Cloud 서비스의 트래픽 라우팅 및 부하 분산을 처리합니다. 유니캐스트 또는 Anycast를 통해 공지된 경로를 사용하는 GFE 접속 지점이 세계 각지에 존재합니다.

GFE는 Google Cloud 서비스로 트래픽을 프록시 처리하고 Google 네트워크 백본을 통해 사용자 요청을 Google Cloud 서비스에 라우팅합니다. 통신이 Google이나 Google 대리인이 통제하는 물리적 경계를 벗어나면 GFE에서 Google Cloud 서비스 또는 고객 애플리케이션의 프런트엔드까지 연결을 인증하고 암호화합니다. 그림 1에서는 이 같은 상호작용(연결 A로 표시)을 보여줍니다.

최종 사용자(인터넷)-Google Cloud에서 호스팅되는 고객 애플리케이션

인터넷에서 수신되는 트래픽을 Google Cloud에서 호스팅되는 고객 애플리케이션으로 라우팅할 수 있는 방법은 다양합니다. 아래 설명과 같이 트래픽이 라우팅되는 방식은 구성에 따라 달라집니다. 그림 1에서는 이 같은 상호작용(연결 B로 표시)을 보여줍니다.

외부 애플리케이션 부하 분산기 또는 외부 프록시 네트워크 부하 분산기(SSL 프록시 사용)를 사용하는 경우 부하 분산기에서 백엔드로의 암호화를 참조하세요.

가상 머신-가상 머신

VPC 네트워크 내의 VM 간 연결과 Google의 프로덕션 네트워크 내의 피어링된 VPC 네트워크가 인증 및 암호화됩니다. 여기에는 고객 VM 간과 고객 VM과 Cloud SQL과 같은 Google 관리 VM 간의 연결이 포함됩니다. 그림 1에서는 이 같은 상호작용(연결 C)을 보여줍니다. 외부 IP 주소를 사용하는 VM 간 연결은 암호화되지 않습니다.

Google API 및 서비스에 연결

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

대부분의 Google API 및 서비스가 Google Front End(GFE)에 호스팅되지만 일부 서비스는 Google 관리 인스턴스에 호스팅됩니다. 예를 들어 비공개 서비스 액세스 및 비공개 클러스터용 GKE 마스터는 Google 관리 인스턴스에 호스팅됩니다.

비공개 Google 액세스를 사용하면 외부 IP 주소가 없는 VM이 App Engine에 호스팅되는 고객 애플리케이션을 비롯한 지원되는 Google API 및 서비스에 액세스할 수 있습니다. Google API 및 서비스 액세스에 대한 자세한 내용은 서비스 비공개 액세스 옵션을 참조하세요.
Compute Engine VM 인스턴스가 또 다른 Compute Engine VM 인스턴스의 외부 IP 주소에 연결되면 트래픽은 Google의 프로덕션 네트워크에서 유지되지만 외부 IP 주소가 사용되므로 암호화되지 않습니다. Google 프로덕션 네트워크 외부에 있고 Compute Engine VM 인스턴스의 외부 IP 주소에 연결되는 시스템은 인터넷을 통해 트래픽을 라우팅합니다.

그림 1에서는 외부 경로(연결 D)를 보여줍니다. 이러한 라우팅 요청의 일반적인 사례는 다음과 같습니다.
- Compute Engine VM-Google Cloud Storage
- Compute Engine VM-Machine Learning API

VM부터 GFE까지 Google Cloud 서비스는 기본적으로 TLS를 사용한 연결을 보호합니다². GFE부터 서비스까지 연결이 인증되고 연결이 물리적 경계에서 벗어나면 암호화됩니다. 이러한 기본 보호 조치 외에도 봉투 암호화를 적용할 수 있습니다. 자세한 내용은 데이터 암호화를 참조하세요.

Google Cloud 서비스-Google Cloud 서비스

프로덕션 서비스 간의 라우팅은 Google 네트워크 백본에서 이루어지며 Google이나 Google 대리인이 통제하는 물리적 경계 외부로 트래픽을 라우팅해야 할 수 있습니다. 그림 1에서는 이 같은 상호작용(연결 E로 표시)을 보여줍니다. Google Cloud Functions를 트리거하는 Google Cloud Storage 이벤트가 이러한 트래픽 유형의 예입니다. 프로덕션 서버 간 연결은 물리적 경계를 벗어나면 암호화되며 물리적 경계 안에서는 인증 처리됩니다.

ALTS 암호화를 사용하여 사용자가 물리적 경계에서 Google Cloud 서비스에 라우팅됩니다.

그림 1: 기본적인 보호 및 VPC 네트워크에서 추가되는 옵션

기본적인 전송 중인 데이터 암호화

Google은 전송 중 데이터에 기본 암호화는 물론 사용자 구성이 가능한 다양한 암호화 방법을 사용합니다. 사용되는 암호화 유형은 OSI 레이어, 서비스 유형, 인프라의 물리적 구성요소에 따라 다릅니다. 아래의 그림 2 및 3은 Google Cloud에서 레이어 3, 4, 7에 적용되는 기본 및 선택적 보호를 보여줍니다.

레이어 3과 4의 암호화 옵션에는 VM 내부에서와 경계를 넘어선 데이터 트래픽이 포함됩니다.

그림 2: Google Cloud의 레이어 3, 4에 적용되는 기본 및 선택적 보호

레이어 7의 암호화 옵션에는 VM 간과 Google 프런트엔드로의 전송 중 데이터를 위한 옵션이 포함됩니다.

그림 3: Google Cloud의 레이어 7에 적용되는 기본 및 선택적 보호 조치³

이 섹션의 나머지 부분에서는 전송 중 데이터를 보호하기 위해 Google이 사용하는 기본적인 보호 조치에 대해 설명합니다.

사용자-Google 프런트엔드 암호화

오늘날 많은 시스템에서 인터넷 통신에 HTTPS를 사용하고 있습니다. HTTPS는 TLS 연결을 통해 요청 및 응답의 신뢰성, 무결성, 보안성을 보장함으로써 보안을 제공합니다. HTTPS 요청을 허용하려면 수신자에게 공개 키/비공개 키 쌍과 인증 기관(CA)에서 발급한 서버 인증용 X.509 인증서가 필요합니다. 키 쌍 및 인증서는 요청을 전달할 도메인 이름이 수신자의 소유임을 입증하여 애플리케이션 레이어(레이어 7)에서 사용자 요청을 보호하도록 도와줍니다. 다음 하위 섹션에서는 사용자와 GFE 간 암호화의 구성요소(TLS, BoringSSL, Google 인증 기관)에 대해 다룹니다. 모든 고객 경로가 GFE를 통해 라우팅되는 것은 아닙니다. GFE는 특히 사용자부터 Google Cloud 서비스까지의 트래픽과 사용자부터 Google Cloud(Google Cloud Load Balancing 사용)에서 호스팅되는 고객 애플리케이션까지의 트래픽에 사용됩니다.

전송 계층 보안(TLS)

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

GFE의 확장 TLS 암호화는 Google과 최종 사용자의 상호작용에 적용될 뿐만 아니라 Google Cloud를 포함해 TLS를 통한 Google과의 API 상호작용도 용이하게 합니다. 또한 TLS 암호화는 Gmail에서 외부 메일 서버와 이메일을 교환하는 데 사용됩니다(자세한 내용은 Gmail의 TLS 요청을 참조하세요).

Google은 TLS 도입과 구현 강화의 업계 선두주자로서 TLS의 많은 보안 기능을 기본적으로 지원하고 있습니다. 일례로 Google은 2011년부터 TLS 구현에 forward secrecy를 사용하고 있습니다. Forward secrecy는 연결을 보호하는 키가 지속되지 않도록 해 공격자가 한 메시지를 가로채 읽어도 이전 메시지는 읽을 수 없게 합니다.

BoringSSL

BoringSSL은 OpenSSL에서 포크된 TLS 프로토콜의 오픈소스 구현으로 Google에서 유지관리하며 OpenSSL과의 인터페이스 호환성이 뛰어납니다. Google은 OpenSSL에서 BoringSSL을 포크하여 내부 용도와 Chromium 및 Android 오픈소스 프로젝트 지원을 위해 OpenSSL을 간소화했습니다. BoringSSL의 핵심인 BoringCrypto는 FIPS 140-2 Level 1 인증을 받았습니다.

GFE의 TLS는 BoringSSL로 구현됩니다. 표 1에서는 클라이언트와 통신할 때 GFE에서 지원하는 암호화 프로토콜을 보여줍니다.

프로토콜	인증	키 교환	암호화	해시 함수
TLS 1.3	RSA 2048	Curve25519	AES-128-GCM	SHA384
TLS 1.2	ECDSA P-256	P-256(NIST secp256r1)	AES-256-GCM	SHA256
TLS 1.1			AES-128-CBC	SHA1⁷
TLS 1.0⁴			AES-256-CBC	MD5⁸
QUIC⁵			ChaCha20-Poly1305
			3DES⁶

표 1: Google Cloud 서비스를 위한 Google 프런트엔드 및 BoringSSL 암호화 라이브러리에서 구현되는 암호화

Google 인증 기관

TLS의 일환으로 연결 요청이 수신된 서버에서는 서버 ID를 사용자에게 입증해야 합니다. 이 같은 ID 확인은 TLS 프로토콜에서 서버가 소유권을 주장한 ID가 포함된 인증서를 제출하도록 요구함으로써 이루어집니다. 인증서에는 서버의 DNS 호스트 이름과 공개 키가 포함되어 있습니다. 제출된 인증서는 연결을 요청한 사용자가 신뢰하는 인증 기관(CA)에 의해 서명됩니다⁹. 결과적으로 서버 연결을 요청하는 사용자는 루트 CA만 신뢰하도록 허용하면 됩니다. 유비쿼터스 방식으로 서버에 액세스해야 하는 경우 루트 CA가 전 세계의 클라이언트 기기에서 확인되어야 합니다. 현재 대부분의 브라우저 및 기타 TLS 클라이언트 구현은 자체 '루트 저장소'에 신뢰할 수 있는 인증서로 구성된 루트 CA 모음을 보유하고 있습니다.

예전부터 Google은 Google 도메인의 인증서 서명에 사용했던 자체 발급 CA를 운영해 왔습니다. 그러나 자체적인 루트 CA는 운영하지 않았습니다. 지금은 DigiCert를 포함해 유비쿼터스 방식으로 분산된 여러 루트 CA와 GlobalSign('GS Root R2' 및 'GS Root R4')에서 이전에 운영한 루트를 통해 Google CA 인증서가 교차 서명됩니다.

2017년 6월, Google은 자체 루트 CA 사용으로의 이전을 발표했습니다. 앞으로 Google 도메인 및 고객의 인증서를 발급할 유비쿼터스 방식으로 분산된 루트 CA를 운영할 계획입니다.

루트 키 마이그레이션 및 키 순환

새로운 루트 CA로 마이그레이션하려면 모든 브라우저와 기기에 인증서의 신뢰성을 삽입해야 하는데 이 과정에서 오랜 시간이 걸리므로 루트 CA 키는 자주 변경되지 않습니다. 따라서 현재 Google에서 자체 루트 CA를 운영하고는 있지만 Google의 자체 마이그레이션 과정에서 기존 기기를 처리하는 과도기 중에는 여러 제3자 루트 CA를 계속하여 사용하게 될 것입니다.

새 루트 CA 키를 만들려면 키 세레모니를 진행해야 합니다. Google에서는 세레모니를 진행할 때 6명의 승인된 직원 중 3명 이상이 실제로 모여야 금고에 보관된 하드웨어 키를 사용할 수 있습니다. 이 직원들은 전자파 장해로부터 보호되는 전용 공간에서 만나 물리적으로 차단된 하드웨어 보안 모듈(HSM)을 사용해 키 및 인증서 모음을 생성합니다. 이 전용 공간은 Google 데이터 센터 내의 안전한 곳에 위치해 있습니다. 물리적 보안 조치, 카메라, 기타 관찰 인력 등의 추가 통제로 절차가 계획대로 진행되도록 보장합니다. 세레모니가 성공적으로 진행되어 생성된 인증서는 발급기관 이름, 공개 키, 서명을 제외하고는 샘플 인증서와 동일합니다. 이렇게 생성된 루트 CA 인증서는 브라우저 및 기기 루트 프로그램에 포함되도록 제출됩니다. 이 절차는 관련된 비공개 키의 공개 범위 및 보안을 충분히 반영해 10년 이상 키를 신뢰할 수 있도록 설계되었습니다.

앞서 설명했듯이 CA에서는 비공개 키를 사용해 인증서를 서명하고 이 인증서로 사용자 세션 중에 TLS 핸드셰이크를 시작할 때 ID를 확인합니다. 서버 인증서는 루트 CA와 유사한 방식으로 생성되는 중개 CA로 서명됩니다. 중개 CA의 인증서는 TLS 세션 중에 배포되므로 새 중개 CA로 마이그레이션하기가 더 쉬워집니다. CA 운영자가 루트 CA 키 자료를 오프라인 상태로 보관할 수 있는 것도 이러한 배포 방법 덕분입니다.

TLS 세션의 보안은 서버의 키를 얼마나 잘 보호하느냐에 달려 있습니다. 키 손상 위험을 완화하기 위해 Google은 TLS 인증서의 수명을 약 3개월로 제한하고 있으며 약 2주마다 인증서를 순환합니다.

서버에 연결한 적이 있는 클라이언트에서는 비공개 티켓 키¹⁰를 사용하여 약식 TLS 핸드셰이크로 이전 세션을 재개할 수 있으므로 이러한 티켓은 공격자에게 매우 취약합니다. Google에서는 티켓 키를 적어도 하루에 한 번 순환하고 3일마다 모든 속성에서 키를 만료합니다. 세션 키 티켓 순환에 관한 자세한 내용은 TLS 약식 암호화의 보안 피해 측정을 참조하세요.

Google 프런트엔드-애플리케이션 프런트엔드

트래픽이 라우팅되는 방식에서 설명했듯이 사용자가 원하는 서비스 및 관련 애플리케이션 프런트엔드가 아닌 다른 물리적 경계 안에 위치한 GFE에 연결되는 경우가 있습니다. 이 경우 사용자 요청 및 기타 레이어 7 프로토콜(예: HTTP)은 TLS로 보호되거나 서비스 간 인증, 무결성, 암호화에서 설명한 애플리케이션 레이어 전송 보안(ALTS)을 사용해 보호되는 RPC로 캡슐화됩니다. 이 같은 RPC는 인증 및 암호화됩니다.

Google Cloud 서비스에서 RPC는 ALTS를 사용하여 보호됩니다. Google Cloud에서 호스팅되는 고객 애플리케이션에서는 트래픽이 Google 프런트엔드를 통해 라우팅되는 경우(예: Google Cloud Load Balancer 사용) 다음 섹션에서 설명된 Google Cloud의 가상 네트워크 암호화를 사용해 VM으로 전달되는 트래픽을 보호합니다.

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

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

Google은 GCM(Galois/Counter Mode)의 AES(Advanced Encryption Standard)와 128비트 키(AES-128-GCM)를 사용해 네트워크 계층에서 암호화를 구현합니다. 통신 호스트 쌍마다 인증 및 암호화된 통신을 위해 ALTS로 보호되는 제어 채널을 통해 세션 키를 설정합니다. 이 세션 키는 호스트 사이의 모든 VM 간 통신을 암호화하는 데 사용되며 주기적으로 순환됩니다.

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

인증 과정에서 보안 토큰은 발신자 및 수신자의 인증 정보가 포함된 터널 헤더에 캡슐화됩니다. 발신자 측의 제어 영역¹¹에서 토큰을 설정하며 수신 호스트에서 토큰 유효성을 검사합니다. 보안 토큰은 모든 흐름에서 사전 생성되며 토큰 키(발신자 정보 포함) 및 호스트 보안 비밀로 구성됩니다. Google이나 Google 대리인이 통제하는 물리적 경계의 모든 소스-수신자 쌍마다 하나의 보안 비밀이 존재합니다.

그림 4에서는 토큰 키, 호스트 보안 비밀, 보안 토큰이 어떻게 생성되는지 보여줍니다.

보안 토큰의 구성요소에는 토큰 키, 호스트 보안 비밀과 그 종속 항목이 포함될 수 있습니다.

그림 4: 보안 토큰

물리적 경계 보안 비밀은 128비트 의사 난수 값이며 이를 바탕으로 HMAC-SHA1을 사용해 호스트 보안 비밀이 파생됩니다. 물리적 경계 보안 비밀은 물리적 경계 한 쌍의 네트워크 제어 영역 간 핸드셰이크를 통해 협상되며 몇 시간마다 다시 협상됩니다. 이러한 입력 및 기타 입력에서 파생된 개별 VM 간 인증에 사용되는 보안 토큰은 지정된 발신자 및 수신자 쌍에 대해 협상된 HMAC입니다.

가상 머신-Google 프런트엔드 암호화

VM-GFE 트래픽은 외부 IP를 사용하여 Google 서비스에 연결되지만 비공개 액세스 기능을 구성하여 요청에 Google 전용 IP 주소를 사용할 수 있습니다.

기본적으로 VM에서 GFE로의 TLS 트래픽이 지원됩니다. 이러한 연결 역시 다른 외부 연결과 동일한 방식으로 이루어집니다. TLS에 대한 자세한 내용은 전송 계층 보안(TLS)을 참조하세요.

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

Google 인프라의 애플리케이션 레이어(레이어 7)에서는 GFE에서 서비스로 전송되거나 서비스 간에 전송되는 Google RPC 호출의 인증, 무결성, 암호화를 위해 애플리케이션 레이어 전송 보안(ALTS)을 사용합니다.

ALTS는 인증에 서비스 계정을 사용합니다. Google 인프라에서 실행되는 각 서비스는 관련 암호화 사용자 인증 정보를 사용한 서비스 계정 ID로 실행됩니다. 다른 서비스에서 RPC를 생성하거나 수신할 경우 각 서비스는 자체 사용자 인증 정보를 사용해 인증합니다. ALTS에서는 내부 인증 기관을 사용해 이 같은 사용자 인증 정보를 확인합니다.

Google이나 Google 대리인이 통제하는 물리적 경계 안에서는 ALTS가 '인증 및 무결성' 모드에서 RPC의 인증 및 무결성을 모두 제공합니다. Google이나 Google 대리인이 통제하는 물리적 경계 밖에 있는 WAN을 통과하는 트래픽의 경우 ALTS가 '인증, 무결성, 보안성' 모드에서 자동으로 인프라 RPC 트래픽에 암호화를 적용합니다. 현재 Google Cloud 서비스를 포함한 Google 서비스에 전달되는 모든 트래픽에 이 같은 보호가 적용됩니다.

Google 프런트엔드에서 애플리케이션 프런트엔드로 이동하는 트래픽의 인프라 RPC 메커니즘에서 ALTS는 HTTP와 같은 다른 레이어 7 프로토콜의 캡슐화에도 사용됩니다. 이 같은 보호를 통해 애플리케이션 레이어를 격리하고 네트워크 경로의 보안에서 모든 종속 항목을 삭제합니다.

보안 인프라 서비스는 Google이나 Google 대리인이 통제하는 물리적 경계 내에서도 '인증, 무결성, 개인 정보 보호' 모드의 ALTS 통신만 허용하고 전송합니다. Google 인프라에 저장된 데이터를 보호하는 데 사용되는 암호화 키를 저장하고 관리하는 키 저장소가 이 예시에 해당됩니다.

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

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

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

PSP 사용 방법에 대한 자세한 내용은 오픈소스가 된 대규모 PSP의 암호화 하드웨어 오프로드 발표를 참조하세요.

ALTS 프로토콜

ALTS는 상호 TLS와 유사한 보안 핸드셰이크 프로토콜을 사용합니다. ALTS를 사용해 통신하고자 하는 두 서비스는 민감한 정보를 전송하기 전에 이 핸드셰이크 프로토콜을 사용하여 통신 매개변수를 인증하고 협상합니다. 이 프로토콜은 두 단계로 이루어집니다.

1단계: 핸드셰이크 클라이언트에서 Curve25519를 사용해 서버와의 타원 곡선 디피-헬만(ECDH) 핸드셰이크를 시작합니다. 클라이언트 및 서버는 각각 디피-헬만 키 교환 중에 사용되는 인증서의 일부로 인증된 ECDH 공개 매개변수를 가집니다. 핸드셰이크로 클라이언트 및 서버에서 사용할 수 있는 공통의 트래픽 키가 생성됩니다. 승인 결정에 사용할 인증서의 피어 ID가 애플리케이션 레이어에 표시됩니다.
2단계: 암호화 기록 1단계에서 생성된 공통 트래픽 키를 사용해 클라이언트에서 서버로 데이터를 안전하게 전송합니다. ALTS의 암호화는 BoringSSL 및 기타 암호화 라이브러리를 사용해 구현됩니다. 암호화는 AES-128-GCM이 가장 일반적으로 사용되며 무결성은 AES-GCM의 GMAC를 통해 제공됩니다.

다음 다이어그램은 ALTS 핸드셰이크를 자세히 보여줍니다. 최신 구현에서는 프로세스 도우미가 핸드셰이크를 수행하지만 애플리케이션에서 직접 수행되는 경우도 있습니다.

클라이언트 앱은 프로세스 도우미를 통해 핸드셰이크 서비스와, 키 교환을 통해 서버 앱과 각각 상호작용합니다.

그림 5: ALTS 핸드셰이크

서비스 간 인증, 무결성, 암호화 섹션 앞부분에서 설명했듯이 ALTS에서는 인증에 서비스 계정을 사용하며 Google 인프라에서 실행되는 각 서비스는 관련 암호화 사용자 인증 정보를 사용한 서비스 ID로 실행됩니다. ALTS 핸드셰이크가 진행되는 동안 프로세스 도우미가 각 클라이언트-서버 쌍이 통신에 사용하는 비공개 키와 해당 인증서에 액세스합니다. 비공개 키 및 해당 인증서(서명된 프로토콜 버퍼)는 서비스의 서비스 계정 ID에 프로비저닝됩니다.

ALTS 인증서 ALTS 인증서에는 여러 가지 종류가 있습니다.

머신 인증서: 특정 머신의 핵심 서비스에 ID를 제공합니다. 약 6시간마다 순환됩니다.
사용자 인증서: 코드 개발 업무를 담당하는 Google 엔지니어를 위한 최종 사용자 ID를 제공합니다. 약 20시간마다 순환됩니다.
Borg 작업 인증서: Google 인프라 내에서 실행되는 작업에 ID를 제공합니다. 약 48시간마다 순환됩니다.

루트 인증서 서명 키는 Google의 외부 CA와 무관하며 독립적인 Google 내부 인증 기관(CA)에 저장됩니다.

ALTS의 암호화

ALTS의 암호화는 사용되는 머신에 따라 다양한 알고리즘을 사용해 구현할 수 있습니다. 예를 들어 대부분의 서비스에서는 AES-128-GCM¹²을 사용합니다. ALTS 암호화에 대한 자세한 내용은 표 2를 참조하세요.

머신	사용되는 메시지 암호화
가장 일반적	AES-128-GCM
Sandy Bridge 이전	AES-128-VCM	GMAC 대신 VMAC를 사용하며, 이 같은 이전 시스템에서 사용 시 좀 더 효율적입니다.

표 2: ALTS의 암호화

대부분의 Google 서비스는 ALTS 또는 ALTS를 사용하는 RPC 캡슐화를 사용합니다. ALTS가 사용되지 않는 경우에는 다른 보호 조치가 사용됩니다. 예를 들면 다음과 같습니다.

일부 하위 수준 머신 관리 및 부트스트랩 서비스의 경우 SSH 사용
일부 하위 수준 인프라 로깅 서비스 TLS 또는 Datagram TLS(DTLS)¹³
TCP 외의 전송을 사용하는 일부 서비스는 Google이나 Google 대리인이 통제하는 물리적 경계 안에 있을 경우 다른 암호화 프로토콜 또는 네트워크 수준의 보호 사용

VM 및 Google Cloud Platform 서비스 간 통신에서는 ALTS가 아닌 TLS를 사용해 Google 프런트엔드와 통신합니다. 이러한 통신에 대한 설명은 가상 머신-Google 프런트엔드 암호화를 참조하세요.

전송 중인 데이터 암호화의 다른 옵션 구성

Google Cloud와 데이터 센터 간에 또는 Google Cloud와 사용자 기기에서 호스팅되는 애플리케이션 간에 전송되는 데이터에 대한 보호를 구성할 수 있습니다.

데이터 센터를 Google Cloud에 연결할 경우 다음을 고려하세요.

외부 애플리케이션 부하 분산기 또는 외부 프록시 네트워크 부하 분산기 중 하나와 함께 TLS를 사용하여 클라우드 서비스에 연결합니다. GFE는 고객이 프로비저닝 및 제어하는 SSL 인증서를 사용해 사용자의 TLS 연결을 종료합니다. 인증서 맞춤설정에 대한 자세한 내용은 SSL 인증서 개요를 참조하세요.
Cloud VPN을 사용하여 IPSec 터널을 만들거나 Cloud Interconnect를 사용하여 온프레미스 네트워크를 Virtual Private Cloud 네트워크에 안전하게 연결합니다. 자세한 내용은 네트워크 연결 제품 선택을 참조하세요.
Cloud Interconnect용 MACsec를 사용하면 온프레미스 라우터와 Google의 에지 라우터 사이의 트래픽을 보호할 수 있습니다. 자세한 내용은 Cloud Interconnect용 MACsec 개요를 참조하세요.

사용자 기기를 Google Cloud에서 실행되는 애플리케이션에 연결할 경우 다음을 고려하세요.

사용하는 SSL 인증서를 구성해 GFE의 TLS 지원을 사용합니다. 예를 들어 애플리케이션에서 TLS 세션을 종료할 수 있습니다.
Firebase 호스팅 및 App Engine 커스텀 도메인 모두에 사용할 수 있는 무료 자동화 SSL 인증서를 사용하는 것이 좋습니다. App Engine 커스텀 도메인을 사용하면 자체 SSL 인증서를 제공하고 HTTP Strict Transport Security(HSTS) 헤더를 사용할 수도 있습니다.
GKE 및 Compute Engine 워크로드의 경우 인증에 mTLS를 사용할 수 있도록 GKE Enterprise 서비스 메시를 사용하는 것이 좋습니다. 그러면 모든 TCP 통신이 전송 중에 암호화됩니다.

Google Workspace를 사용하는 경우 발신 이메일에 S/MIME를 사용 설정하도록 Gmail을 구성하고 콘텐츠 및 첨부파일 규정 준수에 대한 정책을 설정하며 수신 및 발신 이메일에 대한 라우팅 규칙을 만듭니다.

전송 중인 데이터 암호화 연구 및 혁신

Google은 수년 간 인터넷에서 전송 중인 데이터 암호화를 사용하도록 독려하는 여러 오픈소스 프로젝트를 진행하는 등 다양한 노력을 기울이고 있습니다.

이러한 노력에는 다음이 포함됩니다.

인증서 투명성(CT)은 CA에서 승인되지 않았거나 잘못된 인증서를 발급했는지 감지할 수 있는 방법을 사이트 운영자와 도메인 소유자에게 제공하기 위한 Google의 노력입니다.
Google은 매년 HTTPS 투명성 보고서를 통해 Google Cloud를 포함한 모든 Google 속성에 전송 중인 데이터 암호화 100% 달성 목표 진행상황을 추적하고 있습니다.
양자 컴퓨터 공격으로부터 TLS 연결을 보호하기 위한 결합 타원 곡선 및 포스트 퀀텀(CECPQ2) 알고리즘 개발입니다.

최근 Google 기여에 대한 자세한 내용은 보안 연구 커뮤니티와의 공동작업을 참조하세요.

다음 단계

보안 권장사항을 포함하여 Google Cloud 보안에 대한 일반적인 정보는 Google Cloud 웹사이트의 보안 섹션을 참조하세요.
Google Cloud 규정 준수 및 규정 준수 인증에 대한 자세한 내용은 Google의 공개 SOC3 감사 보고서가 포함된 Google Cloud 웹사이트의 규정 준수 섹션을 참조하세요.
전송 중 데이터를 보호하는 방법에 대한 권장사항은 엔터프라이즈 기반 청사진, Google Cloud 아키텍처 프레임워크: 보안, 개인 정보 보호, 규정 준수, 전송 중 데이터 암호화에 대한 규제 요건을 충족하는 방법 결정을 참조세요.

각주

¹ 파트너 솔루션에는 Cloud Launcher에서 제공하는 솔루션과 Cloud Dataprep과 같이 파트너와 공동으로 빌드한 제품이 모두 포함됩니다.

² Google Cloud Storage 버킷에 대한 HTTP 액세스 등의 경우 암호화를 여전히 사용 중지할 수 있습니다.

³ 레이어 7에서 보호되지 않는 VM과 서비스 간의 통신은 레이어 3 및 4에서 계속 보호됩니다.

⁴ Google은 여전히 이 버전의 프로토콜을 사용하는 브라우저를 위해 TLS 1.0을 지원합니다. 참고로 결제 카드 산업(PCI) 규정의 지원 중단 요청에 따라 2018년 7월부터 신용카드 정보를 처리하는 모든 Google 사이트에서 더 이상 TLS 1.0을 지원하지 않습니다.

⁵ QUIC에 관한 자세한 내용은 https://www.chromium.org/quic를 참조하세요.

^{6, 7, 8} 일부 기존 운영체제와의 하위 호환성을 위해 3DES, SHA1, MD5를 지원합니다.

⁹ 연결 인증서의 경우 CA 신뢰가 타동적으로 이루어집니다.

¹⁰ 세션 티켓 RFC 5077 또는 세션 ID RFC 5246일 수 있습니다.

¹¹ 제어 영역은 신호 트래픽을 옮기고 라우팅을 담당하는 네트워크의 일부입니다.

¹² 이전에는 다른 프로토콜을 사용했지만 지금은 지원 중단되었습니다. 이전 프로토콜을 사용하는 작업은 1%가 채 안 됩니다.

¹³ Datagram TLS(DTLS)는 도청 및 조작을 방지하면서 통신할 수 있도록 데이터그램 기반 애플리케이션의 보안을 제공합니다.