安全な BigQuery データ ウェアハウスにデータをインポートする

Last reviewed 2025-06-15 UTC

多くの組織では、さまざまなビジネス目的でデータを分析できるように、機密データを保存するデータ ウェアハウスをデプロイしています。このドキュメントは、BigQuery を使用してデータ ウェアハウスのデプロイと保護を行うデータ エンジニアとセキュリティ管理者を対象としています。これは、次のものから構成されるブループリントの一部です。

このドキュメントでは、次のトピックについて説明します。

  • 本番環境でデータ ウェアハウスを保護するために使用できるアーキテクチャとサービス。 Google Cloud
  • オンプレミス環境などの外部ネットワークから BigQuery にデータをインポートするためのベスト プラクティス。

  • Google Cloudでデータ ウェアハウスを作成、デプロイ、運用する際のデータ ガバナンスのベスト プラクティス。

    • データの匿名化

    • 機密データの差分処理

    • 列レベルの暗号化

    • 列レベルのアクセス制御

このドキュメントは、エンタープライズ基盤ブループリントで説明されているように、基本的なセキュリティ管理の構成が完了していることを前提としています。既存のセキュリティ管理にセキュリティ管理機能を追加して、データ ウェアハウス内の機密データを保護できます。

データ ウェアハウスのユースケース

このブループリントは、次のユースケースをサポートしています。

概要

BigQuery などのデータ ウェアハウスでは、分析情報のためにビジネスデータを分析できます。アナリストは、データ ウェアハウスに保存されているビジネスデータにアクセスして分析情報を作成します。データ ウェアハウスに機密データが含まれている場合は、ビジネスデータの保存中、転送中、分析中のセキュリティ、機密性、整合性、可用性を維持するための措置を取る必要があります。このブループリントでは、以下のことを行います。

  • 外部データソースからデータをインポートする場合は、 Google Cloud の外部（オンプレミス環境など）にあるデータを暗号化して、 Google Cloudにインポートします。
  • 機密データへの安全なアクセスに役立つ管理を構成します。
  • データ パイプラインの保護に役立つ管理を構成します。
  • ペルソナごとに職掌分散を適切に構成します。
  • Google Cloud にある他のソース（内部データソース）からデータをインポートする場合は、機密データを検出して匿名化するためのテンプレートを設定します。
  • 適切なセキュリティ管理とロギングを設定して、機密データを保護します。
  • データ分類、ポリシータグ、動的データ マスキング、列レベルの暗号化を使用して、データ ウェアハウス内の特定の列へのアクセスを制限します。

アーキテクチャ

機密データ ウェアハウスを作成するには、データを安全にインポートしてから、VPC Service Controls の境界にそのデータを保存する必要があります。

Google Cloudからデータをインポートする場合のアーキテクチャ

次の図は、terraform-google-secured-data-warehouse リポジトリを使用してソースデータをインポートするときに、取り込まれたデータがどのように分類、匿名化、保存されるかを示しています。 Google Cloud また、分析のためにオンデマンドで機密データを再識別する方法も表しています。

内部ソース用の機密データ ウェアハウス アーキテクチャ。

外部ソースからデータをインポートする場合のアーキテクチャ

次の図は、terraform-google-secured-data-warehouse-onprem-ingest リポジトリを使用してオンプレミス環境または別のクラウドから BigQuery ウェアハウスにデータをインポートする際のデータの取り込みと保存方法を示しています。

外部ネットワーク向けの機密データ ウェアハウス アーキテクチャ。

Google Cloud サービスと機能

このアーキテクチャでは、次の Google Cloud サービスと機能を組み合わせて使用します。

サービスまたは機能 説明

BigQuery

内部データソースと外部データソースの両方に適用されます。ただし、次のようなさまざまなストレージ オプションがあります。

  • Google Cloudからデータをインポートすると、BigQuery は機密データを機密データ境界に保存します。
  • 外部ソースからデータをインポートすると、BigQuery は暗号化されたデータとラップされた暗号鍵を別々のテーブルに保存します。

BigQuery では、コンテンツを保護するため、アクセス制御、機密データの列レベルのセキュリティ、データ暗号化を含む、さまざまなセキュリティ コントロールを使用します。

Cloud Key Management Service（Cloud KMS）と Cloud HSM

内部ソースと外部ソースの両方に適用されます。ただし、外部データソースの追加のユースケースもあります。

Cloud HSM は、鍵暗号鍵（KEK）をホストするクラウドベースのハードウェア セキュリティ モジュール（HSM）サービスです。外部ソースからデータをインポートする場合は、Cloud HSM を使用して、 Google Cloudに送信する前にネットワーク内のデータの暗号化に使用する暗号鍵を生成します。

Cloud Logging

内部ソースと外部ソースの両方に適用されます。

Cloud Logging は、 Google Cloud サービスからすべてのログを収集し、分析ツールと調査ツールによって保存と取得を行います。

Cloud Monitoring

内部ソースと外部ソースの両方に適用されます。

Cloud Monitoring は、 Google Cloud サービスに関するパフォーマンス情報と指標を収集して保存します。

Cloud Run functions

外部データソースにのみ適用されます。

Cloud Run 関数は Cloud Storage によってトリガーされ、Cloud Storage が取り込みバケットにアップロードするデータを BigQuery に書き込みます。

Cloud Storage と Pub/Sub

内部ソースと外部ソースの両方に適用されます。

Cloud Storage と Pub/Sub は、次のようにデータを受け取ります。

  • Cloud Storage: バッチデータを受信して保存します。デフォルトでは、Cloud Storage は TLS を使用して転送中のデータを暗号化し、AES-256 を使用してストレージ内のデータを暗号化します。暗号鍵は顧客管理の暗号鍵（CMEK）です。暗号化の詳細については、データ暗号化オプションをご覧ください。

    Identity and Access Management、アクセス制御リスト（ACL）、ポリシー ドキュメントなどのセキュリティ管理を使用して、Cloud Storage バケットへのアクセスを保護できます。サポートされているアクセス制御の詳細については、アクセス制御の概要をご覧ください。

