データ所在地の概要

概要

このページでは、Cloud SQL を使用してデータ所在地の要件を適用する方法について説明します。

「データ所在地」とは、データの物理的な場所と、そのデータの保存、暗号化、アクセス方法を規定するローカル規則のことです。国ごとのデータ保護やプライバシーに関する規則の発達に伴い、ローカルデータ所在地の要件に従い、ユーザーデータを保護する方法を理解することがますます重要になっています。

従来のオンプレミス環境では、さまざまなコンポーネントがデータ所在地を統合して処理しています。たとえば、企業はトークン化ゲートウェイをクラウド アクセス セキュリティ ブローカー（CASB）としてホストし、アプリケーション データを海外に転送する前に保護できます。

Google Cloud とそのサービス（Cloud SQL を含む）は統合され、データのロケーションと、Google を含むあらゆるユーザーによるデータへのアクセス権を制御することで、データ所在地の処理を支援します。

クラウド コンピューティング内のデータ所在地

次のリストは、知っておくべきデータ所在地の問題を示したものです。

  • 企業のクラウド管理者がデータの物理的な場所を把握していないなら、そこの規則も把握していません。それぞれの場所のデータ所在地に関する規則を調査できるようになるには、管理者がデータセンターの場所を把握する必要があります。
  • 企業のクラウド管理者とプロバイダは、サービスレベル契約（SLA）を使用して、許可されたロケーションを確立できます。しかし、SLA の条件とは異なるリージョンにデータを保存する必要がある場合はどうすればよいでしょうか。
  • ユーザーは、自身のデータと、自身のクラウド プロジェクトで使用するサービスとリソースのすべてが、ホスト国のデータ所在地に関する規則を遵守していることを確認する必要があります。
    • データと暗号鍵の保存場所を決定する場合はどうするでしょうか。
    • ユーザーがデータにアクセスできる場所を決める場合はどうなるでしょうか。

Cloud SQL を含む Google Cloud サービスでは、以下の内容を行うことで、これらの問題の一部に対処します。

  • データの保管場所を設定します。Cloud SQL インスタンスの作成時にリージョンを選択するか、既存のインスタンスを編集することでリージョンを変更できます。
  • 指定したリージョンのデータ所在地に関する基準への適合を支援するために、Cloud SQL のクロスリージョン リードレプリカ機能を使用します。
  • ユーザーがデータにアクセスできるネットワークの場所や、このデータに対するクラウド管理者のアクセス権を管理します。

Cloud SQL は、データ所在地の課題に対処するための次の 3 つの領域で役立ちます。

データを保存する

データ所在地には、特定のリージョン内に個人を特定できる情報（PII）を保存することが含まれ、そのデータはそのリージョンの規則に従って処理されます。

データを保存するには、該当する国の法的要件や規制要件（データ局所性に関する法律など）を満たす必要があります。たとえば、政府関連のデータをその国内に保存することが法律で義務付けられている場合があります。あるいは、ある会社が契約により、一部の顧客のデータを別の国に保存する義務を負う場合もあります。そのため、企業はデータを保存する国のデータ所在地の要件を満たす必要があります。

Google Cloud を使用すると、バックアップを含め、データの保存場所を構成できます。たとえば、データを保存するリージョンを選択できます。これらのリージョンで Cloud SQL のリソースを構成すると、Google はサービス固有の規約に従い、これらのリージョンにのみデータを保存します。インスタンスの作成時にリージョンを選択するか、既存のインスタンスを編集してリージョンを編集できます。

バックアップ ロケーションの詳細については、カスタム バックアップ ロケーションをご覧ください。

組織のポリシーの制約を使用して、組織レベル、プロジェクト レベル、フォルダレベルでデータ所在地の要件を適用できます。これらの制約を使用することで、サポート対象のサービスのリソースをユーザーが作成できる、Google Cloud の許可されたロケーションを定義できます。データ所在地については、リソース ロケーションの制約を使用して、新しいリソースの物理的な場所を制限できます。また、制約のポリシーを微調整して、許可または拒否するロケーションとして、マルチリージョン（asia、europe など）やリージョン（us-east1、europe-west1 など）を指定することもできます。

VPC Service Controls では、Cloud SQL Admin API または Cloud Storage API のいずれかを使用したデータのインポートとエクスポートを Cloud SQL API の使用のみに制限することで、データ所在地の適用を支援できます。この制限により、選択したネットワーク ロケーションにデータが確実に保存されるようになります。VPC Service Controls を使用して、サービスにアクセスできる仮想境界を定義するサービス境界を作成します。これにより、データが境界外に移動されることを防ぎます。Google Cloud IAM ポリシーに従ってユーザーが承認されている場合でも、この制約を適用できます。

データの暗号化

Cloud SQL を含む Google Cloud サービスは、さまざまな暗号化方式を使用して、お客様のコンテンツを保管時も転送時も暗号化します。暗号化は自動で行われるため、お客様による操作は必要ありません。

Cloud SQL では、顧客管理の暗号鍵（CMEK）を使用して、別の暗号化レイヤをデータに追加することも可能です。 CMEK は、機密データや規制対象データを保管し、独自の暗号鍵を管理する必要がある組織を対象としています。CMEK 機能を使用すると、Cloud SQL 内の保存データに独自の暗号鍵を使用できます。CMEK を追加すると、API が呼び出されるたびに、Cloud SQL はその鍵を使用してデータにアクセスします。

サービスをデプロイするリージョンに CMEK を保存する場合は、Cloud Key Management Service（Cloud KMS）を使用できます。鍵のロケーションは、鍵を作成するときに設定します。または、選択したリージョンにある物理的なハードウェア セキュリティ モジュール（HSM）内にこれらの鍵を保存する場合は、Cloud HSM を使用します。

CMEK の保存先を選択するもう 1 つの方法は、サードパーティ製品を使用することです。Google インフラストラクチャの外部にデプロイされたサードパーティの鍵管理製品で鍵の保管と管理を行うには、Cloud External Key Manager（Cloud EKM）を使用できます。

データへのアクセス

Cloud SQL を使用すると、データにアクセスできるユーザーを制御できます。

Google のサポート担当者とエンジニアリング担当者のアクセスを制御するには、Access Approval を使用します。Access Approval を使用することで、Google Cloud のデータや構成にアクセスする前に、Google 社員に対して明示的に承認を得るように要求できます（除外される場合については、Access Approval の除外をご覧ください）。

Access Approval は、アクセスの透明性（Google 管理者によるお客様のデータ操作時に、ほぼリアルタイムの監査ログを生成する）により提供される可視性を補完するものです。監査ログには、管理者のオフィスの場所とアクセスの理由が記録されます。また、データや構成にアクセスできる管理者には、地理的なリージョンや他のコンプライアンス関連の属性など、特定の属性を適用することもできます。

Key Access Justifications は、Cloud KMS および Cloud EKM と統合されています。データの暗号化または復号で鍵の 1 つが必要になるたびに、Key Access Justifications により、正当性の詳細とともに、設定した自動化ポリシーを使用して鍵アクセスの承認または拒否を行うメカニズムが提供されます。

Cloud KMS と Cloud EKM で Access Approval、アクセスの透明性、Key Access Justifications を使用すると、Google によるデータの復号を拒否できます。その結果、データへのアクセスはお客様自身が行います。

次のステップ