トップ > AWS WAF > AWS WAF 適用環境におけるペネトレーションテストの目的と対応方法を整理する

AWS WAF 適用環境におけるペネトレーションテストの目的と対応方法を整理する

AWS WAF セキュリティ AWS
記事タイトルとURLをコピーする

マネージドサービス部 佐竹です。
本日は AWS WAF を運用していると良くあるシチュエーションの1つ「ペネトレーションテストでの対応」について、その目的と対応方法をまとめます。

はじめに

本ブログは AWS WAF の基礎的な内容を理解されている方向けのブログです。

初学者の方は、以下の「AWS WAF とは何か？その基礎と用語を学ぼう」を先にお読みいただけると、理解が深まると思います。

blog.serverworks.co.jp

ぜひ、合わせてご覧ください。

ペネトレーションテストの必要性について

ウェブサイトや Web API は、日々様々な脅威にさらされています。この「門」（アタックサーフェス）を不正アクセスや攻撃から守るために、私たちは WAF (Web Application Firewall) という「門番」を配置し、リソースの保護に努めています。

AWS WAF のサンプル構成図

AWS WAF は、クラウドネイティブで高機能な「門番」として、SQL インジェクションやクロスサイトスクリプティング、DDoS 攻撃など、多様化・巧妙化する脅威から私たちの「門」を保護してくれるサービスです。

では、この「門番」が期待通りに動作し機能しているのか、また「門番」によって守られている「門」（つまりウェブサイト自体）に脆弱性が存在していないかをどのように確認するのでしょうか？その確認のために、定期的な「ペネトレーションテスト（ペンテスト/侵入テスト）*1」が行われることがあります。

そして、このペネトレーションテストを行うにあたり AWS WAF が有効な環境でテストを行う際には、「WAF の設定をテスト中にどう扱うか」という課題が生じます。

本ブログでは、AWS WAF 環境下でペネトレーションテストを実施する際の代表的な5つの対応方法と、それぞれのメリット・デメリット、そして状況に応じた考え方について解説します。

最初にペネトレーションテストの目的を明確にする

まず、今回のペネトレーションテストで何を達成したいのか、主目的を明確にしてください。

というのも、目的によって選択すべき対応方法が異なるためです。

ここでは、ペネトレーションテストの目的を以下の2つに分類しました。

  • 目的A: WAF を含めたシステム全体の防御能力を評価したい
    • 現在の AWS WAF の設定が想定された攻撃に対してどの程度有効かを含めて検証したい場合。
  • 目的B: ウェブアプリケーション固有の脆弱性を明らかにしたい
    • AWS WAF による防御の影響を一時的に排除し、保護対象のアプリケーション自体に存在するセキュリティ上の欠陥を特定＆評価したい場合。

補足ですが「どちらか一方でなければならない」というわけではなく、「どちらもが目的である」ということもあります。ですが、まずこの2つの目的を明確にする必要があります。その上で、以下を読み進めてください。

AWS WAF 適用環境におけるペネトレーションテストの対応方法

以下に、5つの代表的な対応方法を紹介します。

  • 対応方法1: WAF を有効にしたままテストを行う
  • 対応方法2: WAF を一時的にデタッチしてテストを行う
  • 対応方法3: WAF でルールを COUNT モードに変更する
  • 対応方法4: WAF の Allow List (IP 許可リスト) を使用する
  • 対応方法5: 特定のテストリクエスト識別子で除外する

なお、対応方法1は「目的A」に対応しており、残りの対応方法4つは全て「目的B」に対応しています。

対応方法1: WAF を有効にしたままテストを行う

対応方法1

本対応方法では AWS WAF の設定等を変更せず、本番稼働のそのままの状態、つまり AWS WAF が正しく有効な状態でペネトレーションテストを実施します。

対応方法1のメリット

  • 現在の WAF 設定（マネージドルール、カスタムルール等）が想定される攻撃シナリオに対してどの程度有効かを直接評価できます。
  • AWS WAF のログ（許可やブロックがされたリクエスト）を分析することで、ルールの有効性や誤検知（False Positive）等の可能性を確認できます。
  • 本番環境の設定を変更する必要がないため、オペレーションミスによるリスクがありません。

