AWS Verified Access が非 HTTP(S) プロトコルを介したリソースへの安全なアクセスのサポートを開始 (プレビュー)

AWS Verified Access は、仮想プライベートネットワーク (VPN) なしで、企業のアプリケーションとリソースへの安全なアクセスを提供します。当社は 2 年前の re:Invent で、企業アプリケーションへの VPN なしの安全なアクセスを提供するための手段として、プレビュー版の Verified Access をリリースしました。これを利用することで、組織は IP アドレスではなく ID とデバイスのセキュリティに基づいてネットワークアクセスを管理できるため、アプリケーションアクセスのコントロールとセキュリティが強化されます。

12 月 1 日、Verified Access は、非 HTTP(S) アプリケーションおよびリソースへの VPN なしの安全なアクセス機能のプレビューをリリースしました。これを利用することで、Secure Shell (SSH) や Remote Desktop Protocol (RDP) などのプロトコルを介して企業リソースへのゼロトラストアクセスを実現できます。

組織では、データベース、リモートデスクトップ、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの内部リソースに対する安全なリモートアクセスがますます求められています。従来の VPN ソリューションは、ネットワークアクセスでは効果的ですが、多くの場合、広範な特権を付与するものであり、きめ細かいアクセスコントロールをサポートしていないため、機密データを含むインフラストラクチャが公開される可能性があります。一部の組織はアクセスを仲介するために踏み台ホストを使用していますが、このアプローチでは、HTTP(S) アプリケーションと非 HTTP(S) アプリケーション間で複雑さとポリシーの不一致が生じる可能性があります。ゼロトラストアーキテクチャの台頭により、これらのギャップは、すべてのアプリケーションとリソースにわたって一貫したアクセスポリシーを拡張する安全なアクセスソリューションの必要性を浮き彫りにしています。

Verified Access は、企業のアプリケーションとリソース向けにゼロトラストのアクセスコントロールを提供することで、これらのニーズに対応します。SSH、RDP、Java Database Connectivity (JDBC)、Open Database Connectivity (ODBC) などのプロトコルをサポートすることで、Verified Access はセキュリティオペレーションを簡素化します。今後は、企業のアプリケーションとリソース全体で、統一されたコンテキスト対応のアクセスポリシーを確立できるようになりました。Verified Access は、各アクセスリクエストをリアルタイムで評価し、特定の ID およびデバイスセキュリティ要件を満たすユーザーにのみアクセスが付与されるようにします。さらに、個別の VPN や踏み台ホストが不要になるため、運用が効率化され、過剰な特権が付与された状態でのアクセスのリスクが軽減されます。

私のお気に入りの機能の 1 つは、一度に 1 つのリソースをオンボーディングするのではなく、IP Classless Inter-Domain Routing (CIDR) とポートを指定することによってリソースのグループをオンボーディングする機能です。Verified Access は、指定された CIDR 範囲内のアクティブなリソースごとに DNS レコードを自動的に作成します。これにより、手動での DNS 設定が不要になり、ユーザーは新しいリソースに即座に接続できます。

非 HTTPS アクセスのための Verified Access の使用
非 HTTPS アクセスのために Verified Access を設定することは、現在のものとそれほど変わりません。開始方法については、2 年前にプレビューをリリースしたときに書いたブログ記事または「Verified Access の使用を開始する」チュートリアルをお読みください。

Verified Access は、1 つの単一リソースのターゲットと複数のリソースのターゲットという 2 つの新しいタイプのエンドポイントターゲットを提案します。

ネットワークインターフェイス、ロードバランサー、または RDS エンドポイントターゲットを使用すると、Amazon Relational Database Service (Amazon RDS) インスタンスや、Network Load Balancer または Elastic Network Interface の背後にある任意の TCP アプリケーションなどの個別のリソースへのアクセスを提供できます。このタイプのターゲットエンドポイントは、ターゲットタイプ (ロードバランサーやネットワークインターフェイスなど) と、TCP ポートの範囲の組み合わせによって定義されます。Verified Access は、エンドポイントの作成時に各エンドポイントの DNS 名を提供します。各ターゲットには、Verified Access DNS 名が割り当てられます。これは、エンドユーザーがリソースに安全にアクセスするために使用する名前です。

ネットワーク CIDR エンドポイントターゲットでは、リソースは IP CIDR とポート範囲を使用して定義されます。このタイプのエンドポイントターゲットを使用すると、SSH や RDP などのプロトコルを介して、EC2 インスタンスなどのエフェメラルリソースへの安全なアクセスを簡単にプロビジョニングできます。これは、リソースが追加または削除されるたびにエンドポイントターゲットを作成または削除するなどのアクションを実行することなく行われます。定義された CIDR から IP アドレスがこれらのリソースに割り当てられている限り、Verified Access は、定義された CIDR で検出されたアクティブな IP ごとに一意のパブリック DNS レコードを提供します。

このデモの設定の図を以下に示します。

パート 1: Verified Access 管理者として

Verified Access 管理者として、Verified Access インスタンス、信頼プロバイダー、アクセスグループ、エンドポイント、およびアクセスポリシーを作成し、エンドユーザーが SSH サーバーにアクセスできるようにします。

このデモでは、Verified Access ネットワーク CIDR エンドポイントターゲットを設定します。[プロトコル] として [TCP] を選択し、[エンドポイントタイプ] として [ネットワーク CIDR] を選択します。[CIDR] の範囲が、ターゲットリソースが存在している VPC の 1 つに収まっているようにします。VPC 内の TCP [ポート範囲] と [サブネット] を選択します。

これは、足を伸ばしてコーヒーをお代わりするのに最適な瞬間です。エンドポイントの作成には数分かかります。

