Google Cloud Platform의 저장 데이터 암호화

여기에 포함된 콘텐츠는 2017년 4월 기준으로 작성되었으며, 이 문서가 작성된 당시의 상황을 나타냅니다. Google Cloud Platform의 보안 정책 및 시스템은 보안 성능이 향상됨에 따라 앞으로도 계속 변경될 수 있습니다.

재생 버튼

Google Cloud의 저장 데이터 암호화

CIO 수준 요약

  • Google은 여러 계층에 걸친 암호화를 사용하여 Google Cloud Platform 제품에 저장된 고객 데이터를 보호합니다.
  • Google Cloud Platform은 고객에게 특정 작업을 요구하지 않고도 하나 이상의 암호화 메커니즘을 사용하여 저장된 고객 콘텐츠를 암호화합니다. 몇 가지 사소한 예외가 있으며 그 내용은 이 문서의 뒷부분에서 설명합니다.
  • 저장할 데이터가 청크로 분할되고, 각 청크는 고유한 데이터 암호화 키를 사용하여 암호화됩니다. 이러한 데이터 암호화 키는 데이터와 함께 저장되고, Google의 중앙 키 관리 서비스 내에서만 배타적으로 저장되고 사용되는 키 암호화 키로 암호화('래핑')됩니다. Google의 키 관리 서비스는 중복성을 지원하며 전 세계에 분산되어 있습니다.
  • Google Cloud Platform에 저장된 데이터는 AES256 또는 AES128을 사용하여 스토리지 수준에서 암호화됩니다.
  • Google은 공통 암호화 라이브러리인 Tink를 사용하여 거의 모든 Google Cloud Platform 제품들 간에 암호화를 일관되게 구현합니다. 이 공통 라이브러리를 폭넓게 사용하므로, 소수의 암호화 전문가로 이루어진 팀만으로도 긴밀한 통제와 검토가 이루어지는 코드를 적절히 구현하고 유지보수할 수 있습니다.

소개

많은 개인과 기업체가 공용 클라우드 공급업체를 선정하는 기준으로 보안을 꼽습니다. Google에서 보안은 가장 중요한 요소입니다. Google은 보안 및 개인정보 보호를 위해 최선을 다하고 있습니다. 인터넷을 통해 전달되거나, Google 데이터 센터 간에 이동하거나, Google 서버에 저장되는 데이터를 포함해서 모든 사용자 데이터를 보호하기 위해 끊임없이 노력하고 있습니다.

Google의 포괄적인 보안 전략에서 핵심은 전송 중인 데이터와 저장 데이터를 암호화하는 기술입니다. 이 기술은 암호화 키에 대한 감사된 액세스 권한을 가진 승인된 역할 및 서비스만 데이터에 액세스할 수 있도록 보장합니다. 이 백서에서는 Google Cloud Platform의 저장 데이터 암호화 방식에 대해 설명하고, Google이 이를 사용해서 사용자 정보를 보다 안전하게 유지하는 방법을 설명합니다.

이 문서는 현재 Google Cloud Platform을 사용 중이거나 사용을 고려하고 있는 CISO 및 보안 운영팀을 대상으로 작성되었습니다. 소개 부분을 제외하고, 이 문서에서는 대상 독자가 암호화 및 암호화 기본 요소에 대한 기본적인 지식이 있다고 가정합니다.

암호화란 무엇인가요?

암호화는 판독 가능한 데이터를 입력(일반 텍스트라고도 부름)으로 사용해서 일반 텍스트에 대해 거의 어떤 정보도 노출하지 않는 출력(암호문이라고도 부름)으로 변환하는 과정을 의미합니다. 여기에 사용되는 암호화 알고리즘은 AES(Advanced Encryption Standard)와 같은 공개 기술이지만, 알고리즘을 실행할 때 사용되는 키는 비공개입니다. 암호문을 다시 원래 형태로 복호화하기 위해서는 키를 사용해야 합니다. Google에서 데이터를 기밀로 유지하기 위한 암호화 사용은 일반적으로 무결성 보호 기술과 결합됩니다. 암호문에 액세스할 수 있는 사용자가 키를 알지 못하면 해당 텍스트를 이해하거나 수정할 수 없습니다. 암호화에 대해 자세히 알고 싶다면 현대 암호화 기술 소개를 읽어볼 것을 권장합니다.

이 백서에서는 저장 데이터의 암호화에 대해 집중적으로 설명합니다. 저장 데이터 암호화는 디스크(SSD 포함) 또는 백업 미디어에 저장된 데이터를 보호하기 위해 사용되는 암호화 기술을 의미합니다.

암호화가 고객 데이터 보호에 도움이 되는 이유

