Google Cloud Platform での保存時の暗号化

このドキュメントの内容は 2017 年 4 月時点のもので、作成時点の状況を表しています。お客様の保護を継続的に改善していくために、Google Cloud Platform のセキュリティ ポリシーとシステムは変更される場合があります。

再生ボタン

Google Cloud での保存時の暗号化

CIO レベルの概要

  • Google では、複数の暗号化レイヤを使用して、Google Cloud Platform プロダクト内にあるお客様の保存データを保護しています。
  • Google Cloud Platform では、1 つ以上の暗号化メカニズムを使用して、保存されているお客様のコンテンツを暗号化しています。お客様による操作は必要ありません。ただし、いくつかの小さな例外があります。詳細については、こちらのドキュメントをご覧ください。
  • 保存するデータは複数のチャンクに分割され、各チャンクは一意のデータ暗号鍵で暗号化されます。これらのデータ暗号鍵は別の暗号鍵によって暗号化(「ラップ」)されたうえでデータと一緒に保存されます。ラップに使われる暗号鍵の保存と運用は 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 のように公開されているものですが、実行には秘密の鍵を使用します。暗号テキストを元の形に復号するには、この鍵を使用する必要があります。Google では、暗号化を使用することでデータの機密保持とともに整合性維持も実現しています。暗号テキストにアクセスできても、鍵がわからなければ内容を理解することも変更することもできません。暗号化については、『Introduction to Modern Cryptography』も参照してください。

このホワイトペーパーでは、保存時の暗号化について説明しています。「保存時の暗号化」とは、ディスク(ソリッド ステート ドライブを含みます)またはバックアップ メディアに保存されているデータを保護するための暗号化を指します。

暗号化による顧客データの安全性の向上

暗号化は広範囲なセキュリティ戦略の一部です。暗号化により、データ保護のためのより高度な防御が可能になります。暗号化を使用すると、万が一攻撃者がデータを入手したとしても、暗号鍵がなければデータにアクセスすることはできません。データが保存されているストレージ デバイスを攻撃者が入手したとしても、そのデータを理解することも復号することもできません。

保存時の暗号化により、ハードウェアとソフトウェア スタックの下位レイヤが実質的に「切除」されるため、攻撃者が攻撃できる箇所が減ります。これらの下位レイヤが(デバイスへの物理的なアクセスなどにより)攻撃を受けても、適切な保護処理が行われていれば、これらのデバイスのデータには影響はありません。また暗号化は「チョークポイント」にもなります。暗号鍵は一元管理されているため、データへのアクセスは必ずここを経由しなければならず、アクセスの監査も可能となります。

暗号化は、Google が顧客データのプライバシーを確保するための重要なメカニズムです。これにより、コンテンツにアクセスしなくても、システムがバックアップなどの目的でデータを操作でき、エンジニアはインフラストラクチャのサポートができるようになります。

顧客データとして扱われるデータ

Google Cloud Platform 利用規約で定められているように、「顧客データ」とは、Google Cloud Platform のお客様(またはその指示を受けた者)により、そのお客様のアカウントで使用される Google Cloud Platform サービスを介して直接的または間接的に Google に提供されたコンテンツを指します。顧客データには、顧客コンテンツと顧客メタデータがあります。

「顧客コンテンツ」は、Google Cloud Platform のお客様が自身で作成したデータまたは Google に提供したデータです。Google Cloud Storage に保存したデータ、Google Compute Engine で使用されるディスク スナップショット、Cloud IAM ポリシーなどが該当します。このドキュメントで主に取り上げるのは、顧客コンテンツの保存時の暗号化です。

「顧客メタデータ」とは、顧客データの残りの部分、つまり顧客コンテンツとして分類できないすべてのデータを指します。自動生成されたプロジェクト番号、タイムスタンプ、IP アドレスや、Google Cloud Storage のオブジェクトのバイトサイズ、Google Compute Engine のマシンタイプなどが該当します。メタデータは、進行中のパフォーマンスやオペレーションに対して妥当な範囲で保護されます。

Google のデフォルトの暗号化

データ保存時の暗号化

暗号化レイヤ

Google では複数の暗号化レイヤを使用してデータを保護しています。複数の暗号化レイヤを使用することにより、冗長データ保護機能が追加され、アプリケーションの要件に基づいて最適な手法を選択できるようになります。

暗号化レイヤの図

