プリンシパルアクセス境界ポリシー

プリンシパルアクセス境界（PAB）ポリシーを使用すると、プリンシパルがアクセスできるリソースを制限できます。

たとえば、プリンシパルアクセス境界ポリシーを使用して、プリンシパルが他の組織のリソースにアクセスできないようにすると、フィッシング攻撃やデータの引き出しを防ぐことができます。

Identity and Access Management（IAM）が提供する他のタイプのアクセス制御ポリシーについては、ポリシーの種類をご覧ください。

プリンシパルアクセス境界ポリシーの仕組み

デフォルトでは、プリンシパルはすべての Google Cloud リソースにアクセスできます。つまり、プリンシパルがリソースに対する権限を持ち、その権限が拒否されていなければ、プリンシパルはリソースにアクセスできます。

プリンシパルアクセス境界ポリシーを使用すると、プリンシパルがアクセスできるリソースを制限できます。プリンシパルアクセス境界ポリシーによってプリンシパルがリソースにアクセスできなくなった場合、付与されたロールに関係なく、そのリソースへのアクセスが制限されます。

プリンシパルがアクセス権のないリソースにアクセスしようとすると、プリンシパルアクセス境界ポリシーによって Identity and Access Management（IAM）の権限の一部がブロックされます。ブロックされる権限の詳細については、プリンシパルアクセス境界でブロックできる権限をご覧ください。

プリンシパルアクセス境界ポリシーは、プリンシパルアクセス境界ルールで構成されます。各プリンシパルアクセス境界ルールは、影響を受けるプリンシパルがアクセスできる一連のリソースを定義します。組織で作成できるプリンシパルのアクセス境界ポリシーは最大 1,000 個です。

プリンシパルアクセス境界ポリシーを作成したら、ポリシーバインディングを作成して、ポリシーをプリンシパルのセットに適用します。

プリンシパルは、1 つ以上のプリンシパルアクセス境界ポリシーの対象にすることができます。各プリンシパルは、これらのポリシーにリストされているリソースにのみアクセスできます。他のすべてのリソースの場合、そのリソースに対するプリンシパルのアクセスは、そのリソースに対するプリンシパルにロールを付与しても制限されます。

プリンシパルアクセス境界ポリシーはリソースではなくプリンシパルに関連付けられているため、プリンシパルが所有していないリソースに対するアクセスも禁止できます。たとえば、次のシナリオについて考えてみましょう。

リソースへのアクセスを禁止するプリンシパルアクセス境界ポリシー

プリンシパル Tal（tal@altostrat.com）は、Google Workspace 組織 altostrat.com のメンバーです。
Tal には、別の組織 cymbalgroup.com の Cloud Storage バケットに対するストレージ管理者（roles/storage.admin）ロールが付与されています。このロールには、バケット内のオブジェクトを表示するために必要な storage.objects.get 権限が含まれています。
cymbalgroup.com には、Tal が storage.objects.get 権限を使用できないようにする拒否ポリシーはありません。

許可ポリシーと拒否ポリシーだけでは、altostrat.com は Tal によるこの外部バケット内のオブジェクトの表示を防ぐことはできません。altostrat.com プリンシパルにはバケットの許可ポリシーを編集する権限がないため、Tal のロールを取り消すことはできません。また、cymbalgroup.com に拒否ポリシーを作成する権限もないため、拒否ポリシーを使用して Tal によるバケットへのアクセスを禁止することもできません。

ただし、プリンシパルアクセス境界ポリシーを使用すると、altostrat.com 管理者は、Tal による cymbalgroup.com バケット内のオブジェクトまたは altostrat.com 外の任意のバケット内のオブジェクトの表示を防ぐことができます。これを行うには、管理者は、altostrat.com プリンシパルが altostrat.com のリソースにのみアクセスできるようにするプリンシパルアクセス境界ポリシーを作成します。次に、ポリシーバインディングを作成して、このポリシーを組織 altostrat.com 内のすべてのプリンシパルに適用します。このポリシーが適用されると、Tal はバケットにストレージ管理者ロールが付与されていても、cymbalgroup.com バケット内のオブジェクトを表示できなくなります。

