Bastionホスト（踏み台サーバー）のセキュリティ設計｜SSH接続を一元管理して内部ネットワークを守る実践ガイド

社内の複数サーバーに直接SSHでアクセスしている構成をよく見かけます。管理は楽ですが、攻撃者にとっては「どのサーバーも直接狙える」状態です。Bastionホスト（ジャンプサーバー）を設計すれば、SSH接続の入口を一本化して内部ネットワーク全体を守る構造に変えられます。

この記事では、Bastionホストの概念・攻撃者から見たリスク・具体的な構築と強化手順を、現場で使えるレベルで解説します。

Bastionホストとは？なぜ必要なのか

Bastionホスト（踏み台サーバー・ジャンプサーバーとも呼ばれる）とは、外部ネットワークから内部サーバー群へのSSH接続を一元的に中継するための専用サーバーです。「要塞（Bastion）」という言葉が示すとおり、外部との接点を1台に絞ることで内部を守る役割を担います。

Bastionホストを導入しない場合、外部からの攻撃経路は「内部サーバーの台数分」存在します。SSHポートを複数のサーバーで開放していれば、そのどれもがブルートフォース攻撃・鍵の盗難・設定ミスの標的になりえます。Bastionホストを置くことで、以下の設計が実現できます。

・攻撃面の最小化: 外部に公開するSSHポートを1台（Bastion）に限定する
・アクセスの一元管理: 誰がいつどのサーバーにアクセスしたかを1か所で記録できる
・内部サーバーの隠蔽: 内部サーバーのIPアドレスを外部に露出させない
・権限の分離: Bastionホストと業務サーバーで認証情報・ロールを分離できる

攻撃者はBastionホストをどう狙うか

Bastionホストは「内部への唯一の入口」であるため、攻撃者にとって最も価値の高い標的の一つです。正しく守られていなければ、要塞のつもりが最大の弱点になります。

・ブルートフォース攻撃: 公開SSHポートへの辞書攻撃・パスワード総当たりを継続的に仕掛けてくる。ポート22を開放したまま放置すると即座に始まる
・秘密鍵の盗取: 管理者のPCやBastionホスト自体から秘密鍵ファイルを盗む。鍵にパスフレーズが設定されていない場合は即座に悪用される
・設定ミスの悪用: 不要なポートが開放されている・rootログインが許可されている・不要なサービスが稼働しているなどの設定ミスを狙う
・Bastion乗っ取り後の横展開: Bastionホスト自体を侵害することで、そこを起点に内部サーバー全体へのラテラルムーブメント（横移動）が可能になる

これらのリスクを踏まえると、BastionホストはOSレベルから丁寧に強化する必要があります。

ラテラルムーブメント（横移動）攻撃の詳細については、ラテラルムーブメント（横移動）とは？内部ネットワークを侵食する攻撃手口と防御策を現場目線で解説で解説しています。

Bastionホストの構築と強化手順

1. 最小限のOS構成で攻撃面を絞る

Bastionホストは「SSHの中継専用」と割り切り、余計なソフトウェアを一切入れないことが原則です。Webサーバー・データベース・GUIなど、SSH中継に不要なものはすべて除外します。インストール直後に次の確認を行います。

# 不要なサービスを確認・停止
systemctl list-units --type=service --state=running

# 不要なパッケージを除去（例: Apache が入っていた場合）
dnf remove httpd -y     # RHEL/Rocky系
apt purge apache2 -y    # Debian/Ubuntu系

# 開放ポートの確認（SSH以外は原則閉じる）
ss -tlnp

OSは定期的に自動アップデートを適用し、脆弱性パッチが滞らないようにします。パッチ管理の仕組みについてはパッチ管理の基礎｜脆弱性対応サイクル・優先度判定・適用手順をわかりやすく解説が参考になります。

2. SSH設定を徹底的に絞り込む

Bastionホストの /etc/ssh/sshd_config を以下の方針で設定します。

# /etc/ssh/sshd_config — Bastionホスト向け設定

# rootへの直接ログインを禁止
PermitRootLogin no

# パスワード認証を完全に無効化（鍵認証のみ許可）
PasswordAuthentication no
ChallengeResponseAuthentication no

# 公開鍵認証を明示的に有効化
PubkeyAuthentication yes

# ログイン試行の失敗回数を制限
MaxAuthTries 3

# 接続セッション数の上限（不必要な接続の増殖を防ぐ）
MaxSessions 5

# 未使用のセッションを自動切断（秒単位）
ClientAliveInterval 300
ClientAliveCountMax 2

# TCPポート転送の制限（Bastionは中継のみ）
AllowTcpForwarding no
X11Forwarding no

# ログイン可能なユーザーを明示的に指定
AllowUsers bastion-user

# バナーを表示して不正アクセスを牽制
Banner /etc/ssh/banner.txt

設定変更後は必ず構文チェックをしてから再起動します。

# 設定ファイルの構文チェック（エラーがあれば表示される）
sshd -t

# 問題なければ再起動
systemctl restart sshd

SSH接続の基本的な強化手順については、SSH接続のセキュリティ対策｜鍵認証・ポート変更・fail2banで不正アクセスを防ぐも合わせて参照してください。

3. 多要素認証（MFA）を追加する

鍵認証だけでも強力ですが、秘密鍵が盗まれた場合のリスクを考えると、OTP（ワンタイムパスワード）との組み合わせが理想的です。PAM + Google Authenticatorを使った二要素認証の設定については、LinuxのSSH二要素認証設定｜PAM＋Google AuthenticatorでOTPログインを実装する実践ガイドで詳しく解説しています。

