みなさん、こんにちは！

1. はじめに

クラウド全体のセキュリティガバナンスを高める際、特定の強力な権限をシステム全体で一律で制限したい場面があります。通常のIAM（許可ポリシー）だけでは、プロジェクトごとに個別にロールが付与されてしまった場合に、管理者が意図しないすり抜けが発生するリスクがあります。

先日、社内の検証環境において「コストの跳ね上がりを防ぐために、特定の高額サービスの作成を確実に禁止したい」という要件があり、GCPの「拒否ポリシー」を導入しました。非常に強力かつ便利だったため、その具体的な設定方法を共有します。

この記事では、GCPの「拒否ポリシー」の概要から、具体的なJSONの書き方、そして本番導入時の注意点までを分かりやすく解説します。

2. GCPの「拒否ポリシー」とは？

基本概念

GCPの拒否ポリシー（Deny Policies）とは、通常のIAMによる「許可（Allow）」とは異なり、特定のプリンシパル（ユーザーやグループ）に対して、特定の操作を明示的に禁止するための仕組みです。

許可ポリシーとの関係

GCPのセキュリティ原則において、「拒否はすべての許可に優先する」という絶対的な基本ルールがあります。

通常のIAMでどれだけ強い権限（たとえば「プロジェクトのオーナー（Owner）」や「ストレージ管理者」など）を付与されていたとしても、拒否ポリシーにその操作が指定されていれば、一発でリクエストがブロックされます。一時的な組織変更や権限の付与ミスがあっても、絶対に突破させない「強力なガードレール」として機能するのが特徴です。

3. 拒否ポリシーの具体的な書き方

JSONの実装例

拒否ポリシーは以下のようなJSONファイルで定義します。今回は特定の検証用ユーザーを対象に、高額になりやすい操作や閲覧を制限する設定ファイル（TEST_Deny_Policy.json）を準備しました。

JSON
{
  "displayName": "TEST_Deny_Policy",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principal://goog/subject/[対象プリンシパル]"
        ],
        "deniedPermissions": [
          "compute.googleapis.com/instances.create"
        ]
      }
    }
  ]
}

拒否ポリシーを記述する際は、以下の3つの必須要素を正しく指定する必要があります。

deniedPrincipals（誰を）: 拒否の対象となるユーザーやグループ、サービスアカウントを指定します。
deniedPermissions（どの操作を）: 禁止したい具体的なAPIの権限（Permission）をリスト形式で指定します。
deniedResources（どこで）: ポリシーが適用されるリソースの範囲（※今回のgcloud適用コマンド時にアタッチメントポイントとして指定します）。

適用コマンド

作成したJSONファイルを使って、gcloud コマンドでGCP環境に反映させます。なお、設定を実行するユーザーには拒否管理者（roles/iam.denyAdmin）ロールが必要です。

Cloud Shellなどの適当なディレクトリに準備したファイルをアップロードし、以下のコマンドを実行します。

Bash
gcloud iam policies create test-deny-policy \
    --attachment-point="cloudresourcemanager.googleapis.com/projects/[対象プロジェクト]" \
    --kind="denyPolicies" \
    --policy-file="TEST_Deny_Policy.json"

[補足]
組織レベルに適用する場合は、--attachment-point を organizations/【組織ID】に変更してください。

4. 【超重要】拒否ポリシーの詰まりどころ・注意点

非常に強力な拒否ポリシーですが、仕様を誤解すると大事故に繋がります。導入時に必ず押さえておくべき3つの注意点です。

注意点1：すべてのサービスが対応しているわけではない

「全ての権限を拒否できるわけではない」という点に注意が必要です。拒否ポリシーの deniedPermissions で指定できる権限には一部制限があります。設定する前に、必ず公式ドキュメントの「サポートされている拒否権限のリスト」を確認し、対象の権限が拒否に対応しているかチェックしてください。

注意点2：管理者のロックアウト（締め出し）リスク

設定ミスで最も恐ろしいのが、自分自身の権限を誤って拒否してしまい、二度とポリシーを修正・削除できなくなる「ロックアウト（締め出し）」のリスクです。

例えば、deniedPrincipals に principalSet://goog/publicInfos（全ユーザー）を指定し、deniedPermissions に iam.googleapis.com/policies.delete（ポリシー削除権限）などを入れてしまうと、管理者を含めて誰もそのポリシーを消せなくなります。
[回避策]
まずは本番の影響がないテスト用のフォルダを作成し、影響を受けない別のアカウントを使って安全に検証を行ってから本番環境へ展開することを強く推奨します。

注意点3：継承のルール

拒否ポリシーは、組織やフォルダレベルで設定すると、その配下にあるすべてのプロジェクトへ強制的に継承されます。

そして、下位のプロジェクト側でこの拒否ポリシーを上書き（オーバーライド）して「やっぱり許可する」といった例外を作ることはできません。影響範囲が非常に広くなるため、適用する階層（ターゲット）は慎重に選定する必要があります。

5. まとめ

以上が拒否ポリシー（Deny Policies）を使って、特定の操作を確実に禁止する方法でした。

拒否ポリシーは、設定次第で強力なセキュリティガードレールになる反面、影響範囲が広く、一歩間違えるとシステム全体の運用や管理者の締め出しに繋がる諸刃の剣です。利用する際は、必ずテスト環境での検証と、対応権限の仕様確認を徹底した上で慎重に設計してください。

参考リンク