踏み台サーバーの構成と運用入門｜AWSでSSH接続を安全に管理

※本記事にはプロモーション（広告）を含みます。

踏み台サーバーを構築するなら、まず公開サブネットに置くインスタンスを最小構成にし、SSHの許可元IPをオフィスや自宅の固定IPに限定してください。AWS上でVPCを設計する際、踏み台サーバー（Bastion Host）は内部ネットワークへの唯一の入口として機能します。本記事では、EC2を使った踏み台サーバーの構築手順から、鍵管理、ログ監査、AWS Systems Manager Session Managerとの使い分けまで、実運用を想定して解説します。

踏み台サーバーの基本設計

踏み台サーバーの役割

踏み台サーバーは、プライベートサブネットに配置したデータベースやアプリケーションサーバーへ、管理者が安全にSSH接続するための中継点です。プライベートサブネット内のインスタンスに直接パブリックIPを割り当てないことで、インターネットからの直接攻撃を受けにくくします。管理者は一度踏み台サーバーにログインし、そこから内部インスタンスへ多段SSH接続する構成が一般的です。この構成にすることで、外部に公開する接続経路を1つに集約でき、監査対象も踏み台サーバー1台に絞れます。

VPCとサブネット設計

踏み台サーバーはパブリックサブネットに、業務用インスタンスはプライベートサブネットに配置するのが基本形です。パブリックサブネットにはインターネットゲートウェイへのルートを設定し、プライベートサブネットはNATゲートウェイ経由でのみ外部通信を許可します。サブネットのCIDR設計では、将来の拡張を見込んで余裕を持たせておくと、後からサブネットを追加する手間を減らせます。目安として、踏み台サーバー用のサブネットは/28程度の小さな範囲で十分足りるケースが多く、必要以上に広いレンジを割り当てる必要はありません。

AWSでの構築手順

EC2インスタンス作成

踏み台サーバーには、常時大きな負荷がかかるわけではないため、t3.microやt3.small程度の小型インスタンスタイプを選ぶのが一般的です。AMIはAmazon Linuxなど、AWSが提供する最新のセキュリティパッチが適用されたイメージを選択してください。起動時にはパブリックサブネットを指定し、自動割り当てパブリックIPを有効にします。固定運用を想定する場合はElastic IPを別途アタッチすると、インスタンス再起動後もIPアドレスが変わらず、許可リストの管理が煩雑になりません。

セキュリティグループ設定

セキュリティグループでは、SSH（TCP 22番ポート）の送信元を「0.0.0.0/0」にせず、必要なIPアドレスのみに限定します。オフィスの固定グローバルIPや、VPN経由のIPレンジを指定するのが基本です。内部インスタンス側のセキュリティグループでは、送信元を踏み台サーバーのセキュリティグループIDに指定すると、IPアドレス変更時の設定漏れを防げます。以下は代表的な設定パターンの比較です。

設定項目	推奨設定	避けるべき設定
SSH送信元	特定IP/CIDRのみ許可	0.0.0.0/0で全開放
認証方式	SSH鍵ペア＋パスフレーズ	パスワード認証のみ
内部通信	セキュリティグループ参照	固定IPのみで管理
ログ管理	CloudTrail・OSログ両方記録	ログ未取得のまま放置

SSH鍵と接続確認

EC2起動時に発行されるキーペアの秘密鍵は、ローカル端末の権限600（所有者のみ読み書き可）に設定して保管します。接続確認は次のコマンドで行います。

ssh -i your-key.pem ec2-user@踏み台サーバーのIPアドレス

内部インスタンスへの多段接続は、SSHのProxyCommandやProxyJump（-Jオプション）を使うと、踏み台サーバーに一度ログインしてから改めて内部サーバーへ接続する手間を省けます。~/.ssh/configにホスト設定をまとめておくと、日常的な接続作業が数コマンド分短縮されます。

安全なSSH運用のコツ

多要素認証の導入

SSH鍵だけに頼らず、多要素認証（MFA）を組み合わせると、鍵ファイルが漏えいした場合でも不正ログインのリスクを下げられます。AWS IAMのMFA機能はコンソールログインやAPI操作に対して有効ですが、SSHログイン自体にMFAを組み込みたい場合は、Google Authenticator PAMモジュールなど、OS側でMFA対応するミドルウェアの導入を検討してください。設定変更はSSHセッションを切断すると再接続できなくなるリスクがあるため、必ず別セッションを開いた状態で動作確認を行ってください。

アクセスログの記録

踏み台サーバーへの接続履歴は、OS標準の/var/log/secureや/var/log/auth.logに記録されます。加えて、AWS CloudTrailでAPI経由の操作履歴を、Amazon CloudWatch Logsでシステムログを一元管理すると、インシデント発生時の調査時間を大幅に短縮できます。誰が・いつ・どのIPから・どのユーザーで接続したかを追跡できる状態を維持することが、監査対応の土台になります。ログの保存期間はコンプライアンス要件に応じて設定し、最低でも90日程度は保持しておくと安心です。

