Google Cloud でのデータ削除

データ削除の動画のサムネイル

Google Cloud でのデータ削除

概要

CIO レベルの概要

  • Google では特定の原則に基づいてお客様データの保存と削除を行っています。Google Cloud は優れた速度、可用性、耐久性、整合性を実現できるように設計されていますが、こうしたパフォーマンス上の特性を満たすシステムを設計する場合、適切なタイミングでデータを削除する必要があるという点に配慮することが求められます。
  • お客様データを削除するための Google の削除パイプラインでは、まず削除リクエストを確認し、アプリケーション レイヤとストレージ レイヤから、さらにアクティブ、バックアップ双方のストレージ システムから、データを順に除去していきます。このプロセスの概要については、データの削除と保持に関する Google の方針説明をご覧ください。
  • 論理的削除は段階的に実施され、第 1 ステージではアクティブ ストレージ システムで直ちに削除するデータにマークを付け、そのデータをアプリケーション レイヤで通常の処理の対象から切り離します。Google のストレージ レイヤではコンパクションおよびマークアンドスイープの削除サイクルが連続して行われることで、削除対象データが上書きされていきます。削除されたデータを復元できないようにする暗号消去も使用されます。標準サイクルでは、最終的に Google のアクティブ システムのスナップショットを含むバックアップ システムが廃棄されます。
  • アプリケーション レイヤとストレージ レイヤからの削除は、データのストレージの構成とストレージ レイヤやデータセンターで進行している削除サイクル内のタイミングによって、即時実施される場合があります。通常、アクティブ システムからの削除は削除リクエストから約 2 か月以内で完了します。最終的にお客様データは Google の長期バックアップ システムからも削除されます。このバックアップ システムには、自然災害や重大な障害に備えて、Google システムのスナップショットが最長 6 か月間(180 日間)保持されます。

はじめに

このドキュメントでは、Google Cloud に保存されているお客様データを(Google Cloud のサービス利用規約の規定に従って)安全に削除するプロセスを簡単に説明します。ライフサイクルが終了したお客様データを安全に削除することは、すべてのコンピューティング プラットフォーム上のデータ処理における基本要件です。

可用性や速度が優れていること、どこからでもアクセスできること、データ喪失や障害に対する耐久性があることを目指すクラウド プラットフォームでは、データ処理の一環として、大量のデータを素早く削除するための技術イノベーションが求められます。Google は、膨大なデータ要素を処理するプロダクト向けのエンジニアリング ストレージ プラットフォームにいち早く取り組み、この業界で 10 年以上にわたって培った経験を活かして、この目標に最適な高パフォーマンス ストレージ システムの開発に力を注いでいます。

このホワイト ペーパーでは、まずお客様データがどのように Google Cloud に保存されるかについて簡単に説明します。次に、Google の削除パイプラインについて説明し、削除のそれぞれのステージに要する標準的な期間を示します。最後に、ハードウェアを安全にデコミッションして、サニタイズすることにより、Google のプラットフォームに保存されているデータが復元されないようにする方法について説明します。

データ ストレージとレプリケーション

Google Cloud でお客様データがどのように削除されるかを説明するために、まず Google インフラストラクチャでのデータ ストレージの仕組みについて簡単に説明します。Google Cloud で提供されているストレージ サービスには、Cloud Bigtable や Cloud Spanner などがあります。Google Cloud のアプリケーションやサービスのほとんどが、こうしたクラウド ストレージ サービスや、Google が使用する他の内部ストレージ サービスを介して間接的に Google のストレージ システムにアクセスします。

Google Cloud は、レイテンシが低く、可用性、スケーラビリティ、耐久性の高いソリューションを提供できることを目的としています。データ レプリケーションは、こうした重要なパフォーマンス目標の達成に不可欠な要素です。お客様データの冗長コピーは、お客様の構成やお客様のプロジェクトの要件に応じてローカルやリージョンごとに、場合によっては世界中に保存できます。Google Cloud のデータに対して行われた操作は複数のデータセンターに同時に複製されるので、お客様データの可用性が向上します。ハードウェア、ソフトウェア、ネットワーク環境でパフォーマンスに影響する変更が発生した場合、お客様データは自動的に別のシステムや施設に移行され(お客様の構成設定によって異なります)、お客様のプロジェクトはすべて中断することなく進行します。

