G-genの福井です。Google Cloud の IAM の一機能であるプリンシパルアクセス境界ポリシー （Principal access boundary）を用いたリソースへのアクセス制御について解説します。

概要

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

プリンシパルアクセス境界ポリシー （Principal access boundary policies、以下 PAB ポリシー）とは、Google アカウントがアクセスできる Google Cloud リソースを、特定の Google Cloud 組織のリソースだけに制限するなどの強力なコントロールを実現するための仕組みです。PAB ポリシーによるアクセスのブロックは、IAM の許可ポリシーよりも優先されます。

PAB の設定は、プリンシパル（Google Cloud APIs の実行主体）に対して紐づけます。たとえばある Google Workspace 組織の全アカウントに対して PAB ポリシーを紐づけたり、あるいは特定プロジェクトに所属するサービスアカウントにポリシー紐づけたりすることができます。2025年1月現在、ポリシーを適用する対象として Google グループを指定することはできません。

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

アクセス可否の評価

プリンシパルが Google Cloud リソースにアクセスを試みる際、IAM は「許可ポリシー」、「拒否ポリシー」、そして「PAB ポリシー」をすべて評価して、アクセスを許可するか拒否するかを決定します。

これら3つのポリシーがすべて評価され、いずれかのポリシーでアクセスが拒否されている場合は、IAM はアクセスを拒否します。

以下は、評価のロジックをフロー図化したものです。当社の解釈によるものであり、実際の内部的な評価順序と一致していない可能性がある点にはご留意ください。

Google Cloud では、すべてのリソースへのアクセスはデフォルトで拒否されます。

アクセスの許可を設定できるのは、3つのポリシーの中では「許可ポリシー」だけです。またアクセス拒否を設定できるのは、「拒否ポリシー」と「PAB ポリシー」の2つです。

よって、プリンシパルがリソースにアクセスできるようにするには、「許可ポリシー」が必須です。ここで許可されたアクセスに対して、「拒否ポリシー」や「PAB ポリシー」がアクセスの拒否を追加する形になります。

上記フローのとおり、プリンシパルに複数の PAB ポリシーが紐づけられている場合、（アクセスが許可ポリシーで許可されており、また拒否ポリシーで拒否されていない前提で）いずれか1つの PAB ポリシーでアクセスが許可されていれば、アクセスは最終的に許可されます。これを「PAB ポリシーの評価は累積的である」といいます。すなわち、ある PAB ポリシーでアクセスを許可している場合、別の PAB ポリシーでアクセスの禁止をすることはできません。

ユースケース

複数の組織や複数のプロジェクトを利用している会社等では、従業員が自社組織外の Google Cloud リソースにアクセスできてしまうリスクを抑えたいケースが存在します。

しかしながら Google Cloud の IAM（Identity and Access Management）では通常、「許可ポリシー」と「拒否ポリシー」の2つを組み合わせてアクセス制御を行います。他の Google Cloud 組織において Google アカウントに IAM 権限が付与されてしまった場合、これらのポリシーだけでは他組織のクラウドリソースに対するアクセスを制限することはできません。このような場合に、PAB ポリシーが利用できます。

参考 : これで分かった！Google CloudのIAMの仕組みやAWSとの違い - IAM の仕組み - G-gen Tech Blog

PAB ポリシーを利用することで、例として以下のようなメリットを享受することができます。

メリット	説明
データ流出の抑止	他組織のリソースや不要なプロジェクトへのアクセスを一律に制限できるため、データの流出やフィッシング攻撃などのリスクの低減を期待できます。
既存の IAM ポリシーの上書き	たとえ許可ポリシーで権限を付与していても PAB ポリシーが優先されるため、強い強制力でリソースへのアクセスをブロックできます。

PAB ポリシーの構造

ポリシーの例

以下は、公式ドキュメントから引用した PAB ポリシーの例です。以下は JSON 形式で表記されていますが、Google Cloud コンソールでポリシーを作成、編集する場合、コンソールにはわかりやすく表示されます。ここではポリシーの構造の理解のために、JSON 形式で表記します。

{
  "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"
  }
}

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

ルール（rules）

ルール（rules）は、「どのリソースに対してアクセスが許可されるか」をリストアップしたものです。

前掲の例にある "resources": [ "//cloudresourcemanager.googleapis.com/organizations/0123456789012" ] のように、組織やフォルダ、プロジェクトを指定します。

"effect" には "ALLOW"（許可）のみが指定できます。