フェイルオープンの評価

プリンシパルアクセス境界ポリシーのプレビューリリース中は、プリンシパルアクセス境界ポリシーはフェイルオープンになります。つまり、IAM がプリンシパルアクセス境界ポリシーを評価できない場合、プリンシパルアクセス境界ポリシーは無視され、関連する許可ポリシーと拒否ポリシーの評価に進みます。

プリンシパルアクセス境界ポリシーによってブロックされる権限

プリンシパルがアクセス権のないリソースにアクセスしようとすると、プリンシパルアクセス境界ポリシーにより、プリンシパルは、リソースにアクセスするための Identity and Access Management（IAM）権限の一部（すべてではありません）を使用できなくなります。

プリンシパルアクセス境界ポリシーが権限をブロックすると、IAM はその権限に対してプリンシパルアクセス境界ポリシーを適用します。つまり、リソースにアクセスする資格のないプリンシパルが、その権限を使用してリソースにアクセスできないようにします。

プリンシパルアクセス境界ポリシーが権限をブロックしない場合、プリンシパルアクセス境界ポリシーは、プリンシパルが権限を使用できるかどうかに影響しません。

たとえば、プリンシパル Lee（lee@example.com）に Dataflow デベロッパーロール（roles/dataflow.developer）が付与されているとします。このロールには dataflow.jobs.snapshot 権限が含まれており、Lee は Dataflow ジョブのスナップショットを取得できます。Lee には、example.com 外のリソースにアクセスできないようにするプリンシパルアクセス境界ポリシーも適用されます。ただし、プリンシパルアクセス境界ポリシーで dataflow.jobs.snapshot 権限がブロックされていない場合、Lee は example.com 外の組織の Dataflow ジョブのスナップショットを取得できます。

プリンシパルアクセス境界ポリシーがブロックする権限は、プリンシパルアクセス境界の適用バージョンによって異なります。

プリンシパルアクセス境界の適用バージョン

各プリンシパルアクセス境界ポリシーでは適用バージョン指定します。これにより、プリンシパルアクセス境界ポリシーがブロックできる IAM 権限の事前定義リストが決まります。適用バージョンは、プリンシパルアクセス境界ポリシーを作成または更新するときに指定します。適用バージョンを指定しないと、IAM は最新の適用バージョンを使用し、更新するまでそのバージョンを継続して使用します。

IAM では、追加の権限をブロックできる新しいプリンシパルアクセス境界適用バージョンが定期的に追加されています。新しいバージョンでは、以前のバージョンの権限をすべてブロックすることもできます。

新しい適用バージョンで権限をブロックするには、新しいバージョンを使用するようにプリンシパルアクセス境界ポリシーを更新する必要があります。新しいバージョンがリリースされたときに適用バージョンを自動的に更新するには、ポリシーの作成時に値 latest を使用します。ただし、この値を使用することはおすすめしません。プリンシパルが予期せずリソースへのアクセス権を失う可能性があるためです。

各適用バージョンでブロックされる権限の一覧については、プリンシパルアクセス境界ポリシーでブロックされる権限をご覧ください。

プリンシパルアクセス境界ポリシーをプリンシパルセットにバインドする

プリンシパルアクセス境界ポリシーをプリンシパルセットにバインドするには、適用するプリンシパルアクセス境界ポリシーとプリンシパルセットの両方を指定するポリシーバインディングを作成します。ポリシーをプリンシパルセットにバインドすると、そのプリンシパルセット内のプリンシパルは、プリンシパルアクセス境界ポリシーのルールに含まれるリソースにのみアクセスできます。

プリンシパルアクセス境界ポリシーは、任意の数のプリンシパルセットにバインドできます。各プリンシパルセットには、最大 10 個のプリンシパルアクセス境界ポリシーをバインドできます。

