WAF & Shield — Webアプリの門番と盾

ネットワークレイヤーだけじゃ足りない理由

ウェブアプリケーションって毎日、何千件・何万件のリクエストが来るじゃないですか。正規のユーザーもいれば、SQLインジェクションやXSS狙ってくる攻撃も。さらには単なる嫌がらせのDDoS攻撃まで。こういった脅威から守るのがWAFとShield。

TikTokで「個人情報が全部見える」みたいな動画、見たことありませんか。あるいは昔の大手サイトでSQLインジェクションで全顧客データ漏洩、みたいなニュース。こういう攻撃は、ネットワークレイヤーではブロックできません。IPアドレスはまとも。ポート番号も正常。でも、送ってくるHTTPリクエストの中身が悪い。

例えば「/search?query=」。ネットワーク的には普通のGETリクエスト。でもアプリケーションレイヤーではXSS攻撃。SGやNACLは「ネットワークレイヤーの警備員」です。このアプリケーションレイヤーの攻撃は見えません。

だからアプリケーション層の防御が必要。それがAWS WAF（Web Application Firewall）とAWS Shield です。ネットワークレベルの攻撃はSG/NACL。アプリケーションレベルの攻撃はWAF。DDoS攻撃はShield。これが階層です。

WAF——「入口のボディチェック」

WAFの基本思想は「入口のボディチェック」。全てのHTTP/HTTPSリクエストを検査。疑わしいやつは止める。ユーザーが見えない階層で。WAFはCloudFront、Application Load Balancer（ALB）、API Gateway、AppSync、Cognitoに前置できます。つまりウェブアプリケーションのほぼ全ての入口です。

WAFのルールは二種類です。AWS Managed Rules。AWSが用意した、CRS（Core Rule Set）。OWASPの既知攻撃パターンをカバー。SQLインジェクション、XSS、Local File Inclusion、Remote Code Execution などなど。ほぼ全ての一般的な攻撃をブロック。

ただし「既知」が前提です。新しい脆弱性が発見されると、AWSがCRSを更新するまで時間がかかる可能性があります。あるいはあなたのアプリケーション独特のロジックには対応できない。

Custom Rules。あなた自身が書くルール。「このパスへのアクセスはこのIPだけ許可」「このリクエストサイズを超えたら拒否」「この特定のスクリプトフレーズを含んだら拒否」。カスタムルールの書き方はシンプル。JSONでマッチング条件とアクション（Allow / Block / Count）を定義。

条件は例えば「HTTPメソッドがPOSTで、かつURLが /admin/login」ならBlock、とか。HTTPリクエスト全体を検査するので色々指定できます。Header、QueryString、Body、IPアドレス、Country、Rate（1分間に何リクエストか）など。WAFは「レイヤー7（アプリケーション層）の防御」です。Network Firewall（ネットワークレイヤー）とは別。両方使うことで多層防御が完成。

マネージドルール——OWASP Top 10との向き合い方

AWS Managed Rulesの詳細。これを理解していないと、誤検知で大量のリクエストをブロックする羽目になります。AWS Core Rule Set（CRS）。OWASPが定義した「Webアプリケーション脆弱性のTop10」をカバー。Injection（SQL / Command / LDAP）、Broken Authentication、Sensitive Data Exposure、XML External Entity（XXE）、Broken Access Control、Security Misconfiguration、Cross-Site Scripting（XSS）、Insecure Deserialization、Using Components with Known Vulnerabilities、Insufficient Logging & Monitoring。

AWSのCRSルールグループは、これらにマップされた複数のルールを持ちます。ここが大事。本番環境で新しいルールを追加するときはいきなりBlockしません。まず Countモードで運用。「どれだけのリクエストがこのルールに引っかかるか」を観察。

もし正常なユーザーのリクエストが大量に引っかかっていたら、ルールを調整。例えば特定のIPアドレスを除外するとか、より厳しい条件に調整するとか。1週間Countモードで誤検知がほぼ0になったら、Blockに切り替えます。

あるチームがSQL Injectionルールを有効化したら、いきなり正常なクエリが大量ブロック。理由はクエリ文字列に単なるアポストロフィ（‘）が含まれていた。正常なデータ（例えば “O’Brien”という名前）で引っかかっていた。ルールを調整して「より複雑なSQL風パターン」に絞った。すると実際のSQL インジェクション攻撃はブロックされるのに、正常なリクエストは通る。新ルール導入は Count→ Blockの段階的運用。いきなり Blockは事故です。試験でも出ます。

レートベースルール——ボットとブルートフォース攻撃対策

次。レートベースルール。「1分間に何リクエストなら許可か」という閾値を設定。例えば。IPアドレス単位で「1分間に100リクエスト」と設定。超えたらBlock。これで何が防げるか。

