エンタープライズ データ管理と分析のプラットフォームをデプロイする

Last reviewed 2025-04-04 UTC

エンタープライズ データ マネジメントおよび分析プラットフォームは、セキュリティ制御を維持しながら機密情報を保存、分析、操作できるエンクレーブを提供します。エンタープライズ データメッシュ アーキテクチャを使用して、データ管理と分析用のプラットフォームを Google Cloud にデプロイできます。このアーキテクチャは、 Google Cloud コンポーネントが既存のオンプレミス コンポーネントや運用プロセスと連携するハイブリッドな環境で動作するように設計されています。

エンタープライズ データ メッシュ アーキテクチャには、次のものが含まれます。

• 次のものを構築するための一連の Terraform の構成、スクリプト、コードを含む GitHub リポジトリ。
  • Google の Cloud Data Management Capabilities（CDMS）キー コントロール フレームワークの実装を使用できるガバナンス プロジェクト。
  • インタラクティブ ワークフローと本番環境ワークフローをサポートするデータ プラットフォームの例。
  • 複数のデータ ドメインをサポートするデータ プラットフォーム内のプロデューサー環境。データ ドメインは、データ要素の論理グループです。
  • 複数のコンシューマー プロジェクトをサポートするデータ プラットフォーム内のコンシューマー環境。
  • Workload Identity 連携と Tink 暗号ライブラリを使用して、データを安全に Google Cloud に転送するデータ転送サービス。
  • 取り込みプロジェクト、非機密プロジェクト、機密プロジェクトを含むデータ ドメインの例。
  • データ コンシューマーがデータセットへのアクセスをリクエストし、データ オーナーがデータセットへのアクセスを許可するデータアクセス システムの例。この例には、これらのデータセットの IAM 権限を適宜変更するワークフロー マネージャーも含まれています。
• このアーキテクチャを使用して実装するアーキテクチャ、設計、セキュリティ管理、運用プロセスのガイド（このドキュメント）。

エンタープライズ データメッシュ アーキテクチャは、エンタープライズ基盤ブループリントとの互換性を確保できるように設計されています。エンタープライズ基盤ブループリントは、VPC ネットワークやロギングなど、このアーキテクチャが依存する多くの基本レベルのサービスを提供します。Google Cloud 環境に必要な機能が備わっている場合は、エンタープライズ基盤ブループリントをデプロイせずにこのアーキテクチャをデプロイできます。

このドキュメントは、このアーキテクチャを使用して Google Cloudで包括的なデータサービスを構築してデプロイできるクラウド アーキテクト、データ サイエンティスト、データ エンジニア、セキュリティ アーキテクトを対象としています。このドキュメントは、データ メッシュ、 Google Cloudデータ サービス、CDMC フレームワークの Google Cloud 実装のコンセプトを理解していることを前提としています。

アーキテクチャ

エンタープライズ データメッシュ アーキテクチャは、データの取り込み、データ処理、ガバナンスを可能にする機能を提供するために、レイヤード アプローチを採用しています。このアーキテクチャは、CI/CD ワークフローを通じてデプロイ、制御することを前提としています。次の図は、このアーキテクチャによってデプロイされたデータレイヤが環境内の他のレイヤとどのように関連しているかを示しています。

この図には次のものが含まれています。

• Google Cloud インフラストラクチャは、保存データの暗号化や転送中データの暗号化などのセキュリティ機能とともに、コンピューティングやストレージなどの基本的な構成要素を備えています。
• エンタープライズ基盤は、ID、ネットワーキング、ロギング、モニタリング、デプロイ システムといった、データ ワークロードに Google Cloud を導入するための一連の基本リソースを備えています。
• データレイヤは、データの取り込み、データの保存、データアクセス制御、データ ガバナンス、データ モニタリング、データ共有などのさまざまな機能を提供します。
• アプリケーション レイヤは、データレイヤのアセットを使用するさまざまなアプリケーションを表します。
• CI/CD には、インフラストラクチャ、ワークフロー、ソフトウェア コンポーネントのプロビジョニング、構成、管理、デプロイを自動化するツールが用意されています。これらのコンポーネントにより、デプロイの一貫性、信頼性、監査可能性を保証し、手作業による誤りを最小限に抑えて、全体的な開発サイクルを加速できます。

データ環境の使用方法を示すために、このアーキテクチャにはサンプル データ ワークフローが含まれています。サンプルデータ ワークフローでは、データ ガバナンス、データの取り込み、データ処理、データ共有、データ使用というプロセスを順に説明します。

アーキテクチャに関する重要な決定事項

次の表に、アーキテクチャの概要に関する判断項目をまとめます。