プリンシパルアクセス境界ポリシーの管理方法については、プリンシパルアクセス境界ポリシーを作成して適用するをご覧ください。

サポートされているプリンシパルセット

次の表に、プリンシパルアクセス境界ポリシーをバインドできるプリンシパルセットの種類を示します。各行の内容は次のとおりです。

プリンシパルセットのタイプ
そのタイプのプリンシパルセット内のプリンシパル
そのタイプのプリンシパルセットの ID の形式
そのタイプのプリンシパルセットのポリシーバインディングを親とする Resource Manager リソース（プロジェクト、フォルダ、組織）

プリンシパルセット	詳細	ポリシーバインディングの親リソース
Workforce Identity プール	指定された Workforce Identity プールのすべての ID が含まれます。形式: `//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID`	Workforce Identity プールを含む組織
Workload Identity プール	指定された Workload Identity プール内のすべての ID が含まれます。形式: `//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID`	Workload Identity プールを含むプロジェクト
Google Workspace ドメイン	指定された Google Workspace ドメイン内のすべての ID が含まれます。形式: `//iam.googleapis.com/locations/global/workspace/WORKSPACE_ID` Workspace ID は、次の方法で確認できます。 `gcloud organizations describe` コマンドを使用します。Workspace ID は、レスポンスの `directoryCustomerId` フィールドにあります。 Cloud Resource Manager API の `organizations.get` メソッドを使用します。Workspace ID は、レスポンスの `directoryCustomerId` フィールドにあります。管理コンソールで Workspace ID を確認します。この方法では、Google Workspace 特権管理者ロールが必要です。	Google Workspace ドメインに関連付けられている組織
プロジェクトのプリンシパルセット	指定したプロジェクト内のすべてのサービスアカウントと Workload Identity プールが含まれます。形式: `//cloudresourcemanager.googleapis.com/projects/PROJECT_ID`	プロジェクト
フォルダのプリンシパルセット	指定したフォルダ内のすべてのプロジェクトのすべてのサービスアカウントと Workload Identity プールが含まれます。形式: `//cloudresourcemanager.googleapis.com/folders/FOLDER_ID`	フォルダ
組織のプリンシパルセット	次の ID が含まれます。 Google Workspace のお客様 ID に関連付けられているすべてのドメイン内のすべての ID 組織内のすべての Workforce Identity プール組織内の任意のプロジェクト内のすべてのサービスアカウントと Workload Identity プール形式: `//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID`	組織

プリンシパルアクセス境界ポリシーの条件付きポリシーバインディング

プリンシパルアクセス境界ポリシーのポリシーバインディングで条件式を使用して、ポリシーが適用されるプリンシパルをさらに絞り込むことができます。

ポリシーバインディングの条件式は、最大 10 個の論理演算子（&&、||、または !）で結合された 1 つ以上のステートメントで構成されます。各ステートメントは、ポリシーバインディングに適用される属性ベースの制御ルールを表します。これにより、最終的にポリシーが適用されるかどうかが決まります。

ポリシーバインディングの条件で principal.type 属性と principal.subject 属性を使用できます。ポリシーバインディングの条件では、他の属性はサポートされていません。

principal.type 属性は、リクエスト内のプリンシパルのタイプ（サービスアカウント、Workload Identity プール内の ID など）を示します。この属性の条件を使用して、プリンシパルアクセス境界ポリシーを適用するプリンシパルの種類を制御できます。

たとえば、プリンシパルアクセス境界ポリシーのバインディングに次の条件式を追加すると、このポリシーはサービスアカウントにのみ適用されます。
```
principal.type == 'iam.googleapis.com/ServiceAccount'
```
principal.subject 属性は、リクエスト内のプリンシパルの ID を示します（例: cruz@example.com）。この属性に条件を使用すると、プリンシパルアクセス境界ポリシーの対象となるプリンシパルを正確に制御できます。

たとえば、プリンシパルアクセス境界ポリシーのバインディングに次の条件式を追加すると、ユーザー special-admin@example.com にはポリシーが適用されません。
```
principal.subject != 'special-admin@example.com'
```

