이 문서에서는 에어 갭이 적용된 Google Distributed Cloud (GDC) 암호화 전송에 대해 자세히 설명합니다.
CIO 수준 요약
- GDC는 전송 중인 데이터의 신뢰성, 무결성, 기밀성을 보장하기 위해 다양한 보안책을 강구하고 있습니다.
- GDC는 연결되는 방식에 따라 GDC 구성요소의 전송 중 데이터에 기본 보호를 적용합니다. 예를 들어 사용자와 GDC Cloud Service Mesh 인그레스 게이트웨이 간의 통신은 TLS를 사용하여 보호합니다.
소개
보안은 클라우드 제공업체 선정 시 가장 중요한 요소입니다. Google은 보안을 가장 중시하며 네트워크를 통해 전송되거나, Google 인프라 내에서 이동되거나, Google 서버에 저장되는 데이터를 포함해 모든 사용자 데이터를 보호하기 위해 끊임없이 노력하고 있습니다.
Google의 보안 전략은 저장 데이터 및 전송 중 데이터의 인증, 무결성, 암호화에 주력하는 것입니다. 이 백서에서는 Google Distributed Cloud air-gapped (GDC)의 전송 중 암호화에 대한 Google의 접근 방식을 설명합니다.
저장 데이터의 경우 저장 데이터 암호화를 참고하세요. 모든 Google 보안에 대한 개요는 Google 인프라 보안 설계 개요를 참조하세요.
대상: 이 문서는 GDC를 사용 중이거나 사용을 고려하고 있는 CISO 및 보안 운영팀을 대상으로 작성되었습니다.
기본 요건: 이 소개 외에도 암호화 및 암호화 기본 요소에 대한 기본적인 지식이 있다고 가정합니다.
인증, 무결성, 암호화
GDC는 전송 중인 데이터의 신뢰성, 무결성, 기밀성을 보장하기 위해 다양한 보안책을 강구하고 있습니다.
- 인증: 네트워크 레이어에서 데이터의 대상을 인증합니다. 소스는 GDC 관리 AIS에 의해 인증됩니다.
- 무결성: 전송한 데이터가 변경되지 않고 대상에 도착하는지, 즉 무단 변경으로부터 보호되는지 확인합니다.
- 암호화: 전송 중에 데이터를 읽을 수 없게 처리해 기밀로 유지합니다. 암호화는 데이터 소유자가 승인한 대상만 일반 텍스트에 액세스할 수 있도록 암호화를 통해 판독 가능한 데이터 (일반 텍스트)를 알아볼 수 없게 만듭니다 (암호문). 암호화 프로세스에는 공개 알고리즘이 사용되지만 암호문을 복호화하려면 비공개 키가 필요합니다. 전송 중 암호화에서는 주로 타원 곡선 기반 디피-헬만과 같은 비대칭 키 교환을 사용해 데이터 암호화에 사용되는 공유 대칭 키를 설정합니다. 암호화에 대한 자세한 내용은 현대 암호화 기술 소개를 참고하세요.
암호화를 사용하면 여러 상태의 데이터를 보호할 수 있습니다.
- 저장 데이터 암호화는 저장된 데이터를 암호화해 시스템 손상 또는 데이터 유출로부터 데이터를 보호합니다. 저장 데이터의 암호화에는 주로 AES (Advanced Encryption Standard)가 사용됩니다.
- 전송 중인 데이터 암호화: 사이트와 클라우드 제공업체 간 또는 두 서비스 간에 데이터가 이동하는 동안 통신에 가로채기 시도가 발생하는 경우 데이터를 보호합니다. 전송 전에 데이터를 암호화하고 엔드포인트를 인증하며 도착 시 데이터가 수정되지 않았는지 복호화하고 확인하는 방식으로 보호가 이루어집니다. 예를 들어 전송 계층 보안 (TLS)은 전송 보안을 위해 전송 중인 데이터를 암호화하는 데 사용되고 S/MIME (Secure/Multipurpose Internet Mail Extensions)는 이메일 메시지 암호화를 위해 주로 사용됩니다.
암호화는 광범위한 보안 전략 요소 중 하나입니다. 전송 중 암호화는 연결이 설정 및 인증된 후 다음과 같이 잠재적 공격으로부터 데이터를 보호합니다.
- 제3자가 일반적으로 제공하는 네트워크 하위 계층을 신뢰할 필요성을 없앱니다.
- 잠재적 공격 표면을 줄입니다.
- 통신에서 가로채기 시도가 발생하면 공격자의 데이터 액세스를 차단합니다.
적절한 인증, 무결성, 암호화를 통해 사용자, 기기 또는 프로세스 간에 이동하는 데이터를 위험한 환경에서 보호할 수 있습니다. 이 백서의 나머지 부분에서는 전송 중인 데이터의 암호화에 대한 GDC의 접근 방식과 이러한 접근 방식이 적용되는 상황에 대해 설명합니다.
GDC 네트워크 인프라
물리적 경계
물리적 경계란 Google이 통제하거나 Google과 협력하여 통제하는 물리적 공간을 보호하는 장벽으로서, Google의 엄격한 보안 조치가 적용됩니다. 이러한 위치에 대한 물리적 액세스는 제한되며 철저하게 모니터링되고 감사됩니다. 승인된 소수의 직원만이 하드웨어에 액세스할 수 있습니다. 이러한 물리적 경계 내에서 전송 중인 데이터는 일반적으로 인증되고 암호화됩니다.
GDC의 물리적 경계를 넘나드는 통신에는 강력한 인증 및 암호화가 적용되어 전송 중인 데이터를 보호합니다.
트래픽이 라우팅되는 방식
GDC에서 전송 중인 데이터 암호화가 작동하는 방식을 이해하려면 트래픽이 GDC로 라우팅되는 방식과 GDC를 통해 라우팅되는 방식을 설명해야 합니다. 이 섹션에서는 요청이 최종 사용자에서 적절한 GDC 서비스 또는 고객 애플리케이션으로 전달되고 트래픽이 교차 사이트 서비스 간에 라우팅되는 방법을 설명합니다.
GDC 관리 서비스는 모듈형 프라이빗 클라우드 서비스입니다. 이러한 서비스에는 컴퓨팅, 스토리지, 머신러닝이 포함됩니다. 예를 들어 GDC 객체 스토리지는 GDC 관리형 서비스입니다. 고객 애플리케이션은 GDC 고객이 GDC 서비스를 사용해 빌드하고 배포할 수 있는 GDC 호스팅 애플리케이션입니다. GDC에서 호스팅되는 고객 애플리케이션 또는 파트너 솔루션은 GDC 관리 서비스로 간주되지 않습니다. 예를 들어 GDC VM, 데이터베이스 서비스, Vertex AI를 사용하여 빌드한 애플리케이션은 고객 애플리케이션입니다.
그림 1에는 다양한 라우팅 요청이 나와 있습니다. 그림 1에는 다양한 네트워크 구성요소 간의 상호작용과 각 연결에 적용되는 보안 조치가 나와 있습니다.
그림 1: 사이트 간 연결 인프라
최종 사용자 (고객 네트워크)에서 GDC API 및 관리 서비스로
Cloud Service Mesh 인그레스 게이트웨이에서 호스팅되는 관리 서비스의 경우 Cloud Service Mesh 인그레스 게이트웨이를 사용하여 고객 네트워크의 요청을 수락합니다. Cloud Service Mesh 인그레스 게이트웨이는 들어오는 HTTP(S)의 트래픽을 프록시하고 GDC 관리 서비스 자체로 트래픽을 라우팅하고 부하를 분산합니다. 또 다른 방화벽 레이어는 침입 감지 및 방지를 통해 DDoS 공격 대책을 제공합니다. 이 연결은 Cloud Service Mesh 인그레스 게이트웨이에서 GDC 관리 서비스의 프런트엔드까지 인증되고 암호화됩니다. 그림 1에서는 이 상호작용을 연결 A로 보여줍니다.
대부분의 GDC API 및 관리 서비스는 Cloud Service Mesh 인그레스 게이트웨이에서 호스팅됩니다. 하지만 일부 서비스는 GDC 관리형 레이어 4 부하 분산기에 직접 호스팅됩니다. 예를 들어 DBS 데이터베이스는 GDC 외부 부하 분산기에서 호스팅됩니다. 이러한 서비스는 TLS를 사용하여 애플리케이션 레이어에서 연결을 인증하고 암호화하도록 구성됩니다. 그림 1에서는 이 상호작용을 연결 B로 보여줍니다.
최종 사용자 (고객 네트워크)에서 GDC에 호스팅된 고객 애플리케이션
고객 네트워크에서 GDC에서 호스팅되는 고객 애플리케이션으로 트래픽을 라우팅하는 방법에는 여러 가지가 있습니다. 트래픽이 라우팅되는 방식은 구성에 따라 달라집니다.
고객 API 게이트웨이를 통해 고객 애플리케이션 노출
GDC는 고객 API 게이트웨이를 통해 고객 애플리케이션을 노출하는 것을 지원합니다. 고객 API 게이트웨이 서비스를 통해 사용자는 필요에 따라 API를 개발, 배포, 보호, 관리, 확장할 수 있습니다. 그림 1에서는 이 상호작용을 연결 C로 보여줍니다.
고객 외부 부하 분산기를 통해 컨테이너화된 고객 워크로드 노출
GDC는 고객이 관리하는 컨테이너화된 워크로드를 외부 부하 분산기를 통해 노출하는 것을 지원합니다. GDC는 해당 담당자에게 인그레스 및 이그레스 정책을 구성할 수 있는 기능을 제공합니다. 그림 1에서는 이 상호작용을 연결 E로 보여줍니다.
가상 머신 워크로드 노출
GDC는 고객이 만든 가상 머신을 최종 사용자에게 노출하는 것을 지원합니다. GDC는 해당 담당자에게 인그레스 및 이그레스 정책을 구성할 수 있는 기능을 제공합니다. 그림 1에서는 이 상호작용을 연결 F로 보여줍니다.
GDC 교차 사이트 Interconnect 서비스
관리 서비스 간의 라우팅은 일반적으로 GDC의 물리적 경계 내에서 완전히 이루어집니다. 크로스 사이트 백업과 같은 경우 데이터가 GDC의 물리적 경계 외부로 라우팅됩니다. 이 경우 데이터는 애플리케이션 레이어(예: TLS)에서 암호화되며 네트워크 레이어에서도 암호화될 수 있습니다. 그림 1에서는 이 상호작용을 연결 G로 보여줍니다.
가상 머신-가상 머신
GDC 내의 VM 간 연결은 네트워크 수준에서 암호화되지 않습니다. 고객은 적절한 암호화 프로토콜 또는 IPSec 터널과 같은 특정 기술을 사용하여 데이터를 암호화할 책임이 있습니다.
기본적으로 전송 중 암호화
GDC는 전송 중인 데이터에 기본 암호화는 물론 사용자 구성이 가능한 다양한 암호화 방법을 사용합니다. 사용되는 암호화 유형은 OSI 레이어, 서비스 유형, 인프라의 물리적 구성요소에 따라 다릅니다. 이 섹션에서는 Google이 전송 중인 데이터를 보호하기 위해 사용하는 기본적인 보호 조치에 대해 설명합니다.
이 섹션의 나머지 부분에서는 Google이 전송 중인 데이터를 보호하기 위해 사용하는 기본적인 보호 조치에 대해 설명합니다.
사용자-Cloud Service Mesh 인그레스 게이트웨이 암호화
오늘날 많은 시스템에서 인터넷 통신에 HTTPS를 사용하고 있습니다. HTTPS는 TLS 연결을 사용하여 요청 및 응답의 신뢰성, 무결성, 기밀성을 보장함으로써 보안을 제공합니다. HTTPS 요청을 허용하려면 수신자에게 공개 키–비공개 키 쌍과 인증 기관 (CA)의 서버 인증용 X.509 인증서가 필요합니다. 키 쌍 및 인증서는 요청을 전달할 도메인 이름이 수신자의 소유임을 입증하여 애플리케이션 레이어 (레이어 7)에서 사용자 요청을 인증하도록 도와줍니다. 다음 하위 섹션에서는 사용자-Cloud Service Mesh 인그레스 게이트웨이 암호화의 구성요소(TLS, BoringSSL, GDC 구성 가능한 인증 기관)에 대해 다룹니다.
전송 계층 보안 (TLS)
사용자가 GDC 서비스에 요청을 전송하면 Google에서는 신뢰할 수 있는 인증 기관의 인증서와 함께 HTTPS를 사용해 인증, 무결성, 암호화를 제공하여 전송 중인 데이터를 안전하게 보호합니다. 사용자가 GDC 관리 서비스의 Cloud Service Mesh 인그레스 게이트웨이에 전송하는 모든 데이터는 전송 계층 보안 (TLS)을 통해 전송 중에 암호화됩니다. Cloud Service Mesh 인그레스 게이트웨이는 클라이언트에서 지원할 수 있는 항목에 따라 특정 암호화 프로토콜을 클라이언트와 협상합니다. GDC Cloud Service Mesh 인그레스 게이트웨이는 더 강력한 보안을 제공하기 위해 FIPS 승인 알고리즘만 적용합니다.
BoringSSL
BoringSSL은 OpenSSL에서 포크된 TLS 프로토콜의 오픈소스 구현으로 Google에서 유지관리하며 OpenSSL과의 인터페이스 호환성이 뛰어납니다. Google은 OpenSSL에서 BoringSSL을 포크하여 내부 용도와 Chromium 및 Android 오픈소스 프로젝트 지원을 위해 OpenSSL을 간소화했습니다. BoringSSL의 핵심인 BoringCrypto는 FIPS 140-2 Level 1 인증을 받았습니다.
Cloud Service Mesh 인그레스 게이트웨이의 TLS는 BoringSSL로 구현됩니다. 표 1에서는 클라이언트와 통신할 때 GDC에서 지원하는 암호화 프로토콜을 보여줍니다.
| 프로토콜 | 인증 | 키 교환 | 암호화 | 해시 함수 |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256(NIST secp256r1) | AES-256-GCM | SHA256 |
표 1: GDC 서비스를 위한 Cloud Service Mesh 인그레스 게이트웨이 및 BoringSSL 암호화 라이브러리에서 구현되는 암호화
GDC 구성 가능한 인증 기관
TLS의 일환으로 연결 요청이 수신된 서버에서는 서버 ID를 사용자에게 입증해야 합니다. 이 같은 ID 확인은 TLS 프로토콜에서 서버가 소유권을 주장한 ID가 포함된 인증서를 제출하도록 요구함으로써 이루어집니다. 인증서에는 서버의 DNS 호스트 이름과 공개 키가 포함되어 있습니다. 제출된 인증서는 연결을 요청한 사용자가 신뢰하는 인증 기관 (CA)으로 서명됩니다. 결과적으로 서버 연결을 요청하는 사용자는 루트 CA만 신뢰하도록 허용하면 됩니다. 유비쿼터스 방식으로 서버에 액세스해야 하는 경우 루트 CA가 모든 잠재적 클라이언트 기기에서 확인되어야 합니다. 클라이언트 브라우저와 기기는 클라이언트가 작동하는 환경에 따라 신뢰하는 루트 CA 집합으로 구성됩니다.
GDC의 루트 CA는 배포된 환경과 해당 환경의 고객 요구사항에 따라 달라집니다.
Cloud Service Mesh 인그레스 게이트웨이에서 애플리케이션 프런트엔드로
두 가지 사례:
- Cloud Service Mesh 인그레스 게이트웨이는 TLS를 종료하고 Cloud Service Mesh Istio 인증서를 사용하여 mTLS를 다시 암호화합니다.
- 인그레스 게이트웨이에서 Istio 사이드카 애플리케이션 프런트엔드로의 mTLS
- Cloud Service Mesh 인그레스 게이트웨이는 TLS를 종료하고 구성된 CA를 사용하여 TLS를 다른 서버로 다시 암호화합니다.
스토리지 트래픽의 네트워크 암호화
GDC 파일 및 블록 스토리지 시스템에서 트래픽은 스토리지를 사용하는 애플리케이션과 스토리지 서비스 간에 라우팅됩니다. 해당 데이터는 IPSec를 사용하여 전송 중에 인증되고 암호화됩니다. 스토리지 트래픽에 대한 클라이언트 측 암호화가 곧 제공될 예정입니다. 스토리지에 액세스해야 하는 호스트에 파일과 블록 트래픽 간에 IPSec 전송 모드가 사용됩니다. 인증은 이동 중에 생성되고 GDC에 안전하게 저장되는 사전 공유 키를 통해 이루어집니다. IPSec SA가 설정되면 IPSec 터널을 사용하여 정보가 교환됩니다. 패킷은 IPSec SA에 지정된 FIPS 규격 암호화 암호를 사용하여 암호화 및 복호화됩니다.
서비스 간 인증, 무결성, 암호화
GDC 인프라의 애플리케이션 레이어 (레이어 7)에서는 Cloud Service Mesh 인그레스 게이트웨이에서 서비스로 전송되거나 한 GDC 서비스에서 다른 GDC 서비스로 전송되는 RPC 호출의 인증, 무결성, 암호화를 위해 mTLS 또는 TLS를 사용합니다. GDC에서 실행되는 각 서비스는 연결된 암호화 사용자 인증 정보를 사용한 서비스 계정 ID로 실행됩니다. Cloud Service Mesh를 통해 mTLS로 통신할 때 GDC 서비스는 클라이언트 인증서를 사용하여 다른 서비스에 인증합니다. Cloud Service Mesh는 내부 인증 기관을 사용하여 이러한 인증서를 확인합니다. TLS를 통해 통신하는 경우(예: GDC Kubernetes API 서버) GDC 서비스는 Kubernetes 서비스 계정 토큰을 사용하여 서비스에 인증합니다. Kubernetes 서비스 계정 토큰은 Kubernetes API 서버 토큰 발급자의 공개 키를 사용하여 확인됩니다.