AWS Systems Manager（SSM） を使ったEC2へのセキュアなSSH接続

一般的なEC2へのSSH接続

EC2インスタンスへ接続する最も一般的な方法は、従来の SSH 接続です。構成としては以下のようになります。

EC2インスタンスの作成時にキーペアを発行・ダウンロードする
セキュリティグループでポート 22（SSH）のインバウンドを許可する
ダウンロードした秘密鍵（.pem ファイル）を使って接続する

ssh -i ~/.ssh/my-key.pem ec2-user@<パブリックIPアドレス>

シンプルで分かりやすい反面、この方式にはいくつかの運用上の問題が伴います。

秘密鍵の管理コスト

キーペアは発行した時点でしかダウンロードできません。紛失すれば再発行が必要で、複数人でサーバーを管理する場合は鍵の配布・失効管理が必要になります。

ポート22の開放によるリスク

SSH ポートをインターネットに公開すると、ブルートフォース攻撃やポートスキャンの標的になります。接続元IPを絞るとしても、VPN経由でなければ固定IPを持たないメンバーへの対応が課題になります。

踏み台サーバーの運用コスト

プライベートサブネットに配置したインスタンスへ接続するために踏み台サーバー（Bastion Host）を用意するケースも多いですが、踏み台サーバー自体のメンテナンス・セキュリティ管理・コストが追加で発生します。

セキュリティグループの管理が必要

EC2への接続を安全に保つためには、セキュリティグループの適切な管理が欠かせません。

よくある設定ミスとリスク

ソースIPを 0.0.0.0/0（全許可）にしたままのセキュリティグループは、インターネット上のあらゆるホストから SSH 接続を試みられる状態になります。実際、EC2インスタンスを立ち上げてポート22を全開放すると、数分以内にブルートフォース試行のログが残ることも珍しくありません。

# /var/log/secure の例（ポート22全開放時）
Apr 20 03:12:44 sshd[1234]: Failed password for invalid user admin from 185.xxx.xxx.xxx port 54321 ssh2
Apr 20 03:12:45 sshd[1235]: Failed password for invalid user root from 185.xxx.xxx.xxx port 54322 ssh2
Apr 20 03:12:46 sshd[1236]: Failed password for invalid user ubuntu from 185.xxx.xxx.xxx port 54323 ssh2

適切な制限を設けてもなお残る課題

接続元IPをオフィスや VPN に限定すれば攻撃リスクは下がりますが、以下の課題は残ります。

リモートワーク中のメンバーが自宅の動的IPから接続する際、都度セキュリティグループを更新する必要がある
セキュリティグループの変更履歴管理が煩雑になる
緊急対応時に「誰がどのIPを追加したか」の追跡が難しい
複数のアカウント・リージョンにまたがる場合、管理対象が増大する

こうした課題を解消する手段として登場するのが AWS Systems Manager（SSM） です。

AWS Systems Manager（SSM）とは

AWS Systems Manager（SSM）は、AWS リソースの運用管理を一元化するサービス群です。その中の Session Manager という機能を使うと、ポート22を一切開放せずに EC2インスタンスへの接続が可能になります。

仕組み

Session Manager は、EC2インスタンス上で動作する SSM Agent が AWS の Systems Manager エンドポイントへアウトバウンド通信を確立し、そのトンネル経由でセッションを実現します。通信の向きがインバウンドではなくアウトバウンドであるため、セキュリティグループでのインバウンドポート開放が不要になります。

ユーザーのPC
　　↓（AWS CLI / マネジメントコンソール）
AWS Systems Manager エンドポイント
　　↓（アウトバウンド HTTPS:443 のみ）
EC2インスタンス（SSM Agent が常駐）

SSM を使うメリット

ポート22の完全クローズ

セキュリティグループのインバウンドルールから SSH（ポート22）を削除できます。攻撃対象となるポートが存在しないため、ブルートフォースやポートスキャンの影響を受けません。

キーペア不要

SSM Session Manager を経由した接続では SSH 秘密鍵が不要です。キーの配布・管理・失効という運用コストがなくなります。

IAM による認証・認可

接続の権限は IAM ポリシーで制御します。ユーザーやロールに対して ssm:StartSession 権限を付与・剥奪するだけで、アクセス管理を一元化できます。

