こんにちは！インフラやセキュリティの世界へようこそ。
新しいシステムの開発やサーバーの構築、ワクワクしますよね。「よし、動いた！」という瞬間の達成感は、エンジニアならではの最高の醍醐味です。
ところで、皆さんはサーバーにアクセスするとき、どんな方法を使っていますか？
「.pemや.id_rsaといった秘密鍵ファイルを使って、SSHでログインしているよ」という方が多いのではないでしょうか。実はこれ、長年インフラ業界の「お決まり」として使われてきましたが、セキュリティの現場や私たちホワイトハッカーの視点から見ると、今やトラブルの温床になりやすい大きな弱点を抱えています。
今回は、そんな「古いSSH鍵の管理」から脱却し、AWSの仕組みを使って安全かつスマートにサーバーへアクセスする手法、「AWS Systems Manager Session Manager（以下、SSM）」への切り替えについて、身近な防犯の例えを交えながら一歩ずつ優しく解説していきますね！
—
1. なぜ「SSH鍵」はトラブルの温床になるのか？（家の鍵に例えて考える）
まずは、これまで当たり前のように使われてきた「SSH鍵認証」の何が危険なのか、私たちの身近な「家の鍵」に例えて考えてみましょう。
想像してみてください。あなたは一軒家を建てました。家族や信頼できる友人に家に出入りしてもらうため、合鍵（SSHの秘密鍵）を何本も作り、それぞれに渡しました。ここまでは良いですよね。
しかし、時間が経つにつれて、こんな問題が起きてきます。
- 友人の一人が会社を辞めたり、チームを離れたりした。でも、その人に渡した合鍵を回収し忘れた！
- 誰かがノートパソコンごとカバンを盗まれてしまい、その中にサーバーの合鍵（秘密鍵）が入っていた！
- 「ちょっと面倒だから」と、パスワード（パスフレーズ）を設定していない合鍵をUSBメモリに保存したまま、どこかに置き忘れてしまった！
…どうですか？想像するだけで冷や汗が出てきますよね。一度ばらまいてしまった合鍵をすべて回収し、無効化するのは大変な労力です。
ITの世界でも全く同じことが起きるのです。
開発者のパソコンの中に秘密鍵が散らばり、退職者の鍵がそのまま放置され、最悪の場合、GitHubなどの公開リポジトリにうっかり秘密鍵をアップロードしてしまい、世界中の泥棒にサーバーの合鍵をプレゼントしてしまう……というインシデントが後を絶ちません。
これが、私たちが「SSH鍵の管理」に頭を悩ませる理由です。
—
2. そこで登場するのが「AWS Systems Manager Session Manager（SSM）」です
「じゃあ、合鍵を配るのをやめて、もっと安全で確実な方法にしようよ！」という発想から生まれたのが、今回ご紹介する AWS Systems Manager Session Manager です。
SSMを使ったアクセス方法は、家の鍵に例えるなら「頑丈な合鍵を配るのをやめて、警備員が常駐するオートロックの総合受付を通る仕組み」に変えるようなものです。
SSMのすごいところ
1. サーバーに合鍵（SSHポート：22番）を置く必要がない！
インターネットからサーバーへ直接アクセスするための穴（SSHの窓口）を完全に塞ぐことができます。窓口がなければ、外からの不審者はそもそも侵入を試みることすらできません。
2. 「誰が・いつアクセスしたか」がすべて記録される！
AWSの管理システム（IAM）を通るため、「誰がどのサーバーに入って、どんな操作をしたのか」がログとして完全に残ります。
3. 退職者のアクセス権限も一発で無効化できる！
個人のパソコンにある秘密鍵を回収する必要はありません。AWSの管理画面（IAM）でその人のアカウントを無効化するだけで、一瞬でサーバーへの道が断たれます。
つまり、面倒で危険な「秘密鍵のファイル管理」から私たちを解放してくれる、最強の防犯システムというわけですね。
—
3. 実践！踏み台サーバーを廃止してSSMで安全に接続する
それでは、実際にどのように環境を整え、接続できるようにするのかを見ていきましょう。
「難しそう…」と思うかもしれませんが、ポイントを押さえれば手順はシンプルです。
ステップ1：EC2インスタンスに「SSMエージェント」と「正しい権限」を準備する
まず、AWS上のサーバー（EC2インスタンス）からSSMへ通信できるように設定します。
これには、インスタンスに「SSMエージェント」という小さなプログラムが動いていることと、AWSのサービス同士が通信するためのIAMロール（身分証明書のようなもの）が必要です。
TerraformなどのIaC（コードによるインフラ構築）を使う場合は、以下のようなイメージで設定します。
# 1. EC2インスタンスにアタッチするIAMロールの定義
resource "aws_iam_role" "ssm_instance_role" {
name = "ec2-ssm-connection-role"
# EC2がこのロールを使用できるようにする信頼ポリシー
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ec2.amazonaws.com"
}
}
]
})
}
# 2. AWS公式が用意している「SSMを使ってね」という便利な権限をアタッチする
resource "aws_iam_role_policy_attachment" "ssm_server_policy" {
role = aws_iam_role.ssm_instance_role.name
policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" # これが心臓部です！
}
# 3. インスタンスプロファイルを作成し、EC2に紐付ける
resource "aws_iam_instance_profile" "ssm_profile" {
name = "ec2-ssm-instance-profile"
role = aws_iam_role.ssm_instance_role.name
}この設定によって、サーバー側は「私はAWSの管理下にあり、セキュアに通信する許可を持っています」という状態になります。
ステップ2：開発者のパソコンから接続してみよう！
サーバー側の準備ができたら、開発者側の操作です。
従来のように ssh -i key.pem ec2-user@<IPアドレス> と打つ必要はもうありません。AWS CLI（コマンドラインツール）を使って、以下のようにスマートに接続します。
# AWS Systems Managerのセッション機能を使って、インスタンスIDを指定して接続する
aws ssm start-session --target i-0123456789abcdef0たったこれだけです！
秘密鍵のファイルをパソコンのどこかに保存しておく必要も、パーミッション（権限設定）で悩む必要もありません。裏側ではAWSの強力な認証・暗号化基盤（IAM）がしっかりとユーザーの身元を確認してくれています。
—
4. セキュリティを高めるための実務の泥臭いポイント
さて、ここまでで「SSH鍵を廃止してSSMに移行するメリット」が伝わったかと思いますが、実際の現場ではもう少しだけ気をつけるべき「泥臭いポイント」があります。
① セキュリティグループの22番ポート（SSH）は完全に閉じる
「念のため…」とSSH用の22番ポートを開けたままにしておくと、そこが攻撃者の標的になります。SSMを使う場合、インバウンド（外部からの通信）の22番ポートは一切不要（すべて閉じる）が正解です。アウトバウンド（外への通信）についても、必要な最小限の通信（HTTPSなど）に絞り込みましょう。
② 接続ログをAmazon CloudWatchやS3に保存する
「誰がいつサーバーに入ったか」の監査ログは、万が一インシデント（不正アクセスなど）が起きたときの重要な手がかりになります。SSMの設定画面から、セッションログの出力先としてS3バケットやCloudWatch Logsを指定しておきましょう。
—
まとめ：一歩ずつ、安全なインフラへ
今回は、SSH鍵認証の抱えるリスクと、それを根本から解消するAWS Systems Manager Session Managerの仕組みについて解説しました。
- SSH鍵は「合鍵」と同じ。配り歩く・管理するリスクが大きい。
- SSMを使えば、22番ポートを閉じたまま、IAM認証ベースで安全にサーバーへアクセスできる。
- 退職者が出ても鍵の回収に怯える必要がなくなる！
セキュリティの対策に「終わり」はありません。しかし、こうしたモダンな仕組みに少しずつ切り替えていくことで、システム全体の安全性は劇的に向上します。
「難しそうだな」と感じた方も、まずは検証環境などで一度試してみてくださいね。一歩ずつ、より安全なエンジニアリングの世界へ進んでいきましょう！
コメント