WAF／CDNの基本と設定例：静的・APIの守り方

「WAFを入れたから安心」「CDNを入れたから速いし強い」——現場では、この“思い込み”が事故の入口になります。WAF（Web Application Firewall）はアプリ層の入口で不正なリクエストを検知・遮断する仕組みで、CDNは配信最適化を軸にしつつ、エッジで落とせる攻撃を減らし、オリジン負荷を軽くする役割を持ちます。どちらも強力ですが、設計と運用を誤ると「守るための投資」が「止まる原因」になり得ます。代表例は「誤検知で業務停止」「APIだけ無防備」「ログがつながらず原因不明」です。

本記事はPM・管理職・QAエンジニア向けに、WAFとCDNの基本を押さえつつ、静的コンテンツとAPIを現場で守るための設定例・導入手順・運用フローを一気通貫で整理します。軸は3つです。段階的に強くする、境界を分ける、ログと変更管理で回す。この3点を押さえるだけで、WAF／CDNは“実務で効く道具”になります。

1. なぜ今、WAF／CDN／APIセキュリティがPM・管理職・QAに効くのか

WAFとCDNの導入は、セキュリティ担当だけのテーマではありません。PMや管理職にとっては停止時間（ダウンタイム）と対応工数の最小化、QAにとっては運用変更が引き起こす品質事故の抑止という意味で、事業の安定に直結します。たとえば、トラフィック急増やHTTPフラッドはCDNで吸収できる範囲があり、WAFでレート制限を重ねると“初動の火消し”が速くなります。ここで重要なのは「攻撃をゼロにする」ではなく、被害が拡大する速度を落とし、復旧を早めることです。

特にAPIの領域は、ほぼ全てのプロダクトがAPI中心になったことで、脆弱性の主戦場がUIからAPIへ移っています。APIの安全は、認証・認可、レート制限、異常検知、ログ相関など、複数レイヤーの積み重ねで成立します。WAFはその一部（入口での検知・遮断）を担い、CDNは前段でオリジン負荷を下げて耐障害性を上げることで、事故の規模を抑える役割を持ちます。

現場でよくある“詰み”パターン：WAFをいきなりブロックモードで入れて誤検知→問い合わせが殺到→急いで緩める→本当に守りたいAPIの設計は手つかず。
結論、WAFもCDNも「検知→部分遮断→全面遮断」の段階設計が必要です。

QA観点でも、WAFやCDNの設定変更は“機能追加と同じレベルの仕様変更”になり得ます。たとえばWAFのルールで特定パラメータが弾かれる、CDNのキャッシュで古いレスポンスが残る、レート制限で429が返る——これらはテストしないと本番事故になります。だからこそ、PMが変更管理を設計し、QAが再現と回帰を担い、開発が根本修正をする、という役割分担がWAF・CDN運用の成功条件になります。

2. 基本の整理：WAFとCDNの違い、そしてAPIの責務分界

WAFはHTTP/HTTPSリクエストを評価し、シグネチャ（既知の攻撃パターン）や挙動（異常頻度、サイズ、ヘッダ）に基づいて検知・遮断します。CDNはエッジにコンテンツをキャッシュし、ユーザーに近い地点から配信することでレイテンシを下げ、オリジン負荷を減らします。混同されやすいのが「CDNがあるからWAFはいらない」「WAFがあるからAPIは後回しでいい」という判断です。実務的には、WAFとCDNは別の穴を埋めるもので、どちらか一方では完結しません。

WAFで守れるのは、SQLi/XSSのような入力攻撃、パス探索、明らかなBot挙動、過大なリクエストボディなど、入口に現れる兆候です。一方でWAFで守れないのは、認可の欠陥（他人のデータが見える）、アプリ内部の権限設計ミス、ビジネスロジックの悪用（返品APIの乱用など）です。つまり、APIの中心である認証・認可はアプリ側が責任を持つべき本丸で、WAFは補助輪として使います。

CDNで守れるのは、静的配信の高速化による負荷軽減、エッジでの簡易DDoS耐性、キャッシュによるオリジン保護です。ただしCDNの設定ミスは、キャッシュ汚染や、ユーザーごとに異なる情報をキャッシュしてしまう事故（意図しない共有）につながります。APIの観点では、APIをむやみにキャッシュしない、キャッシュするなら境界（公開/非公開）を明確にする、という設計が必須です。

