ゲスト無線ネットワークの保護

多くの組織や企業は、顧客、クライアント、患者、学生、来訪者に無料の無線インターネットアクセスを提供しています。ホスピタリティ業界では、ゲスト Wi-Fi の提供が不可欠なことがよくあります。大学や短大では、信頼できて安全な Wi-Fi サービスが、入学希望者や来訪者を惹きつける大きな要因になることがあります。

無料の無線インターネットアクセスには、いくつかの利点があります。企業はゲスト Wi-Fi を使い、ランディングページへ誘導してマーケティングキャンペーンを実施したり、クーポンを提供したりして、顧客との接点を増やします。さらに、多くのゲスト Wi-Fi システムは、メールアドレス、閲覧行動、特定の場所での滞在時間など、有用なユーザー分析を収集します。このデータは、店舗での商品配置の判断や、フォローアップのメールマーケティングに役立ちます。

一方で、ゲスト Wi-Fi の提供にはリスクもあります。悪意のある利用者が、禁止コンテンツへのアクセス、違法な物品の購入、サイバー犯罪など、違法行為にネットワークを使う恐れがあります。ホテル、カフェ、図書館などが、ゲスト Wi-Fi 経由の違法ダウンロードを可能にしたとして訴訟を起こされた例もあります。著作権者が起こすこうした訴訟では、ゲストがアクセスまたはダウンロードしたコンテンツを監視・制御しなかったために、企業が海賊行為を助長したと主張されることがあります。

組織が刑事責任を問われる可能性は低いかもしれません。ただし、長期の捜査に巻き込まれ、法的費用や評判の低下につながることはあります。このガイドでは、Cloudflare を使ってリスクを下げ、ゲストのインターネット利用を可視化し、ゲスト無線ネットワークをより安全にする ↗方法を説明します。

このリファレンスアーキテクチャは、Cloudflare を使ってゲスト無線ネットワークを保護したい IT 担当者やセキュリティ担当者向けです。Cloudflare の基礎をより深く理解するには、次の資料をおすすめします。

• Cloudflare とは | Web サイト ↗（5 分で読めます）または 動画 ↗（2 分）
• Cloudflare Zero Trust | https://www.cloudflare.com/zero-trust/ ↗
• Cloudflare の SASE アーキテクチャ | /reference-architecture/architectures/sase/

このリファレンスアーキテクチャガイドでは、次の内容を理解できます。

1. Cloudflare Gateway DNS: 一般的なゲスト無線の構成に、Cloudflare Gateway DNS ポリシーを組み込む方法を学びます。
2. DNS ポリシーのベストプラクティス: 利用規定を適用し、悪意のある行為を防ぐゲスト無線向け DNS ポリシーの作り方を紹介します。
3. 可視化とセキュリティの強化:

• Cloudflare Zero Trust ダッシュボードで詳細なログと分析を確認し、DNS クエリ、トラフィックパターン、潜在的なセキュリティ上の脅威を把握します。
• Logpush を有効にして、ログを外部ストレージへエクスポートし、長期分析やコンプライアンスに使います。
• SIEM（Security Information and Event Management）プラットフォームと連携し、Cloudflare のログを他のセキュリティデータと突き合わせて、インシデントの検知と対応を効率化します。

Cloudflare は、Zero Trust のお客様向けに、保護機能を強化した DNS リゾルバーサービスを提供しています。このサービスは Anycast を使います。Anycast は、複数のサーバーやデータセンターが同じ IP アドレスを共有できるルーティング技術です。Anycast IP アドレスへリクエストを送ると、ルーターは Border Gateway Protocol（BGP）を使って、最も近いサーバーへリクエストを向けます。その結果、DNS クエリは常に、所在地から最も近い Cloudflare データセンターへルーティングされます。Cloudflare は over 330 cities にデータセンターを持ち、世界最大級のグローバルネットワーク ↗のひとつです。このサービスでは、悪意がある、疑わしい、または不適切な宛先への DNS 解決をフィルタするポリシーも作れます。組織のセキュリティを強化できます。このガイドでは、このサービスを有効にし、ゲスト無線ネットワークを保護する環境を設定して、組織のリスクを下げる方法を説明します。