BigQuery 用データ プロファイラ

内部ソースと外部ソースの両方に適用されます。

BigQuery 用データ プロファイラは、すべてのフォルダとプロジェクトを含む、組織全体のすべての BigQuery テーブルと列の機密データを自動的にスキャンします。

Dataflow パイプライン

内部ソースと外部ソースの両方に適用されますが、異なるパイプラインが存在します。

Dataflow パイプラインは、次のようにデータをインポートします。

  • Google Cloudからデータをインポートすると、2 つの Dataflow パイプラインが機密データを匿名化して再識別します。最初のパイプラインでは、仮名化を使用して機密データを匿名化します。2 番目のパイプラインでは、承認されたユーザーがアクセス権を必要とするときに、機密データを再識別します。
  • 外部ソースからデータをインポートする場合、1 つの Dataflow パイプラインがストリーミング データを BigQuery に書き込みます。

Dataplex Universal Catalog

内部ソースと外部ソースの両方に適用されます。

Dataplex Universal Catalog は、取り込み時にメタデータ（ポリシータグとも呼ばれます）を使用して機密データを自動的に分類します。Dataplex ユニバーサル カタログは、メタデータを使用して機密データへのアクセスも管理します。データ ウェアハウス内のデータへのアクセスを制御するには、機密データを含む列にポリシータグを適用します。

Dedicated Interconnect

外部データソースにのみ適用されます。

Dedicated Interconnect を使用すると、ネットワークと Google Cloud間でデータを移動できます。Network Connectivity プロダクトの選択で説明されているように、別の接続オプションを使用することもできます。

IAM と Resource Manager

内部ソースと外部ソースの両方に適用されます。

Identity and Access Management（IAM）と Resource Manager は、アクセスを制限し、リソースをセグメント化します。アクセス制御とリソース階層は、最小権限の原則に従います。

Security Command Center

内部ソースと外部ソースの両方に適用されます。

Security Command Center は、 Google Cloud環境全体のセキュリティ検出結果を 1 か所でモニタリングして確認します。

Sensitive Data Protection

内部ソースと外部ソースの両方に適用されますが、スキャンは異なります。

Sensitive Data Protection は、次のようにデータをスキャンします。

  • Google Cloudからデータをインポートすると、機密データの保護により、取り込み中に機密データが匿名化されます。Sensitive Data Protection では、検出された infoType またはレコードに基づいて、構造化データと非構造化データが匿名化されます。
  • 外部ソースからデータをインポートすると、機密データの保護は BigQuery に保存されているデータをスキャンし、保護されていない機密データを検出します。詳細については、Sensitive Data Protection を使用した BigQuery データのスキャンをご覧ください。

VPC Service Controls

内部ソースと外部ソースの両方に適用されますが、境界は異なります。

VPC Service Controls は、承認、アクセス制御、安全なデータ交換を設定して、サービスとリソースを分離するセキュリティ境界を作成します。境界は次のとおりです。

  • データ取り込み境界は、受信データを（バッチまたはストリームで）受け入れて匿名化します。ランディング ゾーンを分離すると、残りのワークロードを受信データから保護できます。
  • Google Cloudからデータをインポートすると、機密データ境界は機密データを再識別して制限された領域に保存できます。
  • 外部データをインポートする場合、データ境界によって暗号化データが他のワークロードから分離されます。
  • ガバナンス境界は、暗号鍵を保管し、機密データとみなされるものを定義します。

これらの境界は、追加のアクセス制御とモニタリングを設定して機密データを分離し、ウェアハウス内の実際のデータとガバナンスを分離するように設計されています。ガバナンスには、鍵管理、Data Catalog 管理、ロギングが含まれます。

組織構造

組織のリソースをグループ化して管理できるようにし、テスト環境を本番環境から分離します。Resource Manager を使用すると、プロジェクト、フォルダ、組織ごとに論理的にリソースをグループ化できます。

次の図に、ブートストラップ、共通、本番、非本番（ステージング）、開発などのさまざまな環境を表すフォルダを持つリソース階層を示します。アーキテクチャ内のほとんどのプロジェクトを本番環境フォルダにデプロイし、データ ガバナンス プロジェクトをガバナンスに使用する共通フォルダにデプロイします。

Google Cloudからデータをインポートする場合の組織構造

次の図は、terraform-google-secured-data-warehouse リポジトリを使用してGoogle Cloud からデータをインポートする場合の組織構造を示しています。

内部ソースの機密データ ウェアハウスのリソース階層。

外部ソースからデータをインポートする場合の組織構造

次の図は、terraform-google-secured-data-warehouse-onprem-ingest リポジトリを使用して外部ソースからデータをインポートする場合の組織構造を示しています。

外部ソースの機密データ ウェアハウスのリソース階層。

フォルダ

フォルダを使用して、本番環境とガバナンス サービスを非本番環境やテスト環境から分離します。次の表に、このアーキテクチャで使用されるエンタープライズ基盤ブループリントのフォルダを示します。

フォルダ 説明

ブートストラップ

エンタープライズ基盤ブループリントをデプロイするために必要なリソースが含まれています。

一般的な

データ ガバナンス プロジェクトなど、組織の一元化されたサービスが含まれます。

本番環境

テスト済みですぐに使用できるクラウド リソースがあるプロジェクトが含まれます。このアーキテクチャでは、本番環境フォルダにデータ取り込みプロジェクトとデータ関連プロジェクトが含まれています。

非本番環境

テストとリリースのステージングが行われているクラウド リソースがあるプロジェクトが含まれます。このアーキテクチャでは、非本番環境フォルダにデータ取り込みプロジェクトとデータ関連プロジェクトが含まれています。

