Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

トラフィックポリシー

最終更新 Markdown で表示Agent セットアップ

Secure Web Gateway（SWG）は、組織のユーザーとインターネットの間に置くセキュリティサービスです。送信トラフィックを検査し、セキュリティポリシーの適用、脅威のブロック、データ漏洩の防止を行います。SWG の主な機能は次のとおりです。

  • URL とドメインのフィルタリング – ユーザーがアクセスできる Web サイトを制御します。
  • マルウェアスキャン – 転送中のファイルに悪意のあるコードがないか検査します。
  • アプリケーション制御 – ユーザーが使えるアプリケーションと、実行できる操作を管理します。
  • Data Loss Prevention（DLP） – 機密データがネットワークから出る前に検出してブロックします。
  • トラフィック検査 – 暗号化された（HTTPS）トラフィックを復号し、隠れた脅威を調べます。

SWG が必要な理由

従来のネットワークセキュリティは、社内ネットワークの境界にあるハードウェアファイアウォールに依存していました。そのモデルは、ユーザー、アプリケーション、データが同じネットワーク境界の内側にあることを前提にしていました。現在の組織が直面する状況は異なります。

  • 分散した働き方 – 従業員は自宅ネットワーク、公衆 Wi-Fi、モバイルデバイスから接続し、社内境界の外にいます。
  • クラウドと SaaS の導入 – 業務に不可欠なアプリケーションとデータは、Microsoft 365、Google Workspace、Salesforce などのクラウドへ移っています。
  • 脅威面の拡大 – フィッシング、ランサムウェア、コマンドアンドコントロール（C2）ボットネット、データ持ち出しの試みは、場所を問わずユーザーを狙います。

SWG がないと、ユーザーがどの Web サイトやアプリケーションにアクセスしているか、どの脅威がデバイスに届いているか、どのデータが組織から出ているかを把握できません。SWG は、すべてのトラフィックを中央のデータセンターに集めるのではなく、ユーザーに近いクラウドで検査することで、その可視性と制御を取り戻します。

Cloudflare Gateway は Cloudflare の SWG であり、Cloudflare One ↗ SASE プラットフォームに組み込まれています。DNS、ネットワーク（レイヤー 4）、HTTP（レイヤー 7）でトラフィックを検査し、フィルタリングします。

SWG の仕組みについて詳しくは、Cloudflare Learning Center ↗ を参照してください。

トラフィックポリシーの種類

どの組織でも、インターネット上でユーザーが到達できる先を制御する必要があります。マルウェアサイトのブロック、リスクの高いアプリケーションの制限、社内ネットワークからのトラフィックの出口の決め方です。トラフィックポリシーは、通過を許可する前に、トラフィックの異なる層を検査するセキュリティチェックポイントだと考えてください。

Gateway と従来のファイアウォールの関係

従来のネットワークセキュリティに慣れている場合、Gateway のポリシー層は次のように対応します。

  • DNS ポリシーは、DNS 層のフィルタリングに相当します（接続が確立される前にドメインをブロックします）。
  • ネットワークポリシーは、レイヤー 4 のステートフルファイアウォール（Firewall-as-a-Service（FWaaS）とも呼ばれます）に相当し、IP アドレス、ポート、プロトコルでフィルタリングします。
  • HTTP ポリシーは、レイヤー 7 のアプリケーションファイアウォール（TLS 復号と詳細なパケット検査を行うフォワードプロキシ）に相当します。

単一のネットワーク境界に置くハードウェアファイアウォールと異なり、Gateway はこれらのポリシーを Cloudflare のグローバルネットワーク全体で適用します。ユーザーがどこから接続してもトラフィックを保護します。

Gateway が複数のポリシー種別を用意しているのは、ネットワークトラフィックを生パケットから完全な HTTP リクエストまで、異なる層で検査できるからです。各ポリシー種別は、特定の層で制御を与えます。

パケットフィルタリング

パケットフィルタリング は、生のネットワークパケットを検査し、送信元 IP アドレスやプロトコルなどの属性に基づいてトラフィックをブロックします。ユーザーが誰か、どのセッションに属するかは知る必要がありません。

ほかのポリシーに届く前に、不要なトラフィックを落とすために使います。

DNS ポリシー

DNS ポリシー は、ユーザーが行うすべての DNS クエリを確認します。クエリがポリシールールに一致すると、Gateway はそのドメインの名前解決をブロックできます。ドメイン名が IP アドレスに変換されないため、サイトは読み込まれません。

