Bastion Hostを置き換えるAWS Systems Manager Session Manager

クラウド環境でEC2インスタンスに接続するために長らく使われてきた方法は、Bastion Hostでした。

管理者はまずBastion HostにSSHで接続し、その後、内部のプライベートサブネットにあるサーバーに再度接続していました。この構造は単純で慣れ親しんだものですが、運用規模が大きくなるにつれて、管理負担とセキュリティリスクが共に増加します。

最近のAWS環境では、Bastion Hostを減らすか廃止し、AWS Systems ManagerのSession Managerを利用してEC2に接続する方法が広く使われています。

Bastion Host方式の限界

Bastion Hostは外部から内部サーバーへ入るためのゲートウェイの役割を果たします。しかし、この構造にはいくつかの問題があります。

第一に、Bastion Host自体が攻撃対象となります。

外部接続のためにSSH 22番ポートやRDP 3389番ポートを開放する必要があり、このサーバーが侵害されると内部ネットワークへのアクセス経路が露呈する可能性があります。

第二に、SSH Keyの管理が必要です。

ユーザーごとのキー発行、回収、紛失対応、退職者のキー削除といった管理業務が継続的に発生します。

第三に、接続履歴の追跡が困難です。

誰がいつどのサーバーに接続したかは一部確認できますが、コマンドレベルの監査ログを一貫して残すには別途構成が必要です。

第四に、運用コストと管理負担が発生します。

Bastion Hostも結局EC2インスタンスであるため、パッチ適用、セキュリティ設定、モニタリング、障害対応が必要です。

Session Managerとは？

AWS Systems Manager Session Managerは、EC2インスタンスにSSH Keyなしで接続できるようにするマネージド接続機能です。

ユーザーはAWS Console、AWS CLI、またはSDKを通じてSession Managerセッションを開始します。インスタンスにはSSM Agentがインストールされている必要があり、インスタンスはAWS Systems Managerエンドポイントと通信できる必要があります。

接続フローは以下の通りです。

사용자
  ↓
AWS IAM / AWS SSO 인증
  ↓
AWS Systems Manager Session Manager
  ↓
SSM Agent
  ↓
Private EC2 Instance

重要なのは、ユーザーがEC2に直接SSH接続しないという点です。

つまり、EC2セキュリティグループで22番ポートを開放する必要がありません。

Session ManagerがBastionを置き換える理由

Session Managerを使用すると、Bastion HostなしでプライベートサブネットのEC2に接続できます。

従来のBastion構造は以下の通りです。

관리자 PC
  ↓ SSH
Bastion Host - Public Subnet
  ↓ SSH
Private EC2 - Private Subnet

Session Manager構造は以下の通りです。

관리자 PC
  ↓ AWS 인증
Session Manager
  ↓ SSM Agent
Private EC2 - Private Subnet

この方式では、パブリックサブネットにBastion Hostを配置する必要がありません。

プライベートEC2にパブリックIPを付与する必要もなく、SSH 22番ポートを開放する必要もありません。

結局、接続セキュリティの中心がネットワークベースのアクセス制御からIAMベースのアクセス制御へと移行します。

セキュリティ観点での利点

1. インバウンドポートを閉じることができる

Session Managerを使用すると、EC2インスタンスにSSH 22番やRDP 3389番を開放する必要がありません。

セキュリティグループの例は次のように単純化できます。

Inbound:
  없음

Outbound:
  HTTPS 443 허용

もちろん、アプリケーションサーバーであれば、ALB、NLB、内部サービス通信などに必要なポートは別途許可する必要があります。

しかし、運用者接続のためのSSHポートは削除できます。

2. SSH Key管理が軽減される

Session Managerの基本接続はSSH Keyを使用しません。

接続権限はIAMポリシーで制御します。

例えば、運用チームAは開発サーバーのみ接続可能にし、セキュリティチームは運用サーバーに読み取り目的の接続のみを許可するといった制御が可能です。

