G-gen の杉村です。Google Cloud の Dataplex を活用することで、BigQuery や Cloud Storage などで構成された データ分析基盤の権限管理を抽象化して、簡素に運用することができます。当記事では、Dataplex による権限管理の仕組みを、図を交えて解説します。

• はじめに
  • Dataplex とは
  • Dataplex による権限管理
  • メリット
• 前提知識
  • IAM の基本
  • レイク、ゾーン、アセット、エンティティ
  • 注意点
• サンプルアーキテクチャ
• Google アカウントとクエリ実行プロジェクト
• Google アカウントと Dataplex リソース
  • 紐付きの意味
  • ロールの詳細（データへのアクセス）
  • ロールの詳細（メタデータへのアクセス）
• サービスエージェントとデータ保持プロジェクト
• 管理ユーザーインターフェイス
  • Dataplex リソース管理
  • 権限管理
• リソースの検索（Dataplex Univeresal Catalog）
  • Dataplex アセットの検索
  • その他のリソースの検索
  • Dataplex Universal Catalog の詳細
• 導入
  • Dataplex の初期導入
  • 通常の IAM の権限管理からの移行
  • 既存の BigQuery データセットへの権限調査
• Tips : 列レベルのアクセス制御・行レベルのセキュリティとの併用

はじめに

Dataplex とは

Dataplex は Google Cloud（旧称 GCP）で提供されている、データの統合管理のためのフルマネージドサービスです。詳細は、以下の記事で紹介されています。

blog.g-gen.co.jp

Dataplex の数ある機能の中でも、当記事では、BigQuery や Cloud Storage などのデータアセットに対する権限管理の仕組みについて解説します。

• 参考 : Dataplex の概要
• 参考 : IAM によるアクセス制御

Dataplex による権限管理

一般的に、BigQuery や Cloud Storage などの Google Cloud リソースに対するアクセス制御は、Identity and Access Management（IAM）で行われます。

しかし、データマネジメントの背景で、リソースが多くのプロジェクトに分散していたり、データ利用者の数が多数の場合、IAM を使った従来型の権限管理は煩雑になり、適切なアクセス制御のための権限管理の運用が難しくなる場合があります。

Dataplex では、レイク、ゾーン、アセットといった抽象オブジェクトを用いて、権限管理のための仮想的な階層を構成することで、データ分析基盤（データマネジメント基盤）の権限管理を容易にできます。データの仮想化階層を構成することで、物理的にはデータが分散していながら、論理的には適切に管理されているデータメッシュを目指すのが、Dataplex のコンセプトです。

データメッシュについての詳細は、以下の記事をご参照ください。

• 参考 : Dataplexを徹底解説！ - G-gen Tech Blog - データメッシュとは

メリット

Dataplex でデータへのアクセス権限を管理するメリットとして、以下のようなものが挙げられます。

• 様々なプロジェクトに分散したデータの権限管理を集約
• ユーザーにとって意味のある単位（レイク、ゾーン等）で権限を付与できる

前提知識

IAM の基本

当記事では、Google Cloud の IAM の基本的な仕組み（IAM bindings、ロール、継承等）が理解されていることを前提に記載しています。これらの概念については、以下の記事をご参照ください。

blog.g-gen.co.jp

レイク、ゾーン、アセット、エンティティ

レイク、ゾーン、アセット、エンティティは、それぞれデータ管理のための仮想的な階層です。

レイクは、データのドメインやビジネスユニット（部門）によって切り分ける、論理的な管理単位です。Dataplex の管理単位としては一番大きいものです。

ゾーンは、レイクの下位階層の管理単位です。データの種類やセキュリティレベルなどによって切り分けます。

アセットは、最小の管理単位です。1つのアセットは、1つの Cloud Storage バケットまたは BigQuery データセットに対応します。アセットとして登録する Cloud Storage バケットや BigQuery データセットは、Dataplex の管理プロジェクトとは別のプロジェクトに存在していて構いません（ただし、別組織のリソースは登録できません）。

