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

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

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

이 백서에 포함된 콘텐츠는 2017년 12월 기준으로 작성되었으며 따라서 백서 작성 당시의 상황을 나타냅니다. Google이 지속적으로 고객 보호를 개선함에 따라 Google Cloud의 보안 정책 및 시스템은 향후 변경될 수 있습니다.

재생 버튼

Google Cloud 전송 중 암호화

CIO 수준 요약

  • Google은 전송 중인 데이터의 신뢰성, 무결성, 보안성을 보장하기 위해 다양한 보안책을 강구하고 있습니다.
  • 이 백서에서 다루는 사용 사례에서는 데이터가 Google 또는 Google의 대리인이 통제하지 않는 물리적 경계 외부로 이동할 때 Google이 하나 이상의 네트워크 레이어에서 전송 중인 데이터를 암호화하고 인증합니다. Google 또는 Google 대리인이 통제하는 물리적 경계 내에서는 전송 중인 데이터가 일반적으로 인증되지만 반드시 암호화되는 것은 아닙니다.
  • 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)은 전송 보안을 위해 전송 중 데이터를 암호화하는 데 사용되고 S/MIME(Secure/Multipurpose Internet Mail Extensions)는 주로 이메일 메시지 보안을 위해 사용됩니다.
  • 사용 중 암호화: 서버에서 컴퓨팅 실행을 위해 사용 중인 데이터를 보호합니다(예: 동형 암호화).

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

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

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

Google의 네트워크 인프라

Virtual Private Cloud 네트워크의 물리적 경계

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

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

트래픽이 라우팅되는 방식

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

Google Cloud 서비스는 Google이 고객에게 제공하는 모듈 형식의 클라우드 서비스입니다. 컴퓨팅, 데이터 저장, 데이터 분석, 머신러닝 등이 이 서비스에 해당하며 Google Cloud Storage 및 Gmail 모두 Google Cloud 서비스의 예입니다. 고객 애플리케이션은 Google 고객이 Google Cloud 서비스를 사용해 빌드하고 배포할 수 있는, Google Cloud에서 호스팅되는 애플리케이션입니다. Google Cloud에서 호스팅되는 고객 애플리케이션 또는 파트너 솔루션은 Google Cloud 서비스1로 간주되지 않습니다. 예를 들어 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)을 보여줍니다.

Google Cloud HTTP(S) 또는 TCP/SSL 프록시 부하 분산기, 외부 부하 분산기 사용

HTTP(S) 부하 분산, TCP 프록시 부하 분산, SSL 프록시 부하 분산의 경우 Google은 Google Cloud 내에서 Google 프런트엔드(GFE)와 백엔드 간의 트래픽을 자동으로 암호화합니다.

네트워크 수준의 암호화와 더불어 보안 프로토콜을 백엔드 서비스 프로토콜로 사용할 수 있습니다. 보안 프로토콜에는 SSL, HTTPS, HTTP/2(TLS 사용)가 포함되며 GFE 기반 부하 분산기, 내부 HTTP(S) 부하 분산, Traffic Director에 이러한 보안 프로토콜을 사용할 수 있습니다.

부하 분산기가 보안 백엔드 서비스 프로토콜을 사용하여 백엔드에 연결될 때 GFE는 SSL 또는 HTTPS 클라이언트입니다. 마찬가지로 Traffic Director를 사용하여 구성된 클라이언트 측 프록시가 보안 백엔드 서비스 프로토콜을 사용하여 백엔드에 연결될 때 프록시는 SSL 또는 HTTPS 클라이언트입니다.

다음과 같은 경우 백엔드 인스턴스에 연결하기 위한 보안 프로토콜이 권장됩니다.

  • 부하 분산기(또는 Traffic Director)에서 백엔드 인스턴스로 감사 가능하고 암호화된 연결이 필요한 경우

  • 부하 분산기가 인터넷 NEG를 통해 Google Cloud 외부에 있는 백엔드 인스턴스에 연결하는 경우. 인터넷 NEG 백엔드와의 통신은 공개 인터넷을 통해 전송할 수 있습니다. 부하 분산기가 인터넷 NEG에 연결될 때 공개 CA 서명 인증서는 유효성 검사 요구사항을 충족해야 합니다.