開発

開発中のクラウド リソースがあるプロジェクトが含まれています。このアーキテクチャでは、開発フォルダにデータ取り込みプロジェクトとデータ関連プロジェクトが含まれています。

これらのフォルダの名前は、組織のフォルダ構造に合わせて変更できますが、同様の構造を維持することをおすすめします。詳細については、エンタープライズ基盤ブループリントをご覧ください。

プロジェクト

プロジェクトを使用して環境の一部を分離します。次の表に、組織内で必要なプロジェクトを示します。Terraform コードの実行時にこれらのプロジェクトを作成します。これらのプロジェクトの名前は変更できますが、同様のプロジェクト構造を維持することをおすすめします。

プロジェクト 説明

データの取り込み

内部ソースと外部ソースの両方に対する共通プロジェクト。

データを受信して機密データを匿名化するために必要なサービスが含まれています。

データ ガバナンス

内部ソースと外部ソースの両方に対する共通プロジェクト。

鍵管理、ロギング、データカタログ化の機能を提供するサービスが含まれます。

機密ではないデータ

内部ソース専用のプロジェクト。

匿名化されたデータを保存するために必要なサービスが含まれます。

機密データ

内部ソース専用のプロジェクト。

機密データの保存と再識別に必要なサービスが含まれています。

データ

外部ソース専用のプロジェクト。

データを保存するために必要なサービスが含まれます。

これらのプロジェクトに加えて、環境には Dataflow Flex テンプレート ジョブをホストするプロジェクトも必要です。Flex テンプレート ジョブは、ストリーミング データ パイプラインに必要です。

ロールとグループをプロジェクトにマッピング

組織内のさまざまなユーザー グループに、機密データ ウェアハウスを構成するプロジェクトへのアクセス権を付与する必要があります。以降のセクションでは、作成するプロジェクトのユーザー グループとロールの割り当てに関するアーキテクチャの推奨事項について説明します。組織の既存の構造に合わせてグループをカスタマイズできますが、同様の職掌分散とロール割り当てを維持することをおすすめします。

データ アナリスト グループ

データ アナリストは、ウェアハウス内のデータを分析します。terraform-google-secured-data-warehouse-onprem-ingest リポジトリでは、このグループはデータ ウェアハウスに読み込まれたデータを表示し、暗号化されたデータ閲覧者グループと同じオペレーションを実行できます。

次の表に、terraform-google-secured-data-warehouse リポジトリのさまざまなプロジェクトにおけるグループのロールを示します（内部データソースのみ）。

プロジェクトのマッピング ロール

データの取り込み

機密データへのアクセスを必要とするデータ アナリストの追加ロール:

機密データ

機密ではないデータ

次の表に、terraform-google-secured-data-warehouse-onprem-ingest リポジトリのさまざまなプロジェクトでのグループのロールを示します（外部データソースのみ）。

割り当てのスコープ ロール

データ取り込みプロジェクト

データ プロジェクト

データポリシー レベル

マスクされた読み取り（roles/bigquerydatapolicy.maskedReader）

暗号化されたデータ閲覧者グループ（外部ソースのみ）

terraform-google-secured-data-warehouse-onprem-ingest リポジトリの暗号化されたデータ閲覧者グループは、Looker Studio や SAP Business Objects などのレポートツールを使用して、BigQuery レポート テーブルから暗号化されたデータを表示できます。暗号化されたデータ閲覧者グループは、暗号化された列のクリアテキスト データを表示することはできません。

このグループには、データ プロジェクトでの BigQuery ユーザー（roles/bigquery.jobUser）のロールが必要です。このグループには、データポリシー レベルでのマスクされた読み取り（roles/bigquerydatapolicy.maskedReader）ロールも必要です。

平文リーダー グループ（外部ソースのみ）

terraform-google-secured-data-warehouse-onprem-ingest リポジトリの平文リーダー グループには、復号ユーザー定義関数（UDF）を呼び出して平文データを表示するために必要な権限と、マスクされていないデータを読み取るための追加の権限があります。

このグループには、データ プロジェクトで次のロールが必要です。

また、このグループには、Dataplex Universal Catalog レベルでのきめ細かい読み取り（roles/datacatalog.categoryFineGrainedReader）ロールが必要です。

データ エンジニア グループ

データ エンジニアは、データ パイプラインとデータ ウェアハウスを設定して維持します。

次の表に、terraform-google-secured-data-warehouse リポジトリのさまざまなプロジェクトでのグループのロールを示します。

課題のスコア ロール

データ取り込みプロジェクト

機密データ プロジェクト

機密性のないデータ プロジェクト

次の表に、terraform-google-secured-data-warehouse-onprem-ingest リポジトリのさまざまなプロジェクトでのグループのロールを示します。

割り当てのスコープ ロール

データ取り込みプロジェクト

データ プロジェクト

ネットワーク管理者グループ

ネットワーク管理者はネットワークを構成します。通常は、ネットワーキング チームのメンバーです。

ネットワーク管理者には、組織レベルで次のロールが必要です。

セキュリティ管理者グループ

セキュリティ管理者は、アクセス、鍵、ファイアウォール ルール、VPC Service Controls、Security Command Center などのセキュリティ制御を管理します。

セキュリティ管理者には、組織レベルで次のロールが必要です。

セキュリティ アナリスト グループ

セキュリティ アナリストは、セキュリティ インシデントと Sensitive Data Protection の検出結果をモニタリングし、対処します。

セキュリティ アナリストには、組織レベルで次のロールが必要です。

外部ソースのグループ アクセスフローの例

以降のセクションでは、terraform-google-secured-data-warehouse-onprem-ingest リポジトリを使用して外部ソースからデータをインポートする場合の 2 つのグループのアクセスフローについて説明します。

暗号化されたデータ閲覧者グループのアクセスフロー

