同じSaaSプラットフォームでも、ある顧客は正常にログインできる一方、別の企業ではオフィス全体がレート制限を受ける。静的ページは速くてもリアルタイム通知が頻繁に切れる。キャッシュを有効にすれば、他のテナントのデータが見えてしまわないかも気になります。

SaaSでは、「サイトが開く」ことは導入テストの出発点にすぎません。

SaaS向けのDDoS対策CDNを選ぶ際は、まずテナント間のデータ分離、ログインとAPIの互換性、常時接続の安定性を検証します。そのうえで、ネットワーク経路、防御容量、費用を比較してください。

テナント間のデータ混在、認証フローの中断、常時接続の不安定さがあれば、トップページの表示速度が改善しても意味は薄れます。

SaaS向けCDNを一般的なWebサイトと同じ基準で選べない理由

マルチテナントとは、複数の企業や組織が同じプラットフォームを利用しながら、それぞれのアカウント、データ、権限を持つ構成です。サーバー、データベース、アクセスの入口を共有していても、データとアクセス権限の境界は明確でなければなりません。

そのため、評価対象は一つのドメインではありません。メインサイト、テナント別サブドメイン、顧客独自のドメイン、ログイン、API、ファイルのダウンロード、リアルタイム接続を一連の仕組みとして確認する必要があります。

例えば、10のテナントが一つの送信元IPを共有していても、同一ユーザーではありません。また、あるテナントが短時間に大量のレポートをエクスポートしても、プラットフォーム全体のAPI容量を自動的に使い切るべきではありません。CDNの設定は、アプリケーションの認証、割り当て、リソース管理と連携させる必要があります。

まず、キャッシュがテナントの境界を越えて使われないか確認する

ドメイン、パス、リクエストヘッダーは応答内容にどう影響するか？

一般的なテナントへのアクセス方法には、次のものがあります。

• サブドメイン：tenant-a.example.comとtenant-b.example.com。
• パス：example.com/tenant-a/とexample.com/tenant-b/。
• 共有API：パスは同じで、セッションまたはトークンからテナントを識別します。
• 独自ドメイン：顧客ごとに自社ブランドのドメインを使用します。

CDNは通常、キャッシュキーで保存済みのコンテンツを区別します。これは、二つのリクエストに同じ内容を返せるかを判断するための識別子です。実際のルールで、応答内容に影響するドメイン、パス、パラメータを区別できるか確認してください。特に、カスタムキャッシュキー、クエリパラメータの除外、パスの書き換えに注意が必要です。

例えば、二つの企業が同じ/api/reportというパスにアクセスしても、返されるのはそれぞれの経営レポートです。パスだけでキャッシュすると、誤った応答を再利用する恐れがあります。キャッシュキーにテナントIDを含めても、同じテナントの管理者と一般ユーザーでは閲覧権限が異なる場合があります。

キャッシュを分けて保存することと、リクエストの認可が済んでいることは別です。

ログインやユーザー権限に依存する機密性の高い応答は、まず共有キャッシュを避ける構成を検討します。キャッシュが必要な場合に限り、信頼できる認証・認可、分離の単位、無効化の仕組みを設計してください。

OWASPのマルチテナントセキュリティガイドが指摘するように、クライアントから送られたテナント識別子はアクセス先の選択には使えても、サーバー側でそのユーザーにアクセス権があるか確認する必要があります。X-Tenant-IDヘッダーがあるだけで認可されたとは判断できません。

CookieやSet-Cookieがあっても、自動的にキャッシュが禁止されるわけではない

「ログインCookieが付いているAPIは、CDNが当然キャッシュしない」というのは誤解です。動作は製品、ルール、上書き設定によって異なります。デフォルトの動作をセキュリティの境界として扱わないでください。

IETFのHTTPキャッシュ標準RFC 9111では、Set-Cookieだけではキャッシュを防げないと明記されています。応答を保存するかどうかは適切なキャッシュ指示で制御し、CDNに強制キャッシュなどの上書きルールがないかも確認します。

保存すべきでない機密性の高い応答には、アプリケーションから次の応答ヘッダーを返せます。導入後は実際の動作を検証してください。

Cache-Control: no-store

これはHTTP応答ヘッダーの例であり、ターミナルで実行するコマンドでも、すべてのAPIに一律適用する設定でもありません。公開ヘルプ、バージョン付きのスクリプト、画像には、内容に応じて別のキャッシュ方針を採用できます。