부하 분산기와 백엔드 간에 보안 프로토콜을 사용하려면 다음 요구사항에 유의하세요.

  • 부하 분산기의 백엔드 서비스는 SSL(TLS), HTTPS 또는 HTTP/2 프로토콜을 사용해야 합니다.

  • 백엔드 인스턴스 소프트웨어는 백엔드 서비스와 동일한 프로토콜을 사용하여 트래픽을 처리해야 합니다. 예를 들어 백엔드 서비스가 HTTPS를 사용하는 경우 HTTPS를 사용하도록 백엔드 인스턴스를 구성해야 합니다. HTTP/2 프로토콜을 사용하는 경우 백엔드는 TLS를 사용해야 합니다. 구성 안내는 백엔드 인스턴스의 소프트웨어 문서를 참조하세요.

  • 백엔드 인스턴스에 비공개 키와 인증서를 설치해야 합니다. 이러한 인증서는 부하 분산기의 SSL 인증서와 일치하지 않아도 됩니다. 설치 안내는 백엔드 인스턴스의 소프트웨어 문서를 참조하세요.

  • 백엔드 인스턴스에서 실행 중인 소프트웨어는 SSL 또는 HTTPS 서버로 작동해야 합니다. 구성 안내는 백엔드 인스턴스의 소프트웨어 문서를 참조하세요.

인스턴스 그룹 또는 영역별 NEG 백엔드를 사용할 때는 다음 사항에 유의하세요.

  • GFE가 백엔드에 대한 TLS 세션을 시작하면 GFE는 서버 이름 표시(SNI) 확장 프로그램을 사용하지 않습니다.

  • GFE가 Google Cloud 내의 백엔드에 연결될 때 GFE는 백엔드에서 제시하는 모든 인증서를 수락합니다. GFE는 인증서 유효성 검사를 수행하지 않습니다. 예를 들어 다음 상황에서도 인증서가 유효한 것으로 간주됩니다.

    • 인증서가 자체 서명됩니다.
    • 인증서가 알 수 없는 인증 기관(CA)에 의해 서명됩니다.
    • 인증서가 만료되었거나 아직 유효하지 않습니다.
    • CNsubjectAlternativeName 속성이 Host 헤더 또는 DNS PTR 레코드와 일치하지 않습니다.

외부 IP 또는 네트워크 부하 분산기 IP를 사용한 VM 직접 연결 사용

VM의 외부 IP 또는 네트워크 부하 분산 IP를 통해 연결하는 경우에는 연결이 GFE를 통과하지 않습니다. 이러한 연결은 기본적으로 암호화되지 않으며 사용자 판단에 따라 보안이 제공됩니다.

Cloud VPN 사용

VPN을 통해 온프레미스 호스트를 Google Cloud VM에 연결하면 온프레미스 호스트가 온프레미스 VPN, Google VPN, Google Cloud VM과도 상호 연결될 수 있습니다. 이 경우에는 연결이 GFE를 거치지 않습니다. 이러한 연결은 IPSec를 통해 온프레미스 VPN부터 Google VPN까지 보호됩니다. Google VPN부터 Google Cloud VM까지의 연결은 통신이 Google이나 Google 대리인이 통제하는 물리적 경계에서 벗어나면 인증 및 암호화됩니다.

Cloud Dedicated Interconnect 사용

Dedicated Interconnect를 통해 연결하는 경우 GFE를 거치지 않고 온프레미스 호스트에서 직접적인 상호 연결이 이루어집니다. 이러한 연결은 기본적으로 암호화되지 않으며 사용자 판단에 따라 보안이 제공됩니다. 전송 계층 보안(TLS) 레이어 7 암호화 프로토콜을 사용하여 Dedicated Interconnect를 통과하는 애플리케이션 트래픽을 암호화할 수 있습니다.

가상 머신-가상 머신