암호화는 광범위한 보안 전략 중 하나입니다. 암호화는 데이터 보호를 위한 심층적 방어 레이어를 추가합니다. 데이터가 공격자의 손에 들어가더라도 암호화 키를 이용할 수 없다면 데이터에 액세스할 수 없습니다. 또한 공격자가 데이터가 포함된 저장 기기를 입수하더라도 이를 이해하거나 복호화할 수 없게 됩니다.

저장 데이터 암호화 기술은 하드웨어 및 소프트웨어 스택의 하위 레이어를 효과적으로 '잘라냄'으로써 공격 영역을 줄여줍니다. 이러한 하위 레이어가 무너지더라도(예: 기기에 대한 물리적 접근) 적절한 암호화가 적용되었다면 해당 기기에 있는 데이터가 유출되지 않습니다. 또한 중앙에서 관리되는 암호화 키가 데이터 액세스를 적용하고 감사할 수 있는 단일 지점으로 작용하기 때문에 암호화는 공격을 방어할 수 있는 '요충지'의 역할을 수행합니다.

암호화는 Google이 고객 데이터의 기밀성을 보장할 수 있게 해주는 중요한 메커니즘을 제공합니다. 암호화를 통해 시스템에서 백업 등의 데이터 조작을 수행할 수 있고, 엔지니어가 콘텐츠에 액세스하지 않아도 인프라 지원 업무를 수행할 수 있습니다.

Google에서 고객 데이터의 의미

Google Cloud Platform 서비스 약관에 정의된 대로 고객 데이터는 Google Cloud Platform 고객이 또는 고객의 지시에 따라 본인 계정으로 사용한 Google Cloud Platform 서비스를 통해 직접 또는 간접적으로 Google에 제공한 콘텐츠를 의미합니다. 고객 데이터에는 고객 콘텐츠 및 고객 메타데이터가 포함됩니다.

고객 콘텐츠는 Google Cloud Storage에 저장된 데이터, Google Compute Engine에서 사용되는 디스크 스냅샷, Cloud IAM 정책과 같이 Google Cloud Platform 고객이 직접 생성하거나 Google에 제공하는 데이터입니다. 이 백서에서는 저장된 고객 콘텐츠의 암호화에 대해 집중적으로 다룹니다.

고객 메타데이터는 고객 데이터의 나머지 부분을 구성하며, 고객 콘텐츠로 분류될 수 없는 모든 데이터를 의미합니다. 여기에는 자동 생성된 프로젝트 번호, 타임스탬프, IP 주소는 물론 Google Cloud Storage에 있는 객체의 바이트 크기 또는 Google Compute Engine에 있는 머신 유형이 포함됩니다. 메타데이터는 지속적인 성능 및 운영을 위해 합리적인 수준으로 보호됩니다.

Google의 기본 암호화

저장 데이터 암호화

암호화 레이어

Google은 데이터 보호를 위해 여러 암호화 레이어를 사용합니다. 여러 암호화 레이어를 사용해서 중복된 데이터 보호 기능을 추가하고 애플리케이션 요구 사항에 따라 최적의 접근 방식을 선택할 수 있습니다.

암호화 레이어 차트

그림 1: Google Cloud Platform에 저장된 데이터 보호를 위해 여러 암호화 레이어를 사용합니다. 거의 모든 파일에 분산 파일 시스템 암호화 또는 데이터베이스 및 파일 스토리지 암호화가 사용되고, 거의 모든 파일에 저장 기기 암호화가 사용됩니다.

스토리지 시스템 레이어의 암호화

Google Cloud Storage 암호화의 작동 방식을 이해하기 위해서는 Google에서 고객 데이터가 어떻게 저장되는지 이해하는 것이 중요합니다. 데이터는 보관을 위해 하위 파일 청크로 분할됩니다. 각 청크는 크기별로 수 GB까지 다양할 수 있습니다. 각 청크는 개별 암호화 키를 사용하여 스토리지 수준에서 암호화됩니다. 같은 고객이 소유하고 있거나, 같은 머신에 저장되었거나, 같은 Google Cloud Storage 객체에 속하는 경우라도 서로 다른 청크 2개가 동일한 암호화 키를 갖지 않습니다.1 데이터 청크가 업데이트되면 기존 키를 다시 사용하지 않고 새로운 키로 암호화됩니다. 각각 서로 다른 키를 사용해서 데이터가 분할되므로, 데이터 암호화 키가 유출되더라도 그에 따른 '영향 범위'는 오직 해당 데이터 청크로만 제한됩니다.

Google은 디스크에 기록되기 전에 데이터를 암호화합니다. 모든 Google 스토리지 시스템에서 암호화는 이후에 추가되는 부가 기능이 아니라 내장 기능입니다.

각 데이터 청크에는 고유한 식별자가 있습니다. ACL(액세스제어 목록)은 해당 시점에 액세스가 부여된, 승인된 역할에 따라 작동하는 Google 서비스만 각 청크를 복호화할 수 있도록 합니다. 승인 없이는 데이터에 액세스할 수 없도록 설정함으로써 데이터 보안 및 개인정보 보호 수준을 향상할 수 있습니다.