アセットに Cloud Storage バケットまたは BigQuery データセットを登録すると、中身のオブジェクトやテーブル等が自動的にエンティティとして登録されます。

• 参考 : Dataplex の概要 - 用語

注意点

ゾーンは1つのレイクにしか所属できません。

また、ゾーンの下位リソースであるアセットも、1つのゾーンにしか所属できません。

サンプルアーキテクチャ

当記事では、以下のような簡易的な構成を用いて、Dataplex の権限管理の仕組みを解説します。

ここでは、以下のようなプロジェクトを考えます。

プロジェクト名	概要
dptest-workload-a	クエリを実行するためのプロジェクト（ユーザー dptest-user-a 向け）
dptest-workload-b	クエリを実行するためのプロジェクト（ユーザー dptest-user-b 向け）
dptest-data-001	BigQuery データセットが配置されているプロジェクト（A 部署向け）
dptest-data-002	BigQuery データセットが配置されているプロジェクト（B 部署向け）
dptest-dataplex	Dataplex の設定管理用のプロジェクト

ユーザーとしては、それぞれ異なる部署に所属する dptest-user-a と dptest-user-b を想定します。

また、プロジェクト dptest-dataplex には、サービスエージェントである service-${プロジェクト番号}@gcp-sa-dataplex.iam.gserviceaccount.com が存在します。これは、Dataplex API を有効化すると自動的に作成される、特殊なサービスアカウントです。

上記の図に、IAM ロールの紐付きを書き加えると、以下のとおりです。

青い線とその上に書かれているロール名は、プリンシパルがリソースに対してどのロールを持っているか（IAM bindings）を表します。

ここからは、各ロール紐付き（IAM bindings）の意味について説明します。図と見比べながら、解説文をお読みください。

Google アカウントとクエリ実行プロジェクト

Google アカウント（またはグループ）すなわちデータ分析基盤のユーザーは、クエリ実行用のプロジェクトに対して BigQuery ジョブユーザー（roles/bigquery.jobUser）ロールを持ちます。

これにより、BigQuery のコンピュートリソースを消費してジョブを実行する権限が得られます。ジョブ実行権限は、データへのアクセス権限とは関係ありません。また、BigQuery のコンピュート料金は、ジョブを実行したプロジェクトに課金されます。

BigQuery の IAM 権限については、以下の記事でも詳細に解説しています。ジョブ実行権限とデータアクセス権限の分離の概念についても解説されていますので、ご参照ください。

blog.g-gen.co.jp

Google アカウントと Dataplex リソース

紐付きの意味

Google アカウントは、Dataplex のアセットに対して、Dataplex データオーナー（roles/dataplex.dataOwner）や Dataplex データリーダー（roles/dataplex.dataReader）のロールを持っています。

これにより、アセットに登録されている BigQuery データセットや Cloud Storage バケットに対してのデータアクセス権限が付与されます。

Dataplex データオーナー（roles/dataplex.dataOwner）であれば、データセット内のテーブルに対して読み取り、書き込み、テーブルの削除や作成の権限を持ちます。Dataplex データリーダー（roles/dataplex.dataReader）は、読み取りのみです。

図ではアセットにロールを紐付けていますが、レイクにロールを紐付けた場合、配下のすべてのゾーンやアセットに権限が継承されます。ゾーンにロールを紐付けた場合、配下のすべてのアセットに権限が継承されます。アセットの中の個々のエンティティには、直接ロールを紐付けることはできません。

なお、ゾーン、レイク、アセットには、Dataplex や BigQuery データセットとは別の組織（Organization）のアカウントでも、ロールを付与することができます。これにより、Google アカウントのドメインが異なる協力会社やグループ会社のアカウントの権限管理も、Dataplex で行うことができます。

ロールの詳細（データへのアクセス）

レイク、ゾーン、アセットに紐付けられるロールは、以下の3種類です。

