Cloudflare Gateway（ゼロトラスト）

解決する課題

• 従来型の拠点VPNやハードウェアプロキシでは、拠点外や自宅勤務のトラフィックを一元的に検査できない
• マルウェア・フィッシング・C2通信先などの既知の悪性ドメイン/IPへのアクセスを、端末や拠点を問わず遮断したい
• 暗号化されたHTTPS通信の中身を検査できず、脅威やデータ持ち出しを見逃してしまう
• シャドーIT（未承認SaaS）の利用実態が見えず、アプリケーション単位でのアクセス許可/禁止ができない
• セキュリティポリシーを拠点ごと・機器ごとにバラバラに設定しており、統一的な適用や監査が難しい

主要概念と用語

• Cloudflare Gateway: DNS・HTTP(S)・ネットワーク（L4/L7）の各層でトラフィックを検査し、フィルタリングポリシーを適用するセキュアウェブゲートウェイ（SWG）。Cloudflare Oneの構成要素
• DNSポリシー: 名前解決の時点でドメインをカテゴリや脅威インテリジェンスに基づき許可/ブロックする最も軽量なフィルタリング層
• HTTPポリシー: TLSインスペクション（複合化）を行い、URLカテゴリ・アプリケーション・ファイルタイプ・アップロード/ダウンロード内容などに基づき通信を制御する層
• ネットワークポリシー: IP/ポート/プロトコル単位でトラフィックを許可/拒否するL4/L7のファイアウォールポリシー
• WARPクライアント: 端末にインストールするエージェントで、トラフィックをCloudflareのエッジへ転送しGatewayやAccessのポリシーを適用させる
• GRE/IPsecトンネル、CNI: 拠点ルーターやクラウド環境からネットワーク全体のトラフィックをCloudflareへ誘導する接続方式
• TLSインスペクション（HTTPS復号）: Gatewayが発行するルート証明書を端末に配布し、HTTPSの内容を復号して検査した上で再暗号化する仕組み
• DLP（データ損失防止）/CASB: Gatewayと連携し、機密データの送信検知やSaaSアプリの設定リスク検出を行う関連コンポーネント
• Cloudflare One: Gateway・Access・WARP・DLP・CASB・Cloudflare WANなどを束ねるSASE（Secure Access Service Edge）プラットフォーム

仕様・制限・クォータ

• GatewayはDNS/HTTP/ネットワークの3種類のポリシーを組み合わせて運用し、それぞれ評価順序と適用範囲が異なる
• HTTPポリシーでのTLSインスペクションには、端末へのルート証明書配布とWARPクライアントの証明書検証設定が必要
• ポリシーは**ID/デバイス/場所（ロケーション）などの条件（セレクター）**で対象を絞り込んで適用できる
• ログ（Gateway活動ログ）の保持期間や詳細度はプランにより異なり、SIEM連携でのログ転送も選択できる
• 対応プラットフォーム、同時接続数、ポリシー数などの具体的な上限値はプランや契約により変動するため、最新の公式ドキュメントで確認する
• オンプレミス拠点はGREまたはIPsecトンネル、クラウド環境はCNIなど、環境に応じた接続方式が用意されている

内部の仕組み

Gatewayは、端末や拠点からのトラフィックをCloudflareのエニーキャストネットワーク（エッジ）に誘導したうえで検査します。誘導方法は主に3つあり、端末にはWARPクライアント（デバイスプロファイルに応じたポリシー適用が可能）、拠点ネットワークにはGRE/IPsecトンネル、クラウド環境の仮想ネットワークにはCNIを用います。

トラフィックがエッジに到達すると、まずDNSポリシーが評価され、名前解決の段階で脅威インテリジェンスやカテゴリに基づき危険なドメインをブロックします。DNSを通過した通信のうちHTTP(S)については、HTTPポリシーが評価されます。ここでは、Gatewayが発行したルート証明書を使ってTLSセッションを一度復号し、URL・アプリケーション・ファイルタイプ・アップロード/ダウンロードの中身を検査したうえで、再度暗号化して宛先へ転送します。DNSやHTTPでカバーしない任意のプロトコル/ポートの通信には、ネットワークポリシーでL4/L7レベルの許可・拒否を適用します。