각 청크는 Google의 스토리지 시스템에 분산되며, 백업 및 재해 복구를 위해 암호화된 형식으로 복제됩니다. 고객 데이터에 액세스하려는 공격자는 (1) 자신이 원하는 데이터에 해당하는 모든 스토리지 청크 및 (2) 청크에 따른 암호화 키를 파악하고 여기에 액세스할 수 있어야 합니다.

암호화된 청크로 저장된 데이터의 다이어그램

그림 2: Google에서 데이터는 암호화된 청크로 분할되어 보관됩니다.

Google은 고급 암호화 표준(AES) 알고리즘을 사용해서 저장 데이터를 암호화합니다. AES는 (1) AES256 및 AES128 모두 미국 국립 표준 기술 연구소(NIST)에서 장기 보관 용도로 권장되고(2019년 3월 기준), (2) AES가 고객 규정 준수 요구사항으로 포함되는 경우가 많기 때문에 널리 사용됩니다.

Google Cloud Storage에 저장되는 데이터는 거의 모든 경우 GCM(Galois/Counter Mode)의 AES를 사용하여 스토리지 수준에서 암호화됩니다. 이 기능은 Google이 유지관리하는 BoringSSL 라이브러리로 구현됩니다. 이 라이브러리는 OpenSSL의 여러 결점이 드러난 후 OpenSSL에서 내부 용도로 가져왔습니다. 일부의 경우, 인증을 위해서는 HMAC(해시된 메시지 인증 코드)와 함께 CBC(Cipher Block Chaining) 모드로 AES가 사용되고, 일부 복제된 파일의 경우에는 HMAC와 함께 CTR(Counter) 모드로 AES가 사용됩니다. (알고리즘에 대한 자세한 내용은 이 문서의 뒷부분을 참조하세요.) 다른 Google Cloud Platform 제품에서는 AES가 여러 모드로 사용됩니다.

저장 기기 레이어의 암호화

위에 설명된 스토리지 시스템 수준의 암호화 외에, 대부분의 경우 저장 기기 수준에서도 데이터가 암호화됩니다. 이를 위해서 적어도 HDD(하드 디스크)에는 AES128가, 그리고 새로운 SSD(솔리드 스테이트 드라이브)에는 AES256이 별도의 기기 수준 키(스토리지 수준에서 데이터 암호화를 위해 사용되는 키와 다름)와 함께 사용됩니다. 이전 기기들이 교체되면 기기 수준 암호화에 AES256만 사용될 것입니다.

백업 암호화

Google 백업 시스템을 통해 백업 프로세스 전반에 걸쳐 데이터가 암호화된 상태로 유지됩니다. 이러한 방식은 일반 텍스트 데이터가 불필요하게 노출되는 것을 방지할 수 있습니다.

또한 백업 시스템은 Google의 KMS(키 관리 서비스)에 저장된 키로부터 파생되는 고유한 DEK(데이터 암호화 키)와 백업 시에 무작위로 생성되는 파일별 시드를 사용해서 각 백업 파일을 독립적으로 암호화합니다. 백업에 포함된 모든 메타데이터에는 Google의 KMS에 저장되는 또 다른 DEK가 사용됩니다. (키 관리에 대한 자세한 내용은 아래 섹션을 참조하세요.)

저장 데이터가 암호화되지 않는 경우가 있나요?

Google Cloud Platform은 고객이 조치를 취하지 않아도 하나 이상의 암호화 메커니즘을 사용하여 저장된 고객 콘텐츠를 암호화합니다. 하지만 다음과 같은 예외가 있습니다.

  • Google Compute Engine의 가상 머신에서 제공되는 직렬 콘솔 로그. 이 문제는 현재 해결 중입니다.
  • 프로세스가 예기치 않게 실패할 때 로컬 드라이브에 기록되는 코어 덤프. 이 문제는 현재 해결 중입니다.
  • 로컬 디스크에 기록되는 디버깅 로그. 이 문제는 현재 해결 중입니다.
  • 스토리지 시스템에서 사용되는 임시 파일. 이 문제는 현재 해결 중입니다.
  • 고객 메타데이터 뿐만 아니라 고객 콘텐츠를 포함할 수 있는 일부 로그. 이 문제는 앞으로 해결할 계획입니다.

이러한 데이터는 여전히 다른 Google 보안 인프라를 통해 광범위하게 보호되고 있으며, 대부분의 경우에 스토리지 수준의 암호화를 통해 보호됩니다.

키 관리

데이터 암호화 키, 키 암호화 키, Google의 키 관리 서비스

