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

注: 特定の BigQuery エディションで作成された予約を使用する場合、この機能は使用できません。各エディションで有効になる機能の詳細については、BigQuery エディションの概要をご覧ください。

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

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

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

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

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

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

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

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

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

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

注: 既存のデータセットの ACL に加えて、列レベルのアクセス制御が適用されます。列レベルのアクセス制御で保護されたデータにアクセスするには、ユーザーにデータセット権限とポリシータグ権限の両方が必要です。

タグ付けの対象を特定する

所有しているセンシティブ データの種類と、ポリシータグが必要な列を特定するには、Sensitive Data Protection を使用して、組織、フォルダ、プロジェクト全体でデータに関するプロファイルを生成することを検討してください。データ プロファイルには、テーブルに関する指標とメタデータが含まれており、センシティブ データとリスクの高いデータの場所を特定できます。Sensitive Data Protection は、これらの指標をプロジェクト、テーブル、列の各レベルで報告します。詳細については、BigQuery データのデータ プロファイルをご覧ください。

次の図は、列データ プロファイルのリストを示しています（クリックして拡大）。データリスク値が高い列には、高度なセンシティブ データが含まれ、列レベルのアクセス制御がない場合があります。あるいは、これらの列には、多くのユーザーがアクセスできる中程度または高度なセンシティブ データが含まれている場合があります。

使用例

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

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

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

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

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

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

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

   

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

   あるいは、bq update コマンドを使用してポリシータグを設定することもできます。以下の例では、policyTags の names フィールドに、高のポリシータグの 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 コマンドでポリシータグを設定する方法については、列にポリシータグを設定するをご覧ください。

   注: 1 つの列に割り当て可能なポリシータグは 1 つのみです。

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

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

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

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

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

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

ロール / ID	権限	説明
Data Catalog ポリシータグ管理者 / datacatalog.categoryAdmin	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 Data Policy 管理者ロール、BigQuery 管理者ロール、または BigQuery データオーナー ロールが必要です。Google Cloud コンソールを使用して分類階層に対するアクセス制御を適用すると、サービスによって自動的にデータポリシーが作成されます。

ロール / ID	権限	説明
BigQuery Data Policy 管理者 / bigquerydatapolicy.admin 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 ポリシーの取得と設定。

また、datacatalog.taxonomies.get 権限も必要です。この権限は、いくつかの Data Catalog の事前定義ロールから取得できます。

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

ロール / ID	権限	説明
きめ細かい読み取り / datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	ポリシータグ レベルで適用されます。 このロールは、ポリシータグによって制限された列のコンテンツにアクセスする権限を付与します。

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

書き込みの影響

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

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

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

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

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

ユーザーが INSERT SELECT ステートメントを実行する場合、クエリ対象のテーブルに対するきめ細かい読み取りロールが必要です。

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

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

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

テーブルをクエリする

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

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

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

  SELECT * EXCEPT (ssn) FROM ...

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

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

クエリビュー

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

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

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

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

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

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

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

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

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

max_staleness によるタイムトラベルとマテリアライズド ビューの影響

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

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

max_staleness オプションが設定されたマテリアライズド ビューは、未更新期間内の過去のデータを返します。この動作はビューの最終更新時に FOR SYSTEM_TIME AS OF を使用したクエリと似ており、削除または更新されたレコードに BigQuery でクエリを実行できます。時間 t でテーブルの履歴データをクエリするとします。この場合は、次のとおりです。

• 時間 t のスキーマがテーブルの現在のスキーマと同一であるか、またはサブセットである場合、BigQuery は現在のテーブルの最新の列レベルのセキュリティを確認します。ユーザーが現在の列を読み取ることができる場合、ユーザーはそれらの列の履歴データをクエリできます。列レベルのセキュリティで保護されている列のセンシティブ データを削除またはマスクするために、列レベルのセキュリティは、センシティブ データのクリーンアップから構成されたタイムトラベル期間が経過した後にのみ、安全に緩和できます。

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

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

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

ポリシータグ

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

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

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

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

組織

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

制限事項

• 特定の BigQuery エディションで作成された予約を使用する場合、この機能は使用できません。各エディションで有効になる機能の詳細については、BigQuery エディションの概要をご覧ください。

• BigQuery は、BigLake テーブル、BigQuery テーブル、BigQuery Omni テーブルの列レベルのアクセス制御のみをサポートします。

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

  bq query --destination_table mydataset.mytable2 \
    --use_legacy_sql=false --destination_schema=schema.json \
    'SELECT * FROM mydataset.mytable1'
  

  スキーマの変更は、クエリの実行とは別のオペレーションで行われます。--destination_table フラグを指定することでクエリ結果をテーブルに書き込んだ後、クエリによって例外が発生した場合、スキーマの変更がスキップされる可能性があります。このような場合は、宛先テーブルのスキーマを確認し、必要に応じてスキーマを手動で更新してください。

• 1 つの列に設定できるポリシータグは 1 つのみです。

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

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

• 次のスクリーンショットに示すように、ポリシータグ階層は、ルートノードから最下位レベルのサブタグまでの深さが 5 レベルを超えることはできません。

  

• 分類名は、組織内のすべてのプロジェクト間で一意である必要があります。

• 列レベルまたは行レベルのアクセス制御を有効にしている場合、リージョン間でテーブルをコピーすることはできません。ソーステーブルにポリシータグがある場合、リージョン間でのテーブルのコピーは拒否されます。

料金

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

• BigQuery の料金
• Data Catalog の料金

監査ロギング

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

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

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

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

次のステップ

• 列レベルのアクセス制御を使用する詳細については、列レベルのアクセス制御によるアクセスの制限をご覧ください。

• ポリシータグのベスト プラクティスについては、BigQuery のベスト プラクティス: ポリシータグの使用をご覧ください。