次の図は、暗号化されたデータ閲覧者グループのユーザーが BigQuery の暗号化されたデータにアクセスするとどうなるかを示しています。

暗号化されたデータ閲覧者グループのフロー。

BigQuery でデータにアクセスする手順は次のとおりです。

  1. 暗号化されたデータ閲覧者は、BigQuery で次のクエリを実行して機密データにアクセスします。

    SELECT ssn, pan FROM cc_card_table

  2. BigQuery では、次のようにアクセスを確認します。

    • ユーザーが期限切れでない有効な認証情報を使用して認証されている。 Google Cloud
    • ユーザー ID とリクエストの送信元 IP アドレスは、VPC Service Controls の境界のアクセスレベルまたは上り（内向き）ルールの許可リストに含まれている。
    • IAM により、ユーザーに適切なロールがあり、BigQuery テーブルで選択した暗号化された列へのアクセスが許可されていることが確認されている。

BigQuery は、機密データを暗号化された形式で返します。

平文リーダー グループのアクセスフロー

次の図は、平文リーダー グループのユーザーが BigQuery の暗号化されたデータにアクセスしようとするとどうなるかを示しています。

平文リーダー グループのフロー。

BigQuery でデータにアクセスする手順は次のとおりです。

  1. 平文リーダーは、BigQuery で次のクエリを実行し、機密データに復号された形式でアクセスします。

    SELECT decrypt_ssn(ssn) FROM cc_card_table

  2. BigQuery は、クエリ内で復号ユーザー定義関数（UDF）を呼び出して、保護された列にアクセスします。

  3. アクセス権は次のように検証されます。

    • IAM は、ユーザーに適切なロールがあり、BigQuery の復号 UDF へのアクセスが許可されていることを確認します。
    • UDF は、機密データ列の保護に使用されたラップされたデータ暗号鍵（DEK）を取得します。

  4. 復号 UDF は、Cloud HSM の鍵暗号鍵（KEK）を呼び出して DEK をラップ解除します。復号 UDF は、BigQuery AEAD 復号関数を使用して機密データ列を復号します。

  5. ユーザーに、機密データ列の平文データへのアクセス権が付与されます。

一般的なセキュリティ管理

以降のセクションでは、内部ソースと外部ソースの両方に適用される制御について説明します。

データ取り込みの制御

データ ウェアハウスを作成するには、別のGoogle Cloud ソース（データレイクなど）、オンプレミス環境、または別のクラウドからデータを転送する必要があります。次のいずれかのオプションを使用して、データを BigQuery のデータ ウェアハウスに転送できます。

  • Cloud Storage を使用するバッチジョブ。
  • Pub/Sub を使用するストリーミング ジョブ。

取り込み中にデータを保護するには、クライアントサイド暗号化、ファイアウォール ルール、アクセスレベル ポリシーを使用します。取り込みプロセスは、抽出、変換、読み込み（ETL）プロセスとも呼ばれます。

ネットワークとファイアウォールのルール

Virtual Private Cloud（VPC）ファイアウォール ルールによって、境界へのデータフローが制御されます。restricted.googleapis.com の特別なドメイン名からの特定の TCP ポート 443 接続を除き、すべての下り（外向き）を拒否するファイアウォール ルールを作成します。restricted.googleapis.com ドメインには次のようなメリットがあります。

  • ワークロードが Google API およびサービスと通信する際に限定公開の Google アクセスを使用することで、ネットワーク攻撃の可能性を低減できます。
  • VPC Service Controls をサポートするサービスのみを使用するようになります。

詳細については、限定公開の Google アクセスの構成をご覧ください。

terraform-google-secured-data-warehouse リポジトリを使用する場合は、Dataflow ジョブごとに個別のサブネットを構成する必要があります。個別のサブネットにすると、匿名化されたデータが、再識別されるデータと適切に分離されます。

データ パイプラインでは、各リポジトリの dataflow_firewall.tf ファイルで定義されているように、ファイアウォールで TCP ポートを開く必要があります。詳細については、インターネット アクセスとファイアウォール ルールの構成をご覧ください。

リソースで外部 IP アドレスを使用する機能を拒否するために、VM インスタンスに対して許可されている外部 IP を定義する（compute.vmExternalIpAccess）組織ポリシーはすべて拒否に設定されています。

境界制御

アーキテクチャ図に示すように、データ ウェアハウスのリソースを個別の境界に配置します。異なる境界のサービス間でデータを共有できるようにするには、境界ブリッジを作成します。

境界ブリッジを使用すると、保護されたサービスが境界外のリソースをリクエストできます。これらのブリッジは、terraform-google-secured-data-warehouse リポジトリに対して次の接続を行います。

  • データ取り込みプロジェクトをガバナンス プロジェクトに接続して、取り込み中に非匿名化できるようにします。
  • 機密ではないデータ プロジェクトと機密データ プロジェクトを接続し、データ アナリストからの要請に応じて機密データを再識別できるようにします。
  • 機密プロジェクトをデータ ガバナンス プロジェクトに接続して、データ アナリストからの要請に応じて再識別できるようにします。

これらのブリッジは、terraform-google-secured-data-warehouse-onprem-ingest リポジトリに対して次の接続を行います。

  • データ取り込みプロジェクトをデータ プロジェクトに接続して、データを BigQuery に取り込むことができます。
  • データ プロジェクトをデータ ガバナンス プロジェクトに接続して、Sensitive Data Protection が BigQuery で保護されていない機密データをスキャンできるようにします。
  • ロギング、モニタリング、暗号鍵にアクセスするために、データ取り込みプロジェクトをデータ ガバナンス プロジェクトに接続します。

