【ITニュース解説】Enable Session Manager and delete shared ssh keys

システムエンジニアとして多くのサーバーを管理する際、セキュリティは最も重要な課題の一つだ。特に、サーバーへのアクセス方法はその根幹をなす。これまで、仮想サーバーであるEC2インスタンスにアクセスする一般的な方法の一つは、SSH（Secure Shell）というプロトコルと、それに伴うSSHキーの利用だった。しかし、SSHキーの管理、特に複数のエンジニア間でSSHキーを共有している場合、セキュリティリスクが高まり、鍵の更新や削除といった運用が非常に煩雑になるという課題があった。この記事では、この問題を解決し、より安全かつ効率的にEC2インスタンスにアクセスし、共有SSHキーを安全に削除する手法について解説する。

まず、SSHキーを使わずにEC2インスタンスへアクセスする環境を整えることから始める。これには、AWSが提供する「AWS Systems Manager」というサービスの中にある「Session Manager」という機能を利用する。AWS Systems Managerは、AWS上のインフラストラクチャを大規模に管理・運用するための統合サービスであり、Session Managerはその一部として、ブラウザベースまたはコマンドラインからEC2インスタンスに安全に接続するための機能を提供する。

最初の手順は、Session Managerを有効にすることだ。AWSマネジメントコンソールからSystems Managerの画面へ進み、Session Managerが有効になっていることを確認する。次に、EC2インスタンスがSession Managerと通信できるように、特定の「IAMロール」を付与する必要がある。IAMロールとは、AWSリソースに与える権限のまとまりであり、今回は「AmazonSSMManagedInstanceCore」というロールをEC2インスタンスにアタッチする。これにより、EC2インスタンスはSystems Managerエージェントを通じてSystems Managerサービスと安全に通信できるようになる。この設定が完了すると、Systems Managerの「マネージドインスタンス」という項目に、アクセスしたいEC2インスタンスが表示されるようになる。これは、Session Managerによる管理対象になったことを意味し、SSHキーなしでインスタンスへアクセスする準備が整ったことを示す。

次に、この新しいアクセス方法が正しく機能するかを検証する。AWSコマンドラインインターフェース（CLI）から、aws ssm start-session --target <インスタンスID>というコマンドを実行してみる。これにより、SSHキーや、従来外部からプライベートネットワーク内のサーバーに接続する際に中継役として使われていた「踏み台ホスト（Bastion Host）」を介することなく、直接EC2インスタンスに接続できるはずだ。この接続が成功すれば、Session Managerによるアクセス環境が完全に整ったことになる。

アクセス検証が完了したら、いよいよセキュリティリスクの原因となっていた共有SSHキーを削除する段階に進む。共有SSHキーは、もし一つでも漏洩すれば、その鍵を使っている全てのサーバーへの不正アクセスを許してしまう可能性があるため、コンプライアンス（法令や規制の遵守）の観点からも速やかに削除すべきだ。

共有SSHキーを削除する方法は二つある。一つは手動での削除だ。Session Managerで個々のインスタンスに接続し、SSHの認証に使われるファイルを直接削除する。具体的には、ユーザーのホームディレクトリにある.ssh/authorized_keysというファイルをsudo rm /home/ec2-user/.ssh/authorized_keysといったコマンドで削除する。このファイルには、そのユーザーでSSH接続を許可する公開鍵が記録されており、これを削除することで、そのファイルに登録されていた鍵を使ったSSH接続を無効にできる。もし他のユーザーアカウントもSSHアクセスを許可していた場合は、それらのユーザーのホームディレクトリにある同様のファイルも削除する必要がある。

しかし、手動での削除は、インスタンスが多数ある場合、非常に手間がかかり現実的ではない。そこで活用するのが、Systems Managerのもう一つの強力な機能である「Run Command」だ。Run Commandは、複数のEC2インスタンスに対して、一度に同じコマンドを同時に実行できる機能であり、大規模な環境での管理作業を劇的に効率化する。Run Commandの画面で、「AWS-RunShellScript」というドキュメントを選択し、削除したいファイルのパスを指定するコマンド、例えばrm /home/ec2-user/.ssh/authorized_keysやrm /root/.ssh/authorized_keysといった命令を記述する。その後、対象となるインスタンスを全て選択して実行すれば、一度に全てのインスタンスから共有SSHキーを削除できる。これにより、手動で何百ものインスタンスにログインして作業する手間が省け、作業時間を大幅に短縮できる。

キーの削除作業が終わったら、それが本当に完了し、意図した通りの状態になっているかを必ず確認する必要がある。Systems ManagerやAWS Configといったサービスを利用して、.ssh/authorized_keysファイルが全てのユーザーで空になっているか、あるいは存在しないかを確認する。AWS Configは、AWSリソースの設定変更を継続的に監視し、設定が期待通りであるかをチェックしてくれるサービスだ。これを利用すれば、設定の遵守状況を継続的に監査できる。また、AWS CloudTrailのログを確認し、コンプライアンスに関連する記録に問題がないかもチェックする。CloudTrailは、AWSアカウント内で行われた全てのAPI操作やイベントを記録し、セキュリティ分析や監査の証跡を提供する。

最後に、単に既存のSSHキーを削除するだけでなく、将来的に新しいSSHキーが誤ってデプロイされてしまうことを防ぐための対策も講じる必要がある。これにはいくつかの方法がある。まず、EC2インスタンスの元となるテンプレートである「AMI（Amazon Machine Image）」にSSHキーが含まれていないかを確認し、もし含まれていれば、それらを削除した新しいAMIを作成して使用する。次に、EC2インスタンス起動時に自動的に実行される「ユーザーデータスクリプト」に、SSHキーを自動的に設定するような記述がないかをチェックし、もしあれば削除する。さらに、継続的インテグレーション/デリバリー（CI/CD）パイプラインなどの自動化ツールやスクリプトが、SSHキーの「プロビジョニング」（設定や配布）を行っていないかを確認し、その機能を削除する。これらの対策によって、システム全体でSSHキーのデプロイを根本的に防ぎ、セキュリティ体制を一層強化できる。

この一連のプロセス、特にSession ManagerとRun Commandを組み合わせることで、セキュリティを大幅に向上させつつ、多数のインスタンスに対する管理作業を劇的に効率化できる。システムエンジニアとして、このような先進的なセキュリティ管理手法を理解し、活用することは、今後のキャリアにおいて非常に重要なスキルとなるだろう。