みなさん。こんにちは。小寺です。
1週間お休みだったり、しなかったりする方、様々だと思いますが、re:Inventで発表されたVerified AccessがGAになりました。

https://aws.amazon.com/about-aws/whats-new/2023/04/aws-verified-access-generally-available/

AWS Verified Accessとは

AWS Verified Accessとは、AWSのゼロトラストの基本原則に基づいて構築されています。AWS Verified Accessを使えば、アプリケーションへのアクセス許可をする前に、すべてのリクエストを検証します。アクセスを検証するため、VPNが不要になり、エンド ユーザーのリモート接続が簡単になります。
というのがオフィシャルでの説明です。
re:Invent時の発表内容を踏まえた過去記事はこちらからご確認くださいませ。

またGA時にアップデートがあるので、その内容もご紹介させていただきます。
アプリケーションのセキュリティをさらに強化することを目的として、 Verified Accessの検証済みアクセスがAWS WAFをサポートするようになりました。
AWS WAFを使うことで、SQL インジェクションやクロスサイト スクリプティングなど、幅広いインターネットベースの脅威から保護することができます。
さらに、検証済みアクセスは、ユーザーのログイン エイリアスなどの署名付きのIDコンテキストをアプリケーションに渡すようになりました。
アプリケーションが署名されたコンテキストのないリクエストを受信した場合、リクエストを拒否するのでセキュリティ強化に繋がります。
署名されたコンテキストには、役割や部門などのユーザー属性も含まれており、アプリ利用の従業員のロールに基づいてアプリケーションにカスタムコンテンツを表示することもできます。

どんなときに役立つ？

現状のアーキテクチャについて、紹介します！

【パターン①】
AWS Site-to-Site VPNを使っている場合です。このアーキテクチャでは、ユーザーは、Site-to-Site VPN によって AWS に接続した場合のみ、アプリケーションにアクセスできます。
これらのアプリケーションの多くには、ユーザーが VPN を使用している場合にアプリケーションにアクセスできる暗黙の信頼モデルとなっていますよね。
ユーザーの認証とログインはアプリケーション側で行われるため、追加の開発が必要です。ただし、要求に含まれる ID 以外の追加チェックはありません。
このアーキを採用する場合、Application Load Balancer (ALB) は内部ロードバランサーであり、ルーティングは Site-to-Site VPN または Client VPNから有効になります

https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-verified-access-general-availability/より引用

【パターン②】
パターン①とは異なり、ユーザはインターネット経由でアプリケーションにアクセスできます。
インターネットに接続する ALB を AWS WAF と OIDC プロバイダーの両方と統合することが多いですよね。
ユーザーは ALBで認証され、HTTP ヘッダー x-amzn-oidc-data を使用して ALB からインスタンスに送信されます。アプリケーション側はWAFのHTTPヘッダーを使用して認証されたユーザーを識別しますが、デバイスの正常性やその他のコンテキストは ALBでは検証されないというマイナス面があります。

https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-verified-access-general-availability/より引用

【パターン③】
ここで、AWS Verified Access（AVA）の出番です。
・ALB: AVAでは、ALB が内部向けに配置されている必要があります。パターン①の場合OKなのですが、ALB検証をするにはパターン②のアーキテクチャは見直しが必要です。
・WAF 統合: 検証済みアクセス内のインスタンス レベルでの WAF のサポートにより、WAF と ALB が統合されている既存のアプリケーションは、ポリシーを ALB から検証済みアクセス インスタンスに移動できます。
・Cedar Policy: AVAは、検証済みアクセスの背後にあるアプリケーションへのアクセスを許可するために、一元化されたポリシーが利用できます。Cedar ポリシーを使用して、アプリケーションへのアクセスを許可および禁止できます。
ポリシーは、顧客のニーズに応じて、グループ レベルまたはエンドポイント レベルで作成できます。
・リクエスト: 検証済みアクセスが HTTP ヘッダーを介してアプリケーションにリクエストを渡す場合、アプリケーションは x-amzn-ava-user-context HTTP ヘッダーを使用して、アプリケーションにアクセスするユーザーの識別が必要です。

試してみた

(1) AWS Verified Accessの使用を開始から「Verified Accessインスタンスを作成」をクリックします。

(2)「Verified Access インスタンスを作成」画面からインスタンスの名称を入力し、「Verified Access信頼プロバイダーをアタッチ」から
「Verified Access信頼プロバイダーを作成」をクリックします。

(3)信頼プロバイダータイプとしては「ユーザー信頼プロバイダー」か「デバイス信頼プロバイダー」を選ぶことができます。

(4)作成した「Verified Access信頼プロバイダー」を選び「Verified Accessインスタンスを作成」をクリックします。

(5)インスタンス作成後「統合」タブから「WAF」のアタッチができます。

利用料

正式な利用料はこちらからご確認ください。

ご利用可能リージョン

GA時点では以下の10リージョンで利用が可能です。
・US East (Ohio)
・US East (N. Virginia)
・US West (N. California)
・US West (Oregon)
・Asia Pacific (Sydney)
・Canada (Central)
・Europe (Frankfurt)
・Europe (Ireland)
・Europe (London)
・South America (São Paulo)