図 1: Google Cloud Platform では保存されているデータを保護するために、複数の暗号化レイヤが使用されています。ほぼすべてのファイルで、分散ファイル システム暗号化またはデータベースおよびファイル ストレージ暗号化が使用されています。また、ほぼすべてのファイルでストレージ デバイス暗号化が使用されています。

ストレージ システム レイヤでの暗号化

Google Cloud Storage 暗号化の具体的な仕組みを理解するには、Google が顧客データをどのように保存しているかを理解する必要があります。データは保存にあたりサブファイル チャンクに分割されます。各チャンクのサイズは数 GB に達する場合もあります。各チャンクは、個別の暗号鍵を使ってストレージ レベルで暗号化されます。2 つのチャンクの暗号鍵が同じになることはありません。たとえそれら 2 つのチャンクが、同じお客様が所有する同じ Google Cloud Storage オブジェクトに属していても、あるいは同じマシンに保存されていても、これが当てはまります1。データのチャンクが更新されると、元の鍵を再利用せず、新しい鍵を使用してこのチャンクを暗号化します。このように分割されたデータのそれぞれが異なる鍵を使用するため、データ暗号鍵が漏えいしたとしても、被害範囲はそのデータチャンクだけにとどまります。

Google では、データをディスクに書き込む前にデータを暗号化します。暗号化は Google のすべてのストレージ システムに当初から備わっている機能であり、後から追加されたものではありません。

各データチャンクには一意の識別子があります。アクセス制御リスト(ACL)により、各チャンクを復号できるのは、その時点でアクセスが許可されている承認済み役割によって運用されている Google サービスのみであることが保証されます。これにより、承認なくデータにアクセスすることはできなくなり、データのセキュリティとプライバシーが強化されます。

各チャンクは複数の Google のストレージ システムに分散され、バックアップと障害復旧のために暗号化形式で複製されます。悪意のあるユーザーが顧客データに仮にアクセスしようとする場合、(1)目的のデータに該当するすべてのストレージ チャンクと、(2)それらのチャンクに対応する暗号鍵をすべて把握し、さらにそれらのアクセス権を得る必要があります。

暗号化チャンクに保存されたデータの図

図 2: Google のデータは保存にあたりチャンクに分割され暗号化されます。

Google は AES(Advanced Encryption Standard)アルゴリズムを使用して保存時の暗号化を行っています。AES が広く利用されているのは、(1)AES256 と AES128 がともに長期保存用としてアメリカ国立標準技術研究所(NIST)により推奨されていて(2019 年 3 月現在)、(2)AES が顧客のコンプライアンス要件の一部となっていることが多いためです。

Google Cloud Storage で保存されているデータは AES を使用してストレージ レベルで暗号化されます。ほとんどの場合、Galois/Counter Mode(GCM)が使用されます。これは Google が管理する BoringSSL ライブラリで実装されています。このライブラリは、OpenSSL で数多くの欠陥が発見された後、内部使用のために OpenSSL を基に作成されました。例外的に他のモードが使用される場合もあります。認証用には HMAC(ハッシュ化メッセージ認証コード)による CBC(暗号ブロック チェーン)モードで AES が使用されています。複製された一部のファイルでは、HMAC による CTR(カウンタ)モードで AES が使用されています(アルゴリズムの詳細についてはこのドキュメントで後述します)。その他の Google Cloud Platform プロダクトでは、AES はさまざまなモードで使用されます。

ストレージ デバイス レイヤでの暗号化

上記のストレージ システム レベルの暗号化に加えて、多くの場合、データはストレージ デバイスレベルでも暗号化されます。この暗号化には少なくとも、ハードディスク(HDD)では AES128、新しいソリッド ステート ドライブ(SSD)では AES256 が使用され、また個別のデバイスレベルの鍵が使用されます(これはストレージ レベルでのデータの暗号化に使用した鍵とは異なります)。デバイスの交換が進めば、デバイスレベルの暗号化では AES256 のみが使用されるようになります。

バックアップの暗号化

Google のバックアップ システムでは、バックアップ プロセス全体でデータが確実かつ継続的に暗号化されます。この方法により、プレーンテキスト データが不必要に暴露されるのを避けることができます。

さらに、このバックアップ システムでは独自のデータ暗号鍵(DEK)を使用して各バックアップ ファイルを個別に暗号化します。この DEK は、Google の鍵管理サービス(KMS)に保存されている鍵と、バックアップ時にランダムに生成されるファイル別のシードを使用して生成されます。また、バックアップ時にはすべてのメタデータに対して別の DEK が使用され、この DEK も Google の KMS に保存されます(鍵管理の詳細についてはこの後のセクションで説明します)。

