踏み台サーバを、監査や緊急対応にも耐えられる運用入口として設計する考え方を整理する。
1. 業務課題
踏み台サーバは、プライベートネットワーク上のリソースへ到達するための管理された入口である。 したがって、踏み台自体の安全性は、接続先サーバやデータベースの安全性にも直結する。
社内監査では、次のような確認が行われる可能性がある。
- 踏み台OSは最新化できる状態か
- 踏み台の接続先IDや秘密鍵はどこで管理されているか
- 踏み台のEC2 Key Pairや秘密鍵は漏えい時に更新できるか
- 接続情報が漏えいした場合、再作成や差し替えの手順は明確か
これらに答えるには、単に踏み台サーバを用意するだけでは足りない。 OS更新、接続情報管理、Key Pair更新まで含めて、運用担当者が扱える入口を設計しておく必要がある。
2. 構成の考え方
この構成では、Bastion EC2をprivate subnetに配置し、public IPを付与しない。 接続はSSM Session Managerを前提とし、秘密鍵はSSM Parameter Storeで管理する。
OS更新の場合は、Bastion EC2を削除してTerraform applyすることで、最新AMIからEC2を再作成する。 Key Pair更新の場合は、Key Pairローテーション用の入力値を変更してTerraform applyすることで、 鍵素材、AWS EC2 Key Pair、SSM Parameter Storeの秘密鍵、Bastion EC2を一貫して更新する。
色分け: 緑は運用担当者、黄は運用担当者が直接操作する入口またはリソース、青はインフラ担当が構成し運用接続の対象になるリソース、橙は監査や緊急更新など運用対応のきっかけ。
3. この構成で実現できること
- 踏み台をprivate subnetに配置し、公開SSH入口を作らない
- 接続はSSM Session Managerに寄せる
- 秘密鍵をSSM Parameter Storeに集約し、人手のメモに散らばらせない
- OS更新はEC2再作成として扱い、最新AMIから作り直せる
- Key Pair更新はローテーション用入力値から実行し、秘密鍵、EC2 Key Pair、Bastion EC2を整合した状態で更新できる
踏み台を「接続できるサーバ」としてではなく、「監査や緊急対応にも耐えられる運用入口」として設計する。