CDNとWAFは、企業サイトの性能とセキュリティを考える際にセットで検討されることがあります。しかし、「CDNの前後どちらにWAFを置くのか」「CDNにWAF機能があれば別製品は不要か」「オリジンサーバーへ直接アクセスされたらどうなるのか」など、構成上の論点は少なくありません。
CDNは利用者に近い拠点からコンテンツを配信し、オリジンサーバーへの負荷を軽減します。WAFはWebアプリケーションへのリクエストを検査し、不正な通信を検知・遮断します。両者を組み合わせる際は、正常時の高速化だけでなく、攻撃時、障害時、更新時の挙動まで確認することが重要です。
本記事では、CDN/WAF構成を検討する企業サイト担当者向けに、基本構成と設計・運用のチェックポイントを整理します。
この記事のポイント
- CDNは配信・負荷分散、WAFはアプリケーション入口の検査が中心
- すべての通信がCDN・WAFを通るよう、オリジンへの直接アクセスを制限する
- キャッシュ対象、フォーム、管理画面、APIを分けて設計する
- 障害時のバイパス・切り戻しとログの突合方法まで確認する
|
観点 |
CDN |
WAF |
|
主目的 |
高速・安定したコンテンツ配信、負荷分散 |
不正なWebリクエストの検知・遮断 |
|
主な処理 |
キャッシュ、エッジ配信、経路最適化 |
ルール照合、レート制限、アクセス制御 |
|
守る対象 |
オリジンサーバーの負荷・露出 |
Webアプリケーションへの攻撃 |
|
運用論点 |
キャッシュ更新、TTL、障害時配信 |
誤検知、ルール更新、例外、ログ |
|
単独では不足する点 |
CMS内部の不正操作や脆弱性修正 |
配信最適化、改ざん後の状態監視 |
CDNにもDDoS緩和やWAF機能が含まれる場合がありますが、機能名だけで同等とは判断できません。保護対象、ルール、ログ、運用支援、契約範囲を比較します。
|
項目 |
確認ポイント |
|
|
1. DNS |
切替方法、TTL、切り戻し、複数ドメイン |
|
|
2. TLS証明書 |
発行・更新・保管の担当、暗号化区間 |
|
|
3. オリジン保護 |
CDN/WAF以外からの直接アクセス制限 |
|
|
4. キャッシュ |
HTML、画像、PDF、API、Cookieごとの方針 |
|
|
5. 動的処理 |
フォーム、検索、ログイン、プレビューの扱い |
|
|
6. 管理画面 |
公開サイトと分離するか、IP・認証制限 |
|
|
7. クライアントIP |
アクセスログへ正しく引き継げるか |
|
|
8. ログ |
CDN・WAF・オリジンの時刻とIDを突合できるか |
|
|
9. 障害対応 |
フェイルオーバー、バイパス、切り戻し |
|
|
10. 更新運用 |
キャッシュ削除、公開反映、緊急修正の手順 |
|
章 |
主な内容 |
読み手が確認すること |
|
1. プロジェクト概要 |
案件名、背景、目的、成功条件、前提 |
なぜ行うのか |
|
2. 現状と課題 |
現行サイト、CMS、運用、アクセス、保守の課題 |
何を変えるのか |
|
3. ターゲット・方針 |
主要ターゲット、導線、コンテンツ・デザイン方針 |
誰へ何を伝えるのか |
|
4. 対象範囲 |
対象サイト、ページ、言語、外部サービス、対象外 |
今回はどこまで行うのか |
|
5. コンテンツ要件 |
新規・改稿・移行・削除、原稿・撮影・校正の役割 |
何を準備するのか |
|
6. 運用要件 |
編集者、承認者、更新頻度、緊急対応、研修 |
公開後に誰が回すのか |
|
7. 機能要件 |
CMS、検索、フォーム、ニュース、IR、多言語、連携 |
何ができる必要があるか |
|
8. 非機能要件 |
セキュリティ、性能、可用性、バックアップ、アクセシビリティ |
どの品質を守るか |
|
9. 移行・公開要件 |
コンテンツ、URL、リダイレクト、テスト、公開手順 |
安全に切り替えられるか |
|
10. 体制・スケジュール・予算 |
役割、会議体、マイルストーン、費用前提 |
どう進めるのか |
|
11. 決定事項・未決事項 |
状態、担当者、決定期限、提案依頼事項 |
次に何を決めるのか |
CDNの効果を高めるには、キャッシュ可能なコンテンツを増やすことが有効です。一方で、ログイン状態、個人ごとの表示、フォーム完了画面、プレビューなどを誤ってキャッシュすると、情報漏えいや表示不整合につながります。
- 画像、CSS、JavaScript、公開PDFは長めのキャッシュを検討する
- ニュースやトップページは更新頻度に合わせてTTLを設定する
- Cookieや認証ヘッダーを使うページはキャッシュ条件を明確にする
- フォーム入力・完了ページは原則として個別に扱う
- 緊急更新時に対象URLだけキャッシュ削除できるようにする
- 公開処理とCDNキャッシュ削除を運用フローで連携する
WAFルールも性能へ影響する場合があります。大きなファイルアップロード、複雑なパラメータ、API通信などは、正常な利用シナリオを用いた負荷・動作確認が必要です。
CDNやWAFを導入しても、オリジンサーバーのIPアドレスへ直接アクセスできる状態では、保護経路を迂回される可能性があります。CDN・WAFの送信元だけを許可する、認証用ヘッダーを利用する、管理系経路を分離するなど、構成に応じた制限を検討します。
直接アクセス制限は切り戻し手順とセット
障害時にCDNを迂回する必要がある構成では、誰が、どの条件で、どのくらいの時間だけ制限を変更するかを決めます。恒久的な例外を残さない運用が必要です。
- CDN、WAF、オリジンのどこで異常が起きているかを切り分ける。
- 影響するURL、地域、利用者、機能を特定する。
- キャッシュ配信の継続、ルール緩和、バイパスの可否を判断する。
- ログ・設定変更を保全し、関係者へ状況と次回更新時刻を連絡する。
- 復旧後に設定を戻し、再発防止と監視ルールを見直す。
提供会社が複数に分かれている場合、障害時の連絡順序と主担当を決めておくことが重要です。各社が「自社範囲は正常」と回答するだけで終わらないよう、全体を統括する役割を明確にします。
- 経営・責任者レビュー:背景、目的、対象範囲、予算、スケジュールを確認する
- 関係部門レビュー:コンテンツ、導線、運用、承認、原稿責任を確認する
- 情報システムレビュー:セキュリティ、アカウント、連携、保守、データ管理を確認する
- 制作会社レビュー:実現方法、前提、未決事項、費用・スケジュールへの影響を確認する
- 更新履歴には、変更日、変更箇所、理由、決定者、影響範囲を記録する
-
CDNとWAFは同時に導入できますか?
可能です。同一サービスに統合される場合と、別サービスを連携する場合があります。通信経路、証明書、クライアントIP、ログ、障害時の責任分界を確認します。
-
CDNにWAF機能があれば十分ですか?
必要な防御ルール、Bot・DDoS対策、ログ、チューニング、有人運用が満たされるかで判断します。名称ではなく要件との適合を確認してください。
-
CDNのキャッシュで更新が反映されないことはありますか?
キャッシュ設定により旧コンテンツが一定時間残ることがあります。CMS公開時のパージ、TTL、緊急削除の方法を決めます。
-
管理画面もCDNやWAFを経由させるべきですか?
構成によります。管理画面を公開サイトから分離し、IP制限や追加認証を使う場合もあります。管理系通信の可用性と安全性を別途設計します。
CDNとWAFは、性能と防御を異なる角度から支える仕組みです。組み合わせる際は、DNS、証明書、通信順序、オリジン保護、キャッシュ、動的処理、ログ、障害時の切り戻しを設計します。
正常時の高速化だけでなく、攻撃・障害・緊急更新のシナリオで動作と責任分界を確認することが、安定した企業サイト運用につながります。
企業サイトの多層防御を、運用まで含めて整理する。
WAF・改ざん検知・CDN・監視・バックアップを含む
ShareWithのセキュリティ対策をご覧いただけます。

