SSH踏み台か直接VPNアクセスか：適用されるのはどちらのポリシーか

VPN利用者がジャンプホストを経由せずにサーバーへ到達してよいかは、ネットワークの装いをしたポリシーの問題である。踏み台が必須の統制を担っているなら、VPNへの接続はそれを迂回するのではなく、そこへ導くものでなければならない。ジャンプホストがかつて到達できなかったセグメントを橋渡ししていただけなら、狭い直接経路が誠実な代替になり得る。以下の確認を順に進め、最初に失敗した確認で止めること。その答えが残りを決めるからだ。

踏み台が実際に何を制御しているかを確認する

設計書の図ではなく、現状についての証拠から始める。対象のSSH設定とパケットフィルターを見る。受信ポート22が踏み台のアドレスからのみ許可されているなら、ジャンプホストは強制された統制である。同じポートがVPNプール全体からの接続を受け付けるなら、踏み台は便宜にすぎず、強制はまったく別の場所にある。チケット履歴は通常、どちらが先に存在したかを裏づける。

踏み台が提供する統制を名指しする一文で所見を述べる。宛先の制限、二段目の認証、セッション記録、あるいはインシデント時の運用上の可視性である。その一文こそ、代替ポリシーが維持すべきものだ。

対象が経路を区別できるかを確認する

送信元アドレスの規則は、二つの経路が異なる送信元アドレスで届く間だけ機能する。サーバーサブネットへの通信をマスカレードするVPNゲートウェイはその違いを消してしまい、そのときポート22への接続はすべてゲートウェイから来たように見える。確認は対象の上で完結し、一瞬で終わる。確立済みのSSHセッションを一覧し、それぞれのピアアドレスを読む。

両方の経路が一つのアドレスに潰れる場合、区別はもっと前で行う必要がある。VPNが押し出してよい宛先と、ゲートウェイ自身のフィルターによってである。その状況で対象に規則を足しても、届くものを変えずに境界の錯覚を作るだけだ。

各記録が実際に何を保持しているかを確認する

三つの異なるログは三つの異なる事象を記述しており、どれも他の代わりにはならない。VPNの接続記録は、ある識別情報がネットワークの範囲に入ったことを示す。踏み台の転送記録は、そこから宛先とポートへ向かうTCPチャネルを示す。対象の認証ログは、あるアカウントがSSHでサインインしたことを示す。これらを併せて読むことで初めて時系列が生まれ、一つだけ読めば推測が生まれる。

これらの記録のどれも、クライアントと対象の間の暗号化されたセッションの内部で起きたことを含んでいない。コマンド単位のレビューが要件なら、独自のデータ取り扱い規則を持つ記録機構を意図的に配備する必要がある。ジャンプホストのログにそれを期待するのは、監査の隙間が重大になるまで隠れ続ける道である。

ポリシーが実際にどこで強制されるかを確認する

ProxyJumpのようなクライアント設定は要求であって制限ではない。宛先に到達できるならOpenSSHは喜んで直接接続を開くので、ノートPCの設定ファイルは意図を述べ、結果を決めるのはファイアウォールである。強制はVPNゲートウェイの許可宛先と、対象自身のアクセス規則に属し、どちらも利用者は編集できない。同時に代替経路を監査すること。二つ目のインターフェース、公開リスナー、メッシュのオーバーレイ、古い拠点間トンネルは、いずれも今閉じた近道を復活させ得る。

それでもProxyJumpを設定する。承認された経路を楽な道にし、日常業務が例外を生み出すのを防ぐからだ。信頼する前に、クライアントが実際に何を解決するかを確認すること。

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

意図的な直接試行で検証する

試されたことのないポリシーは希望にすぎない。VPNに接続したクライアントから、いま拒否されるべき経路を試し、次に承認された経路を試し、両方の結果を残す。拒否された試行こそ、変更が効いた証拠である。

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

きれいな結果とは、対象アドレスへの直接接続が拒否されるかタイムアウトし、続いてジャンプホストへのログインが成功し、対象側に支援された送信元を名指す認証エントリが残る形である。それ以外なら、文書が何と言おうと境界はまだ穴だらけだ。日付、変更した規則、二つの結果を記録し、そのうえで 復旧経路に所有者と有効期限を与える 緊急アクセスが静かに日常の経路にならないようにするためである。