こんにちは！クラウドのインフラ構築やサーバー管理、毎日お疲れ様です。
「とりあえず動く環境を作ろう！」と、AWSなどのクラウド環境で仮想サーバー（EC2など）を立ち上げたとき、こんな設定にしたことはありませんか？
「どのAWSのリソースにもアクセスできるように、とりあえず最強の権限（AdministratorAccessのような何でもできる権限）をこのサーバーに付けちゃえ！」
……実はこれ、セキュリティの現場では「泥棒に自宅の合鍵を全種類、しかも玄関の鍵穴に挿しっぱなしにして出かけるようなもの」なんです。
今回は、クラウド環境でサーバーを守るための超重要テーマである「IAMロールの最小権限付与」と「メタデータ保護」について、難しい専門用語を噛み砕きながら、一歩ずつ一緒に学んでいきましょう！
—
1. 家の鍵で例える「IAMロールの最小権限」と「SSRFの脅威」
まずは、クラウドの世界で何が起きているのか、私たちの身近な「家と泥棒」に例えて考えてみますね。
あなたが大きなマンションの一室（クラウド上の仮想サーバー）に住んでいるとします。その部屋には、リビングや寝室だけでなく、大切なへそくり（機密データ）をしまっている金庫室や、管理人室（クラウド全体の管理機能）につながる秘密の通用口がありました。
通常、あなたがお出かけするときに持ち歩く鍵は、自分の部屋の玄関の鍵だけで十分ですよね。それなのに、「鍵を付け替えるのが面倒だから」という理由で、マンション全体のマスターキー（すべての部屋が開く最強の鍵）をポケットに入れて外出したとします。
もし、そのポケットからうっかり鍵を落としてしまったり、スリに遭ったりしたらどうなるでしょうか？ あなたの部屋だけでなく、マンション全体の部屋に泥棒が入り放題になってしまいますよね。
クラウドにおける「IAMロール」は、まさにサーバーが持ち歩く「鍵」のことです。そして、「最小権限の原則」とは、「そのサーバーが仕事をするために絶対必要な最小限の部屋の鍵だけを持たせる」という防犯の基本ルールになります。
攻撃者はどうやってその鍵を狙うのか？（SSRFの恐怖）
ここで厄介なのが、「SSRF（サーバーサイド・リクエスト・フォージェリ）」という攻撃手法です。
例えば、あなたの作ったWebアプリに「外部の画像を読み込んで表示する機能」があったとします。普通は https://example.com/image.jpg などの安全なURLを指定しますが、悪意のある攻撃者がそこに次のような巧妙なURLをこっそり入力したらどうなるでしょうか？
http://169.254.169.254/latest/meta-data/iam/security-credentials/
「ん？なんだこの変な数字の羅列は？」と思いましたよね。
実はこれ、クラウドの世界（AWSなど）でサーバー自身が「自分は今、どんな権限を持っているのかな？」と確認するための「インスタンスメタデータサービス（IMDS）」という特別な住所（IPアドレス）なんです。
もし、あなたのWebアプリに脆弱性（穴）があって、攻撃者のこのズルい命令をそのまま実行してしまうと、サーバー自身が持つ「鍵（IAMロールの一時的な認証情報）」がペロッと攻撃者に盗み出されてしまいます。
もし、そのサーバーに「何でもできる最強の鍵（マスターキー）」を持たせていたらどうでしょう？ 攻撃者はその盗んだ鍵を使って、あなたのクラウド環境にあるすべてのデータを勝手にダウンロードしたり、消去したりできてしまうのです。これが、最小限の権限が求められる本当の理由です。
—
2. 攻撃を防ぐための第一歩：IAMポリシーを「最小限」にする
それでは、実際にどうやって「最小限の鍵」を作ればいいのかを見ていきましょう。
例えば、「S3というオンラインストレージにある特定のフォルダ（画像保存用）にだけ、ファイルを保存したい」というサーバーがあったとします。
このとき、以下のように書いてはいけません。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}*↑絶対にやってはいけない例：すべての操作（*）とすべてのリソース（*）を許可する危険なポリシー*
これでは、先ほどのマスターキーを持たせているのと一緒です。正しくは、次のようにアクセスできる場所とできることをガチガチに絞り込みます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOnlySpecificS3Upload",
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-company-image-bucket/uploads/*"
}
]
}【この設定のポイント】
Action: 許可する操作を「ファイルを置くこと（s3:PutObject）」だけに限定しています（ファイルを消したり読んだりする権限は与えません）。Resource: アクセスできる場所をmy-company-image-bucketという特定の箱の中にあるuploads/というフォルダ以下だけに限定しています。
万が一、アプリの脆弱性をつかれてSSRF攻撃を受け、この鍵が盗まれたとしても、被害はこの「特定のフォルダへの書き込み」だけに最小限に食い止めることができます。これが最小限の権限設計です。
—
3. メタデータへのアクセスを強固に守る（IMDSv2への移行）
IAMロールの権限を絞り込むと同時に、もう一つ絶対にやっておかなければならない大切な対策があります。それが、先ほど登場したメタデータサービス（IMDS）のセキュリティ強化です。
実は、昔の仕組み（IMDSv1）では、先ほどのような簡単なURLアクセスだけで、簡単に鍵が盗めてしまう弱点がありました。そこで現在では、「IMDSv2」という、より安全な仕組みが標準になっています。
IMDSv2では、メタデータを取得する前に「私は本当にこのサーバーの内部にいる正規のプログラムですよ」と証明するための「トークン」という合い言葉を発行してもらう必要があります。
先ほどのSSRF攻撃のように、外からブラウザ経由で適当なURLを叩くだけでは、このトークンが手に入らないため、鍵を盗み出すことができなくなるのです。
AWS CLIでの強制設定（IMDSv2の義務化）
新規にサーバーを作る際や既存のサーバーを保護する際は、古い「IMDSv1」を禁止し、安全な「IMDSv2」だけを許可するように設定しましょう。
例えば、AWSを操作するコマンドライン（AWS CLI）では、次のようなコマンドで設定を強制できます。
# インスタンスのメタデータサービスの設定を更新し、IMDSv2を必須（Required）にする
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required \
--http-endpoint enabled【パラメータの解説】
--http-tokens required: 「トークンを使った厳格な認証（IMDSv2）を必ず必須にする」という設定です。これが有効になると、古い方法でのアクセスはすべて遮断されます。--http-endpoint enabled: メタデータサービス自体の有効・無効を切り替えます（基本的には有効にします）。
この設定をしておくだけで、万が一アプリにSSRFの穴が見つかったとしても、攻撃者がメタデータにたどり着くハードルを劇的に高く（ほぼ不可能に）跳ね上げることができます。
—
まとめ：一歩ずつ、安全なインフラを作っていきましょう！
今回は、クラウドセキュリティの基本中の基本である「IAMロールの最小権限」と「メタデータ保護」について紐解いてみました。
1. すべての権限（マスターキー）をサーバーに持たせない！
2. 仕事に必要な最小限の操作と場所だけを許可する（IAMポリシーの絞り込み）。
3. メタデータへのアクセスにはIMDSv2を必ず使用し、外からの不正な読み取りを防ぐ。
セキュリティの対策は、最初はいろいろな設定があって難しく感じるかもしれませんが、こうした「一つひとつの鍵の管理」を丁寧に行うことで、あなたの作るシステムは圧倒的に堅牢（要塞化）になっていきます。
焦らず、一歩ずつ、安全なインフラストラクチャ作りを楽しんでいきましょう！応援しています！
コメント