SaaS（Software-as-a-Service）アプリケーションを開発するうえで重要なのは、インターネット上で直面するさまざまな攻撃から保護することです。Cloudflare のネットワークとセキュリティサービスを使うと、SaaS アプリケーションを利用するお客様を保護でき、アプリケーション保護 ↗ の経験があるベンダーへリスクを任せられます。
このデザインガイドでは、自社で製品 / アプリケーションを構築しホストしているプロバイダーが、Cloudflare を使って、Cloudflare ネットワークのセキュリティ、パフォーマンス、コンプライアンス上のメリットをエンドカスタマーへ拡張する方法を示します。
次の図では、次のサービスを使う構成を可視化します。
- Data Localization Suite（特に Regional Services）
- Cloudflare for SaaS
- Web アプリケーションを安全に公開するための Cloudflare Tunnel（パブリックホスト名 と プライベートネットワーク）
- トラフィックを管理し、信頼性とパフォーマンスを確保するための Load Balancer。Global Traffic Management（GTM）と Private Network Load Balancing を実装します。
この構成は、ダウンタイムを最小にし、SSL/TLS 証明書を自動更新し、健全なエンドポイントへトラフィックを効率よく分散し、コンプライアンスとパフォーマンス最適化のためにリージョン単位でトラフィックを管理する必要がある SaaS プロバイダーに適しています。
このドキュメントでは、プロバイダーのアプリケーション DNS が、プライマリかつ権威 DNS プロバイダーとして Cloudflare に登録され、管理されていることを前提とします。設定方法の詳細は Cloudflare DNS ゾーンセットアップガイド を参照してください。
このソリューションは、自ゾーン配下のサブドメインをサポートしつつ、お客様が自社のドメイン名（バニティドメインまたはカスタムドメイン）でサービスを使えるようにします。たとえば、お客様ごとにカスタムホスト名 mycustomer.myappexample.com を作成しつつ、お客様自身のドメイン app.mycustomerexample.com から、サービス上のテナントを指せるようにします。各サブドメイン（mycustomer.myappexample.com）は、Cloudflare API でメインドメイン（myappexample.com）上に作成できます。お客様がサービス上でアカウントを作成したときに、DNS レコードの作成を自動化しやすくなります。
カスタムホスト名を通じて Cloudflare を設定し SaaS アプリケーションを保護する方法を見る前に、このアプローチのメリットを確認します。
| メリット | 説明 |
|---|---|
| ダウンタイムの最小化 | Cloudflare for SaaS へのカスタムホスト名移行時だけでなく、アプリケーションのライフサイクル全体で ダウンタイムを最小 にします。 |
| セキュリティとパフォーマンス | お客様のカスタムドメインを通じて、Cloudflare の セキュリティ と パフォーマンス のメリットをエンドカスタマーへ拡張します。 |
| 自動更新 | カスタムホスト名証明書の 更新 と管理を自動化します。 |
| Apex Proxying | エンドカスタマーが ドメインエイペックス（ルートドメイン）をカスタムホスト名として使う場合をサポートします。DNS サービスが ルートドメインの CNAME を許可しないときに使い、A レコードを使えるよう 静的 IP を使います。 |
| スマートな負荷分散 | Load Balancer を custom origin として使い、セッションアフィニティ でトラフィックを振り分けます。Cloudflare for SaaS では、custom origin を使うと、1 つ以上のカスタムホスト名からのトラフィックを、既定のプロキシ fallback origin 以外へ送れます。 |
| O2O | すでに Cloudflare 経由でトラフィックをプロキシしているエンドカスタマーでは、O2O が必要になることがあります。一般には、SaaS プロバイダーが使うホスト名を プロキシしない ことを推奨します。O2O 機能が必要な場合は、製品の互換性 を確認してください。 |
| Regional Services | データローカライゼーション要件に合わせて、リージョン単位のトラフィック管理 ができます。 |
このソリューションでは、次の製品を使います。
| 製品 | 役割 |
|---|---|
| Cloudflare for SaaS | お客様自身のカスタムドメインまたはバニティドメインを通じて、Cloudflare ネットワークのセキュリティとパフォーマンスのメリットを拡張します。Certificate Management、WAF for SaaS、Early Hints for SaaS、Cache for SaaS を含みます。 |
| DDoS Protection | プロキシ済み ホスト名では、ボリューム攻撃の保護が自動で有効になります。 |
| Regional Services（Data Localization Suite の一部） | データの検査（処理）を、管轄境界内のデータセンターにだけ制限します。 |
| Load Balancer | エンドポイントへトラフィックを分散し、エンドポイントの負荷とレイテンシを下げ、エンドユーザーの体験を改善します。 |
| Cloudflare Tunnel | ファイアウォール に穴を開けずに、お客様のネットワークとサーバーへ安全に接続します。cloudflared はオリジンサーバーにインストールするデーモン（ソフトウェア）で、アプリケーションから Cloudflare への安全なトンネルを作ります。 |
Cloudflare を使う主な目的は、アプリケーションのカスタムホスト名へのすべてのリクエストを、まず Cloudflare のセキュリティとパフォーマンスサービス経由にし、セキュリティ制御とルーティング、または負荷分散を適用することです。オリジンサーバーは公開アクセス可能である必要があることが多いため、Cloudflare とオリジンサーバー間の接続の保護が重要です。オリジンサーバーの保護の包括的なガイダンスは、Cloudflare のドキュメント オリジンサーバーを保護する を参照してください。
以下の図では、まずこの目的を達成する最も単純な方法を示し、続いてより複雑な構成を示します。
この標準的な Cloudflare for SaaS 構成は、ほとんどのプロバイダーで最もよく使われ、実装しやすいです。通常、これらのプロバイダーは SaaS 企業で、ソフトウェアをサービスとして開発し提供します。この構成では、リクエストを Cloudflare へ向ける DNS レコードが 1 つあればよく、Cloudflare はそのトラフィックを A レコードでアプリケーションへプロキシします。
- カスタムホスト名（
custom.example.com）は、プロバイダーの fallback origin を指す CNAME レコードとして設定します。fallback origin は、カスタムホスト名へのリクエストがあったときに、Cloudflare が既定でトラフィックを送るサーバーです。この DNS レコードは Cloudflare 内で管理する必要はなく、プロバイダーの Cloudflare ホスト済みレコード（fallback.myappexample.com）を指せば十分です。 - Fallback Origin は、オリジンサーバーのパブリック IP アドレスを指す A レコードとして設定します。Cloudflare は、カスタムホスト名宛てのトラフィックを、既定でこのオリジンサーバーへ送ります。
オリジンサーバーは、host ヘッダーまたは SNI を通じてカスタムドメインの詳細を受け取ります。これにより、オリジンサーバーはどのアプリケーションへリクエストを向けるかを判断できます。この方法は、カスタムホスト名（例: app.mycustomerexample.com）とバニティドメイン（例: customer1.myappexample.com）の両方に使えます。アプリケーションへのすべてのリクエストが Cloudflare ネットワーク経由になるため、次を含むさまざまなセキュリティとパフォーマンスサービスを、リクエストごとに利用できます。
- Web Application Firewall
- アクセス制御ポリシー
- アプリケーションコンテンツのキャッシュ
- ブラウザの Early Hints のサポート
- Image Transformations
- Waiting Room
- Workers for Platforms
実装の詳細は、開発者ドキュメント を参照してください。
この方法では、Cloudflare の Regional Services を導入し、TLS 終端と HTTP 処理をリージョン化します。サービスが特定の地理的場所でデータを処理することを求めるコンプライアンス規制に合わせます。オリジンサーバー宛てのトラフィックは、選んだリージョン内だけで処理されます。
- カスタムホスト名（
custom.example.com）は、リージョン化した SaaS ホスト名（eu-customers.myappexample.com）を指す CNAME レコードとして設定します。この構成により、TLS 終端を含むすべての処理が、指定した地理的リージョン内だけで行われます。 - リージョン化した SaaS ホスト名は、SaaS プロバイダーの標準 Fallback Origin（
fallback.myappexample.com）へトラフィックを向ける CNAME レコードとして設定します。 - fallback origin は、オリジンサーバーのパブリック IP アドレスを指す A レコードとして設定します。Cloudflare は、カスタムホスト名宛てのトラフィックを、既定でこのオリジンサーバーへ送ります。
セキュリティを高めるため、アプリケーションサーバーをパブリック IP でインターネットに直接公開する代わりに、SaaS プロバイダーは Cloudflare Tunnel を使えます。これらのトンネルは、ネットワークを最寄りの Cloudflare データセンターへ接続し、SaaS アプリケーションを パブリックホスト名 経由で利用できるようにします。その結果、パブリックインターネットからアプリケーションネットワークへのエンドカスタマーの入り口は、Cloudflare だけになります。
- カスタムホスト名（
custom.example.com）は、リージョン化した SaaS ホスト名（eu-customers.myappexample.com）を指す CNAME レコードとして設定します。この構成により、TLS 終端を含むすべての処理が、指定した地理的リージョン内だけで行われます。 - リージョン化した SaaS ホスト名は、SaaS プロバイダーの標準 Fallback Origin（
fallback.myappexample.com）へトラフィックを向ける CNAME レコードとして設定します。 - fallback origin は、Cloudflare Tunnel が公開する パブリックホスト名 を指す CNAME DNS レコードです。このパブリックホスト名は、アプリケーションへトラフィックをルーティングするよう設定します（例:
localhost:8080）。
この構成は、複数のオリジンサーバー間で 地理位置ベースのトラフィックステアリング などの細かい負荷分散が不要な SaaS プロバイダーに適しています。Cloudflare Tunnel 経由のリクエストだけを許可して オリジンサーバーを保護する だけで十分な、単純なテストや開発環境にも向いています。ただし、グローバルとローカルの両方で負荷分散が必要な分散アプリケーションでは、グローバルおよびプライベートネットワークの負荷分散機能を持つ Cloudflare の Load Balancer の利用を推奨します。
Cloudflare は強力な負荷分散機能を提供します。SaaS アプリケーションをホストする異なるオリジンサーバーへ、パブリックホスト名（上記）またはプライベート IP アドレスを通じて、確実にトラフィックを振り分けられます。この構成は、複数サーバーへトラフィックを分散してオリジンの過負荷を防ぎ、Cloudflare Tunnel 経由のリクエストだけを許可してセキュリティを高めます。
- カスタムホスト名（
custom.example.com）は、Cloudflare の リージョン化した Load Balancer（eu-lb.myappexample.com）を指す CNAME レコードとして設定します。TLS 終端を含むすべての処理が、指定した地理的リージョン内で行われます。加えて、SaaS プロバイダーは、そのカスタムホスト名の custom origin として Load Balancer を設定する必要があります。 - リージョン Load Balancer は、複数の下流サーバーへリクエストを分散する origin pool で設定します。各プールは、Global Traffic Management（GTM）付きの パブリックホスト名、または Private Network Load Balancing 付きの プライベートネットワーク アドレスを使えます。上の図では、両方を使っています。
- Origin pool 1 は、それらのリクエストを処理するエンドポイントまたはオリジンサーバーとして、Cloudflare Tunnel ホスト名（
<UUID>.cfargotunnel.com）を使います。 パブリックホスト名を使う場合は、Cloudflare Tunnel が設定し公開しているパブリックホスト名と一致するよう、HTTP host ヘッダー値 を設定する必要があります。オリジンサーバーが受信リクエストを正しくルーティングできるようにするためです。 - Origin pool 2 は、SaaS アプリケーションがあるプロバイダー内部ネットワーク内のプライベート IP アドレスまたはプライベートネットワーク（例:
10.0.0.5）を使います。このプールは、指定した 仮想ネットワーク 内で動作するよう設定し、リクエストが正しくルーティングされるようにします。
- Origin pool 1 は、それらのリクエストを処理するエンドポイントまたはオリジンサーバーとして、Cloudflare Tunnel ホスト名（
- Cloudflare Tunnel は、GTM 付きの パブリックホスト名 と、Private Network Load Balancing 付きの プライベートネットワーク（プライベート IP）の両方を公開します。
アプリケーション配信の粒度とスケーラビリティを高めるには、一般にパブリックホスト名よりプライベートネットワークの利用を推奨します。プライベートネットワークでは、Cloudflare が host ヘッダーを保持し、オリジンサーバーへ正確に渡せます。一方、パブリックホスト名を使う場合、プロバイダーは Load Balancer 上で ヘッダー値 を設定する必要があり、Load Balancer エンドポイントあたり 1 つのパブリックホスト名に制限されるため、柔軟性が下がることがあります。
Zero Trust の Tunnel の制限、Cloudflare for SaaS の 接続リクエストの詳細、Custom Origin の SNI 仕様 に注意してください。Cloudflare Load Balancer の詳細は、リファレンスアーキテクチャ を参照してください。
SaaS プロバイダーとしては、これらのプロセスのほとんど、できればすべてを API、SDK、スクリプト、Terraform、その他の自動化ツールで自動化することを推奨します。
高レベルの移行計画の例は、ここからダウンロード できます。
Cloudflare for SaaS への移行は段階的に進め、特に Domain Control Validation（DCV） で発生した問題にその都度対処することを強く推奨します。プロセス中は 検証ステータス と関連 ドキュメント を確認してください。
Cloudflare のインフラストラクチャを使うと、SaaS プロバイダーはエンドカスタマーへ、安全で信頼性が高く、パフォーマンスの良いサービスを提供できます。リージョン化などのコンプライアンス要件を満たしつつ、スムーズで安全なユーザー体験を確保できます。
いくつかの Cloudflare のお客様は、現在 Cloudflare for SaaS ソリューション（旧称 SSL for SaaS）を使っています。公開されている主な事例は次のとおりです。
加えて、Cloudflare for SaaS へ移行するときは、関連する詳細をエンドカスタマーへ伝えるランブックと明確な公開ドキュメントを用意することが重要です。優れた公開例として、Salesforce CDN ↗ と Shopify ↗ のドキュメントがあります。