決定分野	決定
Google Cloud アーキテクチャ
リソース階層	このアーキテクチャでは、エンタープライズ基盤ブループリントのリソース階層を使用します。
ネットワーキング	このアーキテクチャには、Workload Identity 連携と Tink ライブラリを使用するデータ転送サービスの例が含まれています。
ロールと IAM 権限	このアーキテクチャには、セグメント化されたデータ プロデューサー ロール、データ コンシューマー ロール、データ ガバナンス ロール、データ プラットフォーム ロールが含まれます。
共通データサービス
メタデータ	このアーキテクチャでは、Data Catalog を使用してデータ メタデータを管理します。
ポリシーの一元管理	ポリシーを管理するために、アーキテクチャは Google Cloudの CDMC フレームワークの実装を使用します。
データアクセス管理	データへのアクセスを制御するために、アーキテクチャには、データ利用者がデータオーナーにデータアセットへのアクセスをリクエストする必要がある独立したプロセスが含まれています。
データ品質	このアーキテクチャでは、Cloud Data Quality Engine を使用して、指定されたテーブル列でデータ品質ルールを定義して実行し、正確性や完全性などの指標に基づいてデータ品質を測定します。
データ セキュリティ	このアーキテクチャでは、タグ付け、暗号化、マスキング、トークン化、IAM 制御を使用してデータ セキュリティを確保します。
データドメイン
データ環境	このアーキテクチャには、3 つの環境が含まれています。2 つの環境（非本番環境と本番環境）は、パイプラインによって駆動される運用環境です。1 つの環境（開発）はインタラクティブ環境です。
データオーナー	データオーナーは、データアセットの取り込み、処理、公開、アクセス権の付与を行います。
データ コンシューマ	データ コンシューマーがデータアセットへのアクセスをリクエストします。
オンボーディングと運用
パイプライン	このアーキテクチャでは、次のパイプラインを使用してリソースをデプロイします。 基盤パイプライン インフラストラクチャ パイプライン アーティファクト パイプライン サービス カタログ パイプライン
リポジトリ	各パイプラインは、責任の分離を可能にするために個別のリポジトリを使用します。
プロセスの流れ	このプロセスでは、本番環境への変更に送信者と承認者が含まれている必要があります。
Cloud Operations
データ プロダクトのスコアカード	レポート エンジンは、データ プロダクトのスコアカードを生成します。
Cloud Logging	このアーキテクチャでは、エンタープライズ基盤ブループリントのロギング インフラストラクチャを使用します。
Cloud Monitoring	このアーキテクチャでは、エンタープライズ基盤ブループリントのモニタリング インフラストラクチャが使用されます。

ID: ロールをグループにマッピングする

データメッシュは、エンタープライズ基盤のブループリントの既存の ID ライフサイクル管理、認可、認証アーキテクチャを活用します。ユーザーにはロールが直接割り当てられません。代わりに、グループが IAM でロールと権限を割り当てる主な方法となります。IAM のロールと権限は、基盤パイプラインでプロジェクトの作成時に割り当てられます。

データメッシュは、グループを 4 つの主要分野（インフラストラクチャ、データ ガバナンス、ドメインベースのデータ プロデューサー、ドメインベースのコンシューマー）のいずれかに関連付けます。

これらのグループの権限スコープは次のとおりです。

• インフラストラクチャ グループの権限スコープは、データ メッシュ全体です。
• データ ガバナンス グループの権限スコープは、データ ガバナンス プロジェクトです。
• ドメインベースのプロデューサーとコンシューマーの権限は、データ ドメインにスコープ設定されます。

次の表に、このデータ メッシュの実装で使用されるさまざまなロールと、関連する権限を示します。

インフラストラクチャ

グループ	説明	ロール
[e-mail]	データ メッシュの全体管理者	roles/owner（データ プラットフォーム）

データ ガバナンス

グループ	説明	ロール
[e-mail]	データ ガバナンス プロジェクトの管理者	データ ガバナンス プロジェクトに対する roles/owner
[e-mail]	データ ガバナンス コンポーネントを構築して維持するデベロッパー	データ ガバナンス プロジェクトに対する複数のロール（roles/viewer、BigQuery ロール、Data Catalog ロールなど）
[e-mail]	データ ガバナンス情報の閲覧者	roles/viewer
[e-mail]	ガバナンス プロジェクトのセキュリティ管理者	roles/orgpolicy.policyAdmin と roles/iam.securityReviewer。
[e-mail]	タグ テンプレートを使用する権限を持つグループ	roles/datacatalog.tagTemplateUser
[e-mail]	タグ テンプレートの使用とタグの追加の権限を持つグループ	roles/datacatalog.tagTemplateUser と roles/datacatalog.tagEditor。
[e-mail]	Security Command Center 通知のサービス アカウント グループ	なし。これはメンバーシップのグループであり、この名前でサービス アカウントが作成され、必要な権限が付与されます。

ドメインベースのデータ プロデューサー

グループ	説明	ロール
gcp-dm-{data_domain_name}[e-mail]	特定のデータドメインの管理者	データ ドメイン プロジェクトに対する roles/owner
gcp-dm-{data_domain_name}[e-mail]	データ ドメイン内でデータ プロダクトを構築して保守するデベロッパー	データ ドメイン プロジェクトに対する複数のロール（roles/viewer、BigQuery ロール、Cloud Storage ロールなど）
gcp-dm-{data_domain_name}[e-mail]	データドメイン情報の閲覧者	roles/viewer
gcp-dm-{data_domain_name}-metadata-editors@{var.domain}	Data Catalog エントリの編集者	Data Catalog エントリを編集するロール
gcp-dm-{data_domain_name}[e-mail]	データドメインのデータ スチュワード	メタデータとデータ ガバナンスのアスペクトを管理するロール

