Cloudflare Organizationsで設計する、マルチアカウント運用の実践コントロールプレーン
Cloudflare Organizationsが重要なのは、機能不足を埋めるからではありません。実運用で起きる事故の多くは、機能がないことよりも設定ドリフトで発生するからです。事業部ごと・地域ごと・買収由来のアカウントごとに設定がばらつき、監査時に「どこが誰の責任で守られているか」が説明できない状態が生まれます。
Organizationsは、個別アカウントの上に運用レイヤーを作るための仕組みです。ここで大事なのは「全部を中央集権化する」ことではなく、中央統制と現場の裁量を両立させる設計です。
なぜ今このテーマが優先度高なのか
企業のCloudflare導入は、多くの場合ボトムアップで進みます。
- プロダクトチームが高速化目的で個別導入
- 地域チームが独自にDNSを管理
- 後からセキュリティ部門がWAFやAccessを追加
- 最後に監査部門が証跡を要求
この順番だと、責任境界が分断されやすくなります。Cloudflare BlogのOrganizations解説は、こうした分断を再設計するための起点として読めます。
推奨する3層運用モデル
1. グローバルポリシー層（Platform/Security）
- TLS最低基準
- WAF必須ルール
- Bot対策の初期値
- AccessのIdP標準
2. ドメインポートフォリオ層（事業部・プロダクト群）
- ゾーン追加時のオンボーディング
- 例外申請の受付と期限管理
- 地域要件に応じた制御
3. ワークロード層（開発チーム）
- アプリ固有のルーティング
- キャッシュ/変換ルール
- リリース連動の安全変更
重要なのは、どこが「必須統制」でどこが「チーム裁量」かを最初に明文化することです。
最初の60日でやること
Phase 1: 棚卸しとリスク分類
- 全アカウント・全ゾーンを一覧化
- 重要度（Tier0〜Tier3）を付与
- 認証ドメインや決済系など共有依存を可視化
- 未管理ゾーンを移行対象としてマーク
成果物は「誰がどのリスクを持つか」を説明できる台帳です。
Phase 2: ポリシーバンドル化
以下のようにバージョン管理します。
baseline-security-v1dns-governance-v1access-identity-v1
ルールは設定値だけでなく、適用範囲・例外条件・ロールバック条件までセットで定義します。
Phase 3: ガード付き委譲
現場に裁量を渡すときは、境界を明確にします。
- キャッシュ調整は許可（上限付き）
- 独自WAF式は許可（ログ必須）
- 基本防御を無効化する変更は禁止
中央承認だけにすると、現場は回避策を作り始めます。委譲は妥協ではなく、定着の条件です。
Phase 4: 監査証跡の自動化
月次で最低限これを出せるようにします。
- 基準未達ゾーン一覧
- 例外一覧（期限つき）
- 過去30日での高リスク変更
- オーナー不明資産
監査対応を「四半期ごとの大作業」から「常時運用」に変換できます。
事故を減らす実装パターン
1) Break-glassは必ず期限付き
緊急回避を許可する場合でも、
- インシデントID必須
- 自動失効（例: 24時間）
- 事後レビュー必須
をセットにします。これで暫定設定の常態化を防げます。
2) DNSとZero Trustを分離しない
アプリ通信だけ守ってDNS統制が弱いと、境界は簡単に破綻します。DNS・Origin公開範囲・Accessポリシーを一体で扱う設計が必要です。
3) ルールにオーナー情報を埋める
大規模障害時は、技術調査より「誰に連絡すべきか」で時間を失うケースが多いです。主要ルールには必ず担当チーム情報を持たせます。
追うべきKPI（少数精鋭）
- Tier別のポリシー準拠率
- 新規ゾーンが基準到達するまでの時間
- Break-glass変更の期限内クローズ率
- 30日超の例外件数
- 未管理資産起因の障害件数
この5つで、ガバナンスが「監査のため」ではなく「事故削減と開発速度向上のため」であることを示せます。
まとめ
Organizations導入は管理画面の刷新ではなく、運用設計の再構築プロジェクトです。設定移行は比較的容易ですが、成功を分けるのは責任分界と委譲設計です。Cloudflareを全社スケールで安全に使い続けるための基盤として、今のタイミングで着手する価値は大きいです。