ブルートフォース攻撃です。パスワードログイン画面を狙って、毎秒大量の試行。正常なユーザーなら数秒で完了。でも毎秒何十リクエストはありえない。レートベースルールで即座に拒否。

スクレイピング / API乱用。あるユーザーがあなたのAPIを毎秒何千回も呼び出す。アカウントを盗んだ悪者かもしれない。あるいは競合他社が価格情報を盗んでいるかも。レートベースルールで制限。

レート計算の「スコープ」を選べます。IPアドレス単位 / HTTPHeader（例えばAPIキー）単位 / QueryStringパラメータ単位。例えばAPIキーを持つ正当なユーザーなら高い閾値を許容。IPアドレス単位なら低い閾値。こう分けられます。

「1分間に100リクエスト」が厳しすぎるかも、という心配。リアルユーザーの行動を観察。例えば画像を50個貼ったページをロードするとブラウザは並列リクエストで50～100リクエスト送信。一般ユーザーでも1分で100超えることあります。だから実装前に本番に近いテスト環境で「正常なユーザー操作のリクエスト数」を測定。その2～3倍を閾値に設定。これが無難です。

Bot Control——スマートボット対策

レートベースルールで防げるのは「大量リクエスト」です。でも最近のボットは「自然なペースでリクエスト」を送ります。1秒に1リクエスト。だからレート制限も引っかからない。こういう「スマートボット」に対抗するのがBot Control。

Bot Controlは機械学習を使ってリクエスト元を判定。「これは本当にブラウザ」「これはスマートフォン」「これはボット」を判断。判定根拠は複雑です。リクエストのタイミング、ユーザーエージェント、JavaScriptの実行有無、マウス動き（JavaScriptで検出可能）、TLSフィンガープリント、など。

WAFルールグループにBot Controlを追加。すると各リクエストに「BotCategory」というラベルが付きます。その値に基づいてルール設定。例えば。BotCategory = LEGITIMATE_BOT（Googleの爬虫ロボット）→ Allow、BotCategory = SUSPICIOUS_BOT（不明なボット）→ Challenge、BotCategory = KNOWN_MALICIOUS_BOT（既知の悪質ボット）→ Block。こう分けられます。Bot Control=機械学習による「あの子ボット？人間？」判定。段階的対応です。

CAPTCHA / Challenge——人間確認

「ロボットですか、人間ですか」。reCAPTCHAで見たやつ。WAFでも ChallengeやCAPTCHAを出せます。Challenge。ユーザーのブラウザにJavaScriptチャレンジを送信。正常なブラウザなら、JavaScriptを実行して証明をWAFに返す。ボットはJavaScript実行できない（大抵）ので失敗。

メリット。ユーザー側では何も見えない。バックグラウンドで判定。画像選択とか煩わしい操作不要。CAPTCHA。「信号機の画像を選んで」みたいな、あの嫌な画像認識。ユーザーには見える。でもボットには難しい（視覚AIが進化しつつあるので完全ではない）。

Bot Controlで SUSPICIOUS_BOTと判定されたら Challenge。Challengeをパスしたら Allow。KNOWN_MALICIOUS_BOTは即Block。この層別対応がユーザーエクスペリエンスとセキュリティのバランスです。Challengeだけで十分なケースが多い。不要にCAPTCHAを出すとユーザーがストレスを感じるしアクセシビリティが下がる（視覚障害者向け選択肢が必須）。

Shield Standard vs Advanced——「無料保険」vs「プレミアム保険」

さあDDoSの話です。DDoS（Distributed Denial of Service）攻撃。複数の場所から大量のトラフィックを一気に送る。サイトが過負荷になって落ちる。AWSは全ユーザーにShield Standardを無料で提供。これは「自動的にDDoS検出・軽減」。ほぼ全ての一般的なDDoS攻撃（Layer 3 / 4レベル）を防ぎます。ユーザーは何もしない。自動です。

では Shield Advancedは何か。Shield Advancedは有料（月3,000ドル、アメリカ）。何が追加される。DRT（DDoS Response Team）。DDoS攻撃が起きたときAWSのセキュリティ専門家チームが対応。「これはどういう攻撃か」「どう対策するか」をアドバイス。DDoS対応SLA。DDoSによる通信遅延や接続喪失に対してクレジット保証。

WAF統合割引。WAFを使う場合、割引。CloudFront/ALB/NLBへの適用。Shield Standardは全リージョン適用だけど、Advancedはこれらの各サービスで、より細かい検出・軽減設定が可能。Shield Advancedは SLAが重要な企業向け。「DDoS攻撃で5分止まった」という損失が大きい金融機関とか大規模SaaSとか。個人や小規模スタートアップなら Shield Standardで大丈夫。AWSインフラ自体がDDoS軽減してくれるので。Shield Standard=無料で最低限のDDoS防御。大抵これで十分。Shield Advanced=有料でSLA保証。攻撃時の専門家対応。大企業向けです。