対応方法1のデメリット

  • WAF がテスト用の攻撃リクエストの多くをブロックしてしまうため、ウェブアプリケーション層に存在する潜在的な脆弱性を見逃してしまう可能性があります。
  • テスト結果が WAF の性能や設定状態に大きく依存します。これは、WAF がテスト攻撃の大部分を防いでしまう可能性が高いためです。

推奨されるケース

  • WAF 導入後の有効性検証や、定期的なセキュリティ監査の一環として、現在の防御体制の全体的な強度を確認したい場合 (目的A)。

対応方法2: WAF を一時的にデタッチしてテストを行う

対応方法2

本対応方法ではテスト期間中、対象のリソース（ALB, API Gateway, CloudFront など）から AWS WAF の Web ACL を一時的に関連付け解除（デタッチ）します。

対応方法2のメリット

  • WAF による影響を完全に排除できるため、ウェブアプリケーション固有の脆弱性を網羅的に洗い出すことに集中できます。

対応方法2のデメリット

  • テスト期間中は WAF による防御が完全に未適用の状態となり、本番環境が外部の脅威に対して無防備にさらされるという重大なセキュリティリスクがあります。本番環境でこの方法を用いることは原則として推奨されません。
  • 本番環境の構成とは異なる状態でのテストとなるため、WAF を含めた総合的な挙動は評価できません。
  • 設定の解除および再設定のオペレーションが必要となり、人為的ミスのリスクが伴います。
  • AWS WAF を通過しないため、テスト期間中のリクエストに関する AWS WAF のログが一切取得できなくなります。これにより、事後の WAF ログ分析や、万が一インシデントが発生した場合の調査に必要な情報が欠落します。

推奨されるケース

  • アプリケーション開発の初期段階や、本番環境とは隔離されたテスト環境（ステージング環境など）で、アプリケーション自体の脆弱性を網羅的に診断したい場合 (目的B)。

対応方法3: WAF でルールを COUNT モードに変更する

対応方法3

本対応方法では Web ACL に含まれるルールの多く、または全てのアクションを BLOCK から COUNT (カウント) に一時的に変更してテストを行います。COUNT モードでは、ルールに一致したリクエストはブロックされなくなりますが、その事実は AWS WAF のログとして記録されます*2。

なおこの対応方法は、前提として AWS WAF の Web ACL におけるデフォルトアクションが「Allow」で運用されている想定で記載しています。

対応方法3のメリット

  • 攻撃リクエストがブロックされずにアプリケーション層まで到達するため、アプリケーションの脆弱性を発見できます。
  • 同時に、どの攻撃ペイロードがどの WAF ルールに抵触していたかを事後にログで確認・分析でき、WAF ルールのチューニング（誤検知の低減や検知精度の向上）に役立ちます。

対応方法3のデメリット

  • 全てのルールを COUNT モードとすると、WAF はリクエストをブロックしないため、テスト期間中は実質的に WAF による防御が行われないことになります。対応方法2と同様、本番環境での実施にはセキュリティリスクが伴います。
  • 多数のルール設定を変更し、テスト後に確実に元の設定に戻す必要があり、オペレーション負荷と設定ミスのリスクがあります。
  • 1つのリクエストが複数のルールにカウントされる可能性があり、ログ分析がやや複雑になる場合があります。

推奨されるケース

  • リスクを十分に理解し、（可能であれば）監視体制を強化した上で、アプリケーションの脆弱性テストと WAF ルールの状況分析を同時に行いたい場合に適しています (目的B)。
  • 対応方法2と同様、テスト環境での実施が望ましいですが、本番環境で実施する場合は、テスト期間を最小限にし、厳重な監視下で行う必要があります。

対応方法4: WAF の Allow List (IP 許可リスト) を使用する

対応方法4

本対応方法ではペネトレーションテストを実施するテスター（セキュリティベンダー等）の送信元 IP アドレスを AWS WAF の IP セットで定義し、その IP セットからのアクセスを許可（Allow）するルールを Web ACL に追加します。これにより、テスターのみ AWS WAF をバイパスさせるようにします。

