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

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

Google Cloud Encryption による保存時の暗号化

CIO レベルの概要

  • Google では、複数の暗号化レイヤを使用して、Google Cloud Platform プロダクト内のお客様の保存データを保護しています。
  • Google Cloud Platform では、1 つ以上の暗号化メカニズムを使用して、保存されているお客様のコンテンツを暗号化しています。お客様による操作は必要ありません。ただし、いくつかの細かな例外があります。詳細については、このドキュメントをご覧ください。
  • 保存するデータは複数のチャンクに分割されます。各チャンクは一意のデータ暗号鍵で暗号化されます。これらのデータ暗号鍵はデータとあわせて保存され、Google の Key Management Service で独占的に保存され、使用される暗号鍵で暗号化(「ラップ」)されます。Google の Key Management Service は冗長的で、グローバルに分散しています。
  • Google Cloud Platform に保存されるデータは AES256 または AES128 を使用してストレージ レベルで暗号化されます。
  • Google では、共通暗号ライブラリ「CrunchyCrypt」を使用して、ほぼすべての 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 より少なくして、1 つの鍵管理サービスにより一括管理することにより、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 社員のみです。

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

まとめ

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

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

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

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

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

Google の共通暗号ライブラリ

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

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

このドキュメントの発行時点においては、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 で暗号化されるデータのサイズ)
ストレージ クラウドのBigtable データチャンクごと(テーブルごとに複数)
Cloud Datastore データチャンクごと9
Cloud Spanner データチャンクごと(テーブルごとに複数)
Cloud SQL
  • 第 2 世代: インスタンスごと。Google Compute Engine と同様(各インスタンスには複数のデータベースを格納可能)
  • 第 1 世代: インスタンスごと
クラウド ストレージ データごとのチャンク(通常は 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 Cloud Platform 顧客が次の作業をできるようにすることが目標です。

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

顧客は、Google Cloud Platform で管理している既存の暗号鍵を、ユーザー入力暗号鍵機能により使用することができます。この機能は、ストレージ レイヤの暗号化用として Google Cloud StorageGoogle 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 の共有ベースイメージがあげられます。ここでは、複数の顧客が、1 つの DEK で暗号化された 1 つのコピーを参照しています。
3 Cloud Datastore、App Engine、Cloud Pub/Sub に保存されたデータは例外で、同じ DEK で複数の顧客のデータを暗号化できます。サービスによるデータ暗号化の粒度に関するセクションを参照してください。
4 以前は AES128 でした。また、これらの鍵の一部はデータ復号化のためアクティブのままとなります。
5 Google では別のライブラリ「Keymaster」も使用しています。Keymaster は CrunchyCrypt と共通の新しい暗号コードを共有しますが、異なる鍵バージョニングを実装し、古いアルゴリズムにも対応しています。
6 OpenSSL も Google Cloud Storage の一部で使用されています。
7 他の暗号プロトコルもライブラリにあり、以前はサポートされていましたが、このリストは Google Cloud Platform で主に使用されるものを取り上げています。
8 顧客コンテンツの暗号化の粒度を指します。これにはリソース名などの顧客メタデータは含まれません。一部のサービスでは、すべてのメタデータが 1 つの DEK で暗号化されます。
9 1 顧客について一意であるわけではありません。
10 アプリケーション コードやアプリケーション設定が含まれます。App Engine で使用されるデータは、顧客の構成により、Cloud Datastore、Cloud SQL または Cloud Storage のいずれかに保存されます。
11 機能コード、設定、イベントデータが含まれます。イベントデータは Cloud Pub/Sub に保存されます。
12 Cloud Pub/Sub はメッセージの暗号化に使用する DEK を 1 時間ごとにローテーションします。暗号化するメッセージが 100 万件に達する場合はこの間隔が短くなります。顧客について一意であるわけではありません。

このページは役立ちましたか?評価をお願いいたします。

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