SSMで踏み台サーバーを廃止！安全にEC2へ接続する設定手順まとめ

By /

はじめに

インフラの設計・運用において、プライベートサブネットに配置されたEC2インスタンスへのセキュアなアクセス経路の確保は、常にセキュリティ上の重要な課題です。かつては「踏み台サーバー（Bastion Host）」をパブリックサブネットに構築するのが主流でしたが、現在では運用保守コストやセキュリティリスクを低減するため、AWS Systems Manager（SSM）の「Session Manager」を利用した接続方法がベストプラクティスとなっています。

本記事では、踏み台サーバーを一切使わずに、完全にプライベートな環境にあるEC2インスタンスへ、安全かつシンプルにシェル接続するための設計と具体的な設定手順を解説します。

前提知識/必要な理由

踏み台サーバーが抱える課題

従来の踏み台サーバー方式には、以下のような運用負荷とセキュリティリスクが存在していました。

  • 踏み台サーバー自体のOSパッチ管理や脆弱性対応が必要。
  • SSHキー（鍵ファイル）の配布や管理が煩雑になり、紛失や漏洩のリスクがある。
  • ポート22をインターネットに開放する必要があり、常に不正アクセスの標的にされる。

SSM Session Managerを導入すべき理由

Session Managerを採用することで、これらの課題を一挙に解決できます。

  • ポート開放が不要： EC2側からSSMのエンドポイントへアウトバウンド（HTTPS/443）で接続を確立するため、インバウンドポート（22や3389）を完全に閉じた状態で接続可能です。
  • 鍵管理からの解放： IAMポリシー（AWS IAM）によってアクセス権限を一元管理でき、SSHキーの共有や管理が不要になります。
  • 強固な監査ログ： 誰が、いつ、どのインスタンスで、どのようなコマンドを実行したかを、CloudWatch LogsやS3に自動で記録できます。

具体的な設定手順・設計方法

プライベートサブネット（インターネットゲートウェイおよびNATゲートウェイなし）のEC2インスタンスに、Session Manager経由で接続するための設定手順を3つのステップで解説します。

手順1：EC2用のIAMロール（インスタンスプロフィール）の作成

EC2インスタンスがSSMサービスと通信するための権限を付与します。

  1. AWSマネジメントコンソールの「IAM」画面を開き、「ロールの作成」をクリックします。
  2. 信頼されたエンティティタイプで「AWSのサービス」を選択し、ユースケースに「EC2」を指定します。
  3. 許可ポリシーの追加画面で、AWS管理ポリシーである AmazonSSMManagedInstanceCore を検索し、チェックを入れます。
  4. ロール名（例: EC2-SSM-Access-Role）を入力し、ロールを作成します。

手順2：VPCエンドポイントの設定（インターネット通信がない場合）

プライベートサブネット内のEC2からAWS SSM APIへ接続するために、VPCエンドポイント（AWS PrivateLink）を作成します。以下の3つのインターフェイス型エンドポイントが必要です。

  • com.amazonaws.[リージョン名].ssm
  • com.amazonaws.[リージョン名].ssmmessages
  • com.amazonaws.[リージョン名].ec2messages

【セキュリティグループの設計】

VPCエンドポイントに紐付けるセキュリティグループ（例: ssm-vpce-sg）を作成し、以下のようにインバウンドルールを設定します。

[インバウンドルール]
- プロトコル: TCP
- ポート範囲: 443
- 送信元: EC2インスタンスが所属するサブネットのCIDR（例: 10.0.0.0/16）

※EC2インスタンス自身に紐付けるセキュリティグループのアウトバウンドルールでは、上記VPCエンドポイントへの「HTTPS (ポート443)」での送信を許可しておいてください。

手順3：EC2インスタンスの起動と接続テスト

  1. プライベートサブネット内に、OS「Amazon Linux 2023」（SSM Agent標準インストール済み）のEC2を起動します。
  2. 起動時、高度な詳細設定の「IAM インスタンスプロフィール」に、手順1で作成した EC2-SSM-Access-Role を割り当てます。
  3. EC2が起動したら、AWS CLIがインストールされたローカルPCから接続を試行します。

※注意：ローカルPCからAWS CLI経由で接続を行う場合、事前に「Session Manager Plugin」のインストールが必要です。 以下に、ローカル環境（Mac/Windows）への導入手順を記載します。

【macOS（Homebrew）でのプラグイン導入例】

# Session Manager Pluginのインストール
brew install --cask session-manager-plugin

# インストールの確認
session-manager-plugin --version

【Windows（PowerShell）でのプラグイン導入例】

# MSIインストーラーのダウンロードと実行
Start-BitsTransfer -Source https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows_64bit/SessionManagerPluginSetup.msi -Destination .\SessionManagerPluginSetup.msi
Start-Process msiexec.exe -ArgumentList '/i SessionManagerPluginSetup.msi /quiet' -Wait

プラグインが導入できたら、以下のAWS CLIコマンドを実行して、ローカル端末からプライベートEC2へ直接SSHのようにシェル接続します。

# AWS CLIでの接続コマンド（インスタンスIDを指定）
aws ssm start-session --target i-0123456789abcdef0

実務での注意点

  • DNS解決の有効化： VPCエンドポイントを使用する場合、対象VPCの設定で「DNSホスト名」および「DNS解決」の両方が「有効（Enabled）」に設定されている必要があります。これが無効になっていると、SSM Agentがプライベートエンドポイントの名前解決を行えず、接続に失敗します。
  • SSM Agentの自動更新： SSM Agentの不具合や古いバージョンでの脆弱性を防ぐため、Systems Managerの「高速セットアップ（Quick Setup）」を利用して、Agentの自動更新を有効化しておくのが実務でのベストプラクティスです。
  • 接続ログの暗号化： 操作ログをCloudWatch LogsやS3に転送する際は、ログ自体の暗号化（KMSによる暗号化）を有効にし、重要情報の漏洩リスクを最小限に抑えましょう。

まとめ

AWS Systems Manager Session Managerを導入することで、これまで運用負荷やセキュリティリスクの原因だった「踏み台サーバー」を完全に廃止することができます。VPCエンドポイントを正しく設計すれば、インターネットに一切公開されていない極めて安全なプライベートネットワーク内であっても、シームレスにEC2へのシェルアクセスが可能です。ぜひ本設定手順を参考に、堅牢なAWSインフラを構築してください。

Related Posts

上部へスクロール