AWS Verified Access の主要な 4 つのコンポーネント構造を整理してみた

いわさです。

先日 GA となった AWS Verified Access ですが、以下の記事でも登場するように利用する際にはいくつかコンポーネントを構成する必要があります。

主要なものとして以下の 4 つがあります。

• Verified Access インスタンス
• Verified Access 信頼プロバイダー
• Verified Access グループ
• Verified Access エンドポイント

厳密にはポリシーも重要なコンポーネントと言えるのですが、マネジメントコンソールや API 上からリソースとして操作するのは上記 4 つです。

一度 Verified Access を構築してみると上記のうちエンドポイントと信頼プロバイダーの基本的な部分は直感的に理解できると思います。

• エンドポイントで実際のプライベートアプリケーションへの経路や構成を設定します
• 信頼プロバイダーでは信頼する IdP やデバイスなどの構成を設定します

しかし、インスタンスとグループについてはまとめるためのリソースグループのようなものかな？くらいで、その実態や使い方がよくわかっていませんでした。
また、インスタンスに対して複数の信頼プロバイダーをアタッチしたり、単独のグループに複数のエンドポイントを構成したりすることが出来ますがどういう時にどう使えば良いのかわからずにこれまで構成していました。

今回それぞれのコンポーネントを複数構成したり組み合わせたりしていくつかわかったことがありますので検証結果などと併せて紹介したいと思います。

先にまとめてみたが...

今回複数のコンポーネントを組み合わせることで Verified Access 全体像として次のような構成になっていることがわかりました。

1 つの構成図でまとめれると理解しやすいのかなと思って作ってみたのですが、私の表現力が不足していました。申し訳ありません。

そこで、ポイントごとに解説したいと思います。

パブリックエンドポイントは Verified Access インスタンスが持っている

Verified Access では、Verified Access エンドポイントを作成し、その時に出力されるエンドポイントに対してパブリックなリクエストを送信することでアクセス元の検証などが発生します。
私は今回検証するまで、実は次のように Verified Access エンドポイントごとにエンドポイントドメインが生成されているのかと思いこんでいました。

しかし、今回複数のエンドポイントを同一の Verified Access インスタンス、あるいは別の Verified Access インスタンスにデプロイしたところ次のように、いくつかのエンドポイントドメインが同じものでした。なんと。

上記を整理してみると、実はエンドポイントドメイン自体は Verified Access インスタンスから提供されているものということがわかりました。
そして、Host ヘッダーによってインスタンス内のリバースプロキシ先を分けているようなイメージです。

構成図を直すと次のような感じになるでしょうか。

なお、単独のインスタンスで複数のエンドポイントをデプロイ出来るので、同一インスタンスにエンドポイントを集中させた場合のパフォーマンス影響について少し気になりましたが、公式ドキュメント上での記述は見当たりませんでした。

Verified Access 信頼プロバイダーは同じタイプを組み合わせることは出来ない

今回一番気になっていて検証したかったのがここです。

Verified Access 信頼プロバイダーは Verified Access インスタンスにアタッチすることで利用されます。
そして Verified Access インスタンスには複数の信頼プロバイダーをアタッチ出来るようになっています。

仮に、次のように IAM Identity Center と Azure AD と、異なる IdP をどちらもアタッチさせるとどうなるのでしょうか。
どちらの認証も必要になるのでしょうか。それともどちらかが認証されていてポリシーをクリア出来ていれば検証済みとみなされるのでしょうか。

結論としては上記の組み合わせは出来ませんでした。
次のように組み合わせてみたところデプロイ時にエラーが発生しました。

:
  HogeInstance:
    Type: AWS::EC2::VerifiedAccessInstance
    Properties: 
      VerifiedAccessTrustProviderIds: 
        - !Ref HogeTrustProvider
        - !Ref HogeTrustProvider2

  HogeTrustProvider:
    Type: AWS::EC2::VerifiedAccessTrustProvider
    Properties: 
      PolicyReferenceName: !Sub ${AWS::StackName}policy
      TrustProviderType: user
      UserTrustProviderType: iam-identity-center

  HogeTrustProvider2:
    Type: AWS::EC2::VerifiedAccessTrustProvider
    Properties: 
      OidcOptions: 
        AuthorizationEndpoint: https://login.microsoftonline.com/5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7/oauth2/v2.0/authorize
        ClientId: 5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7
        ClientSecret: hogesecret
        Issuer: https://login.microsoftonline.com/5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7/v2.0
        Scope: openid
        TokenEndpoint: https://login.microsoftonline.com/5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7/oauth2/v2.0/token
        UserInfoEndpoint: https://graph.microsoft.com/oidc/userinfo
      PolicyReferenceName: hoge0512policy
      TrustProviderType: user
      UserTrustProviderType: oidc