データが保存時に暗号化されない場合

Google Cloud Platform は、お客様が特に何もしなくても、1 つ以上の暗号化メカニズムを使用して、保存されている顧客コンテンツを暗号化します。ただし、次のような例外があります。

  • Google Compute Engine の仮想マシンのシリアル コンソールログ。これについては現在修正中です。
  • プロセスで予期しない障害が発生した場合にローカル ドライブに書き込まれるコアダンプ。これについては現在修正中です。
  • ローカル ディスクに書き込まれるデバッグログ。これについては現在修正中です。
  • ストレージ システムが使用する一時ファイル。これについては現在修正中です。
  • 顧客コンテンツや顧客メタデータが含まれる可能性がある一部のログ。これについては今後修正予定です。

とはいえ、これらのデータは他の Google セキュリティ インフラストラクチャによって広範に保護されており、ほぼすべての場合、ストレージ レベルの暗号化によっても保護されます。

鍵管理

データ暗号鍵、鍵暗号鍵、Google の鍵管理サービス

チャンクのデータを暗号化するための鍵は「データ暗号鍵(DEK)」と呼ばれています。Google で使用する鍵は膨大な数にのぼり、また低レイテンシと高可用性を実現する必要があるため、これらの鍵は暗号化対象のデータの近くに保存されます。DEK は「鍵暗号鍵(KEK)」を使用して暗号化(「ラップ」)されます。Google Cloud Platform サービスごとに 1 つ以上の KEK があります。これらの KEK は Google の「鍵管理サービス(KMS)」に一括保存されています。これは鍵を保存するための専用のリポジトリです。KEK の数を DEK より少なくし、単一の鍵管理サービスによってそれらを集中管理することで、Google 規模のデータの保存と暗号化を扱いやすくなり、データの追跡や制御を 1 か所から行うことができるようになります。

Google Cloud Platform のお客様ごとに、すべての非共有リソース2がデータチャンクに分割され、他のお客様用に使われる鍵とは別の鍵で暗号化されます3。これらの DEK は、同じお客様が所有する、同じデータの他の部分を保護する DEK とも異なります。

DEK は、Google の共通暗号ライブラリを使用してストレージ システムによって生成されます。その後 KMS に送信され、そのストレージ システムの KEK でラップされます。ラップされた DEK はストレージ システムに戻され、データチャンクと一緒に保存されます。ストレージ システムが暗号化データを取得する必要がある場合、ラップされた DEK を取得してから KMS に渡します。KMS はこのサービスが KEK の使用を承認されているかどうか確認して、承認されていればラップを解除し、プレーンテキストの DEK をサービスに返します。サービスはこの DEK を使用してデータチャンクをプレーン テキストに復号し、整合性を確認します。

データチャンクの暗号化に使用する KEK の大部分は KMS 内で生成され、残りはストレージ サービス内で生成されます。一貫性を確保するため、KEK はすべて Google の共通暗号ライブラリと Google が作成した乱数生成ツール(RNG)を使用して生成されます。この RNG は NIST 800-90Ar1 CTR-DRBG に基づいていて、AES256 KEK を生成します4。この 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 によりラップされます。現在、Cloud サービスのすべての KEK を AES256 にアップグレードする作業を進めています。

Google の KMS は KEK 管理専用のサービスであり、その他の目的では使用されません。このサービスではセキュリティが最重要視されています。仕様により、Google の KMS から KEK をエクスポートすることはできません。これらの鍵を使用した暗号化と復号はすべて KMS 内で行う必要があります。これにより、漏えいや誤使用を防ぐことができ、また鍵の使用時に KMS が監査証跡を生成できます。

KMS は一定の時間間隔で自動的に KEK をローテーションし、Google の共通暗号ライブラリを使用して新しい鍵を生成することができます。「鍵」と言えば 1 つの鍵を指すことが多いですが、厳密にはデータは 1 組の鍵のセットで保護されています。つまり、暗号化にはアクティブな 1 つの鍵、復号には複数の履歴鍵を使用します。履歴鍵の数は鍵のローテーションのスケジュールで決まります。実際の 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 をサービスに渡します。ストレージ システムは暗号化されたデータチャンクをサービスに渡し、サービスはデータチャンクを復号して使用します。

ローカル SSD などの専用ストレージ デバイスではこのプロセスは異なり、デバイスがデバイスレベルの DEK を管理し、保護します。