VPC 서브넷 범위를 사용해 Google 프로덕션 네트워크 내부의 VPC 네트워크에서 이루어지는 VM 간 라우팅의 경우 Google이나 Google 대리인이 통제하는 물리적 경계 외부로 트래픽을 라우팅해야 할 수 있습니다. VM 간 라우팅의 예는 다음과 같습니다.

  • 서로 요청을 전송하는 두 Compute Engine VM
  • Cloud SQL 등 Google에서 관리하는 VM으로 연결되는 고객 VM

VM 간 연결은 물리적 경계를 벗어나면 암호화되며 물리적 경계 안에서는 인증 처리됩니다. 외부 IP 주소를 사용하는 VM 간 트래픽은 기본적으로 암호화되지 않으며 사용자 판단에 따라 보안이 제공됩니다. 그림 1에서는 이 같은 상호작용(연결 C)을 보여줍니다.

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의 프로덕션 네트워크에 유지됩니다. Google 프로덕션 네트워크 외부에 있고 Compute Engine VM 인스턴스의 외부 IP 주소에 연결되는 시스템은 인터넷을 통해 트래픽을 라우팅합니다.

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

    • Compute Engine VM-Google Cloud Storage
    • Compute Engine VM-Machine Learning API

VM부터 GFE까지 Google Cloud 서비스는 기본적으로 TLS를 사용한 연결을 보호합니다2. 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에 적용되는 기본 및 선택적 보호 조치3

이 섹션의 나머지 부분에서는 전송 중 데이터를 보호하기 위해 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.34 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 SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

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

Google 인증 기관

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

예전부터 Google은 Google 도메인의 인증서 서명에 사용했던 자체 발급 CA를 운영해 왔습니다. 그러나 자체적인 루트 CA는 운영하지 않았습니다. 지금은 Symantec('GeoTrust')을 포함해 유비쿼터스 방식으로 분산된 여러 루트 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주마다 인증서를 순환합니다.

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

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

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

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

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

트래픽이 Google의 물리적 경계를 벗어나면 Google Cloud의 가상 네트워크 인프라를 통해 암호화가 이루어집니다. 암호화는 네트워크 레이어에서 수행되며 동일한 Virtual Private Cloud(VPC) 내 또는 피어링된 VPC 네트워크 전반에서 비공개 IP 트래픽에 적용됩니다.

Google이나 Google 대리인이 통제하지 않는 물리적 경계를 통과하는 네트워크는 전송 중인 트래픽을 염탐, 삽입 또는 변경할 수 있는 능동적 공격자에 의해 손상될 수 있다고 가정합니다. Google에서 통제하지 않는 물리적 경계 밖으로 데이터가 이동하는 경우 암호화를 사용해 통신의 무결성과 보안성을 보장하고 있습니다.

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

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

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

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

그림 4: 보안 토큰

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

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

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 인프라에 저장 상태로 보관 중인 데이터를 보호하는 암호화 키를 저장 및 관리하는 Google의 내부 키 관리 서비스가 그 예에 해당합니다.

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-GCM13을 사용합니다. ALTS 암호화에 대한 자세한 내용은 표 2를 참조하세요.

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

표 2: ALTS의 암호화

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

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

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

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

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

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

사용자가 구성 가능한 전송 중 암호화 옵션

전송 중 암호화에서는 Google이 전송 중 데이터에 적용하는 기본적인 보호에 대해 설명했습니다. 이 섹션에서는 이러한 기본적인 보호 조치에 사용자가 설정할 수 있는 구성에 대해 설명합니다.

온프레미스 데이터 센터-Google Cloud

GCLB 외부 부하 분산기를 사용하는 TLS

클라우드 서비스가 Google HTTPS 또는 SSL 프록시 외부 부하 분산기를 사용하는 경우 GFE에서는 고객이 직접 프로비저닝 및 제어하는 SSL 인증서를 사용해 사용자의 TLS 연결을 종료합니다. 인증서 맞춤설정에 관한 자세한 내용은 SSL 인증서 문서를 참조하세요.

Google Cloud VPN을 사용하는 IPSec 터널

