【GCP】BigQuery のアクセス制御まとめ その②

こんにちは。SCSKの山口です。

本ブログはBigQuery のアクセス制御まとめ その①の続編です。

今回は、BigQueryの「列と行のアクセス制御」について書きます。

BigQuery のアクセス制御

概要については下記ブログをご参照ください。

データレベルのアクセス制御

本ブログでは、列と行のアクセス制御を「データレベル」のアクセス制御と位置付けます。

列レベルのアクセス制御

列レベルのアクセス制御では、文字通り列に対するアクセスを制御することができます。

列レベルのアクセス制御を実現するには、以下の手順を踏む必要があります。

  1. 分類階層とポリシータグを定義する
  2. BigQuery 列にポリシータグを割り当てる
  3. 分類階層にアクセス制御を適用する
  4. ポリシータグへのアクセス権を管理する

聞きなれない「ポリシータグ」という単語が出てきました。ポリシータグについて説明します。

ポリシータグ

ポリシータグとは、カラム単位のアクセス制限や、動的データマスキングを行うために、BigQuery の列にタグを付与する機能です。

※動的データマスキングについてはまた別のブログで触れようと思います。

ポリシータグを使用する際に重要になるのが、「データクラス階層の構築」です。

取り扱うデータの種類を検討し、データ特性や重要度、機密性等を加味してデータクラスを決定します。

上記、公式ドキュメント内の図で説明します。

最上段の黄色四角形が最上位ポリシータグです。すべてのデータタイプが高、中、低で分類されています。

最上位ポリシータグにぶら下がっている青色四角形がリーフポリシータグです。

このように、ポリシータグはツリー状にまとめることが可能です。

これらのポリシータグをBigQuery の列に付与し、アクセス制御や動的データマスキングを実現します。

 

行レベルのアクセス制御

こちらも文字通り、行に対するアクセスを制御できます。

行レベルのアクセス制御は、「アクセスポリシー」を使用して実現します。データに対するアクションがされた際に、ユーザまたはグループが許可リストに含まれているかどうかに応じて特定のデータ行を表示または非表示します。

1つのテーブルに対して、複数の行レベルアクセスポリシーを設定することも可能です。

 

実践1:列レベルのアクセス制御

実際に列レベルのアクセス制御をやってみます。

今回も前ブログ(その①)同様、AdminとMemberに分けて実装していきます。

まずは「分類階層の定義」と「ポリシータグの定義」でしたね。

Admin:分類階層の定義

今回は公式ドキュメントに記載のある分類階層のテーブルをそのまま使用します。

テスト用に、最上位ポリシータグの高、中、低のカラム含むテーブルを用意します。

Admin:ポリシータグの定義

次にポリシータグを定義します。

  • BigQuery 画面の左ペインから「管理」-「ポリシータグ」を選択

  • 「分類を作成」をクリック

  • ポリシータグの分類を作成

Admin:BigQuery 列にポリシータグを割り当てる

作成したポリシータグを割り当てます。

今回のテーブルのカラムとポリシータグの対応は以下の通りです。

カラム名 最上位ポリシータグ リーフポリシータグ
ユーザID
クレジットカード番号 High Credit card
住所_都道府県 Medium Location
氏名 Low Name
メールアドレス Low Email

上記の対応に基づいてポリシータグを割り当てます。

  • 対象テーブルの「スキーマ」タブの「スキーマの編集」をクリック

  • 割り当て対象のスキーマを選択した状態で「ADD POLICY TAG」をクリック

  • 対応付けたいポリシータグを選択

  • 該当するすべてのスキーマにタグを割り当てる

→「氏名」スキーマを見てわかる通り、あえて上位ポリシータグの「Low」を割り当てることも可能です。

Admin:分類階層にアクセス制御を適用する

次にアクセス制御を適用します。

今回はMemberユーザに対して、MediumとLowのデータのみアクセスを許可(Highのデータはアクセス禁止)する制御とします。

  • BigQuery の「ポリシータグの分類」画面から、「Medium」「Low」配下のすべてのポリシータグを選択した状態で、「プリンシパルを追加」をクリック

※最上位のポリシータグを選択しても、リーフポリシータグは選択されていない状態になるので注意が必要です。

  • 「新しいプリンシパル」にMemberユーザのアカウントを入力し、「ロール」で「プロダクトまたはサービス」-「データカタログ」-「きめ細かい読み取り」を選択

ここまででAdmin側の作業は完了です。

Member:テーブル確認

Admin側で、アクセス制御の適用を行っていない状態でMemberのアカウントからテーブルを見てみます。

ポリシータグを付与していないスキーマはデータがみれていますが、ポリシータグを付与したスキーマ関してはデータが閲覧不可になっています。

Admin側でのアクセス制御の適用が完了した後に再度確認すると。

Admin側でアクセスを許可したMedium,Lowのスキーマがアクセス可能になりました。

 

実践2:行レベルのアクセス制御

次に行レベルのアクセス制御をやってみます。

あらかじめ、Memberユーザからテーブル内のすべてのデータがみれるようにしておきます。

Admin:行データのフィルタリングをクエリ

Admin側から下記クエリを発行します。

CREATE ROW ACCESS POLICY
  location_filter
ON
  `evocative-entry-277709.yamaguchi_test_acctrl.user`
GRANTTO
  ("user:shXXXX@XXXX.com")
FILTER USING
  (`住所_都道府県`="Tokyo")

これで、Memberユーザに対して`住所_都道府県`=”Tokyo”のデータのみにしかアクセスできない制限がかかりました。

Member:クエリ結果確認

Memberユーザ側でデータを全件SELECTしてみます。

`住所_都道府県`=”Tokyo”のデータのみが表示されました。

Memberユーザがアクセスできる行を絞り込むことができました。

 

まとめ

BigQuery の様々なレベルのアクセス制御について、二本にわたって書きました。

今回紹介した各レベルの制御方法は組み合わせることができます。各方法のベストプラクティスを確認し、要件に適した組み合わせ、実装方法を検討することが重要だと思います。

どんなデータがあって、だれに見せたくないのか(見せたいのか)を確認すること最初のステップが重要です。

その次の実装のステップでこのブログが皆さんのお役に立てると幸いです。

 

著者について

Google Cloud歴2年目です。
日々捌ききれないほどのインプットを浴びているので、本ブログをアウトプットの場として活用しています。
-----
好きな(よく触っている)サービス:BigQuery、Cloud Functions、Data Fusion
保有資格:応用情報技術者、Google Cloud 認定資格全冠(11冠)
受賞歴:Google Cloud Partner Top Engineer 2025(カテゴリ:General)受賞

山口翔平をフォローする

クラウドに強いによるエンジニアブログです。

SCSKクラウドサービス(Google Cloud)は、Google Cloudの多彩なAIや各種サービスを活用したワンストップソリューションを提供します。SCSKのノウハウや体制を有効活用し、業務課題の解決に必要な全体検討と組み合わせで、最適な業務実装まで支援します。

Google Cloudクラウドソリューションデータ分析・活用基盤
シェアする
タイトルとURLをコピーしました