Cloudflare の DNS ロケーションは、オフィス、自宅、データセンターなどの物理的な場所に対応付けできる DNS エンドポイントの集まりです。Gateway は、DNS クエリのプロトコルに応じてロケーションを識別します。IPv4 トラフィックは、DNS クエリの送信元 IP アドレスで識別します。IPv6 トラフィックは、Cloudflare ダッシュボードで作成する一意の IPv6 リゾルバーアドレスで識別できます。以降のセクションでは、ネットワーク環境と利用プロトコルに応じて、DNS クエリを物理ロケーションへ正しく対応付ける方法を説明します。この文書の後半では、ロケーションの IP アドレスを属性として Gateway DNS ポリシーに適用する方法も説明します。

目標は、Wi-Fi ネットワークからの DNS リクエストを、Cloudflare のセキュア DNS とセキュア Web ゲートウェイサービス経由で送ることです。そこで DNS ポリシーがリクエストをフィルタし、リスクがあると判断したものをブロックできます。このガイドでは、ゲストネットワーク向けに考えられるネットワーク構成を順に説明し、ゲスト Wi-Fi 上のデバイスを Cloudflare で保護する方法を示します。

ゲスト無線アクセスを提供する一般的な方法は、社内ネットワークや本番ネットワークから完全に分離したネットワークを用意することです。たとえば、支店や小売店では、1 台の無線ルーターでこれを実現することがあります。ルーターはゲスト無線の Service Set Identifier（SSID）を発信し、接続デバイスに IP アドレスを割り当て、インターネット接続を提供します。ルーターに割り当てられたパブリックな静的 IPv4 アドレスは、Cloudflare Zero Trust ダッシュボードで DNS ロケーションの属性として使えます。ISP がルーターの IP アドレスを動的に割り当てる場合は、「専用 DNS リゾルバーの IPv4 および IPv6 アドレス」のセクションを参照してください。

すべての DNS クエリを Cloudflare 経由にするには、ルーターの WAN インターフェースの DNS 設定を、Cloudflare のリゾルバー IP アドレスに更新します。Zero Trust 向けの具体的なリゾルバー IP は、Cloudflare ダッシュボードの DNS ロケーション設定にあります。WAN インターフェースの更新手順は、ルーターメーカーのドキュメントを参照してください。通常、Wi-Fi で接続したデバイスは、DNS サーバーとしてルーターの IP アドレスを使います。ルーターは、それらの代理で DNS クエリを Cloudflare へ転送します。その結果、無線デバイスからの DNS クエリは Cloudflare へ送られ、送信元はルーターに割り当てられた静的 IP アドレスになります。

セキュリティを高めるには、対応している場合、ルーター上にファイアウォールルールを作り、無線ゲストが他の DNS サービスへアクセスできないようにします。このルールでは、Cloudflare の DNS サーバーへのアクセスだけを許可し、UDP/TCP ポート 53 の他の DNS 宛先をすべてブロックします。さらに、一部の高機能な無線ルーターはコンテンツフィルタに対応しています。使える場合は、DNS over TLS（DoT）や DNS over HTTPS（DoH）をブロックするオプションを有効にして、エンドポイントが Cloudflare で設定した DNS セキュリティを迂回できないようにします。

コンシューマー向けやセミプロ向けの一体型無線ルーターにとどまらず、既存のエンタープライズネットワーク上にゲスト Wi-Fi を載せる企業もあります。たとえば、同じ Wi-Fi アクセスポイントのハードウェアが、社内ネットワークとゲストネットワークの両方を発信することがあります。

社内ネットワークとゲストネットワークを分ける一般的な方法は、別々の SSID を使うことです。社内向けのコーポレート SSID とゲスト無線 SSID を、別々の VLAN（Virtual Local Area Network）または Dot1q タグ ↗ に紐付けると、ネットワーク間を仮想的に分離できます。

この構成では次のようにします。

