はじめに

どーも！shihopowerです！

今日はEC2インスタンス作成時に割り当てる キーペア についてお話しします。

とある研修でEC2インスタンスを作成しようとしたところ、権限の制約でキーペアを割り当てられない状態になっていました。私は「あ、割り当てられないんだ」とそのままスルーしたのですが、他の研修受講生から「キーペアを割り当てないとセキュリティリスクが高まるよ」と教えていただいて……

いったい何がどうまずいのか？そもそもキーペアって何のためにあるのか？

気になったので、AWS公式ドキュメントを参照して徹底的に調べてみました。

対象読者

AWSを学び始めたばかりの方
EC2インスタンスを触り始めた方
キーペアを「なんとなく」割り当てていた方
キーペアなしで起動して「まあいいか」と思っていた方（過去の私）

忙しい人向けの要約

キーペアとは「公開鍵＋秘密鍵」のペアで、EC2インスタンスへの接続に使うセキュリティ認証情報
公開鍵はAWS（インスタンス内）が保管、秘密鍵は自分が保管する
LinuxはSSH接続、Windowsは管理者パスワードの復号化に使う
キーペアなしで起動すると、基本的にインスタンスに接続できなくなる（AWS公式が「非推奨」と明記）
キーペアなしのリスクは「パスワード認証への依存」「rootへの無防備なアクセス」「中間者攻撃」「コンプライアンス違反」など多岐にわたる
代替手段としてAWS Systems Manager Session Managerを使えばキーペア不要での接続も可能

1. キーペアとは何か

AWS公式ドキュメント（Amazon EC2ユーザーガイド）では、キーペアを以下のように定義しています。

キーペアにはプライベートキーと公開キーを含んでおり、Amazon EC2 インスタンスへの接続時の身分証明に使用する、セキュリティ認証情報のセットを構成しています。

出典：Amazon EC2 のキーペアと Amazon EC2 インスタンス

つまりキーペアとは、EC2インスタンスに接続するための「鍵のセット」 です。

公開鍵と秘密鍵、それぞれの役割

	公開鍵（パブリックキー）	秘密鍵（プライベートキー）
保管場所	AWSがインスタンス内に保管	自分のPCに保管（`.pem`ファイル）
役割	接続者の照合に使う	接続時に自分の身元を証明する
例え	南京錠（誰でも見られるが開けられない）	南京錠の鍵（自分だけが持つ）

公式ドキュメントにはこう書かれています。

パブリックキーは Amazon EC2 によりお客様のインスタンス内に保管されます。またプライベートキーはお客様自身が保管します。プライベートキーを所有するすべてのユーザーはキーペアを使用するインスタンスに接続できるため、プライベートキーを安全な場所に保存することが重要です。

出典：Amazon EC2 のキーペアと Amazon EC2 インスタンス

LinuxとWindowsで異なる使われ方

OSによってキーペアの使い方が変わります。

Linux インスタンスの場合、プライベートキーを使用すると、インスタンスに安全に SSH 接続できます。Windows インスタンスの場合、管理者パスワードを復号化するにはプライベートキーが必要です。

出典：Amazon EC2 のキーペアと Amazon EC2 インスタンス

また、インスタンス起動時に公開鍵がどこに配置されるかも明記されています。

Linux インスタンスではインスタンスを初めて起動する際に、起動時に指定したパブリックキーが Linux インスタンス上で ~/.ssh/authorized_keys 内のエントリに配置されます。SSH を使用して Linux インスタンスに接続する際のログインにはパブリックキーに対応するプライベートキーを指定する必要があります。

出典：Amazon EC2 のキーペアと Amazon EC2 インスタンス

2. 公開鍵・秘密鍵のサンプル（AWS公式ドキュメントより）

実際にどんな見た目なのか、AWS公式ドキュメントに掲載されているサンプルを紹介します。

公開鍵のサンプル

ssh-keygen -y -f /path_to_key_pair/key-pair-name.pem コマンドを実行すると、以下のような公開鍵が出力されます。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0i
BXrlsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQ
k+0FzZqaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rW
i+z7wB3RbBQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE

