鍵管理という「終わりのない悪夢」から卒業せよ：SSH廃止とSSM Session Managerへの移行論
エンジニアの皆さん、こんにちは。現場でインシデント対応をしていると、決まって遭遇する「死のパターン」があります。それは、「踏み台サーバー（Bastion Host）の鍵が流出・放置され、そこを足掛かりに本番環境が蹂躙される」というシナリオです。
SSH鍵は便利ですが、一度Gitの履歴に紛れ込んだり、PCのHDD紛失とともに流出したりすれば、その瞬間にあなたのネットワーク境界は「存在しない」のと同じになります。今日は、RSAや楕円曲線暗号（ECC）の数学的な美しさの話ではなく、それらを取り巻く「人間という脆弱性」をシステム的に無効化する話をしましょう。
なぜ今、SSHの「鍵認証」を捨てるべきなのか
SSHの鍵認証は、鍵そのものが「唯一のパスポート」です。誰が持っているか、いつ生成されたか、ローテーションされているかを厳密に管理するのは至難の業です。
攻撃者は、GitHubの公開リポジトリをスキャンしたり、開発者の端末をマルウェアで汚染して ~/.ssh を丸ごと抜き取ったりします。一度鍵を奪えば、多要素認証（MFA）をすり抜けて、OSの管理者権限まで一直線です。
これを解決する唯一の解が、AWS Systems Manager (SSM) Session Manager への移行です。
SSM Session Manager：攻撃者が最も嫌う「透過的アクセス」
SSM Session Managerは、SSHのような「恒久的なポート開放（22番ポート）」を必要としません。通信はHTTPS（443番ポート）経由でAWSのコントロールプレーンを介して行われ、認証はすべてIAMで行われます。
- IP制限不要: 踏み台サーバー自体を撤去できる。
- 証跡管理: セッションの操作ログがCloudWatch LogsやS3に自動保存される。
- IAM一元管理: 退職者のアクセス権剥奪がIAMの一括削除で完結する。
実装：AWS IAMによる鉄壁の制御
まず、EC2インスタンスに付与するIAMロールの最小権限設定（ポリシー）を見てください。これは「SSMエージェントがAWSと会話するためのチケット」です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceInformation",
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel",
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*"
}
]
}このポリシーをインスタンスプロファイルとして割り当てるだけで、SSHポートをセキュリティグループから削除できます。「22番ポートを閉じる」という行為こそが、攻撃者に対する最大の拒絶です。
現場で直面する「運用の壁」を越えるコツ
「SSHを使わないと、VS CodeのRemote Developmentが使えない」という現場の不満はよく聞きます。しかし、これもSSMのプロキシ機能を使えば解決します。ローカルの ~/.ssh/config を以下のように設定してください。
# これにより、VS CodeやscpコマンドがSSM経由で透過的に通信できるようになる
host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"こうすることで、開発者は意識することなく、IAM認証（あるいは一時的なセッショントークン）だけでセキュアにサーバーへ接続できます。
最後に：セキュリティは「性悪説」で設計せよ
セキュリティの真髄は、「人間はミスをする」「鍵は必ず紛失する」という前提でシステムを構築することです。
SSH鍵を管理し続けることは、穴の空いたバケツで水を運ぶようなものです。Session Managerに移行すれば、鍵のライフサイクル管理から解放され、監査ログという強力な武器が手に入ります。
次にあなたがやるべきことは、全サーバーのセキュリティグループから22番ポートを削除し、IAMユーザーに適切なセッション権限を付与することです。明日と言わず、今すぐ着手してください。それが、あなたのシステムを「標的」から「要塞」に変えるための最初の一歩です。
何か技術的な壁にぶつかったら、また聞きに来てください。我々の仕事は、泥臭い運用を自動化し、より創造的な開発に集中できる環境を作ることなのですから。
コメント