청크에 포함된 데이터를 암호화하기 위해 사용되는 키를 DEK(데이터 암호화 키)라고 부릅니다. Google에는 많은 양의 키가 사용되고, 짧은 지연 시간과 고가용성이 요구되기 때문에, 이러한 키는 암호화 대상 데이터 근처에 저장됩니다. DEK는 KEK(키 암호화 키)로 암호화(또는 '래핑')됩니다. 각 Google Cloud Platform 서비스에는 하나 이상의 KEK가 존재합니다. 이러한 KEK는 특별히 키 보관 용도로 빌드된 저장소인 Google의 KMS(키 관리 서비스)에 중앙 집중식으로 저장됩니다. KEK를 DEK보다 적은 숫자로 유지하고 중앙 키 관리 서비스를 사용하면 Google 규모의 데이터 저장 및 암호화를 쉽게 관리할 수 있으며, 중앙에서 데이터 액세스를 추적 및 제어할 수 있습니다.

Google Cloud Platform 고객마다 공유하지 않는 리소스2는 여러 데이터 청크로 분할되고 다른 고객이 사용하는 키와 별도의 키를 사용하여 암호화3됩니다. 이러한 DEK는 같은 고객이 소유하는 같은 데이터의 다른 조각을 보호하는 키와도 구분됩니다.

DEK는 Google의 공통 암호화 라이브러리를 사용하여 스토리지 시스템에서 생성됩니다. 그런 다음 KMS로 전송되어 스토리지 시스템의 KEK로 래핑되고, 래핑된 DEK는 다시 스토리지 시스템으로 전달되어 데이터 청크와 함께 보존됩니다. 스토리지 시스템이 암호화된 데이터를 검색해야 할 때는 래핑된 DEK를 검색하고 이를 KMS에 전달합니다. 그런 다음 KMS는 이 서비스가 해당 KEK를 사용하도록 승인되었는지 확인합니다. 승인되었으면 키를 래핑 해제하고 일반 텍스트로 된 DEK를 서비스에 반환합니다. 그런 다음 서비스는 DEK를 사용해서 데이터 청크를 일반 텍스트로 복호화하고 무결성을 확인합니다.

데이터 청크 암호화에 쓰이는 KEK의 대부분은 KMS 내에서 생성되며, 나머지는 스토리지 서비스 내에서 생성됩니다. 일관성을 위해 모든 KEK는 Google이 만든 RNG(난수 생성기)를 사용하는 Google의 공통 암호화 라이브러리를 통해 생성됩니다. 이러한 RNG는 NIST 800-90Ar1 CTR-DRBG를 기반으로 하며 AES256 KEK4를 생성합니다. 이 RNG는 Linux 커널의 RNG에서 시드되고, Linux 커널의 RNG는 다시 여러 독립적인 엔트로피 소스로부터 시드됩니다. 여기에는 디스크 탐색에 대한 미세 측정 및 패킷 간 도착 시간과 같은 데이터 센터 환경의 엔트로피 이벤트와 가능한 경우 Intel RDRAND 지침(Ivy Bridge 이상 CPU)이 포함됩니다.

Google Cloud Platform에 저장되는 데이터는 위에 설명된 대로 AES256 또는 AES128을 사용하는 DEK로 암호화되고, Google Compute Engine의 영구 디스크에서 암호화되는 모든 새 데이터는 AES256을 사용하여 암호화됩니다. DEK는 Google Cloud Platform 서비스에 따라 AES256 또는 AES128을 사용하는 KEK로 래핑됩니다. Google은 현재 Cloud 서비스의 모든 KEK를 AES256으로 업그레이드하기 위해 노력하고 있습니다.

Google의 KMS는 KEK를 관리하며, 처음부터 이 목적을 위해서만 개발되었습니다. 이 시스템은 보안을 고려하여 설계되었습니다. KEK는 기본적으로 Google의 KMS에서 외부로 내보낼 수 없습니다. 이러한 키를 사용한 모든 암호화 및 복호화는 KMS 내에서 수행되어야 합니다. 덕분에 유출 및 오용을 방지할 수 있으며, KMS에서 키 사용에 대한 감사 추적을 수행할 수 있습니다.

KMS는 Google의 공통 암호화 라이브러리로 새 키를 생성하여 주기적으로 KEK를 자동으로 순환할 수 있습니다. 이 문서에서 단일 키처럼 언급된 경우가 많지만, 실제로 데이터는 하나의 키 세트를 사용하여 보호됩니다. 여기에는 암호화를 위한 활성 키 하나와 복호화를 위한 이전 키 세트가 포함되며 키의 수는 키 순환 일정에 따라 결정됩니다. KEK의 실제 순환 일정은 서비스에 따라 달라지지만, 표준 순환 기간은 90일입니다. Google Cloud Storage는 KEK를 90일 간격으로 순환하고, 최대 20개의 키 버전을 저장할 수 있으며, 최소 5년마다 데이터를 다시 암호화하도록 요구합니다(실제로 데이터는 이보다 더 자주 재암호화됨). KMS에 저장된 키는 재해 복구 목적으로 백업되고, 무한정 복구할 수 있습니다.

