yagibrary
← 記事一覧に戻る
公開日: 2026-06-09

AWSのWeb防壁！「AWS WAF」とは？初心者向けに概念から設定方法まで図解でわかりやすく解説

AWS WAF セキュリティ 初心者向け AWS入門

Webアプリケーションを悪意あるサイバー攻撃から守る最重要サービス「AWS WAF」を初心者向けに解説。仕組みやメリット・デメリットから、Web ACLやルールなどの4大基本要素、JSONによるルール記述の分解解説、誤検知を防ぎ安全に運用するためのベストプラクティスまで、図解を交えて分かりやすく紹介します。

AWSのWeb防壁！「AWS WAF」とは？初心者向けに概念から設定方法まで図解でわかりやすく解説

「Webサイトやアプリを公開したいけれど、サイバー攻撃からどうやって守ればいいかわからない…」 「『WAF（ワフ）』という言葉は聞くけれど、具体的にどんな仕組みなのかイメージできない…」

AWS上でWebサービスを公開する際、避けて通れない最重要セキュリティサービスが**AWS WAF（Web Application Firewall）**です。 AWS WAFは、SQLインジェクションやクロスサイトスクリプティング（XSS）といったWebアプリケーション特有の攻撃からシステムを守る盾の役割を果たします。しかし、その概念や設定方法は初心者にとって少し難解に感じられるかもしれません。

そこでこの記事では、AWS WAF of 概要からメリット・デメリット、4つの重要構成要素、および具体的なルールの書き方まで、図解を交えてわかりやすく解説します。

この記事を読めば、AWS WAF of 全体像がすっきりと理解でき、安全にWebサイトを公開するための第一歩を踏み出せるようになります。

AWS WAF（ワフ）とは？

AWS WAF（Web Application Firewall）とは、**「誰が（どのIPが）」「どのようなリクエストで」「どのWebアプリケーション（リソース）にアクセスできるか」**を動的にチェックし、悪意ある通信を遮断するためのWebアプリケーションファイアウォールです。

通常のネットワークファイアウォール（セキュリティグループなど）は、IPアドレスやポート番号（送信元・送信先）といった比較的浅いネットワークレイヤーでアクセスを制御します。しかし、WAFはHTTP/HTTPSリクエストの中身（ペイロード）まで深く解析し、不正なプログラムやパラメータが含まれていないかを確認します。

AWS WAFは、CloudFront（CDN）やALB（Application Load Balancer）、API Gateway、AppSyncといった各種AWSリソースの前面に配置され、アクセス制限を行います。

AWS WAFによる通信制御の流れ

AWS WAFを理解する上で重要なのが、リクエストがアプリケーションに到達するまでの検査の流れです。

graph TD
    A[ユーザー / 攻撃者] -->|HTTPリクエスト送信| B("AWS WAF (Web ACL)")
    B -->|ルールとリクエストを照合| C{検査結果}
    C -->|攻撃を検知: BLOCK| D[403 Forbiddenで遮断]
    C -->|安全な通信: ALLOW| E["AWSリソース (ALB, CloudFrontなど)"]
    E -->|アプリケーション処理| F[正常な応答を返却]
  1. リクエスト受信：ユーザーまたは攻撃者からのアクセスが、AWS WAFが紐付くリソースに到達します。
  2. ルールの判定：あらかじめ設定された「ルール（ポリシー）」とリクエストの内容を照合します。
  3. 制御の実行：悪意あるリクエストであれば即座に通信を遮断（BLOCK）し、安全なリクエストであれば背後のアプリケーションへ処理を通します（ALLOW）。

AWS WAFはこの一連の処理を、ほぼ遅延なく実行します。

AWS WAFのメリット・デメリット

AWS WAFを利用するメリットと、導入時に直面しやすい課題（デメリット）を整理しました。

