こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者や、これからクラウドでの開発に挑戦する一般開発者の皆さん、日々の業務本当にお疲れ様です！
サーバーを構築したり、クラウド上でアプリケーションを動かしたりする時、「セキュリティをしっかりしなきゃいけない」と頭では分かっていても、専門用語ばかりで何から手を付けたらいいか途方に暮れてしまうことってありますよね。
今回は、AWSなどのクラウド環境（EC2やLambdaなど）で絶対に避けて通れない「サービス間通信におけるIAMロールの利用」と、絶対に守り抜かなければならない「メタデータサービス（IMDS）の保護」について、身近な防犯の例えを交えながら、一歩ずつ優しく紐解いていきたいと思います。
難しいセキュリティの壁も、仕組みさえ分かってしまえば怖くありません。一緒に楽しく学んでいきましょう！
—
1. 家の鍵で例える「IAMロール」と「メタデータサービス」の仕組み
まずは、クラウドの世界を「一軒の大きなお家（サーバー）」に例えて考えてみましょう。
皆さんがAWSなどのクラウド上にサーバー（EC2インスタンスなど）を立てたとします。そのサーバーの中では、ウェブサイトを表示するプログラムや、データを保存するプログラムなど、色々な「住人（プロセスやアプリケーション）」が暮らしています。
アプリケーションが他の部屋（AWSサービス）に行くとき
この住人たちが、例えば「データベースから最新のユーザー情報を取ってきてほしい！」と、AWSの他のサービスに頼みごとをしたい時どうするでしょうか？
昔の方法だと、プログラムの中に「合言葉（パスワードや秘密鍵）」を直接書き込んでいました。これって、家の玄関の鍵のコピーを、リビングのテーブルの上に置きっぱなしにしているようなものです。もし泥棒が窓から侵入したら、その鍵を盗まれて家中を荒らされてしまいますよね。危険極まりありません。
そこで登場するのが「IAMロール」です。
これは、プログラムに直接合言葉を持たせるのではなく、「このサーバー（お家）に住んでいる公式なプログラムなら、一時的にこの特別なパスポート（権限）を持って行っていいですよ」と、クラウドの管理人さん（AWS）が自動でお墨付きを与える仕組みです。これなら、鍵を持ち歩く必要がなくなりますよね！
でも、その「パスポート」を狙う悪い奴らがいるんです
ここで問題が発生します。
サーバーの中で動いているプログラムの中に、もし外部から侵入されたり、悪意あるコードが混ざっていたりしたらどうなるでしょうか？
その悪い奴らは、サーバーの裏口からこっそり管理人室（特殊なURL：http://169.254.169.254/）にアクセスして、「このサーバーのIAMロールのパスポート（一時的な認証情報）をちょうだい！」と要求してしまうのです。
これが、セキュリティの世界でよく耳にするSSRF（サーバー側リクエスト偽造）という攻撃の恐ろしい手口です。玄関の鍵は閉めたつもりでも、家の中の住人になりすまして管理人室から合言葉を盗み出されてしまうわけですね。
—
2. 泥棒の侵入を防ぐ最強の防犯ドア「IMDSv2」とは？
この「管理人室からのパスポート窃盗（SSRF経由の攻撃）」を防ぐためにAWSが用意してくれた最強の防犯システム、それがIMDSv2（Instance Metadata Service Version 2）です。
古いバージョンの「IMDSv1」は、管理人室の窓が常に空いているようなもので、外から「パスポートちょうだい」と言われたら、確認もせずにポイっと渡してしまっていました。
しかし、新しい「IMDSv2」では、パスポートを貰うために「秘密の合言葉（セッショントークン）」を最初に発行してもらう手続きが必要になりました。
普通のブラウザ経由のちょっとしたイタズラ（単純なSSRF攻撃）では、この事前の手続きやヘッダーのやり取りが難しいため、悪意ある攻撃者が簡単にパスポートを盗み出せなくなるのです。つまり、管理人室の前に頑丈な「暗証番号付きの二重扉」を設置したようなイメージですね。
実務においては、このIMDSv2を「強制（Required）」に設定することが、サーバー要塞化の極めて重要な第一歩になります。
—
3. 実践！IMDSv2を強制する設定とコード例
それでは、実際にインフラを構築する現場で、どのようにIMDSv2を有効化するのかを見ていきましょう。難しく考えず、「こういう設定をするんだな」と雰囲気を掴んでもらえれば大丈夫です！
① Terraformを使ったインフラコードでの設定例
インフラをコードで管理するツール（Terraform）を使う場合、EC2インスタンスの設定（aws_instance）に metadata_options というブロックを追加し、IMDSv2を必須化します。
# AWSのEC2インスタンスを安全に構築するための設定例
resource "aws_instance" "secure_web_server" {
ami = "ami-0c55b159cbfafe1f0" # サンプル用のOSイメージID
instance_type = "t3.micro"
# ★ここがメタデータサービス（IMDS）のセキュリティ設定です！
metadata_options {
http_endpoint = "enabled" # メタデータサービス自体は有効にする
http_tokens = "required"# ★超重要：IMDSv2のトークンを必須化（v1を禁止）
http_put_response_hop_limit = 1 # ルーター経由での不正アクセスを防ぐためホップ数を制限
}
tags = {
Name = "SecureWebServer"
}
}② アプリケーション側（プログラム）から安全にメタデータを取得する例
もし、どうしてもプログラム側から自分のサーバーのメタデータ（IPアドレスなど）を取得したい場合は、IMDSv2の作法に則ってコードを書く必要があります。Pythonを例に見てみましょう。
import urllib.request
import urllib.error
# 1. まず最初に、管理人室から「秘密のトークン（セッショントークン）」をPUTリクエストでもらいます
token_url = "http://169.254.169.254/latest/api/token"
headers = {
"X-aws-ec2-metadata-token-ttl-seconds": "21600" # トークンの有効期限（秒）
}
try:
# トークン取得用のリクエストを作成（PUTメソッドを指定）
req = urllib.request.Request(token_url, headers=headers, method="PUT")
with urllib.request.urlopen(req, timeout=2) as response:
token = response.read().decode("utf-8")
print("無事にセッショントークンを取得できました！")
# 2. 取得したトークンをヘッダーに含めて、安全にメタデータ（このインスタンスのID）を要求します
meta_headers = {
"X-aws-ec2-metadata-token": token
}
meta_url = "http://169.254.169.254/latest/meta-data/instance-id"
meta_req = urllib.request.Request(meta_url, headers=meta_headers)
with urllib.request.urlopen(meta_req, timeout=2) as meta_response:
instance_id = meta_response.read().decode("utf-8")
print(f"インスタンスID: {instance_id}")
except urllib.error.URLError as e:
print(f"メタデータの取得に失敗しました: {e}")このように、IMDSv2では「ただURLを叩くだけ」ではデータを返してくれません。一手間増えますが、この一手間こそがサーバーをサイバー攻撃から守る頑丈な盾となるのです。
—
4. まとめ：安全なクラウドライフを送るために
今回は、サービス間通信を安全に行う「IAMロール」の仕組みと、それを裏側で狙う脅威から守る「IMDSv2の強制」について解説しました。
- IAMロールを使えば、プログラムにパスワードを直接書かずに安全に権限を渡せる。
- しかし、サーバーがSSRFなどの攻撃を受けると、メタデータサービス（IMDS）から認証情報を盗まれる危険がある。
- だからこそ、IMDSv2を強制（Required）にして、合言葉（トークン）のやり取りを義務付けることが最高の防衛策になる。
セキュリティの対策は、最初は少し面倒に感じるかもしれません。「なんでわざわざこんな手順を踏まなきゃいけないんだろう？」と思うこともあるはずです。でも、それはすべて大切なお家（システムやデータ）と、そこにいるユーザーの笑顔を守るための大切な防犯ロックです。
一歩ずつ、確実な設定を積み重ねて、信頼されるエンジニアへの階段を一緒に登っていきましょう！それではまた次回のブログでお会いしましょう！
コメント