EC2インスタンスのリモートアクセスについて考える

はじめに

こんにちは、あるいはこんばんは　なかはらです。今ハマっている漫画のなかでのあいさつです。 AWSのVPC内に作成したLinux,Windowsインスタンスへアクセスするには、いくつか方法があります。インスタンスに直接アクセスする、踏み台サーバ(AWSではBation Hostsという)経由でアクセス、AWSサービスを使ってアクセスするなど、様々な方法でアクセスできます。それぞれの特徴をまとめてみました。

リモートアクセスの手段

• インスタンスに直接アクセス

パブリックサブネットに配置されている且つ、グローバルIPアドレスがアタッチされているインスタンスであれば、直接アクセスできます。踏み台サーバが不要で既存のSSHクライアントやリモートデスクトップクライアントを利用してアクセスできます。さらにセキュリティグループのインバウンドルールで送信元(xxx.xxx.xxx.xxx/32)を制限することができます。 ただし、セキュリティグループに誤ったルールを設定(すべてのトラフィック, 0.0.0.0/0)してしまった場合は、総当たり攻撃の危険にさらされることになります。

• 踏み台サーバを利用

VPC内のプライベートサブネットに配置されているインスタンスに踏み台サーバ経由でアクセスできます。既存のSSHクライアントやSSHポートフォワーディングによるリモートデスクトップクライアントが利用できます。踏み台サーバにリモートアクセスを集中できる為、アクセス管理が容易になります。 踏み台サーバありきの構成なので踏み台サーバのインスタンスの利用料が発生します。さらにAZ障害など考えて冗長化させるとインスタンスの利用料とAWSリソース(踏み台サーバ2台)が2倍になります。

• AWS Systems Manager Session Managerを利用

インスタンスに直接アクセスする構成と似ていますが、AWS Systems Manager Session Managerの通信要件は、セキュリティグループのインバウンドルールは不要です。SSM関連sitaAWSサービスエンドポイントにアウトバウンド通信(セキュリティグループでは、デフォルトでアウトバウンド通信はすべて許可)できればIAM権限でリモートアクセスできます。さらにリモートアクセスのアクティビティをS3に保管することでアクセス管理が容易となります。 プライベートサブネットにあるインスタンスは、NatGatewayを配置して、アウトバウンド通信を満たすことでリモートアクセスが可能となります。踏み台サーバの利用と同様にNatGatewayの利用料が発生すること、AZ障害を考慮して冗長化を検討する必要があります。 NatGatewayを利用しない場合は、VPCエンドポイント経由でAWSサービスエンドポイントとアウトバウンド通信要件を満たすことが可能です。サービスエンドポイント毎に各AZのサブネットを指定して冗長化できます。VPCエンドポイント毎に利用料が発生します。

結局どれがいいの？

システム要件により選定基準が変わるため、一概にこれが良いとは言えません。 リモートアクセスで重要なことは、「誰が」「いつ」「何をしたのか」を管理できることだと思っています。そのためのユーザ管理、アクセス制御、作業証跡の保管、定期的なモニタリングを実現できる仕組みを取り入れることが重要だと考えます。それぞれの特徴を理解して安全なメンテナンスの実現を目指していきましょう。