:

Stack hoge0521verified: ROLLBACK_FAILED
Messages:
  - HogeInstance: Resource handler returned message: "Cannot have more than 1 VerifiedAccessTrustProvider with TrustProviderType user attached to a VerifiedAccessInstance (Service: Ec2, Status Code: 400, Request ID: daae7d1e-d280-4618-b948-5275848fc653)" (RequestToken: abb43652-186b-2e99-a4fb-7a276f9e59f2, HandlerErrorCode: ServiceLimitExceeded)
  - HogeTrustProvider2 - vatp-0205770612f199966: Resource handler returned message: "VerifiedAccessTrustProvider has existing attachments. Please remove all VerifiedAccessTrustProvider attachments before deleting. (Service: Ec2, Status Code: 400, Request ID: 84c13a39-f519-421f-9bda-24324c8bf537)" (RequestToken: 449d2725-85bf-338e-24ba-bd54c7478707, HandlerErrorCode: InvalidRequest)
failed deploying stack 'hoge0521verified'
iwasa.takahito@HL01200 hoge0521verified %

信頼プロバイダーには TrustProviderType という属性があり、大きく分けるとユーザー信頼プロバイダーとデバイス信頼プロバイダーの 2 つの種類があります。
上記のエラーメッセージはユーザー信頼プロバイダーが既にアタッチされているのでダメだぜ。と言われています。

よく読むとこのあたりは公式ドキュメントにも記述がありました。

You can choose to use either AWS IAM Identity Center (successor to AWS Single Sign-On) or an OpenID Connect-compatible user-identity trust provider.

User-identity trust providers - AWS Verified Access より

You can use device management trust providers with AWS Verified Access. You can use multiple device trust providers with your Verified Access instance.

Device-based trust providers - AWS Verified Access より

よって、次のように IAM Identity Center (ユーザー信頼プロバイダー）と Jamf (デバイス信頼プロバイダー) の組み合わせであれば同一インスタンスへアタッチが可能です。
また、異なるユーザー信頼プロバイダーの場合も同一インスタンスでなければアタッチが可能なので、あるインスタンスは IAM Identity Center + Jamf で検証を行い、別のインスタンスは Azure AD で検証を行う、というようなインスタンスごとに検証方法を分けて使うことが可能です。

同一プライベートアプリケーションに別々のエンドポイントから接続出来る

出来るだろうなと思っていましたが、出来ました。
次のように単独のプライベートアプリケーションに対して別々の Verified Access エンドポイント、インスタンスで構成可能です。

よって、アプリケーションドメインを分けることで、同一アプリケーションでも信頼プロバイダーやポリシーを複数の組み合わせを用意することが可能です。
これは使い所結構ありそうですね。（社内向けと社外向けで信頼プロバイダーやポリシーを分けるとか）

ちなみに、エンドポイントごとに Verified Access 用の ENI が作成されます。

インスタンスとグループは同一信頼プロバイダー、共通のポリシーでまとめるのが良い

ここはあまり難しくなく、インスタンスでのみ管理されるのはどの信頼プロバイダーを使うかです。
また、グループで管理出来るのはグループポリシーです。

よって、同一の信頼プロバイダーの組み合わせであれば、グループとエンドポイントは同一の Verified Access インスタンスで良いと思います。
同様に同一のポリシーを使えるアプリケーションであれば、同一の Verified Access グループにまとめて良いと思います。

ポリシーに関してはエンドポイントごとに個別でポリシーを設定しても良いですが、グループポリシーで設定の簡素化・共通化が可能です。

コンポーネントの上限があるのでサービスクォータで緩和申請

ここでまで触れたように、Verified Access のコンポーネントは複数作成して組み合わせることが出来ます。
ただし、リージョンごとに各コンポーネントの上限数が設定されているのでご注意ください。

サービスクォータから上限緩和申請が可能ですので、必要に応じて以下からリクエストを送信してください。

さいごに

本日は AWS Verified Access の主要な 4 つのコンポーネント構造を整理してみました。
また、それぞれのコンポーネントを複数利用する際に、どのように組み合わせたら良いかについても確認してみました。

どういう時にどのコンポーネントを組み合わせたら良いか理解が進みました（私は）