BigQuery の列レベルのセキュリティの概要

BigQuery では、データのポリシータグ(型ベースの分類)を使用し、機密性の高い列に対してきめ細かいアクセスを行うことができます。BigQuery の列レベルのセキュリティを使用すると、ユーザーが適切なアクセス権を持っているかどうかをクエリの実行時に確認するポリシーを作成できます。たとえば、あるポリシーでは次のようなアクセスのチェックを実施できます。

  • TYPE_SSN が含まれる列の表示には group:high-access に属している必要がある。

列レベルのセキュリティ ワークフロー

ワークフロー

列レベルでデータアクセスを制限するには:

  1. 分類とデータポリシー タグを定義しますData Catalog を使用して、データの分類とポリシータグを作成、管理します。ガイドラインについては、ポリシータグのベスト プラクティスをご覧ください。

  2. BigQuery 列にポリシータグを割り当てます。BigQuery ではスキーマ アノテーションを使用して、アクセスを制限する列ごとにポリシータグを割り当てます。

  3. ポリシータグへのアクセス権を管理しますIdentity and Access Management(IAM)ポリシーを使用して、各ポリシータグへのアクセスを制限します。ポリシーは、ポリシータグに属する列ごとに有効です。

ユーザーがクエリの実行時に列データにアクセスしようとすると、BigQuery は列ポリシータグとそのポリシーをチェックして、ユーザーがデータにアクセスできる権限を持っているかどうかを確認します。

使用例

たとえば、機密性の高いデータをの 3 つのカテゴリに分類する必要がある組織について考えてみましょう。

ポリシータグ

列レベルのセキュリティを設定するには:

  1. データ ガバナンス管理者が、Data Catalog にのポリシータグを定義します。

  2. のアクセス ポリシータグに対して、管理者が高階層アクセスグループへのアクセス権を付与します。

  3. 管理者がのポリシータグに列を割り当てます。たとえば、ssn 列がのポリシータグに含まれている場合、ssn のスキーマには policyTags フィールドが含まれます。以下は、ポリシータグが [現在のスキーマ] ページにどのように表示されるかを示しています。

    ポリシータグの UI

    コンソールを使用してポリシータグを設定する方法については、列にポリシータグを設定するをご覧ください。

    あるいは、bq update コマンドを使用してポリシータグを設定することもできます。以下の例では、policyTagsnames フィールドに、のポリシータグの ID である projects/project- id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id が含まれています。

    [
     ...
     {
       "name": "ssn",
       "type": "STRING",
       "mode": "REQUIRED",
       "policyTags": {
         "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id",]
       }
     },
     ...
    ]
    

    bq update コマンドを使用してポリシータグを設定する方法については、列にポリシータグを設定するをご覧ください。

  4. のポリシータグについても管理者は同様の手順を実行します。

このきめ細かいアクセスにより、少数のデータ分類ポリシータグを制御するだけで、多くの列へのアクセスを管理できます。

こちらの手順の詳細については、BigQuery の列レベルのセキュリティによるアクセスの制限をご覧ください。

列レベルのセキュリティで使用されるロール

BigQuery の列レベルのセキュリティには、次の Data Catalog のロールが使用されます。

ロール タイトル 適用先 説明
roles/
datacatalog.categoryAdmin
ポリシータグ管理者 プロジェクト 次の権限があります:
  • 分類の作成、読み取り、更新、削除
  • ポリシータグに IAM ポリシーを設定する
このロールでは列のコンテンツを読み取ることができません。

通常、このロールを持つユーザーは、組織向けのデータ ガバナンス ポリシー設定を担当します。
roles/
datacatalog.categoryFineGrainedReader
きめ細かい読み取り ポリシータグ 対応するポリシータグでタグ付けされた BigQuery の列にアクセスできます。

通常、このロールを持つユーザーはデータのクエリを実行します。

書き込みの影響

列レベルのセキュリティで保護されている列からデータを読み取る場合、ユーザーがその列のポリシータグに対するきめ細かい読み取りアクセス権を通じて、読み取り権限を常に持つ必要があります。

適用対象は次のとおりです。

  • テーブル(ワイルドカード テーブルを含む)
  • ビュー
  • テーブルのコピー

列レベルのセキュリティで保護されている列の行にデータを書き込む場合、ユーザーの要件は書き込みのタイプによって異なります。

書き込みオペレーションが「挿入」の場合、きめ細かい読み取りアクセスは必要ありません。 ただし、ユーザーにきめ細かい読み取りアクセス権がないと、挿入されたデータを読み取ることはできません。

書き込みオペレーションが更新、削除、統合のいずれかの場合、きめ細かい読み取りアクセス権がない限り、ユーザーはこのオペレーションを実行できません。