DNS ポリシーは接続の最も早い段階、コンテンツを取得する前に働きます。そのため、導入が最も速く、適用範囲も最も広いポリシー種別です。DNS フィルタリング ↗ について詳しくは、Cloudflare Learning Center を参照してください。

悪意のあるドメインのブロック、コンテンツカテゴリの制限、サイト全体の読み込み防止に使います。脅威対策を十分にするには、DNS ポリシーと HTTP ポリシーを組み合わせてください。DNS は既知の危険なドメインをブロックし、HTTP は許可したトラフィックに潜む脅威を捕捉します。

ネットワークポリシー

ネットワークポリシー は、個々の TCP、UDP、Generic Routing Encapsulation（GRE）パケットを検査します。IP アドレス、ポート、プロトコル、暗号化接続の開始時に送られるサーバー名（Server Name Indication、SNI）で一致できます。

特定のポートや、SSH や RDP などの非 HTTP サービスへのアクセスをブロックするために使います。

HTTP ポリシー

HTTP ポリシー は、Web リクエストの内容全体（URL、ヘッダー、アップロードまたはダウンロードされたファイル）を検査します。Gateway は HTTPS トラフィックを復号し、DNS ポリシーやネットワークポリシーでは見えない内容を調べます。そのため、ユーザーデバイスに Cloudflare ルート証明書 をインストールする必要があります。

特定 URL のブロック、ファイルアップロードの機密データスキャン、ダウンロード内のマルウェアのブロック、サンドボックス分析のための 疑わしいファイルの隔離、ユーザーがサインインできるアカウントの制御に使います。たとえば、会社の Google Workspace アカウントは許可し、個人の Gmail はブロックします。

エグレスポリシー

エグレスポリシー は、組織に属する固定 IP アドレスを割り当てて、トラフィックがネットワークから出る方法を制御します。サードパーティのサービスは、これらの IP を自組織のものとして認識できます。

既知の IP アドレス一覧からのトラフィックだけを許可するパートナーやサービスに接続するために使います。

リゾルバーポリシー

リゾルバーポリシー は、デフォルトの Cloudflare リゾルバーではなく、特定の DNS サーバーへ DNS クエリを送ります。

社内ネットワークのプライベートホスト名の解決、コンプライアンスのための自前 DNS サーバーへの照会、Cloudflare One 経由で接続しているときの内部リソースへの到達に使います。

アイデンティティとデバイスのコンテキスト

Gateway ポリシーは、ドメイン、IP、ポートといったネットワーク属性だけでなく、ユーザーのアイデンティティとデバイスの健全性を判断に含められます。

Cloudflare One Client 経由で接続しているとき、Gateway は次を評価できます。

  • ユーザーアイデンティティ – ID プロバイダー（例: Okta、Microsoft Entra ID、Google Workspace）からのメールアドレス、グループ所属、認証方式。
  • デバイスポスチャ – OS のバージョン、ディスク暗号化の状態、ファイアウォールの状態、デバイスのシリアル番号が管理対象デバイス一覧と一致するか、などのシグナル。利用できるチェックの一覧は Device posture を参照してください。

これらのシグナルをトラフィックセレクターと組み合わせて、状況に応じたポリシーを作れます。たとえば、特定グループに属するユーザーで、かつデバイスのディスク暗号化がオンのときだけ、機密性の高い SaaS アプリケーションへのアクセスを許可する HTTP ポリシーを作れます。

アイデンティティセレクターを使ったポリシーの作り方は、アイデンティティベースのポリシー を参照してください。

Cloudflare Gateway のトラフィックポリシーを設定する

Cloudflare Gateway のトラフィックポリシーを作る前に、保護したいデバイスまたはネットワークを接続し、Cloudflare Gateway がそのトラフィックを検査できることを確認します。各トラフィックポリシー種別で、次の流れに従います。

  1. 保護したいデバイスまたはネットワークを接続します。
  2. Gateway がデバイスからのトラフィックを受信していることを確認します。
  3. 推奨のセキュリティポリシーを設定します。例: DNS ポリシーですべての セキュリティ脅威カテゴリ をブロックします。
  4. 組織固有のポリシーを追加します。

たとえば、既知のマルウェアドメインへの従業員アクセスを防ぎたい場合は、まず Cloudflare One Client でデバイスを登録し（手順 1）、Gateway ログに DNS クエリが出ることを確認し（手順 2）、すべてのセキュリティリスクカテゴリをブロックする DNS ポリシーを作成します（手順 3）。

手順ごとの設定ガイドは、DNS、ネットワーク、HTTP の各ポリシーを参照してください。

