【入門編】 IMDSv2(Instance Metadata Service Version 2)の強制とSSRF対策 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやクラウドのセキュリティを担当していると、「サーバーの鍵をしっかりかけよう！」なんて話をよく耳にしますよね。

でも、クラウドの世界の「鍵のかけ方」って、オフィスのドアの鍵とはちょっと勝手が違って、最初は戸惑うことも多いと思います。特にAWSなどのクラウド環境で必ず押さえておきたいのが、今回お話しする「IMDSv2の強制とSSRF対策」です。

なんだか呪文みたいな名前が出てきて身構えてしまうかもしれませんが、大丈夫です！今回は、身近な「合鍵」と「泥棒の侵入経路」にたとえながら、新人のエンジニアや開発者の方にもすんなり理解できるように、一歩ずつ優しく紐解いていきますね。

—

1. クラウドの「管理人室」で何が起きているのか？

まず、AWSなどのクラウド環境で動いているサーバー（EC2インスタンスなど）を想像してみてください。
このサーバーの中では、アプリケーションが動いていますが、ときどき「今動いているサーバーのIPアドレスは何だっけ？」とか「私に割り当てられている権限（IAMロール）の期限はいつまでだっけ？」と、自分自身に関する情報を知りたくなることがあります。

そんなときのために、AWSには「インスタンスメタデータサービス（IMDS）」という、いわばサーバー専用の「管理人室」が用意されています。この管理人室に行けば、サーバーの秘密情報や設定が何でも手に入ります。

非常に便利な仕組みなのですが、ここに「泥棒が忍び込む隙」が隠されているんです。それが、セキュリティ界隈で恐れられているSSRF（サーバーサイドリクエストフォージェリ）という攻撃です。

身近なたとえ：マンションの管理人室と悪質な訪問者

想像してみてください。あなたが住んでいるマンションの1階に「管理人室」があり、そこには住民の合鍵や重要書類が保管されています。

本来なら、管理人室に入れるのは信頼された管理人だけです。しかし、もし「外から来た怪しい訪問者（攻撃者）」が、あなたの部屋のインターホンを悪用して、管理人室の中身を勝手に覗き見ることができたら……？ゾッとしますよね。

SSRFは、まさにこれと同じことをウェブアプリの世界でやります。
外部からユーザーが入力するURLなどを処理するプログラムの不備を突いて、サーバー自身に「ねえ、管理人室に行って、私の代わりにそのデータを取ってきてよ！」と命令させ、本来は見えてはいけない秘密の情報を盗み出すのがSSRF攻撃のメカニズムです。

—

2. なぜ「IMDSv1」は危ないのか？（昔の鍵のままだから）

これまで主流だった「IMDSv1」という古い仕組みには、大きな弱点がありました。それは、「合鍵を見せるだけで、誰でも管理人室に入れた」ということです。

IMDSv1では、サーバーの中のアプリが管理人室のURL（http://169.254.169.254/latest/meta-data/）にアクセスさえすれば、一発で機密情報が手に入ってしまいました。
もし、あなたの作ったウェブアプリにSSRFの脆弱性（うっかり外部からのリクエストをそのまま受け入れてしまう不備）があると、攻撃者は次のようなシンプルな手順でサーバーの権限を乗っ取ってしまいます。

1. 攻撃者が、あなたのアプリの脆弱性を突いて、サーバー自身に http://169.254.169.254/... へアクセスさせる。
2. アプリが言われるがままにアクセスし、サーバーの管理者権限のトークン（パスワードのようなもの）をホイホイと取得してしまう。
3. 攻撃者はそのトークンを手に入れて、AWSリソースを自由に操る（クラウドが乗っ取られる）。

まるで、誰でも使える共通の合鍵が玄関のフックにぶら下がっているような状態だったわけです。これは危ないですよね。

—

3. 救世主「IMDSv2」登場！ セキュリティの「合言葉」を導入しよう

そこでAWSが用意したのが、より安全な新バージョンである「IMDSv2」です。

IMDSv2では、管理人室に入るためのルールが厳しくなりました。単にURLにアクセスするだけでは中に入れてもらえず、「特定の合言葉（セッショントークン）」を最初に発行してもらい、その合言葉を提示しないと情報を教えてくれない仕組みに変わりました。

強化されたポイント：PUTリクエストとカスタムヘッダー

IMDSv2では、情報を引き出すために以下の2つのステップが必要になります。

1. まず、管理人室に対して「合言葉（トークン）をください」という特別な願い出（PUTリクエスト）を送信する。
2. 管理人室から受け取った合言葉を、実際のデータを取りに行くときの「カスタムヘッダー」（例: X-aws-ec2-metadata-token）に含めて送信する。