操作ログの自動記録

セッション中のすべての操作を CloudWatch Logs や S3 に自動的に記録できます。誰が・いつ・何を実行したかの証跡が残るため、監査対応が容易になります。

プライベートサブネットのインスタンスへも接続可能

パブリック IP なし・踏み台サーバーなしで、プライベートサブネットのインスタンスに直接接続できます。VPC エンドポイントを使えばインターネット経由のトラフィックも不要になります。

SSM を使用した接続の例

前提条件の確認

SSM Session Manager を使うには以下が必要です。

EC2インスタンスに SSM Agent がインストールされていること（Amazon Linux 2 / Amazon Linux 2023 はデフォルトでインストール済み）
インスタンスに IAM インスタンスプロファイル がアタッチされており、AmazonSSMManagedInstanceCore ポリシーが含まれていること
SSM エンドポイントへのアウトバウンド通信（HTTPS:443）が許可されていること

IAM ポリシーの設定

EC2 インスタンスにアタッチする IAM ロールに、以下のマネージドポリシーを付与します。

{
　"Version": "2012-10-17",
　"Statement": [
　　{
　　　"Effect": "Allow",
　　　"Principal": {
　　　　"Service": "ec2.amazonaws.com"
　　　},
　　　"Action": "sts:AssumeRole"
　　}
　]
}

ロールには AmazonSSMManagedInstanceCore を付与するだけで SSM Session Manager が利用可能になります。

マネジメントコンソールから接続する

AWS マネジメントコンソールで EC2 の画面を開く
対象インスタンスを選択し、「接続」ボタンをクリック
「Session Manager」タブを選択して「接続」をクリック

ブラウザ上でターミナルが開き、すぐに操作できます。

AWS CLI から接続する

AWS CLI と Session Manager Plugin をインストール済みであれば、ローカルのターミナルから以下のコマンドで接続できます。

# Session Manager でシェルを起動
aws ssm start-session --target i-0123456789abcdef0

# 接続後はそのままコマンドを実行できる
sh-4.2$ whoami
ssm-user
sh-4.2$ sudo su - ec2-user

SSH over SSM（ポートフォワーディング）

SSH クライアントの使い慣れた操作感を保ちつつ SSM 経由で接続したい場合は、~/.ssh/config に以下を追加します。

# ~/.ssh/config
host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

設定後は通常の ssh コマンドでインスタンスID を指定して接続できます。ポート22のインバウンドは不要のままです。

# インスタンスIDを指定するだけで SSM 経由で SSH 接続できる
ssh -i ~/.ssh/my-key.pem ec2-user@i-0123456789abcdef0

セッションログの S3 出力設定

Systems Manager のコンソールから「セッションマネージャー」→「設定」を開き、ログの出力先として S3 バケットや CloudWatch Logs グループを指定します。設定後は、すべてのセッションの操作ログが自動的に記録されます。

# S3 に保存されたログの確認例
aws s3 ls s3://my-ssm-logs/ssm-session-logs/

# ログの内容を確認
aws s3 cp s3://my-ssm-logs/ssm-session-logs/my-session-id.log - | cat

まとめ

従来の SSH 接続と SSM Session Manager を比較すると、以下のようになります。

項目	従来の SSH 接	SSM Session Manager
ポート22の開放	必要	不要
秘密鍵の管理	必要	不要
接続元IP制限	セキュリティグループで管理	IAM で管理
踏み台サーバー	プライベートサブネットでは必要	不要
操作ログ	別途設定が必要	自動記録可能
プライベートサブネット	踏み台が必要	直接接続可能

SSM Session Manager を導入することで、ポート管理・鍵管理・踏み台管理という三つの運用負荷をまとめて解消できます。セキュリティグループからポート22のインバウンドルールを削除するだけで攻撃対象面が大幅に縮小されるため、新規環境はもちろん既存環境への導入も積極的に検討する価値があります。

まず手軽に試すなら、既存の EC2 インスタンスに AmazonSSMManagedInstanceCore ポリシーを付与した IAM ロールをアタッチするだけです。SSM Agent は Amazon Linux 系であればすでに動作しているので、その日のうちに Session Manager 経由での接続を確認できます。

AWS Systems Manager（SSM）を使ったEC2へのセキュアなSSH接続