Cloudflareの利点をSaaSプロバイダーのエンドカスタマーに拡張する
ソフトウェア・アズ・ア・サービス（SaaS）アプリケーションを開発する際の重要な側面は、インターネット上で直面するさまざまな攻撃に対するセキュリティを確保することです。Cloudflareのネットワークとセキュリティサービスを使用することで、SaaSアプリケーションを利用する顧客を保護し、アプリケーションの保護に関する経験を持つベンダーにリスクをオフロードできます。アプリケーションの保護 ↗に関する詳細はここを参照してください。
このデザインガイドでは、独自の製品/アプリケーションを構築およびホスティングするプロバイダーが、Cloudflareを活用してCloudflareのネットワークのセキュリティ、パフォーマンス、およびコンプライアンスの利点をエンドカスタマーに拡張する方法を示します。
以下の図は、次のサービスの使用を視覚化しています。
- データローカリゼーションスイート（特に、地域サービス）
- Cloudflare for SaaS
- Cloudflare Tunnelsを使用してウェブアプリケーションを安全に公開（パブリックホスト名およびプライベートネットワークを使用）
- トラフィックを管理し、信頼性とパフォーマンスを確保するためのロードバランサー、グローバルトラフィック管理（GTM）およびローカルトラフィック管理（LTM）を実装。
このセットアップは、最小限のダウンタイム、SSL/TLS証明書の自動更新、健全なエンドポイントへのトラフィックの効率的な分配、およびコンプライアンスとパフォーマンスの最適化のための地域トラフィック管理を確保する必要があるSaaSプロバイダーに最適です。
この文書は、プロバイダーのアプリケーションDNSがCloudflareを主要かつ権威あるDNSプロバイダーとして登録および管理されていることを前提としています。この設定方法の詳細は、Cloudflare DNSゾーン設定ガイドで確認できます。
このソリューションは、独自のゾーンのサブドメインをサポートし、顧客が独自のドメイン名（バニティまたはカスタムドメイン）をサービスで使用できるようにします。たとえば、各顧客に対してカスタムホスト名mycustomer.myappexample.comを作成することができますが、同時に彼らが独自のドメインapp.mycustomerexample.comを使用してサービス上のテナントを指すことも許可したいと考えています。各サブドメイン（mycustomer.myappexample.com）は、Cloudflare APIを通じてメインドメイン（myappexample.com）上に作成でき、顧客がサービスにアカウントを作成する際にDNSレコードの作成を簡単に自動化できます。
Cloudflareがカスタムホスト名を通じてSaaSアプリケーションを保護するためにどのように構成できるかを見ていく前に、このアプローチを取る利点を確認する価値があります。
| 利点 | 説明 |
|---|---|
| ダウンタイムの最小化 | Cloudflare for SaaSへのカスタムホスト名の移行中だけでなく、アプリケーションのライフサイクル全体を通じて最小限のダウンタイムを確保します。 |
| セキュリティとパフォーマンス | Cloudflareのセキュリティとパフォーマンスの利点を、顧客のカスタムドメインを通じてエンドカスタマーに拡張します。 |
| 自動更新 | カスタムホスト名証明書の更新および管理プロセスを自動化します。 |
| エイペックスプロキシング | エンドカスタマーがドメインエイペックス（ルートドメインとも呼ばれる）をカスタムホスト名として使用することをサポートします。DNSサービスがルートドメインのCNAMEを許可しない場合に使用され、代わりにAレコードを使用するために[静的IP]が使用されます。 |
| スマートロードバランシング | カスタムオリジンとしてロードバランサーを使用し、セッションアフィニティでトラフィックを誘導します。Cloudflare for SaaSの文脈では、カスタムオリジンを使用すると、1つまたは複数のカスタムホスト名からデフォルトのプロキシフォールバックオリジン以外の場所にトラフィックを送信できます。 |
| オレンジからオレンジ（O2O） | すでにCloudflareを通じてトラフィックをプロキシしているエンドカスタマーには、オレンジからオレンジ（O2O）が必要になる場合があります。一般的に、これらのエンドカスタマーには、SaaSプロバイダーが使用するホスト名をプロキシしないことを推奨します。オレンジからオレンジの機能が必要な場合は、製品の互換性を確認してください。 |
| 地域サービス | データローカリゼーション要件に準拠するために地域トラフィック管理を可能にします。 |
このソリューションを提供するために使用される製品は次のとおりです。
| 製品 | 機能 |
|---|---|
| Cloudflare for SaaS | Cloudflareのネットワークのセキュリティとパフォーマンスの利点を、顧客のカスタムまたはバニティドメインを通じて拡張します。これには、証明書管理、SaaS用WAF、SaaS用早期ヒントおよびSaaS用キャッシュが含まれます。 |
| DDoS保護 | プロキシされたホスト名に対して、ボリュメトリック攻撃保護が自動的に有効になります。 |
| 地域サービス（データローカリゼーションスイートの一部） | データ（処理）の検査を管轄区域の境界内にあるデータセンターのみに制限します。 |
| ロードバランサー | エンドポイント間でトラフィックを分配し、エンドポイントの負担とレイテンシを減少させ、エンドユーザーの体験を向上させます。 |
| Cloudflareトンネル | ファイアウォールに穴を開けることなく、顧客のネットワークやサーバーに接続するための安全な方法です。cloudflaredは、アプリケーションからCloudflareへの安全なトンネルを作成するためにオリジンサーバーにインストールされるデーモン（ソフトウェア）です。 |
Cloudflareを使用する主な目的は、アプリケーションのカスタムホスト名へのすべてのリクエストが、最初にCloudflareのセキュリティおよびパフォーマンスサービスを通じてルーティングされ、セキュリティ制御とトラフィックのルーティングまたは負荷分散が適用されることを確保することです。オリジンサーバーは通常、公開アクセスが必要なため、Cloudflareとオリジンサーバー間の接続を保護することが重要です。オリジンサーバーを保護するための包括的なガイダンスについては、Cloudflareのドキュメントを参照してください: オリジンサーバーを保護する。
以下の図は、この目標を達成するための最も簡単なアプローチを示し、その後により複雑な構成を示します。
この標準的なCloudflare for SaaSのセットアップは、最も一般的に使用され、ほとんどのプロバイダーにとって実装が最も簡単です。通常、これらのプロバイダーはSaaS企業であり、サービスとしてのソフトウェアソリューションを開発および提供します。このセットアップでは、リクエストをCloudflareに指向するために単一のDNSレコードのみが必要であり、その後、Aレコードを使用してトラフィックをアプリケーションにプロキシします。
- カスタムホスト名（
custom.example.com）は、プロバイダーのフォールバックオリジンを指すCNAMEレコードとして構成されます。フォールバックオリジンは、カスタムホスト名へのリクエストが行われたときにCloudflareがデフォルトでトラフィックをルーティングするサーバーまたはサーバー群です。このDNSレコードはCloudflare内で管理する必要はなく、単にプロバイダーのCloudflareホストレコード（fallback.myappexample.com）を指す必要があります。 - フォールバックオリジンは、オリジンサーバーのパブリックIPアドレスを指すAレコードとして設定されます。Cloudflareは、カスタムホスト名に送信されたトラフィックをデフォルトでこのオリジンサーバーにルーティングします。
オリジンサーバーは、ホストヘッダーまたはSNIを通じてカスタムドメインの詳細を受け取ります。これにより、オリジンサーバーはリクエストをどのアプリケーションに指向するかを判断できます。この方法は、カスタムホスト名（たとえば、app.mycustomerexample.com）とバニティドメイン（たとえば、customer1.myappexample.com）の両方に適用可能です。すべてのリクエストがCloudflareネットワークを通じてルーティングされるため、各リクエストに対してさまざまなセキュリティおよびパフォーマンスサービスを活用できます。これには以下が含まれます：
開始するための実装の詳細については、開発者ドキュメントを確認してください。
このアプローチでは、Cloudflareの地域サービスソリューションを使用して、TLS終端とHTTP処理を地域化し、特定の地理的場所でデータを処理することを規定するコンプライアンス規制に準拠します。これにより、オリジンサーバーに向かうトラフィックが選択した地域内でのみ処理されることが保証されます。
- カスタムホスト名（
custom.example.com）は、地域化されたSaaSホスト名（eu-customers.myappexample.com）を指すCNAMEレコードとして構成されています。この構成により、TLS終端を含むすべての処理が指定された地理的地域内でのみ行われることが保証されます。 - 地域化されたSaaSホスト名は、SaaSプロバイダーの標準フォールバックオリジン（
fallback.myappexample.com）にトラフィックを誘導するCNAMEレコードとして設定されています。 - フォールバックオリジンは、オリジンサーバーのパブリックIPアドレスを指すAレコードとして設定されています。Cloudflareは、カスタムホスト名に送信されたトラフィックをデフォルトでこのオリジンサーバーにルーティングします。
セキュリティを強化するために、SaaSプロバイダーは、パブリックIPを介してアプリケーションサーバーを直接インターネットに公開するのではなく、Cloudflareトンネルを使用できます。これらのトンネルは、ネットワークをCloudflareの最寄りのデータセンターに接続し、SaaSアプリケーションにパブリックホスト名を介してアクセスできるようにします。その結果、Cloudflareは、パブリックインターネットからアプリケーションネットワークへのエンドカスタマーの唯一の入口となります。
- カスタムホスト名（
custom.example.com）は、地域化されたSaaSホスト名（eu-customers.myappexample.com）を指すCNAMEレコードとして構成されています。この構成により、TLS終端を含むすべての処理が指定された地理的地域内でのみ行われることが保証されます。 - 地域化されたSaaSホスト名は、SaaSプロバイダーの標準フォールバックオリジン（
fallback.myappexample.com）にトラフィックを誘導するCNAMEレコードとして設定されています。 - フォールバックオリジンは、Cloudflareトンネルによって公開されたパブリックホスト名を指すCNAME DNSレコードです。このパブリックホスト名は、アプリケーション（例:
localhost:8080）へのトラフィックをルーティングするように構成する必要があります。
この設定は、複数のオリジンサーバー間で地理ベースのトラフィックスティアリングが必要ないSaaSプロバイダーに最適です。また、オリジンサーバーを保護するためにCloudflareトンネルを介してのみリクエストを許可することが十分なシンプルなテストおよび開発環境にも適しています。ただし、グローバルおよびローカルレベルでの負荷分散を必要とする分散アプリケーションには、Cloudflareのロードバランサーを使用することをお勧めします。
Cloudflareは、強力な負荷分散機能を提供しています。これにより、SaaSアプリケーションがホストされている異なるオリジンサーバーにトラフィックを信頼性高く誘導できます。これは、上記のようにパブリックホスト名を介して行うことも、プライベートIPアドレスを介して行うこともできます。この設定は、トラフィックを複数のサーバーに分散させることでオリジンの過負荷を防ぎ、Cloudflareトンネルを介してのみリクエストを許可することでセキュリティを強化します。
- カスタムホスト名（
custom.example.com）は、Cloudflareの地域化されたロードバランサー（eu-lb.myappexample.com）を指すCNAMEレコードとして構成されています。これにより、TLS終端を含むすべての処理が指定された地理的地域内で行われることが保証されます。さらに、SaaSプロバイダーは、カスタムホスト名のカスタムオリジンとしてロードバランサーを設定する必要があります。 - 地域のロードバランサーは、複数の下流サーバーにリクエストを分散するためにオリジンプールを設定します。各プールは、グローバルトラフィック管理（GTM）を使用するパブリックホスト名またはローカルトラフィック管理（LTM）を使用するプライベートネットワークアドレスを使用するように構成できます。上の図では、両方のオプションを利用しています：
- オリジンプール1は、リクエストを処理するためのエンドポイントまたはオリジンサーバーとしてCloudflareトンネルホスト名（
<UUID>.cfargotunnel.com）を使用します。 パブリックホスト名を使用する場合、HTTPホストヘッダー値を、Cloudflareトンネルによって構成され公開されたパブリックホスト名と一致させる必要があります。これにより、オリジンサーバーが受信リクエストを正しくルーティングできるようになります。 - オリジンプール2は、SaaSプロバイダーの内部ネットワーク内にあるプライベートIPアドレスまたはプライベートネットワーク（すなわち、
10.0.0.5）を使用します。このプールは、リクエストの適切なルーティングを確保するために、指定された仮想ネットワーク内で動作するように構成する必要があります。
- オリジンプール1は、リクエストを処理するためのエンドポイントまたはオリジンサーバーとしてCloudflareトンネルホスト名（
- Cloudflareトンネルは、GTMを使用したパブリックホスト名とLTMを使用したプライベートネットワーク（プライベートIP）の両方を公開します。
アプリケーションの提供とスケーラビリティにおける粒度を高めるためには、一般的にパブリックホスト名よりもプライベートネットワークを使用することが推奨されます。プライベートネットワークは、Cloudflareがホストヘッダーを保持し、オリジンサーバーに正確に渡すことを可能にします。一方、パブリックホスト名を使用する場合、プロバイダーはロードバランサー上でヘッダー値を構成する必要があり、これはロードバランサーエンドポイントごとに1つのパブリックホスト名に制限されるため、柔軟性が制限される可能性があります。
Zero Trustのトンネル制限、Cloudflare for SaaSの接続リクエストの詳細、およびカスタムオリジンのSNI仕様に注意してください。Cloudflareのロードバランサーに関する詳細情報は、そのリファレンスアーキテクチャを確認してください。
SaaSプロバイダーとして、これらのプロセスのほとんど、あるいはすべてをAPI、SDK、スクリプト、Terraform、またはその他の自動化ツールを使用して自動化することをお勧めします。
高レベルの移行計画の例は、こちらからダウンロードできます。
Cloudflare for SaaSへの移行は段階的に行い、特にドメインコントロールバリデーション（DCV）に関する問題が発生した場合には、問題に対処することを強くお勧めします。プロセス中に検証ステータスと関連するドキュメントを確認してください。
Cloudflareのインフラストラクチャを活用することで、SaaSプロバイダーはエンドカスタマーに対して安全で信頼性が高く、パフォーマンスの高いサービスを提供できます。これにより、地域化などのコンプライアンス要件を満たしながら、シームレスで安全なユーザーエクスペリエンスが保証されます。
現在、いくつかのCloudflareの顧客がCloudflare for SaaSソリューション（以前はSSL for SaaSとして知られていました）を使用しています。注目すべき公共のユースケースには以下が含まれます：
さらに、Cloudflare for SaaSへの移行時には、ランブックとエンドカスタマーに関連する詳細を伝えるための明確な公開ドキュメントを持つことが重要です。これに関する優れた公開例としては、Salesforce CDN ↗やShopify ↗のドキュメントがあります。