SSMセッションマネージャーでEC2に安全接続する設定手順

はじめに

AWSでEC2インスタンスを構築する際、SSH用のポート（22番）をインターネットに公開することは大きなセキュリティリスクを伴います。本記事では、踏み台サーバーやSSH鍵を使用せず、ブラウザやAWS CLIから安全にEC2へ接続できる「AWS Systems Manager Session Manager（セッションマネージャー）」の具体的な構築手順と設計のベストプラクティスを解説します。

前提知識/必要な理由

従来のSSH接続では、パブリックIPアドレスの付与やセキュリティグループでのインバウンド許可が必要でした。これに対して、セッションマネージャーを採用することで以下のメリットが得られます。

セキュリティの向上：インバウンドポートを完全に閉じた状態（ポート22も不要）でEC2へのアクセスが可能になります。
鍵管理からの解放：SSHキー（PEMファイル）の配布や管理が不要になり、紛失や漏洩のリスクがなくなります。
権限管理の一元化：IAM（Identity and Access Management）を使用して、どのユーザーがどのインスタンスにアクセスできるかを細かく制御できます。
監査ログの取得：実行したコマンドの履歴をCloudWatch LogsやS3に自動保存できます。

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

プライベートサブネットに配置されたEC2インスタンス（Amazon Linux 2023）にセッションマネージャーで接続するための設定手順を4つのステップで進めます。

ステップ1：EC2用IAMロールの作成とアタッチ

EC2がAWS Systems Managerサービスと安全に通信できるように、適切なIAMロールを付与します。

AWSマネジメントコンソールで「IAM」を開き、[ロール] – [ロールの作成] をクリックします。
信頼されたエンティティタイプで「AWSのサービス」、ユースケースで「EC2」を選択します。
許可ポリシーの検索窓に「AmazonSSMManagedInstanceCore」と入力し、該当するポリシーを選択して次へ進みます。
ロール名（例: EC2SSMInstanceRole）を設定し、[ロールの作成] をクリックします。
「EC2」コンソールへ移動し、対象のインスタンスを選択後、[アクション] – [セキュリティ] – [IAMロールを変更] から、作成したIAMロールをアタッチします。

ステップ2：セキュリティグループとネットワークの設定

セッションマネージャーは、EC2インスタンス側からSSMのエンドポイントに対してアウトバウンドで接続を開始する仕組みです。

そのため、対象EC2に適用されているセキュリティグループのインバウンドルールは空（すべて不許可）で問題ありません。アウトバウンドルールで「HTTPS（ポート443）」の外部通信が許可されていることを確認してください。

※注意：インターネットゲートウェイやNATゲートウェイを持たない、完全なプライベートサブネットの場合は、以下の3つのVPCエンドポイント（インターフェイス型）を作成し、VPC内からSSMにアクセスできるように設計する必要があります。

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

ステップ3：SSM Agentの起動確認

Amazon Linux 2やAmazon Linux 2023などのAMIには、SSM Agentが標準でプリインストールされています。もし独自AMIや古いOSを使用しており、手動で導入する場合は以下のコマンドを実行します。

# SSM Agentのインストール（Amazon Linux / RHEL系の場合）
sudo dnf install -y amazon-ssm-agent

# サービスの有効化と起動
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

※外部パッケージを新規にインストールする場合、一時的にインターネット接続が必要になるか、あるいはVPCエンドポイント経由での通信が確立されている必要があります。

ステップ4：セッションマネージャーでの接続テスト

AWSコンソールで「Systems Manager」を検索して開きます。
左側メニューから「セッションマネージャー」を選択し、[セッションの開始] をクリックします。
ターゲットインスタンスの一覧に対象のEC2が表示されていることを確認します。
対象インスタンスを選択し、[セッションの開始] をクリックすると、ブラウザ上でシェルが起動します。

実務での注意点

実務でセッションマネージャーを本格導入する際は、以下の2点について考慮してください。

1. タグを用いたIAMによる接続制限

全ての開発者が本番環境のEC2に接続できては危険です。特定のタグ（例: Environment: Development）を持つEC2にのみ接続を許可するポリシーを定義し、ユーザーに付与することを推奨します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Environment": "Development"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:TerminateSession"
            ],
            "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
        }
    ]
}

2. 接続ログの転送設定

運用監査に備えるため、セッションマネージャーの「設定」タブから、実行ログを「Amazon S3」または「CloudWatch Logs」へ転送する設定を有効にしてください。ログを暗号化して保管することで、万が一のインシデント時にも確実な調査が可能になります。

まとめ

SSMセッションマネージャーを使用すれば、SSHポートを開放することなく、極めてセキュアなインフラ運用を実現できます。踏み台サーバーの管理コストや鍵管理の煩雑さから解放されるため、これからのAWS設計におけるデファクトスタンダードとして積極的に活用しましょう。