アーキテクチャの基本形は「クライアント → CDN → WAF → オリジン（Web/API）」です。CDNとWAFの順序はサービスで異なりますが、実務ではエッジで落とせるものはエッジで落とし、アプリに届く前にWAFで判定し、アプリは認証・認可を守るという思想が揃っていれば問題ありません。ここから先は、静的とAPIを分けて具体的な設定例に落としていきます。

3. 設定例：静的コンテンツをCDNで強くする（キャッシュ設計＋WAFの最小構成）

静的サイト（コーポレート、LP、ドキュメント、ヘルプ）の基本は、CDNでキャッシュを効かせてオリジンに行かない比率を上げることです。CDNの設定で最初に決めるのはキャッシュキーです。何を同一とみなすか（パス、クエリ、ヘッダ、Cookie）を誤ると、表示崩れだけでなく“別ユーザーの情報を見せる”という重大事故になります。静的配信では、Cookieや認証ヘッダをキャッシュキーに含めない、または静的経路ではCookie自体を受け付けない、といった割り切りが安全です。

TTL設計は、更新頻度と運用体制に合わせます。運用に慣れていない場合は短めのTTLで始め、問題が出ないことを確認して段階的に長くします。おすすめは、ビルド時にファイル名へハッシュ（例：app.3f2a1.js）を付け、CDNは長いTTLで配信し、HTMLだけ短めにして参照先を更新する方式です。これならパージ乱発に依存しない運用に寄せられ、CDNの強みが素直に出ます。背後にCMSや管理APIがある場合は、その経路だけキャッシュを無効にし、境界を明確にします。

静的サイト向けのWAFは、最初から複雑にしません。マネージドルールを有効化し、明らかな攻撃（スキャン、パス探索、異常ヘッダ）をまず検知します。いきなりブロックを強くすると誤検知でフォームや問い合わせが止まるため、最初はログ中心で当たりを取り、誤検知は最小範囲で除外します。CDNとWAFを組み合わせる場合、静的経路はCDNで吸収し、動的経路（フォーム、ログイン）はWAFを厳しめにする、という境界分離が安定への近道です。

最後にヘッダ周りも“守り”です。HTTPS強制、HSTS、不要なレスポンスヘッダの削除、CSPなどはCDN側で付与できる場合があります。WAFとCDNは入口を守りますが、ブラウザ側の防御（CSPなど）も組み合わせると、改ざんやXSSの影響範囲を抑えられます。静的は軽視されがちですが、ユーザーが最初に触れる場所だからこそ、CDNとWAFで軽く強くしておく価値があります。

4. 設定例：APIをWAFとCDNで現実的に固める（認証→制限→検知→遮断）

APIの安全は「認証・認可が正しい」ことが大前提です。WAFはAPIを“代替”できませんが、入口の制限と検知で被害を小さくできます。実務で効く順番は、認証→制限→検知→遮断です。まず認証と認可（ユーザーが触れてよい範囲）を整理し、次にレート制限でリソース消費を止め、ログで異常を検知し、最後にWAFで段階的に遮断します。いきなり遮断から始めると誤検知で本番が止まり、強化どころではなくなります。

WAFがAPIに効くのは入力攻撃だけではありません。たとえば、メソッド制限（GETのみの経路にPOSTを弾く）、ボディサイズ上限（巨大JSONでメモリを食わせる攻撃を抑止）、ヘッダ衛生（疑わしいUser-Agentや必須ヘッダ欠落を検知）などは、入口の“衛生管理”として非常に有効です。さらに、認証前のログインAPIはクレデンシャルスタッフィングの的になるため、レート制限やBot対策を最優先で適用します。

レート制限の粒度は、IPだけに頼らないのがコツです。攻撃者はIPを変えられるため、APIキー、ユーザーID、トークン、端末IDなど、可能な範囲で“主体”に寄せます。CDNを前段に置く場合は、エッジでの制限機能を使い、WAFで追加制限を重ねると、オリジンに届く前に“燃料”を減らせます。ここでも公開APIと認証必須APIで扱いを分けることが重要です。公開GETの一部はCDNキャッシュで守り、認証が絡むAPIはキャッシュしない、という境界が事故を防ぎます。