少なくとも二つのテナント、同じテナント内の異なる権限、未ログイン状態をテストしてください。分離したブラウザーセッションで同じアプリケーションのパスに順次アクセスし、返されたデータの帰属を確認します。ログアウト、メンバーの削除、権限の引き下げ後には、それまで閲覧できたデータを取得できないことも検証します。

まずテナントAがリクエストし、次にテナントBが対応するURLへアクセスします。順序を逆にして繰り返し、キャッシュヒット時とオリジンへのアクセス時の両方を確認してください。各テナントに固有で見分けられるテストデータを使い、同じサンプル値が誤ったキャッシュの再利用を隠さないようにします。

独自ドメインには導入と解除の手順も必要

企業向けSaaSでは、ドメインの管理が継続的に発生します。新規顧客の追加、証明書の更新、ドメインの解除、解約時には、それぞれ対応する手順が必要です。

選定時には、接続できる独自ドメイン数、所有権の確認方法、証明書の管理方法、ルールの一括適用、解除後のドメインとテナントの紐付けの削除方法を確認します。ワイルドカード証明書では、顧客が所有する任意の独自ドメインをカバーできません。

これらの機能は「複数ドメインに対応」から推測できません。規模が大きい場合、ドメインを一つずつ手動で設定する時間も運用コストに含めてください。

ログイン保護で企業全体を誤ってブロックしないためには？

IP単位のレート制限では、企業の共有出口を考慮する

企業のオフィス、大学、モバイルネットワークでは、多くの正規ユーザーが一つのパブリックIPアドレスを共有することがあります。単純なIP単位のしきい値だけでは、朝の一斉ログイン、一括でのページ更新、クライアントの同期時に誤ってブロックする可能性があります。

一方、分散型のクレデンシャルスタッフィングでは、多数のIPアドレスに試行を分散できます。送信元ごとの頻度が低く見えても、アカウントにはパスワード試行が続いている場合があります。

OWASPの認証セキュリティガイドは、失敗回数をアカウントに紐付けることを推奨し、アカウントロック自体が正規ユーザーの利用を妨げるために悪用され得ると注意を促しています。IPのしきい値だけを上下させるのではなく、送信元、アカウント、アプリケーション上の動作をあわせて評価してください。

役割を分けて考えます。CDNは入口での異常なトラフィックと識別可能なリクエストの特徴に対応し、アプリケーションはアカウントの状態、認証、テナント権限、信頼できるIDを必要とする利用枠を管理します。必要な単位のルールにCDNが対応するかは、個別のプランで検証してください。CDNが自社のテナントやアカウントの仕組みを理解していると決めつけてはいけません。

ログインページ、送信処理、認証コールバックを個別にテストする

SaaSのログインには、シングルサインオン（SSO）、多要素認証、IdPへのリダイレクト、コールバック、トークン更新が含まれる場合があります。ログインページが開くだけでは、そのうち一つの段階しか確認できません。

少なくとも次のパスを整理します。

すべてのマシン間APIにブラウザー認証チャレンジを強制しないでください。JSONを期待するクライアントがHTMLのチャレンジページを受け取れば、ステータスコードが200でもエラーになる可能性があります。一方、コールバックを通すためにサイト全体の保護を無効にすれば、リスクにさらされる範囲が広がります。

APIの分類とルール設計にはAPIへの過剰なリクエストに対する防御方法を参考にし、ログイン、照会、エクスポート、外部連携を分けて扱います。各セキュリティ機能の役割についてはWAF、Bot管理、DDoS対策の連携方法も参照してください。

WebSocketとSSEの常時接続では、何をテストすべきか？

まず接続の種類を分け、制限を確認する

リアルタイム通知、共同作業、AIによる生成結果には、WebSocketまたはSSEが使われます。両者は同じものではありません。

WebSocketは継続的な双方向通信に適しています。WebSocketプロトコルのRFC 6455にあるとおり、接続確立後もデータのやり取りが続くため、ハンドシェイクの成功だけでは十分なテストになりません。

SSEでは、サーバーがHTTP経由でクライアントにイベントを継続的に送信します。MDNのSSEの利用ガイドによると、イベントストリームはtext/event-stream形式を使い、メッセージを空行で区切ります。導入後は、メッセージが順次届き、最後にまとめて返されないことを確認してください。

WebSocketに対応しているだけで、SSEや他のストリーミングプロトコルもアプリケーションの想定どおり動作するとは限りません。アイドルタイムアウトと接続の最大継続時間は分けて確認してください。ハートビートですべての切断を防げるわけでもありません。