Google Cloud 고객은 Google Cloud VPN으로 IPSec VPN 연결(레이어 3)을 통해 온프레미스 네트워크를 Google Cloud Platform VPC(Virtual Private Cloud) 네트워크에 안전하게 연결할 수 있습니다. 한쪽 VPN 게이트웨이에서 두 네트워크 사이의 트래픽 이동을 암호화하고 다른 쪽 VPN 게이트웨이에서 이를 복호화합니다. 이를 통해 인터넷에서 데이터를 보호합니다. 또한 여러 VPN 게이트웨이를 통해 부하 분산된 여러 터널을 설정할 수도 있습니다. Google Cloud VPN은 다음과 같은 방법으로 데이터를 보호합니다.

  • VM에서 Cloud VPN으로 전달되는 패킷은 VPC 네트워크에 그대로 머무릅니다. 이러한 패킷은 Google이나 Google 대리인이 통제하는 물리적 경계 외부로 이동할 경우 Google Cloud의 가상 네트워크를 통해 암호화됩니다.
  • Cloud VPN에서 온프레미스 VPN으로 전달되는 패킷은 IPSec 터널을 사용해 암호화 및 인증됩니다.
  • 온프레미스 VPN에서 온프레미스 호스트로 전달되는 패킷은 네트워크에 마련된 통제에 따라 보호됩니다.

VPN을 설정하려면 호스팅되는 서비스의 VPC 네트워크에 Cloud VPN 게이트웨이와 터널을 만들고 네트워크 간 트래픽을 허용하세요. 두 VPC 간의 VPN을 설정할 수도 있습니다.

VPN 터널의 IKE15(Internet Key Exchange) 버전을 지정하여 네트워크를 맞춤설정할 수 있습니다. IKE 버전은 IKEv1 및 IKEv2 두 가지 중에서 선택할 수 있으며 버전 별로 다른 암호화를 지원합니다. IKEv1을 지정하면 Google에서 AES-128-CBC를 사용하여 패킷을 암호화하고 SHA-1 HMAC16를 통해 무결성을 제공합니다. IKEv2의 경우 다양한 암호화가 제공 및 지원됩니다. 어떤 경우든 Google Cloud VPN은 피어 기기가 지원하는 가장 안전한 공통 프로토콜을 협상합니다. VPN 설정에 관한 자세한 지침은 VPN 라우팅 옵션 선택 문서를 참조하세요.

Cloud VPN(IPSec) 터널 대신 Google Cloud Dedicated Interconnect를 사용할 수 있습니다. Dedicated Interconnect는 온프레미스 네트워크와 VPC 네트워크 간의 직접적인 실제 연결과 비공개 IP 통신을 제공합니다. Dedicated 또는 Partner Interconnect를 통해 이동하는 데이터는 기본적으로 암호화되지 않으므로 TLS 등을 사용해 애플리케이션 레이어에서 보호해야 합니다. MACsec(레이어 2 보호)는 현재 지원되지 않습니다.

사용자-Google 프런트엔드

관리형 SSL 인증서: 무료 자동화 인증서

Google Cloud에 애플리케이션을 빌드하는 경우 사용 중인 SSL 인증서를 구성해 GFS의 TLS 지원을 활용할 수 있습니다. 예를 들어 애플리케이션에서 TLS 세션을 종료할 수 있습니다. 여기서 말하는 종료는 GCLB 외부 부하 분산기를 사용하는 TLS에서 설명한 TLS 종료와는 다른 것입니다.

또한 Google은 Firebase 호스팅Google App Engine 커스텀 도메인 모두에 무료 자동화 SSL 인증서를 제공합니다. 이 인증서는 Google에서 호스팅되는 속성에만 사용할 수 있습니다. Google App Engine 커스텀 도메인을 사용하면 자체 SSL 인증서를 제공하고 HSTS(HTTP Strict Transport Security) 헤더를 사용할 수도 있습니다.

도메인이 Google 인프라를 가리키면 Google은 해당 도메인의 인증서를 요청하고 확보해 안전한 통신을 지원합니다. Google에서 TLS 서버 비공개 키(2048비트 RSA 또는 secp256r1 ECC)를 관리하고 고객을 대신해 인증서를 갱신합니다.

