AWS Verified Access 経由でプライベートサブネット上の EC2 にリモートデスクトップ接続してみた

AWS Verified Access 経由でプライベートサブネット上の EC2 にリモートデスクトップ接続してみた

Clock Icon2025.01.24

プレビュー ではありますが、昨年 AWS Verified Access の非 HTTPS(S) プロトコルがサポートされました。

本エントリでは、Verified Accessを使用して、プライベートサブネット上にある EC2 にリモートデスクトップ接続する方法を紹介します。

以下のブログを参考に設定しました。いつもありがとうございます。

https://aws.amazon.com/jp/blogs/news/aws-verified-access-now-supports-secure-access-to-resources-over-non-https-protocols/

https://dev.classmethod.jp/articles/aws-verified-access-secure-access-resources-non-https-protocols-preview/

やってみた

検証環境

検証環境の構成図は以下のとおりです。

20250113-verified-access-rdp-001

IAM Identity Center で認証されたユーザーであれば、インターネットから Verified Access を経由し、プライベートサブネット上の EC2 にリモートデスクトップ接続できます。

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

Verified Access 信頼プロバイダーを作成します。

20250113-verified-access-rdp-002-2

ポリシー参照名は 32 文字以内であることと、ハイフンをサポートしていないので注意してください。

信頼プロバイダータイプでは、ユーザー信頼プロバイダーを選択し、ユーザーの信頼プロバイダータイプに IAM Identity Center を選択しました。。

検証環境では既に IAM Identity Center を有効化していたのでステータスが有効になっていました。

Verified Access インスタンスの作成

Verified Access インスタンスを作成します。

20250113-verified-access-rdp-003

事前に作成しておいた Verified Access 信頼プロバイダーを指定します。

Verified Access グループの作成

Verified Access グループを作成します。

20250113-verified-access-rdp-004-2

事前に作成しておいた Verified Access インスタンスを指定します。

ポリシーは公式ドキュメントで紹介されているものを参考にしました。

以下のポリシーにより、IAM Identity Center で認証されたすべてのユーザーではなく、特定のグループに所属したユーザーの利用に限定することが可能です。

permit(principal,action,resource)
when {
    context.devio_provider_policy.groups has "d754XXXX-XXXX-XXXX-XXXX-XXXXXXXXX389"
};

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

Verified Access エンドポイントを作成します。

20250113-verified-access-rdp-006

CIDR は Verified Access がアクセスできるネットワーク範囲をしていします。

今回は VPC の CIDR にしましたが、特定のサブネットの CIDR の範囲に限定することも可能です。

本エントリのケースでは、RDP(3389) の利用のみ考えているので 3389-3389 としました。

マネジメントコンソール上では 70~110 で表現されているのですが、実際はハイフンである必要があるので注意です。

Verified Access グループで設定したポリシーが継承されるので、ここでは設定していません。

もし、エンドポイントごとにポリシーを変更したければ設定します。

あらかじめ、Verified Access エンドポイント用に、以下のような Security Group を作成しておいたので指定しました。

20250113-verified-access-rdp-005

リモートから Verified Access エンドポイントにアクセスするために、アクセス元 IP からのアクセスを許可するインバウンドルールの追加は必要ありません。

エンドポイントが有効になるまで10分くらい掛かるので気長に待ちましょう。

検証用 EC2 の作成

Windows Server 2025 の EC2 を起動しました。

特別な設定はしていないので詳細は割愛しますが、EC2 に設定した Security Group は以下のとおりです。

Verified Access エンドポイントの Security Group からのみ RDP(3389) のアクセスを許可するようにしています。

20250113-verified-access-rdp-007

Connectivity Client for AWS Verified Access を設定する

ユーザーデバイスと非 HTTP(S) アプリケーション間の接続を可能にする Connectivity Client が AWS から提供されています。

Connectivity Client for AWS Verified Access - AWS Verified Access

なのでここからは、Connectivity Client を設定していきます。

Connectivity Client は以下の OS を対象に用意されています。

  • Windows用
  • Apple Silicon 搭載 Mac用
  • Intel 搭載 Mac 用

本エントリでは Apple Silicon 搭載 Mac クライアントをダウンロードしました。

つぎに、クライアント構成ファイルをユーザーデバイス側に設定します。

このクライアント構成ファイルは、Verified Access インスタンスを作成していれば、マネジメントコンソールや AWS CLI からダウンロードが可能です。

なお、Verified Access エンドポイントが起動していないとダウンロードできないので注意してください。

20250113-verified-access-rdp-009

ダウンロードした構成ファイルの内容を ClientConfig-1.json というファイル名で配置します。

$ sudo vi /Library/Application\ Support/Connectivity\ Client/ClientConfig-1.json

それでは、Connectivity Client を起動します。

20250113-verified-access-rdp-010

サインイン をクリックすると IAM Identity Center のログイン画面に遷移します。

20250113-verified-access-rdp-012

ログインすると Connectivity Client に Verified Access へのアクセス許可を求められるの許可します。

20250113-verified-access-rdp-013

許可をすると接続中のステータスになり、

20250113-verified-access-rdp-014

接続済みになりました。

20250113-verified-access-rdp-015

これで Connectivity Client の設定が完了です。

EC2 にリモートデスクトップ接続する

Verified Access エンドポイントが起動していると、EC2 が自動認識されて、ドメインが払い出されます。

20250113-verified-access-rdp-016

このドメインを利用して、後は普通にリモートデスクトップ接続します。

接続できました!

20250113-verified-access-rdp-017

おわりに

Veridied Access 経由でプライベートサブネット上の EC2 にリモートデスクトップ接続してみました。

Verified Access の非 HTTP(S) プロトコルのサポートは、まだプレビュー機能です。

実際にリリースされるのか、リリースされても本エントリで紹介したような使い方ができるのかは不明ですが、Session Manager や EC2 Instance Connect に並ぶ、EC2 への新しい接続方法になると思いました。

実は、本エントリを執筆した背景に以下のような要件を満たす構成の検討をしていた、というのがあります。

  • マネジメントコンソールや AWS CLI の操作をさせず、通常のリモートデスクトップ接続の方法をユーザーに提供したい
  • ユーザーの接続元の IP アドレスが固定されないので、Security Group で許可しようにも /16 になってしまうが/16では許可したくない

IAM Identity Center 利用中の環境であり、Verified Access がこの要件を満たせそうなので、非 HTTP(S) プロトコルサポートの GA を心待ちにしています。

本エントリが、どなたかのお役に立てれば幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.