メリット

  • AWSマネージドルールによる容易な運用 AWSやセキュリティベンダーが作成した、最新の脅威情報に基づいて自動更新される**「AWS Managed Rules」**が用意されています。これにより、専門知識がなくてもすぐに高いセキュリティレベルを確保できます。
  • シンプルな導入と柔軟なスケーリング インフラの変更（ハードウェアの調達や専用の仮想マシンの構築など）が不要で、AWSコンソールから数クリックで導入できます。また、トラフィック量に応じて自動でスケーリングします。
  • 低コスト（使った分だけの従量課金） 初期費用は不要で、作成したWeb ACLの数、設定したルールの数、および処理したリクエスト数に応じたシンプルな従量課金制となっています。
  • リアルタイムの可視化とログ出力 ブロックされたアクセスやリクエストの詳細を CloudWatch や Kinesis Firehose 経由でログ保存し、どのIPからどのような攻撃が来ているかをダッシュボードで即座に分析できます。

デメリット・注意点

  • 「誤検知（False Positive）」による正常なアクセスのブロック WAFの検知ルールが厳しすぎると、ECサイトでの通常の購入操作や、ログインフォームへの入力といった正常なリクエストまで「攻撃」と誤認してブロックしてしまうことがあります。
  • コストの管理 リクエスト数に比例して課金されるため、数千万〜数億リクエストが恒常的に発生する大規模なシステムや、DDoS攻撃を受けてリクエスト数が急増した際には、想定以上のコストが発生する可能性があります。

AWS WAFを構成する「4つの基本要素」

AWS WAFをマスターするための最大の鍵は、**「Web ACL」「ルール」「ルールグループ」「アタッチ対象のリソース（Web ACL Associations）」**という4つの構成要素の関係性をマスターすることです。

それぞれの関係を図に表すと以下のようになります。

graph TD
    subgraph WebACL["Web ACL (Webアクセス制御リスト)"]
        Rule1["ルール1: IP制限ルール"]
        subgraph Group["ルールグループ: AWSマネージドルール"]
            Rule2["SQLインジェクション対策"]
            Rule3["既知の不正IPからの保護"]
        end
    end

    WebACL -->|アタッチ| ALB["ALB (ロードバランサー)"]
    WebACL -->|アタッチ| CF["CloudFront (CDN)"]
    WebACL -->|アタッチ| APIGW["API Gateway"]

それでは、各要素について詳しく見ていきましょう。

1. Web ACL (Web Access Control List)

AWS WAFの**設定をまとめる最上位の入れ物（コンテナ）**です。 保護対象のリソースに対して、この「Web ACL」を1つだけアタッチします。内部に複数のルールを格納し、優先順位を決めて実行します。

  • 用途：特定のシステム全体（例えば、本番環境のALB用、検証環境用など）のセキュリティ設定をグループ化する場合。

2. ルール (Rule)

**「どのようなリクエストを対象にし（条件）」「それに合致したときにどのような処理を行うか（アクション）」**を定義した最小単位のルールです。 アクションには、通す（ALLOW）、ブロックする（BLOCK）、カウントする（COUNT）、あるいは独自のレスポンスを返す（CAPTCHA / Challenge）があります。

  • 用途：「特定の特定の国からのアクセスを遮断する」「攻撃とみなされる文字列が含まれている場合に検知する」などの個別の条件を記述する場合。

3. ルールグループ (Rule Group)

複数のルールをセットにして再利用しやすくしたコレクションです。 AWSが公式に提供する「AWSマネージドルール」や、サードパーティがセキュリティマーケットプレイスで提供するルールは、このルールグループの形で提供されます。自作することも可能です。

  • 用途：OWASP Top 10（脆弱性）対策などの包括的な防御ルールを一括でWeb ACLに適用する場合。

4. 関連付けるリソース (Associations)

Web ACLによってセキュリティ防御を適用する具体的なAWSリソースです。 現在、以下のリソースにアタッチ可能です：

  • Amazon CloudFront（グローバルに配信する静的サイトやAPIの防御）
  • Application Load Balancer (ALB)（EC2やFargate上のWebアプリの防御）
  • Amazon API Gateway（サーバーレスAPI of 防御）
  • AWS AppSync（GraphQL API of 防御）

【実践】WAFルールの設定方法（JSON）を見てみよう

AWS WAFのルールは、コンソールのUIからビジュアルに作成できるほか、JSON形式で記述・管理することもできます。 以下は、**「特定のIPアドレスリスト（IPセット）からのアクセスのみを許可（または拒否）する」**ルールの記述例です。