WCU管理——「火力」をコントロール

WAFルールは、それぞれ「処理コスト」を持ちます。WCU（Web ACL Capacity Unit）です。複雑なマッチング条件を持つルールほどWCUが高い。例えば「IPアドレス + HTTPメソッド + QueryString + Bodyの正規表現マッチ」は「IPアドレスだけ」より WCUが高い。

各Web ACLは最大1,500 WCUまで使用可能。ルールを追加していくと WCUが消費される。1,500を超えたら新しいルールは追加できない。WCUを抑えるコツ。単純なルール設計。複数条件のAND / ORを組みすぎない。IP reputation listを活用。AWS提供のブラックリストIPを使うと WCUが低い。

Rateベースルール優先。複雑な正規表現より Rateベースルールの方が効率。ルールグループの整理。使ってないmanaged rulesは削除。大規模サイトで WAFルールグループが増えると WCU逼迫することがあります。その場合は複数のWeb ACLに分割したり AWSに相談してWCU拡張を依頼したり。WCU=WAFの処理能力。複雑なルール設計はWCUを消費。シンプルさが勝つです。

Firewall Manager——複数アカウント・リージョンの一元管理

最後。企業が大きくなってAWSアカウントが複数ある。各アカウントでWAFを設定。これを一元管理したい。AWS Firewall Manager。Organizationの複数アカウント、複数リージョンのWAF / Shield / VPCセキュリティグループを、一箇所から管理。

例えば。「全アカウントのCloudFrontに同じManaged Rulesを適用」という一括設定。OrganizationレベルでPolicyを作ると、配下の全アカウントに自動適用。Organization管理アカウントでのみ設定可能。メンバーアカウントでは Firewall Managerで作られたルールを削除・変更できない。ガバナンスを強化できます。Firewall Managerも有料。WAFとは別料金。Organization単位での課金。ただし複数アカウント管理の煩雑さを考えると大規模企業なら投資価値あります。

よくある間違い——これだけは避けろ

最後に実装での引っかかりポイント。間違い1はAPIキーは認証ではないことです。「APIキー」をWAFで許可してるから安全、と思ってる企業。大間違い。APIキーは「識別」です。「あなたは誰ですか」に答えてるだけで「あなたは何をしていいですか」を答えてない。

正しい実装は APIキーで認証した上で、IAMロールやCognitoで「このユーザーは何ができるか」を制御。WAFはAPIキーの有無は確認するけど権限判定は別レイヤー。間違い2はWAFだけで全てをブロックすることです。WAFは攻撃パターンを検出するけどビジネスロジックの脆弱性は見えない。

例えば「ユーザーIDが数値なら連番で他人のデータが見える」みたいな問題。WAFは見つけられない。アプリケーション層で アクセス制御を厳格に。間違い3はCount モード放置。新しいルールを追加してCount モードのまま3ヶ月放置。その間多数の攻撃がブロックされずに通っていた。Countモードは「様子見」。本運用には戻す必要があります。

間違い4はBot Controlで全ボットをブロックすること。Googleの爬虫ロボット、Bingもボットとしてカテゴリーされます。これを全部ブロックすると検索結果に乗らなくなる。SEOが死ぬ。ボットカテゴリーを理解した上で悪質なボットだけブロック。

間違い5はWAFルールの定期更新忘れ。AWSがCRSを更新するけど、それはAWS側。あなたのWeb ACLは自動更新されない。定期的（月1回）にAWSのお知らせをチェック。新しい脅威が出たら カスタムルールで対応。WAFは「入口のボディチェック」。基本に忠実に段階的運用。いきなりBlockは禁止です。試験でも出ます。

WAF & Shieldのまとめ

WAFはアプリケーション層の防御。Managed Rulesで一般的な攻撃をカバー。カスタムルールで独自の制御。Bot Controlで不正ボット検出。Challenge / CAPTCHAで最終判定。Shield StandardでDDoSの基本的な防御。必要ならAdvancedでSLA保証。Firewall Managerで複数アカウント管理。全部を組み合わせるとアプリケーションが堅牢になります。

ただし忘れないでください。WAFはあくまで「パターンマッチング」。予測不可能な新しい攻撃には対応できません。WAF+監視+インシデント対応体制。この三つで初めて「セキュアなアプリケーション」が成立。では、ここまでAWS SCS-C03の根幹——Security Hub、VPC、S3、WAF / Shieldを学びました。次は、その先へ。Secrets Manager、Encryption、IAMのより深い話へ進みます。試験合格目指して、頑張ってください。