きめ細かい読み取りアクセス権がないユーザーは、ローカル ファイルや Cloud Storage からデータを読み込むことはできません。ただし、ストリーミング読み込みはポリシータグをチェックしないため、ユーザーはストリーミングからデータを読み込むことができます。きめ細かい読み取りアクセス権がないユーザーは、ストリームから読み込んたデータを読み取ることはできません。

詳細については、BigQuery の列レベルのセキュリティを使用した書き込みへの影響をご覧ください。

テーブルのクエリ

ユーザーにデータセットへのアクセス権があり、Data Catalog のきめ細かい読み取りのロールがある場合は、列データを使用できます。ユーザーは通常どおりクエリを実行します。

ユーザーがデータセットにアクセスできるものの、Data Catalog のきめ細かい読み取りのロールがない場合、列データを使用できません。そのようなユーザーが SELECT * を実行した場合、ユーザーがアクセスできない列を示すエラーが表示されます。このエラーを解決する方法は次のとおりです。

  • クエリを変更し、アクセスできない列を除外します。たとえば、ユーザーが ssn 列にはアクセスできないものの残りの列にはアクセスできる場合、次のクエリを実行できます。

    SELECT * EXCEPT (ssn) FROM ...
    

    上記の例では、EXCEPT 句で ssn 列を除外しています。

  • ユーザーを関連データクラスに対して Data Catalog のきめ細かい読み取りのロールを持つものとして追加するよう、Data Catalog 管理者に依頼します。エラー メッセージには、ユーザーがアクセスする必要があるポリシータグの完全な名前が表示されます。

ビューのクエリ

列レベルのセキュリティがビューに与える影響は、そのビューが承認済みビューであるかどうかとは無関係です。どちらの場合も、列レベルのセキュリティは透過的に適用されます。

ビューが承認済みのビューでない場合:

ビューの基になるテーブルの列に対し、列レベルのアクセス権がユーザーにある場合、ユーザーはビュー内の列にクエリを実行できます。アクセス権がない場合、ユーザーはビュー内の列にクエリを実行できません。

ビューが承認済みのビューである場合:

アクセス権を制御できるのは、ビューの基になるテーブルに含まれる列に対する列レベルのセキュリティだけです。テーブルレベルとデータセット レベルの IAM ポリシーは(ある場合)、アクセス権のチェックに使用されません。承認済みビューの基になるテーブルで使用されるポリシータグに対するアクセス権がユーザーにある場合、ユーザーは承認済みビュー内の列にクエリを実行できます。

次の図は、ビューへのアクセスがどのように評価されるかを示しています。

ビューへのアクセス

スナップショットの影響

BigQuery では、ユーザーは以前の状態のテーブルにクエリを実行できます。この機能を使用すると、テーブルの以前のスナップショットから行にクエリを実行できます。また、スナップショットが取得された日付までテーブルをロールバックすることもできます。

レガシー SQL では、テーブル名にスナップショット デコレータを使用してスナップショットにクエリを実行します。標準 SQL では、テーブルに FOR SYSTEM_TIME AS OF 句を使用してスナップショットにクエリを実行します。

スナップショットに対してクエリを実行する時刻は、次の条件のうち最新に制限されます。

  • 過去 7 日間
  • テーブルの作成時刻

テーブルが削除され、同じテーブル名で再作成された場合、以前のテーブルに対してクエリを実行することはできません。

列レベルのセキュリティでスナップショットがどのように機能するかを確認するには、次の設定が前提となります。

  • 起点として、現時点の既存のテーブルがある。

  • 同じテーブルのスナップショットがある。

  • スナップショットのスキーマが、元のスキーマと同じか、そのサブセットである。つまり、スナップショットの列はすべて、生成元に含まれているものです。

以上を前提として、元の(現時点の)テーブルに対する最新の列レベルのセキュリティを対象として権限をチェックします。ユーザーが現在の列を読み取ることができる場合、その列のスナップショットにクエリを実行できます。

元のスキーマとスナップショットのスキーマがクエリの列で異なる場合、スナップショット取得のリクエストは失敗します。

制限事項

  • 宛先テーブルを上書きすると、既存のポリシータグがテーブルから削除されます。ただし、--destination_schema フラグを使用してポリシータグを含むスキーマを指定する場合を除きます。次の例は、--destination_schema の使用方法を示しています。

    bq query --destination_table mydataset.mytable2 \
      --use_legacy_sql=false --destination_schema=schema.json \
      'SELECT * FROM mydataset.mytable1'
    
  • 1 つの列に設定できるポリシータグは 1 つのみです。

  • 1 つのテーブルに、一意のポリシータグを最大 1,000 個まで割り当てることができます。

  • 列レベルのセキュリティを有効にした場合、レガシー SQL は使用できません。ターゲット テーブルにポリシータグがある場合、レガシー SQL クエリはすべて拒否されます。

  • 組織間で参照を使用することはできません。つまり、テーブルとそのテーブルに使用されるポリシータグは、同じ組織内に存在する必要があります。

次のステップ