物理ストレージ レベルでは、アクティブ ストレージ システムとバックアップ ストレージ システムという 2 種類のシステムにお客様データが保存されます。この 2 種類のシステムでは、データはそれぞれ異なる方法で処理されます。アクティブ ストレージ システムとは、Google のアプリケーション レイヤとストレージ レイヤが実行される Google Cloud Platform の本番環境サーバーです。アクティブ ストレージ システムは膨大な数のディスクとドライブのアレイで構成されています。このディスクやドライブを使用して新しいデータが書き込まれるだけでなく、複数の複製データのコピーも保存、取得されます。アクティブ ストレージ システムは、お客様データに対する実際の読み取り / 書き込みオペレーションが高速かつ大量に行えるように最適化されています。

Google のバックアップ ストレージ システムには、Google のアクティブ ストレージ システムの完全なコピーと差分コピーが決められた期間保存されます。これによって Google は、重大な障害や災害が発生したときにデータとシステムを復元できます。バックアップ ストレージ システムはアクティブ システムとは異なり、Google システムの定期スナップショットを受け取り、新しいバックアップ コピーを作成しながら、指定期間が経過した古いバックアップ コピーを廃棄するように設計されています。

これまで説明したストレージ システムでは、お客様データが保存時に暗号化されます。Google で採用されている暗号化方式の詳細については、Google のクラウドのセキュリティに関するホワイト ペーパーをご覧ください。保存データの暗号化は、アクティブ、バックアップのどちらのストレージ メディアでも、アプリケーション レイヤとストレージ レイヤで行われます。

安全で効果的なデータ削除

データ削除パイプライン

Google Cloud に保存されたお客様データは、Google のデータ削除パイプラインの全ステージを終えるまで安全に保存されます。このセクションでは、このプロセスについて詳しく説明します。

ステージ 1 - 削除リクエスト

お客様データの削除は、お客様からの削除リクエストをいただくことにより開始します。一般的に、削除リクエストの宛先は特定のリソース、Google Cloud Platform プロジェクト、またはお客様の Google アカウントです。削除リクエストの処理方法は、お客様のリクエストの対象範囲によって異なります。

  • リソースの削除: お客様データを含む個々のリソース(Google Cloud Storage バケットなど)は、Cloud Console や API を使用してさまざまな方法で削除できます。たとえば、コマンドラインからバケット削除(rm -r)コマンドを発行してストレージ バケットを削除できます。また、Cloud Storage ブラウザからストレージ バケットを選択して削除することもできます。
  • プロジェクトの削除: プロジェクトは Google Cloud プロジェクトの所有者がシャットダウンできます。プロジェクトの削除は、対応する project_number に関連付けられたすべてのリソースに対する一括削除リクエストとして機能します。
  • アカウントの削除: Google アカウントを削除すると、そのアカウントが単独で所有するすべての Google Cloud プロジェクトが削除されます。複数の所有者が所有しているプロジェクトは、所有者全員がそのプロジェクトから削除されるか、それぞれ自身の Google アカウントを削除するまで削除されません。このため、Google Cloud プロジェクトは、所有者がいる限り存続します。

削除リクエストは、本来お客様が自分のデータを管理するために使用しますが、削除リクエストが自動的に発行される場合もあります。お客様が Google との関係を解除した場合などです。

ステージ 2 - ソフト削除

ソフト削除は、プロセスの中で当然生じてくる段階のことで、誤って削除対象としてマークされたデータを復元する猶予期間となる、内部における短いステージングと復元の期間です。Google Cloud Platform の各プロダクトでは、Google の削除タイムラインの中に収まることを条件として、データが保存先のストレージ システムから削除される前のこうした定義済みの復元期間を導入および構成することを認めています。