これらの条件に使用できる値の詳細については、Conditions 属性のリファレンスをご覧ください。

例: 条件を使用して、プリンシパルがアクセスできるリソースを減らす

プリンシパルアクセス境界ポリシーバインディングで条件を使用する目的の一例は、1 つの特定のプリンシパルがアクセスできるリソースを減らすことです。

メールアドレス dev-project-service-account@dev-project.iam.gserviceaccount.com を持つサービスアカウント dev-project-service-account があるとします。このサービスアカウントは、組織 example.com 内のすべてのリソースへのアクセスをプリンシパルに許可するプリンシパルアクセス境界ポリシーの対象となっています。このポリシーは、example.com 組織のプリンシパルセットに関連付けられています。

ここで、dev-project-service-account が example.com 内のすべてのリソースにアクセスできるようにするのではなく、dev-project 内のリソースにのみアクセスできるようにします。ただし、example.com プリンシパルセット内の他のプリンシパルがアクセスできるリソースは変更しないようにする必要があります。

この変更を行うには、プリンシパルがアクセスできるリソースを減らすための手順を進めます。ただし、ポリシーバインディングを削除するのではなく、ポリシーバインディングに条件を追加します。

dev-project-service-account を対象とする唯一のプリンシパルアクセス境界ポリシーは、プリンシパルが example.com 内のすべてのリソースにアクセスできるようにするポリシーであることを確認します。
プリンシパルが dev-project 内のリソースにアクセスできるようにする新しいプリンシパルアクセス境界ポリシーを作成し、dev-project のプリンシパルセットに関連付けます。ポリシーバインディングで次の条件を使用して、ポリシーが dev-project-service-account に対してのみ適用されるようにします。
```
"condition": {
  "title": "Only dev-project-service-account",
  "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
}
```
プリンシパルが example.com 内のすべてのリソースにアクセスできるようにするプリンシパルアクセス境界ポリシーから dev-project-service-account を除外します。これを行うには、そのプリンシパルアクセス境界ポリシーを組織のプリンシパルセットに関連付けるポリシーバインディングに次の条件を追加します。
```
"condition": {
  "title": "Exempt dev-project-service-account",
  "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
}
```
既存のプリンシパルアクセス境界ポリシーを更新する方法については、プリンシパルアクセス境界ポリシーを編集するをご覧ください。

この条件をポリシーバインディングに追加すると、dev-project-service-account は example.com 内のすべてのリソースにアクセスすることはできなくなり、dev-project 内のリソースにのみアクセスできるようになります。

ポリシーの相互作用

IAM は、各プリンシパルアクセス境界ポリシーを許可ポリシー、拒否ポリシー、他のプリンシパルアクセス境界ポリシーと組み合わせて評価します。これらのポリシーはすべて、プリンシパルがリソースにアクセスできるかどうかを判断するために使用されます。

他のポリシータイプとの相互作用

プリンシパルがリソースにアクセスを試みると、IAM は関連するすべてのプリンシパルアクセス境界ポリシー、許可ポリシー、拒否ポリシーを評価し、プリンシパルがリソースにアクセスできるかどうかを確認します。これらのポリシーのいずれかで、プリンシパルがリソースにアクセスできないことが示されている場合、IAM はアクセスを拒否します。

そのため、プリンシパルアクセス境界ポリシーによってプリンシパルがリソースにアクセスできない場合、リソースに適用されている許可ポリシーと拒否ポリシーに関係なく、IAM はプリンシパルがそのリソースにアクセスできないようにします。

また、プリンシパルアクセス境界ポリシーだけでは、プリンシパルにリソースへのアクセス権が付与されません。プリンシパルアクセス境界ポリシーは、プリンシパルにリソースへのアクセスの資格を付与できますが、実際にプリンシパルにリソースへのアクセス権を付与できるのは許可ポリシーのみです。

IAM ポリシーの評価の詳細については、ポリシーの評価をご覧ください。

