IAM Conditions によるアクセス制御
このドキュメントでは、IAM Conditions を使用して BigQuery リソースへのアクセスを制御する方法について説明します。
IAM Conditions では、指定された条件が満たされた場合にのみ BigQuery リソースへのアクセスを許可できます。たとえば、リソースへのアクセスを一定期間または 1 日の中の特定の時間帯に定期的に付与できます。IAM Conditions は、プロジェクト、フォルダ、組織レベルでサポートされ、BigQuery データセット、テーブル、ルーティン、モデルに適用できます。
IAM Conditions は、Identity and Access Management(IAM)権限を、まだ存在しないリソースを含む多くの関連リソースに同時に付与する場合に役立ちます。BigQuery リソースの無関係なグループに権限を付与するには、IAM タグの使用を検討してください。
始める前に
IAM API を有効にして、このドキュメントの各タスクを実行するために必要な権限を付与する IAM ロールを付与します。
IAM API を有効にする
IAM API を有効にするには、次のいずれかのオプションを選択します。
コンソール
[Identity and Access Management(IAM)API] ページに移動し、API を有効にします。
gcloud
gcloud services enable
コマンドを実行します。
gcloud services enable iam.googleapis.com
必要な権限
BigQuery リソースに IAM Conditions を適用するために必要な権限を取得するには、プロジェクト IAM 管理者(roles/resourcemanager.projectIamAdmin
)IAM ロールを付与するよう管理者に依頼してください。ロールの付与の詳細については、アクセス権の管理をご覧ください。
この事前定義ロールには、IAM Conditions を BigQuery リソースに適用するために必要な resourcemanager.projects.setIamPolicy
権限が含まれています。
カスタムロールや他の事前定義ロールを使用して、この権限を取得することもできます。
組織全体で IAM Conditions を使用する場合は、組織のポリシーを管理する権限も必要です。BigQuery における IAM ロールと権限の詳細については、IAM の概要をご覧ください。
条件の属性
IAM Conditions は、次の属性に基づいて BigQuery リソースに設定できます。
request.time
: ユーザーが BigQuery リソースへのアクセスを試行した時刻。詳細と例については、日時属性をご覧ください。resource.name
: BigQuery リソースのパス。形式については、属性の形式の表をご覧ください。resource.type
: BigQuery リソースのタイプ。形式については、属性の形式の表をご覧ください。resource.service
: BigQuery リソースが使用する Google Cloud サービス。形式については、属性の形式の表をご覧ください。resource.tags
: BigQuery リソースに付加されたタグ。タグは、BigQuery のデータセットとテーブルのリソースでのみサポートされています。形式については、属性の形式と IAM ドキュメントの表をご覧ください。
属性の形式
BigQuery データセットの条件を作成する場合は、次の形式を使用します。
属性 | 値 |
---|---|
resource.type |
bigquery.googleapis.com/Dataset |
resource.name |
projects/PROJECT_ID/datasets/DATASET_ID |
resource.service |
bigquery.googleapis.com |
resource.tags |
hasTagKey 、hasTagKeyId 、matchTag 、matchTagId がサポートされます。詳細については、リソースタグをご覧ください。 |
BigQuery テーブルの条件を作成する場合は、次の形式を使用します。
属性 | 値 |
---|---|
resource.type |
bigquery.googleapis.com/Table |
resource.name |
projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID |
resource.service |
bigquery.googleapis.com |
resource.tags |
hasTagKey 、hasTagKeyId 、matchTag 、matchTagId がサポートされます。詳細については、リソースタグをご覧ください。 |
BigQuery ルーティンの条件を作成する場合は、次の形式を使用します。
属性 | 値 |
---|---|
resource.type |
bigquery.googleapis.com/Routine |
resource.name |
projects/PROJECT_ID/datasets/DATASET_ID/routines/ROUTINE_ID |
resource.service |
bigquery.googleapis.com |
BigQuery モデルの条件を作成する場合は、次の形式を使用します。
属性 | 値 |
---|---|
resource.type |
bigquery.googleapis.com/Model |
resource.name |
projects/PROJECT_ID/datasets/DATASET_ID/models/MODEL_ID |
resource.service |
bigquery.googleapis.com |
次のように置き換えます。
PROJECT_ID
: アクセス権を付与するリソースを含むプロジェクトの IDDATASET_ID
: アクセス権を付与するデータセットの IDTABLE_ID
: アクセス権を付与するテーブルの IDROUTINE_ID
: アクセス権を付与するルーティンの IDMODEL_ID
: アクセス権を付与するモデルの ID
リソースに条件を追加する
BigQuery でデータセット、テーブル、ルーティン、モデルに条件を追加するには、条件付きポリシーを許可するをご覧ください。条件を作成するときは、属性形式の表をご覧ください。
条件に関するベスト プラクティス
BigQuery で条件を作成する場合は、次のベスト プラクティスを使用します。
- サポートされていない型は空の文字列を使用し、ほぼすべての否定条件と一致するため、
resource.type
、resource.name
、resource.service
には否定条件を使用しないでください。詳細については、否定条件をご覧ください。 - そのレベルの具体性が必要でない場合でも、条件に
resource.type
、resource.name
、resource.service
を含めます。こうすることで、ワークフロー内のリソースが変更されても、今後他のリソースが意図せず他のリソースに含まれないように条件を維持できます。 - 権限を付与する際は、可能な限り最小限の権限セットを含め、過剰な権限を誤って付与しないようにします。
- BigQuery テーブルのパスには親プロジェクト ID とデータセット ID が接頭辞として付くため、条件で
resource.name.startsWith
フレーズを使用する場合は注意が必要です。具体的ではない条件によって、過剰な権限が付与されることがあります。ただし、ユーザーがワイルドカード クエリを実行できるようにする場合は、resource.name.startsWith
フレーズが便利です。たとえば、条件resource.name.startsWith("projects/my_project/datasets/my_dataset/tables/table_prefix")
を指定すると、ユーザーはSELECT * FROM my_dataset.table_prefix*
クエリを実行できます。 - データセット、テーブル、ルーティン、モデル以外の BigQuery リソースの条件を追加しないでください。
- 正しいリソースに対して正しい権限を付与していることを確認します。たとえば、リソースを一覧表示する権限(
bigquery.RESOURCE.list
)は親レベルで付与する必要がありますが、リソースを削除する権限(bigquery.RESOURCE.delete
)はリソースレベルで付与する必要があります。データセットの削除では、含まれているすべてのリソースも削除されるため、データセットに対するテーブル、モデル、ルーティンの削除権限が必要です。 - テーブル スナップショットとタイムトラベルは権限に影響しないことに注意してください。
否定条件
resource.name != resource
のような否定条件では、過剰なアクセス権が誤って付与される可能性があります。サポートされていない BigQuery リソースには空のリソース属性があります。つまり、すべての否定条件に一致します。BigQuery の外部にあるサービスのリソースも、否定的な条件と一致する可能性があります。
さらに、否定条件により、ユーザーがワイルドカードを使用してクエリを実行する際に問題が発生します。たとえば、否定条件 resource.name != /projects/my_project/datasets/my_dataset/tables/secret
について考えてみます。この条件は、secret
という名前のテーブルを除くすべてのリソースへのアクセス権を付与しているようです。ただし、ユーザーは引き続き、SELECT * from my_project.my_dataset.secre*;
などのワイルドカード クエリを使用して、そのテーブルをクエリできます。
また、テーブル、ルーティン、モデルに否定条件があると、親データセットに過剰な権限が付与される場合があります。削除権限はデータセット レベルで管理されるため、ユーザーはこれらのリソースを削除できる可能性があります。
制限事項
- 承認済みビュー、承認済みルーティン、承認済みデータセットの付与を IAM Conditions で追加することはできません。
- データセットまたはテーブルへの条件付きアクセス権を持つユーザーは、Google Cloud コンソールからそのリソースに対する権限を変更できません。bq ツールと API のみがサポートされます。
- 行レベルと列レベルのアクセス制御は、IAM Conditions で直接サポートされていません。ただし、条件付きアクセス権を持つユーザーは、テーブルに対する BigQuery 管理者ロール(
roles/bigquery.admin
)を自分自身に付与して行と列のアクセス ポリシーを変更できます。 - IAM ポリシーの変更が有効になるまで、最長 5 分かかることがあります。
- 条件付きアクセスを持つユーザーは、
INFORMATION_SCHEMA
ビューをクエリできない場合があります。 - 条件付きテーブルへのアクセス権のみを持つユーザーは、テーブル ワイルドカード関数を実行できません。
例
BigQuery での IAM Conditions のユースケースの例を次に示します。
特定のテーブルへの読み取り権限を付与する
この例では、dataset_1
データセットの table_1
テーブルに対する BigQuery データ閲覧者のロールを cloudysanfrancisco@gmail.com
に付与します。このロールのユーザーは、テーブルに対してクエリを実行し、bq ツールを使用してそのテーブルにアクセスできます。ユーザーにはデータセットに対する bigquery.tables.list
権限がないため、Google Cloud コンソールでテーブルを表示できません。
{ "members": [cloudysanfrancisco@gmail.com], "role": roles/bigquery.dataViewer, "condition": { "title": "Table dataset_1.table_1", "description": "Allowed to read table with name table_1 in dataset_1 dataset", "expression": resource.name == projects/project_1/datasets/dataset_1/tables/table_1 && resource.type == bigquery.googleapis.com/Table } }
特定のデータセットにリストアクセス権を付与する
この例では、dataset_2
データセットに対する BigQuery メタデータ閲覧者のロールを cloudysanfrancisco@gmail.com
に付与します。このロールのユーザーは、データセット内のすべてのリソースを一覧表示できますが、それらのリソースに対してクエリを実行することはできません。
{ "members": [cloudysanfrancisco@gmail.com], "role": roles/bigquery.metadataViewer, "condition": { "title": "Dataset dataset_2", "description": "Allowed to list resources in dataset_2 dataset", "expression": resource.name == projects/project_2/datasets/dataset_2 && resource.type == bigquery.googleapis.com/Dataset } }
特定の接頭辞を持つすべてのデータセット内のすべてのテーブルへのオーナー アクセス権を付与する
この例では、public_
接頭辞で始まるすべてのデータセットのすべてのテーブルに対する BigQuery データオーナーのロールを cloudysanfrancisco@gmail.com
に付与します。
{ "members": [cloudysanfrancisco@gmail.com], "role": roles/bigquery.dataOwner, "condition": { "title": "Tables public_", "description": "Allowed owner access to tables in datasets with public_ prefix", "expression": resource.name.startsWith("projects/project_3/datasets/public_") && resource.type == bigquery.googleapis.com/Table } }
特定の接頭辞を持つすべてのデータセット内のすべてのテーブル、モデル、ルーティンにオーナー アクセス権を付与する
この例では、general_
接頭辞で始まるすべてのデータセットのすべてのテーブル、モデル、ルーティンに対する BigQuery データオーナーのロールを cloudysanfrancisco@gmail.com
に付与します。
{ "members": [cloudysanfrancisco@gmail.com], "role": roles/bigquery.dataOwner, "condition": { "title": "Tables general_", "description": "Allowed owner access to tables in datasets with general_ prefix", "expression": resource.name.startsWith("projects/project_4/datasets/general_") && resource.type == bigquery.googleapis.com/Table } }, { "members": [cloudysanfrancisco@gmail.com], "role": roles/bigquery.dataOwner, "condition": { "title": "Models general_", "description": "Allowed owner access to models in datasets with general_ prefix", "expression": resource.name.startsWith("projects/project_4/datasets/general_") && resource.type == bigquery.googleapis.com/Model } }, { "members": [cloudysanfrancisco@gmail.com], "role": roles/bigquery.dataOwner, "condition": { "title": "Routines general_", "description": "Allowed owner access to routines in datasets with general_ prefix", "expression": resource.name.startsWith("projects/project_4/datasets/general_") && resource.type == bigquery.googleapis.com/Routine } }
次のステップ
- IAM Conditions を使用した一時アクセスの構成方法を学習する。
- IAM Conditions を使用してリソースベースのアクセスの構成方法を学習する。