はじめに
enechainのデータプラットフォームデスクで2年目エンジニアをしている菱沼です。
本記事では、社内ユーザに対する閲覧権限をBigQueryの承認済みビューを用いて改善した例をご紹介します。
事業規模の拡大に伴い、各種データへのアクセス権限整備の重要性が増し、BigQuery上のデータも厳密な権限管理が求められるようになりました。 今回は、我々が抱えていたBigQueryアーキテクチャの権限管理上の課題と、その課題に対する取り組みについて具体的にご紹介します。 ぜひ最後までお付き合いください！
旧BigQuery構成と課題点
データプラットフォームデスクで構築しているデータ基盤の1つに、 外部データソースから取得したデータを収集・蓄積するためのETLパイプラインが存在します。 パイプラインで取得・加工したデータは全てBigQuery (以下「BQ」) へ連携しています。 Google Cloud (以下「GCP」) のBQのデータセットの旧構成は以下の図のようになっていました。
データ種別ごとにデータセットを構築して管理するシンプルな構成にしていました。 一方で、テーブルの閲覧権限はデータセット単位で細かく管理されておらず、 プロジェクト単位のBigQuery Data Viewer権限が付与されたユーザは同一プロジェクトの全BQテーブルのデータにアクセス可能な状態となっていました。 あらゆるユーザやサービスアカウントに権限を付与し続けた結果以下の課題点が発生しました。
- 誰がどのデータを参照しているのか把握しづらい
- データの参照履歴自体はAudit LogやINFORMATION_SCHEMAから確認できますが、ユースケースや参照ジョブの重要度までは把握できません。重要なジョブに利用するデータとして知らずのうちに利用されていた場合でも、データ作成時のトラブルの影響度合いを運用者が特定できない可能性があります。
- 集計前後のデータ両方にアクセス可能である
- データの利用者が内部用の中間テーブルにアクセス可能なため、もし参照されていた場合、データ作成者は内部での仕様変更がしづらくなります。
- 利用用途が制限されているデータに自由にアクセス可能になっている
- 仮にデータの利用規約が厳しいデータに対して誰でもアクセス可能であると、誤利用のリスクが高まります。
データプラットフォームデスクとしては、上記課題に対処するため、各データの利用用途を手動で作成したデータフロー図に記載したり、 権限を付与する代わりにデータ抽出依頼フローを用意して利用用途を確認したうえで提供するなど、その場しのぎの対応をしていました。 一方で、データの利用者が増加し、上記運用ではスケールしなくなってきました。 また、今後さらにデータ利用者の増加が予想される中で、データガバナンスの改善が必要になりました。
新GCP Project/BigQuery構成
上記課題を解決するため、新GCP ProjectとBQの構成を検討しました。具体的には、以下の図のような構成としました。
- Internal Projectには、外部から取得した生データや、それを集計したデータを配置します。 このプロジェクトはチーム内のメンバのみがアクセスできるようにすることで、意図しないデータアクセスを防止します。
- External Projectには、公開用データセットを配置します。このプロジェクトには実テーブルは作成せずViewのみ構築することで、Single Source of Truthを実現します。適切なデータセット設計と権限設定をすることで、各ユーザ・サービスアカウントが必要なデータのみにアクセス可能にします。
External Projectのプロジェクト・データセット構成は、以下のオプションを検討しました。
検討の結果、チームとしてはOption1を採用しました。判断基準は以下となりました。
- データの利用状況のわかりやすさより管理プロジェクトを少なくすることのメリットの方が大きいと考え、プロジェクト構成は単一としました。
- 前の構成の課題点である、誰がどのデータを利用しているのかの把握が難しいという問題を解決することが優先と考え、データセット構成は提供先ごととしました。
承認済みビューの設定
BigQueryでは、特別な設定をしない限り、ビューへアクセスするためには以下の2点が必要となります
- ビュー自体へのアクセス権限
- ビューのソースとなるテーブルへのアクセス権限
一方で、後者の権限を与えてしまうと、前章でいうInternal projectへのアクセス権限を与えてしまうことになり、 意図しないデータアクセスを許可してしまうことになります。
そこで、BigQueryの承認済みビュー (Authorized View)を利用しました。 承認済みビューの設定をすることで、ビューのソースとなるテーブルへのアクセス権限がないユーザでも、ビュー自体へのアクセス権限さえあればクエリが実行できるようになります。
IaCで管理する場合、Terraformではgoogle_bigquery_dataset_access resourceを用いることでビューの承認の設定ができます。
/****************************************** Bigquery view authorization *****************************************/ resource "google_bigquery_dataset_access" "authorized_view" { dataset_id = google_bigquery_dataset.internal.dataset_id view { project_id = google_bigquery_table.external.project dataset_id = google_bigquery_dataset.external.dataset_id table_id = google_bigquery_table.external.table_id } }
注意点としては、Internal Projectに用意するソーステーブルと、External Projectに用意するビューが両方存在しないと、Terraformのapplyが失敗するので気をつける必要があります。
PRのマージとともにterraform applyのCDが走る設定になっているため、チームではテーブル作成用のPRと承認用のPRを分けて作成するルールでカバーしています。
結果として、承認済みビューの設定が確認できました。
結果
左の画像がデータプラットフォームデスクのメンバーから見えるデータセット構成、右の画像がデータ利用者から見えるデータセット構成です。 画像からわかる通り、データ利用者の利用できるデータセットが制限されているのが確認できます。
また、データ利用者がExternal Projectの閲覧権限のあるテーブルに対してクエリを実行できることが確認できました。
さらに、データ利用者がInternal Projectのテーブルに対してクエリ実行ができないことも確認できました。
終わりに
今回はデータガバナンスを意識したGCP Project/BQ構成、及び承認済みビューの設定について紹介しました。 データの管理に関する課題が積もる中、創業から5年が経過したこのタイミングでガバナンスを意識したテーブル構造を再設計できたのは、 今後のデータ活用促進という意味でも大きな意味を持つと思います。 今回は中央集権的なデータ管理手法について紹介した一方で、今後は企業の規模拡大に合わせてよりデータファブリックを意識したデータ管理手法についても検討していきたいと考えています。
データプラットフォームデスクでは、巨大なマーケットを支えるデータ基盤を一緒に構築する仲間を募集しています。 興味のある方は、ぜひ以下のリンクからご応募ください！