プリンシパルアクセス境界ポリシー間の相互作用

いずれかのプリンシパルアクセス境界ポリシーでリソースへのアクセスをプリンシパルに許可している場合、そのプリンシパルを対象とする他のプリンシパルアクセス境界ポリシーに関係なく、そのプリンシパルはそのリソースにアクセスできます。そのため、プリンシパルがすでにプリンシパルアクセス境界ポリシーの対象になっている場合、プリンシパルアクセス境界ポリシーを追加してそのプリンシパルのアクセスを制限することはできません。

たとえば、プリンシパル Dana（dana@example.com）が、1 つのプリンシパルアクセス境界ポリシー prod-projects-policy の対象であるとします。このポリシーにより、プリンシパルは prod-project 内のリソースにアクセスできるようになります。Dana は、組織のプリンシパルセットにバインドされているため、このポリシーの対象となります。

さらに、dev-project と staging-project のリソースにプリンシパルがアクセスできるようにする新しいプリンシパルアクセス境界ポリシー dev-staging-projects-policy を作成し、組織のプリンシパルセットにバインドします。

これらのプリンシパルアクセス境界ポリシーの結果、Dana は dev-project、staging-project、prod-project のリソースにアクセスできます。

ここで、Dana がアクセスできるリソースを減らすには、Dana を対象とするプリンシパルアクセス境界ポリシーを変更または削除する必要があります。

たとえば、プリンシパルが dev-project 内のリソースにアクセスできないように dev-staging-projects-policy を編集できます。この場合、Dana は staging-project と prod-project のリソースにのみアクセスできます。

また、prod-projects-policy を組織のプリンシパルセットにバインドするポリシーバインディングを削除して、このプリンシパルアクセス境界ポリシーを削除することもできます。この場合、Dana は dev-project と staging-project のリソースにのみアクセスできるようになります。

ただし、これらの変更は Dana にのみ影響するわけではありません。変更したプリンシパルアクセス境界ポリシーとポリシーバインディングの対象となる他のプリンシパルにも影響します。1 つの特定のプリンシパルがアクセスできるリソースを減らす場合は、条件付きポリシーバインディングを使用します。

ポリシーの継承

プリンシパルアクセス境界ポリシーは、Resource Manager リソースではなく、プリンシパルセットに適用されます。そのため、許可ポリシーや拒否ポリシーとは異なり、リソース階層を介して継承されません。

ただし、Resource Manager 親リソース（フォルダと組織）のプリンシパルセットには、常に子孫のリソースのプリンシパルセットが含まれます。たとえば、プリンシパルがプロジェクトのプリンシパルセットに含まれている場合、そのプリンシパルは親フォルダまたは組織のプリンシパルセットにも含まれます。

たとえば、example.com という組織について考えてみましょう。この組織はドメイン example.com に関連付けられており、次の Resource Manager リソースがあります。

example.com のリソース階層

組織 example.com
組織の子であるプロジェクト project-1
組織の子フォルダ folder-a
folder-a の子である 2 つのプロジェクト project-2 と project-3

これらのリソースのプリンシパルセットには、次の ID が含まれています。

プリンシパルセット	`example.com` ドメインの Google Workspace ID	`example.com` の Workforce Identity 連携プール	`project-1` のサービスアカウントと Workload Identity プール	`project-2` のサービスアカウントと Workload Identity プール	`project-3` のサービスアカウントと Workload Identity プール
`example.com` のプリンシパルセット
`folder-a` のプリンシパルセット
`project-1` のプリンシパルセット
`project-2` のプリンシパルセット
`project-3` のプリンシパルセット

その結果、次のプリンシパルは、次のプリンシパルアクセス境界ポリシーの影響を受けます。