なお、PAB ポリシーが複数存在する場合、その評価は累積的です。すなわち、すでにある PAB ポリシーでアクセスを許可している場合、別の PAB ポリシーでアクセスの禁止をすることはできません。

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

適用バージョン（enforcementVersion）

適用バージョン（enforcementVersion）は、PAB ポリシーがブロックできる権限のセットが定義されたバージョン番号です。

これは PAB ポリシー機能自体のバージョンを示しています。機能は Google により随時アップデートされており、バージョンが上がるたびに PAB がサポートする（ブロックできる）権限の範囲が広がります。値に latest を指定することで常に最新バージョンを使うことも可能ですが、これまで行使できていた権限が予期せずブロックされるリスクがあります。

ポリシーバインディング

PAB ポリシーをどのプリンシパルに対して適用するかを定義する設定を、ポリシーバインディングといいます。PAB ポリシーとプリンシパルを紐づける設定であるため、前掲の PAB ポリシーの JSON 中には含まれておらず、別の設定オブジェクトです。

ポリシーバインディングでは適用ターゲットとして、組織ドメインに所属するすべてのアカウントや、特定プロジェクトに所属するサービスアカウントなどを指定することができます。また、Workforce Identity プールや Workload Identity プールを指定することができます。2025年1月現在、Google グループをターゲットとして指定することはできません。

ポリシーバインディングでは条件式（condition）で細かな条件付けを行い、特定のユーザーを除外するといった制御が可能です。

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

設定手順

概要

Google Cloud コンソールで PAB ポリシーを設定する手順をご紹介します。

この手順では、自らの組織外のリソースへのアクセスを禁止し、自組織配下のリソースのみアクセスを許可します。

必要な権限

この手順を行うには、操作者の Google アカウントに以下の IAM ロールが必要です。

組織に対する、プリンシパルアクセス境界管理者 (roles/iam.principalAccessBoundaryAdmin)
組織に対する、Workspace プール IAM 管理者 (roles/iam.workspacePoolAdmin)

なお設定する制限によって必要とする IAM ロールは異なります。詳細は以下の公式ドキュメントをご参照ください。

参考 : プリンシパルアクセス境界ポリシーの適用に必要なロール

事前確認

Google Workspace ドメインに属するユーザーアカウントに対して、別組織（別ドメイン）の Cloud Storage バケットに対する閲覧権限をあらかじめ与えておきました。

PAB ポリシー適用前は以下のように、Cloud Storage バケット内のファイル一覧が表示されています。ポリシー適用後は、アクセスできなくなることが期待されます。

ポリシーを作成

PAB 画面へ遷移

Google Cloud コンソールのリソースとして組織を選択し、メニューの「IAMと管理」＞「プリンシパルアクセス境界」を押下します。この画面の「ポリシーを作成」を押下すると、ポリシーの新規作成画面が表示されます。

境界ルールを追加

「どのリソースに対するアクセスを許可するか」を設定します。リソースに設定できる値は「組織」「フォルダ」「プロジェクト」のいずれかです。

ポリシー名と適用バージョンを設定

表示名と適用バージョンを設定し「作成」を押下します。表示名を入力すると、ポリシー ID が自動で生成されるため、必要に応じて変更します。

ポリシーバインディング

バインディング追加画面へ遷移

Google Cloud コンソールメニューの「IAMと管理」＞「プリンシパルアクセス境界」＞「作成したポリシー」を押下します。

「バインディングを追加」を押下すると、バインディング追加画面が表示されます。

バインディングを追加

「どのプリンシパルに、どの PAB ポリシーを適用するか」を設定します。表示名、バインディング ID、ターゲットプリンシパルセットを設定して「追加」を押下します。

ここではプリンシパルセットとして「Workspace プール ID」を指定したため、指定された Google Workspace ドメイン内のすべての ID が制限の対象となります。

なおこの ID は組織の顧客 ID と呼ばれる英数字です。通常、C01abc123 のような形式です。顧客 ID の調べ方は、以下の記事を参照してください。

blog.g-gen.co.jp

その他のプリンシパルセットの ID の形式等は、以下のドキュメントを参照してください。

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

動作確認

ポリシー適用後は、Cloud Storage バケットへアクセスした際に以下のようなエラーが表示され、ファイル一覧が表示されないようになりました。

test@g-gen.co.jp does not have storage.objects.list access to the Google Cloud Storage bucket. Operations on resource are denied due to an IAM Principal Access Boundary Policy. test@g-gen.co.jp does not have storage.objects.list access to the Google Cloud Storage bucket. Operations on resource are denied due to an IAM Principal Access Boundary Policy.