Cloudflare は、アプリケーションのパフォーマンス、セキュリティ、信頼性、開発、Zero Trust をカバーする一連のサービスを提供します。Cloudflare のグローバルネットワークは、インターネット接続人口の約 95% からおよそ 50 ms の距離にあり、すべてのデータセンターのすべてのサーバーでサービスが動作します。このグローバルな規模により、堅牢な脅威インテリジェンスの情報源にもなります。この情報は Cloudflare のセキュリティ製品に継続的にフィードバックされ、機械学習モデルとサービスをさらに強化します。
ほかの差別化要因として、Cloudflare はポイントプロダクトではありません。API セキュリティだけ、Zero Trust サービスだけ、特定のパフォーマンス／セキュリティサービスだけを提供するベンダーとは異なります。お客様は、運用と管理の複雑さ、製品横断のイノベーションや統合を活かせない非効率、ネットワークやリソースの規模を全サービスで共有できないといった理由から、ポイントプロダクトのアプローチを離れ始めています。
さらに、お客様は特定のクラウドプロバイダーにロックインされたくありません。しかし、多くのパフォーマンスおよびセキュリティベンダーは、自社クラウド向けにサービスを最適化し、マルチクラウド戦略の採用を運用面で難しくすることで、お客様を自社プラットフォームに縛ります。
Cloudflare は、ワークロードの実行場所や利用中のクラウドプロバイダーを問いません。特定のクラウドでもオンプレミスでも、同じ一貫した統合ダッシュボードと運用のシンプルさを得られます。多くのベンダーと異なり、製品横断のイノベーションや統合を活かすために、特定のクラウドでワークロードを動かす必要はありません。
本ドキュメントでは、ワークロードの実行場所に関係なく、Cloudflare のサービス群を簡単に使えることを示します。ここでの例では、アプリケーションのワークロードに Cloudflare DNS、CDN、WAF、Access を使い、Cloudflare Tunnel で Cloudflare ネットワークへ安全に接続します。運用がシンプルで一貫した形で、この包括的なセキュリティ機能を提供するベンダーは多くありません。
各サービスの詳細とリファレンスアーキテクチャは、リファレンスアーキテクチャのドキュメント を参照してください。
Cloudflare のようなクラウドベースのセキュリティおよびパフォーマンスプロバイダーは、リバースプロキシとして動作します。リバースプロキシは、Web サーバーの前に置かれ、クライアントのリクエストをそれらの Web サーバーへ転送するサーバーです。リバースプロキシは通常、セキュリティ、パフォーマンス、信頼性を高めるために導入します。
リバースプロキシがない通常のトラフィックフローでは、クライアントが DNS ルックアップを送り、オリジンの IP アドレスを受け取り、オリジンサーバー ↗ と直接通信します。
リバースプロキシを導入すると、クライアントは引き続きリゾルバーへ DNS ルックアップを送ります。リゾルバーは DNS ルックアップの最初の到達点です。場合によっては、リバースプロキシを提供するベンダーが DNS サービスも提供します。これは下の図 3 に示しています。ただし、クライアントはリバースプロキシと通信し、リバースプロキシがオリジンサーバーと通信します。すべてのトラフィックがリバースプロキシを経由するこの流れにより、アプリケーションのセキュリティ、パフォーマンス、信頼性のサービスを簡単に実装できます。
この例では、主要クラウドプロバイダーの 1 つで稼働する Web サイトに対して、Cloudflare DNS、CDN、WAF、Access を使います。まずはこれらのサービスから始めます。必要に応じて、ほかの Cloudflare サービスへ広げられます。Cloudflare の利点は、すべてのサービスをクラウドプロバイダーから切り離せることです。あとでクラウドプロバイダーを変えても、ほかのクラウドで動くアプリケーションを保護しても、ダッシュボードと運用は一貫したままです。
お客様は、Web アプリケーションを Cloudflare ネットワークへ簡単かつ安全に接続し、アプリケーションのパフォーマンスとセキュリティサービスを利用できます。ユースケースに応じた接続オプションがいくつかあります。
最も基本的なシナリオでは、Cloudflare プロキシがリクエストトラフィックをインターネット経由でオリジンへルーティングします。この構成では、クライアントとオリジンの両方が、それぞれの ISP 経由でインターネットに直接接続されたエンドポイントです。リクエストは、（DNS 設定により）クライアントから Cloudflare プロキシへインターネット経由で送られ、プロキシがインターネット経由でお客様のオリジンへリクエストをルーティングします。
次の図は、リクエストが Cloudflare ネットワークを通過するときの、オリジンへのデフォルト接続を示しています。オリジン向けのリクエストが Cloudflare がホストする IP に解決されると、そのリクエストは Cloudflare ネットワークで処理され、パブリックインターネット経由でオリジンサーバーへ転送されます。
オリジンはインターネットに直接接続されており、Cloudflare DNS が解決した IP アドレスに基づいてトラフィックがオリジンへルーティングされます。DNS の A レコードは、ドメイン名をオリジンサーバーの IP アドレス、または通常はオリジンの手前にあるロードバランサーに関連付けます。
このモデルでは、Cloudflare DNS が A レコードのクエリを受け取ると、Cloudflare の anycast IP アドレスが返され、すべてのトラフィックが Cloudflare を経由します。ただし、追加の対策を取らない限り、オリジンの IP アドレスを知っている人が Cloudflare を迂回してオリジンへ直接到達できる可能性があります。
さらにこのモデルでは、HTTP/HTTPS の各ポートで到達できるように、オリジンまたは Web サーバー向けのファイアウォールルールを開く必要があります。一方、Dedicated CDN Egress IPs を使うと、Cloudflare がオリジンへ接続するときに使うお客様専用の IP を割り当てられます。直接アクセスを避けるため、これらのネットワークからのトラフィックだけを許可リストに登録することを推奨します。
オリジン側ファイアウォールでの IP ブロックに加え、「Full (Strict)」SSL 設定 または mTLS 認証 によるトラフィック検証も強く推奨します。これにより、お客様が設定したゾーンを通過したリクエストだけが送信元になります。
Cloudflare は Bring Your Own IP (BYOIP) にも対応しています。BYOIP を設定すると、Cloudflare のグローバルネットワークがお客様自身の IP プレフィックスをアナウンスし、そのプレフィックスを該当する Cloudflare の Layer 7 サービスで使えます。これにより、トラフィックを Cloudflare 経由でプロキシしつつ、DNS 解決ではお客様の IP アドレスを返せます。お客様の IP プレフィックスがすでに許可リストに入っており、ファイアウォールルールの更新が望ましくない、または運用上の負担になる場合に 有効 ↗ です。
インターネット経由でオリジンへ接続する場合の推奨オプションは、セキュリティを高めるために、インターネット上にプライベートなトンネル／接続を設けることです。
従来の VPN 構成は最適ではありません。トラフィックを中央の VPN ゲートウェイへバックホールし、そこからオリジンへ戻すため、エンドツーエンドのスループットとレイテンシが悪化します。Cloudflare は、オリジンと Cloudflare ネットワークの間に暗号化トンネルを提供する Cloudflare Tunnel ソフトウェアを提供します。また、Cloudflare はグローバルネットワークで anycast を使うため、オリジンもクライアントと同様に最も近い Cloudflare データセンターへ接続し、エンドツーエンドのレイテンシとスループットを最適化します。
トンネルを実行すると、インフラ内の軽量デーモンである cloudflared が、オリジンサーバーと Cloudflare ネットワークの間にアウトバウンドのみの接続を 4 本確立します。この 4 本は、少なくとも 2 つの異なるデータセンターに分散した 4 台のサーバーへ張られ、高い耐障害性を提供します。cloudflared のインスタンスを複数インストールして、オリジンサーバーと Cloudflare ネットワークの間の耐障害性をさらに高められます。
cloudflared は、公開インバウンドポートを開かずに、オリジンの Web サーバーと最も近い Cloudflare データセンターの間に暗号化トンネルを作成します。ファイアウォール上のセキュリティ変更が不要なため、導入がシンプルで迅速です。ファイアウォールの設定ミスで会社が攻撃にさらされるリスクも下がります。
ファイアウォールですべてのオリジンサーバーのポートとプロトコルを閉じることで、ファイアウォールとセキュリティ態勢を強化します。Cloudflare Tunnel を導入し、適切なセキュリティを適用すると、HTTP/S ポートへのリクエストはすべて破棄されます。ボリュメトリックな DDoS 攻撃も含みます。転送中データの盗聴やブルートフォースログイン攻撃などのデータ侵害の試みも、完全に遮断されます。
上の図は、Cloudflare Tunnel による接続モデルを示しています。このオプションでは、公開ルーティング可能な IP アドレスなしで、リソースを Cloudflare へ安全に接続できます。Cloudflare Tunnel は、HTTP Web サーバー、SSH サーバー、リモートデスクトップ、その他のプロトコルを Cloudflare へ安全に接続できます。
多くのベンダーは、自社ネットワークへの直接接続オプションも提供します。直接接続は、パブリックインターネットを使う場合と比べて、セキュリティ、信頼性、パフォーマンスの利点があります。これらの直接接続は、ピアリング施設、ISP とインターネットネットワークが相互接続するインターネットエクスチェンジ（IX）、またはベンダーパートナー経由で行います。
上の図は、Cloudflare Network Interconnect (CNI) ↗ によるオリジン接続を示しています。CNI を使うと、自社のネットワークインフラを Cloudflare に直接接続し、その直接リンク上だけで通信できます。CNI により、支店や本社の拠点を Cloudflare に直接相互接続できます。Cloudflare との相互接続には次の 3 つの方法があります。Cloudflare のピアリング施設 ↗ で利用できるプライベートネットワークインターコネクト（PNI）、Cloudflare が参加する世界各地のエクスチェンジ ↗ のいずれかでの IX、または Cloudflare の 相互接続プラットフォームパートナー ↗ のいずれかです。
Cloudflare のグローバルネットワークにより、インフラと従業員の所在地に関係なく、ネットワークへ接続しやすくなります。
どの接続モデルを使う場合でも、まず DNS 解決が行われ、ルーティング先の情報が Cloudflare に渡ります。Cloudflare は、ゾーンに対して権威 DNS プロバイダー、セカンダリ DNS プロバイダー、または非 Cloudflare DNS（CNAME）構成をサポートします。Cloudflare のパフォーマンスおよびセキュリティサービスを適用するには、トラフィックを Cloudflare ネットワークへルーティングする必要があります。
アプリケーションを Cloudflare サービスにオンボードする方法は複数ありますが、よく使われるのは Cloudflare DNS をプライマリの権威 DNS にする方法です。ここでの追加の利点は、Cloudflare が世界で 最も速い権威 DNS プロバイダー ↗ として継続的に評価されていることです。
この例では、Cloudflare Tunnel でオリジンサーバーを Cloudflare に安全に接続します。ダッシュボードで DNS を設定し、オンボードするサイトを入力します。ドメインレジストラ側で設定する Cloudflare ネームサーバーのペアが発行されます。完了すると、Cloudflare がプライマリの権威 DNS プロバイダーになります。
インターネット経由のルーティングだけを設定した場合、DNS 構成は次のようになります。A レコードがオリジンサーバーまたは対応するロードバランサーの IP アドレスを指します。Cloudflare がリバースプロキシとして動作しているため、ステータスは Proxied と表示されます。この状態でも Cloudflare はリバースプロキシとして動作しているため、CDN、WAF、Access などの Cloudflare サービスをすべて利用できます。
インターネット上の Cloudflare Tunnel を使うと、セキュリティを高め、オリジン向けのインバウンドファイアウォールルールを開く必要がなくなります。この場合、DNS 構成の A レコードの代わりに、デプロイしたトンネルを指す CNAME レコードを使います。オリジンから Cloudflare ネットワークへトンネルをデプロイすると、DNS は自動的に設定されます。トンネルを指す CNAME レコードが作成され、オリジンへ向かうすべてのトラフィックが Cloudflare Tunnel 経由でルーティングされます。
トンネルを作成および管理するには、オリジンサーバーに cloudflared をインストールして認証する必要があります。cloudflared が、サーバーを Cloudflare のグローバルネットワークへ接続します。
トンネルの作成には 2 つのオプションがあります。ダッシュボード経由 と コマンドライン経由 です。どのマシンからでもトンネルを管理できるため、まずはダッシュボードから始めることを推奨します。
リモート管理トンネルの実行に必要なのは、トンネルトークンだけです。トークンにアクセスできる人は、誰でもトンネルを実行できます。トンネルのトークンは、ダッシュボードまたは次に示す API から取得できます。ダッシュボードに表示されるコマンドは、認証トークンを使ってサービスとして cloudflared をインストールおよび設定します。
Cloudflare ダッシュボードで、Zero Trust > Networks > Connectors を開きます。「Create a tunnel」ボタンを選び、トンネルに名前を付けて保存します。
次に、オリジンサーバーのオペレーティングシステム（OS）を選ぶ画面が表示されます。オリジンで実行すると、Cloudflare Tunnel ソフトウェアを自動でダウンロードしてインストールする CLI コマンドが提供されます。
次に、CLI コマンドを実行して Cloudflare Tunnel ソフトウェアをダウンロードおよびインストールした状態です。
コネクターは、接続済みとして自動的に表示されます。
ダッシュボードで、次の手順に進めます。下図のように、トンネルを作成し、オリジン上のサービスへマッピングします。この例では、すべての HTTPS トラフィックがトンネル経由でオリジンサーバーへ送られます。
ダッシュボードで、トンネルが作成され、健全であることが確認できます。
さらに DNS 構成を見ると、トンネル ID を指す DNS レコードが自動作成されていることがわかります。トンネルを作成すると、Cloudflare は作成したトンネルの UUID を持つ cfargotunnel.com のサブドメインを生成します。公開ルーティング可能な IP アドレスとは異なり、このサブドメインは同じ Cloudflare アカウント内の DNS レコードのトラフィックだけをプロキシします。別のアカウントやシステムで DNS レコードを作成し、このトンネル経由でトラフィックをプロキシすることはできません。
これで、安全なアプリケーションアクセスが整いました。ユーザーは、Cloudflare ネットワークに接続したトンネル経由でのみアプリケーションにアクセスできます。さらに、Tunnel は Cloudflare へのアウトバウンド接続を使い、アウトバウンド接続の戻りトラフィックは許可されるため、インバウンドのファイアウォールルールは不要です。オーバーヘッドが減り、運用もシンプルになります。
CLI でトンネルをデプロイする場合は、インストール後にオリジンサーバー上で cloudflared を認証する必要があります。cloudflared が、サーバーを Cloudflare のグローバルネットワークへ接続します。この認証は、次に示す cloudflared tunnel login コマンドで行えます。
次に、トンネルを追加するゾーンを選ぶよう求められます。
次に、そのゾーン向けにトンネルを認可します。
最後に、該当ゾーンでトンネルを作成できる証明書がオリジンにインストールされたことを示す確認が表示されます。
ここまでの構成を下図に示します。オリジンサーバーは Tunnel 経由で Cloudflare ネットワークに接続されています。ここから Cloudflare のサービスを利用できます。
現在、オリジンへは Cloudflare Tunnel 経由でのみ到達できます。公開ホスト名を使っているため、オリジンへのアクセスは公開です。アプリケーションは Cloudflare の背後で保護され、DDoS などの攻撃から守られています。さらにセキュリティを高めるには、Cloudflare Access で、トンネル化したアプリケーションの前に認証とアクセス制御の層を置けます。Access は、オリジンへのリクエストが処理される前に認証ステップを強制します。ポリシーには、ほかの多くの ID、デバイス、ネットワーク属性も使えるため、認証だけにとどまらないアクセス定義が可能です。たとえば、リクエストの発信元ネットワークや、ユーザーデバイスが最新のオペレーティングシステムを実行していることを条件にできます。
下図では、cftestsite3.com 向けのアプリケーションが作成されています。
下のポリシー設定では、「Secure Employees」Access グループのメンバーであることが求められています。
「Secure Employees」Access グループを詳しく見ると、メンバーは会社の Okta アイデンティティプロバイダー（IdP）グループ「Employees」から来ています。さらに、この Access グループは多要素認証（MFA）を強制しています。
「Image and Video Gallery」アプリケーションの「Authentication」では、このアプリケーションへの接続に使えるアイデンティティプロバイダーを手動で選べます。
これで、Tunnel 経由のオリジンへの安全なアクセスと、Access によるアプリケーションへの認証およびアクセスポリシーが整いました。ユーザーがサイトへアクセスしようとすると、設定した IdP で認証するよう求める Cloudflare Access のページが表示されます。ページはお客様の好みに合わせてカスタマイズできます。
現在の構成では、オリジンサーバーは Cloudflare Tunnel 経由で Cloudflare ネットワークに安全に接続され、Cloudflare Access のポリシーが認証とその他のセキュリティ要件を強制しています。
Cloudflare はすでに設定済みで、サイトのリバースプロキシとして動作しています。トラフィックは Cloudflare を経由するため、CDN、Security Analytics、WAF、API Shield、Bot Management、クライアントサイドセキュリティなど、すべての Cloudflare サービスを簡単に利用できます。
クライアントが該当 Web サイト（この場合は「cftestsite3.com」）の DNS ルックアップを行うと、Cloudflare は anycast IP アドレスを返します。トラフィックは最も近いデータセンターへ送られ、そこでサービスが適用されたあと、リクエストは Cloudflare Tunnel 経由でオリジンサーバーへ転送されます。
Cloudflare CDN は、Cloudflare のグローバル anycast エッジネットワークを使います。ネットワークのパフォーマンスと耐障害性に anycast を使うことに加え、Cloudflare CDN は Argo Tiered Cache を使い、お客様のコストを抑えつつ結果を最適化します。Argo Smart Routing を有効にすると、オリジンサーバーへのリクエストを最速のネットワーク経路でルーティングできます。下図のように、Cloudflare CDN はコンテンツをグローバルにキャッシュしており、デフォルト動作を変える細かい CDN ポリシーを適用できます。
キャッシュトポロジと設定にはいくつかの種類があります。下図では、ドメインへのリクエストをキャッシュし、オリジンの TTL を上書きする Cache Rule が設定されています。
ダッシュボードの「Caching > Cache Reserve」で「Enable storage sync」ボタンをクリックすると、Cloudflare Cache Reserve も有効になります。Cache Reserve は Cloudflare の永続オブジェクトストレージである R2 を使い、ほかのパブリッククラウドプロバイダーのエグレス料金をなくします。ボタン 1 つでデータを永続的にキャッシュでき、キャッシュヒット率が向上します。
さらに下図のとおり、Cloudflare Security Analytics は Cloudflare の検出機能をまとめ、該当サイトへ向かうすべてのトラフィックの全体ビューと重要なインサイトを提供します。トラフィックが Cloudflare ネットワークを経由するため、Cloudflare は脅威とインサイトを把握でき、ダッシュボード、ログ、レポートでお客様に公開します。
Cloudflare の WAF ルールを適用すると、インラインでトラフィックにポリシーを強制できます。下図では、ボットスコアが 30 未満、かつ WAF 攻撃スコアが 50 未満のトラフィックをすべてログするファイアウォールポリシーがあります。ボットスコア 30 未満は、自動化または自動化の可能性が高いと分類されたトラフィックです。WAF 攻撃スコア 50 未満は、悪意がある、または悪意がある可能性が高いと分類されたトラフィックです。
Cloudflare WAF では、ヘッダー情報を含む多くのリクエスト条件を使える細かいポリシーを設定できます。さまざまなアクション（ログ、ブロック、チャレンジなど）を取れます。
WAF では、カスタムルール、レート制限ルール、マネージドルールを実装して使えます。それぞれの概要は次のとおりです。
- WAF Custom Rules: さまざまなリクエスト属性とヘッダー情報に基づくカスタムルールを作成し、脅威をブロックできます
- WAF Rate Limiting Rules: 不正利用、DDoS、ブルートフォース試行を防ぎ、API 向けの制御を提供します
- WAF Managed Rules
- Cloudflare Managed Ruleset: 高度なゼロデイ脆弱性保護を提供します
- Cloudflare OWASP Core Ruleset: 一般的な Web アプリケーションの脆弱性をブロックします。一部は OWASP Top 10 に含まれます
- Cloudflare Leaked Credential Check: 人気のコンテンツ管理システム（CMS）アプリケーション向けに、漏えい認証情報データベースを照合します
同じ考え方は、ほかのすべての Cloudflare Application Performance および Security 製品（API Shield、Bot Management など）にも当てはまります。トラフィックを Cloudflare ネットワーク経由に設定すれば、Cloudflare のサービスを利用し始められます。図 31 は、ボットスコアに基づいてトラフィックを分類し、ボットスコア分布とその他のボット分析を示す Cloudflare の Bot Analytics です。リクエストデータはすべてインラインで取得され、定義したポリシーに基づく強制もインラインで行われます。
Cloudflare は、包括的なアプリケーションパフォーマンスおよびセキュリティサービスを提供します。オリジンサーバーへのトラフィックを Cloudflare のネットワーク経由にルーティングすれば、すべてのパフォーマンスおよびセキュリティサービスを簡単にオンボードして使い始められます。さらに、Cloudflare は、オリジンサーバーを Cloudflare のネットワークへ安全に接続する Cloudflare Tunnel を含む、複数の接続オプションを提供します。