AWS WAFをAPI Gatewayに設定する方法について

AWS WAFをAPI Gatewayに設定すると、APIに到達する前の段階で不審なリクエストや攻撃リクエストを検査・ブロックできます。

SQLインジェクション、クロスサイトスクリプティング、既知の悪性IPからのアクセス、過剰なリクエストなどを制御できるため、公開APIの防御層として有効です。

ただし、API Gatewayの種類によってAWS WAFの設定方法は異なります。

特に重要なのは、AWS WAFを直接関連付けできるのは、基本的にAPI GatewayのREST APIステージであるという点です。

HTTP APIを利用している場合は、REST APIと同じ方法ではWAFを直接設定できないため、CloudFrontを前段に置いてCloudFrontにAWS WAFを関連付ける構成を検討します。

AWS WAFとAPI Gatewayの関係

AWS WAFとは

AWS WAFは、WebアプリケーションやAPIを一般的な攻撃から保護するためのWebアプリケーションファイアウォールです。

リクエストの送信元IP、国・地域、HTTPヘッダー、URI、クエリ文字列、リクエストボディなどを条件にして、許可、ブロック、カウントなどのアクションを実行できます。

API GatewayにAWS WAFを関連付けることで、API GatewayのバックエンドにあるLambda、HTTPエンドポイント、AWSサービスなどにリクエストが到達する前に、不審なアクセスを遮断できます。

API GatewayでWAFを使うメリット

API GatewayにAWS WAFを設定する主なメリットは、攻撃リクエストをアプリケーション側に到達させずに止められることです。

たとえば、明らかなSQLインジェクションのようなリクエストや、短時間に大量のアクセスを行うIPアドレスからのリクエストを、バックエンド処理の前にブロックできます。

その結果、セキュリティ強化だけでなく、Lambdaやバックエンドサーバーの負荷軽減、不要な処理コストの削減にもつながります。

API Gatewayの種類による違い

REST APIの場合

API GatewayのREST APIでは、AWS WAFのWeb ACLをステージ単位で関連付けできます。

たとえば、REST APIに本番用の「prod」ステージがある場合、そのステージに対してAWS WAFのWeb ACLを関連付けます。

これにより、「prod」ステージへ送られるリクエストがWAFのルールで検査されます。

重要なのは、WAFはAPI全体ではなくステージ単位で関連付けるという点です。

そのため、開発環境、本番環境、検証環境で異なるWAFルールを適用することもできます。

HTTP APIの場合

HTTP APIには、REST APIのようにAWS WAFを直接関連付けることはできません。

HTTP APIをWAFで保護したい場合は、一般的にCloudFrontをAPI Gatewayの前段に配置し、CloudFrontにAWS WAFを関連付けます。

この場合の構成は、ユーザーからのアクセスがCloudFrontに入り、CloudFrontでWAFの検査を受けたうえで、API Gateway HTTP APIへ転送される形になります。

ただし、この構成では注意が必要です。

API Gatewayの標準エンドポイントに直接アクセスされると、CloudFrontとWAFを迂回される可能性があります。

そのため、CloudFrontからAPI Gatewayへ送るリクエストに専用ヘッダーを付与し、API Gateway側やバックエンド側でそのヘッダーを検証するなど、直接アクセスを拒否する仕組みを組み合わせる必要があります。

API GatewayにAWS WAFを設定する流れ

REST APIであることを確認する

まず、対象のAPI GatewayがREST APIであることを確認します。

AWS WAFをAPI Gatewayに直接関連付けたい場合、対象はREST APIのステージです。

HTTP APIの場合は直接関連付けできないため、CloudFrontを前段に置く構成を検討します。

API Gatewayの管理画面で対象APIを開き、APIタイプがREST APIかHTTP APIかを確認しましょう。

Web ACLを作成する

次に、AWS WAFでWeb ACLを作成します。

Web ACLとは、WAFのルールをまとめた設定単位です。

どのリクエストを許可するのか、どのリクエストをブロックするのか、どのリクエストをログとしてカウントするのかを定義します。

API Gateway REST APIに関連付ける場合は、CloudFront用ではなく、Regional resources用のWeb ACLを作成します。

API Gatewayと同じリージョンにWeb ACLを作成する点に注意してください。

たとえば、API Gatewayが東京リージョンにある場合、AWS WAFのWeb ACLも東京リージョンのRegional Web ACLとして作成します。

ルールを追加する

Web ACLを作成したら、必要なルールを追加します。

最初から複雑なカスタムルールを作るよりも、まずはAWS Managed Rulesを利用するのがおすすめです。

AWS Managed Rulesは、AWSが提供するマネージドルールセットで、一般的なWeb攻撃や既知の悪性リクエストに対応しやすくなっています。