これらのポリシーは、ユーザーID・グループ・デバイスの状態（デバイスポスチャ）・接続元の場所といった条件（セレクター）で絞り込んで定義でき、Cloudflare Accessの認証情報と組み合わせることで、ユーザーごとにきめ細かい制御が可能になります。検査結果とアクセスログはCloudflare One内で集約され、可視化やSIEM連携に利用できます。

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

• まずはDNSポリシーから段階的に導入し、影響範囲を確認しながらHTTP・ネットワークポリシーへ拡張する
• TLSインスペクションは業務影響の大きいカテゴリ（金融・医療など）を除外するなど、除外リストを用意してから全体展開する
• デバイスポスチャ（OSバージョン・ディスク暗号化状態など）を条件に組み込み、信頼度に応じたポリシーを適用する
• Cloudflare Accessと組み合わせ、Gatewayによるネットワーク層の制御とAccessによるアプリ単位の認可を役割分担させる
• ポリシーは最小権限・既定拒否を基本方針にし、業務上必要な通信のみを明示的に許可する
• ロールアウトは限定グループでのパイロット運用から始め、誤検知やパフォーマンス影響を検証してから全社展開する

運用・監視

• Gateway活動ログでDNS/HTTP/ネットワークの各判定結果を確認し、誤ブロックや想定外の通信を追跡する
• ログはSIEMやログ転送先（Cloudflare LogpushなどCloudflare One内の連携機能）へ送り、既存の監視基盤と統合する
• ポリシー変更は監査ログに記録されるため、誰がいつ何を変更したかを追跡できるようにする
• TLSインスペクションの証明書配布状況や、WARPクライアントの導入率を継続的にモニタリングし、未適用端末を把握する
• 新しい脅威カテゴリやSaaSアプリの追加に合わせて、ポリシーを定期的にレビュー・更新する

コスト

セキュリティ

• 既知の悪性ドメイン・IP・フィッシングサイトへの通信をDNS/HTTP層でブロックし、初期侵入や情報流出を防ぐ
• TLSインスペクションにより暗号化通信内の脅威やポリシー違反を可視化し、検査の盲点を減らす
• Cloudflare Accessと連携したゼロトラストアクセス制御（暗黙の信頼を置かない設計）をネットワーク層で実現する
• DLP/CASBとの連携で、機密データの持ち出しや未承認SaaSの利用を検知・抑制する
• 管理者権限は最小権限の原則で運用し、ポリシー変更は監査ログで追跡可能にする
• デバイスポスチャチェックにより、セキュリティ要件を満たさない端末のアクセスを制限できる

関連サービス・比較

ハンズオン / CLI例

# 1. wrangler でCloudflareアカウントにログイン
wrangler login

# 2. Gateway向けのDNSロケーション一覧を確認（Cloudflare One APIをwrangler経由で呼び出す例）
wrangler login && curl -s -X GET \
  "https://api.cloudflare.com/client/v4/accounts/<account-id>/gateway/locations" \
  -H "Authorization: Bearer <api-token>"

# 3. DNSフィルタリングポリシー（例: 既知のマルウェアカテゴリをブロック）を作成
curl -s -X POST \
  "https://api.cloudflare.com/client/v4/accounts/<account-id>/gateway/rules" \
  -H "Authorization: Bearer <api-token>" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "block-malware",
    "action": "block",
    "filters": ["dns"],
    "traffic": "any(dns.security_category[*] in {\"malware\"})"
  }'

# 4. 作成済みGatewayルールの一覧を確認
curl -s -X GET \
  "https://api.cloudflare.com/client/v4/accounts/<account-id>/gateway/rules" \
  -H "Authorization: Bearer <api-token>"