SSEのイベントが順次届くかテストする

curlをインストールしたLinuxまたはmacOSのターミナルで、次のコマンドを使ってテスト用のイベントストリームを確認できます。例のURLを実際のSSE APIに置き換えてください。認証が必要な場合は専用のテストセッションを使用し、テストのために本番APIを公開しないでください。

curl -N -sS --connect-timeout 5 --max-time 30 \
  -H 'Accept: text/event-stream' \
  -D - \
  'https://example.com/events'

curlの公式マニュアルによると、-Nが無効にするのはcurl自身の出力バッファリングです。CDN、ゲートウェイ、オリジンのバッファリングには影響しません。--max-time 30はテスト全体を30秒に制限します。

応答形式、イベントの内容、到着間隔を確認します。テスト用オリジンが一定の間隔でイベントを送信しているのに、クライアントにはまとめて届く場合は、オリジンの送信ログとクライアントの受信時刻を照らし合わせ、各段階のバッファリングを調べます。その現象だけでCDNが原因とは判断できません。

401や403は未ログインやアクセス制御が原因かもしれません。まず有効なテスト用IDを用意してください。コマンドが30秒後に終了してタイムアウトを報告しても、それだけでサービス障害とはいえません。これは短時間の接続と出力を確認するテストです。正式な受け入れ検証では、必要な接続継続時間、アイドル期間、ネットワーク切断からの復旧も確認します。

接続の復旧時にログインサービスへ負荷を集中させない

エッジの切り替え、クライアントのネットワーク変更、サービスのデプロイ後には、多数の接続が短時間に再確立される場合があります。すべての接続が同時にトークン更新、権限照会、再購読を行うと、認証・購読サービスが新たなボトルネックになります。

クライアント側のバックオフとランダムな遅延、再認証、購読の復旧、メッセージの重複排除、必要な再送の仕組みをテストしてください。SSEクライアントが自動再接続できても、アプリケーションが失われたイベントを再送できるとは限りません。WebSocketの再接続でもセッション状態は自動的には戻りません。

常時接続の確立後も、テナント、チャネル、メッセージへのアクセス権限はアプリケーション側で適用する必要があります。CDNの評価では、ハンドシェイクのリクエストを検査する機能と、接続内のメッセージを検査する機能を区別してください。

一つのテナントが攻撃を受けても、他のテナントは利用を続けられるか？

マルチテナントの可用性はCDNだけでは決まりません。あるテナントへの大量のリクエストが、共有のアプリケーションスレッド、データベース接続、エクスポートキュー、ファイル処理リソースを消費する場合があります。

二つの層を評価します。入口では異常なトラフィックの影響範囲を抑えられるか。アプリケーションでは、テナントごとの同時実行数、ジョブ、リソース利用に適切な境界を設けているか。

テナント単位のレート制限には、信頼できる識別情報が必要です。クライアントがリクエストヘッダーを書き換えるだけで制限を回避したり、別のテナントに使用量を付け替えたりできてはいけません。ログイン前で信頼できるテナントIDがないリクエストには、別の入口保護ポリシーが必要です。

運用時にはプラットフォーム全体の平均値だけを見ないでください。少なくとも、影響を受けたドメイン、パス、ルール、時間帯をアプリケーションの記録と照合し、CDNによるブロック、オリジンへの接続失敗、アプリケーション処理のどこに問題があるか判断する必要があります。テナント別の情報は信頼できるアプリケーションログで補えます。すべてのCDNが直接提供すると決めつける必要はありません。

ログにはパスワード、完全なトークン、機密性の高い業務データ本文をそのまま保存しないでください。照合に使うリクエストIDやテナントIDも、発行元とアクセス権限を明確にします。

SaaS向けCDNの比較で、料金とネットワーク経路をどう評価するか？

応答が小さいSaaS APIでも、リクエスト頻度が高ければ帯域幅以外のリソースを使います。リアルタイム共同作業のプラットフォームは、転送量が少なくても大量の接続を長時間維持する場合があります。月間転送量だけで総費用を見積もると、重要な項目を見落とします。

見積もりを依頼する際は、ドメイン数、月間転送量、ピークリクエスト数、同時接続数、新規接続レート、ログの要件、必要なセキュリティ機能を分けて提示してください。各項目が課金対象か、計測方法は何か、プランに含まれるかを確認します。