代表的なルールには、一般的なWeb攻撃を検出するルール、SQLインジェクションを検出するルール、既知の悪性IPを検出するルール、異常な入力値を検出するルールなどがあります。

また、APIでは短時間の大量アクセスを制限するために、レートベースルールを設定することもよくあります。

最初はCountモードで確認する

WAFのルールをいきなりBlockにすると、正常なリクエストまでブロックしてしまう可能性があります。

そのため、本番環境に導入する際は、まずCountモードで動かすのが安全です。

Countモードでは、ルールに一致したリクエストをブロックせず、ログやメトリクスで確認できます。

Countモードで一定期間運用し、正常なリクエストが誤検知されていないかを確認します。

問題がなければ、対象ルールをBlockに変更します。

特にAPIでは、JSON、HTML断片、SQLに似た文字列、Base64、JWT、長いクエリ文字列などがリクエストに含まれることがあります。

これらがWAFのルールに誤検知される場合があるため、Countモードでの確認は重要です。

API Gatewayのステージに関連付ける

Web ACLの作成とルール設定が完了したら、API GatewayのREST APIステージにWeb ACLを関連付けます。

API Gatewayの管理画面で対象のREST APIを開き、対象ステージを選択します。

ステージ設定の中でAWS WAFのWeb ACLを選択し、関連付けを保存します。

これで、そのステージに送られるリクエストがAWS WAFによって検査されるようになります。

設定時に重要なポイント

Web ACLはRegionalを選ぶ

API Gateway REST APIにAWS WAFを直接関連付ける場合、Web ACLはRegionalで作成します。

CloudFront用のWeb ACLは、API GatewayのREST APIステージに直接関連付ける用途ではありません。

CloudFrontに対してWAFを設定する場合はCloudFront用のWeb ACLを使いますが、API Gateway REST APIに直接関連付ける場合はRegional Web ACLを使います。

この違いは非常に重要です。

リージョンやスコープを間違えると、対象のAPI GatewayステージにWeb ACLを関連付けられません。

API GatewayとWAFのリージョンを合わせる

API Gateway REST APIに関連付けるWeb ACLは、API Gatewayと同じリージョンに作成します。

たとえば、API Gatewayが東京リージョンにある場合は、AWS WAFのWeb ACLも東京リージョンに作成します。

大阪リージョンのAPI Gatewayを保護する場合は、大阪リージョンのRegional Web ACLを作成します。

CloudFront用WAFとは考え方が異なるため、混同しないように注意が必要です。

WAFは認証より前に評価される

AWS WAFは、API Gatewayの認証・認可処理よりも前に評価されます。

つまり、WAFでブロックされたリクエストは、API Gatewayのリソースポリシー、IAM認証、Lambdaオーソライザー、Cognitoオーソライザーなどに到達しません。

これは、攻撃リクエストを早い段階で遮断できるというメリットがあります。

一方で、WAFでブロックされたリクエストは、バックエンドや認証処理側のログには残らない可能性があります。

そのため、WAFログを有効化して、どのルールでブロックされたのかを確認できるようにしておくことが重要です。

WAFは認証の代わりではない

AWS WAFはセキュリティ対策として有効ですが、認証や認可の代わりにはなりません。

WAFは、悪意のあるリクエストや不審なアクセスパターンを検出・制御するための仕組みです。

一方で、誰がAPIを利用できるのか、どの操作を許可するのかといった制御は、IAM認証、Cognito、JWTオーソライザー、Lambdaオーソライザー、APIキー、Usage Planなどで実装する必要があります。

APIを安全に公開するには、WAF、認証、認可、レート制限、ログ監視を組み合わせて設計することが大切です。

リクエストボディ検査サイズの注意点

デフォルトは16KB

API GatewayにAWS WAFを設定する場合、リクエストボディ検査サイズにも注意が必要です。

AWS WAFでは、API Gatewayに対するリクエストボディを検査できますが、デフォルトで検査されるのは先頭16KBです。

つまり、リクエストボディ全体が常に検査されるわけではありません。

以前は「最大64KBまで検査できる」とだけ説明されることがありますが、正確には、デフォルトは16KBで、設定によって最大64KBまで拡張できます。

最大64KBまで拡張できる

リクエストボディ検査サイズは、16KB、32KB、48KB、64KBのように段階的に設定できます。

ただし、64KBは最大値です。64KBを超えるリクエストボディについては、WAFがすべての内容を検査できるわけではありません。

そのため、大きなJSONやファイルアップロード、大容量のWebhookペイロードなどを扱うAPIでは、WAFだけに頼らず、バックエンド側での入力検証も必要です。

また、デフォルトサイズを超える検査を有効にする場合は、追加料金が発生する可能性があります。

