はじめまして。ANDPADでデータ活用を推進している、データ基盤エンジニアのmikanfactoryです。 2020年5月にジョインしてANDPADのデータ活用の基礎部分を細々と固めています。 今回は弊社の分析環境のアクセスコントロールについて詳しく説明します。
分析環境の現状
データ分析基盤の詳細を書いていたら結構な量になってしまったので、また別の記事で紹介します。
分析環境としてはDWH、データマートにBigQueryを使っていて、BIツールはMetabaseを使っています。また簡単な分析でSpreadSheetを使ったり、一部の集計結果をSalesforceに保存してカスタマーサクセスがダッシュボードでそれを見ていたりします（とはいえ後々廃止する予定です）。
今回は特にBigQueryやMetabaseのアクセスコントロールについて説明します。
満たしたい要件
データの民主化に伴い、弊社でも分析環境にアクセスできる社員の数を増やしています。その際に、人によってアクセスできるテーブルやカラム、ダッシュボードをコントロールできるようにしたいです。例えば以下のようなケースが挙げられます。
- 会計データは正社員以外は見れないようにしたい
- ユーザーのメールアドレスなどの個人情報を、必要な人しか見れないようにしたい
- SaaSメトリクスをまとめたダッシュボードは、正社員以外は見れないようにしたい
BigQueryのアクセスコントロール
基本的には以下の方針でやっています
- Googleグループを用いて、アクセスする主体をグループ単位で管理する
- 共有データセットを用いて、アクセス対象をデータセット単位で管理する
- 列レベルのセキュリティを用いて、個人情報などをカラム単位で管理する
Googleグループ管理
こちら1を参考にGoogleグループを作成して管理しようと思っていましたが、既に開発部や営業部、カスタマーサポートなどの部署ごとに、また業務委託についてもグループが作成、管理されていたので既存のグループを流用することにしました。これらのグループにBigQueryのRoleを付与しています。また事前定義ロールだと帯に短し...的なところがあったので、BigQueryカスタムユーザーも作成しています。その結果、以下のような形になりました。
| Googleグループ | 雇用形態 | Role |
|---|---|---|
| データエンジニア | 正社員 | BigQuery 管理者 |
| エンジニア | 正社員 | BigQueryカスタムユーザー |
| エンジニア（業務委託） | 業務委託 | BigQueryジョブユーザー |
| 営業 | 正社員 | BigQueryカスタムユーザー |
| カスタマーサクセス | 正社員 | BigQueryカスタムユーザー |
| カスタマーサクセス（業務委託） | 業務委託 | BigQueryジョブユーザー |
共有データセット
データセットは下記のようにソースごとに作成しています。上で作成したBigQueryカスタムユーザーではどのデータセットにもアクセスできるのですが、ジョブユーザーは権限が弱く、どんなデータセットやテーブルがあるかを見ることができません。そこで共有データセットを使って業務委託にも閲覧できるようにします。その結果、以下のようにアクセスできるデータセットをコントロールできました。
| データセット | 共有データセット設定 | アクセス可能なユーザー |
|---|---|---|
| アプリケーションAのログ | エンジニア（業務委託）、カスタマーサクセス（業務委託） | 全員 |
| アプリケーションAのDB | エンジニア（業務委託）、カスタマーサクセス（業務委託） | 全員 |
| アプリケーションBのログ | エンジニア（業務委託）、カスタマーサクセス（業務委託） | 全員 |
| SaaS Aのデータ | 割当なし | 正社員 |
| データマートA | 割当なし | 正社員 |
| データマートB | 割当なし | 正社員 |
列レベルのセキュリティ
本来なら個人情報も分析環境に置きたくないのですが、過去の業務プロセス上しかたがなく置かなきゃいけないケースがあります。こういったものをデータ基盤で管理しようとすると、やり方は色々ありますが、大抵テーブルの2重管理になって大変です。しかし列レベルのセキュリティを使うとテーブルは1つで済み、BigQueryのプレビューのときにも隠してくれるなどとても便利です。こちらはGCPのDataCatalogのポリシータグを使って実現できます。作成したポリシータグへのアクセスも、別のGoogleグループを作成して割り当てて管理しています。
Metabaseのアクセスコントロール
OSSのBIツールといえばRedashが有名ですが、Metabaseは見た目が綺麗でダッシュボードを作成していてテンションが上がるのと、Optional Clauses2やField Filters3など痒いところに手が届くのが気に入っています。
BIツールでのアクセスコントロールでは以下を考える必要があります。
- クエリ実行時の実行権限
- ダッシュボードや他の人が書いたクエリの結果へのアクセス権限
クエリ実行時の実行権限
Metabaseでクエリを実行する際には、BigQueryでの実行権限を見に行くので、上で作成したものをそのまま流用できます。そのためRedashのようにBIツール側でDWHの実行権限を考える必要がなくなります。
ダッシュボードや他の人が書いたクエリの結果へのアクセス権限
Metabaseの用語をサクッと説明します。
- Question： 作成したクエリのこと
- Dashboard： よくあるダッシュボード。Questionを1ページにまとめることができる
- Collection：作成したQuestionやDashboardを入れる箱。Collectionも入れられるので、階層構造にすることができる。
Metabaseにもユーザーが属するグループという概念があり、Collectionに対して編集、閲覧をこの単位でコントロールできます。そのため、業務委託グループはSaaSメトリクスのDashboardを入れているCollectionを閲覧禁止にし、月次で集計しているレポートを入れているCollectionを閲覧可能にするとやりたいことを実現できます。
さいごに
ANDPADでは一緒に働く仲間を募集しています。一緒にデータ分析者の気持ちに寄り添ってデータ基盤を作成してくれる方、一緒に理想の基盤を考えながら分析を進めてくれる方がいらっしゃいましたら、ぜひぜひ応募お願いします。
