クラウドアプリ防御（WAAP: WAF・API・ボット対策）

クラウドアプリケーションはインターネットに直接公開されるため、SQL インジェクション・API 悪用・DDoS・ボットスクレイピングが絶え間なく着弾する。WAAP（Web Application and API Protection） は WAF・DDoS 防御・API 保護・ボット管理を単一サービスに統合したアーキテクチャだ。Gartner の「Cloud WAAP Market Guide 2025」が代表的な指標となっている。情報カットオフ ~2025-08、confidence: medium 固定。

WAAP とは何か：4 つの中核機能

WAAP は以下の 4 機能を同一サービスで提供する統合概念だ。

機能	防御対象	概要
WAF	アプリ層攻撃（L7）	SQLi・XSS・SSRF 等の OWASP Top 10 攻撃をルール＋振る舞いで遮断
DDoS 防御	L3/L4/L7 フラッド	ボリューム攻撃・SYN フラッド・HTTP フラッドを CDN・スクラビングで吸収
API 保護	API エンドポイント	shadow/zombie API 発見・スキーマ検証・認可欠陥検知
ボット管理	自動化攻撃	クレデンシャルスタッフィング・スクレイピング・在庫枯渇の識別と遮断

従来は WAF と DDoS 対策が別製品で運用されていたが、API とボットへの攻撃が増加した 2020 年代以降、4 機能の統合が業界標準となった。

WAF（Web Application Firewall）

WAF はアプリケーション層（HTTP/HTTPS）の攻撃を検知・遮断する。

検知方式：

シグネチャ（ルールベース）：OWASP ModSecurity CRS などの既知パターンマッチング。
振る舞い分析（アノマリー）：正常トラフィックのベースラインから逸脱したリクエストを検知。
ポジティブセキュリティモデル：許可リスト方式で、定義済みパターン以外を拒否する。

OWASP Top 10 に含まれる SQLi・XSS・SSRF・コマンドインジェクションが WAF の主要ターゲットだ。OWASP アプリセキュリティの詳細は tech-137 を参照。

誤検知チューニング：WAF を最初から「ブロックモード」にすると正当なリクエストが拒否されてビジネス影響が出る。検知モードで学習期間を設け、ホワイトリストを育ててからブロックモードへ段階的に移行するのがベストプラクティスだ。

API セキュリティ

現代のウェブサービスはほぼ API で成立しており、API が新たな主要攻撃面となっている。

API 発見の問題：組織が把握していない「shadow API」（開発者が追加したまま管理されていない）や「zombie API」（廃止済みだが残存しているエンドポイント）が攻撃に悪用される。WAAP は API トラフィックを継続観測して自動でインベントリを生成する。

OWASP API Security Top 10:2023：API 固有のリスクを 10 種類にまとめたもの。

順位	リスク	概要
#1	BOLA（Broken Object Level Authorization）	他ユーザーのリソースに認可なくアクセス。最も悪用が多い。
#2	Broken Authentication	脆弱な認証・セッション管理
#3	Broken Object Property Level Authorization	プロパティ単位の認可欠陥（過剰応答を含む）
#4	Unrestricted Resource Consumption	レート制限なしによる DoS・コスト爆発
#5	Broken Function Level Authorization	管理機能への横断的アクセス

BOLA（旧 IDOR） は WAF では検知が難しい。なぜなら認可はアプリロジックに依存し、リクエスト自体は正当な HTTP として見えるからだ。WAAP の API セキュリティ機能はランタイムでのアクセスパターン分析によって検知する。

スキーマ検証：OpenAPI / Swagger 定義に基づいてリクエスト・レスポンスを検証し、定義外の入力を拒否する。

レート制限：エンドポイントごとの呼び出し上限を設定し、ブルートフォースやリソース枯渇を防ぐ。

ボット対策

自動化スクリプトによる攻撃は多岐にわたる。

クレデンシャルスタッフィング：過去の漏洩 ID/パスワードリストを使い、自動で大量ログイン試行する攻撃。成功率は低くても、大規模に試行することでアカウント乗っ取りが発生する。

スクレイピング：価格情報・在庫情報・コンテンツを自動収集する。EC サイトや航空券サイトで競合他社が価格ダンピングに利用する。

在庫枯渇（Scalping）：限定商品を bot が買い占め、転売目的で価格をつり上げる。

検知手法：

クライアント挙動分析：マウス移動・クリック間隔・ページ滞在時間などのブラウザ挙動で人間か bot かを識別。
ブラウザフィンガープリント：ヘッダー・TLS フィンガープリント・JavaScript 実行環境を分析。
CAPTCHA：チャレンジ方式。ただし高度な bot や CAPTCHA ファームによる突破が増えており、単体では不十分。

IP アドレスブロックは bot が IP をローテーションするため効果が限定的だ。挙動ベースの識別が主流になっている。

DDoS 防御

DDoS（Distributed Denial of Service）攻撃は複数のレイヤーで発生する。

L3/L4 攻撃（ネットワーク・トランスポート層）：SYN フラッド・UDP フラッド・Amplification 攻撃。大量パケットで帯域を飽和させる。CDN やスクラビングセンターで上流で吸収するのが基本対策。

L7 攻撃（アプリケーション層）：通常の HTTP リクエストを大量送信し、アプリサーバーのリソースを枯渇させる（HTTP フラッド・スローロリス）。WAF のレート制限・振る舞い検知と組み合わせて対処する。

ネットワークセキュリティアーキテクチャ全般における DDoS 対策の位置付けについては tech-112 を参照。

主要プロバイダー：Cloudflare・Akamai・Imperva（現 Thales 傘下）・F5・AWS WAF + Shield Advanced・Fortinet。各社ともグローバル Anycast ネットワークで上流 DDoS を吸収する。

アンチパターン一覧

#	アンチパターン	リスク	対策
1	WAF を「検知モード」のまま本番放置	ルール評価のみで攻撃を遮断しない	チューニング完了後にブロックモードへ移行。段階的移行を計画する。
2	API を WAF 任せで個別保護なし	shadow API・BOLA 等の認可欠陥が未検知	API セキュリティ専用モジュール＋スキーマ検証の導入
3	BOLA 等の認可欠陥を WAF で防げると誤解	認証は通過するため WAF は素通し	アプリ側でオブジェクト単位の認可チェックを実装（参照: tech-137）
4	ボット対策を IP ブロックリストのみに依存	IP ローテーションで容易に回避される	挙動分析＋ブラウザフィンガープリントによる識別
5	API インベントリを把握していない	shadow/zombie API が無防備のまま存在	WAAP の API 発見機能＋定期監査で全エンドポイントを把握
6	レート制限を設定せず無制限 API アクセスを許可	DoS・コスト爆発・ブルートフォース	エンドポイント単位のレート制限＋ IP / JWT subject 別クォータ

Cloud Application Protection: WAAP（WAF/API/Bot）