はじめに
どーも！shihopowerです！
今日はEC2インスタンス作成時に割り当てる キーペア についてお話しします。
とある研修でEC2インスタンスを作成しようとしたところ、権限の制約でキーペアを割り当てられない状態になっていました。私は「あ、割り当てられないんだ」とそのままスルーしたのですが、他の研修受講生から「キーペアを割り当てないとセキュリティリスクが高まるよ」と教えていただいて……
いったい何がどうまずいのか？そもそもキーペアって何のためにあるのか？
気になったので、AWS公式ドキュメントを参照して徹底的に調べてみました。
対象読者
- AWSを学び始めたばかりの方
- EC2インスタンスを触り始めた方
- キーペアを「なんとなく」割り当てていた方
- キーペアなしで起動して「まあいいか」と思っていた方（過去の私）
忙しい人向けの要約
- キーペアとは「公開鍵＋秘密鍵」のペアで、EC2インスタンスへの接続に使うセキュリティ認証情報
- 公開鍵はAWS（インスタンス内）が保管、秘密鍵は自分が保管する
- LinuxはSSH接続、Windowsは管理者パスワードの復号化に使う
- キーペアなしで起動すると、基本的にインスタンスに接続できなくなる（AWS公式が「非推奨」と明記）
- キーペアなしのリスクは「パスワード認証への依存」「rootへの無防備なアクセス」「中間者攻撃」「コンプライアンス違反」など多岐にわたる
- 代替手段としてAWS Systems Manager Session Managerを使えばキーペア不要での接続も可能
目次
- キーペアとは何か
- 公開鍵・秘密鍵のサンプル（AWS公式ドキュメントより）
- EC2インスタンス作成時にキーペアを割り当てる必要性
- キーペアなしで起動した場合のセキュリティリスク
- キーペアなしでも接続できる代替手段
- まとめ
1. キーペアとは何か
AWS公式ドキュメント（Amazon EC2ユーザーガイド）では、キーペアを以下のように定義しています。
キーペアにはプライベートキーと公開キーを含んでおり、Amazon EC2 インスタンスへの接続時の身分証明に使用する、セキュリティ認証情報のセットを構成しています。
つまりキーペアとは、EC2インスタンスに接続するための「鍵のセット」 です。
公開鍵と秘密鍵、それぞれの役割
| 公開鍵（パブリックキー） | 秘密鍵（プライベートキー） | |
|---|---|---|
| 保管場所 | AWSがインスタンス内に保管 | 自分のPCに保管（.pemファイル） |
| 役割 | 接続者の照合に使う | 接続時に自分の身元を証明する |
| 例え | 南京錠（誰でも見られるが開けられない） | 南京錠の鍵（自分だけが持つ） |
公式ドキュメントにはこう書かれています。
パブリックキーは Amazon EC2 によりお客様のインスタンス内に保管されます。またプライベートキーはお客様自身が保管します。プライベートキーを所有するすべてのユーザーはキーペアを使用するインスタンスに接続できるため、プライベートキーを安全な場所に保存することが重要です。
LinuxとWindowsで異なる使われ方
OSによってキーペアの使い方が変わります。
Linux インスタンスの場合、プライベートキーを使用すると、インスタンスに安全に SSH 接続できます。Windows インスタンスの場合、管理者パスワードを復号化するにはプライベートキーが必要です。
また、インスタンス起動時に公開鍵がどこに配置されるかも明記されています。
Linux インスタンスではインスタンスを初めて起動する際に、起動時に指定したパブリックキーが Linux インスタンス上で
~/.ssh/authorized_keys内のエントリに配置されます。SSH を使用して Linux インスタンスに接続する際のログインにはパブリックキーに対応するプライベートキーを指定する必要があります。
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
秘密鍵のサンプル
aws ec2 create-key-pair コマンドで生成・保存される .pem ファイルの内容はこのような形式です。
-----BEGIN RSA PRIVATE KEY-----
EXAMPLEKEYKCAQEAy7WZhaDsrA1W3mRlQtvhwyORRX8gnxgDAfRt/gx42kWXsT4r
XE/b5CpSgie/vBoU7jLxx92pNHoFnByP+Dc21eyyz6CvjTmWA0JwfWiW5/akH7iO
...
-----END RSA PRIVATE KEY-----
両者の違いまとめ
| 公開鍵 | 秘密鍵 | |
|---|---|---|
| ヘッダー |
ssh-rsa で始まる |
-----BEGIN RSA PRIVATE KEY----- で始まる |
| 保存場所 | インスタンス内 ~/.ssh/authorized_keys
|
自分のPC（.pem ファイル） |
| 形式 | OpenSSH形式 | PEM形式 |
⚠️ 上記はAWS公式ドキュメントに掲載されているフォーマット例示用のダミー値です。末尾の
EXAMPLEからも分かるとおり、実際には使用できません。
3. EC2インスタンス作成時にキーペアを割り当てる必要性
キーペアは唯一の接続手段
インスタンス起動ウィザードのパラメータ解説ページには、こう書かれています。
キーペアを除き、インスタンス起動ウィザードは各パラメータのデフォルト値を提供します。
他のパラメータにはデフォルト値があるのに、キーペアだけはデフォルト値がない。それだけ重要な設定ということです。
キーペアなしで起動するとどうなる？
公式はズバリこう言っています。
「キーペアなしで進む」オプションを選択した場合（非推奨）、ユーザーが別の方法でログインすることを許可するように設定された AMI を選択した場合でなければ、インスタンスに接続できなくなります。
「非推奨」と明記されています。 キーペアを割り当てないまま起動すると、そのインスタンスへのログイン手段が事実上なくなります。
なぜ後からキーペアを割り当てられないのか
Amazon EC2 ではプライベートキーのコピーが保持されないため、プライベートキーを失った場合、復元することはできません。
キーペアはインスタンス起動時にのみ割り当てられるもので、起動後に追加・変更することは基本的にできません。だからこそ、起動前に必ず設定しておく必要があります。
4. キーペアなしで起動した場合のセキュリティリスク
キーペアがない＝パスワードベースの認証に頼ることになります。これには複数のリスクがあります。
リスク1：パスワード認証への依存
公式ドキュメントは、パスワード認証の危険性をはっきりと述べています。
固定のrootパスワードを公開AMIに使用することはセキュリティリスクであり、すぐに知られてしまう可能性があります。最初のログイン後にユーザーがパスワードを変更することに頼る場合でも、潜在的な悪用の機会を生む小さな窓が開いてしまいます。
キーペアはまさにこのリスクを解消するために存在します。
パブリックAMIから作成されたEC2インスタンスは、SSHでサインインする際にパスワードではなく公開鍵・秘密鍵のペアを使用します。パブリックキーはインスタンスに埋め込まれ、プライベートキーを使ってパスワードなしで安全にサインインします。
リスク2：rootログインの無防備な有効化
EC2 Linuxインスタンスのデフォルト設定はこうなっています。
デフォルトでは、パスワード認証とrootログインは無効化されており、sudoが有効になっています。インスタンスにログインするにはキーペアを使用する必要があります。
キーペアなしにしてパスワード認証を有効にすると、このデフォルトの保護が崩れます。公式はrootへの直接ログインを無効化することをベストプラクティスとして明示しており、
共有AMIを扱う場合のベストプラクティスとして、直接のrootログインを無効化することが推奨されています。
と述べています。
リスク3：中間者攻撃（MitM）のリスク
SSHホストキーの管理を怠ると、中間者攻撃のリスクが生まれます。
既存のSSHホストキーペアを削除することで、誰かがあなたのAMIを使用してインスタンスを起動したときにSSHが新しいユニークなSSHキーペアを生成するよう強制されます。これによりセキュリティが向上し、「中間者攻撃（man-in-the-middle attack）」の可能性が低下します。
リスク4：コンプライアンス違反・AWSによる検出
AWSはキーペアなしのインスタンスをコンプライアンス違反として検出する仕組みを持っています。
ユーザーがキーペアをアタッチせずに誤ってインスタンスを起動することがあります。キーペアはインスタンスの起動時にのみ割り当てることができるため、キーペアなしで起動したインスタンスをすばやく特定し、非対応としてフラグを立てることが重要です。
さらにSSHホストキーペアが残ったAMIを公開してしまった場合、AWSが自ら動きます。
既存のSSHホストキーペアを公開AMIから削除し忘れた場合、AWSの定期的な監査プロセスがあなたとそのAMIを使用しているすべての顧客に対してセキュリティリスクの可能性を通知します。短い猶予期間の後、そのAMIはプライベートとしてマークされます。
リスクまとめ
| リスク | 内容 |
|---|---|
| パスワード認証への依存 | 固定パスワードはすぐに漏洩・悪用される |
| rootアクセスの無防備化 | デフォルトで無効のrootログインが有効になりうる |
| 中間者攻撃（MitM） | SSHホストキーの使い回しで攻撃のリスクが高まる |
| コンプライアンス違反 | AWSがキーペアなしインスタンスを非準拠として検出・通知 |
5. キーペアなしでも接続できる代替手段
キーペアが使えない状況でも、接続する方法はあります。
キーペアの代わりに、インタラクティブなワンクリックのブラウザベースのシェルまたは AWS Command Line Interface (AWS CLI) を使用してインスタンスに接続するために、AWS Systems Manager Session Manager を使用できます。
AWS Systems Manager Session Manager を使えば、キーペアなしでもブラウザやCLIからインスタンスに接続できます。私の研修のように「キーペアを割り当てられない」制約がある環境では、こちらが有効な選択肢です。
6. まとめ
今回はAWS公式ドキュメントのみを参照して、キーペアについて根本から調べてみました。
「なんとなく割り当てていた」キーペアが、実はパスワード認証という古典的な攻撃手法を排除するための重要な仕組みだということが分かりました。また、AWSがデフォルトで「パスワード認証無効・rootログイン無効・キーペアでのみ接続」という安全な設計にしていることも、あらためて理解できました。
研修でスルーしてしまったあの瞬間、もし自分がそのままインスタンスを使い続けていたら……と思うとちょっとヒヤっとしますね😅
最後に、キーペアに関する重要ポイントを振り返ります。
| ポイント | 内容 |
|---|---|
| キーペアとは | 公開鍵＋秘密鍵のセット。EC2接続の認証情報 |
| 公開鍵の保管場所 | AWSがインスタンス内に保管 |
| 秘密鍵の保管場所 | 自分のPCに保管（紛失したらAWSでも復元不可） |
| 割り当てなかった場合 | 接続できなくなる（AWS公式が「非推奨」と明記） |
| 主なリスク | パスワード依存・root無防備化・MitM・コンプライアンス違反 |
| 代替手段 | AWS Systems Manager Session Manager |