{
  "Name": "IPRestrictionRule",
  "Priority": 0,
  "Statement": {
    "IPSetReferenceStatement": {
      "ARN": "arn:aws:wafv2:ap-northeast-1:123456789012:regional/ipset/MyOfficeIPs/a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d"
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "IPRestrictionRuleMetric"
  }
}

ルールを紐解く重要キーワード

JSON内の構成は、主に以下の要素で成り立っています。これを**「4つの重要要素」**と整理すると理解しやすいです。

キーワード意味具体的な記述例
Nameルールの一意な名前IPRestrictionRule
Priorityルールが評価される優先順位0 (数字が小さいほど先に評価される)
Statement判定基準（どの条件に合致するか）IPSetReferenceStatement（特定のIPセットに合致するか）
Action条件に合致した際のアクションBlock（アクセスを拒否する） または Allow（許可する）

上記のルールコードでは、「MyOfficeIPs」というIPセットに含まれるアクセス元からのHTTPリクエストを「ブロック（Block）」する、という意味になります。

AWS WAF 安全運用のためのベストプラクティス

WAFを導入するだけで満足していると、誤検知による業務トラブルや、思わぬコストの増加につながります。初心者が必ず守るべき4つの運用ルールを紹介します。

1. 最初は必ず「COUNT」モードでテストする

WAFのルールを新しく本番に導入する際は、いきなり BLOCK（遮断）アクションを設定してはいけません。 まずは**「COUNT」モード（遮断はせず、ログ検知だけを行うモード）**で数日から1週間ほど運用し、正常なユーザーのアクセスが誤って引っかかっていないか（誤検知の有無）をログで確認した上で、安全に BLOCK に移行しましょう。

2. マネージドルールを賢く組み合わせる

WAFルールを一から自作するのは非常にハードルが高いです。 まずはAWSが標準提供している 「AWS Managed Rules（コアルールセット：CRS）」 を導入しましょう。これだけでSQLインジェクションや代表的なWebの脆弱性の大部分を防ぐことができます。必要に応じて、特定のOSやデータベースに特化したルールを追加していきます。

3. コスト削減のために前面でCloudFrontを活用する

AWS WAFの課金には「処理されたリクエスト数」が含まれます。 悪意ある大量アクセス（DDoS攻撃など）が直接アプリケーションサーバーに到達すると、WAFのコストが跳ね上がります。Webサイトの前面に Amazon CloudFront を配置し、そこでWAFを適用することで、CloudFrontのキャッシュ効果により不要なリクエスト数を大幅に削減し、WAFのコストも抑えることができます。

4. ログを保存し定期的に分析する

WAFが「どのリクエストを」「なぜブロックしたのか」を追跡するために、ログ出力（WAF Logging）を有効化しましょう。 CloudWatch Logs や S3 にログを保存することで、攻撃の傾向分析や、システムで不具合が生じた際の「WAFによる意図しないブロックが原因かどうか」の調査が迅速に行えます。

まとめ：Webアプリの盾はWAFにあり！

AWS WAFの重要ポイントを振り返りましょう。

  1. WAFは、HTTPリクエストの内容を検査し、Webアプリケーションへの攻撃を防ぐ盾
  2. 基本は「Web ACL」「ルール」「ルールグループ」「関連付けるリソース」の4つ
  3. ルールはコンソールまたはJSONで定義し、優先順位（Priority）順に評価される
  4. 導入時は「COUNT」モードで誤検知を防ぎ、マネージドルールを活用する

AWSでWebサービスを全世界に向けて公開する際、WAFを適切に設定することは、大切なデータとユーザーを守るための「防犯ロック」のようなものです。

次のステップとして、実際にAWSコンソールにログインし、**「検証用のWeb ACLを1つ作成し、AWSマネージドルールをアタッチして、自分のIPアドレスだけを一時的にブロックしてみる」**という作業にぜひ挑戦してみてください。身をもってブロックされる動き（403エラー）を体験することで、その効果と動作の仕組みが深く実感できます。

この記事をシェアする