ログ調査ではなく、「最初から入れない」仕組みで解決する
この記事の要点
- 「Gmail や Dropbox に会社アカウント以外でアクセスしているログを取りたい」――CASBツールの Application Events のような機能を思い浮かべていませんか？
- 結論：Cloudflare One の Gateway ログには、宛先SaaS側の実ログインアカウント名を返すフィールドはありません。ログに出るのは常に「Cloudflare One クライアントにログインしている社内メールアドレス」です。
- ただし、同じ課題は**「検知して後から調べる」のではなく「そもそも個人アカウントでログインできなくする」**という方法で、より確実に解決できます。それが Gateway の Tenant Restriction（テナント制限） です。
一言で言うと
「誰が個人アカウントを使ったかを調べる」のではなく、「個人アカウントでは端からログインできない」状態にする。検知より予防、というアプローチです。
よくある要望：「個人アカウント利用のログが欲しい」
SWG/CASB製品の比較検討をしていると、こんな機能イメージを持つことがあります。
- 会社支給の端末から、会社アカウント以外の Gmail や Dropbox にアクセスした形跡をログで見たい
- 「どのサービスに、どの個人アカウントでログインしたか」を一覧で抽出したい
- CASBの「Application Events」のような、宛先アプリ内のアカウント単位の可視化をイメージしている
このアプローチには、Cloudflare One の設計思想を理解する必要があります。
Cloudflare One（Gateway + WARP）のログ仕様
Gateway の HTTP ログにある Email フィールドは、公式ドキュメントで次のように定義されています。
Email address of the user who made the HTTP request. This is generated by the Cloudflare One Client.
つまりこの値は、常に社内の認証基盤（IdP）でログインした社員のメールアドレスです。宛先が Gmail であろうと Dropbox であろうと変わりません。
flowchart LR
U["社員（会社アカウントで<br/>Cloudflare One にログイン）"] -->|"WARP"| GW["Cloudflare Gateway"]
GW -->|"ログのEmailフィールド<br/>= 常に社内アカウント"| LOG[("Gateway ログ")]
GW -->|"HTTPS（TLS）"| SaaS["Gmail / Dropbox 等"]
SaaS -.->|"実際にログインしている<br/>アカウントは中身（暗号化）に依存"| Hidden["個人アカウントかどうかは<br/>ログの標準フィールドに現れない"]「宛先SaaS側で、どのアカウントとしてログインしているか」は、Cloudflareから見るとアプリケーションの中身（セッション情報）の話であり、ネットワーク層・WARPクライアントの識別情報とは別のレイヤーです。ここをログとして機械的に抽出する標準フィールドは用意されていません。
アプローチ：「検知」ではなく「予防」
同じ課題――「会社のSaaSは使わせたいが、個人アカウントは使わせたくない」――に対して、Cloudflareが用意している答えは Tenant Restriction（テナント制限） です。
考え方はシンプルです。
ログを見て「個人アカウントを使った人」を後から探すのではなく、個人アカウントでは最初からログインできないようにする。
そもそも「検知が漏れる／気づくのが遅れる」というリスク自体を排除する設計思想があります。
仕組み：HTTPヘッダーで「許可するテナント」を伝える
Gateway は TLS復号（HTTPSインスペクション）を有効にした上で、SaaSへのリクエストに特定のHTTPヘッダーを付与できます。このヘッダーは「このアクセスは、どの会社（テナント）に属するものか」をSaaS側に伝えるもので、多くの主要SaaSがこの仕組みに対応しています。
sequenceDiagram participant U as 端末（会社アカウントでログイン試行） participant GW as Cloudflare Gateway participant SaaS as SaaS（Google/Dropbox等） U->>GW: Gmailへのログインリクエスト GW->>GW: Allowポリシーに一致<br/>許可テナントのヘッダーを付与 GW->>SaaS: リクエスト + X-GoogApps-Allowed-Domains: 自社ドメイン SaaS-->>U: 会社アカウントでのログイン成功 Note over U,SaaS: 同じ端末で「個人のGmail」を選択した場合 U->>GW: 個人アカウントでのログイン試行 GW->>SaaS: 同じヘッダーを付与して転送 SaaS-->>U: 許可テナントと不一致のため拒否
ポイントは、判定と拒否そのものはSaaS側が行うということです。Cloudflareは「このアクセスは弊社の管理下にある」という証明書（ヘッダー）を渡すだけで、実際に「このアカウントは弊社のテナントではない」と突き返すのはGoogleやDropbox自身です。
主要SaaSの設定例
TLS復号を有効化した上で、対象アプリケーションへの Allow ポリシーに以下のヘッダーを設定します。
| サービス | ヘッダー名 | 値 |
|---|---|---|
| Google Workspace | X-GoogApps-Allowed-Domains |
自社ドメイン |
| Microsoft 365 | Restrict-Access-To-Tenants ほか |
自社テナントID |
| Slack | X-Slack-Allowed-Workspaces ほか |
自社ワークスペース |
| Dropbox | X-Dropbox-allowed-Team-Ids |
自社チームID |
| ChatGPT | Chatgpt-Allowed-Workspace-Id |
自社ワークスペースID |
| Claude | anthropic-allowed-org-ids |
自社組織UUID |
Microsoft 365 のみ、login.live.com（個人Microsoftアカウントの認証エンドポイント）を先に restrict-msa で明示的に制限するポリシーが別途必要になるなど、サービスごとに細かな作法の違いはありますが、基本構造は共通です。
flowchart TD
A["Gateway HTTP ポリシー<br/>(Allow)"] --> B{"宛先アプリケーション<br/>を判定"}
B -->|"Google Workspace"| C1["X-GoogApps-Allowed-Domains<br/>を付与"]
B -->|"Dropbox"| C2["X-Dropbox-allowed-Team-Ids<br/>を付与"]
B -->|"Slack"| C3["X-Slack-Allowed-Workspaces<br/>を付与"]
B -->|"ChatGPT / Claude"| C4["Allowed-Workspace/Org-Id<br/>を付与"]
C1 --> D["SaaS側が自社テナントか判定"]
C2 --> D
C3 --> D
C4 --> D
D -->|"一致"| E["ログイン許可"]
D -->|"不一致（個人アカウント等）"| F["ログイン拒否"]この方法の限界も正直に
Tenant Restriction は強力ですが、万能ではありません。
- 拒否の記録はCloudflare側に残らない：Gateway のログには「ヘッダーを付けて許可した」という記録しか残らず、SaaS側で拒否されたかどうか・どの個人メールアドレスだったかは分かりません。その証跡は Google Workspace / Microsoft 365 / Dropbox の管理コンソール側のサインインログにあります。
- CASB（API連携）でも埋まらない：Cloudflare CASBは自社が契約・接続した正規テナントの中を可視化するもので、他人の個人アカウントでの利用そのものを検知する機能ではありません。
- 未対応のSaaSには使えない：ヘッダーによるテナント制限に対応しているのは、対応が明記された主要SaaS（Google Workspace、Microsoft 365、Slack、Dropbox、ChatGPT、Claude など）に限られます。
つまり、「誰が・いつ・どの個人アカウントを使おうとしたか」を事後的に一覧で見たい、という要件そのものには、Cloudflare One は正面から答える機能を持っていません。「使わせない」を確実にすることで、実質的に同じ課題を解決する、という設計思想の違いを理解しておくことが重要です。
| やりたいこと | 対応状況 |
|---|---|
| 個人アカウントでのアクセスを防ぐ | ○ Tenant Restriction で実現可能 |
| 個人アカウントでアクセスした記録を一覧抽出 | × 標準ログには存在しない項目 |
まとめ
- 「個人アカウント利用のログが欲しい」という要望は、CASBの発想（検知・可視化）から来ることが多い
- Cloudflare Gateway のログの
Emailは常に社内の認証アカウントであり、宛先SaaSの実ログインアカウントとは別物 - Cloudflareが提供するのは検知ではなく Tenant Restriction（個人アカウントのログインそのものを拒否）
- 「気づく」よりも「そもそも起きない」状態を作れる点で、運用上はむしろ安心感が高い
- 事後の証跡が必要な場合は、SaaS側の管理コンソール（サインインログ）と組み合わせる
「使われているかもしれない」から「使えない」へ。検知の仕組みを探す前に、まず入口を締める設定から検討してみてください。