ドメインベースのデータ コンシューマー

グループ	説明	ロール
gcp-dm-consumer-{project_name}[e-mail]	特定のユーザー プロジェクトの管理者	コンシューマー プロジェクトに対する roles/owner
gcp-dm-consumer-{project_name}[e-mail]	コンシューマー プロジェクト内で作業しているデベロッパー	roles/viewer ロールや BigQuery ロールなど、コンシューマー プロジェクトの複数のロール
gcp-dm-consumer-{project_name}[e-mail]	コンシューマー プロジェクト情報の閲覧者	roles/viewer

組織構造

本番環境のオペレーションと本番環境のデータを区別するために、このアーキテクチャでは、ワークフローの開発とリリースに異なる環境を使用します。本番環境のオペレーションには、ワークフローのガバナンス、トレーサビリティ、再現性、ワークフローの結果の監査可能性が含まれます。本番環境データとは、組織の運営に必要なセンシティブ データのことです。すべての環境は、データを取得して操作できるセキュリティ制御を備えるように設計されています。

データ サイエンティストとエンジニアを支援するために、このアーキテクチャにはインタラクティブ環境が含まれています。この環境では、デベロッパーが環境を直接操作し、ソリューションの厳選されたカタログを通じてサービスを追加できます。運用環境は、アーキテクチャと構成がコード化されたパイプラインによって推進されます。

このアーキテクチャでは、データ ワークロードのデプロイのための基盤として、エンタープライズ基盤ブループリントの組織構造を使用します。次の図は、エンタープライズ データ メッシュ アーキテクチャで使用される最上位のフォルダとプロジェクトを示しています。

次の表に、アーキテクチャの一部である最上位のフォルダとプロジェクトを示します。

フォルダ	コンポーネント	説明
common	prj-c-artifact-pipeline	アーキテクチャのコード アーティファクトの構築に使用されるデプロイ パイプラインが含まれています。
	prj-c-service-catalog	インタラクティブ環境にリソースをデプロイするためにサービス カタログで使用されるインフラストラクチャが含まれています。
	prj-c-datagovernance	CDMC フレームワークの Google Cloud実装で使用されるすべてのリソースが含まれています。
development	fldr-d-dataplatform	インタラクティブ モードでユースケースを開発するためのデータ プラットフォームのプロジェクトとリソースが含まれています。
non-production	fldr-n-dataplatform	運用環境にデプロイするユースケースをテストするためのデータ プラットフォームのプロジェクトとリソースが含まれます。
production	fldr-p-dataplatform	本番環境にデプロイするデータ プラットフォームのプロジェクトとリソースが含まれています。

データ プラットフォーム フォルダ

データ プラットフォーム フォルダには、すべてのデータプレーン コンポーネントと一部の CDMC リソースが含まれています。また、データ プラットフォーム フォルダとデータ ガバナンス プロジェクトには CDMC リソースが含まれています。次の図は、データ プラットフォーム フォルダにデプロイされるフォルダとプロジェクトを示しています。

各データ プラットフォーム フォルダには、環境フォルダ（本番環境、非本番環境、開発環境）が含まれています。次の表に、各データ プラットフォーム フォルダ内のフォルダを示します。

フォルダ	説明
Producers	データドメインが含まれます。
一般ユーザー	コンシューマー プロジェクトが含まれます。
データドメイン	特定のドメインに関連付けられたプロジェクトが含まれます。

プロデューサー フォルダ

各プロデューサー フォルダには、1 つ以上のデータドメインが含まれています。データ ドメインとは、共通の意味、目的、ビジネス コンテキストを共有するデータ要素の論理グループを指します。データドメインを使用すると、組織内のデータアセットを分類して整理できます。次の図は、データドメインの構造を示しています。このアーキテクチャでは、各環境のデータ プラットフォーム フォルダにプロジェクトがデプロイされます。

次の表に、各環境のデータ プラットフォーム フォルダにデプロイされるプロジェクトを示します。

プロジェクト	説明
取り込み	取り込みプロジェクトは、データドメインにデータを取り込みます。このアーキテクチャは、BigQuery、Cloud Storage、Pub/Sub にデータをストリーミングする方法の例を示しています。取り込みプロジェクトには、取り込んだデータの変換と移動をオーケストレートするために使用できる Dataflow と Managed Service for Apache Airflow の例も含まれています。
非機密	機密情報を含まないプロジェクトには、匿名化されたデータが含まれています。データをマスク、コンテナ化、暗号化、トークン化、難読化できます。ポリシータグを使用して、データの表示方法を制御します。
機密	機密プロジェクトには平文データが含まれています。アクセスは IAM 権限で制御できます。

消費者フォルダ

コンシューマー フォルダには、コンシューマー プロジェクトが含まれています。コンシューマー プロジェクトは、必要な信頼境界に基づいてデータユーザーをセグメント化するメカニズムを提供します。各プロジェクトは個別のユーザー グループに割り当てられ、グループにはプロジェクトごとに必要なデータアセットへのアクセス権が割り当てられます。コンシューマー プロジェクトを使用して、グループのデータを収集、分析、拡張できます。

共通フォルダ

