WAFと脆弱性診断の違い｜防御運用と弱点確認を分けて考える

WebサービスでWAFを利用していると、脆弱性診断も済んでいるように感じることがあります。一方で、診断を依頼する際にWAFの存在を伝えないと、対象となる公開経路や運用上の制約を共有できません。

結論から言うと、WAFは通信を保護する運用、脆弱性診断は合意した対象の弱点を確認する発注業務として整理します。導入済みの防御策と診断結果を同じ評価に混ぜず、目的、対象、成果物、担当者を分けて確認します。

発注前には、防御製品の有無を構成条件として共有し、診断対象となる画面・認証後の機能・API・外部連携を別途決めます。報告後は、修正と設定見直しの責任者を分けて、再確認の条件を整理します。

本記事で分かること

• WAFと脆弱性診断の目的の違い
• 発注前に共有する構成条件
• 認証後やAPIを含めた対象整理
• 報告後の修正・設定見直しの分担

結論：防御運用と弱点確認を別に設計する（早見表）

WAFは通信を保護する運用、脆弱性診断は合意した対象を確認する発注業務として整理します。WAFがあることを診断対象の除外理由にせず、現在の構成と確認したい範囲を対象表へ分けて記載します。

目的・対象・成果物を比べる

導入済みの防御策と診断結果を同じ評価に混ぜません。何を守るために運用するか、何を確認するために発注するかを分け、関係者が見る資料を整理します。

主な目的

WAFは、公開される通信を保護するために運用する仕組みです。脆弱性診断は、発注時に合意した対象で確認した内容を報告として受け取るための業務です。どちらもセキュリティに関わりますが、同じ目的・同じ成果物として扱うと、何を確認したかが曖昧になります。

WAFを導入している場合も、診断で確認したい画面や機能を対象表に整理します。診断の必要性を一般論で決めるのではなく、取引先への説明、変更後の確認、管理下の資産といった目的から判断します。防御製品の有無は、発注時に共有する構成情報の一つです。

確認対象

WAFの運用では、保護する公開経路、設定を管理する担当、変更時の連絡方法を整理します。脆弱性診断では、公開画面だけでなく、認証後の機能、API、外部連携を対象表に分けます。対象が重なる場合でも、運用上の対象と発注上の対象を同じ欄にしません。

Webアプリ診断の対象範囲を参照し、画面、利用者区分、認証後の機能、連携先を整理します。WAFが経路を保護していることと、どの機能を診断対象にするかは別の判断です。対象外にする範囲と理由も、発注仕様に残します。

残す成果物

WAFに関して残す情報は、運用の担当、構成上の前提、変更時の確認記録です。脆弱性診断で残す情報は、対象、対象外、確認時点、報告書、再確認の条件です。資料を同じ保存先に置く場合でも、目的と更新担当を区別します。

報告書を受け取った後は、WAFの設定があるという理由だけで指摘を完了扱いにしません。指摘の対象となった画面・機能・連携を確認し、修正を担う担当と設定を見直す担当を分けます。どの成果物に何を残すかを決めれば、後の確認がしやすくなります。

発注前に確認する構成

防御製品の有無を範囲条件として共有し、診断対象の除外を決めないことが大切です。公開経路、認証後の画面、API、外部連携を整理し、管理者と承諾範囲を確認します。

公開経路

公開経路を整理するときは、外部から利用される画面や入口を一覧にし、どの担当が管理しているかを確認します。WAFの有無や構成は、依頼先が実施条件を理解するための情報として共有します。防御製品があることだけで、公開経路を診断対象外にする理由にはしません。

対象となる経路に変更予定がある場合は、変更の内容、診断への影響を判断する担当、連絡方法を記録します。公開経路を一括にせず、管理者や利用目的が異なるものを分けることで、承諾範囲を確認しやすくなります。

認証後の画面

認証後の画面は、利用者区分と主な機能を対応付けて整理します。WAFの運用対象と、ログイン後に使われる機能の対象は同じとは限りません。テスト用アカウントを用意する場合は、必要な権限、利用できる範囲、提供方法を確認します。

対象外にする権限や機能がある場合は、理由を発注仕様に残します。管理者の承諾や業務上の制約を確認し、未確認の領域を対象に含めたように扱わないことが重要です。画面名だけでなく、どの利用者がどの操作をするかを整理します。

APIと外部連携

APIや外部連携は、アプリケーション本体と別の行で対象表に記載します。連携先の管理者、利用目的、自社が承諾を得られる範囲を確認し、対象に含めるかを判断します。外部サービスを利用しているだけの場合は、自社だけで確認対象に含めません。

セキュリティ診断の発注ガイドを参考に、対象、管理者、実施制約、成果物を同じ仕様表で整理します。WAFの構成情報、連携先、対象外の理由を共有すれば、依頼先からの質問にも条件ごとに答えやすくなります。

報告後に行うこと

指摘への対応と防御設定の見直しは、責任者を分けて管理します。修正が必要な機能、運用設定を見直す経路、再確認する対象を対応表にまとめます。

修正の担当

指摘を受けたら、対象となる画面、機能、API、連携先のどこを誰が修正するかを決めます。一つの指摘に複数の担当が関わる場合は、作業の窓口と完了を確認する担当を分けます。修正予定が別の変更に影響する場合は、対象表と変更管理の記録を更新します。

修正の優先順位は、対象となる業務機能、利用者、連携先を確認して決めます。技術的な説明と業務上の判断を分け、事業責任者と開発・運用の担当が同じ対象を見て判断できるようにします。報告書の文言だけを作業指示にせず、自社の管理方法に沿って整理します。

設定見直しの担当

WAFの設定見直しは、運用を担う担当と変更を承認する担当が管理します。診断の結果を受けて見直す場合も、どの公開経路、どの運用条件、どの変更記録に関係するかを確認します。設定を変更することと、アプリケーションを修正することを同じ担当に集めません。

設定見直しの結果は、運用の記録として残し、診断報告書の対象と対応付けます。変更が対象範囲に影響する場合は、再確認が必要かを発注担当と相談します。運用上の判断と発注上の判断を分けることで、どの対応が完了しているかを追いやすくなります。

再確認の条件

再確認では、どの指摘に関係する画面・機能・連携を確認するか、どの版と構成を対象にするかを決めます。修正と設定見直しのどちらが関係するかを整理し、追加の変更があれば当初の対象表との差分を記録します。結果を受け取る担当も決めます。

手動診断とツール診断の違いを参考に、確認方法の名称ではなく、再確認で何を確認するかを仕様にします。対象、条件、結果の受け方を事前にそろえれば、報告後の調整を進めやすくなります。

まとめ

WAFは防御運用、脆弱性診断は合意した対象の確認として分けます。防御製品の有無を構成条件として共有し、公開経路、認証後の機能、API、連携先を別の対象表で整理すると、報告後の修正・設定見直し・再確認を進めやすくなります。

Webサービスの対象整理は、Webアプリ診断の対象範囲と、お役立ち記事一覧から確認できます。