運用コストの観点でも、必要な検査サイズを見極めることが重要です。

大きなリクエストを扱うAPIでは特に注意する

APIでは、通常のWebページよりも大きなリクエストボディを扱うケースがあります。

たとえば、フォームデータ、JSONの配列、複雑な検索条件、外部サービスからのWebhook、Base64化されたデータなどです。

これらのリクエストがWAFの検査サイズを超える場合、WAFで検査できない部分が発生します。

そのため、重要な入力検証はWAFだけに任せず、アプリケーション側でも必ず実施する必要があります。

よく使われるWAFルール

AWS Managed Rules

初めてAWS WAFをAPI Gatewayに導入する場合は、AWS Managed Rulesを利用するのが現実的です。

AWS Managed Rulesには、一般的な脆弱性を狙う攻撃、既知の不正な入力、SQLインジェクション、悪性IPからのアクセスなどに対応するルールセットがあります。

これらを利用することで、ゼロからすべての検知ルールを作成する必要がなくなります。

ただし、Managed Rulesでも誤検知が発生する可能性はあるため、最初はCountモードで導入し、ログを確認しながらBlockへ移行するのが安全です。

レートベースルール

API Gatewayでは、短時間に大量のアクセスが来ることがあります。

攻撃だけでなく、クローラー、Bot、誤ったクライアント実装、リトライ処理の暴走などでもリクエスト数が急増することがあります。

このようなケースに備えて、レートベースルールを設定すると効果的です。

レートベースルールでは、一定期間内に特定のIPアドレスから送信されたリクエスト数をもとに、しきい値を超えたアクセスをブロックできます。

ただし、しきい値はAPIの性質によって変わります。

管理画面向けAPI、一般ユーザー向けAPI、公開API、Webhook受信用APIでは、適切な値が異なります。

まずはログやメトリクスを見ながら、通常時のアクセス量を把握したうえで設定するのが安全です。

IP制限

管理用APIや社内向けAPIでは、IP制限が有効です。

特定の固定IPアドレスや社内ネットワークからのみアクセスを許可し、それ以外をブロックすることで、不特定多数からのアクセスを防げます。

ただし、利用者がモバイル回線や動的IPを使う場合、IP制限の運用が難しくなることがあります。

また、外部SaaSやWebhook送信元のIPアドレスが変わる可能性もあるため、許可リストの管理方法を事前に決めておく必要があります。

国・地域による制限

日本国内向けのAPIで、海外からのアクセスが不要な場合は、国・地域による制限を検討できます。

ただし、国・地域制限は誤判定や運用上の問題もあります。

海外出張中の正規ユーザー、VPNを利用するユーザー、海外SaaSからのWebhookなどが影響を受ける可能性があります。

そのため、最初からBlockにするのではなく、まずCountモードで海外からのアクセス状況を把握し、本当にブロックして問題ないかを確認するのがおすすめです。

ログと監視の設定

WAFログを有効化する

AWS WAFをAPI Gatewayに設定したら、WAFログを有効化することをおすすめします。

WAFログを確認すると、どのリクエストがどのルールに一致したのか、許可されたのか、ブロックされたのか、Countされたのかを把握できます。

特に導入初期は、誤検知の有無を確認するためにログが重要です。

正常なユーザーのリクエストがブロックされていないかを確認しながら、ルールの除外設定や優先順位を調整します。

API Gatewayのアクセスログも確認する

WAFログだけでなく、API Gatewayのアクセスログもあわせて確認します。

API Gatewayのアクセスログでは、ステータスコード、レイテンシ、リクエストパス、送信元情報などを確認できます。

WAFでブロックされたリクエストはAPI Gatewayの処理に進まない場合があるため、WAFログとAPI Gatewayログを組み合わせて見ることが重要です。

CloudWatch Metricsで傾向を見る

AWS WAFやAPI GatewayのメトリクスをCloudWatchで監視すると、許可リクエスト数、ブロックリクエスト数、特定ルールへの一致数などを把握できます。

ブロック数が急増した場合は、攻撃が発生している可能性もあります。

一方で、設定変更後にブロック数が急増した場合は、誤検知が増えている可能性もあります。

運用では、単にブロック数を見るだけでなく、どのルールでブロックされているのか、正常ユーザーへの影響がないかを確認する必要があります。

HTTP APIを保護する場合の考え方

CloudFrontを前段に置く

HTTP APIにAWS WAFを直接関連付けることはできないため、WAFを使いたい場合はCloudFrontを前段に置く構成が一般的です。

CloudFrontにAWS WAFを関連付け、CloudFrontからAPI Gateway HTTP APIへリクエストを転送します。

これにより、クライアントからのアクセスはCloudFrontでWAFの検査を受けたうえでAPI Gatewayへ到達します。