Gmail의 TLS 요청

전송 계층 보안에서 다루었듯이 기본적으로 Gmail은 TLS를 사용합니다. Gmail은 TLS 세션17을 통해 이메일의 마지막 홉이 이뤄졌는지 여부를 기록하고 표시합니다. Gmail 사용자들끼리 교환한 이메일은 TLS로 보호되며 경우에 따라서는 애플리케이션에서 직접 전송되기도 합니다. 이러한 경우 Gmail 애플리케이션에서 사용한 RPC는 ALTS로 보호됩니다. 자세한 설명은 서비스 간 인증, 무결성, 암호화를 참조하세요. 다른 이메일 제공업체에서 받은 메시지의 경우에는 Gmail에서 TLS를 적용하지 않습니다. Gmail 관리자는 모든 수신 및 발신 이메일에 보안 TLS 연결을 요청하도록 Gmail을 구성할 수 있습니다.

Gmail S/MIME

S/MIME(Secure/Multipurpose Internet Mail Extensions)는 인증, 무결성, 암호화를 제공하는 이메일 보안 표준입니다. S/MIME 표준 구현 시 이메일을 전송하는 사용자와 관련된 인증서를 공용 CA에서 호스팅해야 합니다.

관리자는 Gmail을 구성하여 발신 이메일에 S/MIME를 사용 설정하고 콘텐츠 및 첨부파일 규정 준수에 대한 정책을 설정하며 수신 및 발신 이메일의 라우팅 규칙을 만들 수 있습니다. 구성을 마친 후에는 Gmail API를 사용해 사용자의 공개 인증서를 Gmail에 업로드해야 합니다. Gmail 외부 사용자의 경우 초기 S/MIME 서명 메시지를 교환해 기본값으로 S/MIME를 설정해야 합니다.

서비스 간 암호화 및 VM 간 암호화

Istio는 서비스 검색 및 연결을 간소화하기 위해 Google, IBM, Lyft 등에서 개발한 오픈소스 서비스 메시입니다. Istio 인증은 서비스 간 전송 중 데이터의 자동 암호화와 연결된 키 및 인증서의 관리를 제공합니다. Istio는 Google Kubernetes Engine 및 Google Compute Engine에서 사용할 수 있습니다.

워크로드에 상호 인증 및 암호화를 구현하려면 istio 인증을 사용하면 됩니다. 특히 Kubernetes 워크로드의 경우 Istio 인증을 사용하면 클러스터 수준 CA에서 인증서를 생성 및 배포할 수 있으며 이후 이 인증서를 pod 간 상호 전송 계층 보안(mTLS)에 사용할 수 있습니다.

Google에서 인터넷의 전송 중 데이터 암호화를 지원하는 방법

기본적인 전송 중 암호화사용자가 구성 가능한 전송 중 암호화 옵션을 통해 Google Cloud에서 전송 중인 고객 데이터에 적용하는 기본 및 맞춤설정 보호에 대해 살펴봤습니다. 또한 Google은 인터넷 전반에서 전송 중 암호화 및 데이터 보안을 사용하도록 독려하는 여러 오픈소스 프로젝트를 진행하는 등 다양한 노력을 기울이고 있습니다.

인증서 투명성

사용자-Google 프런트엔드 암호화에서 다루었듯이 HTTPS를 제공하려면 먼저 신뢰할 수 있는 웹(공용) 인증 기관(CA)의 인증서를 신청해야 합니다. 인증 기관에서는 신청자가 도메인 소유자의 승인을 받았는지 확인하고 인증서에 포함된 다른 정보가 정확한지 확인하는 업무를 담당합니다. 이후 인증서가 브라우저에 표시되어 사용자가 액세스하려는 사이트를 인증하게 됩니다. HTTPS를 제대로 인증하려면 CA에서 도메인 소유자가 승인한 인증서만 발급하도록 해야 합니다.

