「WAFは導入済みです。だから大丈夫だと思っていたんですが……」

セキュリティ運用の現場でお客様とお話しすると、こういったケースに頻繁に出会います。WAF（Webアプリケーションファイアウォール）を入れた、それ自体は正しい判断です。でも今、「WAFを入れた＝Webを守れている」という認識が、静かにリスクになってきています。

今日は、WAFが守れない領域が実は増えていること、そしてその対策として何をすべきかをお伝えします。

なぜ「WAFを入れたのに攻撃される」のか

WAFはもともと、SQLインジェクションやクロスサイトスクリプティング（XSS）といった、Webアプリの古典的な攻撃手法を防ぐために作られたツールです。「既知の悪い通信パターン」をルールとして登録し、それに一致する通信をブロックする——という仕組みです。

でも今、攻撃者はそこを突いてきています。

WAFが対応しにくい攻撃の典型例：

  1. 正規のHTTPS通信に見せかけたAPI不正アクセス
  2. 人間に見せかけた高度なボット（自動化ツール）による不正ログイン
  3. ルールに登録されていない「未知の脆弱性」を狙うゼロデイ攻撃
  4. リクエストサイズを意図的に肥大化させ、WAFの検査範囲を超える攻撃

特に深刻なのが①と②です。現在、日本のWebへの攻撃のうち約23%がAPIを標的にしているというデータもあります。

スマホアプリや外部サービスとのデータ連携に使われるAPIは、WAFのルールでは守りにくい構造になっているんです。

WAFが「ルール型」である限り生じる限界

WAFの仕組みを少し噛み砕いて説明しましょう。

WAFは「悪いと判断されたパターン一覧（シグネチャ）」を持っていて、それに合致する通信をブロックします。

問題は、APIは企業ごとに独自の設計をしているため、「このAPIはどんな値が正常で、どんな値が攻撃なのか」をWAFが事前に知ることができない点です。

つまり、WAFは原理的にAPIの独自脆弱性を突く攻撃を防ぐことができません。

また、最近のボット攻撃も厄介です。
昔のボットはUser-Agent（ブラウザの種類を示す情報）を偽らなかったり、短時間に大量アクセスするためすぐ検知できました。

しかし今は、人間のブラウジング挙動を模倣し、IPアドレスを頻繁に変え、アクセス間隔もランダムにする「高度なボット」が増えています。
WAFのIPブロックやレート制限だけでは追いつかない状況です。

WAFの次のステップ「WAAP」とは何か

こうした課題を受けて、最近セキュリティ業界で注目されているのが「WAAP（ワープ）」という概念です。

WAAPは「Web Application and API Protection」の略で、WAFの機能に加えて、API保護・悪性ボット対策・DDoS防御（大量アクセスによる障害攻撃への防御）を統合したものです。

米国の調査会社ガートナーが提唱した、いわば「WAFの進化版」と考えると分かりやすいです。

従来のWAFとWAAPの比較

従来のWAF

  • 守れる範囲：SQLインジェクション、XSS、既知の攻撃パターン（シグネチャ一致）
  • 守りにくい範囲：APIの独自脆弱性、高度なボット攻撃、ゼロデイ攻撃

WAAP（次世代）

  • 追加された防御：API通信の振る舞い分析、悪性ボットの識別・ブロック、DDoS攻撃の自動軽減、機械学習による異常検知、未知の攻撃パターン対応

ただし、WAAPを導入すれば終わりかというと、そう単純でもありません。
ツールをどう設定し、アラートをどう運用し、インシデント発生時にどう動くか——ここに人の判断が必ず必要になります。

実運用で陥りやすい「入れっぱなし問題」

WAFを導入してから数年経つと、「誰もルールを触っていない」状態になりがちです。

攻撃手法は毎月進化しているのに、WAFのルールは初期設定のまま。
これが最も危険なパターンです。

特に注意が必要なのは「検知モード（ブロックせず記録だけする設定）」のまま放置されているケースです。

誤検知が怖くてブロックモードに切り替えられず、ログだけが貯まり続けて誰も見ていない、という状況は珍しくありません。
WAFが「お守り」になっていないか、定期的に確認することが重要です。

WAFをSOCと連携させることで何が変わるか

WAFを「入れて終わり」ではなく、継続的に価値を出す運用に変えるために有効なのが、SOC（セキュリティ監視センター）との連携です。

  1. ルールの継続チューニング
    WAFが誤検知を起こすポイントを特定し、正規ユーザーを誤ってブロックしないようルールを最適化します。
  2. WAFが見逃した攻撃の補足
    WAFをすり抜けた不審な通信をSIEM（ログの統合管理システム）で検知し、インシデントとして対応します。
  3. API・ボット攻撃の文脈分析
    単一リクエストではなく時系列パターンを見ることで、ボットによる低速スキャンや異常なAPIアクセスを検出します。
  4. インシデント発生時の初動対応
    WAFのブロックログをリアルタイム監視し、実際の侵害が始まった際に即時エスカレーション（担当者への報告・対応）を行います。

「WAFがあれば大丈夫」から「WAFを活かす運用体制がある」へ。
この転換が、今のセキュリティ運用には不可欠です。

まとめ：WAFは「起点」であって「ゴール」ではない

WAFを導入していること自体は、決して間違いではありません。
ただ、今の攻撃環境では「WAFだけでは守り切れない領域」が確実に存在します。
特にAPIやボット攻撃への対応は、WAF単体では構造的に難しいです。

大切なのは、WAFを「入れた安心感」のゴールにしないこと。
定期的なルール更新と検知モードの見直し、API・ボット攻撃への補完対策、SOCによる継続監視というこの3つが揃って初めて、現代のWebセキュリティは機能します。

「自社のWAFがどんな状態か正直わからない」「APIへの対策が後手に回っている気がする」という方は、まず現状確認から始めてみてください。
専門家に相談するのが最短ルートです。

Colorkrew Securityでは、WAF運用の現状診断からSOCによる継続監視まで一括でご支援しています。
お気軽にご相談ください