対応方法4のメリット

  • 指定した IP アドレスからの通信は WAF の他のルール評価（SQL Injection 検知など）をスキップして許可されるため、アプリケーションの脆弱性を効果的にテストできます。
  • WAF 自体は他の一般ユーザーからのアクセスに対して有効な状態を維持したままテストを実施できるため、対応方法2や対応方法3に比べてセキュリティリスクを大幅に低減できます。
  • 本番環境に近い構成で、かつアプリケーションの脆弱性診断も可能という、バランスの取れた対応方法となります。

対応方法4のデメリット

  • Allow ルールが意図通り機能するためには、ルールの優先度（Priority）を他のブロック/カウントするルールよりも高く（数値が最も小さいか 0 を指定）設定する必要があります。これを誤ると意図通りにバイパスされません。
  • テスト元の IP アドレスを正確に把握し、AWS WAF の IP セットに登録・管理する必要があります。もし IP アドレスが頻繁に変わる場合は、その都度 IP セットの更新が必要です。
  • テスト終了後、不要になった IP アドレスは、Allow List の IP セット内から速やかに削除される必要があります。

推奨されるケース

  • テスターの送信元 IP アドレスが固定されている場合には、最も推奨される対応方法です (目的B)。
  • セキュリティリスクを最小限に抑えつつ、アプリケーションの脆弱性を診断できるため、特に本番環境に対してペネトレーションテストを実施する場合に適しています。

対応方法5: 特定のテストリクエスト識別子で除外する

本対応方法ではペネトレーションテストで使用するリクエストに、特定の HTTP ヘッダー（例: XXXX-PenTest-Identifier: UniqueValue）や User-Agent 文字列などを付与するよう事前にテスターと合意し、これらの識別子を持つリクエストを検知した場合に許可（Allow）するカスタムルールを Web ACL に追加します。

補足：構成図は対応方法4と近似しているため割愛しました

対応方法5のメリット

  • テスト元の IP アドレスが固定できない、または多数存在する場合の、対応方法4に対する有効な代替策となります。
  • IPアドレスベースのAllow Listよりも、より細かく「テスト目的のリクエスト」を識別して他のルール評価から除外できます。

対応方法5のデメリット

  • テストツールやスクリプト側で、事前合意した識別子をすべてのテストリクエストに確実に付与する必要があります。
  • 除外条件となる識別子の設計が重要です。単純すぎると、実際の攻撃トラフィックと偶然一致し、WAFをすり抜けてしまうリスクがあります。
  • カスタムルールの作成と 優先度設定（通常は Allow List 同様に優先度を高く設定する対応）が必要です。
  • テスト終了後、このカスタムルールを確実に削除する必要があります。カスタムルールが残存した状態で識別子が漏洩した場合、セキュリティホールとなってしまう点に十分注意してください。

推奨されるケース

  • テスターの送信元 IP アドレスが不定、または動的に変わるクラウド環境等からのペネトレーションテストの場合に、対応方法4に対する代替案となります (目的B)。

どの対応方法を選ぶべきか？

最適な対応方法は、前述のテストの目的が「目的Aなのか、目的Bなのか」と、許容できるリスクレベル（テスト中の無防備状態を許容できるかどうか）、そして運用負荷（設定変更・管理の手間）を総合的に判断し、決定することになります。

それぞれの状況に応じた指針を、以下にまとめます。

  • セキュリティリスクとテスト網羅性のバランスを最も重視するなら、対応方法4（Allow List - IP）が、送信元 IP アドレスが固定できる場合の第一の選択肢です。
  • 送信元 IPアドレスが固定できない場合は、対応方法5（リクエスト識別子）が有効な代替策です。ただし、識別子の適切な管理や、テストツール側での確実なヘッダー付与といった運用上の準備や考慮が必要です。
  • アプリケーションの脆弱性を最優先で洗い出したい、かつ安全なテスト環境があるならば、対応方法2（デタッチ）も有効な選択肢です。
  • AWS WAF ルールのチューニングも兼ねたい場合は、リスクを理解した上で対応方法3（COUNTモード）を検討できますが、本番環境での実施においては慎重な判断が必要です。
  • AWS WAF 込みの現状の防御力を評価したいのであれば、対応方法1（WAF を有効のまま保持）が適しています。