Cloudflare Gateway のポリシー種別の選び方

次の表は、よくあるトラフィックフィルタリングの目的と、適した Cloudflare Gateway のポリシー種別を対応づけています。

フィルタリングの目的 ポリシー種別 理由
URL で Web サイトをブロックする HTTP ドメインだけでなく、URL パス全体を検査します
ドメイン（全ページ）をブロックする DNS ドメインの名前解決自体を防ぎます
非 HTTP トラフィック（SSH、RDP）をブロックする ネットワーク 任意のポートの TCP/UDP パケットを検査します
マルウェアと脅威をブロックする DNS と HTTP DNS は既知の危険なドメインをブロックします。HTTP は許可したトラフィック内の脅威を捕捉します。
静的なエグレス IP を割り当てる エグレス サードパーティのサービスが組織を識別できます
ほかのポリシーが動く前にトラフィックを落とす パケットフィルタリング ユーザーコンテキストなしで、パケット属性によってブロックします
カスタムネームサーバーへ DNS を向ける リゾルバー デフォルトの Cloudflare リゾルバーを上書きします

Cloudflare Gateway のポリシー種別を選んだら、目的に合うポリシーを作るため、対応する設定ガイドへ進んでください。

接続方法を選ぶ

使う接続方法（オンランプ）によって、Gateway が適用できるポリシー種別が決まります。各方法の概要は次の表のとおりです。

接続方法 DNS ポリシー ネットワークポリシー HTTP ポリシー 適した用途
Cloudflare One Client（WARP） はい はい はい 管理対象デバイス（ノート PC、スマートフォン）上の外出先ユーザー
DNS resolver の設定 はい いいえ いいえ 非管理対象デバイス、ネットワーク全体、または初期展開
Proxy endpoint（PAC ファイル） いいえ いいえ はい（ブラウザーのみ） デバイスエージェントなしのブラウザー単位の HTTP フィルタリング
Network tunnel（Magic WAN 経由の IPsec/GRE） はい はい はい 支社、データセンター、サイト単位の接続
  • Cloudflare One Client は最も広い範囲をカバーし、デバイス単位の導入で推奨される方法です。
  • DNS resolver の設定は導入が最も簡単です（ルーターまたはデバイスの DNS 設定を変えるだけ）。すぐに保護できますが、適用されるのは DNS ポリシーだけです。
  • Proxy endpoint はエージェントを入れずにブラウザーのプロキシ設定で HTTP 検査を有効にしますが、対象はブラウザーのトラフィックに限られます。
  • Network tunnel はサイトのすべてのトラフィックを Gateway 経由にし、オフィス全体やデータセンターの保護に適しています。

複数のオンランプを組み合わせられます。たとえば、リモート従業員には Cloudflare One Client、支社には network tunnel を使います。

Gateway がトラフィックを処理する流れ

ユーザーがリクエストを送ると、Gateway は接続を通す前に複数の層で検査します。エンドツーエンドの流れは次の図のとおりです。

flowchart LR
    accTitle: Gateway のトラフィックフロー
    accDescr: ユーザデバイスからオンランプを経て Cloudflare Gateway でポリシー評価され、宛先へ向かうトラフィックの流れを示す図。

    A["ユーザーデバイス"] --> B["オンランプ"]
    B --> C["Cloudflare エッジ<br/>（最寄りの拠点）"]
    C --> D["ポリシー評価"]
    D --> E["宛先<br/>サーバー"]
    E --> D
    D --> C
    C --> B
    B --> A
  1. ユーザーのデバイスがリクエスト（DNS クエリ、TCP 接続、または HTTP リクエスト）を送ります。
  2. リクエストはオンランプ（Cloudflare One Client、DNS resolver の設定、proxy endpoint、または network tunnel）経由で Cloudflare に届きます。
  3. Cloudflare は中央のデータセンターではなく、最寄りのエッジ拠点でリクエストを処理します。ユーザーがどこから接続しても、遅延を低く保てます。
  4. Gateway は、設定したポリシーを 適用順 で評価します。先に DNS ポリシー、次にネットワークポリシー、最後に HTTP ポリシーです。
  5. ポリシーがリクエストを許可すると、Gateway は宛先サーバーへプロキシし、戻り経路でも応答を検査します。

Gateway がトラフィックをプロキシし、接続を確立する仕組みは Proxy を参照してください。

Cloudflare Gateway ポリシーのトラブルシューティング

Cloudflare Gateway ポリシーのよくある問題の解決は、トラブルシューティング を参照してください。

役に立ちましたか？