example.com ドメインの Google Workspace ID は example.com のプリンシパルセットに属し、そのプリンシパルセットにバインドされたプリンシパルアクセス境界ポリシーの影響を受けます。
project-1 のサービスアカウントは、project-1 と example.com のプリンシパルセットに属しており、これらのプリンシパルセットのいずれかにバインドされたプリンシパルアクセス境界ポリシーの影響を受けます。
project-3 のサービスアカウントは、project-3、folder-a、example.com のプリンシパルセットに属しており、これらのプリンシパルセットのいずれかにバインドされているプリンシパルアクセス境界ポリシーの影響を受けます。

プリンシパルアクセス境界ポリシーとキャッシュに保存されたリソース

一部の Google Cloud サービスは、一般公開されているリソースをキャッシュに保存します。たとえば、Cloud Storage は一般公開で読み取り可能なオブジェクトをキャッシュに保存します。

プリンシパルアクセス境界で、権限のないプリンシパルが公開リソースを表示できないようにできるかどうかは、リソースがキャッシュに保存されているかどうかによって異なります。

リソースがキャッシュに保存されている場合、プリンシパルアクセス境界によってプリンシパルのリソース表示を防ぐことはできません。
リソースがキャッシュに保存されていない場合、プリンシパルアクセス境界により、資格のないプリンシパルによるリソースの表示を防ぐことができます。

いずれの場合も、プリンシパルアクセス境界ポリシーにより、資格のないプリンシパルによる一般公開リソースの変更または削除を防ぐことができます。

プリンシパルアクセス境界ポリシーの構造

プリンシパルアクセス境界ポリシーは、メタデータとプリンシパルアクセス境界ポリシーの詳細のコレクションです。メタデータには、ポリシー名やポリシーの作成日時などの情報が含まれます。ポリシーの詳細では、ポリシーの機能（影響を受けるプリンシパルがアクセスできるリソースなど）を定義します。

たとえば、次のプリンシパルアクセス境界ポリシーでは、ポリシーの対象となるプリンシパルが、ID 0123456789012 の組織内のリソースにアクセスできるようになります。

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

以降のセクションでは、プリンシパルアクセス境界ポリシーのメタデータと詳細のフィールドについて説明します。

メタデータ

プリンシパルアクセス境界ポリシーには次のメタデータが含まれます。

name: プリンシパルアクセス境界ポリシーの名前。この名前の形式は organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID です。ここで、ORGANIZATION_ID はプリンシパルアクセス境界ポリシーが作成された組織の数値 ID、PAB_POLICY_ID はプリンシパルアクセス境界ポリシーの英数字の ID です。
uid: プリンシパルアクセス境界ポリシーに割り当てられた一意の ID。
etag: ポリシーの現在の状態の ID。この値は、ポリシーを更新すると変更されます。更新の競合を回避するため、etag 値は IAM に保存されている値と一致させる必要があります。etag 値が一致しない場合、リクエストは失敗します。
displayName: 人が読める形式のプリンシパルアクセス境界ポリシーの名前。
annotations: 省略可。ユーザー定義の Key-Value ペアのリスト。これらのアノテーションを使用して、ポリシーにメタデータを追加できます。たとえば、ポリシーを作成したユーザーや、ポリシーが自動化されたパイプラインによってデプロイされたかどうかなどを追加できます。アノテーションの詳細については、アノテーションをご覧ください。
createTime: プリンシパルアクセス境界ポリシーの作成時間。
updateTime: プリンシパルアクセス境界ポリシーが最後に更新された時刻。

詳細

各プリンシパルアクセス境界ポリシーには details フィールドが含まれています。このフィールドは、プリンシパルアクセス境界ルールと適用バージョンを表します。

rules: プリンシパルアクセス境界ルールのリスト。影響を受けるプリンシパルがアクセスできるリソースを定義します。各ルールには次のフィールドが含まれます。
- description: 人が読める形式のルールの説明。
- resources: プリンシパルがアクセスできるようにする Resource Manager リソース（プロジェクト、フォルダ、組織）のリスト。このポリシーの対象となるプリンシパルは、これらのリソースにアクセスできます。
  
  各プリンシパルアクセス境界ポリシーは、ポリシー内のすべてのルールで最大 500 個のリソースを参照できます。
