列レベルのアクセス制御の概要

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

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

列レベルのアクセス制御を強化するため、必要に応じて動的データ マスキングプレビュー)を使用できます。データ マスキングを使用すると、列の実際の値の代わりに null、デフォルト、またはハッシュされたコンテンツで置換することで、機密データをマスクできます。

列レベルのアクセス制御のワークフロー

ワークフロー

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

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

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

  3. 分類階層にアクセス制御を適用します。アクセス制御を適用すると、分類階層内のすべてのポリシータグに対して定義されたアクセス制限が適用されます。

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

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

使用例

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

ポリシータグ

列レベルのセキュリティを設定するには、適切な権限を持つデータ管理担当者が以下の手順を行い、データ分類の階層を設定します。

  1. データ管理担当者はデータカタログに「ビジネス クリティカル」という分類を作成します。この分類には、ノードまたはポリシータグが含まれます。

  2. データ管理担当者は、ノードのポリシーに high-tier-access というグループへのアクセスを含めるかどうかを決定します。

  3. データ管理担当者は、の下にノードの分類レベルをさらに作成します。最下位ノードはリーフノードです。たとえば、employee_ssn リーフノードなどです。データ管理担当者は、employee_ssn リーフノード用に異なるアクセス ポリシーを作成できます。

  4. データ管理担当者は、特定のテーブル列にポリシータグを割り当てます。この例では、データ管理担当者は、テーブル内の employee_ssn 列にアクセス ポリシーを割り当てます。

  5. Console の [現在のスキーマ] ページに、特定の列を管理するポリシータグが表示されます。この例では、employee_ssn 列にはポリシータグが割り当てられているため、employee_ssn のスキーマを表示すると、Console の [Policy tags] フィールドに分類名とポリシータグ(Business criticality:High)が表示されます。

    ポリシータグの UI

    Console でポリシータグを設定する方法については、列にポリシータグを設定するをご覧ください。

    あるいは、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 コマンドでポリシータグを設定する方法については、列にポリシータグを設定するをご覧ください。

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

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

こうした手順の詳細については、列レベルのアクセス制御によるアクセスの制限をご覧ください。

列レベルのアクセス制御で使用されるロール

BigQuery の列レベルのアクセス制御には次のロールが使用されます。

分類階層とポリシータグを作成、管理する必要があるユーザーには、Data Catalog ポリシータグ管理者ロールが必要です。

ロール / ID 権限 Description
Data Catalog ポリシータグ管理者 / datacatalog.policyTagAdmin datacatalog.categories.getIamPolicy
datacatalog.categories.setIamPolicy
datacatalog.taxonomies.create
datacatalog.taxonomies.delete
datacatalog.taxonomies.get
datacatalog.taxonomies.getIamPolicy
datacatalog.taxonomies.list
datacatalog.taxonomies.setIamPolicy
datacatalog.taxonomies.update
resourcemanager.projects.get
resourcemanager.projects.list

プロジェクト レベルで適用されます。

このロールにより、次の権限が付与されます。

  • 分類階層とポリシータグの作成、読み取り、更新、削除。
  • ポリシータグの IAM ポリシーの取得と設定。

データポリシーを作成して管理するには、BigQuery 管理者ロールか、BigQuery データオーナー ロールが必要です。Google Cloud コンソールを使用して分類階層に対するアクセス制御を適用すると、サービスによって自動的にデータポリシーが作成されます。

ロール / ID 権限 Description
BigQuery 管理者 / bigquery.admin

BigQuery データオーナー / bigquery.dataOwner
bigquery.dataPolicies.create
bigquery.dataPolicies.delete
bigquery.dataPolicies.get
bigquery.dataPolicies.getIamPolicy
bigquery.dataPolicies.list
bigquery.dataPolicies.setIamPolicy
bigquery.dataPolicies.update

bigquery.dataPolicies.create 権限と bigquery.dataPolicies.list 権限は、プロジェクト レベルで適用されます。その他の権限は、データポリシー レベルで適用されます。

このロールにより、次の権限が付与されます。

  • データポリシーの作成、読み取り、更新、削除。
  • データポリシーに対する IAM ポリシーの取得と設定。

保護された列のデータにアクセスする必要があるユーザーには、Data Catalog のきめ細かい読み取りロールが必要です。

ロール / ID 権限 Description
きめ細かい読み取り / datacatalog.categoryFineGrainedReader datacatalog.categories.fineGrainedGet

ポリシータグレベルで適用されます。

