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

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

再生ボタン

Google Cloud での保存時の暗号化

CIO レベルの概要

  • Google では複数の暗号化レイヤを使用して、Google Cloud Platform プロダクト内のお客様の保存データを保護しています。
  • Google Cloud Platform は、1 つ以上の暗号化メカニズムを使用して、保存されているお客様のコンテンツを暗号化します。お客様による操作は必要ありません。ただし、いくつかの軽微な例外があります。詳細については、このドキュメントをご覧ください。
  • 保存するデータは複数のチャンクに分割され、各チャンクは一意のデータ暗号鍵で暗号化されます。これらのデータ暗号鍵はデータと一緒に保存されます。さらに Google の Key Management Service で保存され、使用される専用の暗号鍵によって、それが暗号化(「ラップ」)されます。Google の Key Management Service は冗長的で、グローバルに分散しています。
  • Google Cloud Platform に保存されるデータは、AES256 または AES128 を使用してストレージ レベルで暗号化されます。
  • Google は、共通暗号ライブラリの「Tink」を使用して、ほぼすべての Google Cloud Platform プロダクトに一貫した暗号化を実装しています。この共通ライブラリは広範に利用されているため、その厳密に管理およびレビューされたコードの実装や保守は、少人数で構成された 1 つの暗号作成者チームだけで行う必要があります。

はじめに

多くの人や企業にとって、セキュリティはパブリック クラウド ベンダーを選ぶための重要な基準です。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 アルゴリズムを使用して保存時の暗号化を行っています。AES が広く利用されているのは、(1)AES256 と AES128 の両方が長期保存用としてアメリカ国立標準技術研究所(NIST)により推奨されていて(2015 年 11 月現在)、(2)AES が顧客のコンプライアンス要件の一部となっていることが多いためです。

Google Cloud Storage で保存されているデータは AES を使用してストレージ レベルで暗号化されます。ほとんどの場合、Galois/Counter Mode(GCM)が使用されます。これは Google が管理する BoringSSL ライブラリで実装されています。このライブラリは、OpenSSL で数多くの欠陥が発見された後、内部使用のために OpenSSL を基に作成されました。選択の場合、AES は認証用に HMAC(ハッシュ化メッセージ認証コード)による CBC(暗号ブロック チェーン)モードで使用されます。複製された一部のファイルでは、AES は HMAC による CTR(カウンタ)モードで使用されます(アルゴリズムの詳細についてはこのドキュメントで後述します)。その他の 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 デベロッパーが利用できます。この共通ライブラリは広範囲からアクセスできるため、少人数の暗号作成者チームが 1 チームあれば、この厳密に管理および審査されたコードを実装するには十分です。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 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 1 時間ごと、最大 100 万件のメッセージ12

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 つのお客様のデータが存在することがあります。サービスによるデータ暗号化の粒度に関するセクションを参照してください。
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 に保存されます。
12 Cloud Pub/Sub は、メッセージの暗号化に使用する DEK を 1 時間ごとにローテーションします。暗号化するメッセージが 100 万件に達した場合は、1 時間経過していなくても DEK がローテーションされます。それぞれのお客様に一意であるわけではありません。
このページは役立ちましたか?評価をお願いいたします。

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