AWS WAFでBasic認証をかける方法について

AWS WAFでBasic認証をかける方法として、Authorization ヘッダーを検査し、正しい認証情報が含まれていないリクエストをブロックする、という考え方は大筋で正しいです。

ただし、厳密にいうと、AWS WAFは認証機能そのものを提供するサービスではありません。

そのため、AWS WAFで行うのは「Basic認証そのもの」というより、Basic認証と同じ形式のAuthorizationヘッダーをWAFでチェックする簡易的なアクセス制御と考えるのが正確です。

検証環境、ステージング環境、公開前サイト、社内確認用ページなどを一時的に保護する用途であれば、AWS WAFだけでも十分実用的です。

一方で、会員ログインや管理者認証のように、本格的な認証・認可が必要な用途では、AWS WAF単体では不十分です。

AWS WAFでBasic認証相当の制御ができる理由

AWS WAFはリクエストヘッダーを検査できる

AWS WAFでは、HTTPリクエストのさまざまな要素を条件として検査できます。

たとえば、以下のような情報をチェックできます。

• リクエストヘッダー
• URIパス
• クエリ文字列
• HTTPメソッド
• Cookie
• リクエストボディ
• IPアドレス

Basic認証では、ブラウザやクライアントが Authorization ヘッダーに認証情報を付けてリクエストを送ります。

そのため、AWS WAFで Authorization ヘッダーの中身を検査すれば、Basic認証と同じようなアクセス制御ができます。

Basic認証ではAuthorizationヘッダーが使われる

Basic認証では、ユーザー名とパスワードを組み合わせた文字列をBase64形式に変換し、それを Authorization ヘッダーに入れて送信します。

AWS WAFでは、この Authorization ヘッダーの値が、あらかじめ設定した値と一致するかどうかを判定します。

正しい値であればアクセスを許可し、正しくなければブロックします。

つまり、AWS WAFで行う処理は次のようなイメージです。

「Authorizationヘッダーが正しいBasic認証の値と一致している場合だけ通す」

または、

「Authorizationヘッダーが正しいBasic認証の値と一致しない場合はブロックする」

という制御です。

AWS WAFでBasic認証を実装する基本的な考え方

正しいAuthorizationヘッダー以外をブロックする

AWS WAFでBasic認証相当の制御を行う場合、ルールの考え方は非常にシンプルです。

正しい認証情報が含まれているリクエストは許可し、それ以外はブロックします。

ただし、実際のWAFルールでは「正しいものを許可する」というよりも、「正しくないものをブロックする」という作り方にするのが一般的です。

なぜなら、初回アクセス時には、まだブラウザがAuthorizationヘッダーを送っていないからです。

そのため、AWS WAFでは次のような条件にします。

「Authorizationヘッダーが正しい値ではない場合にブロックする」

このように設定することで、Authorizationヘッダーがない初回アクセスもブロック対象になります。

ブロック時には401を返す

Basic認証としてブラウザに認証ダイアログを表示させるには、単にアクセスを拒否するだけでは不十分です。

通常のAWS WAFのブロックでは、デフォルトで403 Forbiddenが返されます。

しかし、Basic認証として動作させたい場合は、403ではなく401 Unauthorizedを返す必要があります。

401を返すことで、ブラウザは「認証が必要なページ」と判断します。

WWW-Authenticateヘッダーを返す必要がある

Basic認証のログインダイアログをブラウザに表示させるには、401ステータスに加えて、WWW-Authenticate ヘッダーも必要です。

このヘッダーがあることで、ブラウザはBasic認証の入力画面を表示します。

AWS WAFのカスタムレスポンスでは、ステータスコードだけでなくレスポンスヘッダーも設定できます。

そのため、ブロック時に401を返し、さらに WWW-Authenticate ヘッダーを付ければ、ブラウザ上でBasic認証のように動作させることができます。

AWS WAFでBasic認証をかける手順の流れ

ユーザー名とパスワードを決める

まず、Basic認証で使うユーザー名とパスワードを決めます。

このとき、ユーザー名とパスワードは推測されにくいものにする必要があります。

特にステージング環境や公開前サイトでは、簡単なID・パスワードを使い回してしまうケースがありますが、これは避けるべきです。

Basic認証は簡易的な保護手段であり、強固な認証基盤ではありません。

そのため、最低限、第三者に推測されにくい文字列を使うことが重要です。

ユーザー名とパスワードをBase64形式に変換する

