いわさです。
re:Invent 2022 で AWS Verified Access がパブリックプレビューで登場していました。
VPC 内のプライベートなアプリケーションに信頼された IdP を使って、構成されたポリシーをクリアしている場合など一定条件を満たしているとパブリックなエンドポイントを経由したプライベートネットワーク上の Web アプリケーションへ接続させることが出来るサービスです。
そんな AWS Verified Access が本日 GA となりました。
プレビュー時点からいくつか機能が追加されているのですが、そもそも DevelopersIO に実際に使った記事がないことに気が付きました。
そこで、本日はまず基本的な使い方を通しで試してみましたので紹介します。
東京リージョンはまだ
GA 後も東京リージョンではまだ利用出来ません。
プレビュー時と同様に以下のリージョンでのみ利用が可能です。
- 米国東部 (オハイオ)
- 米国東部 (バージニア北部)
- 米国西部 (北カリフォルニア)
- 米国西部 (オレゴン)
- アジアパシフィック (シドニー)
- カナダ (中部)
- 欧州(フランクフルト)
- ヨーロッパ (アイルランド)
- ヨーロッパ (ロンドン)
- 南アメリカ (サンパウロ)
また、本日時点では IdP に IAM Identity Center を使う場合は同一リージョンである必要があるようです。
東京リージョンの IAM Identity Center が有効な場合は次のように、Verified Access から認識されませんでした。
ただ、公式ドキュメントには同一リージョンである旨の記述が見当たらなかったので、これは今後変更される可能性があります。
料金はデプロイリソースがプロビジョニングされている時間と処理されたデータ量での従量課金
初めて使うサービスということもあるので、使い前に利用料金も軽く確認しておきましょう。
詳細は上記をご確認頂ければと思いますが、Verified Access に関連付けしたアプリケーションごとの時間単位課金に加えて、処理されたデータに対して GB 単位で料金が発生するようです。
バージニア北部だと $0.27/hr なので、720 時間だとすると 1 アプリあたり $200/月 + データ処理量($0.02/GB) という感じでしょうか。
検証用のプライベートアプリケーションを用意
まずはプライベートネットワーク上で動作するアプリケーションを用意して、後ほど Verified Access を統合させたいと思います。
私が検証用にいつも使っている次のサンプルアプリケーションを使いたいと思います。
上記の CloudFormation を展開すると、VPC と ALB、Apache 入りの EC2 がセットアップされます。
パブリックアクセスが出来る状態なのですが、デプロイ後に ALB を internal な ALB に入れ替えることでプライベートアクセスのみ可能なアプリケーションということにしたいと思います。
AWS Verified Access を構成
ではここから AWS Verified Access を構成していきます。
色々とコンポーネントが登場してきて混乱するのでまず公式ドキュメントの図を引用して私の理解を軽く解説しますね。
How Verified Access works - AWS Verified Access より引用
右側の緑色の枠の VPC が Verified Access で統合したいプライベートアプリケーションです。
左側の紫色の枠が Verified Access です。
Verified Access 内の Verified Access エンドポイントを作成する際に、接続先のプライベートリソースを指定します。
この際に指定出来るのは internal な Network Load Balancer / Application Load Balancer か ENI です。
Verified Access エンドポイントを作成すると宛先 VPC 内に Verified Access が使用する ENI が作成され、このENI から内部 Web アプリケーションへアクセスします。
同時にパブリックなエンドポイントが払い出されるので、リクエストが Verified Access のパブリックエンドポイントへ送信されるのように CNAME レコードを作成する必要があります。
ざっくりいうと、Verified Access エンドポイントを作成する際に Verified Access を経由して接続するウェブアプリケーションを指定しています。
あとは Verified Access に信頼プロバイダーやグループポリシーを設定することで、エンドポイントへ送信されたリクエストが許可されたものであるかを Verified Access が判断し、内部 Web アプリケーションへ通知するか拒否するかを制御します。
Verified Access インスタンス作成
まずは Verified Access インスタンスを作成します。
なお、Verified Access 関係のリソースは VPC メニューからアクセスする形となっています。
信頼プロバイダーは既存のものをこの時点でアタッチしても良いですが、後ほど作成して追加でアタッチやデタッチが出来るのでこの時点では作成しなくても良いです。
Verified Access 信頼プロバイダー作成
続いて信頼プロバイダーを作成します。
信頼プロバイダーにはまず大きくはユーザー信頼プロバイダーとデバイス信頼プロバイダーの 2 種類があります。
ユーザー信頼プロバイダーは ID プロバイダーが認証したユーザーを信頼するもので、本日時点では IAM Identity Center か個別に OIDC 準拠の外部 IdP を統合することが出来ます。
デバイス信頼プロバイダーはデバイスのセキュリティ状態を検証するもので、本日時点では Jamf と Crowdstrike の 2 つから選択ができます。
今回は最も導入が簡単な IAM Identity Center を使用したいと思います。
前述のとおり AWS Verified Access と同一リージョンで IAM Identity Center を有効化していれば、それだけですぐに Verified Access 信頼プロバイダーを作成することが出来ました。
作成後は、Verified Access インスタンスにアタッチしておきましょう。
アタッチされると次のように一覧に表示されます。
Verified Access グループ作成
続いて Verified Access グループを作成します。
このグループで複数のエンドポイントをまとめて共通のポリシーを設定し、Verified Access インスタンスを通して信頼プロバイダーと関連付けします。
ポリシーで、アクセス許可する条件を Cedar で定義するのですが、後ほど設定します。
Verified Access エンドポイント作成
ACM とドメインを先に用意しておく
続いてエンドポイントを構成することで、具体的に Verified Access からどの Web アプリケーションへ接続するのかを構成します。
Verified Access エンドポイントを作成すると、パブリックエンドポイントが作成されてユーザーはそのエンドポイントを経由してプライベートアプリケーションへアクセスします。
パブリックエンドポイントへアクセスする際にはカスタムドメインと、その SSL 証明書が必要となります。
そのため、まずその 2 つを用意しておきましょう。
なお、本日時点で Verified Access エンドポイントはエイリアスレコードに対応しておらず、DNS 側では CNAME レコードでの登録が必要です。
APEX ドメインなどを使おうとしていた場合は注意しましょう。
エンドポイント作成
エンドポイント作成時には前述のようにまずはアプリケーションドメインとドメイン証明書(ACM) の ARN を指定します。
ACM は Verified Access と同一リージョンでの作成が必要です。
続いて Verified Access がプライベートネットワークの Web アプリケーションへどのように接続するのかを具体的に設定します。
アタッチメントタイプは本日時点では VPC のみ選択可能です。
ここで指定するセキュリティグループは Verified Access エンドポイントによって作成される ENI が使用するセキュリティグループです。
内部アプリケーションはこのセキュリティグループからのアクセスを許可する必要があります。
プライベートアプリケーションへ接続可能なプロトコルは、どのエンドポイントタイプだとしても HTTPS と HTTP のみ選択出来ます。
Verified Access から接続可能なのはプライベートな Web アプリケーションのみであると考えるのが良さそうです。
作成後、VPC 内に ENI が作成されていることが確認出来ます。
Verified Access パブリックエンドポイントの名前解決
Verified Access エンドポイントを作成するとパブリックなエンドポイントドメインが払い出されるので、これをアプリケーションドメインとして指定したホストゾーンで CNAME レコードで登録を行います。
ポリシー設定
この時点では Verified Access 上でポリシーの設定を行っていません。
そのためアプリケーションドメインにアクセスしたとしても次のようにタイムアウトになります。
Verified Access グループのポリシータブからポリシーを設定しましょう。
ポリシーの記述方法は次のドキュメントを確認してください。
いくつか記述例も紹介されています。
例えば次のように指定すれば、信頼プロバイダーの認証に成功すれば無条件で接続が出来ます。
permit(principal,action,resource)
when {
true
};今回は IAM Identity Center の特定のグループに所属している場合のみアクセス出来るようにしてみたいと思います。
公式ドキュメントによると次のようなフォーマットとなります。
permit(principal,action,resource)
when {
context.<policy-reference-name>.groups has "<グループ ID>"
};policy-reference-name は信頼プロバイダーの詳細情報から確認可能です。
グループ ID は IAM Identity Center のグループ詳細情報から確認可能です。
以上から次のようなポリシーを今回は設定してみました。
グループポリシーを更新すると、グループ内の Verified Access エンドポイントのステータスが Updating となります。
ステータスが Active になったら、アプリケーションドメインへアクセスしてみましょう。
先程と異なり、ポリシー構成後はタイムアウトせずに IAM Identity Center の認証画面へリダイレクトされるようになりました。
ちなみに IAM Identity Center には次の 2 名のユーザーが存在しています。
hogeadmin は対象のグループに所属しており、hogeuser1 は対象グループに所属していません。
まずは hogeadmin の認証情報を入力してみましょう。
次のように、プライベートネットワーク上の EC2 インスタンスでホスティングされているサンプルアプリケーションへ、ネットワークの外部からアクセスすることが出来ました。
また、一度セッションを終了し hogeuser1 で同じ手順で認証した場合は次のように 403 Unauthorized となりました。
期待どおり拒否されましたね。
さいごに
本日は AWS Verified Access が GA となったので IAM Identity Center を信頼プロバイダーとしてグループポリシーを設定して使ってみました。
まずは一番導入が簡単そうな IAM Identity Center を使う方法を使ってみました。
ドキュメントだけ最初見てると少し難しそうだなと感じたのですが、使ってみるとなんとなく使い方がわかってきました。
プライベートネットワーク上のアプリケーションに信頼された認証情報で外部からアクセスさせたいという要件は多いと思うので、今後 AWS Verified Access を導入するシーンが増えてくるのではないかと感じました。早く東京リージョンで使いたいところですね。
次回は外部 IdP なども構成してみたいと思います。
5
