Cloud Data Fusion のインスタンスとパイプラインへのアクセスを制限する 3 つの方法

※この投稿は米国時間 2024 年 7 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Data Fusion は、安全なデータ パイプラインを視覚的に構築、管理できる、クラウドネイティブなフルマネージド エンタープライズ データ統合サービスです。アクセスを制限することは、セキュリティの目標を達成するために重要となる要素のひとつです。このブログでは、Cloud Data Fusion でアクセス制御を管理するための 3 つの異なる手法について説明します。

1. IAM を使用したインスタンス レベルのアクセス制御

2. ロールベース アクセス制御（RBAC）を使用した名前空間レベルのアクセス制御

3. 名前空間サービス アカウントを使用したアクセスの分離

これらの手法はいずれも、以下の重要なコンセプトに基づいています。

名前空間名前空間とは、Cloud Data Fusion インスタンスのアプリケーション、データ、および関連するメタデータの論理グループのことです。名前空間は、インスタンスの区分けであると考えることができます。

サービス アカウントサービス アカウントはアプリケーションやサーバー用に設計されるもので、実質的には特殊な Google アカウントです。Google Cloud リソース上で実行されるアプリケーションは、サービス アカウントを使用して、Google Cloud API やサービスと通信する際に自身を認証します。

Cloud Data Fusion には 2 つのサービス アカウントがあります。

• 設計サービス アカウント: 通常、Cloud Data Fusion API サービス エージェントと呼ばれます。設計サービス アカウントは、パイプライン設計段階（例: プレビュー、Wrangler、パイプライン検証）でお客様のリソースにアクセスするために使用されます。

• 実行サービス アカウント: Compute Engine サービス アカウントと呼ばれ、パイプラインを実行するために Dataproc により使用されます。

それでは、Cloud Data Fusion でアクセスを制御できる 3 つのレベルについて、詳しく見てみましょう。

シナリオ 1: IAM を使用したインスタンス レベルのアクセス制御

Cloud Data Fusion は、Identity and Access Management（IAM）で Google Cloud サービスと統合されます。これには、管理者と閲覧者という 2 つの事前定義ロールがあります。IAM の最小権限の原則に従い、管理者のロールはインスタンスを管理（作成および削除）するユーザーにのみ割り当てます。閲覧者のロールはインスタンスを管理する必要がなく、インスタンスにアクセスできれば十分なユーザーに割り当てます。

Acme Inc. が Cloud Data Fusion を使用して財務部門用のパイプラインを実行するシナリオを考えます。  Acme Inc. は、簡単なアクセス制御構造から始め、以下のように IAM をアクセス管理に活用したいと考えています。

IAM ロールをユーザーに割り当てる:

• Acme Inc. が財務部門の管理者とデータ エンジニアを特定します。

• 管理者を “role/datafusion.admin” のロールに割り当てて、管理者が Cloud Data Fusion インスタンスの作成、編集、削除を行えるようにします。

• 次に、管理者が “role/datafusion.viewer” のロールをデータ エンジニアに割り当てて、データ エンジニアがインスタンスの表示、パイプラインの設計および実行を行えるようにします。

• データ エンジニアは、Cloud Data Fusion Studio への完全アクセスが可能になりますが、Cloud Data Fusion インスタンスの編集や削除、アップグレードを行うことはできません

IAM ロールをサービス アカウントに割り当てる:

• Acme Inc. のデータ エンジニアは、Cloud Storage からデータを取り込み、そのデータを BigQuery に読み込むパイプラインの設計を行います。

• 管理者が以下のロールを Cloud Data Fusion の実行サービス アカウントに割り当て、Cloud Storage と BigQuery からデータを取り込む権限を付与します。

• roles/storage.legacyBucketReader

• roles/storage.objectViewer

• roles/bigquery.jobUser

• 以上の割り当てを行うと、データ エンジニアはこれらのサービスから制限なくデータの取り込みを行えるようになります。

シナリオ 2: ロールベース アクセス制御を使用した名前空間レベルのアクセス制御

Cloud Data Fusion でロールベース アクセス制御を使用することで、データ パイプライン内のユーザー権限をきめ細かく管理できるようになり、誰がリソースにアクセスできるか、そのリソースで何を行えるか、インスタンス内のどの領域にアクセスできるかを管理できます。ロールベース アクセス制御では、名前空間レベルでユーザーに割り当てられる以下のロールを利用できます。

