Organization Policy Service

解決する課題

IAM が「誰が何をできるか」を制御するのに対し、Organization Policy Service は「組織として何を許すか／禁じるか」という構成上のガードレールを敷きます。個々のプロジェクト管理者の善意や注意力に頼らず、組織全体で一律に望ましくない構成を予防的にブロックします。

• プロジェクト管理者に強い権限を渡しつつ、外部公開やパブリック IP の付与だけは絶対に禁じたい
• データ主権の要件から、リソースを作れるリージョンを特定の地域に限定したい
• 全社で許可するドメインのアカウントしか IAM に追加できないようにしたい
• サービスアカウントキーの作成や、特定 API の有効化を組織として一律に止めたい
• 多数のプロジェクトに同じルールを個別設定するのではなく、上位で一度設定して継承させたい

主要概念と用語

• 組織ポリシー（Organization Policy）: 制約に対して設定した実体。リソース階層のノード（組織・フォルダ・プロジェクト）にアタッチして適用する
• 制約（Constraint）: 制御の対象を定義した「型」。Google が提供する事前定義の制約と、利用者が条件を書く**カスタム制約（Custom Constraint）**がある
• リスト制約（List Constraint）: 許可／拒否する値の一覧で縛る型。allowedValues / deniedValues を指定する（例: 許可リージョンの限定、許可ドメインの限定）
• ブール制約（Boolean Constraint）: オンかオフで縛る型。enforced を true / false で設定する（例: 外部 IP の禁止、サービスアカウントキー作成の禁止）
• カスタム制約: 対象リソースの種類とメソッド、CEL（Common Expression Language）の条件式を自分で記述し、独自のガードレールを作る仕組み
• 継承（Inheritance）と統合（Merge）: 上位ノードのポリシーは下位に継承される。下位は親の設定を継承するか、上書きするか、または親とマージするかを選べる
• デフォルト動作: 親を継承しつつ、制約ごとに定められた既定の振る舞いに従う状態
• ドライラン（Dry-run / 監査モード）: 実際にはブロックせず、違反となる操作をログに記録して影響範囲を事前に確認するモード

仕様・制限・クォータ

• 適用範囲はリソース階層。制約は組織・フォルダ・プロジェクトのいずれかにアタッチし、その配下に効く
• ポリシーは予防的ガードレールであり、IAM の許可とは独立に評価される。IAM で権限があっても、組織ポリシーで禁じられた構成は作れない
• リスト制約・ブール制約・カスタム制約という型ごとに設定できる項目が決まっており、任意の API を自由に縛れるわけではない。事前定義の制約に存在しないものはカスタム制約で補う
• カスタム制約が対応するリソース種別・メソッドには対象範囲がある。すべての Google Cloud サービスを網羅するわけではなく、対応状況は拡大途上である点に注意する
• 一組織・一リソースあたりに設定できるポリシーやカスタム制約の数には上限があり、変動するため正確な数は公式ドキュメントで確認する
• 設定の反映は短時間で伝播するが即時保証ではない。新規作成リソースに対して効くものと、既存リソースの評価に影響するものがある点を踏まえて運用する

内部の仕組み

リソースの作成・変更リクエストが来ると、対象ノードから上位階層へさかのぼって有効なポリシーが解決され、その操作が制約に違反していないかが評価されます。

1. リクエストされた操作に対し、対象リソースとその上位（プロジェクト→フォルダ→組織）にアタッチされたポリシーを収集する
2. 継承ルールに従って有効ポリシーを合成する。下位ノードは親を継承する、上書きする、親とマージする、のいずれかの指定を持つ
3. 合成されたポリシーに照らして操作を評価し、違反していれば操作自体を拒否する。違反がなければ通常どおり処理が進む

設計パターン / ベストプラクティス

• 組織ノードにベースラインを敷く: 外部公開の禁止、許可リージョンの限定、許可ドメインの限定といった全社共通の制約は組織直下に設定し、全体へ継承させる
• 例外はフォルダ単位で切り出す: 特定環境だけ緩和が必要なら、その環境専用のフォルダを作り、そこだけ上書きする。プロジェクト単位の散発的な例外は避ける
• 本番適用前にドライランで影響確認: 既存環境にいきなり強い制約を効かせると既存ワークロードが壊れる恐れがある。監査モードで違反ログを観測してから本適用する
• IAM との役割分担を明確に: 「誰が」は IAM、「何を許すか（構成の可否）」は組織ポリシー、と二層で設計する
• カスタム制約は対応リソースを確認してから: 事前定義制約で足りない統制だけをカスタム制約で補い、CEL 式は読みやすく保つ
• IaC で管理する: ポリシー設定をコード化し、レビューと変更履歴を残す

運用・監視

• ポリシーの変更は Cloud Audit Logs に記録される。誰がいつどのノードの制約を変更したかを監査する
• ドライランポリシーの違反はログに出力されるため、本適用前後で違反の発生状況を継続的に観測する
• Policy Analyzer / アナライザ系の機能で、現在どのノードにどの制約が効いているか、継承の結果として有効なポリシーが何かを棚卸しする
• 想定外にリソース作成が失敗したときは、有効ポリシー（継承込み）→ 該当する制約の種別 → 上書き設定の順で原因を切り分ける

コスト

Organization Policy Service の利用自体は無料です。制約の設定・評価・継承に料金はかかりません。ただしドライランの違反や変更の監査ログを Cloud Logging に長期保管する場合は、Logging 側の取り込み・保管料が発生し得ます。

セキュリティ

• ポリシー管理者を絞る: 組織ポリシーを変更できるロール（roles/orgpolicy.policyAdmin 系）は限られた管理者だけに付与し、ガードレール自体の改ざんを防ぐ
• 多層防御として使う: IAM の最小権限と組み合わせ、権限があっても危険な構成（外部公開、パブリック IP、無制限なサービスアカウントキー作成など）を構造的にブロックする
• 上書き権限の連鎖に注意: 下位ノードでポリシーを上書きできる管理者がいると、上位のガードレールを実質的に無効化できる。上書きの可否と管理ロールをセットで設計する
• データ主権: リージョン限定の制約で、データを置ける地域を物理的に制限し、コンプライアンス要件を満たす

Well-Architected の観点

• セキュリティ: 予防的統制（preventive control）の中核。望ましくない構成をそもそも作れなくすることで、人的ミスや内部不正による事故の発生確率を下げる
• 運用上の優秀性: 全社ルールを上位で一度定義して継承させるため、プロジェクトが増えても統制が自動的に行き渡る。IaC 化とドライランで安全に変更を回せる
• 検出的統制（Security Command Center 等による検知）が「起きた後に気づく」のに対し、組織ポリシーは「起きる前に止める」点が補完関係にある

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 設定可能な制約の一覧を確認する
gcloud resource-manager org-policies list-available-constraints \
  --organization=123456789012

# ブール制約: VM への外部 IP 付与を組織全体で禁止する（有効化）
gcloud resource-manager org-policies enable-enforce \
  compute.vmExternalIpAccess \
  --organization=123456789012

# リスト制約: リソースを作れるリージョンを特定ロケーションに限定する
gcloud resource-manager org-policies allow \
  gcp.resourceLocations \
  in:asia-northeast1-locations \
  --organization=123456789012

# あるプロジェクトに現在効いている組織ポリシー（継承込み）を確認する
gcloud resource-manager org-policies list --project=my-project