境界ブリッジに加えて、下り（外向き）ルールを使用して、サービス境界で保護されているリソースが境界外のリソースにアクセスできるようにします。このソリューションでは、下り（外向き）ルールを構成して、外部プロジェクトの Cloud Storage にある外部 Dataflow Flex テンプレート ジョブを取得します。詳細については、境界外の Google Cloud リソースにアクセスするをご覧ください。

アクセス ポリシー

特定の ID（ユーザーまたはサービス）のみがリソースとデータにアクセスできるようにするには、IAM のグループとロールを有効にします。

特定のソースのみがプロジェクトにアクセスできるように、Google 組織でアクセス ポリシーを有効にします。リクエストに対して許可される IP アドレス範囲を指定し、特定のユーザーまたはサービス アカウントからのリクエストのみを許可するアクセス ポリシーを作成することをおすすめします。詳しくは、アクセスレベル属性をご覧ください。

サービス アカウントとアクセス制御

サービス アカウントは、 Google Cloud ユーザーに代わって API リクエストを実行するために使用できる ID です。サービス アカウントにより、ユーザー ID がサービスに直接アクセスできなくなります。職掌分散を許可するために、特定の目的のために異なるロールを持つサービス アカウントを作成します。これらのサービス アカウントは、各アーキテクチャの data-ingestion モジュールと confidential-data モジュールで定義されています。

terraform-google-secured-data-warehouse リポジトリのサービス アカウントは次のとおりです。

  • 機密データを匿名化する Dataflow パイプラインの Dataflow コントローラ サービス アカウント。
  • 機密データを再識別する Dataflow パイプラインの Dataflow コントローラ サービス アカウント。
  • バッチファイルからデータを取り込むための Cloud Storage サービス アカウント。
  • ストリーミング サービスからデータを取り込むための Pub/Sub サービス アカウント。
  • Dataflow パイプラインを作成する Dataflow バッチジョブを実行するための Cloud Scheduler サービス アカウント。

次の表に、各サービス アカウントに割り当てられているロールを示します。

サービス アカウント 名前 プロジェクト ロール

Dataflow コントローラ

このアカウントは匿名化に使用されます。

sa-dataflow-controller

データの取り込み

Dataflow コントローラ

このアカウントは再識別に使用されます。

sa-dataflow-controller-reid

機密データ

Cloud Storage

sa-storage-writer

データの取り込み

Pub/Sub

sa-pubsub-writer

データの取り込み

Cloud Scheduler

sa-scheduler-controller

データの取り込み

terraform-google-secured-data-warehouse-onprem-ingest リポジトリのサービス アカウントは次のとおりです。

  • Cloud Storage サービス アカウントは、取り込みストレージ バケットへのバッチデータの自動アップロード プロセスを実行します。
  • Pub/Sub サービス アカウントを使用すると、Pub/Sub サービスへのデータのストリーミングが可能になります。
  • Dataflow コントローラ サービス アカウントは、Dataflow パイプラインで Pub/Sub から BigQuery へのデータの変換と書き込みに使用されます。
  • Cloud Run 関数のサービス アカウントは、Cloud Storage から BigQuery にアップロードされた後続のバッチデータを書き込みます。
  • Storage Upload サービス アカウントを使用すると、ETL パイプラインでオブジェクトを作成できます。
  • Pub/Sub 書き込みサービス アカウントを使用すると、ETL パイプラインで Pub/Sub にデータを書き込むことができます。

次の表に、各サービス アカウントに割り当てられているロールを示します。

名前 ロール 割り当てのスコープ

Dataflow コントローラ サービス アカウント

データ取り込みプロジェクト

データ プロジェクト

データ ガバナンス

Cloud Run 関数のサービス アカウント

データ取り込みプロジェクト

データ プロジェクト

Storage Upload サービス アカウント

データ取り込みプロジェクト

Pub/Sub 書き込みサービス アカウント

データ取り込みプロジェクト

組織のポリシー

このアーキテクチャには、エンタープライズ基盤ブループリントで使用されている組織のポリシーの制約と、追加の制約が含まれています。エンタープライズ基盤ブループリントで使用する制約の詳細については、組織のポリシーの制約をご覧ください。

次の表に、各リポジトリの org_policies モジュールで定義されている追加の組織のポリシーの制約を示します。

ポリシー 制約名 推奨値

特定の物理的な場所にリソースのデプロイを制限します。その他の値については、値グループをご覧ください。

gcp.resourceLocations

次のいずれか:

in:us-locations

in:eu-locations

in:asia-locations

サービス アカウントの作成を無効にする

iam.disableServiceAccountCreation

true

プロジェクトで作成した VM で OS Login を有効にする。

compute.requireOsLogin

true

IP アドレスに基づいて、新しい転送ルールを内部専用に制限します。

compute.restrictProtocolForwardingCreationForTypes

INTERNAL

Compute Engine リソースで使用できる一連の共有 VPC サブネットワークを定義します。

compute.restrictSharedVpcSubnetworks

projects//regions//s ubnetworks/。

アーキテクチャで使用するプライベート サブネットのリソース ID に置き換えます。

Cloud Logging へのシリアルポート出力ロギングを無効にする。

compute.disableSerialPortLogging

true

CMEK 保護を要求する（terraform-google-secured-data-warehouse-onprem-ingest のみ）

gcp.restrictNonCmekServices

bigquery.googleapis.com

サービス アカウント キーの作成を無効にする（terraform-google-secured-data-warehouse-onprem-ingest only）

disableServiceAccountKeyCreation

true

プロジェクトで作成した VM で OS Login を有効にする（terraform-google-secured-data-warehouse-onprem-ingest only）

compute.requireOsLogin

true

デフォルトのサービス アカウントへの自動的なロール付与を無効にする（terraform-google-secured-data-warehouse-onprem-ingest only）

automaticIamGrantsForDefaultServiceAccounts

true

許可される上り（内向き）設定（Cloud Run 関数）（terraform-google-secured-data-warehouse-onprem-ingest only）

cloudfunctions.allowedIngressSettings

