🐙
BigQueryの行列レベルのアクセス制御について
what
- BigQueryにおける「行列レベル」のアクセス制御について調べたことをまとめる
そもそも: 行・列単位に対してのアクセス制御は可能なのか?
A. できる
それぞれ記載していく
列単位
列に対して事前定義したポリシータグと呼ばれるものを付与することで、特定のアカウントやグループだけが列にアクセスできる。
アクセスポリシーはSQLを実行する際に確認され、許可されていないメンバーからのクエリはAccess Denitedとして拒否される。
分類とポリシータグ
列レベルでのアクセス制御には、事前にData Catalogで分類と呼ばれるものを作成する必要がある。
分類の中には複数のポリシータグを収容することができる。
作成したポリシータグにはアカウントやグループ、きめ細かい読み取りロール等を紐付けることで、そのポリシータグがアタッチされた列へのアクセスを許可することが可能になる。
このポリシータグをテーブルの列へアタッチすることで、適切なIAMロールと紐付けられたアカウントやグループのみが列へアクセスできるようになる。
制限
列レベルのアクセス制御には以下の制限がある
- 列にはポリシータグを1つしかアタッチできない
- 1テーブルにアタッチ可能なポリシータグの種類は最大1000まで
- ポリシータグが1つでもついていると、そのテーブルに対してレガシーSQLが利用できなくなる
データの書き込みについて
該当のテーブルに書き込みを行う際は、書き込みをするユーザーへポリシータグで保護されている列に対して読み取り権限を追加する必要がある。
行単位
テーブルに行レベルのアクセスポリシーと呼ばれるもの作成することによって、アカウントやグループに対して、特定の値を持った列にだけアクセスできるように制限する事ができる。
行レベルのアクセスポリシー
行レベルのアクセスポリシーはDDLで作成する。
例としては以下のような形式
CREATE ROW ACCESS POLICY region
ON `myproject.mydataset.user_table`
GRANT TO ("group:team-hokkaido@example.com")
FILTER USING (region = "Hokkaido");
FILTER 句の部分に WHERE 句に相当する文を入れることで、許可対象の行が持つ値を指定できる。
制限
行レベルのアクセス制御を使用すると、クエリの際に特定の行しか見えなくなる。
このため、パフォーマンス面で影響が出る点に注意が必要になる。
- パーティショニングやクラスタリングによる高速化ができなくなり、フルスキャンになってしまう
- マテリアライズド・ビューへのクエリでも、ソーステーブルに行レベルアクセス制御が使われていると、ソーステーブルへのクエリになる
- BigQuery BI Engine のキャッシュが効かなくなる
- クエリパフォーマンスが若干低下する
Discussion