その他の重要な考慮事項

どの対応方法を選択するにしても、以下の点は共通して重要となるため、合わせてご確認ください。

  • テスト環境の活用
    • 可能であれば、本番環境と同一構成を持つステージング環境などを用意し、その環境でペネトレーションテストを実施することが最も安全で、理想的です。
  • AWS への事前申請 (必要な場合)
  • 設定変更と復旧
    • 一時的な設定変更（対応方法2, 3, 4, 5）を行う場合は、テスト計画段階で詳細な手順と復旧手順を確立しておき、テスト完了後に確実に元の状態に戻す必要があります。
    • 特に本番環境での作業においては、ダブルチェック体制を取るだけでなく、設定変更前後のスクリーンショットや設定内容を記録しておくことが推奨されます。
  • ログの分析
    • テスト期間中の AWS WAF ログ（アクセスログ、ルールヒットログ）を収集・分析することは非常に有益です（※対応方法2を除きます）。
    • AWS WAF のログ分析は必須ではありませんが、意図した通りに動作しているか、予期せぬブロックが発生していないか、不審なアクセスがないかなどを確認し、WAF ルールの有効性や改善点を見つけることに繋がる可能性があります。
  • ペネトレーションテスト中のアラート対応と事前準備
    • 特に対応方法1において、ペネトレーションテスト中は AWS WAF でのブロックの通知が頻発する可能性があります。
    • 加えて、CloudFront 等アプリケーション側のログも瞬間的に増加する傾向があるため、必要以上のアラートが発生する可能性があります。
    • ペネトレーションテストの実行タイミングでは通知を減らす、もしくは静観とする、社内に事前告知するなど十分な準備が必要です。

WafCharm の場合に設定で気を付けたいこと

AWS WAF で WafCharm をご利用されている場合に考慮すべき点がありますため、2点記載します。

なお、以下のブログに則って「Advanced Rule ポリシー」の WafCharm を前提として記載しています。

blog.serverworks.co.jp

WafCharm での Allowリストの設定方法 (対応方法4 を選択した場合)

「対応方法4: WAF の Allow List (IP 許可リスト) を使用する」を選択した場合の、WafCharm における設定箇所を記載します。

Allowリスト

WafCharm では「ルール設定」>「IPアドレス」>「IPアドレスベースのルール制御」において「Allowリスト」の記載が可能です。

このリストに画像のようにテスターの送信元 IP アドレスをそれぞれ記載し、更新のために「登録」を押下して完了します。

AWS WAF ではどのように反映されるのか？

WafCharm ではデフォルトで、優先度 (Priority) が上から2番目に高いルールグループである「WafCharm_Bypass_」からはじまるルールグループの中に追加されます*3。

WafCharm_Bypass_ ルールグループ

またそのルールグループの中には「WafCharm_AllowIps_」から始まるルールが含まれます。その中にはさらに「WafCharm_AllowIps_」から始まる AWS WAF IP セットが設定されています。

対応方法4 で「ルールの優先度（Priority）を他のブロック/カウントするルールよりも高く（数値が最も小さいか 0 を指定）設定する必要があります」と記載した通り、本ルールグループの優先度は「高く設定されている」必要があります。

念のために、WafCharm の設定を行うだけではなく、その「Allowリスト」が想定通りの優先度となっているのか、AWS WAF の設定画面からも合わせて確認することを推奨します。

重要: WafCharm での 例外IPリストの設定方法 (対応方法1 を選択した場合)

「対応方法1: WAF を有効にしたままテストを行う」を選択した場合の、WafCharm における関連した設定について説明します。

WafCharm には「例外設定」という項目が用意されています。本項目を WafCharm 公式ドキュメントより引用します。

WafCharmには、お客様から提供されるログに対して再マッチングをし、動的にIPアドレスをDenylistに追加する機能を提供しています。