Basic認証では、ユーザー名とパスワードを組み合わせた文字列をBase64形式に変換します。

AWS WAFでは、変換後の文字列をAuthorizationヘッダーの値として照合します。

ここで注意したいのは、Base64は暗号化ではないという点です。

Base64はあくまで文字列の変換形式であり、誰でも元の文字列に戻すことができます。

そのため、Base64化したから安全というわけではありません。

AWS WAFに設定する値や、TerraformなどのIaCに記述する値は、実質的に認証情報そのものとして扱う必要があります。

AWS WAFでAuthorizationヘッダーの条件を作る

次に、AWS WAFのWeb ACLにルールを追加します。

検査対象は Authorization ヘッダーです。

このヘッダーの値が、事前に用意したBasic認証用の値と一致するかどうかを判定します。

実際には、Authorizationヘッダーが正しい値と一致しない場合にブロックするルールを作ります。

このようにすることで、認証情報がないリクエストや、間違った認証情報を送ったリクエストを拒否できます。

ブロック時のレスポンスをカスタマイズする

AWS WAFでは、ブロック時のレスポンスをカスタマイズできます。

Basic認証のように動かすためには、ブロック時のレスポンスコードを401に変更します。

さらに、Basic認証を要求するためのレスポンスヘッダーを追加します。

この設定を行うことで、ブラウザで対象ページにアクセスしたときに、IDとパスワードの入力ダイアログが表示されるようになります。

AWS WAFでBasic認証をかける場合の正しい表現

「Basic認証を実装する」より「Basic認証相当の制御」が正確

AWS WAFで行っているのは、Basic認証のヘッダー値をチェックする処理です。

そのため、「AWS WAFでBasic認証を実装する」と表現しても大きく間違いではありませんが、より正確には「AWS WAFでBasic認証相当のアクセス制御を行う」と表現するのが適切です。

なぜなら、AWS WAFは認証サーバーではなく、ユーザー管理機能やパスワード管理機能を持っているわけではないからです。

AWS WAFでできるのは、あくまで「特定のAuthorizationヘッダーを持つリクエストだけ許可する」という制御です。

ユーザー管理やセッション管理はできない

AWS WAFを使ったBasic認証相当の制御では、ユーザーごとの管理は基本的にできません。

たとえば、以下のような機能はAWS WAF単体では実現しにくいです。

• ユーザーごとのID管理
• ユーザーごとのパスワード変更
• ログイン履歴の管理
• ログイン失敗回数の制限
• 多要素認証
• セッション管理
• 権限ごとのアクセス制御

そのため、社内確認用や一時的なアクセス制限には向いていますが、本格的なログイン機能として使うべきではありません。

AWS WAF方式が向いているケース

ステージング環境の保護

AWS WAFでBasic認証相当の制御を行う方法は、ステージング環境の保護に向いています。

たとえば、公開前のWebサイトをクライアントや社内メンバーだけに見せたい場合です。

ステージング環境は、本番環境ほど複雑な認証機能を必要としないことが多く、外部からの不用意なアクセスを防げれば十分なケースがあります。

このような場合、AWS WAFで簡易的なBasic認証を設定する方法は有効です。

公開前サイトの一時的なアクセス制限

Webサイトのリニューアル前やキャンペーンページの公開前など、一時的にアクセスを制限したい場面でもAWS WAF方式は使いやすいです。

アプリケーション側に認証機能を追加しなくても、WAF側でリクエストを止められるため、実装の負担を抑えられます。

特に、CloudFrontやALBの前段にAWS WAFを設定している構成であれば、比較的導入しやすい方法です。

特定パスだけを保護したい場合

AWS WAFでは、URIパスを条件に含めることができます。

そのため、サイト全体ではなく、特定のパスだけにBasic認証相当の制御をかけることも可能です。

たとえば、以下のようなパスを保護できます。

• 管理画面
• 社内向けページ
• 検証用ページ
• 公開前のLP
• 特定のディレクトリ配下

この場合は、URIパスの条件とAuthorizationヘッダーの条件を組み合わせます。

IP制限と併用したい場合

AWS WAFでは、IPアドレスによる制限も可能です。

そのため、社内IPからのアクセスは認証なしで許可し、それ以外のIPからのアクセスにはBasic認証を求める、といった制御もできます。

この構成は、ステージング環境や管理画面の保護でよく使われます。

たとえば、社内ネットワークやVPN経由のアクセスはそのまま許可し、外部からアクセスする場合だけ認証を求める、といった運用ができます。

