이 콘텐츠는 2024년 5월에 마지막으로 업데이트되었으며 작성 당시의 상황을 나타냅니다. Google의 보안 정책 및 시스템은 고객 보호를 지속적으로 개선함에 따라 앞으로도 계속 변경될 수 있습니다.
Google의 포괄적인 보안 전략에는 고객 데이터를 공격자로부터 보호하는 데 도움이 되는 저장 데이터 암호화가 포함됩니다. Google은 사용자가 조치를 취하지 않아도 하나 이상의 암호화 메커니즘을 사용하여 모든 Google 고객 콘텐츠를 암호화합니다. 이 문서에서는 Google 인프라 및 Google Cloud의 기본 저장 데이터 암호화 방식과 이를 사용하여 고객 콘텐츠를 보다 안전하게 유지하는 방법을 설명합니다.
이 문서는 현재 Google을 사용 중이거나 사용을 고려하고 있는 보안 설계자 및 보안팀을 대상으로 합니다. 이 문서에서는 대상 독자가 암호화 및 암호화 기본 요소에 대한 기본적인 지식이 있다고 가정합니다. 암호화에 대한 자세한 내용은 현대 암호화 기술 소개를 참조하세요.
저장 데이터 암호화는 디스크(솔리드 스테이트 드라이브 포함) 또는 백업 미디어에 저장된 데이터를 보호하기 위해 사용되는 암호화입니다. Google에서 저장하는 모든 데이터는 고급 암호화 표준(AES) 알고리즘인 AES-256을 사용하여 스토리지 레이어에서 암호화됩니다. Google은 FIPS 140-2 검증 모듈(BoringCrypto)이 포함된 공통 암호화 라이브러리인 Tink를 사용하여 Google Cloud 간에 암호화를 일관되게 구현합니다.
Google에서 기본 저장 데이터 암호화에 사용되는 키를 소유하고 관리합니다. Google Cloud를 사용하는 경우 Cloud Key Management Service를 사용하여 데이터에 봉투 암호화를 추가할 수 있는 자체 암호화 키를 만들 수 있습니다. Cloud KMS를 사용하여 키를 생성, 순환, 추적, 삭제할 수 있습니다. 자세한 내용은 Cloud Key Management Service 심층 탐구를 참조하세요.
저장 데이터 암호화가 데이터 보호에 도움이 되는 방식
저장 데이터 암호화는 광범위한 보안 전략 중 하나입니다. 암호화에는 다음과 같은 이점이 있습니다.
- 데이터가 공격자의 손에 들어가더라도 공격자가 암호화 키에 액세스하지 못하면 데이터를 읽을 수 없게 됩니다. 공격자가 고객 데이터가 포함된 스토리지 기기를 입수하더라도 이를 이해하거나 복호화할 수 없게 됩니다.
- 하드웨어 및 소프트웨어 스택의 하위 레이어를 잘라내어 공격 영역을 줄이는 데 도움이 됩니다.
- 중앙에서 관리되는 암호화 키가 데이터 액세스를 시행하고 감사할 수 있는 단일 지점을 만들기 때문에 정체 현상을 만드는 역할을 합니다.
- 기업에서 모든 데이터를 보호할 필요 없이 암호화 키에 집중할 수 있으므로 공격 표면을 줄이는 데 도움이 됩니다.
- 고객에게 중요한 개인 정보 보호 메커니즘을 제공합니다. 데이터가 저장 상태에서 암호화되면 시스템 및 엔지니어가 데이터에 액세스할 수 있는 권한이 제한됩니다.
고객 데이터란 무엇인가요?
Google Cloud 서비스 약관에 정의된 대로 고객 데이터는 고객 또는 최종 사용자가 본인 계정으로 서비스를 통해 Google에 제공하는 데이터입니다.
고객 콘텐츠는 사용자가 직접 생성하거나 Google에 제공하는 데이터(예: Cloud Storage 버킷에 저장된 데이터, Persistent Disk 볼륨, Compute Engine에서 사용되는 디스크 스냅샷)입니다. 이 문서에서는 이 유형의 고객 데이터에 대한 기본 저장 데이터 암호화를 집중적으로 설명합니다.
고객 메타데이터는 고객 콘텐츠에 대한 데이터이며 자동 생성된 프로젝트 번호, 타임스탬프, IP 주소, Cloud Storage에 있는 객체의 바이트 크기, Compute Engine의 머신 유형을 포함합니다. 고객 메타데이터는 지속적인 성능 및 운영을 위해 합리적인 수준으로 보호됩니다. 이 문서에서는 메타데이터 보호에 초점을 맞추지 않습니다.
고객 콘텐츠와 고객 메타데이터가 함께 고객 데이터를 구성합니다.
저장 데이터의 기본 암호화
Google은 사용자가 조치를 취하지 않아도 하나 이상의 암호화 메커니즘을 사용하여 저장된 모든 고객 콘텐츠를 암호화합니다. 다음 섹션에서는 Google에서 고객 콘텐츠를 암호화하는 데 사용하는 메커니즘을 설명합니다.
암호화 레이어
Google은 데이터 보호를 위해 여러 암호화 레이어를 사용합니다. 여러 암호화 레이어를 사용해서 중복된 데이터 보호 기능을 추가하고 애플리케이션 요구 사항에 따라 최적의 접근 방식을 선택할 수 있습니다.
다음 다이어그램은 Google 프로덕션 데이터 센터에서 사용자 데이터를 보호하기 위해 일반적으로 사용되는 여러 암호화 레이어를 보여줍니다. 모든 사용자 데이터에 분산 파일 시스템 암호화 또는 데이터베이스 및 파일 스토리지 암호화 중 하나가 사용되고, Google 프로덕션 데이터 센터의 모든 데이터에 스토리지 기기 암호화가 사용됩니다.
하드웨어 및 인프라 레이어의 암호화
구현 세부정보는 시스템마다 다르지만 Google의 모든 스토리지 시스템은 유사한 암호화 아키텍처를 사용합니다. 데이터는 보관을 위해 하위 파일 청크로 분할됩니다. 각 청크는 크기별로 수 GB까지 다양할 수 있습니다. 각 청크는 개별 데이터 암호화 키(DEK)를 사용하여 스토리지 수준에서 암호화됩니다. 같은 고객이 소유하고 있거나 같은 머신에 저장되었더라도 2개의 청크가 동일한 DEK를 갖지 않습니다. (Datastore, App Engine, Pub/Sub의 데이터 청크에는 여러 고객의 데이터가 포함될 수 있습니다.)
데이터 청크가 업데이트되면 기존 키를 다시 사용하지 않고 새로운 키로 암호화됩니다. 각각 서로 다른 키를 사용한 이러한 데이터 파티셔닝으로 데이터 암호화 키가 손상될 위험이 해당 데이터 청크로만 제한됩니다.
Google은 데이터가 데이터베이스 스토리지 시스템 또는 하드웨어 디스크에 기록되기 전에 데이터를 암호화합니다. Google의 모든 스토리지 시스템에서 암호화는 이후에 추가되는 기능이 아니라 내장된 기능입니다.
각 데이터 청크에는 고유한 식별자가 있습니다. 액세스 제어 목록(ACL)은 승인된 역할(해당 시점에만 액세스 권한 부여)로 작동하는 Google 서비스만 각 청크를 복호화할 수 있도록 합니다. 이러한 액세스 제한은 승인 없이 데이터에 대한 액세스를 방지하여 데이터 보안 및 개인 정보 보호를 강화하는 데 도움이 됩니다.
각 청크는 Google의 스토리지 시스템에 분산되며, 백업 및 재해 복구를 위해 암호화된 형식으로 복제됩니다. 고객 데이터에 액세스하려는 공격자는 두 가지 사항(원하는 데이터에 해당하는 모든 스토리지 청크 및 청크에 해당하는 암호화 키)을 알아야 액세스할 수 있습니다.
다음 다이어그램은 데이터가 인프라에 업로드된 후 암호화된 청크로 분할되어 저장되는 방법을 보여줍니다.
Google은 AES 알고리즘을 사용하여 저장 데이터를 암호화합니다. 스토리지 수준의 모든 데이터는 기본적으로 AES-256을 사용하는 DEK로 암호화됩니다. 단, 2015년 이전에 생성되었고 AES-128을 사용하는 소수의 Persistent Disk는 예외입니다. AES-256 및 AES-128은 모두 미국 국립표준기술연구소(NIST)에서 장기 보관 용도로 권장하고 AES가 고객 규정 준수 요구사항으로 포함되는 경우가 많기 때문에 널리 사용됩니다.
저장 기기 레이어의 암호화
스토리지 시스템 수준 암호화 외에도 스토리지 기기 수준에서도 별도의 기기 수준 키(스토리지 수준에서 데이터 암호화를 위해 사용되는 키와 다름)를 사용하여 하드 디스크 드라이브(HDD) 및 솔리드 스테이트 드라이브(SSD)에 AES-256으로 데이터가 암호화됩니다. 소수의 기존 HDD는 AES-128을 사용합니다. Google에서 사용하는 SSD는 사용자 데이터에만 AES256을 구현합니다.
백업 암호화
Google 백업 시스템을 통해 백업 프로세스 전반에 걸쳐 데이터가 암호화된 상태로 유지됩니다. 이러한 방식은 일반 텍스트 데이터가 불필요하게 노출되는 것을 방지할 수 있습니다.
또한 백업 시스템은 자체 DEK를 사용하여 대부분의 백업 파일을 독립적으로 암호화합니다. DEK는 키 저장소에 저장된 키와 백업 시 무작위로 생성되는 파일별 시드에서 파생됩니다. 백업의 모든 메타데이터에 대해 다른 DEK가 사용되며, 키 저장소에도 저장됩니다.
저장 데이터에 대한 FIPS 규정 준수
Google은 프로덕션 환경에서 FIPS 140-2 검증 암호화 모듈(인증서 4407)을 사용합니다.
키 관리
Google에는 많은 양의 키가 사용되고 짧은 지연 시간과 고가용성이 요구되기 때문에 DEK는 암호화 대상 데이터 근처에 저장됩니다. DEK는 봉투 암호화라는 기술을 사용하여 키 암호화 키(KEK)로 암호화(래핑)됩니다. 이러한 KEK는 고객으로 한정되지 않으며 각 서비스에 하나 이상의 KEK가 존재합니다.
이러한 KEK는 특별히 키 보관 용도로 빌드된 저장소인 키 저장소에 중앙 집중식으로 저장됩니다. KEK를 DEK보다 적은 숫자로 유지하고 중앙 키 저장소를 사용하면 Google 규모의 데이터 저장 및 암호화를 쉽게 관리할 수 있으며, 중앙에서 데이터 액세스를 추적 및 제어할 수 있습니다.
Google Cloud에서 각 고객은 공유 리소스와 비공유 리소스를 가질 수 있습니다. 공유 리소스의 예시로는 Compute Engine의 공유 기본 이미지가 있습니다. 공유 리소스에 대해 여러 고객이 단일 DEK로 암호화되는 단일 복사본을 참조합니다. 비공유 리소스는 데이터 청크로 분할되고 다른 고객이 사용하는 키와 별도의 키로 암호화됩니다. 이러한 키는 같은 고객이 소유하는 같은 데이터의 다른 조각을 보호하는 키와도 구분됩니다. 하지만 둘 이상의 고객 데이터가 동일한 DEK로 암호화될 수 있는 예외(예: Datastore, App Engine, Pub/Sub)가 있습니다.
DEK 생성
스토리지 시스템은 Google의 공통 암호화 라이브러리를 사용하여 DEK를 생성합니다. 일반적으로 DEKS는 키 저장소로 전송되어 해당 스토리지 시스템의 KEK로 래핑되고 래핑된 DEK는 다시 스토리지 시스템으로 전달되어 데이터 청크와 함께 보존됩니다. 스토리지 시스템이 암호화된 데이터를 검색해야 할 때는 래핑된 DEK를 검색하고 이를 키 저장소에 전달합니다. 그런 다음 키 저장소는 이 서비스가 해당 KEK를 사용하도록 승인되었는지 확인합니다. 승인되었으면 키를 래핑 해제하고 일반 텍스트로 된 DEK를 서비스에 반환합니다. 그런 다음 서비스는 DEK를 사용해서 데이터 청크를 일반 텍스트로 복호화하고 무결성을 확인합니다.
모든 Google Cloud Storage 시스템은 이 키 관리 모델을 준수하지만 대부분의 시스템은 스토리지 측 KEK를 추가로 구현하여 키 계층 구조를 만듭니다. 이렇게 하면 시스템은 가장 높은 수준의 KEK(키 저장소에 저장됨)를 신뢰할 수 있는 루트로 사용하면서 짧은 지연 시간을 제공할 수 있습니다.
KEK 생성
데이터 청크 암호화에 쓰이는 KEK의 대부분은 키 저장소 내에서 생성되며, 나머지는 스토리지 서비스 내에서 생성됩니다. 일관성을 위해 모든 KEK는 Google이 만든 RNG(난수 생성기)를 사용하는 Google의 공통 암호화 라이브러리를 통해 생성됩니다. 이러한 RNG는 NIST 800-90Ar1 CTR-DRBG를 기반으로 하며 AES-256 KEK를 생성합니다. (이전에는 이것이 AES-128이었으며, 이러한 키 중 일부는 데이터 복호화를 위해 아직 유지되고 있습니다.)
Intel 및 AMD 프로세서의 경우 RNG는 RDRAND 안내 및 Linux 커널의 RNG에서 시드됩니다. 한편 Linux 커널의 RNG는 데이터 센터 환경의 RDRAND 및 엔트로피 이벤트를 포함하여 여러 독립적인 엔트로피 소스로부터 시드됩니다(예: 디스크 탐색에 대한 미세 측정 및 패킷 간 도착 시간). Arm 프로세서의 경우 RNG는 Linux 커널의 RNG에서 시드됩니다.
DEK는 Google Cloud 서비스에 따라 AES-256 또는 AES-128을 사용하는 KEK로 래핑됩니다. Google은 현재 Google Cloud 서비스의 모든 KEK를 AES-256으로 업그레이드하기 위해 노력하고 있습니다.
KEK 관리
키 저장소는 KEK 관리 목적으로만 빌드되었습니다. 기본적으로 스토리지 시스템에서 사용하는 KEK는 키 저장소에서 내보낼 수 없습니다. 이러한 키를 사용하는 모든 암호화 및 복호화는 키 저장소 내에서 수행되어야 합니다. 이를 통해 유출 및 오용을 방지할 수 있으며, 키 가 사용될 때 Keystore가 감사 추적을 만들 수 있습니다.
키 저장소는 Google의 공통 암호화 라이브러리로 새 키를 생성하여 주기적으로 KEK를 자동으로 순환할 수 있습니다. 이 문서에서 단일 키처럼 언급된 경우가 많지만, 실제로 데이터는 하나의 키 세트(암호화를 위한 활성 키 하나와 복호화를 위한 이전 키 세트)를 사용하여 보호됩니다. 이전 키 수는 키 순환 일정에 따라 결정됩니다. KEK는 재해 복구 목적으로 백업되고 무한정 복구할 수 있습니다.
KEK 사용은 키별 정책에 따라 키 저장소에서 각 키에 대한 ACL에서 관리됩니다. 승인된 Google 서비스 및 사용자만 키에 액세스할 수 있습니다. 각 키의 사용은 그 키를 요구하는 개별 작업 수준에서 추적되므로, 사용자가 키를 사용할 때마다 사용자가 인증되고 로깅됩니다. 사용자의 모든 데이터 액세스는 Google의 전체 보안 및 개인정보처리방침의 일환으로 감사 가능합니다.
암호화된 데이터 청크에 액세스하는 프로세스
Google 서비스가 암호화된 데이터 청크에 액세스할 때 다음 작업이 수행됩니다.
- 필요한 데이터를 얻기 위해 서비스에서 스토리지 시스템을 호출합니다.
- 스토리지 시스템이 해당 데이터가 저장된 청크를 식별하고(청크 ID), 저장된 위치를 확인합니다.
- 청크마다 스토리지 시스템이 청크와 함께 저장되어 있는 래핑된 DEK를 가져오고(일부 경우에 이 작업은 서비스에서 수행됨), 이를 래핑 해제하기 위해 키 저장소로 전송합니다.
- 스토리지 시스템이 작업 식별자와 청크 ID를 기준으로 식별된 작업이 해당 데이터 청크에 액세스하도록 허용되었는지 확인합니다. 키 저장소는 스토리지 시스템이 서비스와 연결된 KEK를 사용하고 해당 DEK를 래핑 해제하도록 승인되었는지 확인합니다.
- 키 저장소는 다음 중 하나를 수행합니다.
- 래핑 해제된 DEK를 다시 스토리지 시스템으로 전달해서 데이터 청크를 복호화하고 이를 서비스에 전달합니다.
- 드물지만 래핑 해제된 DEK를 서비스에 전달합니다. 스토리지 시스템이 암호화된 데이터 청크를 서비스로 전달하여, 서비스가 데이터 청크를 복호화하고 이를 사용합니다.
기기를 통해 기기 수준의 DEK를 관리하고 보호하는 전용 스토리지 기기에서는 과정이 다릅니다.
다음 다이어그램에서 이 프로세스를 볼 수 있습니다. 데이터 청크를 복호화하기 위해 스토리지 서비스가 키 저장소를 호출하여 해당 데이터 청크에 대해 래핑 해제된 DEK를 검색합니다.
암호화 키 계층 구조 및 신뢰할 수 있는 루트
키 저장소는 키 저장소 마스터 키라고 부르는 루트 키로 보호됩니다. 이 키는 키 저장소에 있는 모든 KEK를 래핑합니다. 이 키 저장소 마스터 키는 AES-256이며 자체적으로 루트 키 저장소라고 하는 다른 키 관리 서비스에 저장됩니다. (이전에는 키 저장소 마스터 키가 AES-128이었고, 이러한 키 중 일부는 데이터 복호화를 위해 아직 유지되고 있습니다.) 추가적인 보안을 위해 루트 키 저장소는 일반적인 프로덕션 머신에서 실행되지 않으며, 각 Google 데이터 센터에 있는 전용 머신에서만 실행됩니다.
루트 키 저장소에는 루트 키 저장소 마스터 키라고 하는 자체 루트 키가 있습니다. 이 키도 AES-256이고, 이러한 키를 전역으로 복제하는 루트 키 저장소 마스터 키 배포자라고 하는 P2P 인프라에 저장됩니다. (루트 키 저장소 마스터 키는 이전에는 AES-128이었고, 이러한 키 중 일부는 데이터 복호화를 위해 아직 유지되고 있습니다.) 루트 키 저장소 마스터 키 배포자는 루트 키 저장소와 동일한 전용 머신의 RAM에만 키를 저장하며, 적절한 사용을 확인하기 위해 로깅을 사용합니다.
루트 키 저장소 마스터 키 배포자의 새 인스턴스가 시작되면 배포자 인스턴스를 이미 실행 중인 호스트 이름 목록으로 새 인스턴스가 구성됩니다. 그런 다음 배포자 인스턴스가 다른 실행 중인 인스턴스에서 루트 키 저장소 마스터 키를 가져올 수 있습니다. 전역 가용성 및 복제에 설명된 재해 복구 메커니즘을 제외하고 루트 키 저장소 마스터 키는 특수 보안이 적용된 제한된 수의 머신에서 RAM에만 존재합니다.
루트 키 저장소 마스터 키 배포자의 모든 인스턴스가 동시에 다시 시작되는 시나리오에 대비하기 위해 루트 키 저장소 마스터 키가 안전한 하드웨어 기기에도 백업됩니다. 이 기기는 지리적으로 여러 곳에 분산된 엄격한 보안 구역 내 물리적 금고에 저장되어 있습니다. 이 백업은 리전의 모든 배포자 인스턴스가 한번에 중단되는 경우에만 필요합니다. 일부 Google 직원만 이러한 금고에 액세스할 수 있습니다.
다음 다이어그램은 암호화 키 계층 구조를 보여줍니다. 암호화 키 계층 구조는 키 저장소에서 KEK로 래핑된 DEK를 사용하여 데이터 청크를 보호하고 KEK는 다시 루트 키 저장소와 루트 키 저장소 마스터 키 배포자로 보호됩니다.
키 관리 요약
다음 목록에는 Google의 키 관리가 요약되어 있습니다.
- 데이터가 청크로 분할되고 DEK를 사용해서 암호화됩니다.
- DEK는 KEK로 암호화됩니다.
- KEK가 키 저장소에 저장됩니다.
- 키 저장소는 전 세계 데이터 센터의 여러 머신에서 실행됩니다.
- 키 저장소 키는 루트 키 저장소에 저장되는 키 저장소 마스터 키로 래핑됩니다.
- 루트 키 저장소는 키 저장소보다 훨씬 작고 각 데이터 센터에 있는 전용 머신에서만 실행됩니다.
- 루트 키 저장소 키는 루트 키 저장소 마스터 키 배포자에 저장되는 루트 키 저장소 마스터 키로 래핑됩니다.
- 루트 키 저장소 마스터 키 배포자는 전역적으로 전용 머신의 RAM에서 동시에 실행되는 P2P 인프라입니다. 각 머신은 해당 리전에서 실행 중인 다른 인스턴스에서 키 자료를 가져옵니다.
- 한 리전에 있는 배포자의 모든 인스턴스가 중단되는 경우 마스터 키는 제한된 Google 위치에 있는 물리적 금고의 서로 다른 보안 하드웨어에 저장됩니다.
전역 가용성 및 복제
고가용성, 짧은 지연 시간, 키에 대한 전역 액세스는 모든 수준에서 필수적입니다. Google의 키 관리 서비스는 이러한 특성을 갖추어야만 합니다.
따라서 키 저장소는 확장성이 높으며 전 세계 Google 데이터 센터에 수천 번 복제됩니다. 이 애플리케이션은 프로덕션 Fleet의 일반 머신에서 실행되며 키 저장소 인스턴스는 Google 작업을 지원하기 위해 전 세계적으로 실행됩니다. 그 결과 모든 단일 키 운영의 지연 시간이 매우 짧게 유지됩니다.
루트 키 저장소는 각 데이터 센터에 있는 여러 보안 운영용 머신에서 실행됩니다. 같은 머신에서 루트 키 저장소와 일대일 비율로 루트 키 저장소 마스터 키 배포자가 실행됩니다. 루트 키 저장소 마스터 키 배포자는 가십핑 프로토콜을 사용하여 배포 메커니즘을 제공합니다. 정해진 주기로 각 배포자 인스턴스가 무작위로 다른 인스턴스를 선택하여 키를 비교하고 키 버전이 다르면 조정합니다. 이 모델에서는 Google의 모든 인프라가 의존하는 중앙 노드가 없습니다. 이 배포 방법을 사용하면 고가용성을 지원하면서 키 자료를 유지관리하고 보호할 수 있습니다.
Google의 공통 암호화 라이브러리
Google의 공통 암호화 라이브러리는 FIPS 140-2 검증 모듈인 BoringCrypto가 통합된 Tink입니다. 모든 Google 개발자가 Tink를 사용할 수 있습니다. 공통 라이브러리를 일관적으로 사용한다는 것은 소수의 암호화 전문가 팀만 이 엄격하게 통제되고 검토된 코드를 구현하면 된다는 것을 의미하며, Google의 모든 팀이 자체 암호화를 독립적으로 개발할 필요가 없습니다. 모든 제품의 공통 암호화 라이브러리를 유지관리하는 작업은 특수 Google 보안팀에서 담당하고 있습니다.
Tink 암호화 라이브러리는 다양한 암호화 키 유형과 모드를 지원하며, 이들은 최신 공격에 대응할 수 있도록 정기적으로 검토됩니다.
현재 Google은 DEK 및 KEK를 위한 저장 데이터 암호화에 다음 암호화 알고리즘을 사용합니다. 이러한 알고리즘은 기능 및 보안이 향상되면서 변경될 수 있습니다.
| 암호화 기본 요소 | 선호 프로토콜 | 지원되는 기타 프로토콜 |
|---|---|---|
| 대칭적 암호화 | AES-GCM(256비트) |
|
| 대칭적 서명(인증을 위해 위의 AES-CBC 및 AES-CTR과 함께 사용) | HMAC-SHA256 |
|
다른 암호화 프로토콜도 이 라이브러리에 존재하며 지금까지 지원되었으나 이 표에서는 Google에서 주로 사용되는 프로토콜을 설명합니다.
암호화 기술 연구 및 혁신
암호화 기술 혁신에 발맞추어 Google은 암호화 기술을 숙지, 개발, 향상시키기 위한 세계적인 수준의 보안 엔지니어팀을 보유하고 있습니다. Google 엔지니어들은 표준화 절차 및 널리 사용되는 암호화 소프트웨어의 유지관리 과정에 참여하고 있습니다. Google은 일반 대중을 포함하여 누구나 Google의 연구 성과를 활용할 수 있도록 암호화 분야의 연구 결과를 정기적으로 발표하고 있습니다.
예를 들어 포스트 퀀텀 암호화 연구에서는 다음과 같은 영역을 연구하고 있습니다.
표준화: Google은 FIPS 205로 표준화된 스테이트리스(Stateless) 해시 기반 디지털 서명 스키마를 공동 설계했습니다. Google은 포스트 퀀텀 암호화 해시 기반 서명에 관한 국제표준화기구(ISO) 표준의 편집자이며 IETF의 해시 기반 서명을 위한 상태 관리 지침에 기여했습니다.
Enablement: 전송 계층 보안을 위해 내부 프로토콜에 포스트 퀀텀 암호화를 출시했습니다. Chrome에서 포스트 퀀텀 암호화 지원을 사용 설정했습니다. Tink 암호화 라이브러리에 여러 포스트 퀀텀 암호화 알고리즘을 추가했습니다. 이 코드는 실험용이며 커뮤니티에 각 접근 방식을 교육하는 데 도움이 되도록 설계되었습니다.
간행물: Google은 포스트 퀀텀 암호화로 조직 전환을 네이처에 게시했습니다. 이 문서에서는 포스트 퀀텀 암호화 마이그레이션 과제의 개요를 제공합니다. Google은 보안 키에서 포스트 퀀텀 암호화를 가져오는 연구 논문도 게시했습니다.
대칭적 암호화(AES-128 이상 사용)는 여전히 양자 공격에 강합니다.
다음 단계
Google Cloud에서 자체 암호화 키를 사용하는 방법에 대한 자세한 내용은 고객 관리 암호화 키(CMEK)를 참조하세요.
Google Cloud 보안에 대한 일반적인 정보는 Google Cloud 웹사이트의 보안 섹션을 참조하세요.
Google Cloud 규정 준수 및 규정 준수 인증에 대한 자세한 내용은 Google의 공개 SOC3 감사 보고서가 포함된 Google Cloud 웹사이트의 규정 준수 섹션을 참조하세요.
Google Workspace 암호화 및 키 관리에 대한 자세한 내용은 Google Workspace에서 암호화를 사용하여 데이터를 보호하는 방법 를 참조하세요. 이 방법은 여기에 포함된 동일한 내용의 대부분을 다루지만 Google Workspace에만 초점을 맞춥니다.