ロール	実行可能なアクション
Dataplex データリーダー (roles/dataplex.dataReader)	データとメタデータの読み取り
Dataplex データライター (roles/dataplex.dataWriter)	データの書き込み、変更、削除（メタデータは不可。またデータの読み取りも不可）
Dataplex データオーナー (roles/dataplex.dataOwner)	データとメタデータの読み取り、書き込み、変更、削除。子リソースの作成（BigQuery テーブル等）

• 参考 : Dataplex IAM ロール - データロール

なお、2025年4月現在の当社の検証では、Dataplex データライター（roles/dataplex.dataWriter）だけを付与されたプリンシパルは、BigQuery テーブルへ INSERT や UPDATE を実行できませんでした。Dataplex データライター（roles/dataplex.dataWriter）と Dataplex データリーダー（roles/dataplex.dataReader）の両方を付与した場合に、INSERT や UPDATE が可能になりました。

ロールの詳細（メタデータへのアクセス）

前述の3ロールは、データそのものへのアクセス権限を付与するものです。もし、利用者にはデータそのものへのアクセス権限は与えず、メタデータだけを閲覧したり検索したりさせたい場合などには、以下のロールも利用できます。

ロール	実行可能なアクション
Dataplex メタデータ読み取り (roles/dataplex.metadataReader)	ゾーンやアセットのメタデータの読み取り
Dataplex メタデータ ライター (roles/dataplex.metadataWriter)	ゾーンやアセットのメタデータの読み取りと書き込み、変更、削除

ただし、Dataplex Univeresal Catalog で検索を実行する場合、検索実行者は上記のロールだけでなく、Dataplex Catalog 閲覧者（roles/dataplex.catalogViewer）ロール等を検索実行プロジェクトに対して持っている必要があります。

例えばアカウント dptest-user-a は、自身用のクエリ実行プロジェクトである dptest-workload-a プロジェクトに対して Dataplex Catalog 閲覧者（roles/dataplex.catalogViewer）ロールを持ち、かつゾーン my-zone-001 に対して Dataplex メタデータ読み取り（roles/dataplex.metadataReader）ロールを持っているとします。

この場合、アカウント dptest-user-a は、dptest-workload-a プロジェクト上で検索を行うことができます。検索結果には、ゾーン my-zone-001 のアセットが表示されます。

サービスエージェントとデータ保持プロジェクト

Dataplex のサービスエージェントは、データ保持プロジェクトに対して、Cloud Dataplex サービスエージェント（roles/dataplex.serviceAgent）ロールを持っています。

これにより、Dataplex はデータリソースの実体に対して読み取りや書き込みを行うことができるため、ユーザーは実体リソースに対して直接権限を持つ必要性がなくなります。Dataplex が、権限の中継を行っているようなイメージです。

なお、サービスエージェントがこの権限を対象リソースに対して持たない状態で、BigQuery データセット等をアセットとして登録しようとすると、以下のような警告が表示されます。

Dataplex service account service-(PROJECT_NUMBER)@gcp-sa-dataplex.iam.gserviceaccount.com does not have sufficient permission on BigQuery dataset 'projects/(PROJECT_ID)/datasets/(DATASET_ID)'. Please grant it role roles/dataplex.serviceAgent on the dataset or parent project.

解消するには、対象のプロジェクトかデータセットにおいて、サービスエージェントに対して Cloud Dataplex サービスエージェント（roles/dataplex.serviceAgent）ロールを紐付けます。

付与すべきロールについて、公式ドキュメントでは、対象リソースが BigQuery の場合に「BigQuery 管理者ロールを Dataplex サービス アカウントに付与する必要があります。」としています。しかし、コンソール上の警告メッセージでは Cloud Dataplex サービスエージェントロールとされていることに加えて、同ロールには BigQuery への十分なアクセス権限が含まれていることから、どちらのロールの付与でも構いません。