AWS WAF方式が向いていないケース

本番サイトの会員ログイン

AWS WAFによるBasic認証相当の制御は、本番サイトの会員ログインには向いていません。

会員ログインでは、ユーザーごとのID管理、パスワード管理、セッション管理、権限制御などが必要になります。

AWS WAFは、これらの認証・認可機能を持つサービスではありません。

そのため、本番サイトのログイン機能には、アプリケーション側の認証機能やAmazon Cognitoなどを使うべきです。

管理者ごとの権限管理が必要な場合

管理画面を保護する場合でも、ユーザーごとの権限管理が必要なケースでは、AWS WAFだけでは不十分です。

たとえば、管理者Aには全権限を与え、担当者Bには一部機能だけ許可する、といった制御はAWS WAFではできません。

AWS WAFでできるのは、基本的に「通すか、止めるか」です。

そのため、細かな権限管理が必要な場合は、アプリケーション側の認証・認可機能を使う必要があります。

MFAが必要な場合

多要素認証が必要な環境では、AWS WAFによるBasic認証相当の制御は適していません。

Basic認証はIDとパスワードだけで認証する仕組みです。

さらに、AWS WAF方式では、ヘッダーの文字列一致を見ているだけなので、MFAのような追加認証には対応できません。

セキュリティ要件が高いシステムでは、Cognito、OIDC、SAML、SSO、ALB認証などを検討したほうがよいです。

CloudFrontでAWS WAFを使う場合の注意点

Authorizationヘッダーをオリジンに転送する必要は基本的にない

CloudFrontにAWS WAFを関連付けている場合、WAFはオリジンへリクエストが到達する前に評価します。

そのため、AWS WAFでBasic認証相当のチェックだけを行うのであれば、基本的にAuthorizationヘッダーをオリジンへ転送する必要はありません。

ただし、オリジン側のアプリケーションでもAuthorizationヘッダーを使っている場合は注意が必要です。

APIがAuthorizationヘッダーを使う場合は衝突に注意する

Basic認証もBearerトークン認証も、通常は同じAuthorizationヘッダーを使います。

そのため、サイト全体にAWS WAFでBasic認証相当の制御をかけると、APIリクエストがブロックされる可能性があります。

特に、SPA、会員サイト、管理画面、ヘッドレスCMS、GraphQL APIなどでは、AuthorizationヘッダーにBearerトークンを入れて通信することがあります。

このような構成で、AWS WAF側が「AuthorizationヘッダーはBasic認証の値でなければならない」と判定してしまうと、Bearerトークン付きのAPIリクエストも不正扱いになります。

そのため、APIを利用しているサイトでは、Basic認証をかける範囲を慎重に決める必要があります。

APIパスは除外する設計が現実的

APIがAuthorizationヘッダーを使う場合は、Basic認証相当の制御からAPIパスを除外するのが一般的です。

たとえば、Webページ本体や管理画面にはBasic認証をかけ、APIエンドポイントは対象外にします。

こうすることで、画面へのアクセスは制限しつつ、必要なAPI通信は正常に動作させることができます。

ただし、APIを除外する場合は、そのAPI自体が適切な認証・認可で保護されていることが前提です。

ALBでAWS WAFを使う場合の注意点

ホスト名やパスで条件を分ける

Application Load BalancerにAWS WAFを関連付けている場合も、考え方は同じです。

ただし、ALB配下に複数のアプリケーションや複数のドメインがある場合は、Basic認証相当の制御をかける対象を明確に分ける必要があります。

たとえば、ステージング用のドメインだけに認証をかけ、本番ドメインには影響させないようにします。

この場合は、HostヘッダーとAuthorizationヘッダーを組み合わせて条件を作ります。

本番環境への影響を避ける

ALBにAWS WAFを設定する場合、Web ACLの適用範囲を間違えると、本番環境にもBasic認証がかかってしまう可能性があります。

特に、同じALBで本番環境と検証環境を振り分けている場合は注意が必要です。

Basic認証をかけたいドメイン、パス、アプリケーションを明確にし、対象外の通信がブロックされないように設計する必要があります。

WordPressで使う場合の注意点

wp-adminとwp-login.phpの保護は有効

WordPressでは、管理画面やログイン画面を保護する目的でBasic認証を使うことがあります。

AWS WAFでも、WordPressの管理画面に対してBasic認証相当の制御をかけることは可能です。

主な対象は、管理画面とログインページです。

