【Google Cloudでセキュリティの柱を築く】PAB(プリンシパルアクセス境界ポリシー)を構成する
こんにちは山下です。
GoogleCloud環境に@gmail.comのような個人アカウントや業務委託などで別ドメインのアカウントにロールバインドしないための対策は充実しています。例えば組織ポリシーで特定のGoogleアカウント(CloudIdentity)に制限したりといったことが可能です。
これによって自分の管理する組織やプロジェクトに権限を勝手に付与する事が出来ないため、ゼロトラスト対策が可能になります。
しかし、自分のドメイン組織内のサービスアカウントやGoogleアカウントに対して、別組織のGoogleCloud環境でロールバインドをすることはできてしまいます。
これを悪用して以下のように組織(ドメイン)のサービスアカウントやGoogleアカウントを勝手に別の組織や個人のプロジェクト、さらにはGWSに対して権限付与を行えてしまいます。勿論、勝手に権限を付与するだけなので認証情報が盗られる訳ではなく直ちに影響はありません。
ただ、以下の例にあるようにCloudRunのサービスアカウントを別組織に招待(＝ロールバインド)することで自身のCloudStorage内のオブジェクトをダウンロードして、そのオブジェクトを別組織のオブジェクトに書き込むといった制御が行えてしまいます。つまり、悪意のある内部者が個人のGoogleCloudプロジェクトにデータを持ち出すといった操作がこれで可能になってしまいます。
VPC Service Controlsで境界を組織レベルで設定し、Egress(外向き)通信で別組織のCloudStorage APIにアクセスできるよう明示的に許可設定を入れないと通信できなくすることで保護する事は可能です。とはいえ、好き放題サービスアカウントやGoogleアカウントが別組織で権限付与されるのは統制上望ましい状態ではありません。
これを解消できるのが**プリンシパルアクセス境界ポリシー(通称PAB)**です。プリンシパル（アクセス主体、つまりユーザーやサービスアカウントなど）がアクセスできるリソースの範囲を定義します。PABポリシーを適用することで、このアクセス範囲を意図的に狭めることができます。
PABとは？
Googleアカウントとサービスアカウントはデフォルトでは、IAMで許可されていれば組織内外のあらゆるGoogle Cloudリソースにアクセスできます。そのため、自分達の管理していないGoogle Cloudリソースに対して最小権限の原則を効かせることはできませんでした。
プリンシパル アクセス境界ポリシー(PABポリシー)を使用するとGoogleアカウントまたはサービスアカウントがアクセスできるリソースを定義できます。プリンシパル アクセス境界ポリシーによってプリンシパルがリソースにアクセスできなくなった場合、付与されたロールに関係なく、そのリソースへのアクセスが制限されます。
つまり、ロールバインド自体を防ぐのではなく、認可(＝権限の行使)を行おうとしたタイミングでブロックとなります。ですので、事前予防策ではなく事後の検出/ブロック策となります。
ただし、ドキュメントにもある通り、全ての権限をブロックできる訳ではありません。この辺りはVPC Service Controlsや組織ポリシーと同じでAPIや権限が常に更新されているためです。また、2025年7月現在ではそこまで多くのサービスをサポートしていません・・・。しかしながら冒頭に記載の通り、ユースケースとして恐ろしいのはデータの漏洩です。そういう点では主要なところを押さえてはいます。
[サポートされている権限] ※2025年7月時点
- アクセス承認
- AccessContextManager
- BigQuery
- BinaryAuthorization
- CloudLogging
- CloudRun
- CloudStorage
- Dataflow
- Datastore
- Firebaseセキュリティルール
- GKE Hub
- Pub/Sub
- Memorystore for Redis
- Vertex AI
PABを実際に適用してみる
PABポリシーは”IAMと管理”より選択できます。前提として組織レベルでこちらを設定する必要があります。”ポリシーを作成”を選択し、ポリシー名とバージョンを指定します。
※バージョンはPABポリシーでサポートされているブロックする権限が追加されるたびに更新されます。Latestとする事でサポートする権限を常に全てにはできますが、権限の増減があるため外部組織(ドメイン)と連携していた場合に思わぬ影響が生じます。個人的にはGoogleアカウントはLatestとしてサービスアカウントなどワークロードが利用するものには特定のバージョン適用が安全と考えています。
ポリシーをただ追加しただけなので、プリンシパルをまだ設定していません。これを設定するために境界ルールとバインディングを追加します。
境界ルールはアクセス出来る範囲を指定するものです。この操作を行うアカウントが権限を持つ組織/フォルダ/プロジェクトを境界に指定することが出来ます。これは許可ルールなので、どこまでアクセスしてもいいかを設定するのと同義です。
バインディングは境界ルールで許可したリソース(組織/フォルダ/プロジェクト)に対してどのプリンシパルがアクセスするのかを指定するものです。
任意のIDを付与しターゲットプリンシパルを設定していきます。ターゲットプリンシパルはプリンシパル(≒認証ID)の払い出し元を指定すると読み替えるのがよいかと思います。
例えばサービスアカウントはフォルダ/プロジェクト単位で発行されるもののため、特定のフォルダ/プロジェクトのサービスアカウントに境界を儲けたい場合はフォルダ/プロジェクトのいずれかを指定します。また、GKE PodのようなワークロードはWorkload Identityプール、GoogleアカウントはGoogle Workspaceといった具合になります。ちなみに組織は全てを包含しています。
ターゲットプリンシパルは見ての通り、IDの払い出し元単位で設定するもののため、特定のサービスアカウントにだけ指定するといった細かい制御を行うためには条件をつける事で指定することもできます。
最後に”変更内容をテスト”を設定することでバインディングと境界ルールの組み合わせを元に権限の行使が拒否されるかを試験できます。過去90日に遡って、バインディングに指定されたプリンシパルが境界ルール外のリソースにアクセスしていないかをチェックできます。
ここで影響範囲を特定して、例えばSaaS連携で別の境界にアクセスする場合に境界ルールを変えることが可能です。
まとめ
プリンシパルアクセス境界ポリシーによって自分のドメイン組織内のプリンシパルが外部の組織やプロジェクトにアクセスすることを制限できるようになります。
これにより、認可のタイミングでブロックがかかり、データ漏洩リスクを低減できます。特に主要なサービスでは効果的な対策となり、ゼロトラスト環境の構築に役立ちます。サポートされる権限の増加であったり、AIエージェントが増えゆく世界でNon Human Identity統制の一つの選択肢として広がっていくことを期待しております。
Discussion