技術 約5分で読めます

Cloudflare Organizationsがパブリックベータ入り、マルチアカウント管理を統合

Cloudflare エンタープライズ 認可 マルチテナント Terraform
いけさん目次

Cloudflareを大規模に使っている企業には共通の悩みがある。事業部ごと・子会社ごとにCloudflareアカウントが分かれていて、WAFルールもDNS設定もバラバラ。統一したセキュリティポリシーを適用したくてもアカウントを跨ぐ管理手段がなく、スーパー管理者が個別にログインして回るしかなかった。

4月6日にパブリックベータとして公開されたCloudflare Organizationsは、この問題に対する公式回答だ。個別アカウントの「上」に組織レイヤーを置き、アカウント横断の管理・分析・ポリシー配布を一箇所でやれるようにする。

何ができるのか

Organizationsが提供する機能は4つある。

機能内容
アカウントリスト組織配下の全アカウントをフラットに一覧管理。最大500アカウント・500ゾーンまで
Org Super Administrator組織レベルのスーパー管理者ロール。子アカウント個別のメンバーシップなしで全アカウントを管理可能
集約アナリティクス組織全体のHTTPトラフィックをダッシュボードで横断表示
共有コンフィグレーションWAFカスタムルールセットやGatewayポリシーを複数アカウントに一括配布

1組織あたりの上限は500アカウント・500ゾーン。AWSのOrganizationsやGoogle Cloudの組織リソースと同じカテゴリの機能で、クラウドサービスが一定規模を超えると必ず必要になるマルチアカウント管理レイヤーだ。

認可システムの統合が本丸だった

機能面だけ見ると「管理画面が増えた」程度に映るが、内部的にはかなり大きな作業が走っている。Cloudflareの認可（authorization）システムは長年の成長の中で複数の仕組みが混在していた。Organizationsを作るにあたり、これらをドメインスコープドロール（domain-scoped roles）ベースの単一システムに統合した。

コード変更の規模は約13万3千行の追加、約3万2千行の削除。単純な機能追加ではなく、既存の認可チェックを全面的に書き直すリファクタリングだ。

この統合の副産物として、/accounts や /zones のような列挙系APIエンドポイントの権限チェックが27%高速化された。数千アカウントにアクセスできるユーザーの場合、従来はレスポンスが著しく遅くなる問題があったが、認可ロジックの整理で解消されている。

graph TD
    A[従来の認可システム] --> B[レガシーロール]
    A --> C[Tenantシステム<br/>パートナー向け]
    A --> D[アカウント単位の<br/>メンバーシップ]
    B --> E[ドメインスコープドロール<br/>統合認可システム]
    C --> E
    D --> E
    E --> F[Organizations]
    E --> G[従来のアカウント管理]
    E --> H[パートナーエコシステム]

Org Super Administratorの権限モデル

Organizations導入で新設されたOrg Super Administratorロールは、組織配下の全子アカウントに対してSuper Administrator権限を暗黙的に持つ。従来のアカウント単位のメンバー管理とは独立しており、子アカウント側のメンバー一覧には表示されない。

graph TD
    O[Organization] --> OSA[Org Super Administrator]
    O --> A1[アカウントA]
    O --> A2[アカウントB]
    O --> A3[アカウントC]
    OSA -.->|暗黙的Super Admin権限| A1
    OSA -.->|暗黙的Super Admin権限| A2
    OSA -.->|暗黙的Super Admin権限| A3
    A1 --> M1[アカウントAの<br/>メンバー一覧]
    OSA -.->|非表示| M1

この設計にはセキュリティ上の配慮がある。子アカウントのメンバーから見えない管理者が存在することで、アカウントレベルの攻撃者が組織管理者を特定・標的にしにくくなる。一方で、「誰がこのアカウントを触れるのか」の可視性が下がるトレードオフもある。

共有コンフィグレーションの仕組み

WAFカスタムルールセットやGatewayポリシーを、ソースアカウントから複数のターゲットアカウントに配布できる。ポイントは、ソースアカウント側でコンフィグ管理権限を持つユーザーが、組織管理者でなくても共有ポリシーを更新できること。セキュリティチームが全社WAFルールを管理しつつ、各事業部のアカウント管理者は自分のアカウント固有の設定だけを触る、という運用が成り立つ。

graph LR
    SA[ソースアカウント<br/>セキュリティチーム管理] -->|WAFルールセット配布| T1[事業部Aアカウント]
    SA -->|WAFルールセット配布| T2[事業部Bアカウント]
    SA -->|Gatewayポリシー配布| T3[子会社アカウント]
    SEC[セキュリティチーム] -->|コンフィグ管理権限| SA

AWSのService Control Policies（SCP）やAzureのManagement Groupsポリシーに相当する概念だが、Cloudflareの場合はWAFとGatewayに絞った実装。組織全体へのガードレール適用というよりは、セキュリティポリシーの横展開に特化している。

Terraformサポート

初日からTerraformプロバイダーが対応している。Organizations・アカウント割り当て・設定をコードで管理できる。エンタープライズ環境ではGUIポチポチで数百アカウントの設定を回すのは現実的でないので、IaCサポートは必須だった。

Cloudflareは以前からTerraformプロバイダーの整備に力を入れており、Workers・Pages・WAF・DNS・Tunnelなど主要リソースのほぼ全てがTerraform管理可能になっている。Organizationsはその延長線上にある。

セキュリティファーストのロールアウト

ベータ公開にあたって、Cloudflareは権限昇格が起きない設計を徹底している。

  • 自動的なOrganization作成は行わない。エンタープライズアカウントのSuper Administratorがダッシュボードで招待を受ける形式
  • 1企業につき1 Organizationのみ
  • 既存ユーザーの権限が勝手に拡大されることはない
  • Cloudflareサポートが顧客に代わって設定変更を行うことはない

権限モデルの変更は常にリスクが伴う。Cloudflareは以前Client-Side SecurityのGNN+LLM検出を全ユーザーに開放したときもセルフサーブ展開を段階的に進めていたが、Organizationsでも同様に慎重なアプローチを取っている。

今後のロードマップ

現時点ではエンタープライズ顧客限定だが、今後数ヶ月でPay-as-you-goプランの顧客にも展開予定。パートナーエコシステムへの対応は特殊シナリオの検討が残っており、時期は未定。

追加予定の機能としては、組織レベルの監査ログ、請求レポート、製品別のアナリティクスダッシュボード拡充、追加のユーザーロール、セルフサーブでのアカウント作成がある。特に監査ログは、マルチアカウント環境でインシデント対応する際に組織横断の操作履歴を追えないと実用にならないので、早期に欲しいところだ。