これにより、WordPressのログイン画面に到達する前に、WAF側でアクセスを制限できます。

admin-ajax.phpへの影響に注意する

WordPressでは、管理画面配下にあるファイルが、フロントエンド機能から利用されることがあります。

特に注意したいのが admin-ajax.php です。

このファイルは、テーマやプラグインによって、サイトの表側から呼び出される場合があります。

そのため、管理画面配下をすべてBasic認証の対象にすると、フロント側のAjax機能が正常に動作しなくなる可能性があります。

WordPressでAWS WAFによるBasic認証相当の制御を使う場合は、必要に応じて除外条件を検討しましょう。

wp-jsonへの影響にも注意する

WordPressでは、REST APIとして wp-json が使われることがあります。

ブロックエディタ、プラグイン、外部連携、ヘッドレスCMS構成などで利用されることがあるため、安易に制限するとサイト運用に影響が出る場合があります。

特に、WordPressをAPI連携やヘッドレス構成で使っている場合は、wp-json をBasic認証対象に含めるかどうかを慎重に判断する必要があります。

IP制限とBasic認証を併用する場合

社内IPは認証なしで許可できる

AWS WAFでは、IPセットを使って許可IPを定義できます。

これをBasic認証相当のルールと組み合わせることで、社内IPからのアクセスはそのまま許可し、社外からのアクセスにはBasic認証を求める構成にできます。

この方法は、社内確認用サイトやステージング環境で特に便利です。

非許可IPかつ認証情報がない場合だけブロックする

IP制限とBasic認証を併用する場合は、条件の作り方が重要です。

考え方としては、「許可IPではなく、かつBasic認証も正しくない場合だけブロックする」という形にします。

これにより、社内IPからのアクセスは認証なしで通り、社外からのアクセスは正しい認証情報がある場合だけ通ります。

この設計にすれば、社内メンバーはスムーズにアクセスでき、外部からの不用意なアクセスは防げます。

AWS WAF方式のセキュリティ上の注意点

Base64は暗号化ではない

Basic認証で使われるBase64は、暗号化ではありません。

Base64化された文字列は、簡単に元のユーザー名とパスワードに戻せます。

そのため、AWS WAFに設定するBasic認証用の文字列は、認証情報そのものとして扱う必要があります。

Base64に変換しているから安全、という考え方は危険です。

Terraform stateに認証情報が残る可能性がある

TerraformなどのIaCでAWS WAFを管理する場合、Basic認証用の文字列がTerraform stateに残る可能性があります。

これは非常に重要な注意点です。

Terraform stateを閲覧できる人は、Base64化された認証情報を取得できる可能性があります。

そして、その値は簡単に復元できます。

そのため、Terraformで管理する場合は、stateファイルの保存先、暗号化、アクセス権限、CI/CDログなどを適切に管理する必要があります。

Secrets ManagerやSSMを使っても最終的な値の管理は必要

Secrets ManagerやSSM Parameter Storeで元のユーザー名・パスワードを管理することは可能です。

ただし、AWS WAFのルールに反映した時点で、Base64化された認証情報相当の値がWAF設定やTerraform stateに残る可能性があります。

つまり、Secrets ManagerやSSMを使えばすべて安全になるわけではありません。

元の認証情報だけでなく、変換後の値やデプロイ後の設定情報についても、適切な権限管理が必要です。

HTTPSは必須

Basic認証を使う場合、HTTPSは必須です。

Basic認証では、リクエストヘッダーに認証情報が含まれます。

HTTPSで保護されていない通信では、認証情報を盗聴されるリスクがあります。

CloudFrontやALBを使う場合は、HTTPアクセスをHTTPSへリダイレクトする、またはHTTPを受け付けない構成にするのが望ましいです。

AWS WAF方式のメリット

アプリケーションを改修せずに導入できる

AWS WAFでBasic認証相当の制御を行う大きなメリットは、アプリケーション側を改修しなくても導入できる点です。

すでにCloudFront、ALB、API GatewayなどにAWS WAFを関連付けている場合、WAFルールを追加するだけで簡易的なアクセス制限を実現できます。

ステージング環境や公開前サイトの保護であれば、この手軽さは大きなメリットです。

パスやIP条件と組み合わせやすい

AWS WAFでは、URIパス、ホスト名、IPアドレス、ヘッダーなどを組み合わせて条件を作れます。

そのため、Basic認証相当の制御を特定パスだけに適用したり、許可IPからのアクセスを除外したりできます。