出典：Manage system users on your Amazon EC2 Linux instance

秘密鍵のサンプル

aws ec2 create-key-pair コマンドで生成・保存される .pem ファイルの内容はこのような形式です。

-----BEGIN RSA PRIVATE KEY-----
EXAMPLEKEYKCAQEAy7WZhaDsrA1W3mRlQtvhwyORRX8gnxgDAfRt/gx42kWXsT4r
XE/b5CpSgie/vBoU7jLxx92pNHoFnByP+Dc21eyyz6CvjTmWA0JwfWiW5/akH7iO
...
-----END RSA PRIVATE KEY-----

出典：AWS CLI での Amazon EC2 キーペアの作成、表示、削除

両者の違いまとめ

	公開鍵	秘密鍵
ヘッダー	`ssh-rsa` で始まる	`-----BEGIN RSA PRIVATE KEY-----` で始まる
保存場所	インスタンス内 `~/.ssh/authorized_keys`	自分のPC（`.pem` ファイル）
形式	OpenSSH形式	PEM形式

⚠️ 上記はAWS公式ドキュメントに掲載されているフォーマット例示用のダミー値です。末尾の EXAMPLE からも分かるとおり、実際には使用できません。

3. EC2インスタンス作成時にキーペアを割り当てる必要性

キーペアは唯一の接続手段

インスタンス起動ウィザードのパラメータ解説ページには、こう書かれています。

キーペアを除き、インスタンス起動ウィザードは各パラメータのデフォルト値を提供します。

出典：Amazon EC2 インスタンス設定パラメータのリファレンス

他のパラメータにはデフォルト値があるのに、キーペアだけはデフォルト値がない。それだけ重要な設定ということです。

キーペアなしで起動するとどうなる？

公式はズバリこう言っています。

「キーペアなしで進む」オプションを選択した場合（非推奨）、ユーザーが別の方法でログインすることを許可するように設定された AMI を選択した場合でなければ、インスタンスに接続できなくなります。

出典：Amazon EC2 インスタンス設定パラメータのリファレンス

「非推奨」と明記されています。 キーペアを割り当てないまま起動すると、そのインスタンスへのログイン手段が事実上なくなります。

なぜ後からキーペアを割り当てられないのか

Amazon EC2 ではプライベートキーのコピーが保持されないため、プライベートキーを失った場合、復元することはできません。

出典：Amazon EC2 のキーペアと Amazon EC2 インスタンス

キーペアはインスタンス起動時にのみ割り当てられるもので、起動後に追加・変更することは基本的にできません。だからこそ、起動前に必ず設定しておく必要があります。

4. キーペアなしで起動した場合のセキュリティリスク

キーペアがない＝パスワードベースの認証に頼ることになります。これには複数のリスクがあります。

リスク1：パスワード認証への依存

公式ドキュメントは、パスワード認証の危険性をはっきりと述べています。

固定のrootパスワードを公開AMIに使用することはセキュリティリスクであり、すぐに知られてしまう可能性があります。最初のログイン後にユーザーがパスワードを変更することに頼る場合でも、潜在的な悪用の機会を生む小さな窓が開いてしまいます。

出典：Recommendations for creating shared Linux AMIs

キーペアはまさにこのリスクを解消するために存在します。

パブリックAMIから作成されたEC2インスタンスは、SSHでサインインする際にパスワードではなく公開鍵・秘密鍵のペアを使用します。パブリックキーはインスタンスに埋め込まれ、プライベートキーを使ってパスワードなしで安全にサインインします。

出典：Amazon Web Services: Overview of Security Processes

リスク2：rootログインの無防備な有効化

EC2 Linuxインスタンスのデフォルト設定はこうなっています。

デフォルトでは、パスワード認証とrootログインは無効化されており、sudoが有効になっています。インスタンスにログインするにはキーペアを使用する必要があります。