Google은 2013년 3월부터 시행한 인증서 투명성(CT)으로 CA에서 승인되지 않았거나 잘못된 인증서를 발급했는지 감지할 수 있는 방법을 사이트 운영자와 도메인 소유자에게 제공하고 있습니다. 도메인 소유자, CA, 대중에게 표시된 신뢰할 수 있는 인증서(CA의 경우 발급한 인증서)를 공개적으로 검증 가능한 추가 전용 변조 방지 로그에 기록하는 메커니즘을 제공하는 원리입니다. 이 로그의 인증서에 포함된 정보가 올바르고 정확하며 승인받은 것인지 누구나 검토할 수 있습니다.

최초 버전의 인증서 투명성은 IETF 시험용 RFC인 RFC 6962로 지정되었습니다. 인증서 투명성 개발 과정에서 Google은 인증서를 기록하는 오픈소스 로그 서버 및 인증서 투명성 로그를 생성하는 도구 등 다양한 도구를 오픈소스로 공개했습니다. 또한 Chrome에서는 EV(Extended Validation) 인증서 또는 인증서를 부적절하게 발급한 적이 있는 CA에서 발급된 인증서 등을 공개하도록 요구하고 있습니다. 2018년부터는 Chrome에서 공개적으로 신뢰할 수 있는 인증서를 새로 발급하는 경우 모두 공개해야 합니다.

사이트 운영자는 인증서 투명성을 사용해 승인되지 않은 인증서가 웹사이트에 발급되었는지 여부를 감지할 수 있습니다. Google의 인증서 투명성 보고서, 인증서 검색 또는 Facebook 도구 등 이를 쉽게 감지할 수 있는 다양한 도구가 무료로 제공되고 있습니다. 인증서 투명성을 사용하고 있지 않아도 현재 많은 브라우저에서 인증서 투명성을 정기적으로 검사하여 사용자가 웹사이트에 액세스할 때 신뢰하는 CA가 업계 요구사항 및 권장사항을 준수하는지 확인하여 허위 인증서 발급의 위험성을 줄이고 있습니다.

HTTPS 사용 증가

사용자-Google 프런트엔드 암호화에서 설명했듯이, Google은 자사 사이트와 서비스에서 기본적으로 최신 HTTPS를 제공하기 위해 노력하고 있으며 제품과 서비스 전반에서 암호화를 100% 달성하는 것을 목표로 삼고 있습니다. 이를 위해 Google Cloud를 포함한 모든 속성의 목표 진행상황을 추적하는 HTTPS 투명성 보고서를 해마다 발표하고 있습니다. Google은 HSTS(HTTP Strict Transport Security)18를 지원하지 않는 브라우저 또는 다른 클라이언트를 위한 솔루션과 같이 일부 Google 제품의 암호화 지원을 어렵게 하는 기술 장벽을 해결하기 위해 지속적으로 노력하고 있습니다. google.com 홈페이지를 포함한 일부 Google 사이트에서는 사용자가 HTTPS로만 서버에 연결할 수 있도록 HSTS를 사용하고 있습니다.

앞으로 더 많은 인터넷이 HTTPS로 이전할 것이며 Google은 이러한 움직임을 다음과 같이 지원하고 있습니다.

2016년, Google은 인터넷의 Google 외 상위 100개 사이트에 대한 '인터넷의 HTTPS 사용량'에 대한 측정항목을 게시하기 시작했습니다. 이 측정항목을 바탕으로 HTTPS에 대한 인식을 높이고 모든 사용자가 더 안전하게 인터넷을 사용하도록 돕고 있습니다. 2017년 10월, Chrome은 플래티넘 스폰서로서 Let’s Encrypt에 대한 재정적 후원을 공식적으로 갱신했습니다.

보안 SMTP 사용 증가: Gmail 지표

대부분의 이메일은 기본적으로 암호화를 사용하지 않고 이메일을 전송하는 SMTP(Simple Mail Transfer Protocol)를 사용해 교환됩니다. 이메일을 암호화하려면 메일 제공업체에서 TLS와 같은 보안 통제를 구현해야 합니다.

