このコンテンツの最終更新日は 2024 年 5 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。
このドキュメントでは、Google Cloud でお客様のデータを削除する際にとられる安全なプロセスの概要を説明します。Google Cloud 利用規約で定義されているように、「顧客データ」とは、お客様またはエンドユーザーが自分のアカウントを使用して、サービス経由で Google に提供するデータです。
このドキュメントでは、Google Cloud に顧客データを保存する方法、削除パイプライン、Google プラットフォームに保存されたデータの再構築を防止する方法について説明します。
データ削除のコミットメントについては、Cloud のデータ処理に関する追加条項（お客様向け）をご覧ください。
データ ストレージとレプリケーション
Google Cloud では、Bigtable や Spanner などのストレージ サービスとデータベース サービスを提供しています。ほとんどの Google Cloud アプリケーションとサービスは、これらのクラウド サービスを使用して Google のストレージ インフラストラクチャに間接的にアクセスします。
データ レプリケーションは、レイテンシが低く、可用性、スケーラビリティ、耐久性の高いソリューションを実現するために不可欠です。顧客データの冗長コピーは、お客様の構成やお客様のプロジェクトの要件に応じてローカルやリージョンごとに、場合によっては世界中に保存できます。Google Cloud のデータに対して行われた操作は複数のデータセンターに同時に複製されるので、顧客データの可用性が向上します。パフォーマンスに影響する変更がハードウェア、ソフトウェア、ネットワーク環境で行われた場合、顧客データは自動的に別のシステムや施設に移行され（お客様の構成設定によって異なります）、お客様のプロジェクトはすべて中断することなく進行できます。
物理ストレージ レベルでは、アクティブ ストレージ システムとバックアップ ストレージ システムという 2 種類のシステムにお客様のデータが保存されます。この 2 種類のシステムでは、データはそれぞれ異なる方法で処理されます。アクティブ ストレージ システムは、Google のアプリケーション レイヤとストレージ レイヤを実行する Google Cloud の本番環境サーバーです。アクティブ ストレージ システムは膨大な数のディスクとドライブのアレイで構成されています。このディスクやドライブを使用して新しいデータが書き込まれるほか、複数の複製されたコピーのデータの保存や取得が行われます。アクティブ ストレージ システムは、顧客データに対する実際の読み取り / 書き込みオペレーションが高速かつ大量に行えるように最適化されています。
Google のバックアップ ストレージ システムには、Google のアクティブ ストレージ システムの完全なコピーと差分コピーが決められた期間格納されます。これによって Google は、重大な障害や災害が発生したときにデータとシステムを復元できます。バックアップ ストレージ システムはアクティブ システムとは異なり、Google システムの定期スナップショットを受け取り、新しいバックアップ コピーを作成しながら、指定期間が経過した古いバックアップ コピーを廃棄するように設計されています。
これまで説明したストレージ システムでは、顧客データが保存時に暗号化されます。詳細については、デフォルトの保存データの暗号化をご覧ください。
データ削除パイプライン
顧客データが Google Cloud に保存された後、データ削除パイプラインの全ステージを終えるまで安全に保存されます。このセクションでは、削除のステージについて説明します。
ステージ 1: 削除リクエスト
顧客データの削除は、削除リクエストを開始した時点で開始されます。一般的に、削除リクエストの宛先は特定のリソース、Google Cloud プロジェクト、またはお客様の Google アカウントです。削除リクエストの処理方法はリクエストの対象範囲によって異なります。
- リソースの削除: Cloud Storage バケットなど、顧客データを含む個々のリソースは、Google Cloud コンソールまたは API を使用してさまざまな方法で削除できます。たとえば、remove bucket コマンドまたは
gcloud storage rmコマンドを発行して、コマンドラインからストレージ バケットを削除できます。また、Google Cloud コンソールでストレージ バケットを選択して削除することもできます。 - プロジェクトの削除: プロジェクトは Google Cloud プロジェクトの所有者がシャットダウンできます。プロジェクトの削除は、対応するプロジェクト番号に関連付けられたすべてのリソースに対する一括削除リクエストとして機能します。
- Google アカウントの削除: Google アカウントを削除すると、組織に関連付けられていない、そのアカウントが単独で所有するプロジェクトがすべて削除されます。組織外プロジェクトのオーナーが複数存在する場合、オーナー全員がプロジェクトから削除されるか、オーナーの Google アカウントが削除されるまで、プロジェクトは削除されません。このプロセスにより、プロジェクトはオーナーがいる限り存続します。
- Google Workspace または Cloud Identity アカウントの削除: Google Workspace または Cloud Identity アカウントを削除すると、そのアカウントに関連付けられている組織も削除されます。詳しくは、組織の Google アカウントを削除するをご覧ください。
削除リクエストは主にデータを管理するために使用します。ただし、Google との関係を解消する場合など、Google が削除リクエストを自動的に発行することもあります。
ステージ 2: ソフト削除
ソフト削除とは、誤って削除対象としてマークされたデータを復元する猶予時間を確保するために、プロセス中に発生する時点で内部のステージングおよび復元のために短い期間を設けることです。Google Cloud では、保存先のストレージ システムからデータが削除される前の復元期間が定義されており、Google の削除タイムラインの中に収まることを条件として、個々のプロダクトでこの復元時間が導入および構成されていることがあります。
プロジェクトが削除されると、Google Cloud はまず一意のプロジェクト番号を識別し、そのプロジェクト番号を含む Google Cloud プロダクト（Compute Engine や Bigtable など）に停止シグナルをブロードキャストします。この場合、Compute Engine はそのプロジェクト番号をキーとするオペレーションを停止し、Bigtable 内の関連テーブルは内部復元期間（最長 30 日）に入ります。この復元期間が終わると、Google Cloud は同じプロダクトにシグナルをブロードキャストし、その一意のプロジェクト番号に関連付けられたリソースの論理削除を開始するよう指示します。その後、待機し（必要に応じてシグナルを再配信し）、対象となったプロダクトからの確認応答シグナル（ACK）を受け取ってプロジェクトの削除を完了します。
Google アカウントが閉じられると、過去のアカウント アクティビティに応じて Google Cloud によって最長 30 日の内部復元期間が設けられます。猶予期間が終了すると、削除される請求先アカウントのユーザー ID を含むシグナルが Google プロダクトにブロードキャストされ、そのユーザー ID だけに関連付けられている Google Cloud リソースが削除対象としてマークされます。
ステージ 3: アクティブ ストレージ システムからの論理削除
データが削除対象としてマークされ、復元期間が終わると、データはまず Google のアクティブ ストレージ システムから削除され、次にバックアップ ストレージ システムから削除されます。アクティブ ストレージ システムでのデータの削除には、2 つの方法があります。
コンピューティング、ストレージ、データベースの各プロジェクト カテゴリ（Cloud Storage を除く）のすべての Google Cloud プロダクトでは、削除対象のデータのコピーは使用可能なストレージとしてマークされ、上書きされていきます。アクティブ ストレージ システムでは、Bigtable と同様、削除対象のデータは大規模な構造化テーブル内のエントリとして保存されます。既存のテーブルを圧縮して削除対象のデータに上書きする場合、既存（削除対象でない）データのテーブルへの再書き込みが必要になるため費用が高くなる可能性があります。そのため、マークアンドスイープ ガベージ コレクションおよび大規模なコンパクションのイベントがスケジュールに従って一定の間隔で実施され、ストレージ スペースの再利用と削除対象データへの上書きが行われます。
Cloud Storage では、顧客データの削除に暗号消去も使用されます。暗号消去は、データの復号に必要な暗号鍵を削除することでデータを読めないようにする業界標準の手法です。暗号消去を使用するメリットの一つは、暗号鍵を Google が提供するかお客様が提供するかに関係なく、Google Cloud のアクティブとバックアップのストレージ システムで削除対象の全データブロックが上書きされる前に論理削除を完了できる点です。
ステージ 4: 保存期間満了によるバックアップ ストレージ システムからのデータの削除
Google のアクティブ ストレージ システムと同様に、バックアップ ストレージ システムでも削除対象のデータは上書き手法と暗合手法のどちらかで削除されます。ただし、バックアップ システムでは通常、アクティブ システムの大量のスナップショット群の中に顧客データが保存されます。このスナップショット群は、障害発生時（データセンター全体に影響する停止の発生時など）、バックアップ システムからシステム全体を復元する時間と費用が必要になったときに事業を継続できるよう、一定期間保持されています。適切な事業継続手法に従い、アクティブ システムの完全なスナップショットと差分スナップショットが日ごと、週ごと、月ごとのサイクルで作成され、決められた期間が経過すると廃棄され、新しいスナップショットのためのスペースが確保されます。
バックアップが廃棄されるに従い、そのスペースは使用可能としてマークされ、日ごと、週ごと、月ごとの新しいバックアップが実施されて上書きされていきます。
適切に設定されたバックアップ サイクルには、バックアップ システム内をデータ削除リクエストが伝搬される際の遅延が事前定義され、適用されています。アクティブ システムから削除されたお客様のデータは、バックアップ システムにはコピーされません。削除前に行われたバックアップは、事前に定義されたバックアップ サイクルに基づいて順次期限切れになります。
なお、削除対象データの暗号消去は、顧客データを含むバックアップが期限切れになる前に行われる場合があります。特定の顧客データの暗号化に使用された暗号鍵がなければ、その顧客データは Google のバックアップ システムでの寿命が残っていても復元できません。
削除のタイムライン
Google Cloud は、優れた速度、可用性、耐久性、整合性を実現できるように設計されています。こうしたパフォーマンス特性を満たすシステムを設計する場合、適切なタイミングでデータを削除する必要があるという点に配慮することが求められます。Google Cloud では、顧客データを最長 6 か月（180 日）以内に削除するように取り組んでいます。この取り組みは、前述の Google の削除パイプラインの次のようなステージを経て実現しています。
- ステージ 2: 削除リクエストが行われると、通常、直ちにデータに削除対象のマークが付けられます。ここでの目標は、このステップを 24 時間以内に行うことです。データが削除対象としてマークされると、サービスや削除リクエストによっては、最長で 30 日の内部復元期間が適用されます。
- ステージ 3: ガベージ コレクション処理を行い、アクティブ システムからの論理削除を行うために必要な段階です。それぞれのプロセスは、データ レプリケーションのレベルや進行中のガベージ コレクション サイクルのタイミングによって、削除リクエストを受け取った直後に実施される場合があります。削除リクエストが行われた後、通常はアクティブ システムからデータを削除するまで約 2 か月かかります。2 か月あれば、大規模なガベージ コレクションを 2 サイクル完了し、論理削除を完了するのに十分です。
- ステージ 4: Google のバックアップ サイクルは、削除リクエストから 6 か月以内にデータセンターのバックアップ内の削除対象データを期限切れにするように設計されています。データ レプリケーションのレベルや、進行中のバックアップ サイクルのタイミングによって、削除が早めに行われる場合があります。
次の図は、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 で定められた規格を満たします。