EC2セキュリティ — IMDSv2を知らないと事故る

おはようございます。今日が最後の個別テーマ——EC2 セキュリティです。

EC2 は AWS の最初のサービスで、古いからこそ「もう安全でしょ」と思われがちです。ですが実際には、新しいセキュリティ機能が継続的に追加されています。そして、多くの人がその新機能を知りません。その結果、セキュリティインシデントが発生します。

IMDSv2 の非採用による SSRF 攻撃、Nitro Enclaves の存在を知らない、EC2 Instance Connect の認知度不足。これらが、実務での事故につながります。

IMDS — 「メタデータアクセスの進化」

EC2 インスタンスが起動する際、IAM ロールの認証情報（秘密鍵、一時トークン）が必要です。これらは IMDS（Instance Metadata Service）という、インスタンス内で実行されるサービスに保存されます。

インスタンスは 169.254.169.254 という特殊な IP アドレスに HTTP リクエストを送ることで、このメタデータサービスにアクセスします。例えば curl http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role でアクセスすると、IAM ロールの一時認証情報（access key、secret key、session token）が返されます。すべての EC2 インスタンスはこの仕組みで IAM ロールを活用しています。

IMDSv1 の脆弱性と Capital One 事件

従来の IMDS（IMDSv1）には認証がなく、インスタンス上の誰でもメタデータにアクセスできました。これが SSRF 脆弱性（Server-Side Request Forgery）と組み合わさると、極めて危険になります。2019 年の Capital One のセキュリティ侵害事件がその典型例です。

SSRF 脆弱性を持つアプリケーションに対して、攻撃者が http://169.254.169.254/latest/meta-data/… へのリクエストを送らせました。EC2 インスタンスが代理で IMDS にアクセスし、IAM ロール認証情報を返却。攻撃者がそれを盗み、100 万件以上の個人情報を窃取しました。

この事件をきっかけに、AWS は IMDSv2 を導入しました。

IMDSv2 — 「SSRF 対策」

IMDSv2 では——認証が追加されました。

具体的には——トークンベース認証です。

プロセスはこうなります。

インスタンスがまずIMDSに対してPUTリクエストでトークンをリクエストし、有効期限を900秒と指定します。IMDSがそのトークンを返します。インスタンスがそのトークンを含めてGETリクエストでメタデータを取得します。IMDSがトークンを検証してからメタデータを返すという流れです。

では、SSRF 脆弱性があっても——攻撃者はどうするか？

攻撃者がSSRF脆弱性を使ってGETリクエストでメタデータにアクセスしようとします。しかしIMDSはトークンがないため401 Unauthorizedを返します。攻撃者はトークンが必要なことに気づきますが、トークン取得にはPUTリクエストが必要なのに対してSSRF脆弱性はGETの問題であるため、トークンを取得できません。こうしてSSRF攻撃が防がれるわけです。

IMDSv2 = トークンベース認証。SSRF 対策の必須要件。

IMDSv2 への移行

では、実務的には——何をするべきか？

1. すべての EC2 インスタンスで IMDSv2 を有効化
2. アプリケーションコード を更新（IMDSv2 トークンを取得するロジック）
3. IMDSv1 を無効化（セキュリティグループで、IMDS アクセスを制限）

ただし——注意があります。

古いアプリケーション（IMDSv1 只対応）は——IMDSv2 に対応するまで——動かなくなる。

だからね——本番環境での IMDSv1 廃止は——計画的にね、実施する必要があります。

Nitro Enclaves — 「金庫の中のコンピューター」

では、次のテーマ。

Nitro Enclaves です。

これはね——説明が難しいんですけど——要は——

EC2 インスタンスの中に、さらに隔離された『金庫』を作る。

——こんなイメージです。

例えば——

あなたが暗号化キーを管理したいとします。

その暗号化キーは——絶対に——EC2 インスタンスのメインプロセスから見えてはいけない。

では、どうする？

Nitro Enclave を使って——暗号化キーを「金庫」に入れる。

メインアプリケーションが——「この データを暗号化してくれ」と——Nitro Enclave にリクエストを送る。

Nitro Enclave が——内部で秘密鍵を使って——暗号化を実行する。

暗号化されたデータを返す。

その過程で——メインアプリケーションは——秘密鍵を見ない。

Nitro Enclave の内部は——メインアプリケーションからアクセス不可。

技術的詳細

背後では——AWS の Nitro System（ハードウェアレベルのセキュリティ）が——Nitro Enclave の隔離を保証してます。

Nitro Enclave は——

専用の CPU コアで実行 メインインスタンスのメモリに アクセス不可 ネットワーク接続なし（メインインスタンス経由の通信のみ） 通信は暗号化される

つまり——金庫の中での処理は——完全に隔離されてるわけです。

ユースケース

では、何に使うのか？

暗号化キー管理：秘密鍵を Enclave に隠す 機密データ処理：医療記録、金融データなど——メインアプリから隔離 HSM（Hardware Security Module）代わり：金庫の鍵の鍵、みたいな

ただし——実装が複雑です。

だからね——本当に機密性が高い用途に限定される傾向があります。

Nitro Enclaves = ハードウェアレベルの隔離。最強のセキュリティ。複雑。

EC2 Instance Connect — 「SSH キーなしでアクセス」

では、次のテーマ。

EC2 Instance Connect です。

あ、これは——Systems Manager の Session Manager と似てるんですけど——EC2 専用です。