• 参考 : レイク内のデータアセットを管理する - BigQuery データセットに対するロールを付与する

管理ユーザーインターフェイス

Dataplex リソース管理

Google Cloud コンソールの「Dataplex > 管理」画面で、レイク、ゾーン、アセット、エンティティの作成や、一覧の確認ができます。

この画面でリソースの作成や編集を行うには、操作者のアカウントが Dataplex プロジェクトに対して Dataplex 管理者（roles/dataplex.admin）ロールや、Dataplex 編集者（roles/dataplex.editor）ロール等を持っている必要があります。

権限管理

Google Cloud コンソールの「Dataplex > 安全」画面で、Dataplex リソース（レイク、ゾーン、アセット）に付与されている権限を管理できます。なお「安全」は日本語コンソールの表記であり、英語版では「Secure」となっています。

この画面では、レイク、ゾーン、アセットが一覧表示され、またそれぞれに紐付いているプリンシパルと IAM ロールの一覧表示や編集ができます。

なお、この「安全」からだけではなく、先程の個別のリソース管理画面からも、権限の付与や確認は可能です。

この画面で権限管理を行うには、操作者のアカウントが Dataplex プロジェクトに対して Dataplex 管理者（roles/dataplex.admin）ロール等を持っている必要があります。一方、Dataplex 編集者（roles/dataplex.editor）ロールだと、レイク、ゾーン、アセットの作成や編集はできるものの、権限の編集はできません。

• 参考 : レイクを保護する

リソースの検索（Dataplex Univeresal Catalog）

Dataplex アセットの検索

Dataplex データオーナー（roles/dataplex.dataOwner）や Dataplex データリーダー（roles/dataplex.dataReader）ロールをレイク、ゾーン、アセットに対して持っているアカウントは、Dataplex Univeresal Catalog を使い、アセットの検索ができます。

Dataplex Univeresal Catalog を使って検索を行うアカウントは、検索を実行するプロジェクトに対して、Dataplex Catalog 閲覧者（roles/dataplex.catalogViewer）ロール等を持っている必要があります。例えば、アカウント dptest-user-b はクエリ実行用プロジェクトである dptest-workload-b に対してDataplex Catalog 閲覧者ロールを持っていれば、同プロジェクトの Dataplex Univeresal Catalog 検索画面で、アセットを検索することができます。

• 参考 : Dataplex Univeresal Catalog でリソースを検索する

このとき、検索結果に表示されるのは、自信がメタデータ読み取り権限を持っているリソースのみです。前述の「ロールの詳細（データへのアクセス）」「ロールの詳細（メタデータへのアクセス）」の項目を参照してください。

その他のリソースの検索

Dataplex Universal Catalog では、Dataplex 上で権限を与えたアセットだけではなく、メタデータの閲覧権限を持っているすべてのリソースが検索されます。BigQuery データ閲覧者のようなロールをプロジェクトに対して持っていれば、それらの BigQuery データセットが検索結果として表示されます。

その他にも Bigtable、Spanner、Dataform リポジトリ、Pub/Sub トピックなどのメタデータが自動的に Dataplex Universal Catalog に登録されており、権限を持っていれば検索が可能です。

• 参考 : Dataplex Universal Catalog のデータカタログ管理について - サポート対象のソース

Dataplex Universal Catalog の詳細

その他、Dataplex Universal Catalog の詳細については、以下の記事も参考にしてください。

blog.g-gen.co.jp

導入

Dataplex の初期導入

Dataplex を使わない場合、BigQuery や Cloud Storage に対する権限管理は、プロジェクトや BigQuery データセット、Cloud Storage バケット等に直接 IAM ロールを付与して権限管理を行います。大規模なデータ分析基盤（データマネジメント基盤）を設計する際、Dataplex を導入するべきか、またどのタイミングで導入するべきかは、どのように判断するべきでしょうか。