4. アクセスログと監査証跡を確実に残す

Bastionホストを経由したすべてのアクセスがログに残ることは、インシデント調査の観点から必須です。

# SSH接続ログの確認（リアルタイム監視）
journalctl -u sshd -f

# ログイン成功・失敗の集計（過去24時間）
journalctl -u sshd --since yesterday | grep -E "Accepted|Failed"

# auditdで特定ユーザーのコマンド操作を記録するルール追加
auditctl -a always,exit -F arch=b64 -S execve -F uid=1001 -k bastion_exec

さらに、ログをリモートサーバーに転送することで、Bastionホスト自体が侵害されてもログが消去されない設計が作れます。rsyslogによるリモートログ転送についてはLinuxのrsyslogリモートログ転送設定｜集中ログ管理でサーバー侵害後の証跡消去を防ぐ実践ガイドを参照してください。

5. ファイアウォールでアクセス元IPを制限する

BastionホストへのSSHアクセスを「許可されたIPアドレス（自社オフィス・VPN出口）からのみ」に絞ることで、攻撃の大半を封じることができます。

# firewalldでSSH接続元IPを制限する例
# まずデフォルトゾーンからSSHを削除
firewall-cmd --permanent --remove-service=ssh

# 許可するIPからのSSHのみリッチルールで追加
# 203.0.113.10 の部分を自社VPN出口IPに置き換える
firewall-cmd --permanent --add-rich-rule=\
  'rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'

# 設定を反映
firewall-cmd --reload

# 確認
firewall-cmd --list-all

また、fail2banを導入することで、連続して認証に失敗したIPを自動的にブロックできます。fail2ban完全ガイド｜ブルートフォース攻撃を自動ブロックするLinuxサーバー不正アクセス対策で設定方法を解説しています。

6. クライアント側のSSH設定（ProxyJump）

管理者のPC側では、Bastionを経由して内部サーバーに接続するためのSSH設定を ~/.ssh/config に記述します。

# ~/.ssh/config — クライアント側設定例

# Bastionホストの定義
Host bastion
    HostName 203.0.113.5
    User bastion-user
    IdentityFile ~/.ssh/id_ed25519_bastion
    Port 22

# 内部サーバーへの接続（Bastionを経由）
Host internal-web
    HostName 192.168.10.20
    User deployer
    IdentityFile ~/.ssh/id_ed25519_internal
    ProxyJump bastion

この設定により、ssh internal-web と実行するだけでBastionを経由して内部サーバーへ接続できます。ProxyJumpはOpenSSH 7.3以降で使える機能です。

中小企業でも今日からできること

・まず1台のサーバーをBastionとして指定する: 新規サーバーを用意しなくても、既存サーバーの1台を「Bastion専用」として設定変更することで始められる。Webサービスや業務アプリは動かさず、SSH中継に専念させる
・IPフィルタリングを即日適用する: Bastionへのアクセスを自社の固定IP（オフィス・VPN出口）に絞るだけで、外部からの無差別攻撃を大幅に削減できる
・鍵認証に切り替え、パスワード認証を無効化する: これだけでブルートフォース攻撃をほぼ無効化できる。費用ゼロで今日から実施可能
・fail2banを導入する: 万が一不審な接続試行があっても自動でブロックできる体制を整える

クラウドを利用している場合、AWS Systems Manager Session ManagerやGoogle Cloud IAP（Identity-Aware Proxy）のようなマネージドなBastionサービスも選択肢になります。SSHポートを外部に開放せずにサーバー管理ができるため、セキュリティレベルはさらに高まります。

よくある誤解と注意点

「BastionはLinuxサーバー1台の話だから中小企業には関係ない」
これは誤解です。社員が数人の会社でも、インターネットに公開されたSSHポートは24時間攻撃にさらされています。Bastionホストの設計は規模に関係なく必要です。むしろ情シスが1人の中小企業こそ、アクセス管理を自動化・一元化できる仕組みを活用すべきです。

「BastionホストはDMZに置けば万全」
DMZへの配置は正しい設計ですが、Bastionホスト自体のOS強化・SSH設定・ログ管理を怠れば意味がありません。ネットワーク設計と端末強化の両方が必要です。

「秘密鍵さえ安全に保管すれば大丈夫」
秘密鍵の管理は重要ですが、そのPCが侵害されれば鍵も盗まれます。鍵にパスフレーズを設定する・MFAを追加する・不要な鍵を定期的に失効させる、といった鍵ライフサイクル管理も合わせて実施してください。

「Bastionホストは必ず独立したサーバーが必要」
クラウド環境ではマネージドBastionサービスを使うことで、サーバー管理コストを最小化しながらセキュリティを確保できます。自前でサーバーを管理する工数が取れない場合は積極的に活用してください。

本記事のまとめ

Bastionホストは正しく設計・運用することで、SSH経由の内部ネットワーク侵害を大幅に困難にします。一方で、設定を誤れば攻撃者に「全サーバーへの玄関鍵」を渡すことにもなります。

Bastionホストは「置けば終わり」ではなく、OSのアップデート・不要アカウントの定期棚卸し・ログの定期確認が欠かせません。姉妹サイトLinuxMaster.JPでは、Linuxサーバー管理の基礎から実践まで幅広く解説しています。合わせて参考にしてみてください。