データチャンク暗号化の図

図 3: データチャンクを復号するためにストレージ サービスが Google の鍵管理サービス(KMS)を呼び出し、そのデータチャンク用のラップ解除されたデータ暗号鍵(DEK)を取得します。

暗号鍵の階層と信頼のルート

Google の KMS は「KMS マスター鍵」と呼ばれるルート鍵で保護されています。この鍵は KMS のすべての KEK をラップします。この KMS マスター鍵は AES2564 であり、これ自体が、「ルート KMS」と呼ばれる別の鍵管理サービスに保存されています。ルート KMS に保存されている鍵はかなり少なく、12 個程度です。セキュリティ強化のため、ルート KMS は一般的な本番環境マシンでは実行されず、各 Google データセンターの専用機でのみ実行されます。

ルート KMS にも専用のルート鍵があり、「ルート KMS マスター鍵」と呼ばれています。この鍵も AES2564 であり、ピアツーピア インフラストラクチャに保存されています。このインフラストラクチャは「ルート KMS マスター鍵ディストリビュータ」と呼ばれていて、これらの鍵をグローバルに複製します。ルート KMS マスター鍵ディストリビュータはルート KMS と同じ専用機の RAM 内にのみ鍵を保持し、ロギングを使って鍵の使用が適切であるかを確認します。ルート KMS のインスタンスごとに、ルート KMS マスター鍵ディストリビュータのインスタンスが 1 つ実行されます(ルート KMS マスター鍵ディストリビュータの導入はまだ段階的ですが、同様の方式でピアツーピアではないシステムが順次置き換えられています)。

ルート KMS マスター鍵ディストリビュータの新しいインスタンスの実行にあたり、すでにディストリビュータのインスタンスを実行しているホストの名前のリストが構成されます。これにより、ディストリビュータのインスタンスは実行中の他のインスタンスからのルート KMS マスター鍵を取得できるようになります。後述の障害復旧メカニズムの場合を除き、ルート KMS マスター鍵は専用のセキュリティが設定された少数の RAM にしかありません。

ルート KMS マスター鍵ディストリビュータのすべてのインスタンスが同時に再起動する場合に対応できるように、Google の物理的に離れた 2 か所のグローバル ロケーションにある物理的に安全な場所に設置された安全なハードウェア デバイスにもルート KMS マスター鍵がバックアップされます。このバックアップが必要となるのは、ディストリビュータのすべてのインスタンスが同時に停止した場合(全世界で一斉に再起動する場合など)に限られます。これらの格納場所に立ち入ることができるのは、20 名に満たない Google 社員のみです。

Google の暗号化階層の図

図 4: 暗号鍵階層は DEK によりデータチャンクを保護しています。DEK は KMS の KEK でラップされ、KMS はルート KMS とルート KMS マスター鍵ディストリビュータにより保護されています。

まとめ

  • データはチャンク化され、DEK で暗号化されます。
  • DEK は KEK により暗号化されます。
  • KEK は KMS に保存されます。
  • KMS は全世界のデータセンターにある複数のマシンで実行されます。
    • KMS 鍵は、ルート KMS に保存された KMS マスター鍵でラップされます。
  • ルート KMS は KMS よりはるかに規模が小さく、各データセンターの専用機でのみ実行されます。
    • ルート KMS 鍵は、ルート KMS マスター鍵ディストリビュータに保存されているルート KMS マスター鍵によりラップされます。
  • ルート KMS マスター鍵ディストリビュータは、専用機の RAM 内でグローバルかつ同時に実行されるピアツーピア インフラストラクチャです。ルート KMS マスター鍵ディストリビュータの各インスタンスは、実行中の他のインスタンスから鍵材料を取得します。
    • ディストリビュータのすべてのインスタンスが停止する場合(全体シャットダウン)、マスター鍵は限られた Google 拠点の(物理的な)格納場所にある(別々の)安全なハードウェアに保存されます。
    • ルート KMS マスター鍵ディストリビュータの導入は現在進行中であり、同様の方式でありながらピアツーピアではないシステムがルート KMS マスター鍵ディストリビュータに順次置き換えられています。

グローバルな可用性とレプリケーション

高可用性と低レイテンシ、鍵へのグローバルなアクセスはすべてのレベルで特に重要です。鍵管理サービスを Google 全体で使用できるようにするには、これらの特性が必須となります。

