トップ > BigQuery > Google Groupsを用いたBigQueryの権限管理運用

Google Groupsを用いたBigQueryの権限管理運用

BigQuery Data Security Data Governance

ogp

はじめに

enechainのデータプラットフォームデスクでエンジニアをしている菱沼です。

本記事では、Google Groupsを用いて、BigQueryの権限管理を設計した例をご紹介します。

事業の多角化に伴い様々なデータが新しく生まれてきた中で、BigQueryに集約されたデータを適切に権限管理しつつもよりスムーズに権限を付与できる仕組みが求められるようになってきました。 今回は、私たちが直面していたBigQueryの権限管理の課題と、その解決に向けた取り組みをご紹介します。ぜひ最後までご覧ください！

背景

enechainの事業の性質上、機密性の高いデータを扱う機会が多くあります。 そのため、部門をまたがるデータの不用意な共有やアクセスの適切な制御が求められます。

同様に、BigQueryに蓄積されたデータについても、適切な情報管理体制を構築した上で、閲覧権限の申請からデータ利用に至るまでのプロセスを可能な限り円滑にすることが求められていました。

今までの権限付与運用の課題点

従来のBigQueryへの権限付与のフローは以下のようになっていました。

  1. BigQueryのデータ閲覧申請者が、閲覧権限の申請を承認者 (Engineering Manager, EM) に対して行う。
  2. 承認者 (EM) は、利用者や利用用途などを確認後、権限の承認をする。
  3. 承認者 (EM) は、権限の付与作業をチームのエンジニアに依頼
  4. 権限の承認後は、データを保有しているチームがTerraform経由で権限を付与する。

operation_before

一方で、従来の権限付与フローには以下のような課題点がありました。

  • 権限の付与コストが高い
    • 承認者がエンジニアに権限付与依頼 → エンジニアがTerraformのresource編集 → PR作成 & 承認 → Terraform Applyの手順を踏む必要があります。特に業務が立て込んでいるタイミングでは、Terraformで個別に権限設定する作業が負担となることも少なくありません。
  • データ利用者がデータ活用できるまでのリードタイムが長い
    • 権限付与にかかるコストの高さから、閲覧権限の申請後から実際にデータへアクセスできるようになるまでに長い時では数日かかるなど時間を要することが多くありました。そのため、データ利用者が必要なタイミングでデータを活用できず、業務のスピード感を損なってしまう場面がありました。

これらの課題は、権限申請の件数が少なく、データ活用の頻度も限られていた段階では大きな問題にはなっていませんでした。しかし、データ基盤の整備とともに活用のニーズが高まる中で申請数も増加し、従来の運用フローでは対応コストの大きさが徐々に顕在化してきました。

新運用の概要

そこで、上記課題点を解決すべく、以下のような新運用に変更しました。 リソースと組織レベルの権限設計はIaCで事前に管理しつつ、組織とユーザーの紐付けは承認プロセスを通じて最小限の手動オペレーションで対応することで、運用コストの低減を図っています。

事前準備

  1. (変更あり) BigQueryリソースに紐づくGoogle Groupsを作成し、Viewer権限を付与する

権限付与申請時

  1. (変更なし)BigQueryのデータ閲覧申請者が、閲覧権限の申請を承認者 (Engineering Manager, EM)に対して行う。
  2. (変更なし)承認者 (EM)は、利用者や利用用途などを確認後、権限の承認する。
  3. (変更あり) 手作業でRole GroupにUser / User Groupを加入させることにより、閲覧権限の付与を完了させる

変更点を以下で詳しく説明します。

operation_after

変更点1: BigQueryリソースに紐づくGoogle Groupsの作成・Viewer権限の付与

BigQueryリソースへのアクセス管理を効率化・標準化するために、プロジェクトとデータセットそれぞれに1対1で対応するGoogle Groupsを事前に作成することとしました。

これらのGroupは、該当するBigQueryリソース（projectやdataset）に対してViewer権限を持つようにTerraformで定義されています。 これにより、権限の粒度を細かく保ちつつ、柔軟なアクセスコントロールを可能としています。

これらの役割ベースでアクセス権限を管理するGoogle Groupsは、社内で「Role Groups」と呼ばれています。 一方、ユーザーをデスクやチームごとにまとめたGoogle Groupsは「User Groups」と呼ばれています（上記図参照）。

