データ基盤の運用において必須のIAM設定、基礎を正しく理解しよう！

BigQueryのリソース管理、できてますか？

主にデータ分析基盤のDWHとして利用されるBigQueryですが、組織として扱うデータの規模が拡大していくと、様々なデータセットやテーブルが作成されることになるかと思います。これらのリソースについては適切な権限管理が必要となるため、

• データセットA ⇒ 経営戦略部のメンバーのみがアクセス可能
• データセットB ⇒ 経理部のメンバーのみがアクセス可能
• データセットC ⇒ マーケティング部のメンバーのみがアクセス可能

上記のような権限管理が必要となるケースが多いかと思います。

このような権限管理を行う際にはIAMの機能を利用して、アクセス権限などの権限管理を行うことになります。

リソースに対してのアクセス権限管理についてはとても地味な仕事ではありますが、本来見られてはいけないデータが閲覧可能になっているようなことが起きると、組織的に大きな問題に発展してしまうこともあります。

本記事ではGoogle Cloud(特にBigQuery)におけるIAMの考えを整理しました。しっかり理解した上で、適切なリソース管理を行いましょう。

BigQueryを利用する上で必要なIAM設定を見直してみよう

データ分析基盤としてBigQueryを利用する場合、一般的には以下のリソースを管理する必要があります。

• プロジェクト
• データセット
• テーブル
• カラム
• 承認済みビュー

Google CloudやAWSなどのクラウドサービスの運用に慣れている方はともかく、まだクラウドサービスの運用に慣れていない方からすると、各リソースに対するアクセス制御が煩雑に感じるかもしれません。

本記事では主にBigQueryのリソース管理について、IAMの基本から整理したいと思います。

IAMとはそもそも何か

AWSやGCPなどのクラウドサービスを利用したことがある人は一度は「IAM」というワードを聞いたことがあるかと思います。

IAMとはIdentity and Access Managementの略で、クラウドサービス上のリソースに対してのアクセス制御等を行う仕組みで、GCP上では「Cloud IAM」というサービスとして、GCP上の各種リソースに関するアクセス制御を一元管理する機能があります。

もっとシンプルに表現すると、

• 「誰が」
• 「どのリソース対して」
• 「どんなアクションができるか」

を設定する仕組みとなります。

ちなみに、ここで言う「誰が」はGoogleアカウント、Googleグループ、サービスアカウントのいずれかを指し、「どのリソース対して」はCompute EngineやCloud Storageといった対象のサービスを示し、「どんなアクションができるか」はリソースの作成や更新といった権限をロールとして定義して操作対象者に付与することを示しています。

BigQueryにおけるIAMロールについて

話を戻しますが、BigQuery上でのIAM設定については、特定のユーザー(Googleアカウント、Googleグループなど)に対してIAMロール(権限等を役割としてまとめたもの)を付与してアクセス権限などを管理することになります。

IAMロールについては3種類のロールが存在し、Google Cloudの公式ドキュメントでは以下のように説明されています。

これだけだと、どのような権限が割り当てられるのかがわかりずらいので、具体的な権限内容について整理してみましょう。

BigQueryのIAM事前定義ロール

事前定義ロールについては、ロールに対して権限が割り当てられている形となり、例えばBigQueryデータ閲覧者に対しては、テーブルまたはビューからデータとメタデータを読み取るための権限が割り当てられている形となります。

その他、BigQueryとして用意されている事前定義ロールとしては以下の通りとなります。

• BigQuery管理者（roles/bigquery.admin）
• BigQuery Connection管理者（roles/bigquery.connectionAdmin）
• BigQuery Connectionユーザー（roles/bigquery.connectionUser）
• BigQueryデータ編集者（roles/bigquery.dataEditor）
• BigQueryデータオーナー（roles/bigquery.dataOwner）
• BigQueryデータ閲覧者（roles/bigquery.dataViewer）
• BigQueryフィルタ済みデータ閲覧者（roles/bigquery.filteredDataViewer）
• BigQueryジョブユーザー（roles/bigquery.jobUser）
• BigQueryメタデータ閲覧者（roles/bigquery.metadataViewer）
• BigQuery読み取りセッション ユーザー（roles/bigquery.readSessionUser）
• BigQueryリソース管理者（roles/bigquery.resourceAdmin）
• BigQueryリソース編集者（roles/bigquery.resourceEditor）
• BigQueryリソース閲覧者（roles/bigquery.resourceViewer）
• BigQueryユーザー（roles/bigquery.user）

各ロールに割り当てられている権限の詳細については公式ドキュメントを参照いただければと思います。

https://cloud.google.com/bigquery/docs/access-control?hl=ja#bigquery

BigQueryのカスタムロール

カスタムのIAMロールを作成する場合については、以下の公式ドキュメント(カスタムロールの作成と管理)を参照ください。

https://cloud.google.com/iam/docs/creating-custom-roles?hl=ja

BigQueryの基本ロール

プロジェクトの基本ロールについては、以下の公式ドキュメント(基本ロールと権限)を参照ください。

https://cloud.google.com/bigquery/docs/access-control-basic-roles

IAMロールについては一旦、必要となるリソース管理のためのロールがあるかを確認し、適したものがなければカスタムロールを作成する、という形がよいかもしれません。

リソースレベルでのアクセス制御について

BigQueryでリソースに対してのアクセス制御を行う上では、以下のリソース単位で設定を行うことが可能となっています。

• プロジェクト
• データセット
• テーブル

例えばあるユーザーに対して、プロジェクトに対する「BigQueryデータ閲覧者」のIAMロールを付与すると、プロジェクト内全てのデータセット、テーブルのデータ閲覧が可能になります。(上位の設定は下位に継承されます)

そのため、更に詳細な権限管理(特定のデータセットもしくはテーブルのみに対してのアクセス権限を付与する場合)については、データセット単位もしくはテーブル単位に設定を行う必要があります。

BigQuery上のリソース管理はTerraformを使うのが一般的？

BigQueryはデータ基盤としての用途で使うのが一般的なため、データマートの作成や更新は頻繁に発生すると思われます。そのため、テーブルを作成するたびにIAMの設定を行うのは現実的ではないかと思われます。

最近ではIaC(Infrastructure as Code)も一般化しており、Terraformなどのツールを利用して「コードでリソースを管理する」という運用をするケースが増えています。BigQueryのリソース管理への工数を減らすためにも、Terraform等のツールの導入を進めてみるのも良いかもしれません。

 

なお、本記事については以下の書籍を参考にさせていただきました。

https://amzn.to/3OSX2LA

BigQuery上のIAM設定に関する説明だけでなく、BigQueryを中心としたデータエンジニアリング全般について、Google Cloudのサービスを中心とした丁寧な説明がされているので、BigQueryを利用しているデータエンジニアはぜひ一読してみることをおススメします。