こんにちは!イーゴリです。
外部からAWSアカウントにあるプライベートなリソースにアクセスしたい場合、今まではAWS Client VPN/AWS Site-to-Site VPNを使うかDirect Connectを使う必要がありましたが、 AWS Verified Access (新サービス) を使うことでAWS環境にあるアプリケーションに安全にVPN なしでアクセスできるようになりました!

- イメージ図
- 前提条件
- IdP設定(Okta認証)
- AWS Verified Access 構築
- 接続の確認
- おまけ(料金)
イメージ図
今までのVPN構成

AWS Client VPNの参考記事:
AWS Site-to-Site VPNの参考記事:
VPN-lessの本件記事の構成

前提条件
- 対象AWSアカウント内に利用可能なWebアプリケーション/確認できる簡易なWebサーバーなどが構築されていること(私の場合、下記の図のような環境が準備されています)

- IDプロバイダー(IdP)もしくはAWS Identity Centerがあること(今回の記事では、Oktaを使います)
- 有効なドメイン取得及びSSL証明書
※外部ドメインサービスで取得したドメインをRoute53に設定したい場合、下記の記事をご参考ください。
IdP設定(Okta認証)
Okta アプリケーションの作成 (AWS Identity Centerを使う場合、このステップをスキップ)
Oktaの[管理者]コンソールで「アプリケーション」メニューを開き、「アプリ統合を作成」をクリックします。

- サインイン方法:OIDC

- アプリケーションタイプ:Webアプリケーション
「次へ」をクリックする。

「アプリ名」を入力し、必要に応じて「ロゴ」を設定し、「認証コード」項目を選択します。

「サインイン リダイレクトURIs」で 下記を指定します。
https://<今回使うドメイン名>/authorization-code/callback

「サインアウト リダイレクトURIs」も設定する必要がありますが、今回は簡易なWebページのため不要なので、デフォルトのまま残します。


作成が終わったら、下記のような認証情報の画面が表示されます。

Oktaで利用者の割り当て
アプリにユーザ/グループを追加します。本番環境の場合、ユーザーをグループごとに分けて、グループをアプリに追加したほうが管理しやすいですが、検証のため、ユーザー#1のみを追加します。




AWS Verified Access 構築
[VPC]に入ると、下記のようにAWS Verified Access という新規項目が追加されました。

事前準備
AWS Verified Access セキュリティグループの作成
私の場合、内部通信はHTTPしか使わない※ため、下記の設定で作成します。
※ 2025年2月6日のアップデートにより、AWS Verified Access で非HTTP(S)プロトコル(TCP、SSH、RDPなど)が利用可能になりました。
VPNレスでゼロトラストベースのアクセスを企業アプリケーションとリソースに提供
ユーザーIDとデバイスの状態に基づくアクセスポリシーの設定が可能
AWS Verified Accessが非HTTP(S)プロトコル(TCP、SSH、RDPなど)を使用するリソースへの安全なアクセスをサポート
VPNレスでゼロトラストベースのアクセスを企業アプリケーションとリソースに提供
ユーザーIDとデバイスの状態に基づくアクセスポリシーの設定が可能
エンドポイントセキュリティグループ
AWS Verified Access 構築に入る前に事前にAWS Verified Access エンドポイント用のセキュリティグループを作成します。
| インバウンドルール |
|---|
| なし |
| アウトバウンドルール | |
|---|---|
| タイプ | HTTP |
| プロトコル | TCP |
| ポート範囲 | 80 |
| 送信先 | av-alb-sg (ALBのSG) |


ELBのセキュリティグループ
| インバウンドルール | |
|---|---|
| タイプ | HTTP |
| プロトコル | TCP |
| ポート範囲 | 80 |
| ソース | av-sg (Verified AccessエンドポイントのSG) |
| アウトバウンドルール | |
|---|---|
| タイプ | HTTP |
| プロトコル | TCP |
| ポート範囲 | 80 |
| 送信先 | ec2-linux-sg (対象アプリ/EC2などのSG) |


上記のSGを対象ELBにアタッチします。
アプリのセキュリティグループ
| インバウンドルール | |
|---|---|
| タイプ | HTTP |
| プロトコル | TCP |
| ポート範囲 | 80 |
| ソース | av-alb-sg (対象ELBのセキュリティグループ) |
| アウトバウンドルール | |
|---|---|
| タイプ | HTTP |
| なし |
上記のSGを対象EC2(アプリ)にアタッチします。
AWS Verified Access エンドポイント用の証明書作成(AWS Certificate Managerにすでにある場合、スキップ)
[AWS] > [AWS Certificate Manager] > [リクエスト]をクリックします。

[パブリック証明書をリクエスト]のまま進んで、[次へ]をクリックします。

[完全修飾ドメイン名]に対象のドメイン名を指定します。
対象証明書の期限切れを防ぐために、[DNS 検証 - 推奨]を選択します。

必要に応じてタグを指定し、[リクエスト]をクリックします。

CNAMEレコードを追加します。

Route53の場合、下記の画面の通り、[レコードを作成]をクリックします。

