6
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Y-Y-dev
in

複数クライアントのCloudflare管理で気をつけたい権限制御とアカウント分離

6
Posted at

複数クライアントのCloudflare管理で気をつけたい権限制御とアカウント分離

概要

Cloudflareは、DNS、CDN、WAF、SSL/TLS、Pages、Workers、Zero Trust などをまとめて扱える便利なサービスです。
一方で、複数のクライアントや複数プロジェクトのドメインを同じアカウントで管理している場合、権限設計を誤ると、意図しない情報開示や操作ミスにつながる可能性があります。

特に注意したいのは、次のようなケースです。

  • 外部作業者にCloudflareの作業を依頼する
  • クライアントごとに別々のドメインを管理している
  • DNS設定、SSL設定、WAF設定などを一部だけ触ってもらいたい
  • 請求情報や他クライアントのドメイン情報は見せたくない
  • 一時的な作業のつもりで強い権限を渡してしまいそうになる

この記事では、複数クライアントのCloudflare管理で気をつけたいポイントを、実務目線で整理します。

Cloudflare管理で起きやすい問題

Cloudflareは非常に便利ですが、アカウント単位・ドメイン単位・機能単位の境界を理解しないまま運用すると、権限が広くなりすぎることがあります。

たとえば、外部作業者にDNS設定を依頼したいだけなのに、アカウント全体の管理権限を付与してしまうと、以下のようなリスクが生じます。

  • 他クライアントのドメイン一覧が見えてしまう
  • 関係のないDNSレコードを変更できてしまう
  • 請求情報や契約情報にアクセスできてしまう
  • WAF、SSL、Pages、Workersなど、本来不要な設定まで変更できてしまう
  • 誰がどの範囲まで作業できるのか、あとから説明しづらくなる

DNSやCDN設定は、1つの変更で本番サイト停止につながることがあります。
そのため、単に「信頼できる人だから権限を渡す」ではなく、必要な対象に、必要な権限だけを渡すという考え方が重要です。

まず理解したいCloudflareの単位

Cloudflareの権限設計では、ざっくり次の3つの単位を意識すると整理しやすくなります。

単位 内容 実務上の見方
User Profile 個人ユーザーのログイン情報・言語設定など 作業者個人のアカウント
Account 複数のドメインやメンバーをまとめる単位 組織・会社・管理単位
Zone Cloudflareに登録された各ドメイン 個別ドメイン単位の設定

Cloudflareでは、1つのAccountの中に複数のZone、つまり複数ドメインを持つことができます。
そのため、1つのAccountに複数クライアントのドメインをまとめて入れると、権限設定を慎重に行わない限り、関係のないドメインまで見えてしまう可能性があります。

避けたい運用：とりあえず管理者権限を渡す

一番避けたいのは、作業を急ぐあまり、外部作業者に強すぎる権限を渡すことです。

たとえば、以下のような運用は危険です。

  • DNSを1件設定してもらうだけなのに、Super Administratorを付与する
  • 一時作業のつもりでAdministrator権限を渡し、そのまま放置する
  • 複数クライアントのドメインが入ったAccountに、広いAccount権限を付与する
  • 退任・契約終了後もメンバー権限が残っている
  • API Tokenを共有アカウントや個人メモで管理している

もちろん、緊急対応では一時的に強い権限が必要になることもあります。
ただし、その場合でも「誰に」「何のために」「いつまで」「どの範囲で」権限を渡したのかを明確にしておくべきです。

基本方針：Account分離を優先する

複数クライアントを扱う場合、まず検討したいのは Account分離 です。

つまり、クライアントや運用主体が異なる場合は、同じCloudflare Accountにドメインをまとめず、Account自体を分ける考え方です。

Account分離のメリット

  • クライアントごとのドメイン情報が混ざらない
  • 作業者に他クライアントの情報を見せずに済む
  • 請求・契約・メンバー管理を分離しやすい
  • 誤操作の影響範囲を限定できる
  • 将来的にクライアントへ管理移管しやすい

Account分離のデメリット

  • アカウント切り替えの手間が増える
  • 初期設定やメンバー管理が増える
  • 共通運用ルールを明文化しないと属人化しやすい

実務上は、少し手間が増えても、クライアントごとにAccountを分けた方が安全なケースが多いです。
特に、請求情報、契約主体、作業者、運用責任が異なる場合は、Account分離を前提に考える方が無難です。

Accountを分けられない場合はDomain Scopeを使う

既に1つのAccountに複数ドメインが入っている場合や、運用上Accountを分けづらい場合は、Cloudflareの権限スコープを利用します。

Cloudflareでは、権限付与を以下のような考え方で整理できます。

  • 誰に付与するか
  • どの役割を付与するか
  • どの範囲に付与するか

この「範囲」が重要です。

Account Scope

Account全体に効く権限です。
このスコープを使うと、そのAccount内の複数ドメインに影響する可能性があります。

請求、メンバー管理、Account全体の設定など、本当にAccount全体の操作が必要な場合に限定するべきです。

Specific Domains

特定ドメインだけに権限を限定する方法です。
外部作業者に特定サイトのDNSだけを触ってもらいたい場合などは、この考え方が適しています。

Domain Groups

