WAFの継続的強化と防御検証
文書番号：2609.00008
要旨
WAFの防御を維持するには、既知攻撃を検知する共通ルールと、アプリケーションが受け付ける正常通信の定義を組み合わせ、変更後の動作を確かめ続ける必要があるのだ。本稿では、コード・仕様・観測から得た制約を承認済みの通信契約へ整理し、製品別の設定候補へ変換し、試験と段階導入を経て適用する方法を示すのだ。さらに、公開された脆弱性情報を資産へ対応付け、到達性と攻撃成立を別々に検証し、修正後の再検証へ戻す運用を設計するのだ。
AIは根拠の関連付けと変更案の作成に用い、制約の決定、設定の強制、リスク受容は責任者の判断として残すのだ。WAFで一つの試験通信を遮断できたことと、脆弱性の解消、経路の不存在、業務の安全性は異なる結論なのだ。その違いを証跡と適用範囲で説明できることを、運用の到達点とするのだ。
対象読者はWeb/APIの開発・基盤・セキュリティ担当者なのだ。製品記述は2026年10月11日に確認した公開資料に基づき、構成、データモデル、試験指標は本稿の設計提案として示すのだ。実環境での性能測定や導入成功を報告する記事ではないのだ。
1 目的と範囲 ｜ 2 防御の分担 ｜ 3 正常通信の定義 ｜ 4 設定への変換 ｜ 5 変更と導入 ｜ 6 効果の測定 ｜ 7 脆弱性の検証 ｜ 8 AWSへの適用 ｜ 9 運用と残余リスク ｜ 10 導入手順
第1章 継続的なWAF強化の目的と範囲
1.1 導入済みの防御をアプリケーションへ合わせる
マネージドルールは、多くのアプリケーションへ共通する攻撃の特徴を検査する出発点になるのだ。一方、特定の業務で使うPath、Method、入力項目、許容値は、その業務の仕様から得る必要があるのだ。本稿では、既知の悪性通信を検知する方式をネガティブセキュリティ、許可する通信条件を定義する方式をポジティブセキュリティと呼ぶのだ。両者を重ねることで、既知攻撃への対応と不要な入力経路の縮小を別々に進められるのだ。入力の許可条件とサーバー側検証の原則はOWASPの資料を参照するのだ。1
例えば、注文APIがJSONの注文だけを受け付けるなら、存在しない操作や別形式の本文を入口で識別できるのだ。しかし、新しい配送項目を追加した際に入口の設定が古いままなら、正当な注文も止まるのだ。強化とは制約を増やすことだけではなく、許可する業務と防御設定の対応を維持することなのだ。
1.2 二つの改善サイクルを接続する
日常の変更では、コードや契約の差分から設定を更新するのだ。脆弱性の公表や診断結果を受けたときは、対象条件を確認し、試験によって防御や修正を確かめるのだ。前者を変更追随のサイクル、後者を脆弱性検証のサイクルとして設計するのだ。
| 起点 | 処理 | 残す成果物 | 次へ進む条件 |
|---|---|---|---|
| アプリケーション変更 | 制約抽出、差分判定、設定生成、回帰試験 | 契約版、設定差分、試験結果 | 根拠の矛盾が解消され、正常業務への影響を説明できる |
| 脆弱性情報・診断結果 | 資産照合、成立条件分析、限定試験 | 対象資産、試験条件、観測結果、判定根拠 | 修正・暫定緩和・追加調査の担当と期限が決まる |
両者は同じアプリケーション版、設定版、変更IDを参照するのだ。そうすれば、診断で見つかった問題を修正した後、どの試験と設定を更新すべきか追えるのだ。
1.3 製品比較・基礎調整との境界
本稿の中心は、正常通信の定義から変更・検証を回す設計なのだ。マネージドルールの評価順序、誤検知の調整、製品間の読み替えはクラウドWAFのルール設計とチューニング、調達と比較PoCはWAF・WAAPの選定条件で扱うのだ。これらの判断を終えた環境でも、契約と実装のずれ、例外の陳腐化、新たな脆弱性への対応は継続課題として残るのだ。
第2章 通信経路と防御の分担
2.1 入口から業務処理までを分けて考える
架空の注文サービスを考えるのだ。利用者は商品と数量を送信し、アプリケーションは利用者の権限、在庫、決済条件を確認して注文を確定するのだ。同じ要求でも、通信の形と業務上の正当性を判断する場所は異なるのだ。
利用者 → WAF → API Gateway／入力検証 → 認証・認可 → 注文処理
│ │ │ │
既知攻撃 Path・型・長さ 所有者・権限 在庫・金額・順序
└────────────── 証跡の相関 ──────────────────┘
この図は役割を分けた論理構成なのだ。実装ではGatewayとアプリケーションが同じ処理基盤に置かれる場合もあるのだ。WAFを通らない別経路、旧ホスト名、管理用入口が存在すれば、その経路についても同じ保護条件を確認する必要があるのだ。
2.2 WAFへ移す制約とアプリケーションへ残す判断
| 判断対象 | 入口で扱う制約の例 | アプリケーションで確認すること |
|---|---|---|
| 通信形状 | Path、Method、Content-Type、本文サイズ | 実際に受理する操作と解析結果 |
| 入力項目 | 必須、型、長さ、値域、列挙値 | 同じ制約の再検証と入力の意味 |
| 主体と権限 | 利用可能な認証連携や入口制限 | 対象データの所有者、Role、Tenant境界 |
| 業務状態 | 入口で表現可能な粗い回数制限 | 在庫、残高、操作順、二重実行 |
形式が正しい注文でも、他人の支払情報を指定した要求は拒否しなければならないのだ。対象データへの認可や業務状態を必要とする判断は、入力形式だけからは決まらないのだ。OWASP API Security Top 10も、オブジェクト単位の認可、資源消費、重要な業務フローへのアクセスを別の問題として扱っているのだ。2
WAFへ入力制約を同期した後も、アプリケーションの検証を維持するのだ。別経路、解析差、検査上限、設定反映中の版の違いがあるため、入口の判定だけをアプリケーションの安全性の根拠にしないのだ。
2.3 HTTP上の位置と画面の項目を対応付ける
画面に入力欄があることだけでは、WAFがどこを検査すればよいか決まらないのだ。フォームやJavaScriptの送信処理を調べ、HTTP上の格納位置を確定するのだ。
| 送信方法 | 値の位置 | 契約へ記録する情報 |
|---|---|---|
| GETフォーム | Query | パラメーター名、重複時の扱い、復号条件 |
| JSON送信 | Bodyの構造化項目 | Content-Type、項目の位置、型、配列・ネスト |
| URLエンコードしたPOST | Bodyの文字列 | 文字コード、区切り、復号回数 |
| ファイル添付 | multipartの各part | ファイル名、メタデータ、本文、全体サイズ |
| Pathパラメーター | URLの一部 | 固定部分、変数部分、正規化条件 |
同名のQuery値が複数ある場合や、本文のContent-Typeと実体が異なる場合は、WAFとアプリケーションが同じ値を評価するかを試験するのだ。AWS WAFの検査対象もHTTPの構成要素ごとに指定する方式なのだ。3
第3章 正常通信の定義と根拠の照合
3.1 「最大30文字」を一つの仕様へそろえる
架空の会員登録機能で、POST /customer/registerがURLエンコード形式を受け付け、customer_nameを必須・最大30文字、countryをJP、US、GBのいずれかとする例を考えるのだ。画面、サーバー、保存先が同じ制約を持つかを先に確認するのだ。
| 情報源 | 確認する内容 | 単独で決められないこと |
|---|---|---|
| HTMLのmaxlength | 利用画面が案内する上限 | サーバーが受理する全クライアントの仕様 |
| サーバーのValidator | 実装が拒否する条件 | その条件が承認済みの業務要件か |
| 境界値テスト | 30文字を受理し31文字を拒否する期待 | 未試験の文字種や別経路の挙動 |
| DBの列定義 | 保存可能な範囲 | 通信契約上の文字単位と同じか |
| OpenAPI・承認済み仕様 | 外部へ約束する入力条件 | 稼働中の実装が一致しているか |
画面だけが30文字で、サーバーが100文字を受理するなら、AIに一方を選ばせず不一致として扱うのだ。担当者が業務要件を確認して契約を決め、コードと試験をそろえてからWAFへ反映するのだ。日本語や絵文字を含む場合は、文字数、コードポイント数、バイト数、正規化の違いも試験条件に含めるのだ。WAFのサイズ条件をそのまま業務上の文字数制約へ読み替えないのだ。
3.2 観測通信から仕様を推定するときの限界
実通信は未登録の経路やクライアントを発見する材料になるのだ。しかし、観測期間中に月次処理が使われなかった場合、その処理を不要と判断する根拠にはならないのだ。最大100文字の仕様でも、観測値が10文字以下に偏れば、学習値だけでは上限を復元できないのだ。
観測で見つかった差は、正規機能、廃止予定の機能、攻撃、解析差、情報不足へ分類するのだ。契約へ追加する際は、利用目的と所有者を確かめるのだ。Cloudflareの学習型Schema Profileにも、必須項目の存在を強制しない、新しい項目だけでは違反にならないなどの制約があるのだ。観測から作るプロファイルと、承認した仕様による完全な許可条件を区別する必要があるのだ。4
3.3 承認済みの通信契約を中間表現にする
コードとWAF設定の間に、通信条件と根拠を保持するApplication Security Contractを置く設計を提案するのだ。これは特定製品の標準形式ではなく、設定生成とレビューのための自作データモデルなのだ。次は架空の注文APIの例なのだ。
contractVersion: orders-12
endpoint:
method: POST
path: /orders
queryParameters:
campaign:
type: string
pattern: "^[A-Z0-9]{8}$"
requestBody:
contentType: application/json
fields:
productId:
type: integer
required: true
quantity:
type: integer
minimum: 1
maximum: 99
required: true
deliveryType:
type: string
enum: [normal, express]
evidence:
route: src/routes/order.ts
validator: src/schema/order.ts
test: tests/order.test.ts
evidenceTier: high
実装時には、根拠のコミット、該当位置、承認者、入力位置、JSON Pointer、上限超過と解析失敗の扱いも加えるのだ。認可や業務状態は通信契約の値制約へ押し込まず、対応する認可ポリシーやテストを変更IDで結ぶのだ。
3.4 AIの役割と処理を止める条件
静的に抽出できるRoute、Schema、Validatorは通常のプログラムで取得し、AIには画面・送信処理・サーバーの関連付けや矛盾の説明を担わせるのだ。毎回リポジトリ全体を入力するより、変更されたEndpointと依存する仕様・試験を選ぶ設計にするのだ。
| 根拠の状態 | 判断例 | 処理 |
|---|---|---|
| 一致 | 承認仕様、Validator、境界値試験が一致 | 設定候補を生成し、非遮断試験へ進む |
| 不足 | Validatorはあるが試験がない | 不足を記録し、試験を追加する |
| 推定 | 画面や観測値だけから推論 | 調査候補として提示する |
| 矛盾 | 契約と実装の上限が異なる | 設定の自動昇格を停止する |
この区分は正解確率ではないのだ。未校正の0.90などの数値を遮断判断の根拠にせず、何が一致し、何が不足しているかを示すのだ。AIのモデルや指示を変えた際は、既知の一致・不足・矛盾を含む固定例で回帰試験するのだ。
第4章 通信契約から製品別設定への変換
4.1 設定を生成できることと意味を保存できること
承認した契約を決定論的な変換処理へ渡し、同じ入力から同じ設定候補を作るのだ。ただし、出力が毎回同じでも、製品が契約の意味を表現できなければ防御は一致しないのだ。変換器は制約ごとに次の状態を返す設計にするのだ。
| 変換結果 | 例 | 適用判断 |
|---|---|---|
| 表現可能 | 固定PathとMethodの組合せ | 対応する試験を通して候補へ含める |
| 部分的に表現可能 | 検査範囲が本文の一部に限られる | 未検査範囲と補完制御を明示する |
| アプリケーション専用 | 在庫や所有者を参照する判断 | WAF生成から外し、アプリ側試験へ対応付ける |
サイズ制約を作れたことだけで文字列長の契約を実装済みとしないのだ。表現損失がある場合は自動Block候補から外し、別の制御や契約の見直しを担当者へ返すのだ。
4.2 AWS WAFの検査要素への対応
AWS WAFでは、UriPath、Method、SingleQueryArgument、JsonBodyなどを検査要素として選ぶのだ。JSONの要素抽出は完全なJSON Schema検証とは異なり、形式不正時の処理や検査できる範囲も設定に関係するのだ。3
| 契約 | 変換候補 | 確認する試験 |
|---|---|---|
| 固定Path・変数Path | UriPathと文字列・正規表現条件 | URLエンコード、末尾区切り、大小文字 |
| Method | MethodとPath条件の組合せ | 正規操作と未定義操作 |
| Queryの値 | SingleQueryArgumentなど | 欠落、空値、同名値の重複 |
| JSONの項目 | JsonBodyの対象位置と一致条件 | 欠落、型違い、ネスト、不正JSON |
| Form・multipart | Bodyを使う限定的な条件 | 復号、boundary、添付、検査上限 |
AWS WAFが同名Queryの複数値を評価する方法と、アプリケーションが採用する値を照合するのだ。個別値を選べることを、要求全体の契約検証が完了したことと取り違えないのだ。
4.3 本文上限と解析失敗を制約に含める
AWS WAFのBody検査は、ALBとAppSyncでは先頭8 KB、CloudFrontなど対応する統合先では既定16 KBから最大64 KBという上限があるのだ。上限を超える部分まで検査済みとは扱えないのだ。超過時のContinue、Match、No matchはルール評価の扱いであり、最終的な許可・拒否はルールのActionと評価順に依存するのだ。5
例えば、通常の注文JSONは小さくても、添付機能では上限を超える場合があるのだ。全Bodyを同じ制約で拒否すると添付業務を壊し、すべて継続検査へすると後半の未検査範囲が残るのだ。Endpointを分け、アプリケーション側のサイズ制限、ファイル形式検査、保存後の処理と組み合わせるのだ。正常な添付と、上限前後で条件を変えた試験を別々に用意するのだ。
4.4 他環境へ適用するときの読み替え
| 環境 | 設定・検証の単位 | 同じ契約を使う際の注意 |
|---|---|---|
| Google Cloud | Cloud ArmorのCEL条件、ApigeeのOASValidation | WAF条件とAPI契約検証を分け、実際の解析条件を確認する |
| Azure | WAF Policy、API Managementの検証ポリシー | Front DoorとApplication Gatewayを区別し、APIMの適用Operationを確定する |
| Cloudflare | Schema Profile、Custom Rule | 学習型とアップロードしたSchemaを区別し、検知と制御を対応付ける |
| AWS | WAF Statement、API Gateway REST APIのRequest Validator | WAFの一致条件とGatewayのSchema検証を区別する |
Cloud Armorの式にはrequest.bodyやrequest.paramsを扱う属性があるのだ。ApigeeはOpenAPIに基づく検証、Azure API Managementはvalidate-contentなどによる検証を提供するのだ。AWS API Gateway REST APIでは、必須パラメーターの存在・非空とBodyのSchema検証が対象になり、パラメーターの型・形式を同じ仕組みで検証するわけではないのだ。各機能の対応形式と適用条件はそれぞれの資料で確認するのだ。6789
AkamaiのAPI DefinitionsやThales WAF Gatewayのプロファイルへ展開する場合も、同じ変換表を作るのだ。本稿ではその製品別の変換仕様を確定せず、製品選定記事を起点に、対象契約・版の公開仕様と試験で実装可能性を確認する対象として扱うのだ。
第5章 アプリケーションとWAFの変更管理
5.1 変更種別から更新順序を決める
正常通信の集合が広がる変更と狭まる変更では、更新順序が変わるのだ。次表は、契約を満たすアプリケーション版へ移行する際の基本方針なのだ。旧クライアントの互換性や緊急遮断など、別の要求がある場合は個別に決めるのだ。
| 変更 | 基本となる順序 | 逆順にした場合の問題 |
|---|---|---|
| Path追加 | WAFの許可条件を先に追加し、アプリを公開 | 新しい正常機能が入口で止まる |
| Path削除 | アプリの提供を終了し、WAFの許可条件を削除 | まだ提供中の機能が入口で止まる |
| 制約緩和 | WAFを緩和し、アプリを更新 | 新しい正常値が拒否される |
| 制約強化 | アプリの制約を更新し、WAFを強化 | 旧仕様に従う要求が入口で拒否される |
例えば数量上限を99から120へ広げる場合、先にWAFの候補を検証して反映し、その後アプリを更新するのだ。緩和の中間期間ではアプリの旧上限が最後の検証になるのだ。WAFを先に強くすることだけが安全側とは限らず、途中の状態でも業務と防御が成立するかを確認するのだ。
5.2 非遮断の観測から限定的な強制へ進む
候補は構文検査、変換上限、境界値・正常系試験を通し、本番相当環境で評価するのだ。その後、本番ではCount、Log、Previewなどの非遮断状態で差を観測し、仕様変更、誤検知、攻撃、解析差へ分類するのだ。AWSも試験環境で調整した後、本番通信をCountで評価する流れを案内しているのだ。10
| 段階 | 判断材料 | 進めない条件 |
|---|---|---|
| 生成 | 契約差分、根拠、表現可能性 | 根拠の矛盾、未定義の解析失敗動作 |
| 試験 | 正常系・境界値・異常系の結果 | 正常業務の失敗、試験と契約の不一致 |
| 観測 | 実通信の違反理由と業務照合 | 未説明の違反、ログ不足 |
| 限定遮断 | 対象Endpoint、承認、復旧条件 | 担当不在、復旧不能 |
| 拡大 | 重要業務の成功率、問い合わせ、例外 | 想定外の影響、設定と稼働版のずれ |
遮断対象は製品で実現できるHost、Path、Operation、クライアント群などへ限定するのだ。未確認の機能をまとめて強制対象に含めず、利用サイクルに沿って観測範囲を広げるのだ。
5.3 復旧時にも契約の組合せを確認する
WAFだけを旧版へ戻すと、新版アプリが必要とする通信を拒否する場合があるのだ。アプリ、契約、WAFの対応版を一組で記録し、どの組合せへ戻せるかを事前に確認するのだ。Blue/Green構成や旧クライアントが併存する期間は、両方の正常通信を試験するのだ。
AWS WAFでは設定変更の伝播中に旧設定と新設定が混在する場合があるのだ。変更APIの成功だけで全経路の反映完了とせず、適用対象の挙動とログを確認するのだ。10
第6章 正常業務への影響と防御効果の測定
6.1 正常通信と攻撃通信を別の母集団として用意する
正常通信はログイン、登録、検索、注文、外部連携、添付などの業務から作るのだ。境界値だけでなく、低頻度の正規操作、長い署名値、日本語、非ブラウザーのクライアントも含めるのだ。攻撃通信は検証対象の条件に対応付け、同じ設定版で評価するのだ。
正常系が通ったことは業務継続の証拠になり、攻撃系が止まったことは対象試験に対する防御の証拠になるのだ。例外を追加した後は両者を再実行するのだ。良性母集団、既知誤検知、変異生成、現行設定と候補設定の比較はWAF誤検知検証ツール設計で詳しく扱うのだ。
6.2 送信結果と防御の判定を分ける
HTTP 403が返っても、WAFが返したのか、Gatewayやアプリケーションが拒否したのかは応答だけで決まらないのだ。試験ID、時刻、要求の特徴、WAFログ、Origin側ログを対応付けるのだ。タイムアウトやTLS失敗は遮断成功へ数えず、送信・観測の問題として分離するのだ。
試験用IDが途中で保持されることと、各ログで検索できることを最初に確認するのだ。ログのサンプリング、時刻差、保持期間、記録対象外の経路がある場合は、その範囲を結果へ添えるのだ。Originログに記録がないという一条件だけで非到達を結論にしないのだ。
6.3 Origin到達削減を測る独自指標
同一の凍結した攻撃試験集合について、WAF導入前後のOrigin到達数を比べる指標としてOASR（Origin Attack-Request Suppression Ratio）を定義するのだ。これは本稿のPoC用指標であり、業界標準や製品の保証値ではないのだ。
OASR = 1 - 導入後にOrigin到達を確認した件数
/ 基準状態でOrigin到達を確認した件数
比較には、基準状態で到達を確認した同一の試験ID集合を使い、アプリ版、送信条件、観測条件をそろえるのだ。分母が0なら算出せず、送信失敗やログ欠落で判定できないケースがあれば、完全な比較ができた組だけの値と除外数を明示するのだ。判定不能を到達数0へ置き換えないのだ。
架空の計算例として、基準状態で10万件が到達し、導入後は同じ集合の2万件が到達したなら80%なのだ。これは試験集合における到達要求数の削減であり、リスクや脆弱性が80%減ったという意味ではないのだ。未定義Pathを大量に含む集合では、そのPathを閉じるだけで高い値になるのだ。
Path制限のみ、入力制約追加後、Body制約追加後を段階比較すると、どの制御が結果を変えたかを調べられるのだ。ただし、その比較でも契約内の認可不備や業務悪用は別の試験として残るのだ。
6.4 運用の成果と測定できない範囲
| 観点 | 確認する値・状態 | 解釈上の条件 |
|---|---|---|
| 業務継続 | 主要操作の成功、誤遮断、復旧時間 | 試験だけでなく実際の業務利用と照合する |
| 防御 | 試験ごとの遮断層、到達、攻撃成立 | 試験集合と設定版へ結び付ける |
| 同期 | 変更から反映までの時間、未解消の差分 | 変更規模と未処理理由を含める |
| 保守 | 例外の期限、所有者、再評価結果 | 例外数の少なさだけを目標にしない |
AIの効果は生成ルール数ではなく、同じ品質条件で差分調査や設定維持を行えるかで評価するのだ。本稿では時間短縮や誤検知削減を実測していないため、これらは導入後に測る評価項目なのだ。
第7章 脆弱性の該当性・到達性・攻撃成立の検証
7.1 公開情報を自社資産の条件へ対応付ける
脆弱性の公表を受けたら、まず製品、Component、版、設定、認証前提、入力位置、成立結果を整理するのだ。製品のAdvisoryを軸に、SBOM、Package Manifest、配備イメージ、公開経路、担当者を照合するのだ。脆弱性データベースに名称があることだけで、自社の稼働状態を確定しないのだ。
CISA KEVは実悪用の情報を優先順位へ取り込む材料、EPSSは悪用可能性の予測情報として使うのだ。いずれも個別システムでの到達性や攻撃成立の証拠とは分けるのだ。1112
| 照合する条件 | 確認する対象 | 不足時の扱い |
|---|---|---|
| Component・版 | 配備物、依存関係、提供者資料 | 対象外とせず調査を残す |
| 設定・機能 | 有効機能、構成、Feature Flag | 稼働構成を取得する |
| 外部入力 | Host、Path、Method、認証条件 | 経路と権限を特定する |
| 処理への経路 | 入力から対象コードまでの流れ | 静的分析と限定試験を組み合わせる |
| 成立結果 | データ取得、権限変更、処理実行など | 応答コードだけで判定しない |
図は脆弱性候補を絞り、証跡から内部評価へ進む設計例なのだ。図中の状態は7.4節の判定条件と合わせて読み、試験の応答だけから決めないのだ。
7.2 許可した検証環境で試験条件を固定する
動的検証は、所有・管理権限と実行許可を確認したStagingまたは専用環境で行うのだ。対象URL、期間、利用アカウント、許可手法、上限負荷、停止条件を決め、本番データ、資格情報、通知、決済への接続を分離するのだ。AWS Security Agentの安全上の指針も、非本番環境の利用と生成物のレビューを扱っているのだ。13
公開PoCは、まず成立条件を読む資料として扱うのだ。検証用には非破壊の確認方法、提供者が公開する手順、承認済みの試験集合を優先し、実行内容と副作用を確認するのだ。認証後の操作や複数段階の処理では、試験前の状態を保存し、終了後の状態と復旧も確認するのだ。
7.3 試験で観測した結果を記録する
| 試験結果 | 観測したこと | 追加で調べること |
|---|---|---|
| WAFで遮断 | 対象要求を特定ルールが拒否 | 別表現、別経路、設定更新後の挙動 |
| Gateway・Schemaで拒否 | 契約違反を入口が拒否 | 契約内の要求と認可の試験 |
| アプリへ到達・攻撃不成立 | 入力が到達したが期待した悪用を再現できない | 入力条件、認証、状態、試験の妥当性 |
| 攻撃成立 | 許可環境で対象の悪用結果を再現 | 影響範囲、修正、暫定緩和 |
| 判定不能 | 実行失敗や証跡不足 | 不足条件と再試験の担当 |
この表は一回の試験の観測結果なのだ。例えばWAF遮断は、対象の要求が止まったという結果であり、脆弱なComponentが存在しないという判定ではないのだ。
7.4 証拠から脆弱性の状態を判断する
次の状態は、観測結果だけでなく資産・構成・コードの証拠を合わせた内部評価として定義するのだ。製品の検出状態と同じフィールドへ混在させないのだ。
| 内部状態 | 必要な根拠 | 残る対応 |
|---|---|---|
| NOT_APPLICABLE | 対象Component・版・設定に該当しない確認 | 資産や構成変更時に再評価 |
| NOT_REACHABLE | 定義した入力範囲から対象処理への経路がない確認 | 対象範囲、コード版、解析限界を保持 |
| MITIGATED | 経路はあるが、対象Vectorを補完制御で遮断した確認 | 恒久修正と別Vectorの確認 |
| REACHABLE | 成立条件を持つ入力が対象処理へ到達する確認 | 攻撃成立の評価と修正 |
| UNKNOWN | 該当性・経路・試験の証拠が不足 | 不足解消の担当と期限を設定 |
例えばWAFで遮断し、WAFを外した検証経路では対象処理への到達を確認した場合、対象VectorについてMITIGATEDと判断できるのだ。認証に失敗して試験が進まなかった場合はUNKNOWNなのだ。外部試験が不発だっただけではNOT_REACHABLEにせず、コード上の経路や設定の根拠まで確認するのだ。
7.5 修正と再検証を一つの証跡へ結ぶ
評価記録
├─ Advisoryの識別子・URL・取得日
├─ 資産・Component・版・設定・担当者
├─ 試験許可・環境・入力・期待結果
├─ アプリ版・契約版・WAF版
├─ 送信結果・WAFログ・Originログ・業務結果
├─ 試験の観測結果・内部評価・未確認範囲
└─ 暫定対策・修正・再試験・承認
暫定WAFルールと本体修正は同じ問題IDで追跡するのだ。修正後は元の試験だけでなく、正常業務と関連する境界条件も再実行するのだ。期限付きの緩和策は、修正確認後に解除可否を判断し、残す場合は理由を更新するのだ。
第8章 AWSで二つのサイクルを構成する
8.1 既成サービスと自作処理を分担する
次表はAWSへ適用する設計例なのだ。AWSサービスを組み合わせるだけで全処理が完成するわけではなく、契約形式、変換器、資産照合、判定処理は自作部分として扱うのだ。
| 構成要素 | 役割 | 位置づけ |
|---|---|---|
| 既存CI/CD Runner | 差分取得、試験、承認後の配備 | 既存基盤 |
| Static Extractor | Route、Schema、Validatorの抽出 | 自作 |
| Amazon Bedrock | 曖昧な関連付け、不一致の説明 | AIサービス |
| 通信契約・WAF Compiler | 根拠の保存、表現可能性判定、設定生成 | 自作 |
| AWS WAF・API Gateway | 入口の検査と制約の適用 | AWSサービス |
| Vulnerability Collector | Advisoryと資産の照合、試験候補の整理 | 自作 |
| AWS Security Agent | コードレビュー、ペネトレーションテスト、既存指摘の再検証 | AWS Continuumの一部 |
図のBuilderとValidatorは論理的な分担なのだ。設定を作る側と、その設定下で対象処理を確かめる側を分けることで、同じ生成結果だけを正しさの根拠にする状態を避けるのだ。
8.2 PRごとの変更追随
CI/CDは変更されたRoute、Validator、DTO、OpenAPI、テストを抽出し、機械的に得られた制約を先に確定するのだ。Bedrockへは関連付けが必要な部分を渡し、対応するモデル・APIでStructured Outputsを使う場合も、構造への適合と意味の正しさを別々に検査するのだ。14
生成結果はGit上の差分にし、変換器がAWS WAF設定とIaCを出力するのだ。構文、表現損失、WCU、境界値、正常系の確認を行い、人が契約差分と更新順序を承認するのだ。WCUはCheckCapacityなどで確認するのだ。15
推論を行う権限と本番WAFを変更する権限を分離するのだ。AI処理へ本番更新の資格情報を渡さず、承認済み成果物を配備する別のRoleへ更新を限定する設計にするのだ。入力を変更箇所へ絞り、モデル・指示・契約形式の版と処理時間を記録して、費用と品質の変化を評価するのだ。
8.3 Stagingでの脆弱性検証
Stagingの配備後、Advisoryの追加時、定期実行時に、深い動的検証を別ジョブで行うのだ。AWS Security Agentには対象、認証、セキュリティ要件を設定し、自作の資産照合や試験台帳と結果を対応付けるのだ。公式資料はAgent Space、コードレビュー、ペネトレーションテストなどの役割を説明しているのだ。16
AWS Security AgentのFinding Revalidationは、選択した既存指摘の検証手順を再実行する機能なのだ。任意のCVEを入力する汎用判定器として扱わず、新たな探索と既存指摘の再検証を分けるのだ。製品のActive／Resolvedという結果はその試験における再現状態として保存し、本稿の到達性評価へ機械的に置き換えないのだ。17
図は全体をAWSサービスへ配置する一例なのだ。EventBridgeなどで検証の契機を渡し、CodeBuildなどのRunnerで試験し、指摘と修正結果を保存する構成を想定するのだ。採用するサービスや接続方法は自社のCI/CDに合わせて実装・検証するのだ。
8.4 実行時間と更新経路を分ける
Fast Loopでは変更差分と既知の回帰試験を扱い、Slow Loopでは複数段階の攻撃検証や新たな脆弱性の評価を扱うのだ。これらは運用上の区分であり、処理時間の保証ではないのだ。Slow Loopで重大な問題を確認した場合は、通常の更新頻度にかかわらず公開停止や修正判断へ渡すのだ。
Bedrockの代わりに別の解析器を使っても、根拠、契約、変換、試験、承認という境界を保つのだ。Google CloudやAzureへ適用する場合も、クラウド名だけを置換せず、生成先の設定構文、上限、ログ、動的試験の実行手段を選び直すのだ。
第9章 責任・例外・残余リスクの管理
9.1 変更責任と防御の判断を明確にする
| 担当 | 決める事項 | 残す証拠 |
|---|---|---|
| アプリ担当 | 正常仕様、認可、業務影響 | 契約、実装、正常系・境界値試験 |
| WAF・基盤担当 | 設定の実現方法、対象、配備・復旧 | 設定版、差分、ログ、復旧確認 |
| セキュリティ担当 | 攻撃条件、検証範囲、暫定緩和 | 試験条件、観測結果、内部評価 |
| 承認責任者 | 公開継続、例外、未解消リスク | 判断理由、期限、再評価条件 |
同じ人が複数の役割を担う場合も、仕様の決定と設定変更と結果確認を記録上区別するのだ。AIの提案を承認した事実だけでは業務上の妥当性を説明できず、元の仕様と試験結果へ戻れる必要があるのだ。
9.2 例外と未確認事項を期限付きで管理する
例外には対象Host・Path・入力項目、影響するルール、理由、所有者、期限、代替制御、再試験条件を記録するのだ。例えば添付だけをサイズ制約の対象外にする場合、ファイル処理側の制限と試験を対応付けるのだ。例外を追加した担当者が離れても、何を守るために残しているか判断できる状態にするのだ。
ログ欠落、表現できない制約、未使用の正規機能は、未確認事項として管理するのだ。未確認を許可済みや安全へ変換せず、担当と期限を決め、必要なら強制範囲を縮小するのだ。
9.3 残るリスクから次の対策を選ぶ
ポジティブセキュリティを強化しても、正規権限の悪用、契約内の業務濫用、WAFを通らない経路、未検査部分は残り得るのだ。残った条件を、認可の修正、業務制御、経路閉鎖、別の検査、利用範囲の見直しへ対応付けるのだ。
Botによる買い占めや無料枠濫用は、通信形状が正しくても問題になるのだ。必要性の判断は高度なBot対策の条件と接続するのだ。WAFの制約を増やすことだけで、すべての残余リスクへ対応しようとしないのだ。
第10章 段階導入と継続的な再評価
10.1 一つのAPIで証跡の連鎖を作る
最初はRouteが限定されたStagingのAPIを選ぶのだ。通信契約を手動でも確認できる規模にし、ログと試験を先に整えるのだ。次の段階ごとに成果物を確認してから対象を広げるのだ。
| 段階 | 作業 | 完了を判断する材料 |
|---|---|---|
| 把握 | 公開経路、正常操作、担当者の特定 | 対象一覧、正常要求、仕様 |
| 観測 | 試験IDと各層のログを照合 | 送信・拒否・到達の対応 |
| 契約化 | コード・仕様・試験の照合 | 一致点、不足、矛盾の記録 |
| 生成 | 表現可能な制約を設定へ変換 | 変換表、設定差分、生成物の版 |
| 試験 | 正常系と攻撃系を同条件で比較 | 期待結果、実結果、判定不能 |
| 導入 | 非遮断、限定遮断、復旧確認 | 承認、適用範囲、戻せる組合せ |
| 再評価 | 変更・脆弱性・例外期限への対応 | 修正、再試験、残余リスク判断 |
10.2 実務記録と設計の確認課題
変更票は「何を変えたか」だけでなく、「許可する通信がどう変わるか」を記述するのだ。契約の変更種別、根拠、対応する設定、表現できない部分、試験結果、承認、復旧先を一つの変更IDで追えるようにするのだ。
導入前には、数量上限を広げる変更、必須項目を追加する変更、添付上限を超える正常要求、認証失敗で実行できない脆弱性試験を使って、判断が適切に分岐するか確かめるのだ。単に処理が成功する試験だけでなく、矛盾があれば停止し、証拠不足なら判定不能になることも確認するのだ。
10.3 結論：仕様・設定・証拠を同じ変更として扱う
継続的なWAF強化は、正常通信の理解を設定へ変換し、その意味と業務影響を試験し、稼働状態を観測する活動なのだ。AIはその調査と差分作成を支援できるが、承認された契約、製品の表現範囲、実際の試験結果が判断の根拠になるのだ。
運用では、観測結果と到達性評価を分け、暫定緩和と本体修正を結び付けるのだ。設定が存在することから一歩進め、どの通信を、どの条件で、どの証拠によって制御しているかを説明できる状態を維持するのだ。