ステータスが ✅ [アクティブ] になったら、プライベート Amazon Virtual Private Cloud (Amazon VPC) で EC2 インスタンスを起動します。SSH を有効にして、VPC からのリクエストにのみアクセスするようにインスタンスのセキュリティグループを設定します。数分後、インスタンス IP が検出され、Verified Access クライアントアプリケーションから接続するための DNS 名が割り当てられます。

また、設定中に、secure.mycompany.com などの独自の DNS サブドメインを委任するオプションがあり、Verified Access はそのサブドメイン内のリソースのために DNS 名を割り当てます。

アクセスポリシーを作成する

この段階では、Verified Access エンドポイントでポリシーは定義されていません。デフォルトではあらゆるリクエストが拒否されます。

[Verified Access グループ] ページで、[ポリシー] タブを選択します。その後、[Modify Verified Access endpoint policy] (Verified Access エンドポイントポリシーを変更) ボタンを選択してアクセスポリシーを作成します。

認証されており、メールアドレスが @amazon.com で終わるすべてのユーザーを許可するポリシーを入力します。これは、AWS IAM アイデンティティセンターで定義されたユーザーのために使用したメールアドレスです。context の後の名前は、[Verified Access 信頼プロバイダー] を作成した際に [ポリシー参照名] として入力した名前であることに留意してください。ドキュメントページには、使用できるポリシー構文、属性、演算子の詳細が記載されています。

permit(principal, action, resource)
when {
    context.awsnewsblog.user.email.address like "*@amazon.com"
};

数分後、Verified Access はポリシーを更新し、再び [アクティブ] になります。

クライアントに設定を配布する

Verified Access 管理者としての最後のタスクは、クライアントアプリケーションの JSON 設定ファイルを抽出することです。

クライアントアプリケーション設定ファイルは、AWS コマンドラインインターフェイス (AWS CLI) を使用して取得します。システム管理者として、この設定を各クライアントマシンに配布します。

aws ec2 export-verified-access-instance-client-configuration \
     --verified-access-instance-id "vai-0dbf2c4c011083069"

{
    "Version": "1.0",
    "VerifiedAccessInstanceId": "vai-0dbf2c4c011083069",
    "Region": "us-east-1",
    "DeviceTrustProviders": [],
    "UserTrustProvider": {
        "Type": "iam-identity-center",
        "Scopes": "verified_access_test:application:connect",
        "Issuer": "https://identitycenter.amazonaws.com/ssoins-xxxx",
        "PkceEnabled": true
    },
    "OpenVpnConfigurations": [
        {
            "Config": "Y2...bWU=",
            "Routes": [
                {
                    "Cidr": "2600:1f10:4a02:8700::/57"
                }
            ]
        }
    ]
}

接続するリソースと Verified Access インフラストラクチャの準備が整ったので、ネットワークエンドポイントにアクセスするためのエンドユーザーエクスペリエンスを皆様にご紹介します。

パート 2: エンドユーザーとして

エンドユーザーとして、Verified Access Connectivity Client アプリケーションをダウンロードしてインストールするためのリンクを受け取ります。この記事の執筆時点では、Windows および macOS クライアントがサポートされています。

管理者から受け取った設定ファイルをインストールします。ファイル名として ClientConfig1.json を使用し、Windows の場合は C:\ProgramData\AWSPylon、macOS の場合は /Library/Application Support/com.aws.pylon.client にそのファイルをコピーします。

これはすべてのユーザーについて同じ設定ファイルであり、システム管理者はエンドポイント管理ツールを使用してすべてのクライアントマシンにそのファイルをプッシュする場合があります。

Connectivity Client アプリケーションを起動します。認証シーケンスを開始するには、[サインイン] を選択します。

認証により、ウェブブラウザが開き、ID プロバイダーの認証ページが表示されます。実際の画面とログインシーケンスはプロバイダーによって異なります。認証されると、Connectivity Client は、リソース (このデモでは EC2 インスタンス) にアクセスするための安全なトンネルを作成します。

ステータスが [接続済み] になると、Verified Access によって提供される DNS 名を使用して、リソースに安全に接続できます。ターミナルアプリケーションで、ssh コマンドを入力して接続を開始します。

このデモでは、Verified Access のために委任された DNS ドメイン secure.mycompany.com を設定しました。EC2 インスタンス用に受け取った DNS アドレスは 10-0-1-199.awsnews.secure.mycompany.com です。

$ ssh -i mykey.pem ec2-user@10-0-1-199.awsnews.secure.mycompany.com

   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://thinkwithwp.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
Last login: Sat Nov 17 20:17:46 2024 from 1.2.3.4

$

利用可能なリージョンと料金
Verified Access は、次の 19 の AWS リージョンでパブリックプレビューとしてご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (ジャカルタ、ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、イスラエル (テルアビブ)、南米 (サンパウロ)。

非 HTTP(S) Verified Access エンドポイントがアクティブな間、各接続について 1 時間ごとに課金されます。各 Verified Access エンドポイントにおいて、1 か月あたり最初の 100 件の接続は無料です。詳細については、「AWS Verified Access の料金」をご覧ください。

HTTP(S) および非 HTTP(S) アプリケーションのために Verified Access を使用すると、プライベートアプリケーションとシステムに対するアクセスコントロールを統合し、すべてのアプリケーション、SSH、RDP、HTTP(S) リソースに対してゼロトラストポリシーを一様に適用できます。これは、ネットワークインフラストラクチャの複雑さを軽減するとともに、アプリケーションとリソースに対するゼロトラストアクセスを実装するのに役立ちます。最後に、成長し続けるインフラストラクチャに適応して、DNS 設定を自動化するとともに、リソース固有の登録なしで大規模なデプロイをサポートします。

今すぐ Verified Access をお試しいただき、チームとフィードバックをご共有ください。

— seb

原文はこちらです。