ここで重要なのが、「通常のSSRF攻撃（よくある脆弱性）では、この『PUTリクエスト』をうまく作って送るのが難しい」という点です。多くのSSRF脆弱性は、単純な GET リクエスト（ただURLを開くだけ）しか引き起こせないため、IMDSv2を導入するだけで、大半のSSRF攻撃をシャットアウトできるようになります。

つまり、家に入るために「暗号化されたワンタイムパスワードの提示」を義務付けたようなものです。泥棒は簡単に中に入ることができなくなります。

—

4. 実践！IMDSv2を強制し、古いIMDSv1を無効化する手順

「じゃあ、うちのサーバーでも今すぐIMDSv2を必須にしよう！」となったときに、実務でどう設定すればいいのかを見ていきましょう。

AWS CLI（コマンドラインツール）やTerraformを使って、既存のサーバー（EC2インスタンス）の設定をアップデートします。

方法A: AWS CLIで設定を変更する場合

現在動いているインスタンスに対して、IMDSv2を必須（Required）にし、古いIMDSv1を禁止するコマンドは以下の通りです。

# AWS CLIを使用して、指定したインスタンスのメタデータサービスの設定を更新します
aws ec2 modify-instance-metadata-options \
    --instance-id i-0123456789abcdef0 \
    --http-tokens required \
    --http-endpoint enabled \
    --cli-input-json file://metadata-options.json

設定ファイル（例: metadata-options.json）を使う場合は、以下のように記述して適用します。

{
  "InstanceId": "i-0123456789abcdef0",
  "HttpEndpoint": "enabled",
  "HttpTokens": "required", 
  "HttpProtocolIpv6": "disabled"
}
  • HttpTokens: required の部分が、IMDSv2のトークンを必須化する重要な設定です。ここを required にすることで、IMDSv1へのアクセスが完全に遮断されます。

方法B: Terraform（IaC）で最初から安全に構築する場合

これから新しくインフラを作るなら、コードでしっかりと定義しておきましょう。Terraformを使う場合は、aws_instance リソースの中に metadata_options ブロックを記述します。

resource "aws_instance "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  # ここでメタデータサービスのセキュリティを強化します
  metadata_options {
    http_endpoint               = "enabled"  # メタデータサービス自体は有効にする
    http_tokens                 = "required" # ★IMDSv2のトークンを必須化（v1を禁止）
    http_put_response_hop_limit = 1          # ルーター等を経由した不正なアクセス（ホップ数超過）を制限
  }

  tags = {
    Name = "SecureWebServer"
  }
}
  • http_put_response_hop_limit = 1 も非常に強力な設定です。これは、パケットが通過できるルーターの数（ホップ数）を「1」に制限することで、万が一コンテナや複雑なネットワーク構成をとっていても、外部からの不正な中継をブロックする追加の防護壁になります。

—

5. 移行時の注意点と現場のリアルな落とし穴

「よし、じゃあ全部のサーバーでIMDSv2を強制しよう！」と意気込むのは素晴らしいことですが、現場のインフラ担当としては、少しだけ注意すべきポイントがあります。

古いアプリケーションやSDKの確認

もし社内で使っている古いバージョンのAWS SDK（プログラミング言語用のライブラリ）や、外部から持ち込んだレガシーなアプリケーションが動いている場合、それらがまだIMDSv1にしか対応していないことがあります。

IMDSv2を「必須（required）」にした瞬間に、そうした古いアプリが「あれ？管理人室に入れないぞ！」とエラーを起こして動かなくなってしまうトラブル（いわゆる「自爆テロ」）が起きることがあります。

【現場でのアドバイス】
いきなり本番環境でIMDSv2を必須にするのではなく、以下のステップを踏むのが安全です。
1. まず、ログやAWS CloudWatch等を確認し、IMDSv1が使われていないか調査する。
2. アプリケーションやSDKのバージョンを最新にアップデートする。
3. ステージング環境（テスト環境）で http_tokens = required を適用し、アプリが正常に動作するかテストする。
4. 問題ないことを確認してから、本番環境に適用する。

—

まとめ：一歩ずつ、確実なセキュリティ対策を

今回は、サーバーOSの要塞化において非常に重要なテーマである「IMDSv2の強制とSSRF対策」について解説しました。

  • IMDSv1 は、合言葉なしで誰でもアクセスできる昔の管理人室のようなもの（危険）。
  • IMDSv2 は、合言葉（トークン）の提示を義務付けてSSRFなどの不正な侵入を防ぐ現代のセキュリティ（安全）。
  • 設定変更は http_tokens = required を指定するだけ。ただし、事前のアプリ側の対応確認を忘れずに！

セキュリティの世界は覚えることが多くて大変に見えるかもしれませんが、こうした「仕組みの弱点を知り、正しい鍵に付け替えていく」ことの積み重ねが、強固なインフラストラクチャを作ります。

一歩ずつ、確実に安全な環境を作っていきましょう！それではまた次の記事でお会いしましょう。

スポンサーリンク

コメント

タイトルとURLをコピーしました