사용자-Google 프런트엔드 암호화에서 다루었듯이 Gmail은 기본적으로 TLS를 사용합니다. 또한 Gmail의 TLS 요청에서는 Gmail 관리자가 수신 및 발신 이메일에 TLS 보호 조치를 적용할 수 있는 방법을 설명했습니다. HTTPS 투명성을 위한 노력과 마찬가지로 Gmail에서도 수신되는 이메일에 대한 TLS 사용 데이터를 제공합니다. 이 데이터는 안전한 이메일 투명성 보고서에 나와 있습니다.

Google은 IETF 및 기타 업계 주요 업체와 파트너십을 맺고 SMTP STS 개발에 앞장서고 있습니다. SMTP STS는 암호화된 채널에서만 SMTP를 사용하게 하는 HTTPS용 HSTS와 유사한 개념입니다.

Chrome API

2015년 2월, 보안 출처19에서만 사용할 수 있는 강력한 새 기능을 Chrome에서 발표했습니다. 비공개 정보 처리 및 사용자 기기의 센서 액세스 등이 이러한 기능에 해당합니다. Chrome 50의 위치정보를 시작으로 Google은 안전하지 않은 출처에서는 이 기능을 지원 중단했습니다.

전송 중 암호화의 지속적 혁신

Chrome 보안 사용자 환경

Chrome은 사용자가 사이트 연결의 안전성을 신속하게 파악할 수 있도록 UI를 활용해 보안 정보를 표시하는 업계 선두업체입니다. 이 정보를 통해 사용자는 정보에 근거해 데이터를 공유하는 시기와 방법을 결정할 수 있습니다. Chrome은 광범위한 사용자 연구를 진행하여 전문가 상호심사(peer review)를 마친 논문에 결과를 공유하고 있습니다.

사용자 보호를 강화하기 위해 Chrome은 2017년 말까지 모든 HTTP 연결을 비보안 연결로 표시한다는 계획을 발표했습니다. Chrome 56부터 HTTP 페이지에 비밀번호 또는 신용카드 입력란이 있는 양식이 포함된 경우 기본적으로 사용자에게 경고가 표시됩니다. Chrome 62에서는 사용자가 HTTP 페이지에 데이터를 입력할 때 및 시크릿 모드에서 방문한 모든 HTTP 페이지에 경고가 표시됩니다. 최종적으로 Chrome은 HTTP를 통해 제공되는 모든 페이지에 경고를 표시할 예정입니다.

특정 구성이 Chrome에서 사용자에게 어떻게 표시되는지 보려면 BadSSL 도구를 사용하면 됩니다.

키 투명성

메시지 암호화의 광범위한 도입을 저해하는 주요 요인은 공개 키 교환의 어려움에 있습니다. 새로운 사용자와 통신할 때 새 사용자의 공개 키를 어떻게 하면 안전하게 찾을 수 있을까요? 이 문제를 해결하기 위해 2017년 1월, Google은 키 투명성을 발표했습니다. 키 투명성은 공개 키 배포를 위한 일반적이고 안전하며 감사 가능한 수단을 제공하는 개방형 프레임워크입니다. 이 프레임워크로 사용자가 수동 키 인증을 수행할 필요성을 없앴습니다. 키 투명성은 E2E 및 OpenPGP 이메일 암호화 등 주로 통신 중 사용자 공개 키 배포에 중점을 두고 있습니다. 키 투명성 설계는 새로운 키 복구 및 배포 방식이며 인증서 투명성CONIKS에서 얻은 정보를 기반으로 합니다.

키 투명성은 오픈소스로 개발되었으며 대규모 Merkle 트리를 사용하여 구현됩니다. 키 투명성 확인을 통해 계정 소유자가 자신의 계정에 어떤 키가 연결되었고 얼마나 오랫동안 계정이 안정적으로 활성 상태였는지 확인할 수 있습니다. Google 키 투명성 작업의 장기적 목표는 누구나 키 투명성 서버를 운영할 수 있고 여러 애플리케이션에 쉽게 통합할 수 있도록 하는 것입니다.

포스트 퀀텀 암호화