柔軟に条件を組み合わせられる点は、AWS WAFを使うメリットです。

CloudFrontやALBの前段で制御できる

AWS WAFは、CloudFrontやALBの前段でリクエストを評価できます。

そのため、オリジンやアプリケーションにリクエストが到達する前に、不正なアクセスを止められます。

これにより、アプリケーション側の負荷を抑えつつ、簡易的なアクセス制御を実現できます。

AWS WAF方式のデメリット

認証情報の管理が難しい

AWS WAF方式では、Basic認証用の値をWAFルールに設定する必要があります。

この値はBase64化されていますが、実質的には認証情報そのものです。

そのため、WAF設定、Terraform state、CI/CDログ、運用権限などの管理に注意が必要です。

複数ユーザーの管理には向かない

AWS WAFで複数のユーザーを許可したい場合、複数のAuthorizationヘッダー値を条件として登録することは可能です。

しかし、ユーザーが増えるほど管理が煩雑になります。

たとえば、1人のユーザーだけ削除したい場合、そのユーザーの認証情報に対応する条件をWAFルールから削除する必要があります。

このような運用は、ユーザー数が少ない場合は対応できますが、多人数の管理には向いていません。

本格的な認証機能は提供できない

AWS WAF方式では、ログインセッション、パスワードリセット、MFA、ユーザーごとの権限管理などは提供できません。

あくまで、リクエストヘッダーの値が一致するかどうかを見ているだけです。

そのため、本格的な認証基盤として使うべきではありません。

CloudFront Functionsとの違い

CloudFront FunctionsでもBasic認証は実装できる

CloudFrontを使っている場合は、AWS WAFではなくCloudFront FunctionsでBasic認証を実装する方法もあります。

CloudFront Functionsでは、Viewer Requestの段階でリクエストヘッダーを確認し、認証情報がなければ401を返すことができます。

AWS WAF方式と同じように、アプリケーションへ到達する前にアクセスを制限できます。

CloudFront Functionsのほうが柔軟な場合がある

CloudFront Functionsでは、JavaScriptで条件分岐を書けるため、WAFルールよりも柔軟に制御できます。

たとえば、パスごとに異なる認証情報を使ったり、特定の条件だけ認証対象から外したりする処理を書きやすいです。

一方で、コードの管理が必要になるため、WAFルールだけで済ませたい場合はAWS WAF方式のほうがシンプルです。

CloudFront以外では使えない

CloudFront Functionsは、CloudFrontの機能です。

そのため、ALB単体やAPI Gateway単体の構成では使えません。

ALBやAPI Gatewayに対して同じようなアクセス制御を行いたい場合は、AWS WAF方式のほうが使いやすいです。

AWS WAF方式とCloudFront Functions方式の使い分け

AWS WAF方式が向いているケース

AWS WAF方式は、コードを書かずに簡易的なアクセス制御を行いたい場合に向いています。

特に、以下のようなケースではAWS WAF方式が使いやすいです。

• ステージング環境を簡易的に保護したい
• 公開前サイトを一時的に隠したい
• ALBやAPI Gatewayでも同じように制御したい
• IP制限と組み合わせたい
• WAFのルール管理に統一したい

CloudFront Functions方式が向いているケース

CloudFront Functions方式は、CloudFrontを使っていて、より柔軟な処理を書きたい場合に向いています。

特に、以下のようなケースで検討しやすいです。

• CloudFront配信の静的サイトを保護したい
• パスごとに細かく認証条件を分けたい
• コードで条件を管理したい
• WAFルールより柔軟な判定をしたい
• レスポンス制御をコードで明確に書きたい

実装時に確認すべきポイント

Web ACLのスコープを確認する

AWS WAFには、CloudFront用とRegional用のスコープがあります。

CloudFrontに関連付ける場合はCloudFront用のWeb ACLを使います。

ALBやAPI Gatewayに関連付ける場合はRegionalのWeb ACLを使います。

スコープを間違えると、対象リソースに関連付けられません。

Web ACLが正しいリソースに関連付いているか確認する

AWS WAFのルールを作成しても、対象のCloudFront、ALB、API GatewayなどにWeb ACLが関連付いていなければ効果はありません。

設定後は、Web ACLが正しいリソースに関連付いているか確認する必要があります。

特に、ステージング環境と本番環境でWeb ACLを分けている場合は、関連付けのミスに注意が必要です。

ルールの優先順位を確認する

AWS WAFでは、ルールの評価順が重要です。

