MEGAZONE

MEGAZONEブログ

Secure remote connectivity to AWS
Networking & Content Delivery re:Invent 2023

Secure remote connectivity to AWS

Pulisher : Strategic Tech Center ソ・ジョンス
Description : AWSプライベートにあるリソースとオンプレミスリソースへのアクセス方法についての紹介セッション

AWSプライベートにあるリソースとオンプレミスリソースにアクセスする方法についてのセッションですが、普段構築業務のためにお客様によくガイドする内容以外に追加で得られる情報があるのか気になり申し込みました。

AWS Client VPNとAmazon EC2 ConnectおよびAWS Systems ManagerのSession ManagerとAWS Verified Accessの動作原理について説明し、最後にAvalon Healthcare社が直面している問題に対する解決方法を説明するセッションでした。

ユーザーがパブリックな空間にいると仮定し、プライベートリソースにアクセスするユースケースをネットワーク層とアプリケーション層(SSH,RDP,HTTP/S)に分けて、各ケースごとにどのようなAWSサービスを導入すれば良いかについてアプローチしました。

まず、AWS Client VPNを使用するためには、Client VPNソフトウェアを使用し、証明書/Active Directory/SAML 2.0認証方式を通じてPrivateに位置するリソースと通信が可能で、分割トンネル(Client VPN通信指定対象CIDRはClient VPN Endpointを通じてトラフィックを移動し、その他のアクセスはマイPCの基本ルーティングを通じてインターネットで通信)またはフルトンネル(すべての通信をClient VPN Endpointに転送)方式でトンネリングの選択が可能で、AWS Client VPNを通じて様々な接続(TGW、WAN、Peering、PrivateLink)が可能です。

SSHアクセスのためにPublic網にEC2を置いてIPを制限するなど(通常はBastionサーバーやジャンプサーバーと呼ばれる)でよく使われますが、キーのライフサイクル管理やインターネット網を通じた直接接続などの問題でAmazon EC2 Instance ConnectやAWS Systems Manager Session Managerの使用を代替として提案し、二つの方式の動作方法と技術比較をしました。

HTTP/Sにアクセスするためには、一般ユーザーはインターネットでアクセスしますが、管理者ページは管理者のみアクセスする必要があるなど、もう少し細分化されたアプローチが必要で、AWS Verified Accessを使用してこの問題を解決するのに役立ち、AWS Verified Accessはゼロトラストの原則に合わせて実装されたそうです。 (ここで、Zero TrustとはIDとアクセス管理に対するアプローチで、どのユーザーやソフトウェアも信頼できないと仮定し、すべてのユーザー、デバイス、アプリケーションはリソースにアクセスする前にアクセス権限を証明しなければなりません)。

Verified Accessは権限をもう少し細かく分離可能で、様々な既存の認証体系やObservability providerとの連携が可能で、AWS WAFを連携してセキュリティも強化されたそうです。

Avalon Healthcare社はAVA(AWS Verified Access)を使用する前は、Client VPNやWorkspaceなどを通じたアクセスやTableauの使用などについて課題がありましたが、AVAを導入してから、アーキテクチャと使いやすさがシンプルになったそうです。

構築業務を担当しており、Client VPNとSession Managerは頻繁に使用したり、顧客にガイドすることもありますが、AVAについてはあまり使う機会がなかったのですが、今回のセッションを通じて興味を持つようになり、学習後に適用して良い事例を作ってみたいと思います。

ブログ一覧

この記事の読者はこんな記事も読んでいます