ECS + SSM で実現するセキュアなワンタイム踏み台サーバー

ツール導入前の課題

当初は「昔ながら」の EC2 + SSH で踏み台サーバーを運用していました。しかし、鍵の管理やセキュリティグループの運用負荷が高かったため、まずは EC2 + SSM Session Manager への移行を行いました。

これにより、踏み台をパブリックサブネットに置く必要がなくなり、SSH 鍵の運用からも解放されました。

しかし、EC2 + SSM に移行したことで利便性は向上しましたが、以下の3つの課題は残りました。

• 脆弱性対応
  • AWS Inspector を確認すると、どうしても Affected Resources（影響を受けているリソース）として踏み台 EC2 がリストアップされます。
• 常時起動によるセキュリティリスク
  • 踏み台が常に稼働していることは、潜在的な侵入経路を晒し続けることを意味します。必要な時以外は「存在しない」状態が理想でした。
• 権限管理の粗さ
  • IAM Role に権限があれば、その Role を持つ全員がログインできてしまいます。「特定の人が、その作業のためにだけ使う」というアイデンティティに基づいた制御には限界がありました。

どのような状態を目指していたか

• セキュアな踏み台サーバー

• Amazon Elastic Kubernetes Service
  • ECS で要件を満たせていたので採用は見送りました

• 運用コストの極小化
  • EKS はクラスター自体の運用が必要ですが、コントロールプレーンの管理すら不要な ECS + Fargate が最適解だった

改善したかった課題はどれくらい解決されたか

• 踏み台を常時起動からオンデマンドに変更することでセキュリティリスク軽減
• ABAC によるログイン制限

どのような成果が得られたか

• EC2 の脆弱性対応から解放

• コンテナの起動速度
  • SOCI Index を使用することで起動速度は多少は改善されました

現在は AWS アカウントごとにこの仕組みを展開していますが、セットアップの自動化がまだ完全ではなく、横展開の手間が課題として残っています