Basic認証相当のルールより前に、別の許可ルールや除外ルールがある場合、想定と異なる挙動になる可能性があります。

既存のManaged Ruleやカスタムルールと併用する場合は、優先順位を確認しましょう。

パス条件を正しく設計する

サイト全体にBasic認証をかける場合はシンプルですが、特定パスだけにかける場合は条件設計が重要です。

特に、API、静的ファイル、WordPressのAjax、外部連携用エンドポイントなどを誤ってブロックしないように注意する必要があります。

動作確認で見るべきポイント

認証なしで401が返るか

まず、認証情報なしでアクセスしたときに、401 Unauthorizedが返るか確認します。

403 Forbiddenが返る場合は、WAFのカスタムレスポンスが正しく設定されていない可能性があります。

Basic認証としてブラウザに入力画面を出したい場合は、401を返す必要があります。

WWW-Authenticateヘッダーが返っているか

401が返っていても、WWW-Authenticate ヘッダーがないと、ブラウザでBasic認証の入力ダイアログが表示されない場合があります。

そのため、レスポンスヘッダーに WWW-Authenticate が含まれているかを確認することが重要です。

正しい認証情報でアクセスできるか

次に、正しいユーザー名とパスワードを入力したときに、対象ページへアクセスできるか確認します。

アクセスできない場合は、Base64化した値が間違っている可能性があります。

特に、Base64化する際に改行が含まれていると、期待した値と一致しません。

APIや管理画面の動作に影響がないか

Basic認証相当の制御を設定した後は、対象サイトの主要機能が正常に動作するか確認する必要があります。

特に、以下のような機能は影響を受けやすいです。

• API通信
• ログイン処理
• 管理画面
• WordPressのAjax処理
• WordPress REST API
• 外部サービス連携
• フォーム送信
• 会員機能

単にページが表示されるかだけでなく、サイト全体の動作確認を行うことが大切です。

よくあるトラブル

Basic認証の入力画面が表示されない

ブラウザでBasic認証の入力画面が表示されない場合、WAFのカスタムレスポンス設定が不足している可能性があります。

特に、401ではなく403が返っている場合や、WWW-Authenticate ヘッダーが付いていない場合に起こりやすいです。

Basic認証として動作させたい場合は、401と WWW-Authenticate ヘッダーの両方が必要です。

正しいパスワードを入れても通らない

正しいはずのID・パスワードを入力してもアクセスできない場合、Authorizationヘッダーの値がWAFに設定した値と完全一致していない可能性があります。

よくある原因は、Base64化するときに改行が含まれているケースです。

また、認証情報の前後に余計な空白が入っていたり、WAF側の文字列が間違っていたりする場合もあります。

APIリクエストが401になる

サイト全体にBasic認証相当の制御をかけた場合、APIリクエストも認証対象になります。

APIがBearerトークンなどをAuthorizationヘッダーで送っている場合、WAF側のBasic認証条件と衝突する可能性があります。

この場合は、APIパスをBasic認証対象から外す設計にする必要があります。

WordPressの一部機能が動かない

WordPressで管理画面配下をまとめて保護した場合、admin-ajax.php や wp-json に影響が出ることがあります。

その結果、フロントエンドの一部機能、ブロックエディタ、プラグイン、外部連携などが正常に動かなくなる可能性があります。

WordPressで使う場合は、保護対象と除外対象を慎重に設計しましょう。

最終的な結論

AWS WAFでBasic認証をかける方法は、実装方針としては大筋で正しいです。

AWS WAFはリクエストヘッダーを検査できるため、Authorizationヘッダーに含まれるBasic認証の値をチェックし、正しくないリクエストをブロックできます。

また、ブロック時に401を返し、WWW-Authenticate ヘッダーを付けることで、ブラウザにBasic認証の入力ダイアログを表示させることもできます。

ただし、AWS WAFは認証基盤ではありません。

この方法は、あくまでBasic認証相当のヘッダー検査による簡易的なアクセス制御です。

ステージング環境、公開前サイト、社内確認用ページ、特定パスの簡易保護には向いています。

一方で、本番サイトの会員ログイン、管理者ごとの権限管理、多要素認証、監査ログ、パスワード変更フローなどが必要な用途には向いていません。

そのような場合は、Amazon Cognito、ALB認証、OIDC、SAML、SSO、CloudFront Functions、Lambda@Edge、アプリケーション側の認証機能などを検討するべきです。

以上、AWS WAFでBasic認証をかける方法についてでした。

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