KEK 사용은 키별 정책에 따라 KMS에서 각 키에 대한 ACL(액세스제어 목록)로 관리됩니다. 승인된 Google 서비스 및 사용자만 키에 액세스할 수 있습니다. 각 키의 사용은 그 키를 요구하는 개별 작업 수준에서 추적되므로, 사용자가 키를 사용할 때마다 인증 및 기록이 이루어집니다. 사람의 데이터 액세스는 모두 Google의 전체 보안 및 개인정보처리방침의 일환으로 감사 가능합니다.

Google Cloud Platform 서비스가 암호화된 데이터 청크에 액세스할 때 수행되는 작업은 다음과 같습니다.

  1. 필요한 데이터를 얻기 위해 서비스에서 스토리지 시스템을 호출합니다.
  2. 스토리지 시스템이 해당 데이터가 저장된 청크를 식별하고(청크 ID), 저장된 위치를 확인합니다.
  3. 청크마다 스토리지 시스템이 청크와 함께 저장되어 있는 래핑된 DEK를 가져오고(일부 경우에 이 작업은 서비스에서 수행됨), 이를 래핑 해제하기 위해 KMS로 전송합니다.
  4. 스토리지 시스템이 작업 식별자와 청크 ID를 기준으로 식별된 작업이 해당 데이터 청크에 액세스하도록 허용되었는지 확인합니다. 그런 다음 KMS는 스토리지 시스템이 서비스와 연관된 KEK를 사용하고 해당 DEK를 래핑 해제하도록 승인되었는지 확인합니다.
  5. KMS가 다음 중 하나를 수행합니다.
    • 래핑 해제된 DEK를 다시 스토리지 시스템으로 전달해서 데이터 청크를 복호화하고 이를 서비스에 전달합니다. 또는 드문 경우지만, 다음을 수행합니다.
    • 래핑 해제된 DEK를 서비스로 전달하고, 스토리지 시스템이 암호화된 데이터 청크를 서비스로 전달하여, 서비스가 데이터 청크를 복호화하고 이를 사용합니다.

기기를 통해 기기 수준의 DEK를 관리하고 보호하는 로컬 SSD 등 전용 저장 기기에서는 과정이 다릅니다.

데이터 청크 복호화 다이어그램

그림 3: 데이터 청크를 복호화하기 위해 스토리지 서비스가 Google의 KMS(키 관리 서비스)를 호출하여 해당 데이터 청크에 대해 래핑 해제된 DEK(데이터 암호화 키)를 얻습니다.

암호화 키 계층 구조 및 신뢰 루트

Google의 KMS는 KMS 마스터 키라고 하는 루트 키를 통해 보호됩니다. 이 키는 KMS에서 모든 KEK를 래핑합니다. 이 KMS 마스터 키는 AES2564이며, 자체적으로 루트 KMS라고 하는 또 다른 키 관리 서비스에 저장됩니다. 루트 KMS는 약 12개 정도의 훨씬 적은 수의 키를 저장합니다. 추가적인 보안을 위해 루트 KMS는 일반적인 프로덕션 머신에서 실행되지 않으며, 각 Google 데이터 센터에 있는 전용 머신에서만 실행됩니다.

또한 루트 KMS에는 루트 KMS 마스터 키라고 하는 고유한 루트 키가 있습니다. 이 키도 AES2564이고, 이러한 키를 전역으로 복제하는 루트 KMS 마스터 키 배포자인 P2P 인프라에 저장됩니다. 루트 KMS 마스터 키 배포자는 루트 KMS와 동일한 전용 머신의 RAM에만 키를 저장하며, 적절한 사용을 확인하기 위해 로깅을 사용합니다. 루트 KMS의 인스턴스마다 하나의 루트 KMS 마스터 키 배포자 인스턴스가 실행됩니다. (루트 KMS 마스터 키 배포자는 현재 단계적으로 도입 중이며, 비슷한 방식으로 작동하지만 P2P가 아니었던 시스템을 대체할 예정입니다.)

루트 KMS 마스터 키 배포자의 새 인스턴스가 시작되면 배포자 인스턴스를 이미 실행 중인 호스트 이름 목록으로 새 인스턴스가 구성됩니다. 그런 다음 배포자 인스턴스가 다른 실행 중인 인스턴스에서 루트 KMS 마스터 키를 가져올 수 있습니다. 아래 설명된 재해 복구 메커니즘을 제외하고 루트 KMS 마스터 키는 특수 보안이 적용된 제한된 수의 머신에서 RAM에만 존재합니다.