このため、KMS はスケーラブルなものになっており、世界中の Google のデータセンターで何千回も複製されています。KMS は Google の本番環境で使用されている一般的なマシンで実行されます。KMS のインスタンスはグローバルで実行され、Google Cloud Platform のオペレーションをサポートします。その結果、どの鍵オペレーションもレイテンシが非常に低くなります。

ルート KMS は各データセンターにあるセキュリティ オペレーション専用の複数のマシンで実行されます。ルート KMS マスター鍵ディストリビュータはこれらのマシンで実行され、ルート KMS と 1 対 1 の関係にあります。ルート KMS マスター鍵ディストリビュータは ゴシッピング プロトコルによる配布メカニズムを実現しています。ディストリビュータの各インスタンスは、一定の時間間隔でランダムに他のインスタンスを選択して鍵を比較し、鍵のバージョンの差異を一致させます。このモデルにより、Google のすべてのインフラストラクチャが 1 つのノードに依存することはなくなり、Google は高可用性を確保しながら鍵材料の維持と保護を行うことができます。

Google の共通暗号ライブラリ

Google は Tink5 という共通暗号ライブラリを使用しています。このライブラリは、BoringSSL6 を使用した暗号アルゴリズムを実装します。Tink はすべての Google デベロッパーが利用できます。この共通ライブラリは広範囲からアクセスできるため、この厳密に管理および審査されたコードの実装を少人数の暗号作成者からなる単一のチームによって行うことが可能になっています。Google のすべてのチームが自身で暗号を作成する必要はありません。専門の Google セキュリティ チームが、すべてのプロダクトを対象にこの共通暗号ライブラリの維持を行います。

Tink 暗号ライブラリは数多くの暗号鍵の種類やモードに対応しています。これらの暗号鍵は定期的に審査され、最新の攻撃に対応できるようになっています。

このドキュメントの発行時点において、Google は次の暗号化アルゴリズムを使用して DEK と KEK の保存時の暗号化を行っています。Google の機能やセキュリティの強化に伴い、これらのアルゴリズムは変更される場合があります。

基本暗号 推奨されるプロトコル サポートされるその他のプロトコル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(1 つの DEK で暗号化されるデータのサイズ)
ストレージ Cloud Bigtable データチャンクごと(テーブルごとに複数)
Cloud Datastore データチャンクごと9
Cloud Firestore データチャンクごと9
Cloud Spanner データチャンクごと(テーブルごとに複数)
Cloud SQL
  • 第 2 世代: インスタンスごと。Google Compute Engine と同様(各インスタンスには複数のデータベースを格納可能)
  • 第 1 世代: インスタンスごと
Cloud Storage データごとのチャンク(通常は 256 KB~8 MB)
コンピューティング 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

Cloud のお客様向けのその他の暗号化オプション

Google Cloud Platform のデフォルトの暗号化だけでなく、より高度な制御のため追加の暗号化オプションと鍵管理オプションの準備も進めています。

Google が目指しているのは、Google Cloud Platform のお客様が次のことをできるようにすることです。

  • データの最終管理者となり、データのセキュリティとプライバシーの両方を確保するためにそのデータのアクセスと使用を細かい粒度で制御できるようにする。
  • クラウドでホストしているデータの暗号化を、現在のオンプレミスと同等またはそれ以上の水準で管理する。
  • リソース全体で、証明可能かつ監査可能な信頼のルートを使用する。
  • ACL の使用以外の方法も利用してデータをさらに分離する。

お客様は、Google Cloud Platform で管理している既存の暗号鍵を、顧客指定の暗号鍵機能により使用することができます。この機能は Google Cloud Storage で使用できるほか、Google Compute Engine でもストレージ レイヤの暗号化に使用できます。

Google Cloud Key Management Service(Cloud KMS)を使用して Google Cloud Platform 上で独自の暗号鍵を管理することもできます。このプロダクトでは、アプリケーション レイヤの暗号化をお客様自身で管理することができます。

暗号化の研究とイノベーション

暗号化の進歩に対応するため、Google は世界クラスのセキュリティ エンジニアのチームを組み、暗号化技術の学習、開発、改良を進めています。Google のエンジニアは標準化プロセスと、一般的な暗号化ソフトウェアの維持管理に参加しています。 Google では暗号化に関連する研究の内容を定期的に公開し、業界関係者や一般の人々が Google の知識を活用できるようにしています。たとえば、2014 年には SSL 3.0 暗号化に(POODLE と呼ばれる)重大な脆弱性があることを発見し、2015 年には OpenSSL にリスクの高い脆弱性があることを突き止めました。