たとえば、プロジェクトが削除される際、Google Cloud は最初に一意の project_number を識別し、その project_number を含む Google Cloud Platform プロダクト(App Engine や Cloud Bigtable など)に停止シグナルを配信します。この場合、App Engine ではその project_number をキーとするオペレーションを直ちに停止し、Cloud Bigtable 内の関連テーブルは内部復元期間(最長 30 日)に入ります。この復元期間が終わると、Google Cloud は同じプロダクトにシグナルをブロードキャストし、その一意の project_number に関連付けられたリソースの論理削除を開始するよう指示します。その後、待機し(必要に応じてシグナルを再配信し)、対象となったプロダクトからの確認応答シグナル(ACK)を受け取ってプロジェクトの削除を完了します。

Google アカウントが閉じられると、過去のアカウント アクティビティに応じて Google Cloud によって最長 30 日の内部復元期間が設けられます。その猶予期間が終わると、削除される請求先アカウントの user_id を含むシグナルが Google プロダクトにブロードキャストされ、その user_id だけに関連付けられている Google Cloud リソースが削除対象としてマークされます。

ステージ 3 - アクティブ ストレージ システムからの論理削除

データが削除対象としてマークされ、復元期間が終わると、データはまず Google のアクティブ ストレージ システムから削除され、次にバックアップ ストレージ システムから削除されます。アクティブ ストレージ システムでのデータの削除には、2 つの方法があります。

コンピューティング、Storage & Databases、ビッグデータの各分野のすべての Cloud プロダクトでは、Google Cloud Storage を除いて、削除対象のデータのコピーは使用可能なストレージとしてマークされ、上書きされていきます。アクティブ ストレージ システムでは、Cloud Bigtable と同様、削除対象のデータは大規模な構造化テーブル内のエントリとして保存されます。既存のテーブルを圧縮して削除対象のデータに上書きする場合、既存(削除対象でない)データのテーブルへの再書き込みが必要になり、その結果費用が高くなる可能性があります。そのため、マークアンドスイープ ガベージ コレクションおよび大規模なコンパクションのイベントがスケジュールに従って一定の間隔で実施され、ストレージ スペースの再利用と削除対象データへの上書きが行われます。

Google Cloud Storage では、お客様データの削除に暗号消去も使用されます。暗号消去は、データの復号化に必要な暗号鍵を削除することでデータを読めないようにする業界標準の手法です。暗号消去を使用するメリットの 1 つは、暗号鍵を Google が提供するかお客様が提供するかに関係なく、Google Cloud のアクティブとバックアップのストレージ システムで削除対象の全データブロックが上書きされる前に論理削除を完了できる点です。

ステージ 4 - 保存期間満了によるバックアップ ストレージ システムからのデータの削除

Google のアクティブ ストレージ システムと同様に、バックアップ ストレージ システムでも削除対象のデータは上書き手法と暗号手法のいずれかで削除されます。ただし、バックアップ システムでは通常、アクティブ システムの大量のスナップショット群の中にお客様データが保存されます。このスナップショット群は、障害発生時(データセンター全体に影響する停止の発生時など)、バックアップ システムからシステム全体を復元する時間と費用が必要になったときに事業を継続できるよう、一定期間保持されています。適切な事業継続手法に従い、アクティブ システムの完全なスナップショットと差分スナップショットが日ごと、週ごと、月ごとのサイクルで作成され、決められた期間が経過すると廃棄され、新しいスナップショットのためのスペースが確保されます。

廃棄されたバックアップは使用可能スペースとしてマークされ、日ごと、週ごと、月ごとの新しいバックアップが実施されると上書きされていきます。

適切に設定されたバックアップ サイクルには、バックアップ システム内をデータ削除リクエストが伝搬される際の遅延が事前定義され、適用されています。アクティブ システムから削除されたお客様データは、バックアップ システムにはコピーされません。削除前に行われたバックアップは、事前に定義されたバックアップ サイクルに基づいて順次期限切れになります。

なお、削除対象データの暗号消去は、お客様データを含むバックアップが期限切れになる前に行われる場合があります。お客様データの暗号化に使用された暗号鍵がなければ、そのお客様データは Google のバックアップ システムでの寿命が残っていても復元できなくなります。