従来、EC2 インスタンスに接続するには——SSH キーが必要でした。

でも——EC2 Instance Connect を使うと——

ブラウザから、一時的なキーペアを生成して、接続できる。

プロセスは——

AWSコンソールでConnectボタンをクリックします。そうするとAWSが一時的な公開鍵をインスタンスに追加し、有効期限は60秒です。ブラウザからその公開鍵を使ってWebSocket経由で通信し、ブラウザにSSHターミナルが表示されます。60秒後に公開鍵が自動削除されるという流れです。

メリット

SSH キーが不要：公開鍵基盤（PKI）の複雑さが消える。

CloudTrail に記録：誰がいつアクセスしたか——全部ログに残る。

一時的：60 秒で自動削除。長時間接続が不可能（セキュリティ）。

EC2 Instance Connect = SSH キー不要、一時的、監査可能。Session Manager の兄弟。

Image Builder — 「CIS ハードニング AMI の自動生成」

では、最後のテーマ。

EC2 Image Builder です。

これはね——AMI（Amazon Machine Image）を安全に生成するツールなんです。

例えば——

あなたが Web サーバー用の AMI を作りたいとします。

従来のやり方なら——

1. EC2 インスタンスを起動
2. SSH で接続
3. パッケージを インストール
4. 設定を編集
5. セキュリティパッチを適用
6. 脆弱性をテスト
7. スナップショットを取って AMI に
8. ドキュメント化

——すごい手作業ですよね。

Image Builder のプロセス

では、Image Builder を使うと——

YAML形式でレシピを定義し、名前をWeb-Server-Imageとして、コンポーネントにはOSの更新、Apacheのインストール、PHPのインストール、CISベンチマークの適用、セキュリティハードニング、脆弱性スキャンを記載します。テストには接続確認とセキュリティ準拠確認を含め、出力としてAMIとDockerイメージを指定します。このようなレシピを定義して実行すればImage Builderが全部やってくれるわけです。

自動的に——

1. EC2 インスタンスを起動
2. コンポーネント（パッケージインストール、設定）を実行
3. セキュリティテストを実行
4. 脆弱性スキャンを実行
5. 成功したら AMI を生成

——これが全部、自動です。

CIS Benchmarks との連携

ここが重要なポイント。

CIS Benchmarks ってね——「セキュリティベストプラクティス集」です。

「Linux は、こういう設定にしましょう」「Windows は、こういう設定にしましょう」——みたいな。

Image Builder は——CIS Benchmarks に対応したコンポーネント を使って——

自動的に「CIS ハードニング済みの AMI」を生成できるわけです。

つまり——

Image BuilderでAMIを生成し、CISベンチマークに準拠した設定が自動的に適用されて、脆弱性スキャンが実行されます。その結果、安全なAMIが完成するという流れが、完全に自動化されます。

Image Builder = AMI 生成の自動化＆標準化。CIS 準拠を保証。

Pipeline による継続的な更新

ここが本当に面白いところ。

Image Builder は——パイプラインという仕組みで——

「毎月、新しい OS パッチが出たら、自動的に新しい AMI を生成する」

——こんなことができるんです。

例えば——

毎月1日の深夜2時に、AWSがOSパッチをリリースします。すると自動的にImage Builderパイプラインが実行されて、新しいAMIが生成されます。その後テストが実行され、成功したら本番用AMIに昇格するという流れです。

人間は何もしなくていい。毎月、パッチ済みの AMI が自動で出てくる。

Image Builder Pipeline = AMI の自動更新。CIS 準拠を継続的に保証。

実務的なセキュリティチェックリスト

では、まとめます。

EC2 セキュリティを実装するなら——

1. IMDSv2 を必須化：すべてのインスタンスで有効化。IMDSv1 を無効化。
2. EC2 Instance Connect を使用：SSH キー管理から解放される。
3. Nitro Enclaves を検討：機密度が高い場合。
4. Image Builder で AMI を生成：手作業から自動化へ。CIS 準拠を保証。
5. パイプラインで継続更新：毎月、セキュリティを更新。

これらが——全部統合されるとき——

EC2 も、モダンセキュリティを得るわけです。

IMDSv2 が、SSRF 攻撃を防ぎ。 Instance Connect が、キー管理から解放し。 Nitro Enclaves が、ハードウェアレベルの隔離をし。 Image Builder が、セキュリティを自動化し。

それが——完全な EC2 セキュリティなわけです。

最終的なメッセージ

では、今日で——AWS SCS-C03 の主要テーマが全部終わりました。

CloudWatch から始まって——EC2 まで。

何が分かったか？

セキュリティは、インフラのあらゆるレイヤーに組み込まれている。

IAM から始まり——ネットワークから——ストレージから——コンテナから——サーバーレスから——最後に EC2 まで。

どこをとっても——セキュリティの「仕掛け」が入ってるんです。

そしてね——それらを理解したとき——初めて「安心な AWS 運用」が成り立つんです。

「どうせ AWS が守ってくれるでしょ」——この考えは——間違い。

AWS はツールを提供してるだけ。

それをどう使うか——は、あなた次第なんです。

では——皆さんのセキュアな AWS ライフを祈っています。

最後に——一言。

セキュリティに「完璧」はない。常に改善し続ける。それが、プロの運用者の心構えです。

——では、終わります。ご清聴ありがとうございました。