common フォルダには、さまざまな環境やプロジェクトで使用されるサービスが含まれています。このセクションでは、エンタープライズ データ メッシュを有効にするために共通フォルダに追加される機能について説明します。

CDMC アーキテクチャ

このアーキテクチャでは、データ ガバナンスに CDMC アーキテクチャを使用します。データ ガバナンス関数は、共通フォルダのデータ ガバナンス プロジェクトにあります。次の図は、CDMC アーキテクチャのコンポーネントを示しています。図中の番号は、 Google Cloudサービスが対応しているキー コントロールを表しています。

次の表に、エンタープライズ データ メッシュ アーキテクチャで使用される CDMC アーキテクチャのコンポーネントを示します。

CDMC コンポーネント	Google Cloud サービス	説明
アクセスとライフサイクル コンポーネント
鍵管理	Cloud KMS	機密データを保護する暗号鍵を安全に管理するサービス。
レコード マネージャー	Cloud Run	データ処理アクティビティの包括的なログと記録を保持し、組織がデータの使用状況を追跡および監査できるようにするアプリケーション。
アーカイブ ポリシー	BigQuery	データのストレージ ポリシーを含む BigQuery テーブル。
利用資格	BigQuery	機密データにアクセスできるユーザーに関する情報を保存する BigQuery テーブル。このテーブルにより、承認されたユーザーのみがロールと権限に基づいて特定のデータにアクセスできるようになります。
スキャン コンポーネント
データ損失	Sensitive Data Protection	アセット内のセンシティブ データを検査するために使用されるサービス。
DLP 検出結果	BigQuery	データ プラットフォーム内のデータ分類をカタログ化する BigQuery テーブル。
ポリシー	BigQuery	一貫したデータガバナンス プラクティス（データアクセス タイプなど）を含む BigQuery テーブル。
課金データのエクスポート	BigQuery	Cloud Billing からエクスポートされた費用情報を保存し、データアセットに関連付けられた費用指標の分析を可能にするテーブル。
Cloud Data Quality Engine	Cloud Run	テーブルと列のデータ品質チェックを実行するアプリケーション。
データ品質に関する検出結果	BigQuery	定義されたデータ品質ルールとデータアセットの実際の品質との間の不一致を記録する BigQuery テーブル。
レポート コンポーネント
スケジューラ	Cloud Scheduler	Cloud Data Quality Engine の実行タイミングと Sensitive Data Protection の検査のタイミングを制御するサービス。
レポート エンジン	Cloud Run	CDMC フレームワークのコントロールへの準拠を追跡および測定するレポートを生成するアプリケーション。
検出結果とアセット	BigQuery と Pub/Sub	タグの欠落、分類の誤り、コンプライアンスに準拠していない保存場所など、データ管理制御の不一致や矛盾に関する BigQuery レポート。
タグのエクスポート	BigQuery	Data Catalog から抽出されたタグ情報を含む BigQuery テーブル。
その他のコンポーネント
ポリシー管理	組織ポリシー サービス	データを地理的に保存できる場所の制限を定義して適用するサービス。
属性ベースのアクセス ポリシー	Access Context Manager	きめ細かい属性ベースのアクセス ポリシーを定義して適用し、許可された場所とデバイスの承認済みユーザーのみが機密情報にアクセスできるようにするサービス。
メタデータ	Data Catalog	データ メッシュで使用されているテーブルに関するメタデータ情報を保存するサービス。
Engine のタグ設定	Cloud Run	BigQuery テーブルのデータにタグを追加するアプリケーション。
CDMC レポート	データポータル	アナリストが CDMC アーキテクチャ エンジンによって生成されたレポートを表示できるダッシュボード。

CDMC の実装

次の表に、アーキテクチャが CDMC フレームワークのキー コントロールを実装する方法を示します。