初めから社内（組織内）のステイクホルダや、データの所在・性質を網羅的に把握して、ビジネスの拡大も予測しつつ将来像を練り、データ分析基盤の精緻な設計をウォーターフォール的に行うことができれば理想的です。それができれば、データの規模が小さいうちから Dataplex の導入をすることには、まったく問題がありません。

しかし、実際にはそのようなことは極めて困難です。ビジネスや組織、ステイクホルダの状況は速いスピードで変化します。（Google）Cloud の全社的な利用が、初めから組織の承認やバックアップを得られるとは限りません。データ分析基盤のあるべき姿が常に変化するため、データ分析基盤の利用ユースケースも予想しづらいです。このような状況のほうが、現代の組織では一般的かもしれません。

このような状況においては、若干学習コストが高く、また他の Google Cloud リソースとは管理体系が異なる Dataplex を初めから導入するよりも、シンプルに通常の IAM の権限管理からスタートする、という方法も、十分に選択肢になり得ます。Dataplex による権限管理は、データが多数の Google Cloud プロジェクトに分散しているときに特に力を発揮します。そうではないときは、シンプルな IAM による権限管理のほうが容易であるケースもあります。データ分析基盤の拡大と全社的な利用の目処がついたタイミングで、Dataplex へ移行することも可能です。

ただし、タイミングが遅すぎると、移行には多大な労力がかかりますので、適切な時期に判断することが重要です。

通常の IAM の権限管理からの移行

通常の IAM 権限管理（ここではプロジェクトや BigQuery データセット等への直接の IAM ロール付与を指す）から、Dataplex による権限管理に移行するにあたって、公式のベストプラクティスは発表されていません。当記事の方法は、あくまで一例とお考えください。

まず前提として、通常の IAM 権限と、Dataplex でアセットに付与された権限は、OR の関係です。どちらか一方で権限が付与されていれば、プリンシパルはデータにアクセスできます。両方に権限が付与されていても、アクセスは可能です。しかし、両者の権限管理方式を混在して運用すると、アクセスできないはずのデータにアクセスできてしまうなど、想定外の事故がおきかねません。

このような性質から、以下のような移行方式が考えられます。

1. Dataplex の権限体系と運用を設計する
2. 通常の IAM 権限は残したまま、Dataplex 権限を付与する
3. 一部の利用者から通常の IAM 権限を削除し、問題が出ないことを確認しながら、徐々に Dataplex 権限管理に寄せていく

データ分析基盤が十分に大きくなってしまってから（管理対象のリソース数が多くなってしまってから）の移行は多大な労力を伴いますので、ユースケースの拡大に目処がついた段階で、移行を実施することが推奨されます。

既存の BigQuery データセットへの権限調査

あるプリンシパル（Google アカウントやグループ）がどの BigQuery データセット等のリソースに IAM 権限を持っているか調査するには、Cloud Asset Inventory が利用できます。

• 参考 : Cloud Asset Inventoryを徹底解説！ - G-gen Tech Blog - プリンシパルの検索

例として、以下のようなコマンドラインで、BigQuery 関連のロールを持っている Google アカウントやグループを一覧表示することができます。

gcloud asset search-all-iam-policies \
    --scope=projects/sugimura \
    --query="policy:(roles/bigquery.*) AND memberTypes:(user OR group)" \
    --format=json

Tips : 列レベルのアクセス制御・行レベルのセキュリティとの併用

BigQuery には、列レベルのアクセス制御と行レベルのセキュリティというアクセス制御機能があります。これらの機能で、アクセスできる行や列をプリンシパルごとに制御できます。

blog.g-gen.co.jp

列レベルのアクセス制御と行レベルのセキュリティは、Dataplex の権限管理と併用できます。

プリンシパルに Dataplex 側でデータへの読み取り権限が与えられていても、列レベルのアクセス制御と行レベルのセキュリティの評価は追加で行われます。これらの設定でも行や列へのアクセスが許可されていなければ、プリンシパルは結果を得ることができません。