削除のタイムライン

Google Cloud は優れた速度、可用性、耐久性、整合性を実現できるように設計されていますが、こうしたパフォーマンス上の特性を満たすシステムを設計する場合、適切なタイミングでデータを削除する必要があるという点に配慮することが求められます。Google Cloud では、お客様データを最長 6 か月(180 日)以内に削除するように取り組んでいます。この取り組みは、これまで説明した Google の削除パイプラインの次のようなステージを経て実現します。

  • ステージ 2 - 削除リクエストが行われると、通常、直ちにデータに削除対象のマークが付けられます。ここでの目標は、このステップを 24 時間以内に行うことです。データが削除対象としてマークされると、サービスや削除リクエストによっては、最長で 30 日の内部復元期間が適用されます。

  • ステージ 3 - ガベージ コレクション処理を行い、アクティブ システムからの論理削除を行うために必要な段階です。それぞれのプロセスは、データ レプリケーションのレベルや進行中のガベージ コレクション サイクルのタイミングによって、削除リクエストを受け取った直後に実施される場合があります。削除リクエストが行われた後、通常はアクティブ システムからデータを削除するまで約 2 か月かかります。2 か月あれば、大規模なガベージ コレクションを 2 サイクル完了し、論理削除を完了するのに十分です。

  • ステージ 4 - Google のバックアップ サイクルは、削除リクエストから 6 か月以内にデータセンターのバックアップ内の削除対象データを期限切れにするように設計されています。データ レプリケーションのレベルや、進行中のバックアップ サイクルのタイミングによって、削除が早めに行われる場合があります。

削除パイプラインの図 図 1: Google Cloud の削除パイプラインの各ステージ

セキュリティ対策を施した安全なメディア サニタイズ

Google Cloud の削除パイプラインに加え、統制のとれたメディア サニタイズ プログラムを導入すると、ライフサイクルが終了した物理ストレージ メディアに対するフォレンジック攻撃やラボラトリ攻撃を防いで、削除プロセスのセキュリティを強化できます。

Google のデータセンター内のすべてのストレージ機器に対し、設置場所と状況がきめ細かくトラッキングされます。機器の取得、設置、廃棄、破壊に至るまで、バーコードと資産タグによって Google の資産データベースでトラッキングされます。生体認証、金属検知、カメラ、車両障害物、レーザーによる侵入検出システムなど、さまざまな技術を駆使して、機器が許可なくデータセンターから外部に持ち出されないようにしています。詳細については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

物理ストレージ メディアがデコミッションされる理由はいろいろあります。ライフサイクル中に性能試験に合格しなかったコンポーネントは、在庫から除外され、廃棄されます。また、処理速度やエネルギー効率を向上させたりストレージ容量を増やしたりするために、古くなったハードウェアをアップグレードすることもあります。故障やアップグレードなど、デコミッションする理由の如何を問わず、適切な安全保護対策を行ったうえでストレージ メディアがデコミッションされます。デコミッション時には、Google ハードドライブにフルディスク暗号化(FDE)やドライブのロックなどの技術が適用され、保存データが保護されます。ハードドライブを廃棄する際には、ディスクのデータが消去されていることを所定の権限を持つ担当者が検証します。検証方法は、ドライブのデータをゼロで上書きしてから、複数ステップの検証プロセスを実施してドライブにデータがないことを確認します。

なんらかの理由でストレージ メディアのデータを消去できない場合は、メディアが物理的に破壊できる状況になるまで厳重に保管されます。Google は、使用可能な機器に応じて、ドライブを押しつぶして変形させたり、細かく砕いたりします。どちらの場合も、廃棄された Google ディスクは安全対策が施された施設でリサイクルされ、誰もディスクからデータを読み取れないようにします。各データセンターは、厳格な廃棄ポリシーに従い、ここで説明した手法を採用することで、NIST SP 800-88 Revision 1 の『Guidelines for Media Sanitization』と DoD 5220.22-M の『National Industrial Security Program Operating Manual』で定められた規格を満たします。