루트 KMS 마스터 키 배포자의 모든 인스턴스가 동시에 다시 시작되는 시나리오에 대비하기 위해 루트 KMS 마스터 키가 안전한 하드웨어 기기에도 백업됩니다. 이 기기는 물리적으로 전 세계에 분산된 Google 위치 2곳의 엄격한 보안 구역 내 물리적 금고에 저장되어 있습니다. 이 백업은 모든 배포자 인스턴스가 한번에 작동 종료되는 경우(예: 전역 다시 시작)에만 필요합니다. 이러한 금고에 액세스할 수 있는 Google 직원은 20명 미만입니다.

Google의 암호화 계층 구조 다이어그램

그림 4: 암호화 키 계층 구조는 KMS에서 KEK로 래핑된 DEK를 사용하여 데이터 청크를 보호하고 KEK는 다시 루트 KMS와 루트 KMS 마스터 키 배포자로 보호됩니다.

요약

  • 데이터가 청크로 분할되고 DEK를 사용해서 암호화됩니다.
  • DEK는 KEK로 암호화됩니다.
  • KEK가 KMS에 저장됩니다.
  • KMS는 전 세계 데이터 센터의 여러 머신에서 실행됩니다.
    • KMS 키는 루트 KMS에 저장되는 KMS 마스터 키를 사용하여 래핑됩니다.
  • 루트 KMS는 KMS보다 훨씬 작고, 각 데이터 센터에 있는 전용 머신에서만 실행됩니다.
    • 루트 KMS 키는 루트 KMS 마스터 키 배포자에 저장되는 루트 KMS 마스터 키를 사용하여 래핑됩니다.
  • 루트 KMS 마스터 키 배포자는 전용 머신의 전역 RAM에서 동시에 실행되는 P2P 인프라입니다. 각 배포자는 실행 중인 다른 인스턴스에서 키 자료를 가져옵니다.
    • 배포자의 모든 인스턴스가 작동 종료되는 경우(전체 종료)를 대비해서 마스터 키가 제한된 Google 위치에 있는 (물리적) 금고의 (서로 다른) 보안 하드웨어에 저장됩니다.
    • 루트 KMS 마스터 키 배포자는 현재 단계적으로 도입 중이며, 비슷한 방식으로 작동하지만 P2P가 아니었던 시스템을 대체할 예정입니다.

전역 가용성 및 복제

고가용성, 짧은 지연 시간, 키에 대한 전역 액세스는 모든 수준에서 필수적입니다. Google의 키 관리 서비스는 이러한 특성을 갖추어야만 합니다.

따라서 KMS는 확장성이 높으며, 전 세계 Google 데이터 센터에 수천 번 복제되어 있습니다. KMS는 Google의 프로덕션 시스템에 있는 일반 머신에서 실행되며, KMS 인스턴스는 Google Cloud Platform 운영을 지원하기 위해 전 세계적으로 실행됩니다. 그 결과 모든 단일 키 운영의 지연 시간이 매우 짧게 유지됩니다.

루트 KMS는 각 데이터 센터에 있는 여러 보안 운영용 머신에서 실행됩니다. 같은 머신에서 루트 KMS와 일대일 비율로 루트 KMS 마스터 키 배포자가 실행됩니다. 루트 KMS 마스터 키 배포자는 가십핑 프로토콜을 통해 배포 메커니즘을 제공합니다. 즉, 정해진 주기로 각 배포자 인스턴스가 무작위로 다른 인스턴스를 선택하여 키를 비교하고 키 버전이 다르면 조정합니다. 이 모델에서는 Google의 모든 인프라가 의존하는 중앙 노드가 없습니다. 따라서 Google이 고가용성을 지원하면서 키 자료를 유지관리하고 보호할 수 있습니다.

Google의 공통 암호화 라이브러리

Google의 공통 암호화 라이브러리는 BoringSSL6을 사용하여 암호화 알고리즘을 구현하는 Tink5입니다. 모든 Google 개발자가 Tink를 사용할 수 있습니다. 이 공통 라이브러리를 폭넓게 사용할 수 있으므로, 소수의 암호화 전문가로 이루어진 팀만으로도 긴밀한 통제와 검토가 이루어지는 코드를 적절히 구현할 수 있습니다. 즉, 모든 Google팀이 암호화를 '직접 제공'할 필요는 없습니다. 모든 제품의 공통 암호화 라이브러리를 유지관리하는 작업은 특수 Google 보안팀에서 담당하고 있습니다.

Tink 암호화 라이브러리는 다양한 암호화 키 유형과 모드를 지원하며, 이들은 최신 공격에 대응할 수 있도록 정기적으로 검토됩니다.

이 문서를 작성하는 시점을 기준으로, Google은 DEK 및 KEK를 사용한 저장 데이터의 암호화에 다음과 같은 암호화 알고리즘을 사용합니다. 이러한 알고리즘은 기능 및 보안이 향상되면서 변경될 수 있습니다.

