なぜ今すぐ踏み台サーバー（Bastion Host）が必要なのか？
キャリアをスタートさせたばかりの頃、私は顧客向けのサービスを動かしている20台のサーバー群を管理していました。自宅からSSH接続しやすくするために、すべてのサーバーでポート22をインターネットに公開してしまったのです。その結果、ある日の深夜2時、システムのアラートが鳴り響きました。ログを確認すると、わずか1時間で5万回以上のブルートフォース攻撃が仕掛けられていたのです。開発者の一人があまりにも単純なパスワードを設定していたため、そのうちの1台が乗っ取られてしまいました。
この衝撃的な出来事の後、内部サーバーをインターネットに直接さらすことが致命的なミスであると痛感しました。そこで導入したのが**Bastion Host**（または**踏み台サーバー**／**Jump Server**）です。20もの無防備な扉を開けておく代わりに、入り口を1つだけに絞りました。この入り口を徹底的に要塞化し、そこを通過するすべての行動を厳重に監視するようにしたのです。
踏み台サーバー（Bastion Host）とは何か？
踏み台サーバーは、高級マンションの入り口にある「守衛所」のようなものだと考えてください。居住者の部屋に直接押し入ることはできません。必ず守衛所を通り、身分証を提示し、警備員に入退館時間を記録してもらう必要があります。
ITインフラにおいて、踏み台サーバーは境界領域（パブリックサブネット）に配置されるサーバーです. 内部サーバー（プライベートサブネット）へアクセスするための唯一の中継点として機能します。これにより、内部サーバーはポート22を外部に対して完全に閉じ、踏み台サーバーのIPアドレスからの接続のみを許可するようになります。
この構成には3つの大きなメリットがあります：
- 攻撃対象領域（アタックサーフェス）の縮小： ハッカーが狙えるターゲットが、数十台のサーバーから1台だけに絞られます。
- 集中管理： セキュリティ設定やSSHキーの管理を1箇所に集約できます。
- 正確な監査ログ（Audit Log）： 誰が、いつ、どのサーバーに入り、どのようなコマンドを実行したかを正確に把握できます。
実践：プロフェッショナルな踏み台サーバーの設定
ステップ1：踏み台サーバー自体のセキュリティ強化
これは最終防衛線であるため、踏み台サーバーが乗っ取られれば、ハッカーはシステム全体への鍵を手に入れることになります。したがって、このサーバー自体のセキュリティが最優先事項です。
パスワードによるログインを完全に無効化し、認証にはSSHキーのみを使用するようにします。/etc/ssh/sshd_config ファイルを開き、以下のように編集します。
# パスワード認証を無効化
PasswordAuthentication no
PubkeyAuthentication yes
# 特定のユーザーのみ許可
AllowUsers admin-devops
# SSHポートを変更してボットのスキャンによる不要なログを90%削減
Port 2222その後、サービスを再起動します：sudo systemctl restart ssh
ステップ2：SSH ProxyJumpの利用（標準的な手法）
踏み台サーバーにSSH接続した後、そこへ秘密鍵（Private Key）をコピーして内部サーバーへ接続する人がいますが、絶対にやってはいけません！ 万が一、踏み台サーバーがハッキングされた場合、すべての秘密鍵が攻撃者の手に渡ってしまいます。
最も安全な方法は ProxyJump 機能を使うことです。ローカルマシンの ~/.ssh/config ファイルを次のように設定します。
# 踏み台サーバーの設定
Host bastion
HostName 1.2.3.4
User admin-devops
Port 2222
IdentityFile ~/.ssh/id_rsa_bastion
# 内部サーバーの設定
Host server-app-1
HostName 10.0.1.50
User deploy-user
IdentityFile ~/.ssh/id_rsa_internal
ProxyJump bastionこれで、ssh server-app-1 と入力するだけで、SSHクライアントが自動的に踏み台サーバーを経由して接続してくれます. 踏み台サーバー上に秘密鍵が保存されることはありません。
ステップ3：全セッションの監査ログ（Audit Logging）の記録
これは監視において非常に強力な機能です。script コマンドを使用して、ターミナル上のすべての出来事を記録します。まず、踏み台サーバーにログ保存用ディレクトリを作成します。
sudo mkdir -p /var/log/bastion
sudo chmod 733 /var/log/bastion次に、ユーザーが接続したときに自動的に起動するスクリプト /usr/local/bin/bastion-session.sh を作成します：
#!/bin/bash
# ユーザー名と日時を含めたログファイル名を定義
LOG_FILE="/var/log/bastion/session_${USER}_$(date +%Y%m%d_%H%M%S).log"
echo "--- ようこそ！あなたのセッションは記録されています ---"
/usr/bin/script -q -f $LOG_FILE
exit実行権限を付与します：sudo chmod +x /usr/local/bin/bastion-session.sh。ユーザーがログインすると、すべてのコマンドと実行結果が /var/log/bastion/ に保存され、いつでも確認できるようになります。
ステップ4：権限の最小化
実際、ユーザーは踏み台サーバー上でコマンドを実行する必要はありません。SSHトンネルの利用のみに制限することも可能です。/etc/ssh/sshd_config に、特定のユーザーグループに対する設定を追加します：
Match Group bastion-users
AllowTcpForwarding yes
X11Forwarding no
PermitTunnel no
GatewayPorts no運用における実戦的なアドバイス
長年大規模プロジェクトで導入してきた経験から、いくつか注意点をお伝えします：
- 常に予備の手段を用意する： 別経路のVPNも設定しておきましょう。踏み台サーバーに障害が発生しても、システムを救出する手段を確保しておくためです。
- ログのローテーション：
scriptコマンドによるログファイルは、操作量が多いと数GBに達することがあります。logrotateを使用して、30日後に古いログを圧縮・削除するようにしましょう。 - 2FA（二要素認証）の統合： 可能であれば、踏み台サーバーにGoogle Authenticatorを導入してください。これは非常に強力なセキュリティ層となり、夜も安心して眠れるようになります。
まとめ
踏み台サーバーの設定はそれほど難しくありませんが、その効果は絶大です。インフラ保護の考え方を根本から変えてくれます。あちこちの脆弱性を塞ぐのに奔走する代わりに、1つのポイントを死守することに集中できるのです。
この共有が皆さんのシステムの安全向上に役立つことを願っています。設定中に困ったことがあれば、お気軽にコメントしてください。すぐにお答えします！