リクエストがシグネチャにマッチした際にIPアドレスがDenylistに登録される仕組みとなりますので、もしお客様管理のIPアドレスなどで、他のWafCharmルールでは検査したいが、Denylistには登録したくないものがある場合には、あらかじめ例外設定を行うことで、そのIPアドレスがDenylistに登録されてしまうことを回避できます。

https://console.wafcharm.com/ja/help/configuring_rule_settings_aws_v2_ja

読んだ通りの機能ではあるのですが、少々わかりにくいかもしれません。

WafCharm は「ログを分析して動的にDenyリストへ IP アドレスを追加する」という機能を保持しています。

本機能は便利な反面、ペネトレーションテストのように意図的に多数のシグネチャに合致する可能性のあるリクエストを短時間に送信する場合、テスターの送信元 IP アドレスが意図せず WafCharm の動的Denyリストに登録されてしまうということが起こり得るということです。

本例外設定は「Allowリスト」とは異なります。「Allowリスト」はいつどんな時でも許可されバイパスされる IP アドレスのリストです。「例外設定」における「例外IPリスト」は「WAF のルールでブロックはされるものの、動的Denyリストには登録されないようにする」という機能です。この2つの機能は正しく理解し、使いこなす必要があります。

「例外設定」における「例外IPリスト」の設定画面は以下の通りです。

例外IPリスト

以下に公式ドキュメントから引用した制限及び注意事項を記載します。合わせて確認してください。

  • 複数のIPアドレスを登録する場合は、半角カンマあるいは改行で区切ってください。
  • 登録可能数は、最大1000件です。
  • IPアドレスはCIDRでの指定も可能です。指定可能なCIDRは、/1 ~ /32 です。
  • IPv6 には対応しておりません。
  • CIDR の指定が無い場合は、/32 として処理されます。

まとめ

本ブログでは「AWS WAF 適用環境におけるペネトレーションテストの目的2つと、それに応じた対応方法5つを整理して記載しました。

  • 目的A: WAF を含めたシステム全体の防御能力を評価したい
    • 対応方法1: WAF を有効にしたままテストを行う
  • 目的B: ウェブアプリケーション固有の脆弱性を明らかにしたい
    • 対応方法2: WAF を一時的にデタッチしてテストを行う
    • 対応方法3: WAF でルールを COUNT モードに変更する
    • 対応方法4: WAF の Allow List (IP 許可リスト) を使用する
    • 対応方法5: 特定のテストリクエスト識別子で除外する

また、WafCharm を利用している場合の考慮事項についても合わせて述べ、特に「例外IPリスト」の設定については詳しく利用方法を説明しました。

対応方法4 (再掲)

AWS WAF が適用された環境でのペネトレーションテストは、その目的やリスク許容度に応じて適切な対応方法を選択することが鍵となります。多くの場合、「対応方法4（Allow List - IP）」が、セキュリティリスクを管理しつつ効果的なテストを実施するための有効な選択肢です。

加えて、目的A (WAF の効果を含める)、目的B (WAF の効果を含めない)のどちらのテストもクリアされたい場合には、「対応方法4（Allow List - IP）」の後に、さらに「対応方法1（WAF を有効のまま保持）」のペネトレーションテストを組み合わせて実行する必要があるでしょう。実際に、このような組み合わせでの段階を踏んだペネトレーションテストの対応を行った経験もあります。

最後に、どのような方法でペネトレーションテストを進めるにしても、事前の計画、関係者との連携、リスクの正確な評価、そしてテスト後の確実な設定復旧プロセスを徹底し、安全かつ効果の高いペネトレーションテストを実施してください。

では、またお会いしましょう。

*1:ペネトレーションテストとは、サイバー攻撃を実際に試行したり、システムへの侵入等を試みたりすることで、テスト対象サービスのセキュリティレベルを評価する取り組みのことです

*2:参考ブログ: AWS WAF の COUNT モードのログをクエリする時に httprequest の host を取得したい https://blog.serverworks.co.jp/aws-waf-count-mode-logs-get-host

*3:Bot ルール設定を有効にしている場合を想定しています。Bot ルールが存在しない場合、優先度は異なります

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。