암호화 기본 요소 선호 프로토콜 지원되는 기타 프로토콜7
대칭적 암호화
  • AES-GCM(256비트)
  • AES-CBC 및 AES-CTR(128 및 256비트)
  • AES-EAX(128 및 256비트)
대칭적 서명(인증을 위해 위의 AES-CBC 및 AES-CTR과 함께 사용)
  • HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

각 Google Cloud Platform 제품의 암호화 세분성

각 Google Cloud Platform 서비스는 서로 다른 암호화 세분성으로 데이터를 분할합니다.

  Google Cloud Platform 서비스 고객 데이터 암호화 세분성8 (단일 DEK로 암호화되는 데이터 크기)
스토리지 Cloud Bigtable 데이터 청크당(테이블당 여러 개)
Cloud Datastore 데이터 청크당9
Cloud Firestore 데이터 청크당9
Cloud Spanner 데이터 청크당(테이블당 여러 개)
Cloud SQL
  • 2세대: Google Compute Engine에서와 같은 인스턴스당(각 인스턴스가 여러 데이터베이스를 포함할 수 있음)
  • 1세대: 인스턴스당
Cloud Storage 데이터 청크당(일반적으로 256KB~8MB)
컴퓨팅 App Engine10 데이터 청크당9
Cloud Functions11 데이터 청크당9
Compute Engine
  • 디스크당 여러 개
  • 스냅샷 그룹 마스터 키로부터 파생된 개별 스냅샷 범위를 포함하는 스냅샷 그룹당
  • 이미지당
Kubernetes Engine 디스크당 여러 개(영구 디스크)
Container Registry Google Cloud Storage에 저장, 데이터 청크당
빅데이터 BigQuery 데이터세트당 여러 개
Cloud Dataflow Google Cloud Storage에 저장, 데이터 청크당
Cloud Datalab Cloud Bigtable에 저장, 노트북 파일당
Cloud Dataproc Google Cloud Storage에 저장, 데이터 청크당
Cloud Pub/Sub 30일마다 순환9

클라우드 고객을 위한 추가 암호화 옵션

Google Cloud Platform에서 기본적으로 암호화를 제공하는 것 외에도 Google은 세부적으로 제어할 수 있도록 추가적인 암호화 및 키 관리 옵션을 고객에게 제공하기 위해 노력하고 있습니다.

Google Cloud Platform 고객에게 다음을 제공하고자 합니다.

  • 고객이 고객 데이터를 궁극적으로 관리하고 가장 세부적인 수준으로 데이터 액세스 및 사용을 제어하여 데이터 보안과 개인정보 보호를 모두 보장합니다.
  • 고객이 온프레미스와 동일한 방식으로 또는 이상적으로는 그보다 더 나은 방식으로 클라우드에서 호스팅되는 데이터의 암호화를 관리합니다.
  • 고객 리소스에 대해 입증 및 감사 가능한 신뢰할 수 있는 루트를 확보합니다.
  • ACL 사용 범위를 넘어서 고객 데이터의 추가적인 분리 및 격리를 지원합니다.

고객은 고객 제공 암호화 키 기능을 활용해, 직접 관리하는 기존 암호화 키를 Google Cloud Platform에서 사용할 수 있습니다. 이 기능은 Google Cloud StorageGoogle Compute Engine에서 스토리지 레이어 암호화에 사용할 수 있습니다.

고객은 또한 Google Cloud KMS(Key Management Service)를 사용하여 Google Cloud Platform에서 자신의 고유한 암호화 키를 관리할 수 있습니다. 이 제품은 고객이 애플리케이션 레이어 암호화를 관리할 수 있게 해줍니다.

암호화 기술 연구 및 혁신

암호화 기술 혁신에 발맞추어 Google은 암호화 기술을 숙지, 개발, 향상시키기 위한 세계적인 수준의 보안 엔지니어팀을 보유하고 있습니다. Google 엔지니어들은 표준화 절차 및 널리 사용되는 암호화 소프트웨어의 유지관리 과정에 참여하고 있습니다. Google은 일반 대중을 포함하여 업계의 누구나 Google의 연구 성과를 활용할 수 있도록 암호화 분야의 연구 결과를 정기적으로 발표하고 있습니다. 예를 들어 2014년에는 SSL 3.0 암호화의 중대한 취약점(POODLE)을, 2015년에는 OpenSSL의 고위험 취약점을 밝혀냈습니다.

