AI時代にWAFはどう変わるべきか
先に結論
Frontier AIによってWAFが役に立たなくなるわけではない。AI以前から存在したブラックリスト型防御の限界が、攻撃候補の生成、探索、変形、再試行の低コスト化によって大きく見えるようになる。
進むべき方向は、WAFを捨てることではない。既知攻撃の検知を残しながら、API契約で「存在するEndpoint、許可Method、Content-Type、入力Schema」を定義し、契約外の通信を観測または拒否する。さらに、Schemaでは表せない認可、業務フロー、資源消費をアプリケーションとPolicyで守るのだ。
WAFは、Web Application Firewallの略である。WebサイトやAPIの手前に置かれ、届いた通信を検査し、攻撃らしい通信を止める。建物にたとえるなら、入口で危険物や不審な行動を調べる警備員に近い。ただし、警備員が持つ「過去に見つかった危険物の一覧」だけでは、すべての危険を見抜けない。
そこで必要になるのが、「悪いものを探す」だけでなく、「この建物へ持ち込んでよいものを決める」という考え方である。本稿ではこれをPositive Securityと呼ぶ。来訪者名簿、利用できる入口、持ち込める荷物、入ってよい部屋を決め、それ以外を確認対象にするイメージなのだ。
この記事では、攻撃の細かな手口を覚える必要はない。WAFが得意なこと、API契約が得意なこと、アプリ自身でなければ判断できないことを三つに分けて理解すればよい。
| 防御 | 主に扱うもの | 強み | 単独では残る問題 |
|---|---|---|---|
| WAFマネージドルール | 既知の攻撃特性、異常パターン | 広いWeb通信へ早く適用できる | 未知変形、誤検知、アプリ固有の正当性 |
| API Schema検証 | Path、Method、型、必須、長さ、形式 | 契約外入力を狭くできる | BOLA、権限、操作順、正しい値の悪用 |
| 認証・認可Policy | 主体、権限、対象オブジェクト | 誰が何をできるかを制御する | 大量実行、業務フロー悪用、実装不備 |
| 業務・濫用対策 | 回数、順序、状態、価値移転 | 正規APIを使う悪用へ対応できる | 未知攻撃の網羅、基盤脆弱性 |
表の各行は競合製品ではなく、異なる役割を持つ防御である。鍵を掛けたから監視カメラが不要になるわけではなく、監視カメラがあるから入室権限の確認が不要になるわけでもない。同じように、WAF、Schema検証、認証・認可、業務対策は重ねて使う。
まず、WAFが見ているものを知る
利用者がWebサイトを開いたり、スマートフォンアプリで注文したりすると、端末からサーバーへ通信が送られる。WAFはその途中に立ち、URL、送信方法、文字列、Header、本文などを調べる。明らかに攻撃で使われる文字列や、過去の攻撃に似た特徴があれば、Backendと呼ばれる本体のシステムへ届く前に遮断する。
これは大きな価値を持つ。同じWAFの背後に複数のWebシステムがあれば、共通する攻撃をまとめて観測できる。新しい脆弱性が見つかり、本体の修正に時間がかかる場合には、悪用で使われる通信を暫定的に止める「仮想パッチ」としても利用できる。
ただし、WAFは通常、業務のすべてを理解しているわけではない。注文番号12345が正しい形式だとは判定できても、その注文を見ようとしている人が購入者本人かは、利用者情報と注文データを照合しなければ分からない。金額10000が数字だとは分かっても、その送金を承認してよいかは組織の規則による。
つまりWAFは、入口で観測できる通信から判断する仕組みである。見えていない通信、暗号を解けない通信、検査上限を超えた部分、別経路から直接届く通信は判断できない。ログに攻撃が残っていないことは、攻撃が存在しなかった証明にはならないのだ。
ブラックリスト方式の限界はAI以前からある
WAFはSQL Injection、XSS、RCE、既知の悪性入力などを検出し、アプリケーションへ届く前に遮断できる。緊急時の仮想パッチ、共通の観測点、複数アプリへの横断適用という価値は今後も残る。
一方で、悪い入力の集合を列挙する方式には構造的な限界がある。
- 同じ意味を持つ入力を、符号化、分割、構文、Content-Typeで変形できる。
- アプリケーションごとにParser、Framework、業務上の正常値が異なる。
- 検知を広げるほど、正常通信を止める誤検知が増えやすい。
- 正しい形式と認証で実行される権限逸脱や業務濫用は見えにくい。
- 検査サイズ、復号、圧縮、Protocol、非HTTP経路などの観測限界がある。
これは「シグネチャが少ない」という問題だけではない。無限に近い入力空間から悪いものを探し続ける側と、止めてはいけない正常通信を抱える側の非対称性なのだ。
ブラックリスト方式は、空港の保安検査で「過去に危険だった品物」を探す考え方に似ている。既知の危険物を素早く止められる一方、形を変えたものや、単体では問題がない品物の組み合わせまで完全に列挙するのは難しい。検査を厳しくしすぎれば、無害な荷物まで止めてしまう。
セキュリティでは、正常な通信を誤って攻撃と判定することを誤検知という。反対に、攻撃を正常と判定して通すことを未検知という。防御ルールを広げると未検知を減らせる場合があるが、誤検知が増えて注文やログインを止めるかもしれない。この両者の調整は、単純に「検知率が高い製品ほどよい」とは言えない理由である。
同じ文字列でも意味が変わる
WAFが難しいのは、文字列だけを見ても意味が一つに決まらないからである。ある記号が検索欄では正常な検索語でも、データベースへ渡す処理では攻撃の一部になることがある。アプリが文字列を一度だけ変換するのか、二度変換するのかによっても、最終的に処理される内容が変わる。
また、現代のWeb通信にはJSON、XML、フォーム、ファイルなど複数の形式がある。圧縮されたデータや大きなファイルは、製品や設定によって検査できる範囲が異なる。WAFが「許可した」のか、検査できずに「通過した」のかも区別しなければならない。
この限界はWAF製品の欠陥というより、入口だけで任意のアプリの意味を完全に理解することが難しいという構造から生じる。だからこそ、WAFだけで完結させず、API契約とアプリ側の判断を重ねる必要がある。
Frontier AIは限界を作るのではなく増幅する
ENISAは2026年7月に、Frontier AI時代のサイバーセキュリティについて、政策当局、防御側、サービス提供者向けの初期提言を公開した。ここから導くべき主張は「AIが新しい魔法の攻撃を作る」ではなく、高性能モデルが攻撃者の能力、速度、規模を変えうるため、防御側も運用と設計を更新する必要があるということだ。1
AIは、攻撃候補の生成、コードやエラーメッセージの解釈、入力変形、偵察結果に応じた次の試行を支援できる。したがって、既知パターンを追加して追い掛ける周期だけでは、攻撃側の反復速度に追い付けない場面が増える。
ただし、AIが使われたかをWAFログから確定することは通常できない。大量の変形や短い探索間隔は兆候になっても、攻撃主体のツールを証明するものではない。防御設計は「AI攻撃を識別する」より、「入力の自由度と実行可能な操作を縮める」方へ置くべきなのだ。
Frontier AIとは、その時点で最先端に近い能力を持つAIモデルの総称であり、一つの製品名ではない。文章の作成だけでなく、プログラムの読解、エラーの説明、試行結果に応じた次の候補作成などを行える。この能力は防御側にも攻撃側にも利用されうる。
たとえば攻撃者が一つの入力を試し、エラーを受け取り、その内容を読んで次の入力を考える作業を想像する。従来は人が一回ずつ調べていた作業の一部をAIが補助すれば、候補を作る速度と量が増える。成功を保証するわけではないが、試行錯誤にかかる費用を下げる可能性がある。
重要なのは「AIが作った特別な攻撃文字列」を見つけることではない。同じ攻撃内容でも、人が書いたかAIが作ったかを通信だけから見分けるのは難しい。防御側が確認すべきなのは、攻撃者の道具ではなく、自分たちのシステムが何を受け付け、何を実行できる状態になっているかである。
攻撃者の選択肢を減らす
入力できる項目が100個あり、値の長さも形式も自由なら、試せる組み合わせは非常に大きい。必要な項目を10個に限定し、文字数、形式、選択肢、Methodを定めれば、少なくとも契約外の試行を早い段階で拒否できる。これが入力空間を狭めるという意味である。
実行できる操作も同じである。管理用APIをインターネットへ公開しない、一般利用者には参照だけを許可する、一回の送金額と回数を制限する。こうした制約は、AI攻撃を識別できなくても効果を持つ。相手の速度が上がるほど、自分たちが許可する範囲を明確にしておく価値が増すのだ。
Positive Securityは正常通信を定義する
ここでいうPositive Securityは、悪性パターンの追加だけに頼らず、アプリケーションが受け付ける通信を許可側から定義する考え方である。APIでは、Web画面の任意入力よりも契約を作りやすい。
受信リクエスト
|
+-- 未登録のHost / Path / Method --------> 拒否または観測
|
+-- 不正なContent-Type / Body ----------> 拒否
|
+-- Schema不適合 ------------------------> 拒否または観測
|
+-- 認証・認可不適合 --------------------> 拒否
|
+-- 回数・順序・状態が不正 --------------> 拒否、Challenge、保留
|
`-- 契約・Policy適合 --------------------> Backendへ
Cloudflare API ShieldのSchema Validationは、アップロードしたOpenAPI Schemaと受信リクエストを比較し、Endpoint、PathまたはQuery変数、HTTP Methodなどの適合性を検出する。重要なのは、検出だけでは自動的に通信を止めず、結果を確認してCustom Rulesで強制する段階構造になっている点である。2
これは安全な導入順序でもある。
- 正本候補のOpenAPIを用意する。
- 実トラフィックとの差を検出する。
- 未記載の正規EndpointとShadow APIを分類する。
- 契約と実装の差を修正する。
- 影響範囲を限定してBlockへ移す。
- 変更後も差分と拒否理由を監視する。
いきなり厳密な許可リストを本番へ当てると、古いクライアント、未記載Endpoint、任意項目、Content-Type差異を止める。Positive Securityは強いが、契約品質と変更同期を要求するのだ。
ここで登場するHost、Path、Method、Content-Typeを郵便物に置き換えてみる。Hostは建物名、Pathは部署や窓口、Methodは依頼の種類、Content-Typeは封筒の中身の書式に近い。宛先が存在しない、受付業務にない依頼を出す、指定されていない形式の書類を送る、といった通信は契約外として扱える。
Schemaは書類の記入規則である。氏名は文字、数量は整数、日付は決められた形式、必須欄は空にしない、といった条件を表す。これにより、WAFが知らないアプリ固有の「正常な形」を検査できる。
観測してから止める理由
既に動いているシステムでは、設計書に載っていないが正規に使われている通信が見つかることがある。古いスマートフォンアプリだけが使うEndpoint、特定の取引先だけが送る任意項目、試験後に残った管理機能などである。このうち、組織が把握していないAPIをShadow APIと呼ぶ。
Shadow APIをすべて即座に攻撃とみなして止めると、業務を壊す可能性がある。まず通信を観測し、「契約へ追加すべき正規機能」「廃止すべき古い機能」「不正な通信」に分類する。その後、契約と実装を直し、対象を限定して拒否へ移す。
WAF製品でCountやLogと呼ばれる動作は、条件に一致しても通信を止めず、件数や内容を記録する。Blockは実際に拒否する。製品ごとに名称や細部は異なるが、観測と強制を分ける考え方は、安全に導入するうえで重要なのだ。
許可リストにも保守が必要である
Positive Securityは一度設定すれば終わる防御ではない。アプリへ新しい項目や操作を追加したのに許可ルールを変えなければ、正常通信を止める。反対に、廃止した機能を許可リストへ残せば、不要な入口が開いたままになる。
そのため、API契約、実装、GatewayやWAFの設定、テストを同じ変更として扱う必要がある。第4回で扱う「同期」は、Positive Securityを現実に運用するための条件なのだ。
Schemaで守れる範囲を過大評価しない
OWASP API Security Top 10 2023は、BOLA、Broken Authentication、Broken Object Property Level Authorization、Unrestricted Resource Consumption、Sensitive Business Flowsへの無制限アクセス、Improper Inventory Managementなどを挙げる。これらの多くは、JSON Schemaへ適合していても発生する。3
たとえば次のリクエストは完全にSchemaへ適合できる。
GET /accounts/12345/statements HTTP/1.1
Authorization: Bearer valid-token
問題は、トークンの利用者が12345の所有者かどうかである。PathもMethodも型も正しいため、Schema検証だけではBOLAを止められない。注文APIを正しい順序で一秒間に数千回呼ぶ資源消費や、クーポンを繰り返し取得する業務濫用も同様である。
したがって、Positive Securityを「OpenAPI Schema Validation」と同義にしてはならない。少なくとも次の三層へ分ける。
- 通信形状：OpenAPI、Method、Content-Type、Size、Schema。
- 主体と権限：認証、Scope、Role、Object Level Authorization、Tenant境界。
- 業務の意味：状態遷移、回数、順序、金額、職務分離、不正利用検知。
三層をオンラインバンキングで考えると違いが見える。
| 層 | 確認例 | Schemaだけで分かるか |
|---|---|---|
| 通信形状 | 口座番号が決められた桁数か、金額が数字か | 分かる |
| 主体と権限 | ログイン利用者が送金元口座の所有者か | 分からない |
| 業務の意味 | 一日の上限内か、承認が必要な高額送金か | 分からない |
BOLAは、形式として正しい識別番号を使いながら、他人のデータへアクセスする問題である。ホテルの部屋番号を一つ変えただけで、別の宿泊者の明細が見えるような状態に近い。API側は、ログイン済みであることだけでなく、その利用者と対象データの関係を毎回確認しなければならない。
Resource Consumptionは、計算、通信、保存領域などを大量に使わせる問題である。一回の要求が正常でも、非常に多く繰り返されればサービスを遅くしたり、利用料を増やしたりできる。Rate Limitは一定時間内の回数や量を制限するが、利用者、機能、業務時間などに応じた設計が必要になる。
Sensitive Business Flowの悪用は、正規の機能を望ましくない目的で使う問題である。限定商品の買い占め、予約枠の占有、クーポンの大量取得などは、入力がすべてSchemaに合っていても起こる。これを止めるには、回数、順序、状態、利用者の行動を業務規則として見る必要がある。
Positive Securityは、この三層すべてを許可側から考える大きな方針として使える。ただし、実装手段を一つのSchema検証機能へ縮めて理解してはいけないのだ。
WAFは消えず、役割が変わる
WAFのマネージドルールは、契約内の文字列に埋め込まれたInjection、公開直後の脆弱性、API以外のWeb画面、契約をまだ整備できないLegacyを守る。Schema検証は、WAFが知らないアプリ固有の通信形状を狭める。両者は代替ではなく、異なる失敗を補う。
NIST SP 800-228は、APIの開発時と実行時に存在するリスクを識別し、pre-runtimeとruntimeの基本・高度な制御を、段階的かつリスクベースで導入する考え方を示している。API Schema、Gateway、WAFの一要素だけで完結させず、ライフサイクルとして扱う根拠になる。4
実務では、次の順で境界を狭める。
| 段階 | 実施内容 | 確認する証跡 |
|---|---|---|
| 観測 | Endpoint発見、WAF Count、Schema違反検出 | 実通信、違反理由、未登録API |
| 限定 | 対象Host、Path、Method、Content-Typeを限定 | 許可一覧、例外、利用クライアント |
| 強制 | Schema、認証、認可、Rate Limitを適用 | 拒否ログ、誤検知、認可テスト |
| 適応 | 契約変更とPolicy変更を同じPull Requestで管理 | 差分、承認、Contract Test |
| 再確認 | 外部から旧経路と未知Endpointを継続検査 | ASM、外形監視、Gateway迂回試験 |
この段階表を、小規模な注文APIへ当てはめてみる。最初はWAFを記録だけの状態にし、実際に使われるPathとMethodを集める。次に/ordersへのGETとPOSTだけを対象にし、JSON以外の本文を観測する。契約との差を直した後で、異常なMethodや未知項目を拒否する。最後に、Backendへ直接接続できないことを社外ネットワークから確かめる。
ASMはAttack Surface Managementの略で、外部から見えるDomain、IP Address、Service、APIなどを継続的に把握する活動である。外形監視は、利用者や攻撃者と同じ外側から接続を試し、想定した入口だけが開いているかを確かめる。内部設定を見て「閉じたはず」と判断するだけでなく、外から到達できないことを証拠にする。
「防いだ」と言える範囲を限定する
WAFである攻撃を一度遮断できても、同じ脆弱性のすべての悪用を防いだとは限らない。検査されない経路、別の表現、検査上限を超えた本文、内部からの通信が残る場合がある。仮想パッチは本体修正までの時間を稼ぐ対策であり、脆弱性そのものを消すものではない。
また、拒否ログが増えたから攻撃が増えたとも限らない。新しいルールを有効にして、以前は記録されなかった通信が見えるようになっただけかもしれない。ログの件数を解釈するときは、検出条件、対象範囲、除外、検査できない部分、設定変更時点を合わせて確認する必要がある。
WAFの評価では、単純な検知数よりも、対象アプリに合わせて制御できるか、拒否理由を説明できるか、安全に観測から強制へ移れるかを見る方がよい。技術初学者は「たくさん止める製品」ではなく、「何を見て、何を見られず、なぜ止めたかを運用できる仕組み」と捉えるとよいのだ。
注文APIを多層で守る例
ここまでの防御を、Online Shopの注文APIへ当てはめる。利用者は商品番号、数量、配送先を送り、注文を確定する。APIのPathはPOST /ordersとする。
1. WAFが既知攻撃と異常を検査する
WAFは、本文やHeaderに既知のInjection攻撃に似た文字列がないか、明らかに不正な符号化がないかを検査する。緊急の脆弱性が見つかれば、悪用条件に合う通信を一時的に止めるRuleを追加できる。
しかし、商品番号P-100、数量2という普通の注文は攻撃文字列ではない。WAFだけでは、その商品を二個注文してよいか、在庫があるか、同じ人が一万回送っているかを判断できない。
2. API契約が通信の形を検査する
OpenAPI Schemaでは、商品番号は決められた形式、数量は1以上10以下、配送先は必須、契約にない項目は禁止、と定義する。DELETE /ordersが存在しないなら、そのMethodを拒否する。JSONだけを受け付けるなら、別のContent-Typeを拒否する。
これにより、数量へ非常に大きな値を入れる、管理者用らしい未知項目を追加する、存在しない操作を試す、といった契約外通信を減らせる。ただし、商品番号と数量が正しければ、盗んだAccountからの注文も形式上は通る。
3. 認証と認可が利用者を確認する
認証は、Tokenなどを使って注文者が誰かを確認する。認可は、その注文者が指定した住所や支払方法を使ってよいか、注文変更の権限があるかを確認する。
ログイン済みだからといって、URLの注文番号を変えて他人の注文を見られてはいけない。各Requestで、利用者と対象Objectの関係を確認する。これがBOLA対策の中心になる。
4. 業務Policyが正常機能の悪用を見る
一回の注文がすべて正しくても、一人が限定商品を短時間に大量確保すれば、他の利用者が買えなくなる。複数Accountを使う場合は、単純な一利用者あたりRate Limitだけでは足りないかもしれない。
商品の種類、在庫、配送先、端末、時間、過去の行動などを見て、追加確認、保留、取消を行う。ここは業務と不正対策の領域であり、WAFのManaged Ruleへ任せる部分ではない。
5. 観測が防御のずれを見つける
拒否Logには、どの層が、どの理由で、何を止めたかを残す。新しいApp版の公開直後にSchema違反が増えたなら、攻撃ではなく契約同期の漏れかもしれない。特定商品の発売時だけRate Limitが増えるなら、正常な集中と自動買占めを分けて調べる。
利用者
|
v
WAF 既知攻撃と異常な特徴
|
v
Schema Path、Method、入力形式
|
v
認証・認可 誰がどの注文を扱えるか
|
v
業務Policy 回数、順序、在庫、買占め
|
v
注文処理
一番上の層がすべてを理解する必要はない。各層が得意な判断を行い、前後の層が失敗を補う。この形が多層防御である。
正常通信を定義するときの落とし穴
Positive Securityは強力だが、「現在観測した通信を全部正常と登録する」だけでは危険である。観測期間中に攻撃通信や不要な旧機能が混ざっていれば、それまで許可してしまう。実通信は契約候補を発見する材料であり、正しさのOracleではない。
また、正常通信は利用者ごとに異なる場合がある。一般利用者、管理者、取引先Systemでは、使えるPath、Method、回数が違う。一つの広い許可Profileへまとめると、必要以上の操作を全員へ許すことになる。
File Uploadにも注意する。画像や文書は本文が大きく、WAFの検査上限を超えることがある。Upload用の経路を通常APIから分け、File種類、Size、保存先、Malware検査、公開までの状態を別に制御する。WAFを通ったことを、File内容全体の安全性と同一視しない。
拒否理由を運用できる形にする
「WAFで拒否」という一種類の記録だけでは、正常利用者の問題を直せない。少なくとも、未知Path、Method違反、Content-Type違反、Schema違反、認証失敗、認可失敗、Rate Limitなどを区別する。
ただし、外部の利用者へ内部情報を詳しく返しすぎると、攻撃者へ手掛かりを与える。利用者向けResponseは必要最小限にし、内部Logには調査用の理由とRequest IDを残す。利用者の問い合わせと内部記録をRequest IDで結べるようにする。
よくある誤解を言い換える
| よくある言い方 | より正確な読み替え |
|---|---|
| AI攻撃を検知するWAFが必要 | 攻撃者のTool判定より、許可する通信と操作を狭める |
| WAFを入れればWebは安全 | WAFが見える通信とRuleの範囲で一部の攻撃を抑える |
| Schemaに合えば正常 | 形式が正しいだけで、権限と業務上の正当性は別 |
| Block数が多いほど高性能 | 対象範囲、誤検知、未検知、拒否理由と合わせて評価する |
| 仮想パッチで修正済み | 悪用経路を一時的に狭めただけで、本体の脆弱性は残る |
| Logにないから攻撃はない | 未検査、別経路、未検知の可能性を除外できない |
防御の強さを説明するときは、「何を完全に防ぐか」ではなく、「どの経路の、どの条件を、どの証拠で狭めたか」を示すのだ。
非技術者が確認する防御の全体像
製品名や細かな攻撃名を知らなくても、次の質問で防御の抜けを確認できる。
- 外部へ公開する窓口は一覧になっているか。
- 一覧にない窓口や操作を、まず観測してから拒否できるか。
- ログイン済みというだけでなく、対象データを扱う権限を確認しているか。
- 正常な機能の大量利用や順序の悪用を、業務ルールとして見ているか。
- WAFを迂回して本体へ直接接続できないことを、外部から確認しているか。
- WAFが検査できない通信や大きさを把握しているか。
- 暫定対策の後に、アプリ本体の修正を追跡しているか。
一つでも不明なら、WAFを導入済みという事実だけでは十分な説明にならない。逆に、各質問へ対象範囲と証拠を添えて答えられれば、非技術者も残るリスクを判断しやすくなる。
この回で覚えておくこと
- WAFは通信の入口で既知攻撃や異常を検査するが、業務の意味をすべて理解できるわけではない。
- ブラックリスト方式の限界はAI以前からあり、AIは攻撃側の試行速度と量を増やして限界を目立たせる。
- Positive Securityは、正常として許可するPath、Method、入力などを定義する考え方である。
- Schemaが正しくても、他人のデータ閲覧、大量実行、業務フローの悪用は起こりうる。
- WAF、Schema、認証・認可、業務Policyを重ね、観測してから段階的に強制する。
- 「守れた」という説明には、直接経路を閉じた証拠と、検査できない範囲の明示が必要である。
目標は、未知攻撃をすべて言い当てることではない。システムが受け付ける通信と操作を必要な範囲へ狭め、各防御が見落とす部分を別の層で補うことなのだ。
この回の判断基準
「AI対応WAF」という製品名より、次を確認する方が長く使える。
- 正常なAPI通信を契約として定義できるか。
- 契約違反を理由付きで観測してから強制できるか。
- BOLAと業務濫用をSchema外のPolicyで扱えるか。
- アプリ変更とGateway、WAF、テストを同期できるか。
- Originや旧Endpointへの迂回を外部から検査できるか。
- WAFの未検知を「攻撃がなかった」と誤認しないか。
未知攻撃を完全に防ぐ方式はない。許される入力と操作を狭く定義し、既知攻撃検知、認可、業務Policy、観測を重ねることが、攻撃側の反復速度が上がる環境への現実的な応答なのだ。
前後の記事
用語集
| 用語 | 平易な説明 |
|---|---|
| Frontier AI | その時点で最先端に近い、高い能力を持つAIモデルの総称。特定の製品名ではない。 |
| WAF（Web Application Firewall） | WebやAPIへの通信を検査し、攻撃と判断した通信を遮断する防御装置やサービス。 |
| ブラックリスト方式 | 既知の悪い特徴を登録し、それに一致したものを拒否する考え方。未知の攻撃や変形には限界がある。 |
| Signature（シグネチャ） | 攻撃を見分けるための既知のパターン。Managed Ruleは提供事業者が管理するルール群。 |
| Positive Security | 正常として許可した通信の条件を定義し、それ以外を検出または拒否する考え方。一般に許可リスト方式とも呼ばれる。 |
| 誤検知／未検知 | 誤検知は正常通信を攻撃と判定すること。未検知は攻撃を見逃すこと。 |
| OpenAPI／Schema Validation | OpenAPIはAPIの設計を記述する標準。Schema Validationは実際の通信がその設計に合うかを検査すること。 |
| Shadow API | 管理台帳に載らず、組織が把握できていないまま動いているAPI。 |
| 認証／認可 | 認証は利用者が誰かを確認すること。認可は対象データや操作への権限を確認すること。 |
| BOLA（Broken Object Level Authorization） | 利用者が識別番号などを変え、本来は権限のない他人のデータへアクセスできる問題。 |
| Broken Authentication | 本人確認やToken管理の不備により、他人になりすまされる問題。 |
| Rate Limit | 一定時間内に受け付ける通信回数や処理量を制限する仕組み。 |
| Business Flow Abuse | 購入、予約、送金などの正規機能を、想定外の回数や順序で悪用すること。入力形式が正常でも起こりうる。 |
| Gateway | 利用者と内部システムの間に置き、認証、制限、振り分け、記録などをまとめて行う入口。 |
| Origin | GatewayやCDNの背後で、実際にアプリを動かす元のサーバー。直接到達できると入口の防御を迂回されることがある。 |
| Runtime／Pre-runtime | Runtimeは本番で通信を処理している時点。Pre-runtimeは設計、実装、試験など本番前の段階。 |
| ASM（Attack Surface Management） | 外部から見えるシステムや公開経路を継続的に発見し、管理する活動。 |