ALLOW_INTERNAL_AND_GCLB

外部データソースのセキュリティ管理

以降のセクションでは、外部ソースからのデータの取り込みに適用される制御について説明します。

Google Cloudへの接続が暗号化されています

外部ソースからデータをインポートする場合は、Cloud VPN または Cloud Interconnect を使用して、 Google Cloudと環境の間で転送されるすべてのデータを保護できます。大量のデータをストリーミングする場合は直接接続と高スループットを提供することが重要になるため、このエンタープライズ アーキテクチャでは Dedicated Interconnect を推奨します。

環境から Google Cloud へのアクセスを許可するには、アクセスレベルのポリシールールで許可リストに登録された IP アドレスを定義する必要があります。

クライアントサイド暗号化

機密データを Google Cloudに移動する前に、保存中と転送中のデータを保護するため、ローカルでデータを暗号化します。Tink 暗号化ライブラリまたは他の暗号化ライブラリを使用できます。Tink 暗号化ライブラリは BigQuery AEAD 暗号化と互換性があります。このアーキテクチャでは、データのインポート後に列レベルの暗号化データを復号するためにこれを使用します。

Tink 暗号化ライブラリは、ローカルに、または Cloud HSM から生成できる DEK を使用します。DEK をラップまたは保護するには、Cloud HSM で生成された KEK を使用します。KEK は対称 CMEK 暗号鍵セットで、Cloud HSM に安全に保存され、IAM のロールと権限を使用して管理されます。

取り込み時に、ラップされた DEK とデータの両方が BigQuery に保存されます。BigQuery には、データ用とラップされた DEK 用の 2 つのテーブルがあります。アナリストが機密データを表示する必要がある場合、BigQuery は AEAD 復号を使用して、KEK で DEK をラップ解除し、保護された列を復号できます。

また、Tink を使用したクライアント側の暗号化は、BigQuery の機密データ列を暗号化することでデータをさらに保護します。このアーキテクチャでは、次の Cloud HSM 暗号鍵を使用します。

  • 取り込みプロセス用の CMEK 鍵。Pub/Sub、ストリーミング用の Dataflow パイプライン、Cloud Storage の一括アップロード、後続の一括アップロード用の Cloud Run 関数のアーティファクトでも使用されます。
  • Tink を使用してネットワークで暗号化されたデータ用に、Cloud HSM によってラップされた暗号鍵。
  • データ プロジェクト内の BigQuery ウェアハウスの CMEK 鍵。

CMEK のロケーションを指定します。これにより、鍵が保存され、アクセスできるようになる地理的位置が決まります。CMEK がリソースと同じロケーションに存在するようにする必要があります。デフォルトでは、CMEK は 30 日ごとにローテーションされます。

組織のコンプライアンス義務により、独自の鍵を Google Cloudから外部で管理する必要がある場合は、Cloud External Key Manager を有効にできます。外部鍵を使用する場合、鍵のローテーションを含む鍵管理アクティビティは、ユーザーの責任で行う必要があります。

動的データのマスキング

大規模なデータアクセス ポリシーの共有と適用に役立てるために、動的データ マスキングを構成できます。動的データ マスキングを使用すると、次の基準を使用して、既存のクエリによって列データを自動的にマスキングできます。

  • クエリ実行時に列に適用されるマスキング ルール。
  • クエリを実行しているユーザーに割り当てられているロール。マスクされていない列データにアクセスするには、データ アナリストにきめ細かい読み取りロールが必要です。

BigQuery で列のアクセス権を定義するには、ポリシータグを作成します。たとえば、スタンドアロンの例で作成した分類は、クレジット上限など、公開できないデータを含む列用の 1_Sensitive ポリシータグを作成します。これらの列にはデフォルトのデータ マスキング ルールが適用され、列の値が非表示になります。

タグのないものはすべて、データ ウェアハウスにアクセスできるすべてのユーザーが利用できます。このアクセス制御により、データが BigQuery に書き込まれた後でも、ユーザーにアクセス権が明示的に付与されるまで、機密性の高いフィールドのデータを読み取ることはできません。

列レベルの暗号化と復号

列レベルの暗号化を使用すると、BigQuery 内のデータをより詳細なレベルで暗号化できます。テーブル全体を暗号化するのではなく、BigQuery 内の機密データを含む列を選択すると、それらの列のみが暗号化されます。BigQuery は、AEAD 暗号化と復号関数を使用して、暗号化と復号の鍵を含む鍵セットを作成します。その後、これらの鍵を使用して、テーブル内の個々の値を暗号化および復号し、鍵セット内の鍵をローテーションします。列レベルの暗号化では、BigQuery 内の暗号化されたデータに対するデュアル アクセス制御が実現されます。これは、クリアテキストでデータを読み取るには、ユーザーがテーブルと暗号鍵の両方に対する権限を持っている必要があるためです。

Sensitive Data Protection を使用した BigQuery 用データ プロファイラ

データ プロファイラを使用すると、BigQuery テーブル内の機密データと高リスクのデータの場所を特定できます。データ プロファイラは、すべてのフォルダとプロジェクトを含む組織全体のすべての BigQuery テーブルと列を自動的にスキャンして分析します。データ プロファイラは、予測された infoType、評価されたデータリスクと機密性レベルなどの指標、およびテーブルのメタデータを出力します。これらの分析情報を使用すると、データを保護、共有、使用する方法に関して十分な情報に基づいた意思決定を行うことができます。

内部データソースのセキュリティ管理

以降のセクションでは、Google Cloud ソースからのデータの取り込みに適用される制御について説明します。

取り込みの際の鍵管理と暗号化

どちらの取り込みオプション（Cloud Storage または Pub/Sub）でも、CMEK の管理には Cloud HSM が使用されます。CMEK 鍵を使用して、取り込み中にデータを保護します。Sensitive Data Protection はさらに、構成した検出機能を使用して機密データを暗号化することで、データを保護します。