例えば、example_project 内の sales_dataset に対する閲覧用のRole Groupを定義する場合、以下のようなTerraformコードで管理しています。

locals {
  project_id = "example_project"
  dataset_id = "sales_dataset"
  owner      = "hoge@enechain.co.jp"
}

# Role Groupを定義
resource "googleworkspace_group" "bq_r_sales_dataset" {
  email       = "bq-r-${local.project_id}.${local.dataset_id}@enechain.co.jp"
  name        = "bq-r-${local.project_id}.${local.dataset_id}"
  description = "データセット${local.project_id}.${local.dataset_id}に対するBigQuery閲覧権限を持つメンバー"
}

# Role GroupのOWNERを定義
resource "googleworkspace_group_member" "bq_r_sales_dataset_owner" {
  group_id          = googleworkspace_group.bq_r_sales_dataset.id
  email             = local.owner
  role              = "OWNER"
  type              = "USER"
  delivery_settings = "NONE"
}

# Role Groupに対して、対応するdatasetに対する閲覧権限を付与
resource "google_bigquery_dataset_iam_member" "dataset_viewer" {
  dataset_id = local.dataset_id
  project    = local.project_id
  role       = "roles/bigquery.dataViewer"
  member     = "group:${googleworkspace_group.bq_r_sales_dataset.email}"
}

Role Groupsの作成はデータプラットフォームデスクが事前に準備しておく、かつ作成は1度だけで済むため、以前のように権限編集のたびにTerraformの変更が必要なくなりました。

変更点2: 手動でのRole Groupメンバー加入による権限付与

このように、Groupごとに対応するリソースへの閲覧権限を事前に設定しておくことで、ユーザーへのアクセス付与は 「Google Groupsのコンソール上で、該当のGroupに手作業で追加するだけ」 で済むようになります。 これにより、以下の理由から、運用コストと権限付与までのリードタイムを大幅に削減できました。

  • 承認者 (EM) が直接対応することで、エンジニアへの依頼が不要
  • データを所有するチームのTerraform blockの変更やレビュー、反映が不要

この変更による運用コスト削減の効果は現場でも実感されており、弊社のCTOからも次のような声が届いています。

slack_message

今後の展望

承認後の権限付与自動化

今後は、さらなる効率化のため、メンバー管理を手作業からTerraformに移行する予定です。 その上で、Slackでの承認ボタンを押すと自動的に申請内容に基づいてメンバーを追加するためのTerraform resource blockが生成され、その後自動でapplyされる仕組みの実装も進めます。 この仕組みによって、従来の手動操作を大幅に削減し、承認後すぐに権限が付与される環境を提供するとともに、権限付与エラーのリスクも減少させることができます。

Role Groupsの事前作成

現在、データプラットフォームデスクがRole Groupsを自前でTerraformを用いて定義し作成しています。 一方で、このRole Groupsを事前に用意できていない場合、権限付与までにリードタイムが発生してしまいます。

  • 直近では、Information Schemaを定期的に監視する運用体制を構築し、Project / Datasetの増加を検知する仕組みを導入することで、Role Groupsの構築漏れを防ぐ予定です。
  • 最終的には、Information Schemaの監視を毎日実施し、Google Groupsの作成までを自動化するバッチ処理を開発することを目指しています。

権限変更のモニタリング

今後は、権限付与の透明性と正確性をさらに向上させるため、Google Workspace Audit Logによる監視体制を整える予定です。 これにより、権限変更の追跡を通じて権限付与の適切性を確認できるようになり、手作業に伴うリスクが低減されるため、セキュリティ面での信頼性を向上させることができます。

おわりに

今回は、Google Groupsを用いて、BigQueryの権限管理を改善した例について紹介しました。

以前にデータプラットフォームデスクで実施したデータ利用者向けアンケートでは、BigQueryの権限管理の改善を求める声が多く寄せられており、今回の取り組みはそのような現場のニーズに応える形で進めてきました。 データをより使いやすくすることで活用を促進し、意思決定のスピードや質の向上にもつながることを期待しています。 今後も、現場の声にしっかりと向き合いながら、誰もがスムーズにデータを扱える環境を目指して取り組んでいきます。

データプラットフォームデスクでは、巨大なマーケットを支えるデータ基盤を一緒に構築する仲間を募集しています。 興味のある方は、ぜひ以下のリンクからご応募ください！

tech.enechain.com

herp.careers