- effect: プリンシパルと resources フィールドにリストされているリソースの関係。プリンシパルアクセス境界ルールで指定できる効果は "ALLOW" のみです。この関係により、プリンシパルはルールにリストされているリソースにアクセスできるようになります。
enforcementVersion: IAM がポリシーの適用時に使用する適用バージョン。プリンシパルアクセス境界ポリシーのバージョンによって、プリンシパルアクセス境界ポリシーでブロックできる権限が決まります。

プリンシパルアクセス境界ポリシーのバージョンの詳細については、このページのプリンシパルアクセス境界の適用バージョンをご覧ください。

ポリシーバインディングの構造

プリンシパルアクセス境界ポリシーのポリシーバインディングには、ポリシーの名前、ポリシーをバインドするように設定されたプリンシパルの名前、ポリシーバインディングを記述するメタデータが含まれます。また、ポリシーが適用されるプリンシパルを変更する条件を含めることもできます。

たとえば、次のポリシーバインディングは、ID が 0123456789012 の example.com 組織内のすべてのプリンシパルにポリシー example-policy をバインドします。ポリシーバインディングには、プリンシパル super-admin@example.com にポリシーが適用されないようにする条件も含まれます。

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

各ポリシーバインディングには次のフィールドが含まれます。

name: ポリシーバインディングの名前。この名前の形式は RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID です。ここで、RESOURCE_TYPE/RESOURCE_ID はポリシーバインディングの親リソースのタイプと ID、BINDING_ID はポリシーバインディングの英数字の ID です。
uid: ポリシーバインディングに割り当てられた一意の ID。
etag: ポリシーの現在の状態の ID。この値は、ポリシーを更新すると変更されます。更新の競合を回避するため、etag 値は IAM に保存されている値と一致させる必要があります。etag 値が一致しない場合、リクエストは失敗します。
displayName: 人が読める形式のポリシーバインディングの名前。
annotations: 省略可。ユーザー定義の Key-Value ペアのリスト。これらのアノテーションを使用して、ポリシーバインディングにメタデータを追加できます。たとえば、ポリシーバインディングの作成者や、ポリシーバインディングが自動化パイプラインによってデプロイされたかどうかなどを追加できます。アノテーションの詳細については、アノテーションをご覧ください。
target: ポリシーをバインドするプリンシパル。値の形式は {"principalSet": PRINCIPAL_SET} です。ここで、PRINCIPAL_SET はポリシーをバインドするプリンシパルセットの ID です。

各ターゲットには、最大 10 個のポリシーをバインドできます。
policyKind: ポリシーバインディングが参照するポリシーのタイプ。プリンシパルアクセス境界ポリシーのポリシーバインディングの場合、この値は常に PRINCIPAL_ACCESS_BOUNDARY です。
policy: ターゲットプリンシパルセットにバインドするプリンシパルアクセス境界ポリシー。
policyUid: policy フィールドで参照されるプリンシパルアクセス境界ポリシーに割り当てられた一意の ID。
condition: 省略可。IAM がポリシーを適用するプリンシパルに影響する論理式。条件が true と評価されるか、評価できない場合、Identity and Access Management はリクエストを行ったプリンシパルのポリシーを適用します。条件が false と評価された場合、Identity and Access Management はプリンシパルのポリシーを適用しません。詳細については、このページのプリンシパルアクセス境界と条件をご覧ください。
createTime: ポリシーバインディングの作成時間。
updateTime: ポリシーバインディングが最後に更新された時間。

ユースケース

以下では、プリンシパルアクセス境界ポリシーを使用する一般的な状況と、それぞれの状況で作成するプリンシパルアクセス境界ポリシーとポリシーバインディングの例を示します。プリンシパルアクセス境界ポリシーを作成してプリンシパルセットにバインドする方法については、プリンシパルアクセス境界ポリシーを作成して適用するをご覧ください。

プリンシパルを組織内のリソースに制限する