関連する複数ドメインをグループ化し、そのグループに対して権限を付与する考え方です。
本番ドメイン群、検証ドメイン群、特定サービス群など、まとまった管理単位がある場合に有効です。

実務でのおすすめ権限設計

Cloudflareの権限設計では、次のように考えると整理しやすいです。

1. 自分または管理責任者

管理責任を持つ人は、必要に応じて強い権限を持ちます。
ただし、Super Administratorを複数人に広げすぎるのは避けた方がよいです。

推奨方針：

  • 最小人数に限定する
  • 退任時・契約終了時の削除ルールを決める
  • 2要素認証を必須にする
  • 共有アカウントではなく個人アカウントで管理する

2. DNS作業だけを依頼する外部作業者

DNS設定だけが必要な場合は、対象ドメインに限定したDNS関連権限を付与します。

推奨方針：

  • Account全体ではなくSpecific Domainsを使う
  • 作業対象ドメインだけを指定する
  • 請求・メンバー管理・他ドメインへのアクセスは付与しない
  • 作業完了後に権限を削除またはRead Onlyへ変更する

3. 調査だけを依頼する外部作業者

調査や状況確認だけであれば、Read Only系の権限で十分なことがあります。

推奨方針：

  • まずRead Onlyで足りるか確認する
  • 変更作業が必要になった段階で一時的に権限を上げる
  • 作業後は元に戻す

4. 請求や契約を扱う担当者

請求担当者には、ドメイン設定の編集権限ではなく、Billing系の権限を検討します。

推奨方針：

  • 技術設定と請求権限を分ける
  • 請求情報を技術作業者に不要に見せない
  • クレジットカード情報や契約情報の扱いを明確にする

チェックリスト

Cloudflareで外部作業者を追加する前に、以下を確認すると安全です。

事前確認

  • 作業対象のドメインはどれか
  • 作業内容はDNS変更か、WAF変更か、SSL設定か
  • Account全体の権限が本当に必要か
  • Read Onlyで足りないか
  • 請求情報を見せる必要があるか
  • 他クライアントのドメインが同じAccountに入っていないか
  • 作業後に権限を削除する予定があるか

権限付与時

  • 共有アカウントではなく、作業者本人のメールアドレスを招待する
  • Specific Domainsで対象ドメインを限定する
  • 必要最小限のRoleを選ぶ
  • Super Administratorは原則付与しない
  • 作業期限や目的をチケット・チャット・メモに残す

作業後

  • 作業者の権限を削除または縮小する
  • DNS変更内容を確認する
  • SSL/TLS、プロキシ状態、リダイレクトなどの影響を確認する
  • Audit Logsで操作履歴を確認する
  • 作業内容をナレッジ化する

ありがちな失敗例

失敗例1：別クライアントのドメインが見えてしまう

1つのAccountに複数クライアントのドメインを入れている状態で、Account全体の権限を付与すると、作業者が関係のないドメインまで見えてしまうことがあります。

対策：

  • クライアントごとにAccountを分ける
  • 難しい場合はSpecific Domainsで対象ドメインを限定する

失敗例2：DNS作業者に請求情報まで見えてしまう

DNS設定を依頼したいだけなのに、広い管理権限を渡すと、請求・契約情報にアクセスできる可能性があります。

対策：

  • 技術作業と請求権限を分ける
  • Billing系権限は必要な担当者だけに限定する

失敗例3：一時権限が放置される

一時的に付与した強い権限が、作業完了後も残り続けることがあります。

対策：

  • 作業後の権限削除を作業手順に含める
  • 定期的にMembers一覧を棚卸しする
  • 契約終了・担当変更時のチェック項目に入れる

運用ルールとして決めておくとよいこと

複数クライアントのCloudflareを扱う場合、以下のようなルールを決めておくと安全です。

1. 原則としてクライアントごとにAccountを分ける

ドメイン、請求、作業者、契約主体が異なる場合は、Account分離を基本にします。

2. 外部作業者には対象ドメインだけ見せる

同じAccount内で運用する場合でも、作業者にはSpecific Domainsで必要なドメインだけを見せます。

3. Super Administratorは最小人数にする

Super Administratorは非常に強い権限です。
日常作業者に付与するのではなく、管理責任者に限定します。

4. 作業完了後に権限を見直す

Cloudflareの作業は一時的なものも多いため、作業完了後に権限を戻す運用が重要です。

5. Audit Logsを確認する

DNSやWAFなどの重要設定を変更した場合は、Audit Logsで操作履歴を確認できるようにしておくと安心です。

まとめ

複数クライアントのCloudflareを管理する場合、便利さだけでなく、権限の見え方と影響範囲を意識する必要があります。

重要なのは、以下の3点です。

  1. クライアントや契約主体が異なる場合は、Account分離を優先する
  2. Accountを分けられない場合は、Specific Domainsで対象ドメインを限定する
  3. 外部作業者には、必要な期間だけ、必要最小限の権限を付与する

Cloudflareの設定変更は、DNS切り替え、SSL、WAF、リダイレクトなど、本番影響が大きい作業につながります。
だからこそ、作業前に「誰に、どの範囲を、どこまで触らせるのか」を整理しておくことが大切です。

権限管理は地味ですが、複数クライアントを扱う情シス・PM・フリーランスにとっては、かなり重要な運用設計の一部だと思います。

参考資料

6
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?