Google은 클라우드 서비스를 위한 암호화 기술 부문에서 계속 업계 선두를 유지할 것입니다. 새로운 암호화 기술의 개발, 구현, 연구를 위해 Google은 다음과 같은 주제로 연구를 수행하는 연구팀을 보유하고 있습니다.

  • 부분 동형 암호화 - 데이터가 암호화된 상태로 데이터에서 일부 작업을 수행할 수 있도록 지원함으로써, 메모리상에서도 클라우드가 일반 텍스트로 데이터를 확인할 수 없습니다. 이 기술은 일반에 공개된 Google의 실험적 서비스인 암호화된 BigQuery 클라이언트에서 사용되고 있습니다.
  • 형식 및 순서 보존 암호화 - 데이터가 암호화된 상태로 데이터에서 일부 비교 및 순위 지정 작업을 수행할 수 있습니다.
  • 포스트 퀀텀 암호화 - 효율적인 퀀텀 공격에 취약한 기존 암호화 기본 요소를 퀀텀 공격에 훨씬 강력한 것으로 여겨지는 포스트 퀀텀 후보로 대체할 수 있습니다. 여기에서의 핵심은 포스트 퀀텀 알고리즘에 대한 NIST 권장사항을 포함하여 격자 기반의 공개 키 암호화를 연구하고 프로토타입을 마련하는 것입니다. 격자 기반 암호화는 현재까지 포스트 퀀텀 환경에서 사용될 가능성이 가장 높은 암호화 기술 중 하나로 여겨지고 있지만, 격자 기반 암호화를 적용하기 위한 최상의 알고리즘, 명확한 매개변수, 암호화 분석 차원에서는 아직 초기 단계입니다. 대칭적 키 암호화와 MAC가 알려진 퀀텀 알고리즘에 의해 약화되고 있긴 하지만, 키 크기를 2배로 늘려서 포스트 퀀텀 환경에서 비슷한 보안 수준으로 업그레이드할 수 있는 여지도 아직 있습니다.

추가 참조

Google Cloud Platform 보안

Google Cloud Platform 보안에 대한 일반적인 정보는 Google Cloud Platform 웹사이트의 보안 섹션을 참조하세요.

Google Cloud Platform 규정 준수

Google Cloud Platform 규정 준수 및 규정 준수 인증에 대한 자세한 내용은 Google의 공개 SOC3 감사 보고서가 포함된 Google Cloud Platform 웹사이트의 규정 준수 섹션을 참조하세요.

G Suite 보안

G Suite 암호화 및 키 관리에 대한 자세한 내용은 G Suite 암호화 백서를 참조하세요. 이 백서에서는 여기에 포함된 것과 동일한 내용이 상당 부분 다뤄지지만, G Suite 관련 내용에 집중되어 있습니다. 모든 G Suite 솔루션에서 Google은 고객 데이터를 보호하고 데이터 보안 방식을 가능한 한 투명하게 지원하기 위해 노력하고 있습니다. 일반적인 G Suite 보안에 대한 추가 정보는 G Suite 보안 및 규정 준수 백서에서 확인할 수 있습니다.

각주

1 Cloud Datastore, App Engine, Cloud Pub/Sub의 데이터 청크에는 여러 고객의 데이터가 포함될 수 있습니다. 서비스별 데이터 암호화 세분성 섹션을 참조하세요.

2 공유 리소스의 예시(이러한 격리가 적용되지 않음)로는 Google Compute Engine의 공유 기본 이미지가 있습니다. 이 경우 여러 고객이 단일 DEK로 암호화된 단일 복사본을 참조합니다.
3 고객 2명 이상의 데이터가 동일한 DEK로 암호화될 수 있기 때문에 Cloud Datastore, App Engine, Cloud Pub/Sub에 저장된 데이터는 예외입니다. 서비스별 데이터 암호화 세분성 섹션을 참조하세요.
4 이전에는 AES128이었고, 이러한 키 중 일부는 데이터 복호화를 위해 계속 유지됩니다.
5 Google은 또한 Keymaster와 CrunchyCrypt라고 하는 라이브러리 2개를 사용합니다. Keymaster는 Tink와 새로운 암호화 코드를 공유하지만 다른 키 버전 관리 구현을 사용하고 더 다양한 기존 알고리즘을 지원합니다. CrunchyCrypt는 Tink와 병합됩니다.
6 Google Cloud Storage의 일부 위치에서는 OpenSSL도 사용됩니다.
7 다른 암호화 프로토콜도 이 라이브러리에 존재하며 지금까지 지원되었으나, 이 목록에서는 Google Cloud Platform에서 주로 사용되는 프로토콜을 소개합니다.
8 고객 콘텐츠에 대한 암호화 세분성을 의미합니다. 여기에는 리소스 이름과 같은 고객 메타데이터가 포함되지 않습니다. 일부 서비스에서는 모든 메타데이터가 단일 DEK로 암호화됩니다.
9 고객별로 고유하지 않습니다.
10 애플리케이션 코드와 애플리케이션 설정을 포함합니다. App Engine에 사용되는 데이터는 고객 구성에 따라 Cloud Datastore, Cloud SQL 또는 Cloud Storage에 저장됩니다.
11 함수 코드, 설정, 이벤트 데이터를 포함합니다. 이벤트 데이터는 Cloud Pub/Sub에 저장됩니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...