踏み台とSSMの比較

踏み台とSSMの違い

AWS Systems Manager Session Managerは、SSHポートを一切開放せずに内部インスタンスへ接続できるAWSのマネージドサービスです。踏み台サーバーのようにEC2インスタンスを常時起動しておく必要がなく、IAMポリシーによる権限管理がそのまま接続制御に使えます。一方、踏み台サーバーは既存のSSH運用フローをそのまま使い続けられる点や、Linux以外の機器を含む多様な環境への中継役としても柔軟に使える点が利点です。

比較項目	踏み台サーバー	Session Manager
SSHポート開放	必要（制限付き）	不要
インスタンス常時起動	必要	不要（オンデマンド接続）
アクセス制御	セキュリティグループ＋鍵	IAMポリシー
接続ログ	OS側で個別収集	CloudTrail/CloudWatchで一元管理
既存運用との親和性	従来型SSH運用と互換性が高い	AWS CLI/コンソールが前提

移行時の注意点

踏み台サーバーからSession Managerへ移行する際は、対象インスタンスにSSM Agentがインストールされ、適切なIAMロールが割り当てられている必要があります。Amazon Linux 2以降のAMIにはSSM Agentが標準で組み込まれていますが、古いAMIや自作イメージでは別途インストールが必要です。移行期間中は両方式を並行稼働させ、接続経路を段階的に切り替えると、運用チームの混乱を避けられます。バージョンや設定手順は変更される場合があるため、最新の情報はAWS公式ドキュメントで確認してください。

運用中のトラブル対応

よくある接続エラー

接続時に「Connection timed out」と表示される場合、セキュリティグループでSSHポートが許可されていないか、ネットワークACLがブロックしている可能性が高いです。「Permission denied (publickey)」が出る場合は、指定した秘密鍵とインスタンスに登録された公開鍵が一致していないか、鍵ファイルの権限設定に問題があるケースが目安として多く見られます。エラーメッセージを手がかりに、セキュリティグループ→ネットワークACL→鍵の順で切り分けると、原因特定までの手数を減らせます。

監査とコスト管理

踏み台サーバーは常時起動しておく構成が一般的ですが、深夜・休日はアクセスが発生しない業務であれば、AWS Lambdaと組み合わせたスケジュール起動・停止でコストを抑えられます。あわせて、未使用のElastic IPやアタッチされていないEBSボリュームが残っていないか、定期的にAWSコスト管理ツールで確認しておくと、無駄な課金を防げます。セキュリティ設定の変更や自動化スクリプトの導入は、必ず自己責任のもとテスト環境で動作確認してから本番環境へ適用してください。

よくある質問

踏み台サーバーは無料枠内で運用できますか

t2.microまたはt3.microなど対象インスタンスタイプであれば、AWS無料利用枠の条件を満たす範囲で運用できる場合があります。無料枠の対象条件は変更されることがあるため、AWS公式サイトの最新情報を確認してください。

踏み台サーバーとVPNはどちらが安全ですか

どちらか一方が絶対的に安全というわけではなく、目的によって使い分けます。踏み台サーバーは特定の接続経路を明示的に管理しやすく、VPNはネットワーク全体への接続を許可する分、接続後の内部アクセス制御を別途設計する必要があります。

SSHポートを22番以外に変更すべきですか

ポート番号の変更自体は根本的な対策にはなりませんが、自動スキャンによる不要なアクセスログを減らす副次的な効果があります。ポート番号だけに頼らず、送信元IP制限や鍵認証と組み合わせて運用してください。

踏み台サーバーのOSアップデートはどう管理しますか

定期的なOSパッチ適用が基本です。自動アップデート機能を有効にするか、AWS Systems Manager Patch Managerを使ってパッチ適用状況を一元管理すると、複数台運用時の抜け漏れを防げます。

踏み台サーバーを廃止してSSMだけに統一できますか

技術的には可能ですが、Linux以外の機器やSSM Agent非対応の環境が混在する場合は、踏み台サーバーを併用する構成の方が現実的なケースがあります。自社の対象インスタンス構成を洗い出したうえで判断してください。

まとめ

踏み台サーバーの構築は、パブリックサブネットへの最小構成インスタンス配置、送信元IPを限定したセキュリティグループ設定、SSH鍵の厳格な権限管理という3つの基本を押さえることから始まります。運用フェーズでは、アクセスログの記録とMFAの導入によって不正アクセスのリスクを下げつつ、AWS Systems Manager Session Managerへの移行も選択肢として検討する価値があります。どの方式を選ぶ場合も、セキュリティ設定の変更は必ずテスト環境で検証したうえで本番環境に適用し、AWS公式ドキュメントで最新のベストプラクティスを確認しながら運用してください。

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。編集ポリシーはこちら