WAF強化概論
WAFは導入後から強くなる
WAFは、SQL Injection、Cross-Site Scripting、既知Exploit、Bot、過剰なRequestといったWeb攻撃をApplicationの手前で検知・制御する基礎防御である。Managed Ruleを有効にするだけでも広く知られた攻撃への防御面を短期間で作れるため、導入そのものに価値がある。
一方、初期設定のWAFが知っているのは、広いApplicationへ共通する攻撃Patternが中心である。自社Applicationに存在するURL、許可するMethod、Parameterの型、正規Client、操作順序、業務上の上限までは自動的に理解しない。共通Ruleを置いた状態は完成ではなく、WAF強化の出発点と捉えると設計しやすい。
WAFの効果は、Applicationに合わせたチューニングで高まる。本稿では、導入済みWAFを次の三段階で強化する。
- 攻撃面を絞る。Application固有の正常通信を定義し、Positive Securityを重ねる。
- チューニングを自動化する。Code、API契約、Traffic、Testの変化をAIで追い、持続可能な更新Loopを作る。
- 脆弱性を動的に検証する。公開情報と自社資産を照合し、許可された非本番環境で到達性と影響を確かめる。
この三段階はWAF製品の追加機能一覧ではない。Applicationの変更を境界Policyへ反映し、そのPolicyが意図どおり働くことをTestとEvidenceで確かめる運用モデルである。
本稿は2026年9月13日時点の公開一次資料に基づく時点記録である。製品機能、提供範囲、API、検査対象は変更されうるため、導入時にはリンク先の最新仕様を再確認する必要がある。
強化前にWAFの役割を整える
WAF強化では、まず共通攻撃を検知する基礎層を安定させる。Managed Rule、Rate Limit、IP・地域・ASNなどの条件、Bot対策、Loggingを、保護対象ごとのTrafficへ合わせて調整する。
初期導入からBlockまでを一度に進めるより、観測を挟む方が正常通信への影響を確かめやすい。AWS WAFはTest環境で調整した後、本番TrafficではCount modeで評価してからRule Actionを有効化する流れを案内している。Google Cloud ArmorはPreview modeのCanary Rulesetを高いPriorityに置き、安定RuleをEnforceする構成をBest Practiceとしている。Azure WAFもDetection modeで記録と調整を行い、その後Prevention modeへ進める。また、AzureはWAF設定をCLI、PowerShell、Bicep、TerraformなどでCode化することを推奨している。1234
共通Ruleのチューニングでは、次の単位を記録する。
| 管理単位 | 記録する内容 |
|---|---|
| 対象 | Host、Path、Method、Client、Traffic割合 |
| Rule | Managed Rule Set、個別Rule、優先順位、Action |
| 観測 | Match、Count、Block、Challenge、Latency、Application Error |
| 例外 | 対象条件、理由、Owner、期限、再評価条件 |
| 変更 | Policy Version、Diff、承認者、適用時刻、Rollback条件 |
例外は、正常通信を維持しながら防御を進めるための制御機構である。対象をPathやParameterへ限定し、Ownerと失効日を付けることで、例外を管理可能な構成要素にできる。
① 攻撃面を絞る：Application固有のPositive Security
第一の強化は、Applicationが受け付ける通信を定義することである。Negative Securityが攻撃らしいPatternを探すのに対し、Positive Securityは正常なRequestの範囲をPath、Method、Content-Type、Parameter、型、長さ、値域、認証条件などで表す。
例えば、注文APIがPOST /ordersとJSONだけを受け付け、商品数が1から20、通貨が定義済みCode、利用者が注文者Roleであるとする。この契約を入口へ反映すれば、存在しないPath、不要なMethod、想定外Content-Type、巨大Body、余分なParameterをApplicationへ届く前に減らせる。WAF強化の中心は、新しいSignatureを増やすことだけでなく、Applicationが公開する攻撃面そのものを狭く保つことにある。
正常通信をSecurity Contractへする
Application固有制約は、次のSourceから抽出する。
| Source | 得られる制約 | 扱い方 |
|---|---|---|
| OpenAPI、JSON Schema、GraphQL Schema | Path、Method、必須項目、型、形式 | 通信契約の中心に置く |
| Router、Controller、Validator | 実装が受理する条件 | 契約との差分をTestする |
| Authentication、Authorization Policy | 利用者、Role、Scope、Resource関係 | Schemaと別のPolicyとして管理する |
| Production Traffic | 実際のClient、値域、頻度 | 仕様の証明ではなく候補発見に使う |
| 業務Rule | 操作順序、金額、件数、副作用 | ApplicationまたはPolicy Engineで強制する |
OpenAPIだけで全ての正常通信を表せるわけではない。認可、在庫、残高、操作順序、重複実行、資源消費は、Schema外の業務PolicyとApplication Testで補う。Security Contractは一つの巨大仕様書ではなく、契約、Policy、IaC、Testを共通の変更IDで結んだ集合として扱う。
各クラウドでの実装例
主要Cloudでは、WAFとAPI Gatewayの機能を組み合わせることで、Positive Securityを段階的に実装できる。
| 環境 | 基礎WAFの観測と反映 | Application固有制約の実装例 | 設計上の要点 |
|---|---|---|---|
| AWS | AWS WAFをCountで評価し、Scope-down、Rule Action Override、Label、Custom Ruleを経てBlockへ進める | Amazon API GatewayのRequest Validatorで必須ParameterとJSON Schema Bodyを検証する | WAFはEdgeの共通防御、GatewayとApplicationは契約・認可を担当する |
| Google Cloud | Cloud ArmorのPreview Ruleと安定したEnforced Ruleを併用し、SensitivityやSignature除外を調整する | ApigeeのOASValidation PolicyでOpenAPI 3.0のPath、Verb、Parameter、必要に応じてJSON Bodyを検証する | Cloud Armorで広域の攻撃を絞り、ApigeeでAPI Operation単位の契約を強制する |
| Azure | Application GatewayまたはFront Door WAFをDetectionからPreventionへ進め、PolicyをIaCで管理する | API Managementのvalidate-parameters、validate-content、JWT検証PolicyをAPIまたはOperation単位で適用する | Front DoorからAPIMへの入口を限定し、EdgeとAPI Policyの二層で制約を表す |
| Cloudflare | Application Profilesで期待値との差を検知し、Custom RuleをMonitoringからMitigationへ進める | Operation、Path、Method、Schema上の期待値をProfileとCustom Ruleへ反映する | 最初のRuleを一つのOperationへ限定し、影響確認後に範囲を広げる |
AWS API GatewayのRequest Validationは、必須Parameterが存在し空でないことと、Request Bodyが設定したJSON Schemaへ合うことを確認できる。Parameterの型や形式までは同じ範囲で確認しないため、Application側のValidationを残す。5
ApigeeのOASValidation Policyは、OpenAPI 3.0に基づきPath、Verb、Parameter、条件付きのJSON Body検証を扱う。Azure API Managementのvalidate-contentはRequestまたはResponse BodyのSizeやContentをSchemaへ照合する。製品ごとの検査対象とActionを確認し、同じOpenAPIを使う場合も同一動作を前提にしない。67
Cloudflare Application Profilesは、Application固有の期待値から外れたRequestを分類し、Managed Rulesなど既存の検知を補完する。Profileの検知とMitigationを分離し、Custom Ruleによる制御はMonitoringから始める構成である。89
観測から遮断へ進める
Positive Securityは正常通信を厳密に扱うため、Application変更との同期が重要になる。安全な導入は次の順序で進める。
- Contractと実装の差分をTest環境で確認する。
- Log、Count、Detection、Previewなど非遮断Actionで本番Trafficとの差を観測する。
- Violationを仕様変更、未登録Client、攻撃、Parser差、Oversize、例外候補へ分類する。
- 対象を一つのHost、Path、Operation、Client群へ限定して遮断する。
- 正常系Regression Testと境界値Testを継続し、対象を広げる。
この段階導入により、Positive Securityは一括拒否の大Ruleではなく、Applicationの理解を増やしながら攻撃面を絞る運用になる。
② チューニングを持続可能にする：AI活用
第二の強化は、Application変更とWAF Policyの同期を継続できる形にすることである。手作業だけでPath、Parameter、Client、例外を追うと、ApplicationのRelease速度にPolicy更新が追いつきにくい。AIは、異なる形式のSourceを読み、制約候補と差分を作る部分で力を発揮する。
AIを本番WAFの直接管理者にするのではなく、提案・検査・Evidence作成を担うControl Planeに置く。生成結果は決定論的なCompiler、Static Check、Regression Test、観測、人間承認を通して反映する。
Application変更をPolicy変更へつなぐ
持続可能なLoopは次のように構成する。
- Pull RequestからRouter、Schema、Validator、Authorization、IaCの差分を収集する。
- AIが「新しいPath」「広がった型」「削除されたParameter」「変更されたClient条件」を説明付きで抽出する。
- Application Security Contractへ正規化し、Source位置とConfidenceを付ける。
- 決定論的な変換処理がCloud別のWAF、Gateway、Test候補を生成する。
- CIでSyntax、Policy上限、Contract Test、正常系・異常系Testを実行する。
- 本番相当環境でLogまたはCountへ適用し、既存Trafficとの差を観測する。
- 人間がDiff、影響、例外、Rollbackを確認して限定Blockを承認する。
AIへ向くのは、量が多く、元のEvidenceへ戻れる作業である。
| AI支援に向く作業 | 人間が決める事項 |
|---|---|
| Code、Schema、Trafficから制約候補を抽出する | どのSourceを正本として扱うか |
| ContractとWAF Policyの差分を説明する | 本番で許可する通信と業務上の例外 |
| Cloud別PolicyとTest Caseの草案を作る | 適用Scope、実行可否、停止判断 |
| Logを仕様変更、攻撃、誤検知候補へ分類する | Blockへの昇格、Rollback、Risk受容 |
| Policy VersionとTest結果をEvidenceへ束ねる | 最終判定、Owner、修正期限 |
AIの出力には、Source URLまたはFile、取得日時、該当位置、Confidence、矛盾、未確認範囲を付ける。根拠を追える形式にすると、Reviewerは生成文の自然さではなくPolicy変更の妥当性を評価できる。
Cloud別の自動化配置
Cloudが変わっても、AIの役割は同じである。AWSではAWS WAF・API Gateway・CloudFormationなどの差分候補、Google CloudではCloud Armor・Apigee Policy・Infrastructure as Codeの候補、AzureではWAF Policy・API Management Policy・BicepやTerraformの候補へ変換する。各CloudのAPIやPolicy構文は決定論的なGeneratorで扱い、AIはSource間の意味対応、説明、Test候補、例外候補を補助する。
図は、AWSで三つの強化をつなぐReference Architectureの一例である。Amazon EventBridgeで脆弱性情報を検証Flowへ渡し、CodeBuildなどのTest Runnerで限定Testを行い、複雑な経路だけをAWS Security Agentへ送る。WAFの本番反映はStaging検証と承認を通し、Finding、Request / Response、修正履歴をEvidenceとして保存する。図中の構成は設計例であり、実環境の構成や検証結果を示すものではない。
Policy更新には次のGuardrailを置く。
- AIが直接Production Credentialを保持しない。
- PlanまたはDiffと、元Evidenceを同時に出力する。
- 生成物をSchema、Linter、CloudのValidation APIで検査する。
- Log / Count / Previewを必須の中間状態にする。
- 変更Scope、承認者、Rollback条件、例外の失効日を記録する。
- Application Release後もViolationとPolicy Driftを再評価する。
この設計では、AI活用の成果を「生成したRule数」ではなく、Application変更からPolicy反映までのLead Time、期限内に解消したDrift、説明可能な例外、Regression Testの再現性で評価できる。
③ 脆弱性を動的に検証する
第三の強化は、WAF Policyが実際の攻撃条件へどう働くかを動的に確かめることである。公開Advisoryを集めるだけでは、自社Applicationへの該当性、外部からの到達性、既存Controlの効果までは決まらない。資産と条件を絞り、机上照合と許可された非本番検証を組み合わせる。
公開情報から検証対象を絞る
運用の入口には、CISA KEV、NVD、GitHub Global Security Advisories、Vendor Advisoryなどの公開一次情報を使う。GitHubのGlobal Security Advisories APIはCVE ID、Package、Version、Ecosystem、Severity、EPSSなどで絞り込める。NVDもCVE情報をAPIで提供し、CISA KEVは実悪用が確認された脆弱性を優先する入口になる。101112
公開情報は、SBOM、Package Manifest、Container Image、CMDB、Cloud Inventoryと照合する。収集件数よりも、Asset、Version、公開経路、Ownerへ結び付いた候補を増やす方が対応へ直結する。
Advisoryから次の成立条件を取り出す。
| 条件 | 確認する情報 |
|---|---|
| 対象 | 製品、Library、Module、Version、Feature Flag |
| 入口 | Host、Path、Method、Content-Type、Parameter |
| 前提 | 認証、Role、Session、事前操作、設定 |
| Payload特性 | 型、長さ、Encoding、Header、Body構造 |
| 成立結果 | Code Execution、Data Access、権限昇格、状態変更 |
次に、その条件を自社のRoute、WAF Rule、API Schema、Authentication、Authorization、Network Policyと照合する。机上照合の出力は遮断見込み、通過見込み、追加検証の三つに分ける。明確な対象外を除き、実挙動が必要な候補だけを動的検証へ送る。
許可された非本番環境で確かめる
動的検証は、認証後の操作、複数Step、業務Logic、Parser差、実WAF Engineの挙動を確認できる。Application Ownerが許可したStagingまたは専用Test環境へ、対象FindingとTest Caseを限定して実行する。
Google CloudのWeb Security Scanner文書は、ScannerがForm入力、Button操作、Link遷移を行い、DataやSystem状態を変える可能性を示している。事前に対象Applicationを監査し、Test Accountから機密Dataや危険な操作へ到達できない構成を求めている。13
AWS Security Agentも、Penetration Testには状態、Data、System設定を変える可能性があるToolが含まれるとして、Productionと分離し、機密Dataを持たず、本番に近いControlを備えた非本番環境を推奨している。Finding、生成されたVerification Script、Remediation Codeは人間がReviewし、Test環境で確認する。14
AzureではFront Door WAFとAPI Managementで入口と契約を作り、組織が承認したDASTまたはSecurity Test Runnerを隔離されたPre-productionへ接続する構成がとれる。AWS Security AgentやGoogle Web Security Scannerと同一のNative機能があると仮定せず、実行ToolよりもAuthorization、Isolation、Scope、Stop condition、Evidenceの共通要件を固定する。
| Guardrail | 実装する内容 |
|---|---|
| Authorization | Owner、対象FQDN・IP、期間、許可手法、責任者を記録する |
| Isolation | Production Data、Credential、外部通知、課金処理を分離する |
| Scope | 開始URL、除外URL、Rate、認証Role、対象Findingを限定する |
| Stop condition | Error率、状態変更、外部通知、負荷上昇で停止する |
| Review | AI生成Script、Payload、修正案を実行前に確認する |
| Evidence | 実行者、Tool Version、Request、Response、Log、時刻を保存する |
公開PoCはInput資料として隔離し、成立条件とProtocol上の要件を抽出する。実行用Testは、所有または明示的に許可された環境向けに再構成し、破壊的な副作用を除いたうえで承認する。
結果を五つの状態で記録する
動的検証は、防御境界と攻撃成立性を分けて判定する。
| 結果 | 確認できたこと | 次のAction |
|---|---|---|
| WAFで遮断 | 特定Requestが特定Policyで止まった | Payload差、別経路、Policy変更時のRegression Testへ登録する |
| Schemaで拒否 | 特定Schema Versionへの形式違反が拒否された | 認可、業務Logic、Schema内の悪用を別Testで確認する |
| Application到達・攻撃不成立 | 境界を通過したが期待した悪用結果を再現しなかった | Test条件をReviewし、攻撃不成立と判定不能を分ける |
| 攻撃成立 | 許可環境で悪用結果を再現した | Evidenceを保全し、Patchと暫定緩和を優先する |
| 判定不能 | 認証、状態、Tool限界などで結論が出なかった | 不足条件を記録し、追加検証のOwnerを決める |
WAF遮断は、そのRequestとPolicyに対する境界制御のEvidenceになる。Patchは脆弱な処理そのものを修正し、WAFは修正までの時間を稼ぎ、追加の防御面を残す。両者を同じFinding IDで追跡すると、暫定緩和と恒久対応を両立できる。
再検証できるEvidenceを残す
Evidenceは人向けの要約と原記録へ分ける。
assessment.json
├─ advisory_id / source / retrieved_at
├─ affected_asset / component / version / owner
├─ test_scope / authorization / environment
├─ control_versions / policy_diff
├─ test_case_id / request_hash
├─ result / confidence / limitations
├─ evidence_links
└─ remediation / retest_history
evidence/
├─ request-response/
├─ waf-and-application-logs/
├─ scanner-trace/
└─ screenshots/
AWS Security AgentのFindingは、Endpoint、Action Log、再現Step、Request / Response、条件、Verification Scriptへたどれる。修正後はFindingを選んでRevalidationを実行し、元Findingと再検証履歴のLinkを保てる。AIをReport生成器ではなく、再現可能なEvidence Loopへ配置する実装例である。1516
WAF強化を一つの運用へまとめる
三つの強化は、段階的に導入できる。
| 段階 | 到達状態 | 主な成果物 | 昇格条件 |
|---|---|---|---|
| 基礎 | 共通攻撃を観測・制御できる | WAF Policy、Log、Rule台帳 | 正常Trafficへの影響を説明できる |
| ① 攻撃面縮小 | Application固有の正常通信を境界で扱える | Security Contract、Schema、限定Rule | Operation単位のTestとRollbackがある |
| ② AI自動化 | Application変更とPolicy差分を継続処理できる | Policy Diff、Test、Evidence、承認履歴 | 生成根拠と変更責任を追跡できる |
| ③ 動的検証 | 脆弱性の到達性とControl効果を再現できる | Test Case、Request / Response、Finding | Authorizationと再検証履歴がある |
WAF強化のKPIは、遮断数だけでは測りにくい。Applicationの公開面に対するContract適用率、期限付き例外の解消率、Policy Driftの解消時間、変更後Regression Testの再現率、Findingの再検証完了率を組み合わせると、守備範囲と運用品質を評価しやすい。
WAFやSchemaによる遮断は、Patch適用までの補完統制としても役立つ。OWASPはVirtual Patchingを、既知脆弱性の悪用を途中で防ぎ報告するPolicy enforcement layerと定義し、Code修正とVirtual Patchを併用する考え方を示している。Positive Security型のVirtual Patchは選択的に適用できる一方、大規模で動的なSiteでは手作業の維持が課題になる。ここにContract同期とAI支援を組み合わせる意義がある。17
NIST SP 800-40 Rev.4は、Patch管理をPatchの特定、優先順位付け、取得、導入、導入確認からなる継続的な予防保守として扱う。動的検証の結果は、対応順と補完統制を判断するEvidenceへ使い、Patch、期限、構成変更時の再評価まで追跡する。18
まとめ
WAFは、導入した時点で共通攻撃への基礎防御を作り、Applicationに合わせて育てることで効果を高められる。第一にPositive Securityで公開するPath、Method、入力、Client、業務条件を絞る。第二にAIでCode、契約、Policy、Testの差分処理を支援し、人間承認付きの継続チューニングへする。第三に公開脆弱性情報を自社資産へ結び付け、許可された非本番環境でControlの効果と攻撃成立性を動的に確かめる。
この運用を支えるのは、特定のAI製品よりも、Application Security Contract、Policy Version、段階導入、Authorization、Evidence、再検証である。AWS、Google Cloud、Azure、Cloudflareでは実装部品が異なるが、「攻撃面を絞る」「変更に追随する」「実挙動で確かめる」というWAF強化の軸は共通している。