1. ゲスト無線 VLAN にサブネットを割り当てます。
2. そのサブネットのデフォルトゲートウェイを、ファイアウォールやルーターなど上流ネットワーク機器のインターフェース（または仮想インターフェース）に設定します。
3. この機器が、ゲストネットワークトラフィックと社内ネットワークトラフィックを分離し、パブリックインターネットへのセキュアなゲートウェイとしても動作します。

より単純な構成と同様に、ゲスト無線デバイスからの DNS クエリは、Cloudflare のリゾルバー IP へ転送します。次の方法で実現できます。

• ゲストデバイス向けの DHCP スコープに Cloudflare DNS サーバーを割り当てる。
• 上流のネットワーク機器が、DNS クエリを Cloudflare へプロキシする。

ゲストデバイスに一部の社内リソースへのアクセスも提供する場合は、クライアントが内部 DNS サービスを使うように設定することもあります。このサービスを、インターネット向けの DNS リクエストを Cloudflare へ転送するように設定することもできます。

セキュリティを高めるには、アウトバウンドのインターネット向けファイアウォールルールを設定し、TCP/UDP ポート 53 では Cloudflare のエンタープライズリゾルバー IP への DNS クエリだけを許可します。

ゲストトラフィックの送信元を一意のパブリック IPv4 アドレスにするには、次のようにします。

1. ファイアウォールまたはエッジ機器で、ゲストトラフィック専用の Port Address Translation（PAT）ポリシーを作成します。
   • PAT（または NAT overload）により、ローカルネットワーク上の複数デバイスが、1 つのパブリック IP アドレスを使ってインターネットへアクセスできます。
2. ファイアウォール設定で、送信元アドレス範囲をゲストサブネットにします。
3. 変換後の送信元アドレスとして、ゲストネットワークから出るすべてのインターネット向けトラフィックに使うパブリック IPv4 アドレスを指定します。

PAT または NAT overload ルールの設定手順は、ファイアウォールメーカーのドキュメントを参照してください。

ゲストネットワークトラフィックに一意のパブリック IPv4 アドレスを割り当てたら、このアドレスを Cloudflare ダッシュボードの属性として使い、DNS ロケーションを対応付けます。

エッジ機器で静的なパブリック IP アドレスを使えない場合、Cloudflare は組織専用に割り当てられる専用 IPv4 および IPv6 リゾルバーエンドポイントアドレスを提供します。この場合、DNS クエリの宛先アドレスを、物理ロケーションを Cloudflare DNS エンドポイントへ対応付ける手段として使えます。

Cloudflare は、Zero Trust ダッシュボード経由で、固有の IPv6 リゾルバーエンドポイントアドレスを無償で提供します。一方、IPv4 アドレスは数が限られるため、専用 IPv4 DNS エンドポイントは Cloudflare Enterprise プランでのみ利用できます。

たとえば、ゲスト無線ルーターに ISP が IPv6 アドレスと IPv6 DNS サーバーを動的に割り当てる場合、IPv6 DNS アドレスを、Cloudflare の DNS Location 設定で構成した IPv6 DNS エンドポイントアドレスに変更できます。

Cloudflare の DNS リゾルバーへ DNS クエリを送る方法と、送信元 IP アドレスまたは専用リゾルバーアドレスで組織のゲスト無線ネットワークを識別する方法を説明しました。これで、Zero Trust に新しいロケーションを作成できます。

まず、Zero Trust ダッシュボードで DNS Locations を開きます。手順の詳細は、DNS Locations ガイドを参照してください。IPv4 または IPv6 のエンドポイントフィルタとロケーション照合を使う場合、CIDR 表記でネットワークとサブネットマスクを定義し、ロケーションの送信元 IP アドレスを表せます。たとえば次のようにします。

• すべての無線ネットワークが同じサブネット内のパブリック IP アドレスを共有している場合、1 つの DNS ロケーションオブジェクトで、すべてのロケーションに一度にポリシーを適用できます。
• 特定のロケーションに固有のポリシーを割り当てる場合は、/32 で終わるホストアドレスを使い、各ロケーションを個別に表します。

まず、Zero Trust ダッシュボードでファイアウォールポリシーを開き、DNS を選びます。手順の詳細は、DNS ポリシー ガイドを参照してください。

