AWSへのセキュアなリモート接続

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

はじめに

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

セッションの概要紹介

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

ユーザーがPublicな空間にいると仮定し、Privateリソースにアクセスするユースケースをネットワーク層とアプリケーション層(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についてはあまり使用する機会がなかったのですが、今回のセッションを通じて興味を持ち、学習後に適用して良い事例を作りたいと思います。