CDMC コントロール要件	実装
データ管理のコンプライアンス	レポート エンジンは、非準拠のデータアセットを検出し、結果を Pub/Sub トピックにパブリッシュします。これらの結果は、データポータルを使用してレポートを作成するために BigQuery にも読み込まれます。
移行データとクラウド生成データの両方にデータの所有権が確立している	Data Catalog は、BigQuery からテクニカル メタデータを自動的にキャプチャします。Tag Engine は、参照テーブルからオーナー名やセンシティブ データ レベルなどのビジネス メタデータタグを適用します。これにより、すべてのセンシティブ データにコンプライアンスのためのオーナー情報がタグ付けされます。この自動タグ付けプロセスは、センシティブ データを特定して適切な所有者情報でラベル付けすることで、データ ガバナンスとコンプライアンスの実現に役立ちます。
データのソーシングと利用が統制され、自動化によってサポートされている	Data Catalog は、データアセットが信頼できるソースである場合に is_authoritative フラグでタグ付けして、データアセットを分類します。Data Catalog は、テクニカル メタデータとともに、この情報をデータ登録に自動的に保存します。Report Engine と Tag Engine は、Pub/Sub を使用して、信頼できるソースのデータ登録を検証してレポートできます。
データ主権と境界を越えるデータの移動が管理されている	組織のポリシー サービスは、データアセットに許可されるストレージ リージョンを定義し、Access Context Manager は、ユーザーの所在地に基づいてアクセスを制限します。Data Catalog は、承認されたストレージのロケーションをメタデータタグとして保存します。レポート エンジンは、これらのタグを BigQuery のデータアセットの実際のロケーションと比較し、不一致を Pub/Sub を使用して検出結果として公開します。Security Command Center は、定義されたポリシーの外部でデータが保存またはアクセスされた場合に脆弱性の検出結果を生成することで、モニタリングのレイヤを追加します。
データカタログが実装、使用され、相互運用されている	Data Catalog は、すべての BigQuery データアセットのテクニカル メタデータを保存して更新し、継続的に同期される Data Catalog を効果的に作成します。Data Catalog は、新しいテーブルとビュー、変更されたテーブルとビューがカタログに直ちに追加されるようにし、データアセットの最新のインベントリを維持します。
データ分類が定義され、使用されている	Sensitive Data Protection は、BigQuery データを検査し、機密情報のタイプを特定します。これらの検出結果は、分類参照テーブルに基づいてランク付けされ、最も高い機密性レベルが Data Catalog の列レベルとテーブルレベルでタグとして割り当てられます。Tag Engine は、新しいデータアセットが追加されたときや既存のデータアセットが変更されたときに、機密性タグで Data Catalog を更新することで、このプロセスを管理します。このプロセスにより、機密性に基づいてデータ分類が常に更新されます。この分類は、Pub/Sub と統合レポートツールを使用してモニタリングとレポート作成を行うことができます。
データの利用資格が管理、適用、追跡されている	BigQuery のポリシータグは、列レベルでセンシティブ データへのアクセスを制御します。これにより、割り当てられたポリシータグに基づいて、承認されたユーザーのみが特定のデータにアクセスできるようになります。IAM はデータ ウェアハウスへの全体的なアクセスを管理し、Data Catalog は機密性の分類を保存します。定期的なチェックを実施して、すべてのセンシティブ データに該当するポリシータグがあることを確認します。不一致が見つかった場合は、Pub/Sub を使用して修復のために報告します。
データの倫理的アクセス、使用、結果が管理されている	プロバイダとコンシューマーの両方のデータ共有契約は、専用の BigQuery データ ウェアハウスに保存され、使用目的を制御します。Data Catalog は、プロバイダ契約情報でデータアセットにラベルを付けますが、コンシューマー契約はアクセス制御用の IAM バインディングにリンクされます。クエリラベルは利用目的を適用します。利用者は機密データをクエリする際に有効な目的を指定する必要があります。この目的は、BigQuery の利用資格に対して検証されます。BigQuery の監査証跡は、すべてのデータアクセスを追跡し、データ共有の合意の遵守を保証します。
データが保護され、コントロールが証明されている	Google のデフォルトの保存データの暗号化は、ディスクに保存されているデータの保護に役立ちます。Cloud KMS は、鍵管理を強化するために顧客管理の暗号鍵（CMEK）をサポートしています。BigQuery は、匿名化のために列レベルの動的データ マスキングを実装し、データの取り込み時のアプリケーション レベルの匿名化をサポートしています。Data Catalog は、データアセットに適用される暗号化と匿名化の手法のメタデータタグを保存します。自動チェックにより、暗号化と匿名化の方法が事前定義されたセキュリティ ポリシーに準拠していることが確認されます。不一致は Pub/Sub を使用して検出結果として報告されます。
データ プライバシー フレームワークが定義され、運用されている	Data Catalog は、センシティブ データアセットに、影響評価に関連する情報（件名の場所や評価レポートのリンクなど）を含むタグを付けます。Tag Engine は、データの機密性と BigQuery のポリシー テーブルに基づいてこれらのタグを適用します。このポリシー テーブルでは、データとサブジェクトの所在地に基づいて評価要件が定義されます。この自動タグ付けプロセスにより、影響評価要件の遵守状況を継続的にモニタリングしてレポートを作成できます。これにより、必要に応じてデータ保護影響評価（DPIA）または保護影響評価（PIA）を実施できます。
データ ライフサイクルが計画され、管理されている	Data Catalog は、保持期間と有効期限アクション（アーカイブや削除など）を指定して、データアセットに保持ポリシーのラベルを付けます。レコード マネージャーは、定義されたタグに基づいて BigQuery テーブルをパージまたはアーカイブすることで、これらのポリシーの適用を自動化します。この適用により、データ ライフサイクル ポリシーが遵守され、データ保持要件が満たされます。不一致が検出されると、Pub/Sub を使用して報告されます。
データ品質が管理されている	Cloud Data Quality Engine は、指定されたテーブル列でデータ品質ルールを定義して実行し、正確性や完全性などの指標に基づいてデータ品質を測定します。成功率やしきい値などのこれらのチェックの結果は、Data Catalog のタグとして保存されます。これらの結果を保存すると、データ品質の継続的なモニタリングとレポートが可能になり、許容可能なしきい値からの問題や逸脱は Pub/Sub を使用して検出結果として公開されます。
費用管理の原則が確立され、適用されている	Data Catalog には、データアセットの費用関連指標（クエリ費用、ストレージ費用、データ下り（外向き）費用など）が保存されます。これらの指標は、Cloud Billing から BigQuery にエクスポートされたお支払い情報を使用して計算されます。費用関連の指標を保存することで、費用を包括的に追跡して分析し、費用ポリシーの遵守とリソースの効率的な使用を確保できます。異常は Pub/Sub を使用して報告されます。
データの来歴と系列が理解されている	Data Catalog の組み込みのデータ系列機能は、データアセットの来歴と系列を追跡し、データの流れを視覚的に表現します。また、データの取り込みスクリプトは、Data Catalog でデータの元のソースを特定してタグ付けし、データの出所まで遡って追跡できるようにします。