ポリシーを整理しやすくするには、目的が分かる名前を使うことをおすすめします。たとえば、Guest-Security-Block という名前は次を表します。

• Guests: ポリシーの対象。
• Security: 評価するコンテンツの種類。
• Block: 実行するアクション。

Cloudflare は、さまざまな種類の脅威をフィルタできるマネージドカテゴリを提供しています。たとえば、DNS ポリシーに セキュリティカテゴリ の Malware を追加すると、接続デバイスが、Cloudflare がマルウェアキャンペーンの一部、またはマルウェアをホストしているとしてタグ付けしたサイトへ DNS リクエストを送れなくなります。セキュリティカテゴリに加え、Cryptocurrency、P2P 共有サイト、アダルト向けサイトなどを識別する コンテンツカテゴリ もあります。Cloudflare は アプリケーション のリストも管理しているため、パブリッククラウドストレージやファイル共有サイトへのアクセスもフィルタできます。

Cloudflare では カスタムフィード も使えます。他ベンダーのサイトリストを購読してフィルタしたり、組み込みの政府系脅威フィードを使ったりできます。フィルタするサイトを細かく選べます。

既知の DNS ロケーションからリクエストするデバイスでは、これらをポリシーに追加することもできます。ゲスト Wi-Fi のロケーションごとに異なるポリシーを作れます。特定種類のインターネットサイトへのアクセスを防ぐよう現地法で求められる場合に役立ちます。

ポリシーは複数のルールで構成できます。1 つのポリシーで、リスクの高い Web サイトと不適切なコンテンツの両方へのアクセスを防げます。

Cloudflare には、インターネットトラフィックを保護する実装ガイド に追加の推奨 DNS ポリシーがあります。これらのポリシーは組織全体のセキュリティを高めるためのもので、社内の本番 Web トラフィック向けポリシーを設定するときにも考慮してください。

DNS トラフィックを Cloudflare 経由にし、無線ネットワークを保護したら、ログと高度なロギングツールで、ゲストのインターネット利用を詳しく把握できます。すべての DNS リクエストは Cloudflare に 記録 され、ダッシュボードにはシンプルな検索画面があります。これらのログは、ポリシーの適用状況を理解し、ゲストのインターネット利用の傾向やパターンを見つけるのに役立ちます。セキュリティ設定を調整するための具体的な手がかりになります。

高度なテレメトリとデータの管理には、Cloudflare ダッシュボードで Logpush を有効にすることを検討してください。ログを外部、多くの場合は SIEM プラットフォームへ送ると、次の利点があります。

• 集中分析: 複数の Cloudflare サービスからのログを、他の組織データと SIEM にまとめ、全体を把握できます。
• 脅威検知の強化: DNS の動きを他のセキュリティイベントと突き合わせ、悪意のある行為のパターンをより効果的に検知できます。
• コンプライアンスと監査への備え: DNS ログを長期保管し、規制要件への対応やインシデント監査に使えます。
• リアルタイムアラート: SIEM 連携を使い、不審な DNS 活動に基づいて自動アラートや自動対応を起動できます。
• 運用上の洞察: ゲストの閲覧行動をより深く把握し、性能上のボトルネックを特定したり、コンテンツフィルタポリシーを最適化したりできます。

ログ、Logpush、SIEM 連携を使うと、ゲストのインターネット利用の可視化が進むだけでなく、組織全体のセキュリティ体制も強化できます。

ここまでの方法はすべて DNS を中心にしています。ゲスト Wi-Fi 上のトラフィックの多くは DNS を使い、これらの構成ではデバイスにエージェントや証明書を入れる必要がないためです。そのため、ゲスト Wi-Fi を保護するときは、まず DNS 中心の対策から始めることをおすすめします。ただし、DNS ベースのセキュリティは次の方法で迂回できます。

• DNS リゾルバーを手動で変更する
• IP アドレスでサイトへ到達する（ホストファイルで IP と完全修飾ドメイン名の対応を保存する場合もあります）
• 許可されていない VPN クライアントを使う