大口顧客の独自ドメインの増加、ログ保存期間の延長、大量の一斉再接続は、いずれもリソース要件を変えます。DDoS対策CDNのプラン、通常トラフィック、追加料金の内訳も参考に、通常月とピーク時を分けて見積もってください。

経路のテストも用途ごとに分けます。静的リソースでは配信、ログインや照会では動的なオリジン接続、リアルタイム機能では継続的な転送と復旧を確認します。オリジンが中国本土以外にあり、主な企業顧客が中国本土にいる場合は、海外オリジンから中国本土への配信性能と防御のガイドも参考に、主要地域、通信事業者、業務時間帯を測定してください。

サービスを比較する際には、CDN07のDDoS対策CDNサービスもテスト対象にできます。コンテンツ配信とDDoS対策を組み合わせ、WebSocketへの対応が案内されており、エッジ拠点、帯域幅、セキュリティポリシーを用途に合わせて調整する選択肢があります。SaaSに適するかを検討する出発点にはなりますが、テナント別のキャッシュルール、SSOとの互換性、SSEの動作、利用枠の管理は個別に検証してください。製品名だけから判断できません。

試用時の受け入れ検証：導入前に何を確認するか？

許可されたテスト環境で、二つのテナント、異なる権限のアカウント、実際のクライアントを用意し、まず動作の正しさを確認してから性能と防御を評価します。本番環境で独自にクレデンシャルスタッフィングを模擬したり、合意のない負荷テストを行ったりしないでください。

テナント分離に失敗する、主要な認証フローを完了できない、または業務に必要な常時接続に対応できない場合は、導入範囲を広げる前に解決してください。防御容量の数値が大きく、静的リソースの測定結果が速くても、これらの問題を補うことはできません。

よくある質問

SaaSにCDNを導入すると、別のテナントのデータが見えるようになる？

共有キャッシュや権限設定を誤ると、その危険があります。ただし、CDN導入によって必ず起こるわけではありません。公開、テナント別、ユーザー別のコンテンツを分け、キャッシュヒット、ログアウト、権限変更後の動作を確認してください。

テナントごとに別のサブドメインがあれば、データは十分に分離される？

それだけでは不十分です。キャッシュキー、オリジンへの振り分け、アプリケーション側の認可、データアクセスも確認してください。カスタムルールで異なるドメインを同一に扱ったり、アプリケーションがテナント権限を検証しなかったりすれば、境界を越える恐れがあります。

従業員が一斉にログインするとレート制限される。防御が厳しすぎる？

共有出口や集中ログインにルールが合っていない可能性はありますが、他の原因も考えられます。該当したルール、アカウントの動作、アプリケーションログを確認してください。IPのしきい値を上げるか、防御を完全に無効にするだけでは解決しません。

WebSocket対応のDDoS対策CDNなら、SSEにも対応している？

そうとは限りません。SSEについては継続的なHTTP応答、バッファリング、キャッシュ、タイムアウトを個別に確認します。WebSocketでは接続とメッセージの処理を検証します。両方を受け入れテストに含めてください。

SSEの出力が最後にまとめて届くのは、CDNがキャッシュしているから？

必ずしもそうではありません。アプリケーション、リバースプロキシ、圧縮処理、CDN、クライアントのいずれも出力のタイミングに影響します。各段階の送信・受信記録を比較し、バッファリングとフラッシュの動作を調べてください。

DDoS対策CDNはSaaSのアカウント管理やテナント認可を代替できる？

できません。CDNは適切な入口保護を担えますが、アカウントの状態、テナントのメンバー関係、オブジェクト単位の権限、利用枠は、信頼できるアプリケーションロジックで引き続き管理する必要があります。

選定時には実際のアプリケーション操作をテストする

SaaS向けDDoS対策CDNの評価では、次の四点を確認します。

• キャッシュヒット後も、テナントとユーザーの権限が正しく適用される。
• 防御を有効にしても、ログイン、SSO、マシン間APIが完了する。
• 常時接続は確立できるだけでなく、通信を続け、適切に復旧できる。
• 一つのテナントの異常、障害調査、費用の増加を管理できる。

次に、テナントのアクセス方式、ドメイン数、ログイン経路、常時接続の種類、ピーク時の使用量、主要なユーザー地域を整理し、代表的なテナントを選んで検証します。

CDN07をテストする場合は、DDoS対策CDNの導入・構成相談を通じてこれらの要件を伝え、必須条件をテスト項目に記載してください。テナント分離、ログインの成功、継続的な通信を基に適合性を判断するほうが、防御容量だけを比較するよりSaaSに必要な可用性を評価できます。