いわさです。
AWS Verified Access を使うことで信頼された IdP やデバイスが利用されていることを前提に、既存のプライベートネットワーク上の Web アプリケーションをプライベートネットワーク外から利用出来るようにすることが出来ます。
しかし、これまでプライベートネットワーク内でのみ利用していたアプリケーションをパブリックなエンドポイントを経由してアクセス出来るようにさせるということもあり、外部からの攻撃に備えなければと考え始める方も多いと思います。
実は AWS Verified Access の GA 時に、AWS WAF でもサポートされるようになっています。
公式ドキュメントはこちらです。
AWS WAF を統合することで、IdP の前段で AWS Verified Access + AWS WAF が攻撃から防御してくれます。
Verified Access 一式のデプロイ
前回 IAM Identity Center が有効なアカウントでプライベートアプリケーションを含めて Verified Access 一式をデプロイ出来る CloudFormation テンプレートを作成しています。
次のように IAM Identity Center で認証された後、プライベートアプリケーションへアクセス出来るようになりました。
これらはデプロイされると次のような構成になっています。
ここに AWS WAF を統合します。
他のサービスと同様 Web ACL を作成して関連付けするだけ
まず Verified Access はいくつかリソースが存在していますが、Web ACL を関連付けする対象はエンドポイントではなく Verified Access インスタンスになります。
マネジメントコンソールの場合は Verified Access インスタンスの統合タブで AWS WAF と統合済みかどうか確認が出来ます。
以下はまだ関連付けがされていない状態のものとなります。
「ウェブ ACL を作成」という画面で AWS WAF の Web ACL 作成画面へ遷移します。
後は従来どおり Web ACL を作成するだけなのですが、Verified Access の GA に伴って、Web ACL のリソース関連付け画面でもターゲットリソースタイプに Verified Access が追加されていることが確認できるはずです。
今回は適当なカスタムヘッダーが指定の値だった場合にブロックさせるルールにしました。
Web ACL を関連付けすると、Verified Access インスタンスの統合タブも WAF 統合ステータスが「関連付け済み」となっていることが確認出来ます。
ブロック動作の確認
今回は ModHeader の Google Chrome 拡張を使って、Chrome から Verified Access エンドポイントへカスタムヘッダー付きでアクセスしてみます。
アクセスしてみると次のように 403 Forbidden となりました。ブロックされていますね。
知っておきたい重要な点としては、信頼プロバイダー（今回だと IAM Identity Center）への認証前の段階で評価されているという点です。
IAM Identity Center 認証後に WAF ルールが評価されるのかな？と最初予想していたのですが、そうではありませんでした。
カスタムヘッダーを付与しない状態でアクセスしてみると次のように信頼プロバイダーによる認証が要求され、プライベートアプリケーションへアクセスすることが出来ました。
良いですね。
さいごに
本日は AWS Verified Access で公開されたパブリックエンドポイントを AWS WAF で保護してみました。
Verified Access を導入する際にはほぼ構成することになるであろうこの機能ですが、CloudFront や ALB、API Gateway と同じで構成自体は非常に簡単でした。
是非使ってみてください。
5
