第6回：危険な設定は許さない！「組織ポリシー」でガードレールを敷こう
はじめに
お疲れ様です。SKYこと関谷です。
前回（第5回）では、Shared VPC を使った安全なネットワーク設計について解説しました。
ネットワーク資源をホストプロジェクトに集約して複数プロジェクトで共有することで、ネットワークの共通化 を図り、ファイアウォールや Cloud NAT などのポリシーを一元適用できました。
また、ネットワーク管理者とサービス利用者の 役割と権限の分離 を徹底し、「誰が構成を変更でき、誰が利用するだけか」を明確に区分することで、設計ミスが生じにくい 壊れにくい運用設計 を実現しました。
しかし、IAM やファイアウォール設定だけでは防ぎきれないリスクが残ります。権限を持ったユーザーが誤って危険な設定を行ってしまった場合、IAM上はそれが許可された操作であればブロックされず、ファイアウォールでは対処できないケースもあります。
例えばデフォルトでは Compute Engine の VM インスタンスに外部 IP アドレスを割り当てることが可能ですが、これにより本来閉域のシステムが誤ってインターネットに公開されてしまう恐れがあります。
設定ミスを未然に防ぐ自動ブレーキ のような仕組み、そして全社共通ルールを強制する枠組みが必要です。
そこで活躍するのが Google Cloud の 「組織ポリシー」 です。
組織のポリシーは全社共通の「ルールブック」として機能し、特定の操作を強制または禁止する仕組みを提供します。リソース階層の上位（組織やフォルダ）にポリシーを設定すれば、その配下にあるすべてのプロジェクトへルールを強制適用でき、組織全体にガードレール を敷くことが可能です。
例えば組織のポリシーで VM インスタンスへの外部 IP 割り当てを禁止しておけば、どのプロジェクトでも意図しないインターネット公開を根本から防止できます。
今回の読みどころ
- なぜ IAM／FW だけでは不十分か — “権限内のミス”が生むリスクを具体化
- 組織のポリシーの基本 — 制約の考え方、継承、例外の扱い
- まず適用したい代表制約 — 外部IP禁止、リージョン制限、SA鍵の抑止 ほか
- 現場に効く運用設計 — フォルダ分割、段階適用、監査と例外申請の型
それでは、組織のポリシーで「クラウド運用の自動ブレーキ」をかけ、危険な設定を許さない仕組み を詳しく見ていきましょう。
ブログシリーズその他の執筆
本編
番外編
第３回では紹介しなかった関連機能の説明です
6-1. なぜ IAM とファイアウォールだけでは不十分なのか？
クラウド環境のセキュリティ対策としてまず思い浮かぶのは IAM（Identity and Access Management） と ファイアウォール です。
IAM は「誰が・どのリソースに・何をするか」を制御し、ファイアウォールはネットワークレベルでのアクセス制御を担います。それぞれ重要な基盤機能ですが、これらだけでは防ぎきれないリスク が存在します。
なぜなら、IAM もファイアウォールも「許可された操作」そのものを止めることはできないからです。権限を持つユーザーが意図せず危険な設定を行ってしまった場合、それは“許可された操作”である以上デフォルトではブロックされません。
IAM はプロジェクト内の操作権限を厳密に管理し、権限のないユーザーによるリソース操作を防ぎます。
しかし IAM が関与するのは「誰にその操作を許可するか」までです。その操作自体が適切かどうかまでは判断しません。 一方、VPC ネットワークのファイアウォール は仮想マシンへの通信をIPやポートに基づき許可・拒否する仕組みで、適用したルールどおりにトラフィックを制御します。ファイアウォールは“不正なアクセス”は防げても、ルールの設定ミス には忠実に従ってしまいます。
つまり、IAM とファイアウォールは 「善意のミス」や「想定外の設定」まではカバーできない のです。
具体的な例を見てみましょう。あるエンジニアに VM インスタンス作成権限を与えていたとします。
誤ってその VM に外部 IP アドレスを割り当ててしまった場合、IAM 上は許された操作のため 止めるものがありません 。Google Cloud ではデフォルトで全ての VM に外部IPv4アドレスの使用が許可されています。ファイアウォールも、外部からのアクセスを遮断する設定にしておかなければその VM へのインターネットからの通信を許してしまいます（初期状態のファイアウォールルールではインバウンドは基本ブロックですが、ルール設定によっては広範なアクセスを許可できます）。
このように、IAM上許可されたユーザーによる設定ミス （例: 不要な外部IPの付与）は従来の仕組みだけでは防ぎづらいのです。
別の例として、サービスアカウントの管理があります。
サービスアカウントに紐づく秘密鍵（キー）は慎重に扱う必要がありますが、IAM上は鍵を作成する権限があれば 何本でも発行できてしまいます 。大量にキーを発行したり、古いキーを放置したりすれば、漏洩リスクが高まります。
しかしこれも IAM 権限内の操作であるため、標準の仕組みでは制限されません（デフォルトではIAM権限があるユーザーはサービスアカウント鍵を作成可能です）。ネットワークのファイアウォールはこの問題には関与しないため、 鍵の乱発や管理不備といったリスクには無力 です。
他にも、ファイアウォール自体の設定ミスも起こりえます。
例えば誤って「0.0.0.0/0（全インターネット）」からのアクセスを許可するルールを作成してしまったケースです。
本来ファイアウォールは特定の通信だけ許可するのが原則ですが、誤った許可ルールが設定されればその範囲の通信はすべて通ってしまいます。IAM上はファイアウォールルール作成が許可されたユーザーの操作なので止められず、結果として内部システムがインターネットから丸見えになる危険があります。
このように「許可された範囲内の危険な操作」を抑止する仕組みがないと、ヒューマンエラーによるセキュリティリスクを完全には防げません。
以上の内容を、IAM とファイアウォールの役割および限界という観点で表に整理します（※✔は対策可能、✘はデフォルトでは対策困難）。
| 想定シナリオ（リスク例） | IAMでの制御 | ファイアウォールでの制御 | 不足している点 |
|---|---|---|---|
|
VMに不要な外部IPを付与 （内部システムが意図せず外部公開） |
権限があれば操作可能 （✅権限なければ禁止） |
IP割当自体は制御範囲外 通信はルール次第で許可も❌ |
外部IPの割当はデフォルトで許可。許可されたユーザーのミスを阻止できない。 |
|
サービスアカウント鍵の乱発 （長期キーの漏洩リスク増大） |
権限があれば操作可能 （✅権限なければ禁止） |
対象外（ネットワーク制御とは無関係） | 鍵の発行は権限内では無制限❌。ガバナンス不足によりリスク拡大。 |
|
広範な許可のFWルール設定 （全通信を許可してしまう） |
権限があれば操作可能 （✅権限なければ禁止） |
設定されたとおりに通信許可❌ （誤設定を検知できない） |
ルール設定ミスを止める仕組みがない❌。人的ミスによりファイアウォールが形骸化する。 |
ご覧のように、IAM とファイアウォールは強力ですが「 与えられた権限内で行われる操作 」まで網羅的にチェックする仕組みではありません。
言い換えれば、システム全体のルール違反を検知・阻止するガードレール が不足しているのです。だからこそ、組織全体で統一されたルールに基づき “許されない設定” を事前にブロックする仕掛けが必要になります。これが 「上位からのブレーキ」 の役割を果たす 組織のポリシー です。
6-2. 組織のポリシーとは：全社共通の「ルールブック」
組織のポリシー（Organization Policy） とは、組織全体で従うべき設定上のルールを一元管理し、強制するための仕組みです。
いわばクラウド利用の「社内ルールブック」をシステム化したもので、プロジェクトやリソースに対して「何を してよいか／してはいけないか 」をあらかじめ定めておくことができます。
例えば「External IP を付けてはいけない」「サービス アカウントのキーを作成してはいけない」といった禁止事項や、「特定のリージョンにしかリソースを作ってはいけない」といった遵守事項をポリシーとして設定できます。
これにより、現場のエンジニアが誤って危険な設定を行おうとしても、システム側でブロックされるため、“人の注意”に頼らず 構造的にミスを防止できる のです。
IAMポリシーとの違い：「誰ができるか」vs「何ができるか」
多くの方になじみ深い IAM（Identity and Access Management）はアクセス制御の仕組みで、「 誰が 」「 どのリソースに 」「 何をするか 」を定義します。
一方、組織のポリシーで焦点となるのは 「何ができるか」 です。すなわち、操作の可否やリソース設定の許可範囲 を制限するものであり、IAMのように人物やロールに紐づく権限ではなく、リソース環境に対する ガードレール（安全柵） を提供します。
組織のポリシーは IAM と補完関係にあり、IAM で権限を持ったユーザーであっても、組織のポリシーで禁止された操作は実行できなくなります。例えば「VMインスタンスに外部IPを付与する権限」がIAM上ユーザーに与えられていても、組織のポリシーで外部IP付与が禁止されていれば、そのユーザーは実際に外部IPを持つVMを作成することは 構造上 できません。
このように 「権限はあるが危険な操作」 を事前に潰しておけるのが、組織のポリシーの強みです。
「制約」でルールを構成する
組織のポリシーで定めるルールは、あらかじめ用意された 「制約（Constraint）」 によって構成されます。
制約とは「○○を許可しない」「△△のみ許可する」といったポリシーの粒度で、Google Cloudが提供するもの（ マネージド制約 ）と独自に作成できるもの（ カスタム制約 ）があります。
管理者は目的に応じて適切な制約を選び、その設定値を決めて組織のポリシーとして適用します。
制約にはブール型（有効化/無効化するルール）とリスト型（許可または拒否する値のリストを指定するルール）があり、たとえば以下のような制約が代表的です。
-
外部IPアドレスの禁止:
Compute Engine インスタンスに外部IPを割り当てられないようにします（constraints/compute.vmExternalIpAccess制約）。
このポリシーを組織やフォルダに適用しておけば、誤ってインターネット経由でアクセス可能なVMを作成してしまうリスクを構造的に排除 できます。 -
サービス アカウント鍵の禁止:
サービス アカウントの秘密鍵を手動で作成できないようにします（constraints/iam.disableServiceAccountKeyCreation制約）。
これを適用すれば、手動管理する長期鍵のばらまきを防ぎ、鍵漏洩によるリスク低減 につながります。 -
利用できるリソースの場所を制限:
マルチリージョン対応の制約（constraints/gcp.resourceLocations）を使い、新規リソース作成を特定のリージョン（例:asia-northeast1〈東京〉やus-central1〈アイオワ〉など）に限定可能です。
これにより データの所在地を統制し、規制や社内規定への準拠（コンプライアンス）を担保 します。 -
高コストなリソースの利用制限:
組織のポリシーにはコスト管理目的の制約も設定できます。
例えば一部の制約やカスタム制約を用いて、「特定のVMファミリー（高性能マシンやGPU搭載マシンなど）は作成不可にする」「VMのマシンスペックは○CPUまでに制限する」といったルールを設ければ、現場で うっかり過大なリソースを立ち上げてしまうことを防ぎ、コスト暴走のリスクを減らせます 。
このように制約の種類は多岐にわたり、セキュリティ、コスト、コンプライアンスなど様々な目的で用意されています（詳細は次章で紹介します）。
管理者は自社に必要なルールを洗い出し、適切な制約を選んで組織のポリシーとして設定することで、「クラウド利用の基本ルール」を技術的な仕組みで Enforce（強制） できるのです。
リソース階層への適用と継承
組織のポリシーは Google Cloud のリソース階層（Organization > Folder > Project）に沿って適用され、上位に設定したルールは下位に自動継承 されます。
たとえば組織（Organization）リソースに対してポリシーを設定すれば、組織配下すべてのフォルダやプロジェクトに同じ制約が適用されます。下図はこの継承イメージを示したものです。
上記のように、もし上位にポリシーが設定されていれば基本的に下位リソースには自動でその制約が適用されます。必要に応じてフォルダやプロジェクト単位で ポリシーを上書き（オーバーライド） することも可能です。
例えば「組織全体では外部IP禁止だが、社内検証用のフォルダBだけは例外的に許可する」といった運用もできます（フォルダBで親ポリシーを上書き設定）。
この継承と例外許可の仕組みにより、きめ細かなガバナンスと柔軟性を両立できるのがポイントです。
章のまとめ
- 組織のポリシーはクラウド利用のルールブック: 全社共通の禁止事項や必須設定を技術的に強制し、“危ない設定ができない状態”を作る仕組みです。
- IAMとの棲み分け: IAMが「誰に何を許可するか」を決めるのに対し、組織のポリシーは「環境として何を許容するか」を制限し、許可されている操作でもリスクが高いものはブロックできます。
- 制約（Constraint）で実現: 外部IP禁止やキー作成禁止など、用途別の制約をオンにするだけでガードレールを導入できます。
- 階層で一括適用＆例外管理: Organizationやフォルダに設定したポリシーは自動的に配下プロジェクトへ継承されます。例外が必要な場合はフォルダやプロジェクトで上書き設定し、一部だけルールを緩和することも可能です。
6-3. 【具体的な方法】まず設定したい、代表的な組織ポリシー制約（解説つき完全版）
前章までで「組織のポリシー」が クラウド運用のガードレール として働くことを確認しました。
本章では、まず最初に検討しやすい 代表的な制約（constraints） を、セキュリティ → コンプライアンス → コスト という優先度で6つを取り上げ、ねらい／効果／適用範囲／ユースケース／運用のコツ／落とし穴 まで含めて解説します。
セキュリティ関連
1) constraints/compute.vmExternalIpAccess
目的
VM インスタンスへの 外部IP付与を禁止し、意図しないインターネット公開を根本から防ぎます 。
効果
- 新規作成・既存更新のいずれも、外部 IP を持つ構成が 構造的に不可
- 入口は LB/IAP、出口は Cloud NAT/Private Google Access/Private Service Connect へ 一元化 しやすくなる
適用範囲の考え方
- Organization 直下 に適用（原則）。外部公開が必要な検証用や特定プロダクトのみ、フォルダ／プロジェクト で例外を許可
代表ユースケース
- 社内システムやバッチ処理など、外部公開の必要がない VM 全般
- 監査や脆弱性診断で「外部IP付きVMが散在」の指摘がある場合の 一掃
運用のコツ
- 例外は 期限つき で発行し、CI/CD のパイプラインに 自動失効 を組み込む
- 外部公開が必要なら、 LB/IAP 経由 の標準入口パターンに誘導
落とし穴／確認
- 既存で外部IP依存の運用があると、適用直後に 変更が失敗 する（事前棚卸しが必須）
- 代替経路（NAT/PSC 等）を 先に整備 してから enforce
2) constraints/iam.disableServiceAccountKeyCreation
目的
サービス アカウント鍵（長期秘密鍵）の新規作成を禁止し、鍵の乱発・放置・漏洩を抑止 します。
効果
- 鍵ファイル配布に依存しない運用（短期トークン、Workload Identity 等）へ 強制移行 できる
- 監査で問題になりやすい「期限不明の長期鍵」を 制度的に排除
適用範囲の考え方
- Organization 全体 に適用（原則禁止）。やむを得ないレガシーのみ、フォルダ で一時緩和
代表ユースケース
- 外部委託やローカル検証で 鍵ファイルを共有 していた慣行の是正。
- コンプライアンス監査における 長期資格情報の削減
運用のコツ
- 既存鍵は「 棚卸し → 期限設定 → 置換 」の計画を先に回す
- 例外は 発行目的・期限・廃止手順 をセットで記録
落とし穴／確認
- 置換先（Workload Identity など）の 導入手順とサンプル を準備しないと現場が詰まる
- 自動化（CI/CD, Terraform）で 鍵に依存している箇所 を事前に洗い出す
コンプライアンス関連
3) constraints/iam.allowedPolicyMemberDomains
目的
IAM 付与可能な ユーザー／グループのドメインを制限し、社外アカウントへの誤付与を防止 します。
効果
- 個人アカウントや他社ドメインへのアクセス付与を 技術的に禁止
- 退職者・委託先の アクセス統制 が明確になる
適用範囲の考え方
- Organization で原則 （社内ドメインのみ許可）。特定パートナーの利用がある部門だけ フォルダ で許可ドメインを追加
代表ユースケース
- 個人 Gmail を含む フリーアカウントの排除
- B2B 連携で 特定パートナードメイン のみ許容
運用のコツ
- パートナーには 管理されたアカウント 発行を基本とし、例外は 審査フロー で管理
- 既存 IAM バインディングの 自動検査 （違反検知）を合わせて実装
落とし穴／確認
- 既存で社外アカウントが紛れていると、適用後に 権限剥奪 が発生（事前通知が必要）
- 自動アカウント発行／剥奪の ライフサイクル運用 を整える
4) constraints/gcp.resourceLocations
目的
リソース作成可能な ロケーション（リージョン／マルチリージョン）を制限し、データ所在地の規程・法令に適合 させます。
効果
- 誤って海外リージョンに作るミスを ブロック
- 環境全体として データ所在の一貫性 を担保
適用範囲の考え方
- 業務要件に応じて、 許可ロケーションのホワイトリスト を定義（例：
asia-northeast1のみ） - 例外が必要な研究開発部門だけ、 フォルダ で追加許可
代表ユースケース
- 規制業界（金融・医療）や社内規程で 国内保持 が求められるデータ
- DR 設計で 特定リージョンの二重化 を前提にするケース
運用のコツ
- まず 現状ロケーションの棚卸し を実施し、影響の大きいワークロードから移行計画を立てる
- テンプレート（Terraform/Blueprints）に ロケーション変数 を固定化
落とし穴／確認
- PaaS/マネージドサービスは 対応ロケーションが限定 される場合あり（事前確認）
- マルチリージョンを禁止すると 可用性要件に影響 するケースがある（SLAと整合確認）
コスト関連
5) constraints/gcp.restrictServiceUsage
ねらい
プロジェクトで 有効化できるサービス/API を限定し、想定外の高コスト・高リスク サービスの無断利用を防ぎます。
効果
- 許可リスト外の API 有効化／利用を エラーで拒否
- サービス導入を 申請→評価→許可 のフローに乗せられる
適用範囲の考え方
- 組織で 既承認サービスのリスト を持ち、Organization に適用。新規採用は例外申請で段階承認
代表ユースケース
- 大規模組織での シャドーIT抑止
- セキュリティ審査未了の AI/β版サービスの 先走り利用 を防止
運用のコツ
- 申請時に 費用見積もり／データ所在／責任部署 を添付する標準フォームを用意
- 既存プロジェクトの利用 API を 自動棚卸し して初期リストを作る
落とし穴／確認
- 許可漏れで正当なデプロイが 止まる 恐れ（導入前に PoC で検証）
- 例外許可の 期限管理と再審査 を忘れない
6) constraints/resourcemanager.requireTagKeys
ねらい
リソース作成時に 必須タグ（例：owner, cost-center, env） の付与を 強制 し、コスト可視化／責任分界／棚卸し を徹底します。
効果
- 無タグ資産の発生を 技術的に防止
- 請求レポートの 配賦精度 が上がり、未使用資産の 発見・廃棄 が容易
適用範囲の考え方
- Organization に適用し、キー名の標準 を先に合意。部門独自の追加タグは フォルダ で補完
代表ユースケース
- コスト管理の高度化（部門・プロダクト別集計）
- セキュリティ審査での 資産管理要件 の充足
運用のコツ
- IaC/テンプレート（Terraform/Deployment Manager）で 自動付与
- 値の選択肢（例：
env = prod|stg|dev）を 辞書化 してばらつきを防止
落とし穴／確認
- タグ体系が変遷すると 履歴の不整合 が生じる（移行手順を用意）
- 例外（外部プロビジョニング等）で 未タグ が生じないよう CI/CD で検証
章のまとめ
これら6つの制約だけでも、セキュリティ事故の芽・コンプライアンス逸脱・コスト暴走観点での最低限の部分は抑止できます。
本記事では文量の関係で６つに絞っていますが、「6-6.参照情報」に記載の「Google Cloud公式ドキュメント: Organization policy constraints（利用可能な組織ポリシー制約の一覧）」もご確認いただき、他の有用な組織ポリシー制約を見つけてみて下さい。
設計原則は「 上位で原則、下位で最少の例外 」、例外には 期限と監査 を必ずセットにすることです。
6-4. 組織ポリシーの段階導入と例外運用の型
Google Cloudの 組織のポリシー（Organization Policy） は、クラウド環境全体に共通の ガードレール を敷き、意図しない設定ミスや危険な操作を未然に防ぐ強力な仕組みです。
しかし、強力ゆえに一度に全プロジェクトへ適用すると 業務に支障 をきたす可能性もあります。
そこで、組織ポリシーは 段階的に導入 し、必要に応じて 例外を運用 することが重要です。
ここでは、組織ポリシーの導入を 「パイロット → カナリア → エンフォース」 のステップに分ける方法と、例外申請・管理のベストプラクティス について解説します。
段階的な組織ポリシー導入のアプローチ
まずは、組織ポリシーを 3段階で慎重にロールアウト するアプローチです。
以下のフローチャートに示すように、少数環境で試す パイロット から始め、影響範囲を徐々に拡大する カナリア を経て、最終的に全体へ エンフォース（本番適用） します。
これにより、新しいポリシーによって 業務停止 や 既存リソースのエラー となるリスクを低減できます。また同時に、影響を確認しながら適用することで 社内への周知・調整 もスムーズに行えます。
3段階のロールアウトアプローチ
-
Pilot（パイロット）段階：
まずは限定的な範囲で組織ポリシーを適用し、影響を検証します。
例えば特定のテスト用プロジェクトや開発環境に対してのみ新ポリシーを試験的に導入します。
この際、ドライラン（dry-run）モード を活用すると効果的です。ドライランではポリシー違反が ログに記録 されるものの実際の 拒否は行われない ため、業務を止めずにポリシー適用時の影響範囲を観察できます。
加えて、Policy Simulator の シミュレーション機能 も有用です。Simulatorを使うと、新しいポリシーを本番適用する前に どのリソースが違反状態になるか を事前に把握できます。公式ドキュメントでも、「Simulatorにより提案中のポリシーに不準拠なリソースのリストが提供されるので、適用前にこれらのリソースを再設定したり、例外申請したりと 環境を停止させず対処 できる」ことが強調されています。
つまり、パイロット段階では 違反検知のみ 行い影響を測定し、必要な対応策（設定変更や例外の検討）を洗い出します。 -
Canary（カナリア）段階：
次に、ポリシーを一部の本番環境へ 段階的に適用 します。
影響が小さい部門のフォルダや限定されたプロジェクト群でまず 有効化 し、ポリシー違反による エラー が発生しないか確認します。
カナリアリリースのように少数から適用範囲を広げることで、万一問題が見つかっても 被害を局所化 できます。また、この段階で 組織ポリシーの継承と上書き の仕組みを活用することもポイントです。
組織ポリシーはデフォルトでリソース階層を下位に 継承 されますが、必要に応じて子フォルダやプロジェクトでポリシー設定を 上書き（オーバーライド） できます。
例えば特定フォルダ配下ではポリシーをまだ 「非強制」 に設定して様子を見る一方、他のフォルダでは 「強制」 する、といった柔軟な運用が可能です。
こうしたフォルダ単位の調整により、組織全体への ** 一斉適用前に安全に試行** できます。実際、Google 公式も 「すべてのポリシー変更はテストとドライランを行うことをおすすめします」 と述べています。 -
Enforce（エンフォース）段階：
パイロットとカナリアで十分な検証と社内調整ができたら、組織ポリシーを 本番環境全体に強制適用(Enforce、エンフォース) します。
エンフォース段階ではポリシーは 「Enforced（強制）」状態 となります。
違反する操作 はシステムによって 即座に拒否 されるようになります。
例えば 「外部IPアドレスの禁止」 ポリシーをエンフォースすれば、以降は組織内のどのプロジェクトでも外部IP付きVMの作成試行が** エラー**となります。
この段階まで来れば、組織全体で 統一ルール が徹底され、重大な設定ミス の大半が事前に防がれるようになります。
なお、新しいポリシーをエンフォースした際に既存リソースが制約に 違反 している場合にも注意が必要です。
多くの制約は 遡及適用されない（retroactive でない） ため、既に存在するリソースはそのまま残存します。
例えば、すでに 外部IP が付与されているVMがある状態で 「外部IP禁止」 を適用すると、そのVMは“違反”の状態とはなりますが動作は即停止されず、引き続き外部IP経由で通信できてしまいます。このような既存 違反リソースの洗い出し と 手動対処 も、エンフォース後の重要な運用ポイントです。
Security Command Center（SCC） などのツールで違反状態をモニタリングし、該当リソースに対して 外部IPの削除 など 是正措置 を講じる必要があります。
組織ポリシーの例外運用とベストプラクティス
どれほど厳格にポリシーを敷いても、現実には一部のプロジェクトで ポリシーからの例外 を許可しなければならない状況が生じ得ます。
例えば、「サービス アカウント鍵の作成禁止」 を全社適用している中で、どうしても一時的に鍵を発行しなければならない 移行作業 が発生する、といったケースです。
組織ポリシー運用の鍵は、このような 必要最小限 の例外を 適切に管理 し、ポリシーの 遵守率 と業務の 柔軟性 を両立させることにあります。
例外申請と承認フロー
まず、例外を許可する際の 社内フロー を明確に定めましょう。
一般的には、ポリシー例外を求めるプロジェクト担当者からセキュリティ／ガバナンス担当への 申請 → 審査 → 承認 というプロセスをとります。
以下のシーケンス図は一例のフローです。
例外申請と承認フロー例
このように、まず利用者が 例外申請書 を提出し、セキュリティチームが内容を 精査 します。
申請には 「なぜ必要か（業務上の理由）」「どのリソースに対してか」「何日間必要か」 などを含め、理由が 正当 か、期間は 妥当 かを判断できる情報を盛り込むことが重要です。
セキュリティチーム（もしくはクラウド管理のガバナンス担当）は申請内容を 審査 し、必要であれば申請者と面談して詳細を 確認 します。その上で、承認 か 却下 かを決定します。
承認した場合、プラットフォーム管理者（または同じセキュリティチーム内の担当者）が実際に組織ポリシーへ 例外を反映 します。反映方法については後述しますが、具体的には 「対象プロジェクトにのみポリシーを緩和」 する、「対象リソースにタグを付与して制約を除外」 する、などの方法があります。
最後に申請者へ結果を通知し、承認なら 例外適用が完了 したことを伝えます。却下の場合はその旨と理由、必要に応じて 代替策 （例えば別の安全なアプローチ）の提示を行います。
例外の実現方法: フォルダ分離 vs タグ活用
承認された例外は、組織ポリシー上で技術的に どう実現 するかを考える必要があります。代表的な方法は次の二通りです。
-
フォルダやプロジェクト単位でポリシーを上書きする方法：
例えば、組織全体ではあるサービスの利用を禁止するポリシーを適用していても、特定フォルダ配下のプロジェクトだけはそのサービス利用を許可する、というように リソース階層で区切って適用ルールを変更 できます。
組織ポリシーの 継承ルール を利用し、例外を設けたいプロジェクトが属するフォルダで親ポリシーを オーバーライド して 許可設定 に変更します。この方法は、例外対象が明確にフォルダ単位・プロジェクト単位で分離できる場合に有効です。
例えば 「研究開発用フォルダ内のプロジェクトでは外部IPを許可」 など運用ポリシー自体を分ける場合に適しています。 -
タグを利用した条件付きポリシーの方法：
最近の組織ポリシー機能では、リソースに付与した タグ（ラベル）条件 に応じて制約を 適用・除外 することができます。
例えば、Compute Engineの制約 「VMインスタンスへの外部IP付与を禁止」 を全社にエンフォースしつつ、どうしても外部IPが必要な一部のVMだけは 例外として許可 したい場合があります。その場合、対象VMに例えばenv:AllowExternalIPといったタグを付け、そのタグを持つリソースにはポリシーを適用しない 条件ルール を設定します。こうすることで、タグを付けられた特定VMは 外部IP許可の例外リソース として扱われ、他のVMには引き続き 外部IP禁止ポリシー が適用されます。
タグと条件付きルールの組み合わせにより、組織ポリシーを中央集権的に管理しながら ピンポイントで例外 を設けることが可能です。
上記2つの方法はいずれも公式にサポートされた手段であり、状況に応じて使い分けます。
フォルダ上書きは 「例外とはいえある程度まとまった単位でポリシーを変える」 ケースに向き、タグ条件は 「ごく一部のリソースだけ特例扱いする」 ケースに有効です。
なお、タグを使う方法は組織やフォルダといった階層構造に依存せず例外を柔軟に指定でき便利ですが、タグの命名や運用ルール を社内で明確に定めておく必要があります。また、例外として付与したタグがそのまま放置されないよう、後述する 台帳 で管理し、期間が過ぎたらタグを除去 する運用も大切です。
例外の台帳管理とKPIモニタリング
組織ポリシー運用において、どれだけ例外が発生しているか を可視化しコントロールすることも重要です。ポリシー違反や例外を野放しにすると、せっかくのガードレールが 形骸化 してしまう恐れがあるためです。そこで、以下のような KPI（重要指標） を設定して定期的にモニタリングすると良いでしょう。
KPI例（一覧）
| KPI項目 | 説明（管理の狙い） |
|---|---|
| 組織ポリシー適用数 | 設定している組織ポリシーの本数。増減を追跡し、必要なガバナンス領域を網羅できているか確認。 |
| ポリシー適用率（プロジェクト） | 全プロジェクト数に対しポリシーが適用されているプロジェクトの割合。100%に近いほど統制が行き届いている状態。 |
| 月次ポリシー違反検出件数 | 監査ログやSCCで検知されたポリシー違反イベントの件数。減少傾向であれば順調、増加していれば追加対策や教育が必要。 |
| 例外申請件数（累計/月次） | これまでに申請された例外の件数。急増していないか監視し、ポリシー設定自体の見直しが必要か判断。 |
| 現在有効な例外件数 | 承認され有効期間内の例外の件数。多すぎる場合は例外の乱用傾向を示すため注意。 |
| 平均例外有効期間 | 例外が許可されている平均期間。長期の例外が多い場合は恒久例外化していないかチェック。 |
例えば上記のような指標を用いて、組織ポリシーの施行状況を 定量的に把握 します。違反イベントがゼロに近づくほどガードレールが有効に機能していることを示し、逆に例外申請が 急増 している場合はポリシー内容自体が現実と乖離している可能性もあります。また、例外についてはその内容を一覧表（ 例外台帳 ）で管理しておくことが不可欠です。以下は例外台帳の一例です。
例外台帳（サンプル）
| 例外ID | 対象リソース (プロジェクト/内容) | 許可した例外内容 | 承認者 | 承認日 | 有効期限 | 備考 |
|---|---|---|---|---|---|---|
| #2025-EX001 | Project Alpha（外部IP付きVM） | 外部IPアドレス利用を一時許可 | 情報システム部長 | 2025/10/01 | 2025/12/31 | 新サービス検証のため |
| #2025-EX002 | Project Beta（サービスアカウント鍵） | サービスアカウント鍵の発行を許可 | CISO | 2025/10/15 | 2025/11/15 | 移行作業に限定 |
このように、どのプロジェクトの 何を 例外として許可したか、誰がいつ承認 し いつまで有効 かを一覧で管理します。台帳があることで、期限を過ぎた例外 に気付きながら 解除漏れ を防止できます。また定期レビューの場で台帳をチェックし、「この例外はまだ必要か？恒常化していないか？」 を問いただすことで、例外運用の 健全性 を保つことができます。
最後に、組織ポリシー運用全体を支えるプラットフォームの活用について触れておきます。
- Google Cloudでは Security Command Center (SCC) などのサービスを通じて、組織全体のセキュリティ状態を 監査・可視化 できます。
SCCの Security Health Analytics 機能は、組織ポリシーで定めたルール違反につながる一般的な構成ミスを 自動検出 し、アラート を上げてくれます。
例えば 「Cloud Storageバケットが公開設定」 といった対策違反や、重要な制約違反を見逃さず把握できるため、組織ポリシーではカバーしきれない既存リソースのリスクにも対処可能です。 - また、IaC（Infrastructure as Code） ツールによるポリシー管理も有用です。Terraformなどを用いて組織ポリシーの設定自体を コード化・一元管理 すれば、ポリシー変更の 履歴を監査 でき、誤設定防止 や 複数環境への一括適用 が容易になります。
実際、Google 提供のポリシー検証ツールでは Terraform のプランを組織ポリシーのルールセットと照合して違反がないか 自動チェック する仕組みも提供されています（ Terraform Vet コマンドの利用など）。
これらのプラットフォームやツールを駆使し、組織ポリシーの 計画→導入→監視→改善 のサイクルを継続的に回していくことが、 セキュアな土台作り における長期的な成功につながります。
6-5. まとめ
本章では、Google Cloud の 組織のポリシー（Organization Policy） を「 小さく検証（Pilot）→ 限定展開（Canary）→ 全面施行（Enforce） 」という段階で導入し、最小・期限付き・可視化 を原則に例外を運用する要点を整理しました。ねらいは、チームの注意力に依存しない“ ガードレール ”をつくり、設定ミスを未然に防ぐ ことです。
重要ポイント（要点のおさらい）
-
段階導入が基本：
いきなり全面強制ではなく、まずは ドライラン や シミュレーション で影響を“見える化”。小さく成功体験を積んでから範囲を広げる。 -
階層と条件で柔軟に：
組織→フォルダ→プロジェクトの 継承と上書き 、条件付きポリシー／タグ条件 を使えば、局所的な許可や除外が安全にできる。 -
例外は“最小・期限付き”：
申請→審査→適用→ 台帳記録 →期限リマインドの 一本化フロー で、なし崩しを防ぐ。 -
IaCで統制：
ポリシーと例外を コード化 し、差分確認・レビュー・ロールバックを標準化。人手のばらつきを排除する。 -
継続監視と是正：
監査ログ や セキュリティの健全性チェック を活用し、既存の違反 は計画的に是正。 -
KPIで運用を改善：
違反検知件数、例外件数・期限遵守率、適用率などを定点観測し、ダッシュボード で共有する。
アンチパターン（避けたい落とし穴）
- 一斉強制：検証なしで全社適用し、業務停止や反発を招く。
- 恒久例外の温床：期限を切らない許可、台帳不備、再審査なし。
- 属人的運用：手作業更新・口頭依頼・記録欠落で統制不能に。
- 見っぱなし監視：検知だけで是正に繋がらない“ダッシュボード眺め”。
最小チェックリスト
- Pilot 環境でドライラン／シミュレーションを実施して影響を把握した
- Canary 対象（フォルダ／プロジェクト）を決め、部分施行の手順を整えた
- 例外フロー（申請・承認・設定・台帳・期限リマインド）を決めて回せる
- IaCでポリシーと例外をコード化し、レビュー＆差分確認を必須化した
- 監査ログ／健全性チェックの通知・ダッシュボードを用意した
- KPI（違反件数、例外件数・期限遵守率、適用率）を決めて定点観測する
6-6. 参照情報
本章では、第6回の内容（組織ポリシーの役割・ブレーキ設計、適用順序と継承／ドライラン、例外運用、段階導入と可視化・運用）に 直接ひもづく Google Cloud 公式ドキュメントのみ を掲載します。
組織ポリシーの役割とガードレール設計
組織ポリシー サービスの概要（全社共通ルールの枠組み）
Organization policy constraints（利用可能な組織ポリシー制約の一覧）
Cloud NAT の概要（外部 IP なしでのインターネット到達）
適用順序・継承と監査（ドライラン／Enforce）
ポリシー評価と継承（概要内の評価・継承の考え方）
ドライラン モードで組織のポリシーを作成（Dry-run と Enforce の違い）
Security Health Analytics の概要（代表的なミス構成の自動検出）
Cloud Audit Logs（監査ログ）
例外運用・条件付きポリシー・タグ
条件付きポリシー（CEL）
タグを使用した組織のポリシーの設定（タグ条件で適用／除外）
ポリシーの継承と上書き（フォルダ／プロジェクトでの例外）
段階導入（Pilot→Canary→Enforce）と運用ベストプラクティス
Policy Simulator で組織ポリシー変更をテスト
エンタープライズ セキュリティ基盤ブループリント（ガードレール実装と運用の指針）
Cloud Asset Inventory の概要（資産インベントリの可視化）
ポリシーを検証する（Terraform との統合によるポリシー検証）
Discussion