データアクセス管理

アーキテクチャのデータへのアクセスは、運用制御（Dataflow ジョブの実行など）とデータアクセス制御を分離する独立したプロセスによって制御されます。ユーザーの Google Cloud サービスへのアクセスは、環境または運用の懸念事項によって定義され、クラウド エンジニアリング グループによってプロビジョニングおよび承認されます。 Google Cloud データアセット（BigQuery テーブルなど）へのユーザーのアクセスは、プライバシー、規制、ガバナンスに関する懸念事項であり、生成側と使用側の間のアクセス契約の対象となり、次のプロセスを通じて制御されます。次の図は、さまざまなソフトウェア コンポーネントの相互作用を通じてデータアクセスがどのようにプロビジョニングされるかを示しています。

上の図に示すように、データアクセスのオンボーディングは次のプロセスで処理されます。

• クラウド データアセットは、Data Catalog によって収集され、インベントリに登録されます。
• ワークフロー マネージャーは、Data Catalog からデータアセットを取得します。
• データ オーナーがワークフロー マネージャーにオンボーディングされます。

データアクセス管理の動作は次のとおりです。

1. データ コンシューマーが特定のアセットをリクエストします。
2. アセットのデータ オーナーにリクエストが通知されます。
3. データオーナーがリクエストを承認または拒否します。
4. リクエストが承認されると、ワークフロー マネージャーはグループ、アセット、関連付けられたタグを IAM マッパーに渡します。
5. IAM マッパーは、ワークフロー マネージャーのタグを IAM 権限に変換し、指定されたグループにデータアセットの IAM 権限を付与します。
6. ユーザーがデータアセットにアクセスしようとすると、IAM はグループの権限に基づいてアセットへのアクセスを評価します。 Google Cloud
7. 許可されている場合、ユーザーはデータアセットにアクセスします。

ネットワーキング

データ セキュリティ プロセスは、ソース アプリケーションで開始されます。ソース アプリケーションは、オンプレミスまたはターゲットGoogle Cloud プロジェクトの外部にある別の環境に存在している可能性があります。ネットワーク転送が行われる前に、このアプリケーションは Workload Identity 連携を使用して、Google Cloud API に対して安全に認証を行います。これらの認証情報を使用して Cloud KMS とやり取りし、必要な鍵を取得またはラップします。次に、Tink ライブラリを使用して、事前定義されたテンプレートに従ってセンシティブ データ ペイロードの初期暗号化と匿名化を行います。

データ ペイロードを保護したら、ペイロードを Google Cloud 取り込みプロジェクトに安全に転送する必要があります。オンプレミス アプリケーションの場合は、Cloud Interconnect または Cloud VPN を使用できます。Google Cloud ネットワーク内で、Private Service Connect を使用して、ターゲット プロジェクトの VPC ネットワーク内の取り込みエンドポイントにデータを転送します。Private Service Connect を使用すると、ソース アプリケーションはプライベート IP アドレスを使用して Google API に接続し、トラフィックがインターネットに公開されないようにします。

ネットワーク パス全体と、取り込みプロジェクト内のターゲット取り込みサービス（Cloud Storage、BigQuery、Pub/Sub）は、VPC Service Controls の境界によって保護されます。この境界によりセキュリティ境界が適用され、ソースから送信された保護データは、その特定のプロジェクト内の承認されたGoogle Cloud サービスにのみ取り込むことができます。

ロギング

このアーキテクチャでは、エンタープライズ基盤ブループリントによって提供される Cloud Logging の機能を使用します。

パイプライン

エンタープライズ データメッシュ アーキテクチャでは、一連のパイプラインを使用して、インフラストラクチャ、オーケストレーション、データセット、データ パイプライン、アプリケーション コンポーネントをプロビジョニングします。このアーキテクチャのリソース デプロイ パイプラインは、Infrastructure as Code（IaC）ツールとして Terraform を使用し、CI/CD サービスとして Cloud Build を使用して、Terraform 構成をアーキテクチャ環境にデプロイします。次の図は、パイプライン間の関係を示しています。

基盤パイプラインとインフラストラクチャ パイプラインは、エンタープライズ基盤ブループリントの一部です。次の表に、パイプラインの目的と、パイプラインがプロビジョニングするリソースを示します。

