拒否する力: IAM の拒否ポリシーと組織のポリシーで多層防御を構築

※この投稿は米国時間 2025 年 6 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

昨今のクラウドを取り巻く環境で自社のクラウド環境を保護するには、許可ポリシーと最小権限の原則のほかに、Identity and Access Management（IAM）アプローチを強化する必要があります。防御を強化するために、Google は強力なツールである IAM 拒否ポリシーを提供しています。

IAM 許可ポリシーのみを使用すると必要以上の権限が付与される可能性があり、権限レベルの制限をセキュリティ チームが一貫性を持って大規模に適用することが困難になります。そこで役立つのが IAM 拒否です。

IAM 拒否は、プリンシパルが、割り当てられたロールに関係なく実行できない操作を明示的に定義できる、重要かつスケーラブルなセキュリティ レイヤを提供します。この予防的なアプローチは、不正アクセスを防止し、全体的なセキュリティ ポスチャーを強化するのに役立ちます。また、管理チームは、ガードレールに関するポリシーを環境全体でオーバーライドできるようになります。

IAM 拒否について

IAM 拒否の基盤は、IAM 許可ポリシーの上に構築されています。許可ポリシーは、Google Cloud 組織内で誰が、どんな操作を、何に対して実行できるかを定義し、プリンシパル（ユーザー、グループ、サービス アカウント）を、さまざまなレベル（組織、フォルダ、プロジェクト、リソース）のリソースへのアクセス権を含むロールにバインドします。

一方、IAM 拒否は制限を定義します。バインディングは、プリンシパルも対象となりますが、リソースレベルではなく組織、フォルダ、プロジェクトのレベルで実行されます。

許可ポリシーと拒否ポリシーの主な違い:

• IAM 許可: ロール バインディングにより、プリンシパルに権限を付与します。

• IAM 拒否: IAM 許可によって実行されたロール バインディングを、階層レベルでオーバーライドして権限を制限します。

IAM 拒否は Google Cloud 環境のガードレールとして機能し、管理者権限の管理の一元化や、必要なカスタムロールの数の削減に役立つほか、最終的には組織のセキュリティを強化します。

IAM 拒否の仕組み

IAM 拒否ポリシーでは、制限を適用するために、いくつかの主要コンポーネントが使用されます。

• 拒否されたプリンシパル（誰が）: 制限の適用対象となるユーザー、グループ、またはサービス アカウント。組織内の「全員」や、組織に関係なくすべてのプリンシパル（allUsers 識別子で示される）も指定できます。

• 拒否する権限（どんな操作を）: 拒否されたプリンシパルが使用できない特定の操作または権限。IAM 拒否は、ほとんどの Google Cloud サービスでサポートされていますが、新しいサービスについてはサポート状況を確認することが重要です。

• アタッチメント ポイント（何に対して）: 拒否ポリシーの適用対象となる組織、フォルダ、プロジェクト。拒否ポリシーは、個々のリソースに直接アタッチできません。

• 条件（適用方法）: これは省略可能ですが、拒否ポリシーの適用時に、適用方法をより細かく管理できます。条件は、Common Expression Language（CEL）を使用してリソースタグで設定します。こうして、拒否ポリシーを条件付き（例: 特定の環境に限定する、特定のタグが存在しない場合）で適用できます。

IAM 拒否が優先される

IAM 拒否で重要な点は、評価の順序です。拒否ポリシーは、許可ポリシーよりも先に評価されます。プリンシパルの操作に拒否ポリシーが適用されると、プリンシパルが持つロールに関係なく、そのリクエストは明示的に拒否されます。拒否ポリシーが適用されないことが確認されてから、許可ポリシーが評価され、操作を許可するかどうかが判断されます。

ただし、このルールに対して例外を構成する手段が組み込まれています。拒否ポリシーでは、特定の制限から除外されるプリンシパルを指定できます。これにより、特定の管理者アカウントやブレークグラス（非常時用）アカウントに必要な操作を許可する柔軟性が得られます。

IAM 拒否を使用する場合

IAM 拒否ポリシーを使用すると、一般的なセキュリティ ガードレールを実装できます。たとえば、次が挙げられます。

• 高い権限のアクセス許可の制限: 開発環境で、開発者が IAM ロールの作成や管理、組織のポリシーの変更、機密性の高い課金情報へのアクセスを行えないようにします。

• 組織標準の適用: いずれのロールでも使用できないように権限のセットを制限することで、過剰な権限を持つ基本ロールの誤用を防いだり、特定のフォルダで Google Cloud サービスを有効にする機能を制限したりできます。

• セキュリティ プロファイルの導入: 職務分掌を徹底するために、さまざまなチーム（課金、ネットワーキング、セキュリティなど）に対して拒否する権限のセットを定義します。

• タグ付きリソースの保護: 組織レベルの拒否ポリシーを、特定のタグ（iam_deny=enabled など）が付けられたリソースに適用します。