API Gatewayへの直接アクセスを防ぐ

CloudFrontとWAFを設定しても、API Gatewayの標準エンドポイントに直接アクセスできる状態だと、WAFを迂回される可能性があります。

そのため、CloudFrontからAPI Gatewayへ送るリクエストに専用のヘッダーを付与し、API Gateway側またはバックエンド側でそのヘッダーを検証する方法があります。

ヘッダーがないリクエストを拒否することで、CloudFrontを経由していないアクセスをブロックしやすくなります。

ただし、単純な固定ヘッダーだけでは漏えい時にリスクがあるため、認証・認可、署名検証、JWT、Lambdaオーソライザーなどを組み合わせた設計が望ましいです。

導入時のおすすめ構成

最初はシンプルなルールから始める

AWS WAFをAPI Gatewayに導入する際は、最初から複雑なルールを大量に入れるよりも、基本的なルールから始めるのがおすすめです。

まずは、AWS Managed Rules、既知の悪性IP対策、SQLインジェクション対策、レート制限などを中心に設定します。

そのうえで、WAFログを見ながら、誤検知や不足している防御を確認します。

CountからBlockへ段階的に移行する

本番環境では、最初からBlockにするのではなく、Countで一定期間観察するのが安全です。

Countで検知状況を確認し、正常なリクエストがルールに引っかかっていないことを確認したうえでBlockに変更します。

誤検知がある場合は、特定のルールを除外したり、対象パスだけルールを緩和したり、条件を追加したりして調整します。

本番前にステージング環境で確認する

可能であれば、本番環境に適用する前にステージング環境で同じWAF設定を検証します。

API Gateway REST APIではステージ単位でWAFを関連付けできるため、ステージング用ステージに先にWeb ACLを適用し、動作を確認できます。

ただし、ステージング環境と本番環境でリクエストの量や内容が異なる場合、本番で初めて誤検知が見つかることもあります。

そのため、本番導入後もしばらくはログを重点的に確認する必要があります。

よくある注意点

REST APIとHTTP APIを混同しない

AWS WAFをAPI Gatewayに設定する際によくある間違いは、REST APIとHTTP APIを混同することです。

REST APIであればステージにWeb ACLを直接関連付けできます。

一方、HTTP APIでは同じ方法が使えません。

まず対象のAPIタイプを確認し、そのうえで直接関連付けできるのか、CloudFrontを使う必要があるのかを判断しましょう。

CloudFront用WAFとRegional WAFを混同しない

API Gateway REST APIに直接WAFを関連付ける場合はRegional Web ACLを使います。

CloudFront用のWeb ACLは、CloudFrontディストリビューションに関連付けるものです。

API Gateway REST APIのステージに直接関連付けるものではありません。

スコープを間違えると設定時に対象リソースが選択できないため、Web ACL作成時に必ず確認しましょう。

WAFだけでAPIを守ろうとしない

WAFは重要な防御層ですが、万能ではありません。

APIのセキュリティでは、WAFに加えて、認証、認可、入力検証、レート制限、ログ監視、エラーハンドリング、バックエンド側のバリデーションを組み合わせる必要があります。

特に、WAFが検査できるリクエストボディサイズには上限があるため、大きなペイロードを扱うAPIではアプリケーション側の検証が不可欠です。

まとめ

AWS WAFをAPI Gatewayに設定する場合、まず対象のAPIタイプを確認することが重要です。

REST APIであれば、API GatewayのステージにRegional Web ACLを直接関連付けできます。

このとき、Web ACLはAPI Gatewayと同じリージョンに作成し、CloudFront用ではなくRegional用を選びます。

HTTP APIの場合はAWS WAFを直接関連付けできないため、CloudFrontを前段に置き、CloudFrontにWAFを関連付ける構成を検討します。

ただし、API Gatewayの標準エンドポイントへ直接アクセスされるとWAFを迂回される可能性があるため、直接アクセスを防ぐ設計が必要です。

また、WAFのルールは最初からBlockにするのではなく、Countモードで誤検知を確認してから段階的にBlockへ移行するのが安全です。

特に注意すべき点は、リクエストボディ検査サイズです。

API Gatewayに対するWAFのリクエストボディ検査は、デフォルトでは16KBで、設定により最大64KBまで拡張できます。

64KBを超える部分はWAFで検査できないため、バックエンド側の入力検証も必ず行いましょう。

AWS WAFはAPI Gatewayのセキュリティを高める有効な手段ですが、認証や認可の代わりではありません。

WAF、認証、認可、ログ監視、バックエンド側のバリデーションを組み合わせることで、より堅牢なAPI保護を実現できます。

以上、AWS WAFをAPI Gatewayに設定する方法についてでした。

最後までお読みいただき、ありがとうございました。