概要
目当てのサーバーにアクセスする前に経由するサーバー。
アプリサーバーなどに直接SSHで接続できるようにすると、リスクがある。
そこで、一旦別のサーバーを経由し、アプリサーバーはこの踏み台サーバーからしかアクセスできないようにする。
こうすることで、アプリサーバーのセキュリティが良くなる。
DMZってわけ。
メリット
鍵交換
サーバーが各クライアント全員と鍵交換するのは大変。踏み台サーバーがあると、これと鍵交換すれば良くなる。
ログ管理
踏み台サーバーは別のサーバーにアクセスするのが役割。このサーバーのログをみると、誰がどのサーバーにアクセスしようとしたのかがわかりやすい。
リバースプロキシと何が違うの？
| 項目 | 踏み台サーバー | リバースプロキシ |
|---|---|---|
| 主に扱う層 | ネットワーク層／トランスポート層（SSHやRDPなど） | アプリケーション層（HTTP/HTTPSなど） |
| 接続の対象 | 管理者が使う SSH クライアントや RDP/SFTP | ブラウザや API クライアントが使う HTTP/HTTPS |
| 標的サーバー | 本番サーバー、データベースサーバーなど管理用 | Webサーバー、アプリケーションサーバー、APIサーバーなど |
| 通信の性質 | 対話的（ターミナル操作、リモートデスクトップ） | リクエスト/レスポンス（静的ファイル配信、API応答） |
| 主な役割 | 内部サーバーへの管理者アクセスを一元化・保護 | クライアントからの Web リクエストを振り分け・最適化 |
| 対象プロトコル | SSH、RDP、VPN（管理用） | HTTP/HTTPS、場合によっては WebSocket、HTTP/2 |
| 用途 | 管理者専用のゲートウェイ | Webサーバー群のフロントエンド（負荷分散・キャッシュ・SSL） |
| セキュリティ機能 | 二要素認証、鍵管理、監査ログの集中取得 | SSL/TLS終端、WAF導入、IPフィルタリング、DDoS対策 |
| 負荷分散・可用性 | 一点集中型（冗長化は可能だが運用コストがかかる） | ロードバランサー機能、バックエンドのヘルスチェック、自動フォールバック |
| ログ取得・監査 | 管理操作ログ（SSHコマンド履歴など） | アクセスログ（HTTPリクエスト／レスポンス状況） |
典型的な踏み台サーバー構成
[インターネット]
│ (SSH Port 22)
[Bastion Host (踏み台サーバー)]
│ (内部ネットワーク)
[DBサーバー]
[本番サーバーA]
[本番サーバーB]
管理者はまず踏み台サーバーにSSHで接続。
踏み台サーバーから、DBサーバーや本番サーバーにSSH接続を行う。
（本番サーバーは踏み台サーバーからしかアクセスできないようなファイアーウォール設定を行う）
リバースプロキシ構成
[インターネット（ユーザー）]
│ (HTTP/HTTPS)
[Nginx/HAProxy/Apache などのリバースプロキシ]
├─ (HTTP) ─> [WebサーバーA (静的ファイル)]
├─ (HTTP) ─> [アプリケーションサーバーB (API)]
└─ (HTTP) ─> [管理画面サーバーC]
リクエストがリバースプロキシに到達すると、 /api はサーバーBへ、 /static はサーバーAへ、 /admin はサーバーCへ振り分ける、という具合に URL やホストヘッダーなどでルーティング可能。