出典：Manage system users on your Amazon EC2 Linux instance

キーペアなしにしてパスワード認証を有効にすると、このデフォルトの保護が崩れます。公式はrootへの直接ログインを無効化することをベストプラクティスとして明示しており、

共有AMIを扱う場合のベストプラクティスとして、直接のrootログインを無効化することが推奨されています。

出典：Recommendations for creating shared Linux AMIs

と述べています。

リスク3：中間者攻撃（MitM）のリスク

SSHホストキーの管理を怠ると、中間者攻撃のリスクが生まれます。

既存のSSHホストキーペアを削除することで、誰かがあなたのAMIを使用してインスタンスを起動したときにSSHが新しいユニークなSSHキーペアを生成するよう強制されます。これによりセキュリティが向上し、「中間者攻撃（man-in-the-middle attack）」の可能性が低下します。

出典：Recommendations for creating shared Linux AMIs

リスク4：コンプライアンス違反・AWSによる検出

AWSはキーペアなしのインスタンスをコンプライアンス違反として検出する仕組みを持っています。

ユーザーがキーペアをアタッチせずに誤ってインスタンスを起動することがあります。キーペアはインスタンスの起動時にのみ割り当てることができるため、キーペアなしで起動したインスタンスをすばやく特定し、非対応としてフラグを立てることが重要です。

出典：AWS Config を使用して EC2 インスタンスのキーペアを監視する

さらにSSHホストキーペアが残ったAMIを公開してしまった場合、AWSが自ら動きます。

既存のSSHホストキーペアを公開AMIから削除し忘れた場合、AWSの定期的な監査プロセスがあなたとそのAMIを使用しているすべての顧客に対してセキュリティリスクの可能性を通知します。短い猶予期間の後、そのAMIはプライベートとしてマークされます。

出典：Recommendations for creating shared Linux AMIs

リスクまとめ

リスク	内容
パスワード認証への依存	固定パスワードはすぐに漏洩・悪用される
rootアクセスの無防備化	デフォルトで無効のrootログインが有効になりうる
中間者攻撃（MitM）	SSHホストキーの使い回しで攻撃のリスクが高まる
コンプライアンス違反	AWSがキーペアなしインスタンスを非準拠として検出・通知

5. キーペアなしでも接続できる代替手段

キーペアが使えない状況でも、接続する方法はあります。

キーペアの代わりに、インタラクティブなワンクリックのブラウザベースのシェルまたは AWS Command Line Interface (AWS CLI) を使用してインスタンスに接続するために、AWS Systems Manager Session Manager を使用できます。

出典：Amazon EC2 のキーペアと Amazon EC2 インスタンス

AWS Systems Manager Session Manager を使えば、キーペアなしでもブラウザやCLIからインスタンスに接続できます。私の研修のように「キーペアを割り当てられない」制約がある環境では、こちらが有効な選択肢です。

6. まとめ

今回はAWS公式ドキュメントのみを参照して、キーペアについて根本から調べてみました。

「なんとなく割り当てていた」キーペアが、実はパスワード認証という古典的な攻撃手法を排除するための重要な仕組みだということが分かりました。また、AWSがデフォルトで「パスワード認証無効・rootログイン無効・キーペアでのみ接続」という安全な設計にしていることも、あらためて理解できました。

研修でスルーしてしまったあの瞬間、もし自分がそのままインスタンスを使い続けていたら……と思うとちょっとヒヤっとしますね😅

最後に、キーペアに関する重要ポイントを振り返ります。

ポイント	内容
キーペアとは	公開鍵＋秘密鍵のセット。EC2接続の認証情報
公開鍵の保管場所	AWSがインスタンス内に保管
秘密鍵の保管場所	自分のPCに保管（紛失したらAWSでも復元不可）
割り当てなかった場合	接続できなくなる（AWS公式が「非推奨」と明記）
主なリスク	パスワード依存・root無防備化・MitM・コンプライアンス違反
代替手段	AWS Systems Manager Session Manager

参考：AWS公式ドキュメント