例：優先順位（現場の型）
①認可レビュー（他人のデータを参照できないか）→②ログイン/重要APIのレート制限（WAF）→③サイズ/メソッド/パスの入口制限（WAF）→④ログ相関で異常検知→⑤ブロックを段階的に強化（WAF）→⑥必要に応じてCDNでキャッシュ/吸収を最適化。

APIはQAの出番も大きい領域です。429（Too Many Requests）が返ったときのクライアント挙動、再試行バックオフ、誤検知時の再現手順、ステージングと本番の差（CDNやWAFの有無）をテストケース化します。WAFとCDNは環境差を生むので、テスト計画に組み込むのが実務の最短距離です。

5. 運用・監視：WAF／CDNを“回る仕組み”にする

WAFとCDNは、導入した瞬間ではなく、運用が回った瞬間に価値が出ます。最初に用意したいのは、ログの3点セットです。CDNのアクセスログ、WAFのイベントログ、アプリ/APIのログを同じ観点で追えるようにし、可能なら相関ID（リクエストID）で紐づけます。運用の肝は「誰が」「何に」「どれだけ」アクセスしたかが追えることです。これができると、レート制限の判断や、インシデント時の影響範囲特定が一気に楽になります。

誤検知の扱いは必ずプロセス化します。WAFは最初は検知モードで当て、誤検知が出たら除外を最小範囲で入れます。ここで全体を緩めると、WAFの価値が落ちます。CDNも同様に、ヒット率だけを追うと境界が壊れて事故ります。指標は、CDNはヒット率・オリジン負荷・エラー率、WAFは遮断率・誤検知率・トップルール、アプリ/APIは認証失敗・異常トラフィック・レート制限発生・重要APIのSLO、といった形で分けると判断が早くなります。

インシデント時は、WAFとCDNをレバーとして使えると強いです。CDN側で急増トラフィックの吸収を最大化し、WAF側でレート制限や特定パス遮断を段階的に強化し、狙われているエンドポイントを優先して保護します。復旧後は、認可や入力検証を直す根本対応に戻します。WAF・CDN・アプリの三位一体で、止まりにくい運用に寄せていきます。

6. 導入ロードマップ：最短で成果を出す進め方（チェックリスト付き）

最短で成果を出す導入ステップは、①対象棚卸→②境界分離→③検知から開始→④部分遮断→⑤運用定着です。棚卸では「静的（CDN強め）」「動的UI（WAF強め）」「API（認証・認可と制限を強め）」に分け、どこが最重要か（売上・認証・管理画面）をPMが決めます。次に、CDNでキャッシュする経路としない経路を決め、認証が絡むAPIはキャッシュしないを原則にします。

そのうえでWAFは検知モードで当て、1〜2週間ログを見て誤検知の傾向を掴みます。遮断は、まずログインや重要APIなど守りたい場所から始めます。レート制限は段階的に厳しくし、429の発生がUXに与える影響をQAが確認します。CDN側の変更も同様に、更新（パージ/リビジョン）手順をCI/CDに寄せると安全です。ここまでを2〜4週間で回せると、投資対効果が目に見えてきます。

ベンダー選定では、単に「WAFがある」「CDNがある」ではなく、運用が回るかを見ます。管理画面の分かりやすさ、ログの取りやすさ（外部SIEM連携）、ルールのカスタマイズ性、Bot/レート制限の柔軟性、チューニング支援の有無がポイントです。WAFとCDNが分断されるほど運用は重くなるため、体制や経験に合わせてどこまで統合するかを決めるのが現実的です。

WAFのルール変更、CDNのキャッシュ変更は、プロダクトの“仕様”に近いインパクトがあります。PMが意思決定の枠組みを作り、QAがテスト観点を整備し、開発が根本修正を担う。この流れが整うと、WAF／CDNは“守り”ではなく安定稼働の武器になります。

まとめ

WAFとCDNは、導入すれば自動的に安全になるものではなく、境界を分けて段階的に強くすることで初めて効果が出ます。静的コンテンツはCDNのキャッシュ設計で軽く強くし、動的UIや重要経路はWAFで入口を締め、APIは認証・認可を守ったうえで、認証→制限→検知→遮断を重ねます。運用ではログ相関と変更管理が鍵です。PM・管理職・QAが役割分担して回すことで、止まりにくいWebを実現できます。