権限の回収もSSH Keyの削除ではなく、IAM権限の削除で処理できます。

3. CloudTrailベースの監査が可能

Session Managerの接続はAWS API呼び出しとして記録されます。

誰が、いつ、どのインスタンスにセッションを開始したかをCloudTrailで確認できます。

また、設定に応じてセッションログをS3やCloudWatch Logsに保存できます。

運用環境では、以下のような監査体制を構築することをお勧めします。

Session Manager 접속
  → CloudTrail 기록
  → CloudWatch Logs 또는 S3 저장
  → EventBridge로 접속 이벤트 탐지
  → SNS 또는 Slack 알림

4. プライベートサブネット中心の構造に適している

Session ManagerはプライベートサブネットのEC2にも適しています。

インスタンスがインターネットに直接出る必要なく、VPCエンドポイントを構成すればAWS PrivateLinkを通じてSystems Managerと通信できます。

プライベートサブネットでSession Managerを安定して使用するには、通常、次のVPCエンドポイントを構成します。

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

CloudWatch LogsやS3にセッションログを保存する場合は、関連するエンドポイントも合わせて検討する必要があります。

構成に必要な要素

Session Managerを使用するには、大きく分けて4つの要素が必要です。

1. EC2 IAMロール

EC2インスタンスには、Systems Managerと通信できるIAMロールが必要です。

一般的に、AWS管理ポリシーであるAmazonSSMManagedInstanceCoreをアタッチします。

ポリシーアタッチの例の構造は以下の通りです。

EC2 Instance
  → IAM Role
    → AmazonSSMManagedInstanceCore

2. SSM Agent

EC2内部にはSSM Agentがインストールされている必要があります。

Amazon Linux 2、Amazon Linux 2023、Ubuntuの一部AMI、Windows Server AMIにはデフォルトでインストールされていることが多いです。

ただし、運用環境ではSSM Agentのバージョンを最新に保つことをお勧めします。

確認コマンドは以下の通りです。

sudo systemctl status amazon-ssm-agent

実行中でない場合は、次のように開始できます。

sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

3. ネットワークパス

インスタンスはSystems ManagerエンドポイントとHTTPS 443で通信できる必要があります。

インターネット経路がある場合は、NAT Gatewayを介して通信できます。

インターネット経路を削除したい場合は、VPCエンドポイントを構成します。

セキュリティが重要な運用環境では、NAT GatewayよりもVPCエンドポイントベースの構成の方がよりクリーンです。

4. ユーザーIAM権限

ユーザーはSession Managerセッションを開始する権限が必要です。

権限の例は以下の通りです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:StartSession",
        "ssm:TerminateSession",
        "ssm:ResumeSession"
      ],
      "Resource": [
        "arn:aws:ec2:ap-northeast-2:123456789012:instance/i-xxxxxxxxxxxxxxxxx",
        "arn:aws:ssm:ap-northeast-2:123456789012:document/SSM-SessionManagerRunShell"
      ]
    }
  ]
}

運用環境では、インスタンスタグに基づいて制御することをお勧めします。

例えば、Environment=Devのインスタンスのみ開発者が接続できるようにしたり、Environment=Prodのインスタンスは運用者グループのみが接続できるようにしたりできます。

接続方法

AWS CLIからSession Managerに接続する基本コマンドは以下の通りです。

aws ssm start-session 
  --target i-xxxxxxxxxxxxxxxxx

接続されると、一般的なシェルと同様にコマンドを実行できます。

whoami
hostname
ip addr

EC2コンソールでも、インスタンスを選択し、ConnectメニューからSession Managerを選択して接続できます。

SSHのように使用する必要がある場合

基本的にSession ManagerはSSHなしで接続する方式です。

しかし、既存のツールがSSHベースで動作する場合もあります。

例えば、SCP、rsync、Ansible、IDE Remote SSHのようなツールはSSHプロトコルを要求する可能性があります。

この場合、Session ManagerをSSHトンネルのように使用できます。