そのため、セキュリティは層で適用し、DNS による保護を補うネットワーク中心の強制も検討してください。

ネットワークレベルのフィルタを提供するには、DNS リクエストだけでなく、より広いトラフィック経路に Cloudflare を置く必要があります。インターネット向けトラフィックを IPsec ↗ トンネル経由で Cloudflare へルーティングすると実現できます。Cloudflare の Cloudflare WAN（旧 Magic WAN）サービスでは、サードパーティ機器から Cloudflare ネットワークへ IPsec または GRE トンネルを確立できます。Cloudflare One Appliance だけをデプロイすることもできます。これは事前設定済みの軽量ネットワークアプライアンスで、Cloudflare へのトンネルを自動作成し、遠隔管理できます。トラフィックが Cloudflare に到達すると、次のような複数のセキュリティ制御を重ねられます。

• クラウドベースのネットワークファイアウォール（Cloudflare Network Firewall）
• セキュア Web ゲートウェイ（Gateway）

上の図に対応するトラフィックの流れは、次のとおりです。

1. インターネット宛てのトラフィックは、接続済みのゲストネットワークから Cloudflare へルーティングします。ポリシーベースルートで簡単にできます。多くのゲスト Wi-Fi では、デバイスが生成するトラフィックはインターネット宛てだけなので、宛先を ANY としたポリシーベースルートで十分なことが多いです。例: Source 192.168.53.0/24 to Destination ANY next hop Cloudflare IPsec tunnel。
2. トラフィックが Cloudflare エッジに到達すると、最初に Cloudflare Network Firewall が検査します。Cloudflare Network Firewall では、ネットワーク層とトランスポート層のブロックを作れます。管理者が特定の宛先 IP やポートへのアクセスを制限できます。よくあるポリシーは、Cloudflare DNS リゾルバー以外へ向かうすべての DNS トラフィックをブロックすることです。カスタムリストを使い、既存のリストを取り込めます。IDS を有効にすると、ゲスト利用者がゲストネットワークから既知のエクスプロイトを試みていないかを監視できます。マネージド脅威 リスト を使うと、Cloudflare が自動更新する脅威インテリジェンスで、既知のマルウェアリポジトリやボットネットなどの既知の脅威をブロックできます。
3. トラフィックは次に Cloudflare Gateway へ転送されます。Gateway では、DNS ベースのポリシーで前述した同じコンテンツカテゴリとセキュリティリスクを使い、ネットワークベースのポリシーを作れます。これらのフィルタをネットワークレベルで適用すると、利用者が DNS を迂回してもポリシーを適用でき、多層の強制になります。組織の利用規定に合わせて、DNS ベースのルールをミラーすることをおすすめします。Cloudflare Gateway はセキュアなアウトバウンドプロキシとしても動作し、プライベートアドレスをインターネットでルーティング可能なパブリックアドレスへ SNAT できます。デフォルトでは、RFC 1918 アドレスは共有の Cloudflare egress IP へ自動的に SNAT されます。エッジ機器で PAT を直接管理する必要がなくなり、インターネットサイトを閲覧するときの送信元が Cloudflare 所有の IP になるため、プライバシーも高まります。アカウント固有の Dedicated Egress IP も提供でき、egress IP の選択はポリシーで制御できます。
4. トラフィックは最終的なインターネット宛先へルーティングされます。戻りトラフィックは Cloudflare エッジ経由で戻り、対応する IPsec トンネルへ返されます。

これらの方針に沿い、Cloudflare Zero Trust を活用すると、ゲストに安全で信頼でき、ポリシーに沿った無線体験を提供できます。これらの対策はネットワークを守るだけでなく、可視化を高め、脅威への先回りした対応も可能にします。

Gateway や Cloudflare SASE プラットフォームの他の側面について詳しく知りたい場合は、リファレンスアーキテクチャライブラリ または 開発者向けドキュメント を参照して始めてください。

• Cloudflare で SASE アーキテクチャへ進化する
• Cloudflare One Appliance のデプロイオプション
• DNS ポリシー - Cloudflare Zero Trust