このコンテンツの最終更新日は 2024 年 5 月で、作成時点の状況を表しています。お客様の保護を継続的に改善するために、Google のセキュリティ ポリシーとシステムは変更される場合があります。
Google では、Google の包括的なセキュリティ戦略に含まれている保存データの暗号化により、顧客データを攻撃者から保護しています。Google では、お客様のすべてのコンテンツを 1 つ以上の暗号化メカニズムを使用して暗号化しています。お客様が特別な操作を行う必要はありません。このドキュメントでは、Google インフラストラクチャと Google Cloud で行われているデフォルトの保存データの暗号化と、それにより、顧客コンテンツの安全性をどのように高めているかについて説明します。
このドキュメントは、現在 Google を使用している、またはご利用を検討しているセキュリティ アーキテクトとセキュリティ チームを対象としています。このドキュメントは、暗号化と暗号プリミティブについて基本的な知識があることを前提としています。暗号の詳細については、最新の暗号の概要をご覧ください。
保存データの暗号化は、ディスク（SSD を含む）やバックアップ メディアに保存されているデータを保護するための暗号化です。Google で保存されるすべてのデータは、Advanced Encryption Standard（AES）アルゴリズムである AES-256 を使用してストレージ レイヤで暗号化されます。Google は、共通の暗号ライブラリである Tink を使用しています。このライブラリに含まれている FIPS 140-2 検証済みモジュール（BoringCrypto）により、Google Cloud 全体で一貫した暗号化を実装しています。
デフォルトの保存データの暗号化で使用される鍵は Google が所有し、管理しています。Google Cloud を使用する場合は、Cloud Key Management Service で独自の暗号鍵を作成し、エンベロープ暗号化をデータに追加できます。Cloud KMS を使用すると、鍵の作成、ローテーション、追跡、削除を行うことができます。詳細については、Cloud Key Management Service の詳細をご覧ください。
保存データの暗号化でデータを保護する方法
保存データの暗号化は、より広範なセキュリティ戦略の一部です。暗号化には次のようなメリットがあります。
- データが攻撃者に盗まれても、攻撃者が暗号鍵にアクセスできない限り、攻撃者はデータを読み取ることができません。攻撃者が顧客データを含むストレージ デバイスを取得したとしても、そのデータを理解することも、復号することもできません。
- ハードウェアとソフトウェア スタックの下位レイヤを切り離すことで攻撃対象領域を減らすことができます。
- 暗号化は「チョークポイント」にもなります。暗号鍵は一元管理されているため、データへのアクセスは必ずここを経由しなければならず、アクセスの監査も可能となります。
- すべてのデータを保護するのではなく、暗号鍵の保護戦略に取り組むことで、攻撃対象領域を減らすことができます。
- お客様に重要なプライバシー メカニズムを提供できます。保存データが暗号化されると、システムとエンジニアがデータにアクセスできる範囲が制限されます。
顧客データとは
Google Cloud 利用規約で定められているように、「顧客データ」とは、お客様またはエンドユーザーが自分のアカウントを使用して、サービス経由で Google に提供するデータです。
顧客コンテンツとは、Cloud Storage バケットに保存されているデータ、Persistent Disk ボリューム、Compute Engine で使用されるディスク スナップショットなど、お客様自身で作成したデータ、またはお客様が Google に提供したデータです。このドキュメントでは、このタイプの顧客データに対するデフォルトの保存データの暗号化について説明します。
顧客メタデータは顧客コンテンツに関するデータです。自動生成されたプロジェクト番号、タイムスタンプ、IP アドレス、Cloud Storage 内のオブジェクトのバイトサイズ、Compute Engine のマシンタイプなどが該当します。顧客メタデータは、進行中のパフォーマンスやオペレーションに対して妥当な範囲で保護されます。このドキュメントでは、メタデータの保護については取り上げません。
顧客データは顧客コンテンツと顧客メタデータで構成されます。
デフォルトの保存データの暗号化
Google では、お客様が何もしなくても、1 つ以上の暗号化メカニズムを使用して、保存されているすべての顧客コンテンツを暗号化します。以降のセクションでは、顧客コンテンツの暗号化で使用されるメカニズムについて説明します。
暗号化レイヤ
Google は複数の暗号化レイヤを使用してデータを保護しています。複数の暗号化レイヤを使用することにより、冗長データ保護機能が追加され、アプリケーションの要件に基づいて最適な手法を選択できるようになります。
次の図は、Google 本番環境のデータセンター内のユーザーデータを保護するために一般的に使用される、いくつかの暗号化レイヤを示しています。すべてのユーザー ファイルに対して、分散ファイル システムの暗号化またはデータベースとファイル ストレージの暗号化が使用されます。Google の本番環境データセンター内のすべてのデータに対して、ストレージ デバイスの暗号化が使用されます。
ハードウェアおよびインフラストラクチャ レイヤでの暗号化
Google のすべてのストレージ システムは類似した暗号化アーキテクチャを使用していますが、実装の詳細はシステムによって異なります。データは保存時にサブファイル チャンクに分割されます。各チャンクのサイズは数 GB に達する場合もあります。各チャンクは、ストレージ レベルで個別のデータ暗号鍵（DEK）を使用して暗号化されます。同じお客様が所有していても、また、同じマシン上に保存されていても、2 つのチャンクに同じ DEK が使用されることはありません（Datastore、App Engine、Pub/Sub のデータチャンクには顧客データが複数含まれていることがあります）。
データのチャンクが更新されると、元の鍵を再利用せず、新しい鍵を使用してこのチャンクを暗号化します。異なる鍵を使用してデータを分割するので、データ暗号鍵が悪用されても、侵害範囲はそのチャンクに限定されます。
Google は、データをデータベース ストレージ システムやハードウェア ディスクに書き込む前に暗号化します。暗号化は、Google のすべてのストレージ システムに当初から備わっている機能であり、後から追加されたものではありません。
各データチャンクには固有識別子があります。アクセス制御リスト（ACL）により、各チャンクを復号できるのは、その時点でアクセスが許可されている承認済みロールを持つ Google サービスに限定されます。これにより、承認なくデータにアクセスすることはできなくなり、データのセキュリティとプライバシーが強化されます。
各チャンクは Google のストレージ システム間に分散され、バックアップと障害復旧のために暗号化して複製されます。攻撃者が顧客データにアクセスしようとする場合、目的のデータに対応するすべてのストレージ チャンクと、それらのチャンクに対応する暗号鍵をすべて把握し、さらにそれらのアクセス権を得る必要があります。
次の図は、データが Google のインフラストラクチャにアップロードされ、保存用に暗号化されたチャンクに分割される方法を示しています。
Google では、AES アルゴリズムを使用して、保存データを暗号化します。ストレージ レベルのすべてのデータは、デフォルトで AES-256 を使用する DEK によって暗号化されます。ただし、2015 年より前に AES-128 を使用して作成された永続ディスクは例外です。AES-256 と AES-128 はともに長期保存用としてアメリカ国立標準技術研究所（NIST）によって推奨されているため、AES は広く使用されています。AES は多くの場合、お客様のコンプライアンス要件の一部に含まれます。
ストレージ デバイス レイヤでの暗号化
ストレージ システム レベルの暗号化に加えて、データはハードディスク ドライブ（HDD）とソリッド ステート ドライブ（SSD）用の AES-256 を使用して、ストレージ デバイス レベルで暗号化されます。個別のデバイスレベルの鍵が使用されますが、これはストレージ レベルでデータを暗号化する際に使用される鍵とは異なります。少数の古い HDD では AES-128 が使用されています。Google が使用する SSD では、ユーザーデータ専用の AES-256 が実装されています。
バックアップの暗号化
Google のバックアップ システムでは、バックアップ プロセス全体でデータが確実かつ継続的に暗号化されます。この方法により、平文データが不必要に暴露されるのを避けることができます。
さらに、バックアップ システムは、ほとんどのバックアップ ファイルを独自の DEK で個別に暗号化します。DEK は、キーストアに保存されている鍵と、バックアップ時にファイルごとにランダムに生成されるシードから導出されます。また、バックアップ時にはすべてのメタデータに対して別の DEK が使用されます。この DEK もキーストアに保存されています
保存データに関する FIPS の遵守
Google の本番環境では、FIPS 140-2 認定取得済みの暗号化モジュール（証明書番号 4407）が使用されています。
鍵管理
Google で使用する鍵は膨大な数にのぼり、また低レイテンシと高可用性を実現する必要があるため、DEK は暗号化対象のデータの近くに保存されます。DEK は、エンベロープ暗号化と呼ばれる技術を使用して、鍵暗号鍵（KEK）で暗号化（ラップ）されます。これらの KEK はお客様に固有のものではありません。サービスごとに 1 つ以上の KEK が存在します。
これらの KEK は、鍵を保存する専用のリポジトリであるキーストアに一元的に保存されます。KEK の数を DEK より少なくし、単一のキーストアによってそれらを集中管理することで、Google 規模のデータの保存と暗号化が扱いやすくなり、データの追跡や制御を 1 か所から行うことができます。
Google Cloud で、お客様は共有リソースと非共有リソースを使用できます。共有リソースの例としては、Compute Engine の共有ベースイメージがあります。共有リソースの場合、複数のお客様が単一のコピーを参照します。これは、1 つの DEK で暗号化されます。非共有リソースはデータチャンクに分割され、他のお客様が使用している鍵とは別の鍵で暗号化されます。さらに、同じお客様が所有する同じデータの他の部分を保護する鍵も、それぞれ異なるものが使われます。ただし、例外的に、複数のお客様のデータが同じ DEK で暗号化される場合があります（Datastore、App Engine、Pub/Sub など）。
DEK の生成
ストレージ システムは、Google の共通暗号ライブラリを使用して DEK を生成します。一般に、DEK はキーストアに送信され、そのストレージ システムの KEK でラップされます。ラップされた DEK は、データチャンクとともに保持されるようにストレージ システムに戻されます。ストレージ システムが暗号化データを取得する必要がある場合、ラップされた DEK を取得してからキーストアに渡します。キーストアはこのサービスが KEK の使用を承認されているかどうか確認して、承認されていればラップを解除し、平文の DEK をサービスに返します。サービスはこの DEK を使用してデータチャンクを平文に復号し、整合性を確認します。
すべての Google Cloud ストレージ システムはこの鍵管理モデルに従いますが、ほとんどのシステムでは、鍵の階層を作成するため、ストレージ レベルの KEK を追加で実装しています。これにより、最上位レベルの KEK（キーストアに保存）をルート オブ トラストとして使用しながら、低レイテンシを実現できます。
KEK の生成
データチャンクの暗号化に使用する KEK の大部分はキーストア内で生成され、残りはストレージ サービス内で生成されます。一貫性を確保するため、KEK はすべて Google の共通暗号ライブラリと Google が作成した乱数生成ツール（RNG）を使用して生成されます。この 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 Cloud サービスのすべての KEK を AES-256 にアップグレードする作業を進めています。
KEK の管理
キーストアは KEK の管理のみを目的として構築されました。設計上、ストレージ システムで使用される KEK はキーストアからエクスポートできません。これらの鍵を使用した暗号化と復号はすべてキーストア内で行う必要があります。これにより、漏えいや不正使用を防止でき、鍵を使用したキーストアの監査証跡を作成できます。
キーストアは一定の時間間隔で自動的に KEK をローテーションし、Google の共通暗号ライブラリを使用して新しい鍵を生成できます。鍵と言えば 1 つの鍵を指すことが多いですが、厳密にはデータは 1 組の鍵のセットで保護されています。つまり、暗号化にはアクティブな 1 つの鍵、復号には複数の履歴鍵を使用します。履歴鍵の数は鍵のローテーションのスケジュールで決まります。KEK は障害復旧を目的としてバックアップされ、無期限に復元可能です。
KEK の使用は鍵ごとに、鍵ごとのポリシーを使用して、キーストアの ACL で管理されます。承認された Google サービスとユーザーのみが鍵にアクセスできます。各鍵の使用状況は、鍵が必要な個々の操作ごとに追跡されます。つまり、ユーザーが鍵を使用すると、ユーザーが認証され、ログに記録されます。ユーザーによるすべてのデータアクセスは、Google 全体のセキュリティとプライバシー ポリシーの一環として監査できます。
暗号化されたデータチャンクにアクセスするプロセス
Google サービスが暗号化されたデータチャンクにアクセスすると、次のように処理されます。
- サービスがストレージ システムに対して必要なデータを要求します。
- ストレージ システムは、データが保存されているチャンク（チャンク ID）とそのチャンクが保存されている場所を特定します。
- チャンクごとに、ストレージ システムがそのチャンクと一緒に保存されているラップ済み DEK を取得し（この処理はサービスによって実行される場合もあります）、ラップ解除のためキーストアに送信します。
- ストレージ システムは、ジョブ ID とチャンク ID を使用して、特定されたジョブがデータチャンクにアクセスできることを検証します。キーストアは、ストレージ システムがサービスに関連付けられている KEK を使用し、その特定の DEK をラップ解除する権限を持っていることを確認します。
- キーストアは次のいずれかを行います。
- ラップ解除された DEK をストレージ システムに返します。これにより、データチャンクが復号され、サービスに渡されます。
- まれに、ラップ解除された DEK がサービスに渡されることがあります。ストレージ システムは、暗号化されたデータチャンクをサービスに渡します。このサービスはデータチャンクを復号して使用します。
専用ストレージ デバイスでは、このプロセスは異なり、デバイスがデバイスレベルの DEK を管理し、保護します。
次の図は、このプロセスを示しています。データチャンクを復号するために、ストレージ サービスはキーストアを呼び出し、そのデータチャンクのラップ解除された DEK を取得します。
暗号鍵の階層とルート オブ トラスト
キーストアは、キーストア KEK をすべてラップするキーストア マスター鍵というルート鍵で保護されています。このキーストア マスター鍵は AES-256 であり、Root Keystore という別の鍵管理サービスに保存されています（これまで、キーストア マスター鍵は AES-128 でしたが、一部の鍵はデータの復号に引き続き有効です）。セキュリティ強化のため、ルート キーストアは、一般的な本番環境マシンではなく、各 Google データセンターの専用マシンでのみ実行されます。
ルート キーストアには、ルート キーストア マスター鍵と呼ばれる独自のルート鍵があります。この鍵も AES-256 であり、ピアツーピア インフラストラクチャに保存されます。これは、ルートキーストア マスター鍵ディストリビューターと呼ばれ、鍵をグローバルに複製します（これまで、ルート キーストア マスター鍵は AES-128 でしたが、一部の鍵はデータの復号に引き続き有効です）。ルート キーストア マスター鍵ディストリビューターは、ルート キーストアと同じ専用機の RAM 内にのみ鍵を保持し、ロギングを使って鍵の使用が適切であるかを確認します。
ルート キーストア マスター鍵ディストリビューターの新しいインスタンスの実行にあたり、すでにディストリビューターのインスタンスを実行しているホストの名前のリストが構成されます。これにより、ディストリビューターのインスタンスは実行中の他のインスタンスからのルート キーストア マスター鍵を取得できるようになります。グローバルな可用性とレプリケーションで説明されている障害復旧メカニズムの場合を除き、ルート キーストア マスター鍵は専用のセキュリティが設定された少数の RAM にしかありません。
リージョン内のルート キーストア マスター鍵ディストリビューターのすべてのインスタンスが同時に再起動する場合に対応できるように、ルート キーストア マスター鍵も物理的に安全な場所に設置された安全なハードウェア デバイスにバックアップされ、地理的に分散した複数の地域のセキュリティで保護されます。このバックアップは、リージョン内のすべてのディストリビューター インスタンスを一度に停止させる場合にのみ必要です。これらに安全にアクセスできる Google の従業員はごく一部です。
次の図は、暗号鍵の階層を示しています。暗号鍵階層は DEK によりデータチャンクを保護しています。DEK はキーストアの KEK でラップされます。これらはルート キーストアとルート キーストア マスター鍵ディストリビューターにより保護されています。
鍵管理の概要
次のリストは、Google の鍵管理を要約したものです。
- データはチャンク化され、DEK で暗号化されます。
- DEK は KEK により暗号化されます。
- KEK はキーストアに保存されます。
- キーストアは全世界のデータセンターにある複数のマシンで実行されます。
- キーストア鍵は、キーストア マスター鍵でラップされます。この鍵はルート キーストアに保存されます。
- ルート キーストアはキーストアよりもはるかに小さく、各データセンターの専用マシンでのみ実行されます。
- ルート キーストア鍵は、ルート キーストア マスター鍵ディストリビューターでラップされます。この鍵は、ルート キーストア マスター鍵ディストリビューターに保存されます。
- ルート キーストア マスター鍵ディストリビューターは、世界各地の専用マシンの RAM 内で同時に実行されるピアツーピア インフラストラクチャです。各マシンは、リージョン内で実行中の他のインスタンスから鍵マテリアルを取得します。
- あるリージョンでディストリビューターのすべてのインスタンスが停止した場合、マスター鍵は、限られた Google ロケーションにある物理的に安全な別のハードウェアに保存されます。
グローバルな可用性とレプリケーション
どのレベルでも、高可用性、低レイテンシ、鍵へのグローバル アクセスが不可欠です。これらの特性は、Google 全体で鍵管理サービスを使用するために必要です。
このため、キーストアは非常にスケーラブルで、世界中のデータセンターに数千回も複製されています。これは、本番環境フリートの通常のマシンで実行されます。Google のオペレーションをサポートするためにキーストアのインスタンスがグローバルで実行されます。その結果、どの鍵オペレーションもレイテンシが非常に低くなります。
ルート キーストアは、各データセンターにあるセキュリティ運用専用の複数のマシンで実行されます。ルート キーストア マスター鍵ディストリビューターはこうしたマシンで実行され、ルート キーストアと 1 対 1 の関係にあります。ルート キーストア マスター鍵ディストリビューターは、ゴッシング プロトコルを使用する配布メカニズムを提供します。ディストリビューターは、一定の時間間隔で他のインスタンスをランダムに選択して鍵を比較し、鍵のバージョンの違いを調整します。このモデルでは、すべてのインフラストラクチャが依存する中央ノードはありません。この分散方式では、鍵マテリアルを高可用性で維持し、保護できます。
Google の共通暗号ライブラリ
Google は Tink という共通暗号ライブラリを使用しています。このライブラリには、Google の FIPS 140-2 認証取得済みモジュールの BoringCrypto が組み込まれています。Tink はすべての Google デベロッパーが利用できます。共通ライブラリを一貫して使用するということは、少人数の暗号作成者チームだけで、この厳重に管理およびレビューされたコードの実装とメンテナンスを行わなければならないことを意味します。つまり、Google のすべてのチームがそれぞれ独自の暗号を開発する必要はありません。専門の Google セキュリティ チームが、すべてのプロダクトを対象にこの共通暗号ライブラリの維持を行います。
Tink 暗号ライブラリは数多くの暗号鍵の種類やモードに対応しています。これらの暗号鍵は定期的に審査され、最新の攻撃に対応できるようになっています。
現在、Google では DEK と KEK の保存時に次の暗号化アルゴリズムを使用しています。Google の機能やセキュリティの強化に伴い、これらのアルゴリズムは変更される場合があります。
| 基本暗号 | 推奨されるプロトコル | サポートされるその他のプロトコル |
|---|---|---|
| 対称暗号化 | AES-GCM（256 ビット） |
|
| 対称署名（認証のため上記の AES-CBC および AES-CTR とあわせて使用されている場合） | HMAC-SHA256 |
|
他の暗号プロトコルもライブラリに存在し、以前はサポートされていましたが、このリストでは、Google で主に使用されているものを取り上げています。
暗号の研究とイノベーション
暗号化の進歩に対応するため、Google は世界クラスのセキュリティ エンジニアのチームを組み、暗号化技術の学習、開発、改良を進めています。Google のエンジニアは標準化プロセスと、一般的な暗号化ソフトウェアの維持管理に参加しています。Google は、一般の人々も Google の知識を活用できるように、暗号化分野の研究内容を定期的に公開しています。
たとえば、ポスト量子暗号の研究においては、次の分野に取り組んでいます。
標準化: FIPS 205 として標準化された、ハッシュベースのステートレス デジタル署名スキームを共同設計しました。Google は、ポスト量子暗号のハッシュベースの署名に関する国際標準化機構（ISO）標準の編集者であり、IETF のハッシュベースの署名に関する状態管理のガイダンスに貢献しています。
イネーブルメント: Google は、Transport Layer Security の内部プロトコルにポスト量子暗号を導入しました。Chrome でポスト量子暗号のサポートを有効にしました。Tink 暗号ライブラリに、いくつかのポスト量子暗号アルゴリズムを追加しました。このコードは、各アプローチについてコミュニティに伝えるための試験的なコードです。
出版物: Nature 誌に組織をポスト量子暗号に移行するを公開しました。本書では、ポスト量子暗号の移行に関する課題について説明しました。また、Google のセキュリティ キーでポスト量子暗号を実現する方法に関する研究論文も公開しました。
対称暗号（AES-128 以降を使用）は引き続き、量子攻撃に対する耐性があります。
次のステップ
Google Cloud で独自の暗号鍵を使用する方法については、顧客管理の暗号鍵（CMEK）をご覧ください。
Google Cloud セキュリティの一般的な情報については、Google Cloud ウェブサイトのセキュリティをご覧ください。
Google Cloud のコンプライアンスとそれに関連する認証については、Google Cloud ウェブサイトのコンプライアンスをご覧ください。このセクションには Google の公開 SOC3 監査レポートも掲載されています。
Google Workspace の暗号化と鍵管理については、Google Workspace での暗号化を使用したデータの保護をご覧ください。ここで説明するものとほぼ同じ内容を扱っていますが、Google Workspace だけに焦点を当てています。