対象証明書の画面でステータスが「保留中」から「確認済み」に変わるまで待機します。


AWS Verified Access 信頼プロバイダーの作成

[VPC] > [Verified Access 信頼プロバイダー] > [Verified Access 信頼プロバイダーを作成]をクリックします。

必要に応じてName タグなどを入力します。

- ポリシー参照名:任意の名前
- 信頼プロバイダータイプ:ユーザー信頼プロバイダー
- ユーザーの信頼プロバイダータイプ:OIDC (OpenID Connect)※
※Oktaを使うため、OIDC (OpenID Connect)を選択しましたが、IAM Identity Centerを使う場合、[IAM Identity Center]を選択する必要があります。
下記のURLにアクセスすると信頼プロバイダーの作成時に必要な情報を取得できます。
https://<登録されているOktaドメイン>.okta.com/.well-known/openid-configuration

※上記のままだとJSONが見づらいので、JSON Viewerを使うと見やすくなります。






作成されたことを確認します。

AWS Verified Access インスタンスの作成

AWS Verified Access インスタンスにて上記で作成したVerified Access 信頼プロバイダーを指定します。
[VPC] > [Verified Access インスタンス] > [Verified Access インスタンスを作成]をクリックします。

- 任意のName タグを指定します。
- Verified Access 信頼プロバイダーをアタッチ:<上記にて作成したVerified Access 信頼プロバイダー>

[Verified Access インスタンスを作成]をクリックします。
AWS Verified Access グループの作成

AWS Verified Access グループにて上記で作成したVerified Access インスタンスを指定します。
[VPC] > [Verified Access グループ] > [Verified Access グループを作成]をクリックします。

- Name タグ:任意の名前
- Verified Access インスタンス:上記で作成したVerified Access インスタンスを指定します。
- [ポリシーの詳細]で、認証を許可されたユーザーがアクセスできるという条件を指定できます。
今回は簡易なポリシーを指定します(信頼プロバイダーの認証に成功したらアクセス可能)。何も設定しないとアクセスできませんので、ご注意ください。
permit(principal,action,resource)
when {
true
};
ポリシーステートメントの構造の参考記事:


AWS Verified Access エンドポイントの作成

Verified Accessの構築はほぼ終わりですが、インターネットからアクセスするには、Verified Accessエンドポイントを作成しないといけません。
[VPC] > [Verified Access インスタンス] > [Verified Access エンドポイントを作成]をクリックする。

- Name タグ:任意の名前
- Verified Access グループ:上記にて作成したグループを指定
- アプリケーションの詳細:アプリケーションに到達するユーザーの DNS 名を指定(私の場合、va-test.XXXX)
- ドメイン証明書の ARN:事前準備のステップで準備した証明書を指定

- アタッチメントタイプ:VPC
- セキュリティグループ:事前準備のステップで準備したエンドポイント用のセキュリティグループを指定
- エンドポイントドメインプレフィックス:エンドポイント用に生成された DNS 名の前に付加されるカスタム識別子を指定(私の場合、va-test)→エンドポイントが作成されたら、エンドポイントドメインとして使えます(例:va-test.edge-XXX.prod.verified-access.<リージョン>.amazonaws.com)
- エンドポイントタイプ:ロードバランサー
- プロトコル:内部のトラフィックを暗号なしで通したいため、「HTTP」を選択
- ポート:80
- ロードバランサー ARN:前提条件としている既存の環境にあるロードバランサーを指定
- サブネット:ロードバランサーに関連付けられたサブネットを選択

- ポリシーの詳細:何も入力せずに進む

[Verified Access エンドポイントを作成]をクリックします。

エンドポイントが作成されるまで待機します。

ステータスが「Active」になりました。

補足
エンドポイントタイプとしてロードバランサーだけではなく、ネットワークインターフェイスも使えます。


Route 53 でエンドポイントドメインのCNAMEレコードを作成
DNSでエンドポイントドメインをCNAMEレコードとして登録します。

私はRoute 53を使用します。
[Route 53] > [対象ドメイン] > [レコードを作成] > 下記のレコードを作成 > [レコードを作成]をクリックします。
| レコード名 | レコードタイプ | 値 |
|---|---|---|
| va-test | CNAME | エンドポイントドメイン |

接続の確認
ブラウザーで対象FQDNにアクセスします。

Oktaアクセスページに移動し、認証情報を入力します。


Webページにアクセスできました!

おまけ(料金)
以下の料金が発生します。
東京リージョン:
- Verified Access に関連付けしたアプリケーションごとの時間単位課金※:0.35USD/時間 → 720時間 = 250USD程度 / 月
- 処理されたデータ:0.02USD / 1 GB あたり
※148,800 アプリケーション時間まで
詳しくは下記の記事をご参考ください。
以上、御一読ありがとうございました。
本田 イーゴリ (記事一覧)
カスタマーサクセス部
・2024 Japan AWS Top Engineers (Security)
・AWS SAP, DOP, SCS, DBS, SAA, DVA, CLF
・Azure AZ-900
・EC-Council CCSE
趣味:日本国内旅行(47都道府県制覇)・ドライブ・音楽