AI時代にWAFはどう変わるべきか
文書番号：2608.00007
要旨
注文APIの例で、正常通信の定義とアプリケーション側の認可を分けて学ぶ入門編なのだ。製品を使った詳細な工程はWAF運用の全体像へ進むのだ。
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を導入済みという事実だけでは十分な説明にならないのだ。逆に、各質問へ対象範囲と証拠を添えて答えられれば、非技術者も残るリスクを判断しやすくなるのだ。
この回の判断基準
「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） | 外部から見えるシステムや公開経路を継続的に発見し、管理する活動。 |