プリンシパルアクセス境界ポリシーを使用すると、組織内のプリンシパルが組織内のリソースにのみアクセスできるようにすることができます。

たとえば、組織 example.com 内のすべてのプリンシパルが example.com 内のリソースにのみアクセスできるようにするとします。example.com 内のプリンシパルには、example.com ドメイン内の ID、example.com 内の Workforce Identity プール、example.com 内のプロジェクト内のサービスアカウントと Workload Identity プールがすべて含まれます。

組織内のプリンシパルに適用されるプリンシパルアクセス境界ポリシーはありません。その結果、すべてのプリンシパルがすべてのリソースにアクセスできるようになります。

プリンシパルが example.com 以外のリソースにアクセスできないようにするには、プリンシパルが example.com のリソースにアクセスできるようにするプリンシパルアクセス境界ポリシーを作成します。

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

次に、このポリシーをプリンシパルセットにバインドするポリシーバインディングを作成します。

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

これで、example.com 内のすべてのプリンシパルは、example.com 内のリソースにのみアクセスできるようになりました。これらのユーザーは、プリンシパルアクセス境界ポリシーによってブロックされている権限を使用して、example.com 外部のリソースにアクセスすることはできません。これらのリソースに対する権限が付与されていてもアクセスすることはできません。

サービスアカウントを 1 つのプロジェクトのリソースに制限する

プリンシパルアクセス境界ポリシーを使用すると、特定のプロジェクトのサービスアカウントがそのプロジェクト内のリソースにのみアクセスできるように制御できます。

たとえば、プロジェクト example-dev があるとします。example-dev のサービスアカウントが example-dev のリソースにのみアクセスできるようにします。

example-dev のサービスアカウントを含む、組織内のすべてのプリンシパルが example.com のリソースにアクセスできるようにするプリンシパルアクセス境界ポリシーがすでに存在します。このタイプのポリシーの詳細については、プリンシパルを組織内のリソースに制限するをご覧ください。

example-dev のサービスアカウントが example-dev 外のリソースにアクセスできないようにするには、まず、プリンシパルが example-dev のリソースにアクセスできるようにするプリンシパルアクセス境界ポリシーを作成します。

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

次に、このポリシーを example-dev のすべてのプリンシパルにバインドするポリシーバインディングを作成し、ポリシーバインディングがサービスアカウントにのみ適用されるように条件を追加します。

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

ただし、このポリシー自体では、サービスアカウントの利用資格を制限することはできません。これは、example.com 内のすべてのプリンシパルが example.com 内のすべてのリソースにアクセスできるようにするプリンシパルアクセス境界ポリシーがすでに存在するためです。プリンシパルアクセス境界ポリシーは累積的であるため、example-dev のサービスアカウントは引き続き example.com 内のすべてのリソースにアクセスできます。

example-dev のサービスアカウントが example-dev のリソースにのみアクセスできるようにするには、既存のプリンシパルアクセス境界ポリシーのポリシーバインディングに条件を追加して、example-dev のサービスアカウントに適用されないようにする必要があります。

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

これで、example-dev のサービスアカウントは、example-dev のリソースにのみアクセスできるようになりました。これらのユーザーは、プリンシパルアクセス境界ポリシーによってブロックされている権限を使用して、example-dev 外部のリソースにアクセスすることはできません。これらのリソースに対する権限が付与されていてもアクセスすることはできません。

次のステップ

プリンシパルアクセス境界ポリシーを作成して適用する方法を学習する。
プリンシパルアクセス境界ポリシーの適用バージョンがブロックする権限を確認する。

プリンシパル アクセス境界ポリシー

プリンシパル アクセス境界ポリシーの仕組み

フェイルオープンの評価

プリンシパル アクセス境界ポリシーによってブロックされる権限

プリンシパル アクセス境界の適用バージョン

プリンシパル アクセス境界ポリシーをプリンシパル セットにバインドする

サポートされているプリンシパル セット

プリンシパル アクセス境界ポリシーの条件付きポリシー バインディング