このロールは、ポリシータグによって制限された列のコンテンツにアクセスする権限を付与します。

Data Catalog のロールの詳細については、Data Catalog Identity and Access Management(IAM)をご覧ください。 BigQuery のロールの詳細については、IAM によるアクセス制御をご覧ください。

書き込みの影響

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

これは次のトラフィックに適用されます。

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

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

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

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

ユーザーは、ローカル ファイルまたは Cloud Storage からデータを読み込めます。テーブルにデータを読み込む際、BigQuery は宛先テーブルの列に対するきめ細かい読み取り権限を確認しません。これは、データの読み込みでは宛先テーブルからのコンテンツの読み取りは不要なためです。同様に、ストリーミング読み込みでは、ポリシータグがチェックさあれないため、ユーザーはストリーミングからデータを読み込めます。きめ細かい読み取りアクセス権がないユーザーは、ストリームから読み込んだデータを読み取るアクセス権がありません。

詳細については、列レベルのアクセス制御を使用した書き込みへの影響をご覧ください。

テーブルをクエリする

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

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

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

    SELECT * EXCEPT (ssn) FROM ...
    

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

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

クエリビュー

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

承認済みビューは、次のいずれかです。

  • データセット内のテーブルへのアクセスが明示的に承認されたビュー。
  • 承認済みデータセットに含まれているため、データセット内のテーブルへのアクセスが暗黙的に承認されたビュー。

詳細については、承認済みビュー承認済みデータセットをご覧ください。

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

ビューの基盤テーブルとデータセットに対する IAM アクセス権と、ビューの基盤テーブルに対する列レベルのアクセス権がユーザーに付与されている場合、ユーザーはビュー内の列にクエリを実行できます。アクセス権がない場合、ユーザーはビュー内の列にクエリを実行できません。

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

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

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

ビューへのアクセス

タイムトラベルの影響

BigQuery では、ユーザーは以前の状態のテーブルにクエリを実行できます。この機能により、過去の時点の行にクエリを実行できます。また、ある時点のテーブルを復元することもできます。

レガシー SQL では、テーブル名に時間デコレータを使用して履歴データをクエリします。標準 SQL では、テーブルに FOR SYSTEM_TIME AS OF 句を使用して履歴データをクエリします。

時間 t でテーブルの履歴データをクエリするとします。この場合は、次のとおりです。

  • 時間 t のスキーマがテーブルの現在のスキーマと同一であるか、またはサブセットである場合、BigQuery は現在のテーブルの最新の列レベルのセキュリティを確認します。ユーザーが現在の列を読み取ることができる場合、ユーザーはそれらの列の履歴データをクエリできます。

  • t 時点でのスキーマがクエリの列の現在のスキーマと異なる場合、クエリは失敗します。

ロケーションに関する留意事項

分類のロケーションを選択するときは、次の制限事項を考慮してください。

ポリシータグ

分類は BigQuery のデータセットやテーブルなどのリージョン リソースです。分類を作成するときは、分類にリージョン(ロケーション)を指定します。

分類を作成し、BigQuery を利用可能なすべてのリージョン内のテーブルにポリシータグを適用できます。ただし、分類からテーブル列にポリシータグを適用するには、分類自体とテーブルが同じリージョンに存在している必要があります。

別のロケーションに存在しているテーブル列にポリシータグを適用することはできませんが、分類を明示的に複製して別の場所にコピーすることはできます。

複数の場所にわたって同じ分類とポリシータグを使用する場合は、複数のロケーションにまたがるポリシータグの管理で分類の複製の詳細について確認してください。

組織

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

制限事項

  • 宛先テーブルを上書きすると、既存のポリシータグがテーブルから削除されます。ただし、--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 クエリはすべて拒否されます。

料金

列レベルのアクセス制御には、BigQuery と Data Catalog の両方を使用する必要があります。これらのプロダクトの料金については、次のトピックをご覧ください。

監査ロギング

ポリシータグ付きのテーブルデータが読み取られると、参照先のポリシータグが Cloud Logging に保存されます。ただし、ポリシータグのチェックは、チェックをトリガーしたクエリに関連付けられません。

監査者は、Cloud Logging を使用して、誰がどの種類の機密データにアクセスできるのかを確認できます。詳細については、ポリシータグの監査をご覧ください。

BigQuery のロギングの詳細については、BigQuery Monitoring の概要をご覧ください。

Google Cloud でのロギングの詳細については、Cloud Logging をご覧ください。

次のステップ