踏み台サーバのOS更新とKey Pair更新

 公開 2026-05-01

踏み台サーバを、監査や緊急対応にも耐えられる運用入口として設計する構成を整理する。

構成パターン ・ 認証・認証情報、運用の責務分離、ネットワーク・接続経路 ・ 親記事: DevSecOpsにおけるインフラ担当と運用担当の責務分離

踏み台サーバを、監査や緊急対応にも耐えられる運用入口として設計する考え方を整理する。

1. 業務課題

踏み台サーバは、プライベートネットワーク上のリソースへ到達するための管理された入口である。 したがって、踏み台自体の安全性は、接続先サーバやデータベースの安全性にも直結する。

社内監査では、次のような確認が行われる可能性がある。

  • 踏み台OSは最新化できる状態か
  • 踏み台の接続先IDや秘密鍵はどこで管理されているか
  • 踏み台のEC2 Key Pairや秘密鍵は漏えい時に更新できるか
  • 接続情報が漏えいした場合、再作成や差し替えの手順は明確か

これらに答えるには、単に踏み台サーバを用意するだけでは足りない。 OS更新、接続情報管理、Key Pair更新まで含めて、運用担当者が扱える入口を設計しておく必要がある。

2. 構成の考え方

この構成では、Bastion EC2をprivate subnetに配置し、public IPを付与しない。 接続はSSM Session Managerを前提とし、秘密鍵はSSM Parameter Storeで管理する。

運用担当がAWS CLIから、必要な時にSSM Parameter Storeの秘密鍵を取得し、SSM Session Managerとポートフォワードでプライベートネットワーク内の踏み台EC2に接続し、踏み台から接続先リソースへプライベート接続する経路図
日常の接続

OS更新の場合は、Bastion EC2を削除してTerraform applyすることで、最新AMIからEC2を再作成する。 Key Pair更新の場合は、Key Pairローテーション用の入力値を変更してTerraform applyすることで、 鍵素材、AWS EC2 Key Pair、SSM Parameter Storeの秘密鍵、Bastion EC2を一貫して更新する。

監査や緊急更新の要請を受けた運用担当が、OS更新ではEC2を削除してTerraform applyし、鍵更新ではKey Pairのローテーション用の入力値を変更してapplyする。Terraformは最新AMIで踏み台EC2を再作成し、新しい鍵素材でEC2 Key Pairを登録し、新しい秘密鍵をSSM Parameter Storeへ保存する流れ図
OS更新とKey Pair更新

色分け: 緑は運用担当者、黄は運用担当者が直接操作する入口またはリソース、青はインフラ担当が構成し運用接続の対象になるリソース、橙は監査や緊急更新など運用対応のきっかけ。

3. この構成で実現できること

  • 踏み台をprivate subnetに配置し、公開SSH入口を作らない
  • 接続はSSM Session Managerに寄せる
  • 秘密鍵をSSM Parameter Storeに集約し、人手のメモに散らばらせない
  • OS更新はEC2再作成として扱い、最新AMIから作り直せる
  • Key Pair更新はローテーション用入力値から実行し、秘密鍵、EC2 Key Pair、Bastion EC2を整合した状態で更新できる

踏み台を「接続できるサーバ」としてではなく、「監査や緊急対応にも耐えられる運用入口」として設計する。