データを取り込むには、次の暗号鍵を使用します。

  • Dataflow パイプラインと Pub/Sub サービスでも使用される取り込みプロセスの CMEK 鍵。
  • Sensitive Data Protection を使用したデータ匿名化プロセス用に、Cloud HSM によってラップされた暗号鍵。
  • 2 つの CMEK 鍵。1 つは機密ではないデータ プロジェクトの BigQuery ウェアハウス用、もう 1 つは機密データ プロジェクトのウェアハウス用です。詳細については、鍵管理をご覧ください。

CMEK のロケーションを指定します。これにより、鍵が保存され、アクセスできるようになる地理的な場所が決まります。CMEK がリソースと同じロケーションに存在するようにする必要があります。デフォルトでは、CMEK は 30 日ごとにローテーションされます。

組織のコンプライアンス義務により、独自の鍵を Google Cloudから外部で管理する必要がある場合は、Cloud EKM を有効にできます。外部鍵を使用する場合、鍵のローテーションを含む鍵管理アクティビティは、ユーザーの責任で行う必要があります。

データの匿名化

Sensitive Data Protection を使用して、取り込みフェーズで構造化データと非構造化データを匿名化します。構造化データの場合は、フィールドに基づくレコード変換を使用してデータを匿名化します。このアプローチの例については、/examples/de_identification_template/ フォルダをご覧ください。この例では、構造化データにクレジット カード番号とカード PIN があるかどうかチェックします。非構造化データの場合は、情報タイプを使用してデータを匿名化します。

機密としてタグ付けされたデータを匿名化するには、Sensitive Data Protection と Dataflow パイプラインを使用してデータをトークン化します。このパイプラインは、Cloud Storage からデータを取得して処理し、BigQuery データ ウェアハウスに送信します。

データの匿名化プロセスの詳細については、データ ガバナンスをご覧ください。

列レベルのアクセス制御

機密データを保護するために、BigQuery ウェアハウスでは特定の列のアクセス制御を使用します。これらの列のデータにアクセスするには、データ アナリストにきめ細かい読み取りのロールが必要です。

BigQuery で列のアクセス権を定義するには、ポリシータグを作成します。たとえば、bigquery-confidential-data の例のモジュールの taxonomy.tf ファイルでは、次のタグが作成されます。

  • クレジット カード番号などの機密性の高い情報を含む列用の 3_Confidential ポリシータグ。このタグにアクセスできるユーザーは、2_Private または 1_Sensitive ポリシータグがタグ付けされた列にもアクセスできます。
  • 個人の名前など、個人を特定できる機密情報（PII）を含む列用の 2_Private ポリシータグ。このタグにアクセスできるユーザーは、1_Sensitive ポリシータグでタグ付けされた列にもアクセスできます。ユーザーは、3_Confidential ポリシータグでタグ付けされた列にはアクセスできません。
  • 利用限度額など、公開できないデータを含む列用の 1_Sensitive ポリシータグ。このタグにアクセスできるユーザーは、2_Private または 3_Confidential ポリシータグがタグ付けされた列にはアクセスできません。

タグのないものはすべて、データ ウェアハウスにアクセスできるすべてのユーザーが利用できます。

このアクセス制御により、データが再識別された後も、ユーザーにアクセス権が明示的に付与されるまでデータを読み取ることはできません。

注: デフォルトの定義を使用して、例を実行できます。その他のベスト プラクティスについては、BigQuery でポリシータグを使用するためのベスト プラクティスをご覧ください。

ロールが制限されたサービス アカウント

承認されたユーザーのみが機密データを表示できるように、機密データ プロジェクトへのアクセスを制限する必要があります。そのためには、承認されたユーザーが権限を借用する必要がある サービス アカウント ユーザー（roles/iam.serviceAccountUser）ロールを持つサービス アカウントを作成します。サービス アカウントの権限借用は、ユーザーがサービス アカウント キーをダウンロードせずにサービス アカウントを使用するため、プロジェクトの全体的なセキュリティが向上します。権限借用は、サービス アカウント トークン作成者（roles/iam.serviceAccountTokenCreator）ロールを持つ承認されたユーザーがダウンロードできる短期間のトークンを作成します。

鍵管理と暗号化によるストレージと再識別

機密データに対して個別の CMEK 鍵を管理するため、データを再識別できます。Cloud HSM を使用して鍵を保護します。データを再識別するには、次のキーを使用します。

  • Dataflow パイプラインが再識別プロセスに使用する CMEK 鍵。
  • データを匿名化するために Sensitive Data Protection によって使用される元の暗号鍵。
  • 機密データ プロジェクト内の BigQuery ウェアハウスの CMEK 鍵。

取り込みの際の鍵管理と暗号化で説明したように、CMEK の場所とローテーション期間を指定できます。組織で必要な場合は Cloud EKM を使用できます。

運用

ロギングと、Security Command Center のプレミアム ティアまたはエンタープライズ ティアの機能（Security Health Analytics、Event Threat Detection など）を有効にできます。こうした制御により、次のことを実現できます。

  • データにアクセスするユーザーをモニタリングする。
  • 適切な監査を確実に実施する。
  • クラウド リソースの構成ミスに関する検出結果を生成する。
  • 発生する可能性のある問題への、インシデント管理チームと運用チームの対応能力をサポートする。

アクセスの透明性

アクセスの透明性により、Google 社員がデータにアクセスする必要がある場合、リアルタイム通知を提供します。アクセスの透明性ログは、人間がコンテンツにアクセスするたびに生成され、ビジネス上の正当な理由（サポートケースなど）がある Google の担当者のみがアクセス権を取得できます。

ロギング

監査要件を満たしてプロジェクトの分析情報を得るには、追跡するサービスのデータログを使用して、Google Cloud Observability を構成します。リポジトリの centralized-logging モジュールは、次のベスト プラクティスを構成します。