ローカルSSH設定の例は以下の通りです。

Host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

その後、次のように接続できます。

ssh ec2-user@i-xxxxxxxxxxxxxxxxx

ただし、この方式はSession ManagerがSSHトラフィックをトンネリングする構造であるため、コマンドレベルのセッションロギングには制限があります。

監査ログが重要な運用環境では、デフォルトのSession Managerシェル接続とロギング構成を優先的に検討することをお勧めします。

ポートフォワーディングの活用

Session Managerはポートフォワーディングもサポートしています。

例えば、プライベートサブネットにあるEC2の8080ポートをローカルPCの8080ポートに接続できます。

aws ssm start-session 
  --target i-xxxxxxxxxxxxxxxxx 
  --document-name AWS-StartPortForwardingSession 
  --parameters '{"portNumber":["8080"],"localPortNumber":["8080"]}'

その後、ローカルブラウザから次のアドレスにアクセスできます。

http://localhost:8080

この方式は、内部管理ページ、一時的なデバッグ、プライベートRDSへのアクセス、内部APIの確認などに有用です。

BastionとSession Managerの比較

区分	Bastion Host	Session Manager
接続方式	SSH/RDP 直接接続	AWS API ベースセッション
Public IP	通常必要	不要
Inbound ポート	22/3389 必要	不要
SSH Key 管理	必要	基本接続は不要
アクセス制御	セキュリティグループ、キー、OSアカウント	IAM ポリシー
監査ログ	別途構成必要	CloudTrail, S3, CloudWatch Logs 連携
運用負担	EC2 パッチ/運用必要	マネージドサービス中心
Private Subnet 接続	Bastion 経由	直接可能
費用	Bastion EC2 費用発生	基本使用費用は低い、ログ/VPC Endpoint 費用別途考慮

運用環境の推奨構成

運用環境では、次の構成を推奨します。

1. EC2는 Private Subnet에 배치
2. EC2에는 Public IP 미부여
3. 보안 그룹에서 SSH/RDP Inbound 제거
4. EC2 IAM Role에 AmazonSSMManagedInstanceCore 연결
5. SSM Agent 최신 버전 유지
6. VPC Endpoint 구성
   - ssm
   - ssmmessages
   - ec2messages
7. Session Manager 로그를 CloudWatch Logs 또는 S3에 저장
8. CloudTrail로 StartSession, TerminateSession 이벤트 추적
9. IAM Identity Center 또는 IAM Role 기반으로 사용자 접근 제어
10. 운영 서버 접속은 태그 기반 IAM 정책으로 제한

注意点

Session ManagerがBastion Hostを完全に置き換えられるケースは多いですが、必ずしもすべての状況でBastionが不要になるわけではありません。

例えば、非常に特殊なネットワーク機器へのアクセス、レガシーなSSHベースの自動化、強力なネットワーク分離ポリシーがある環境では、別途接続構造が必要となる場合があります。

また、Session Managerを導入してもIAM権限を広く与えすぎると危険です。

以下のようなポリシーは避けるべきです。

{
  "Effect": "Allow",
  "Action": "ssm:StartSession",
  "Resource": "*"
}

運用環境では、最小権限の原則に従い、特定のインスタンス、特定のタグ、特定のSSMドキュメントのみを許可する形で制限する必要があります。

結論

AWS Systems Manager Session Managerは、Bastion Hostを置き換えるのに非常に適した機能です。

最大の利点は、運用者接続のためにEC2にSSHポートを開放する必要がない点です。

また、SSH Key管理の負担を軽減し、IAMベースでアクセス権限を中央で統制できます。

従来のBastion Host方式が「ネットワークに一つの扉を開いて管理する方式」であったとすれば、Session Managerは「AWS認証と権限を通じて必要な時にのみセッションを開く方式」に近いと言えます。

したがって、AWS運用環境では、新規システムからBastion Hostをデフォルトとするのではなく、Session Managerベースの接続構造を優先的に検討することをお勧めします。