条件付きの寛大さ: Google Cloud のアクセス管理の強化

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

Google Cloud において、Identity and Access Management（IAM）はクラウドのリソースやオペレーションに対するアクセス制御を維持するのに役立ちます。他の機能も含まれますが、これが主な目的です。アプリケーションのセキュリティを強化しようとしたことがある方なら、最小権限の原則（PoLP）の重要性をご存知でしょう。ユーザーとワークロードにタスクの実行を許可するために、最小限の権限を付与するという原則です。事前定義ロールとカスタムロールを使用し、プロジェクト、フォルダ、組織のレベルで 許可と拒否の IAM ポリシーを組み合わせて設定することで実現できます。リソース階層で許可ポリシーと拒否ポリシーを組み合わせて使用すると、アクセスを効果的に制御できます。このアプローチにより、さまざまなシナリオで PoLP を適用できます。

しかし、プロジェクト内のリソースが複数のワークロードで共有されていたり、複数のチームで使われていたりすると、既存の柔軟な制御だけでは不十分な場合があります。このようなシナリオの多くでは、IAM ポリシーをプロジェクト内の特定のリソースにバインドすることが可能です。たとえば、プロジェクトで Artifact Registry 編集者（roles/artifactregistry.editor）ロールを付与する場合と、プロジェクト内の特定のリポジトリで付与する場合の違いを考えてみましょう。前者の場合、プロジェクト内のあらゆるリポジトリへのアクセス権が付与されます。後者の場合、ユーザーは特定のリポジトリに対する編集者アクセス権のみを持ちます。ただし、IAM ポリシーをリソースレベルやサービスレベルに常にバインドできるとは限りません。このような場合に、IAM の条件を使用します。アクセス管理を堅牢化する際、条件がいかに強力に機能するか、2 つの異なる例で見てみましょう。1 つは従来の管理者ロール、もう 1 つは最新の AI インテグレーションの例です。

ユースケース 1: 管理者の権限を制限する

このケースでは、広範な IAM ロールに許可されている特定のオペレーションを制限する方法を示します。プロジェクト レベルで「リソース作成者」ロールを付与し、選択したリソースで編集者ロールを付与すれば、プロジェクト内の特定のリソースを管理するための管理者権限のスコープを簡単に設定できます。しかし、特定のリソースではなく、オペレーションへのアクセス権を付与することを目的とした IAM 管理者ロールを制限するのは、はるかに困難です。代表的な例としては、IAM 管理者ロール（roles/iam.admin）があります。このロールを付与されたユーザーは、他のロールを自分に付与したり、新しいロールを作成したりできます。これは実際のニーズを大幅に超えています。最初のステップとしては、プロジェクト レベルでのみ管理者権限を提供するプロジェクト IAM 管理者ロール（roles/resourcemanager.projectIamAdmin）を使用してアクセスを絞り込むことです。

さらに、付与する権限をより細かく制限することも可能です。たとえば、リソースを作成してワークロードをデプロイするビルダー サービス アカウントにプロジェクト IAM 管理者ロールを付与するとします。ワークロードに必要なのは、BigQuery API と Agent Platform API（旧称 Vertex API）へのアクセス、およびログとトレースを書き込む権限のみです。このような場合は、次の gcloud CLI コマンドまたは Terraform の代替コマンドを使用できます。

condition パラメータの値は、Common Expression Language（CEL）構文を使用して定義されます。まず、フィールド区切り文字をカンマではなくコロンにカスタマイズしてから、条件フィールド title と expression を記述します。expression フィールドでは、API 属性の関数を使用して、付与されるロールを特定し、カンマ区切りのリストにあるロールのみを付与できるようにします。Terraform で同じ操作を行う場合も、ほぼ同じようになります。環境変数ではなく入力変数を使用すると、次のようになります。

ユースケース 2: MCP サーバーへのアクセスを制御する

このケースでは、単一の権限セットの背後にある特定のサービスへのアクセスを強化します。

Google は、Model Context Protocol（MCP）エンドポイントを公開する MCP サーバーを介して、クラウド リソースとサービスのサブセットへのアクセスを公開しています。これらのサーバーへのアクセスは、事前定義された MCP ツールユーザー（roles/mcp.toolUser）ロールを使用して付与されます。このロールは、利用可能な すべての MCP サーバー（IAM ポリシーが設定されているプロジェクトの場合）へのアクセスを許可します。条件を使用すると、特定の MCP サーバーへのアクセスを絞り込むことができます。

resource.service 属性と比較される値は、MCP サーバー エンドポイント（bigquery.googleapis.com/mcp）ではなく、サービスの エンドポイントであることに注意してください。アクセス スコープを特定の MCP ツールレベルまでさらに絞り込むことも可能です。そのためには、API 属性を再度使用する必要があります。次の式は、サービス アカウントのアクセスを 2 つの BigQuery MCP ツールのみのレベルに制限します。

MCP ツールレベルで IAM ポリシー バインディングを条件付けする場合は、resource.service 属性を検証する必要はありません。

MCP サーバーへのアクセスを試すには、「Google MCP サーバーを使ってみる」Codelab を使用し、その gcloud projects add-iam-policy-binding コマンドを変更します。

さらなる活用例

事前定義ロールを使用する際の精密な制御に加えて、IAM 条件を使用すると「リクエストの時刻」に基づいたアクセス管理を構築することも可能です。たとえば、以下の条件式は平日の日中のみアクセスを許可します。

この式は、「Europe/Berlin」タイムゾーンに従って、月曜日から金曜日（曜日は日曜日を 0 とする 0〜6 の範囲）の午前 9 時から午後 5 時までのアクセスに制限します。

IAM 条件を使用すると、プリンシパル属性を使用してアクターの ID を制御できます。ただし、これはアンチパターンになりやすいため注意が必要です。推奨される方法は、条件を使用するのではなく、IAM ポリシーのプリンシパルのリストを通じて、ポリシーの使用を許可するアクターの ID を制御することです。

まとめとその他のリソース

IAM 条件は許可ポリシーに対して精密な制御を提供しますが、IAM 拒否ポリシーを活用することで、多層防御戦略をさらに進めることができます。拒否ポリシーを使用すると、許可ポリシーを持つ事前定義 IAM ロールでアクセス権を付与しつつ、そのロールの過剰な権限を削ぎ落として PoLP を適用できます。拒否ポリシーの詳細については、以下のリソースをご覧ください。

• 拒否ポリシーでサポートされる権限を確認する。

• 拒否ポリシーのプリンシパル ID の形式を取得する。

• 拒否ポリシーに関するアクセス問題のトラブルシューティング方法を確認する。

• プリンシパルへのアクセスの拒否について学習する。

• 多層防御の構築に関するブログ投稿を読む。

Google Skills を使用して、IAM ポリシーを実際に体験できます。

- シニア デベロッパーリレーションズ エンジニア、Leonid Yankulin