• フォルダレベルの制限の適用: 特定のフォルダ内の、タグが付いていないリソースに対して、広範なカテゴリの権限（課金、ネットワーキング、セキュリティなど）を拒否します。

補完的なセキュリティ レイヤ

IAM 拒否は、他のセキュリティ管理と組み合わせて使用すると最も効果的です。Google Cloud には、IAM の拒否を補完するツールがいくつか用意されています。

• 組織のポリシー: リソース使用量の制限に関するポリシーを使用して、組織で利用できる API を制限するなど、Google Cloud 階層全体で組織の制限を一元的に構成および管理できます。IAM のカスタム制約を定義して、許可するロールを制限することもできます。

• Policy Troubleshooter: プリンシパルがリソースにアクセスできる理由や、アクセスが拒否された理由を把握できます。許可ポリシーと拒否ポリシーの両方を分析して、アクセス結果の正確な理由を特定できます。

• Policy Simulator: 拒否ポリシーの変更による影響を、ライブ環境に適用する前にシミュレートできます。中断が発生する可能性を特定し、ポリシーを改善するのに役立ちます。現在、拒否シミュレータをプレビュー版でご利用いただけます。

• IAM Recommender: 適用された IAM 権限を ML を使用して分析し、過剰な権限が付与されたロールの割り当てを削減するための推奨事項を提供します。真の最小権限を実現できます。

• Privileged Access Manager（PAM）: 拒否ポリシーの例外が必要となったプリンシパルに対する、一時的に昇格されたジャストインタイムのアクセス権を管理できます。PAM ソリューションでは、ブレークグラス アカウントやその他の特権アクセス シナリオの監査と管理を行えます。

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

Terraform を使用した IAM 拒否の実装

提供されている GitHub リポジトリには、IAM 拒否と組織のポリシーの実装を開始するのに役立つ Terraform 構成が含まれています。この構成には、次のものが含まれます。

• タグ付きリソースの特定の管理者権限を対象とした、組織レベルの IAM 拒否ポリシー。

• タグ付けされていないリソースに対する、課金、ネットワーキング、セキュリティの権限を制限するフォルダレベルの IAM 拒否ポリシー。

• ロールやオーナーロールの使用を禁止するカスタムの組織ポリシー制約。

• 指定されたフォルダ内での、特定の Google Cloud サービスの使用を制限する組織のポリシー。

Terraform 構成を使用する主な手順:

1. リポジトリのクローンを作成します。

2. examples/iam-deny フォルダに移動し、Terraform ディレクトリに切り替えます。

3. terraform.tfvars を準備します。terraform.tfvars.example を terraform.tfvars にコピーし、組織 ID、ターゲット フォルダ ID、例外用のプリンシパル グループのメールを追加して編集します。

4. 組織でタグキーとタグ値を作成し、これらのポリシーを有効にします。

1. 任意の名前を指定できますが、この例ではタグキー（iamdeny）とタグ値（enabled）を使用します。

5. main.tf のタグ ID を更新します。各ポリシーの denial_condition セクション内で、プレースホルダのタグキー ID とタグ値 ID を、実際のタグ ID に置き換えます。

a. 注: これは省略可能です。この式は、ポリシーの適用時にすべてのリソースを拒否するために使用することもできます。

billing.json、networking.json、securitycenter.json（/terraform/profiles/ ディレクトリにあります）などのファイルと denied_perms.tf ファイルで、事前定義済みの拒否された権限を確認し、組織のセキュリティ要件に合わせてください。

6. Terraform を初期化、確認、適用します。

これらのポリシーをデプロイする前に、必ずセキュリティ チームに相談するようにしてください。

拒否する力を活用する

IAM はセキュリティ強化の重要な要素であり、その戦略的な実装は包括的な多層防御戦略の鍵となります（IAM の利用を開始する方法について詳しくは、IAM ガイド「IAM が大嫌い（だけど、どうしても必要）」および「IAM の山を登る: 詳細ガイド」をご覧ください）。

IAM 拒否ポリシーの実装は、Google Cloud のセキュリティ ポスチャーを強化するうえで重要なステップです。プリンシパルが実行できない操作を明示的に定義すれば、偶発的な構成ミスや悪意のある行為者の両方に対する強力な防御レイヤを実現できます。

IAM 拒否ポリシーを、組織のポリシー、Policy Troubleshooter、Policy Simulator、IAM Recommender と組み合わせることで、最小権限をより効果的に実現し、より安全なクラウド環境を構築できます。提供されている Terraform の例をご覧になり、Google Cloud のセキュリティ戦略における拒否する力を実感してください。

このコンテンツは、Google Cloud コンサルティングが Google Cloud を利用するお客様企業と協力して得た知見に基づいて作成されました。Google Cloud の取り組みを、最適な専門家やイノベーターとともに加速させたいとお考えの場合、Google Cloud コンサルティングまでお問い合わせください。

ー クラウド インフラストラクチャ エンジニア、Kevin Schmidt