プロジェクト内のすべてのサービスに関して、データの読み取りと書き込みに関する情報と、管理者が読み取る内容に関する情報がログに含まれている必要があります。その他のロギングのベスト プラクティスについては、検出制御をご覧ください。

アラートとモニタリング

アーキテクチャをデプロイした後、セキュリティ インシデントが発生している可能性があることをセキュリティ オペレーション センター（SOC）に通知するアラートを設定できます。たとえば、アラートを使用して、IAM 権限が変更されたことをセキュリティ アナリストに知らせることができます。Security Command Center のアラートの構成の詳細については、検出通知の設定をご覧ください。Security Command Center で公開されていない追加のアラートについては、Cloud Monitoring でアラートを設定できます。

その他のセキュリティ上の考慮事項

このドキュメントで説明したセキュリティ管理に加えて、このソリューションの使用と重複し相互に影響し合う主要領域でもセキュリティとリスクを確認して管理する必要があります。法的根拠には次のようなものがあります。

  • Dataflow ジョブと Cloud Run 関数の構成、デプロイ、実行に使用するコードのセキュリティ。
  • このソリューションで使用するデータ分類タクソノミー。
  • 暗号鍵の生成と管理。
  • データ ウェアハウスに保存して分析するデータセットのコンテンツ、品質、セキュリティ。
  • 以下を含む、ソリューションをデプロイする全体的な環境。
    • このソリューションに接続するネットワークの設計、セグメンテーション、セキュリティ。
    • 組織の IAM コントロールのセキュリティとガバナンス。
    • このソリューションの一部であるインフラストラクチャへのアクセス権を持ち、そのインフラストラクチャで保存と管理がされているデータにアクセスできるアクターに対する認証と認可の設定。

まとめ

このドキュメントで説明されたアーキテクチャを実装する方法は次のとおりです。

  1. アーキテクチャをエンタープライズ基盤ブループリントとともにデプロイするか、単独でデプロイするかを決定します。エンタープライズ基盤ブループリントをデプロイしない場合は、同様のセキュリティ ベースラインを環境に設定するようにしてください。
  2. 外部ソースからデータをインポートするには、ネットワークとの Dedicated Interconnect 接続を設定します。
  3. terraform-google-secured-data-warehouse README または terraform-google-secured-data-warehouse-onprem-ingest README を確認し、すべての前提条件を満たしていることを確認します。

  4. 組織構造で説明されているとおり、組織の開発用フォルダに対する サービス アカウント ユーザー（roles/iam.serviceAccountUser）ロールとサービス アカウント トークン作成者 サービス アカウント トークン作成者（roles/iam.serviceAccountTokenCreator）ロールがユーザー ID に設定されていることを確認します。テストに使用するフォルダがない場合は、フォルダを作成してアクセス権を構成します。

  5. 請求先アカウント ID、組織の表示名、テストフォルダまたはデモフォルダのフォルダ ID、次のユーザー グループのメールアドレスを記録します。

    • データ アナリスト
    • 暗号化されたデータ閲覧者
    • 平文リーダー
    • データ エンジニア
    • ネットワーク管理者
    • セキュリティ管理者
    • セキュリティ アナリスト

  6. プロジェクトを作成します。有効にする必要がある API のリストについては、README をご覧ください。

  7. Terraform のサービス アカウントを作成し、すべてのプロジェクトに適切なロールを割り当てます。

  8. アクセス制御ポリシーを設定する

  9. Google Cloud terraform-google-secured-data-warehouse リポジトリを使用するデータソースの場合、テスト環境でチュートリアルをデプロイして、ソリューションの動作を確認します。テストプロセスの一環として、次のことを検討します。

    1. 独自のサンプルデータを BigQuery ウェアハウスに追加します。
    2. 企業内のデータ アナリストと連携して、機密データへのアクセスと、BigQuery のデータを想定どおりに操作できるかどうかをテストします。

  10. terraform-google-secured-data-warehouse-onprem-ingest リポジトリを使用する外部データソースの場合は、テスト環境にソリューションをデプロイします。

    1. Terraform スクリプトのクローンを作成して実行し、Google Cloudで環境を設定します。

    2. ネットワークに Tink 暗号化ライブラリをインストールします。

    3. アプリケーションのデフォルト認証情報を設定して、ネットワークで Tink ライブラリを実行できるようにします。

    4. Cloud KMS で暗号鍵を作成します。

    5. Tink を使用して暗号化された鍵セットを生成します。

    6. 次のいずれかの方法を使用して、Tink でデータを暗号化します。

    7. ストリーミングまたは一括アップロードを使用して、暗号化されたデータを BigQuery にアップロードします。

  11. 外部データソースの場合、承認済みユーザーが BigQuery AEAD 復号関数を使用して、BigQuery から暗号化されていないデータを読み取ることができることを確認します。たとえば、次の create 復号関数を実行します。

    create view クエリを実行します。

    CREATE OR REPLACE VIEW `{project_id}.{bigquery_dataset}.decryption_view` AS

SELECT
 Card_Type_Code,
 Issuing_Bank,
 Card_Number,
 `bigquery_dataset.decrypt`(Card_Number) AS Card_Number_Decrypted
FROM `project_id.dataset.table_name`

    ビューから select クエリを実行します。

    SELECT
  Card_Type_Code,
  Issuing_Bank,
  Card_Number,
  Card_Number_Decrypted
FROM
`{project_id}.{bigquery_dataset}.decrypted_view`

    その他のクエリとユースケースについては、Cloud KMS による列レベルの暗号化をご覧ください。

  12. Security Command Center を使用して、コンプライアンス要件を基に新しく作成したプロジェクトをスキャンします。

  13. アーキテクチャを本番環境にデプロイします。

次のステップ