パイプライン	プロビジョニングしたユーザー	リソース
基盤パイプライン	ブートストラップ	データ プラットフォームのフォルダとサブフォルダ 共通のプロジェクト インフラストラクチャ パイプラインのサービス アカウント インフラストラクチャ パイプラインの Cloud Build ビルドトリガー 共有 VPC VPC Service Controls 境界
インフラストラクチャ パイプライン	基盤パイプライン	コンシューマ プロジェクト サービス カタログのサービス アカウント サービス カタログ パイプラインの Cloud Build ビルドトリガー アーティファクト パイプラインのサービス アカウント アーティファクト パイプラインの Cloud Build トリガー
サービス カタログ パイプライン	インフラストラクチャ パイプライン	サービス カタログ バケットにデプロイされたリソース
アーティファクト パイプライン	インフラストラクチャ パイプライン	アーティファクト パイプラインは、データメッシュで使用されるコードベースのさまざまなコンテナやその他のコンポーネントを生成します。

各パイプラインには、コードと構成ファイルの取得元となる独自のリポジトリのセットがあります。各リポジトリには職務分離があり、運用コードのデプロイの送信者と承認は異なるグループの責任となります。

サービス カタログによるインタラクティブなデプロイ

インタラクティブ環境は、アーキテクチャ内の開発環境であり、開発フォルダに存在します。インタラクティブ環境のメイン インターフェースはサービス カタログです。これにより、デベロッパーは事前構成されたテンプレートを使用して Google サービスをインスタンス化できます。これらの事前構成済みテンプレートは、サービス テンプレートと呼ばれます。サービス テンプレートを使用すると、CMEK 暗号化を必須にするなど、セキュリティ ポスチャーを強化できます。また、ユーザーが Google API に直接アクセスすることも防止できます。

次の図は、インタラクティブ環境のコンポーネントと、データ サイエンティストがリソースをデプロイする方法を示しています。

サービス カタログを使用してリソースをデプロイする手順は次のとおりです。

1. MLOps エンジニアが Google Cloud用の Terraform リソース テンプレートを Git リポジトリに配置する。
2. Git Commit コマンドにより、Cloud Build パイプラインがトリガーされます。
3. Cloud Build がテンプレートと関連構成ファイルを Cloud Storage にコピーする。
4. MLOps エンジニアがサービス カタログ ソリューションとサービス カタログを手動で設定する。エンジニアがインタラクティブ環境でサービス カタログをサービス プロジェクトと共有する。
5. データ サイエンティストがサービス カタログからリソースを選択する。
6. サービス カタログはテンプレートをインタラクティブ環境にデプロイする。
7. リソースが必要な構成スクリプトを pull する。
8. データ サイエンティストがリソースを操作する。

アーティファクト パイプライン

データの取り込みプロセスでは、Managed Airflow と Dataflow を使用して、データ ドメイン内のデータの移動と変換をオーケストレートします。アーティファクト パイプラインは、データの取り込みに必要なすべてのリソースをビルドし、サービスがアクセスできるように適切な場所にリソースを移動します。アーティファクト パイプラインは、オーケストレーターが使用するコンテナ アーティファクトを作成します。

セキュリティ管理

エンタープライズ データメッシュ アーキテクチャでは、デフォルトの Google Cloud 機能、 Google Cloudサービス、エンタープライズ基盤ブループリントを通じて構成されたセキュリティ機能を含む多層防御のセキュリティ モデルを使用します。次の図は、アーキテクチャのさまざまなセキュリティ管理のレイヤを示しています。

次の表に、各レイヤのリソースに関連付けられているセキュリティ対策を示します。

層	リソース	セキュリティ対策
CDMC フレームワーク	Google Cloud CDMC の実装	データアセットの保護、管理、制御に役立つガバナンス フレームワークを提供します。詳細については、CDMC キー コントロール フレームワークをご覧ください。
デプロイ	インフラストラクチャ パイプライン	インフラストラクチャのデプロイ、コンテナのビルド、データ パイプラインの作成を行う一連のパイプラインを提供します。パイプラインを使用することで、監査可能性、トレーサビリティ、再現性を確保できます。
	アーティファクト パイプライン	インフラストラクチャ パイプラインによってデプロイされないさまざまなコンポーネントをデプロイします。
	Terraform テンプレート	システム インフラストラクチャを構築します。
	Open Policy Agent	プラットフォームが選択したポリシーに準拠していることを確認します。
ネットワーク	Private Service Connect	API レイヤと IP レイヤでアーキテクチャ リソースのデータの引き出しを保護します。プライベート IP アドレスを使用して Google Cloud APIs と通信できるため、インターネットへのトラフィックの漏洩を回避できます。
	プライベート IP アドレスを持つ VPC ネットワーク	インターネットに接続された脅威への露出を減らすのに役立ちます。
	VPC Service Controls	機密リソースをデータの引き出しから保護します。
	ファイアウォール	VPC ネットワークを不正アクセスから保護します。
アクセス管理	Access Context Manager	誰がどのリソースにアクセスできるかを制御し、リソースの不正使用を防止します。
	Workload Identity 連携	オンプレミス環境からプラットフォームにデータを転送するために外部認証情報を必要としなくなります。
	Data Catalog	ユーザーが利用できるアセットのインデックスを提供します。
	IAM	きめ細かいアクセスを提供します。