Google はクラウド サービスにおいて業界最先端となるべく計画を進めています。新しい暗号化技術の開発、実装、研究のため、Google ではチームを編成して以下の項目に取り組んでいます。

  • 部分的準同型暗号。これは、暗号化されたままのデータに対して一部のオペレーションを行えるようにする技術です。これが実現されると、メモリ内のデータであってもプレーンテキスト形式で読み取れなくなります。この技術の活用例として、Google が実験的に導入している暗号化 BigQuery クライアントが挙げられます。このサービスは一般公開されています。
  • 形式保存暗号および順序保存暗号。これは、暗号化されたままのデータに対して一部の比較演算とランキング演算を行えるようにする技術です。
  • ポスト量子暗号。これが実現されると、巧妙な量子攻撃に弱い既存の暗号プリミティブを、このような攻撃に強いとされるポスト量子暗号に置き換えることができます。これは格子ベースの公開鍵暗号の研究とプロトタイプ化の分野で最も注目されています。これには NIST が推奨するポスト量子アルゴリズムも含まれます。格子ベースの暗号は現在、ポスト量子世界で利用される可能性が最も高い暗号化技術のひとつと考えられていますが、最善のアルゴリズム、具体的なパラメータ、暗号解析という点で歴史が浅く、まだこの技術を応用できる段階には至っていません。対称鍵暗号化と MAC は既知の量子アルゴリズムによって弱体化したものの、鍵のサイズを倍にすることにより、ポスト量子世界で同等のセキュリティ ビットにアップグレードできます。

その他のリファレンス

Google Cloud Platform のセキュリティ

Google Cloud Platform セキュリティの一般的な情報については、Google Cloud Platform ウェブサイトのセキュリティを参照してください。

Google Cloud Platform のコンプライアンス

Google Cloud Platform のコンプライアンスとコンプライアンス証明書については、Google Cloud Platform ウェブサイトのコンプライアンスをご覧ください。このセクションには Google の公開 SOC3 監査レポートも掲載されています。

G Suite のセキュリティ

G Suite の暗号化と鍵管理については、G Suite 暗号化に関するホワイトペーパーを参照してください。このホワイトペーパーはここで説明するものとほぼ同じ内容を扱っていますが、G Suite だけに焦点を当てています。Google はすべての G Suite ソリューションについて、顧客データの保護に努め、セキュリティ保護の方式についても可能な限り透明性を確保するよう努めています。G Suite のセキュリティに関する一般的な情報については、G Suite のセキュリティとコンプライアンスに関するホワイトペーパーを参照してください。

脚注

1 Cloud Datastore、App Engine、Cloud Pub/Sub のデータチャンクには複数のお客様のデータが存在することがあります。サービスによるデータ暗号化の粒度に関するセクションを参照してください。
2 この分離が適用されない共有リソースの例として、Google Compute Engine の共有ベースイメージが挙げられます。このイメージでは、複数のお客様が、単一の DEK で暗号化された単一のコピーを参照します。
3 例外として、Cloud Datastore、App Engine、Cloud Pub/Sub に保存されるデータの場合、同じ DEK で複数のお客様のデータが暗号化されることがあります。サービスによるデータ暗号化の粒度に関するセクションをご覧ください。
4 以前は AES128 でした。また、これらの鍵のいくつかはデータ復号のために引き続きアクティブのままです。
5 Google は「Keymaster」と「CrunchyCrypt」の 2 つのライブラリも使用しています。Keymaster は Tink と共通の新しい暗号コードを共有しますが、異なる鍵バージョニングを実装し、古いアルゴリズムにも対応しています。CrunchyCrypt は Tink にマージされました。
6 OpenSSL も Google Cloud Storage のいくつかの場所で使用されています。
7 他の暗号プロトコルもライブラリに存在し、以前はサポートされていましたが、このリストでは Google Cloud Platform で主に使用されているものを取り上げています。
8 顧客コンテンツの暗号化の粒度を指します。これにはリソース名などの顧客メタデータは含まれません。一部のサービスでは、すべてのメタデータが 1 つの DEK で暗号化されます。
9 それぞれのお客様に一意であるわけではありません。
10 アプリケーション コードやアプリケーション設定が含まれます。App Engine で使用されるデータは、お客様の構成により、Cloud Datastore、Cloud SQL または Cloud Storage のいずれかに保存されます。
11 ファンクション コード、設定、イベントデータが含まれます。イベントデータは Cloud Pub/Sub に保存されます。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...