• datafusion.viewer: パイプラインの表示

• datafusion.operator: デプロイされたパイプラインの実行

• datafusion.developer: パイプラインの設計、プレビュー、デプロイ

• datafusion.editor: すべてのリソースに対する完全アクセス

カスタムロールの作成も可能になります。

次に Acme Inc. は、Cloud Data Fusion の使用を財務部門の経理チームと支払チームで分けようとします。  Acme Inc. は経理チーム用、支払チーム用 2 つの名前空間を作成して、経理チームのデータ エンジニアのみが、その名前空間のパイプラインを実行できるようにします。Acme Inc. は次のようにロールベース アクセス制御を活用します。

名前空間レベルでロールをユーザー（またはプリンシパル）に割り当てる:

• Acme Inc. の Cloud Data Fusion 管理者が、経理チームのデータ エンジニア（DE1）を特定します。

• Cloud Data Fusion コンソールの権限セクションで、管理者が“Accounting” 名前空間を DE1 に割り当てます。

• 管理者が、datafusion.developer のロールを DE1 に割り当て、DE1 が “Accounting” 名前空間でパイプラインの設計、プレビュー、デプロイを行えるようにします。

• 同様に、管理者が “Payment” 名前空間を支払チームのデータ エンジニア（DE2）に割り当て、datafusion.developer ロールを DE2 に割り当てます。

シナリオ 3: 名前空間サービス アカウントを使用したアクセスの分離

名前空間レベルのサービス アカウントを使用して、各名前空間内での Google Cloud リソースへのアクセスをさらに分離できます。名前空間サービス アカウントは、Wrangler、パイプライン プレビュー、接続などのパイプライン設計時の操作のみを分離します。

Acme Inc. の例を考えます。Acme Inc. は、Cloud Data Fusion の使用をマーケティング部門に拡張しようとしています。Acme Inc. は “Marketing” の名前空間を作成して、“Marketing” 部門のデータ エンジニアはその名前空間のパイプラインを実行できるが、他の部門のデータをパイプラインの設計時に確認できないようにします。Acme Inc は以下のように名前空間サービス アカウントを活用します。

名前空間レベルでロールをユーザー（またはプリンシパル）に割り当てる:

• Acme Inc. の Cloud Data Fusion 管理者が、“Marketing” 部門のデータ エンジニア（DE3）を特定します。

• Cloud Data Fusion コンソールの権限セクションで、管理者が “Marketing” 名前空間を DE3 に割り当てます。

• 管理者が、datafusion.developer のロールを DE3 に割り当て、DE3 が “Marketing” 名前空間でパイプラインの設計、プレビュー、デプロイを行えるようにします。

• DE3 のユースケースは他の部門と同じで、Cloud Storage からデータを取り込み、そのデータを BigQuery に読み込むパイプラインを設計します。

• DE3 は、名前空間で新しい接続を作成する際に、他の部門のストレージ バケットを表示できます。

名前空間レベルでサービス アカウントを割り当てる:

• 管理者がサービス アカウントを構成して、これを “Accounting”、“Payments”、“Marketing” の名前空間のそれぞれに割り当てます。

• 管理者が Cloud Storage に移動し、“roles/storage.objectUser” ロールを “Accounting”、“Payments”、“Marketing” サービス アカウント プリンシパルに割り当てます。

• データ エンジニア（DE3）が Cloud Data Fusion で Cloud Storage 接続の作成に移動し、ストレージ バケット リストを開きます。データ エンジニアはバケットの一覧を確認できますが、彼らがアクセスできるのは “Marketing” 部門のストレージ バケットのみです。

不正アクセスとデータの変更の防止

ETL ワークロードに関して、Cloud Data Fusion には、不正アクセスや意図しないデータの変更に関連するリスクを最低限に抑える堅牢な機能が備わっています。ロールを丁寧に設計し、名前空間を戦略的に活用することで、組織の要件に合致する、独自にカスタマイズされた安全なデータ環境を構築できます。詳しくは、こちらから詳細をご覧ください。

-プロダクト マネージャー Deepinder Dhuria

-ソフトウェア エンジニア Ankit Jain