暗号化	Cloud KMS	暗号鍵とシークレットを管理し、保存データの暗号化と転送データの暗号化によってデータを保護します。
	Secret Manager	IAM によって制御されるパイプラインのシークレット ストアを提供します。
	保存時の暗号化	デフォルトでは、 Google Cloud は保存データを暗号化します。
	転送データの暗号化	デフォルトでは、 Google Cloud は転送中のデータを暗号化します。
検出	Security Command Center	Google Cloud組織内の構成ミスや悪意のあるアクティビティの検出に役立ちます。
	継続的アーキテクチャ	ユーザーが定義した一連の OPA ポリシーとの照合により、 Google Cloud 組織を継続的に確認します。
	IAM Recommender	ユーザー権限を分析し、最小権限の原則を適用するために権限の削減に関する提案を行います。
	ファイアウォール インサイト	全体的なセキュリティ ポスチャーを強化するため、ファイアウォール ルールを分析し、過度に制限の緩いファイアウォール ルールを特定して、より制限の厳しいファイアウォールを提案します。
	Cloud Logging	システムの活動を可視化して、異常や悪意のある活動の検出を実現します。
	Cloud Monitoring	不審な活動の特定に役立つ重要なシグナルとイベントを追跡します。
予防	組織ポリシー	Google Cloud組織内のアクションを制御して制限できます。

Workflows

以降のセクションでは、データ プロデューサーのワークフローとデータ コンシューマーのワークフローの概要を説明し、データの機密性とユーザーロールに基づいて適切なアクセス制御を確保します。

データ プロデューサーのワークフロー

次の図は、BigQuery に転送されるデータの保護方法を示しています。

データ転送のワークフローは次のとおりです。

1. Workload Identity 連携と統合されたアプリケーションは、Cloud KMS を使用してラップされた暗号鍵を復号します。
2. アプリケーションは、Tink ライブラリを使用して、テンプレートを使用してデータを匿名化または暗号化します。
3. アプリケーションは、 Google Cloudの取り込みプロジェクトにデータを転送します。
4. データは Cloud Storage、BigQuery、Pub/Sub に届きます。
5. 取り込みプロジェクトでは、テンプレートを使用してデータの復号または再識別が行われます。
6. 復号されたデータは、別の匿名化テンプレートに基づいて暗号化またはマスクされ、非機密プロジェクトに配置されます。タグは、タグ付けエンジンによって必要に応じて適用されます。
7. 機密ではないプロジェクトのデータが機密プロジェクトに転送され、再識別されます。

以下のデータアクセスは許可されています。

• 機密プロジェクトにアクセスできるユーザーは、すべての未加工の平文データにアクセスできます。
• 非機密プロジェクトにアクセスできるユーザーは、データに関連付けられたタグと権限に基づいて、マスクされたデータ、トークン化されたデータ、暗号化されたデータにアクセスできます。

データ利用者のワークフロー

次の手順では、コンシューマーが BigQuery に保存されているデータにアクセスする方法について説明します。

1. データ コンシューマーは、Data Catalog を使用してデータアセットを検索します。
2. データ利用者は、目的のアセットを見つけたら、データアセットへのアクセスをリクエストします。
3. データオーナーは、アセットへのアクセス権を付与するかどうかを決定します。
4. コンシューマーがアクセス権を取得すると、ノートブックとソリューション カタログを使用して、データアセットを分析して変換できる環境を作成できます。

まとめ

GitHub リポジトリには、エンタープライズ基盤をデプロイした後にGoogle Cloud にデータ メッシュをデプロイする手順が詳しく記載されています。アーキテクチャをデプロイするプロセスでは、既存のインフラストラクチャ リポジトリを変更し、新しいデータ メッシュ固有のコンポーネントをデプロイします。

次の手順に沿って操作します。

1. 次のものを含むすべての前提条件を満たします。
   1. Google Cloud CLI、Terraform、Tink、Java、Go をインストールします。
   2. エンタープライズ基盤ブループリント（v4.1）をデプロイします。
   3. 次のローカル リポジトリを維持します。
      • gcp-data-mesh-foundations
      • gcp-bootstrap
      • gcp-environments
      • gcp-networks
      • gcp-org
      • gcp-projects
2. 既存の基盤ブループリントを変更し、データ メッシュ アプリケーションをデプロイします。項目ごとに、次の操作を行います。
   1. ターゲット リポジトリで、Plan ブランチをチェックアウトします。
   2. データ メッシュ コンポーネントを追加するには、gcp-data-mesh-foundations から関連するファイルとディレクトリをコピーして、適切な基盤ディレクトリに貼り付けます。必要に応じてファイルを上書きします。
   3. Terraform ファイル（*.tfvars や *.tf など）でデータ メッシュの変数、ロール、設定を更新します。GitHub トークンを環境変数として設定します。
   4. 各リポジトリで Terraform の初期化、プラン、適用オペレーションを実行します。
   5. 変更を commit し、コードをリモート リポジトリに push して、pull リクエストを作成し、開発環境、非本番環境、本番環境にマージします。

次のステップ

• データメッシュのアーキテクチャと機能について確認する。
• Google Cloud から安全な BigQuery データ ウェアハウスにデータをインポートする。
• BigQuery データ ウェアハウスに CDMC のキー コントロール フレームワークを実装する。
• エンタープライズ基盤ブループリントを確認する。