Google은 전송 중 암호화 기술 부문에서 계속 업계 선두를 유지할 것입니다. 이를 위해 포스트 퀀텀 암호화 분야의 연구를 시작했습니다. 이 암호화 유형은 효율적인 퀀텀 공격에 취약한 기존 암호화 기본 요소를 가장 강력하다고 여겨지는 포스트 퀀텀 후보로 대체할 수 있게 해줍니다. 2016년 7월, Google은 Chrome의 개발자 버전에 New Hope 포스트 퀀텀 암호화 알고리즘을 사용하여 이러한 알고리즘의 배포 가능성을 실험했다고 발표했습니다. 그 밖에도 Google 연구원들은 기타 실용적인 포스트 퀀텀 키 교환 프로토콜에 관한 논문도 발표했습니다.

부록

인프라 보안 설계 개요가 포함된 Google Cloud 보안과 공개 SOC 3 감사 보고서가 포함된 Google Cloud 규정 준수를 읽어보세요.

각주

1 파트너 솔루션에는 Cloud Launcher에서 제공하는 솔루션과 Cloud Dataprep과 같이 파트너와 공동으로 빌드한 제품이 모두 포함됩니다.
2 Google Cloud Storage 버킷에 대한 HTTP 액세스 등의 경우 암호화를 여전히 사용 중지할 수 있습니다.
3 레이어 7에서 보호되지 않는 VM과 서비스 간의 통신은 레이어 3 및 4에서 계속 보호됩니다.
4 TLS 1.3은 아직 완성되지 않았습니다. 테스트 용도로 Gmail과 같은 특정 Google 도메인에 임시 버전이 구현되었을 뿐입니다.
5 Google은 여전히 이 버전의 프로토콜을 사용하는 브라우저를 위해 TLS 1.0을 지원합니다. 참고로 결제 카드 산업(PCI) 규정의 지원 중단 요청에 따라 2018년 7월부터 신용카드 정보를 처리하는 모든 Google 사이트에서 더 이상 TLS 1.0을 지원하지 않습니다.
6 QUIC에 관한 자세한 내용은 [https://www.chromium.org/quic](https://www.chromium.org/quic)를 참조하세요.
7, 8, 9 일부 기존 운영체제와의 하위 호환성을 위해 3DES, SHA1, MD5를 지원합니다.
10 연결 인증서의 경우 CA 신뢰가 타동적으로 이루어집니다.
11 이는 세션 티켓([RFC 5077](https://tools.ietf.org/html/rfc5077)) 또는 세션 ID([RFC 5246](https://tools.ietf.org/html/rfc5246))일 수 있습니다.
12 제어 영역은 신호 트래픽을 옮기고 라우팅을 담당하는 네트워크의 일부입니다.
13 이전에는 다른 프로토콜을 사용했지만 지금은 지원 중단되었습니다. 이전 프로토콜을 사용하는 작업은 1%가 채 안 됩니다.
14 Datagram TLS(DTLS)는 도청 및 조작을 방지하면서 통신할 수 있도록 데이터그램 기반 애플리케이션의 보안을 제공합니다.
15 IKE(Internet Key Exchange)는 IPSec 프로토콜 모음의 보안 연결을 설정할 때 사용되는 프로토콜입니다.
16 HMAC-SHA-1은 Google 연구원이 발견한 SHAttered 충돌과 같은 [SHA-1 충돌](https://shattered.io/)로 인해 손상되지 않습니다.
17 Enterprise Plus의 경우 UI에 표시되지 않습니다. 도메인 관리자가 [이메일 로그 검색](https://support.google.com/a/answer/2604578)을 사용하여 도메인 데이터를 검사할 수 있습니다.
18 HSTS(HTTP Strict Transport Security)는 웹사이트에서 보안 연결을 통해서만 액세스가 가능함을 자체적으로 선언하고 사용자가 보안 연결을 통해서만 지정된 사이트와 상호작용하도록 사용자 에이전트를 전달할 수 있는 메커니즘입니다.
19 보안 출처는 특정 체계, 호스트 또는 포트 [패턴](https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features)과 일치하는 연결입니다.