【入門編】 AWS IAMにおけるPassRole権限の悪用による権限昇格 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！クラウドインフラの構築やアプリ開発の現場に飛び込んでみたものの、「AWSの権限まわりって、なんだか複雑で難しそう…」と感じていませんか？

今回は、AWSのセキュリティでよく耳にするけれど、少し分かりにくい「PassRole（パスロール）権限の悪用」という権限昇格の手法について、身近な防犯の例えを交えながら、一歩ずつ優しく紐解いていきたいと思います。

難しそうなセキュリティ用語が出てきても大丈夫です。一緒に安心して学びを進めていきましょう！

—

1. 家の鍵で例える「PassRole」の仕組み

AWS（Amazon Web Services）では、サーバーやプログラムがAWS上の他のサービス（例えばデータベースやストレージ）にアクセスするために、「IAMロール（役割）」という専用の身分証（パスポート）を持たせます。

ここで、身の回りの防犯に例えて考えてみましょう。

EC2インスタンス（サーバー）: あなたの家にある「お手伝いロボット」のようなものです。
IAMロール（権限）: ロボットが使える「おつかい用の財布や鍵」です。

通常、ロボットに渡す鍵は「近所のスーパーでの買い出し用（一般権限）」だけに制限しておきたいですよね。万が一、ロボットが不審者に乗っ取られてしまっても、被害を最小限に抑えるためです。

しかし、もしこのロボットに「マスターキー（家全体の金庫を開けられる超強力な鍵）を、別の誰かに手渡す権限」が与えられていたらどうでしょうか？

これが、今回テーマにする「PassRole（ロールを渡す）権限」の正体です。

—

2. 攻撃者はどうやって権限を乗っ取るのか？（悪用のメカニズム）

ペネトレーションテスト（攻撃者の視点で脆弱性を探すテスト）の現場では、攻撃者は次のようなステップでシステムに侵入し、権限を乗っ取ろうと試みます。

1. 初期侵入:
Webアプリケーションの脆弱性などを突いて、クラウド上にある小さなEC2インスタンス（お手伝いロボット）の内部に侵入します。この時点では、攻撃者はまだ「平社員レベル」の弱い権限しか持っていません。
2. PassRole権限の悪用:
ここで攻撃者は、そのEC2インスタンスにiam:PassRoleという権限が付与されていることに気づきます。「あれ？このサーバー、他の高権限なロールを別のリソースにアタッチ（紐付け）できるぞ？」と分かってしまうのです。
3. 権限昇格（Administratorへ）:
攻撃者は、自分が完全にコントロールできる別のリソース（新しく立ち上げた自分用のEC2など）に対し、AWSで最も権限が強い管理者用ロール（例: AdministratorAccess）をPassRoleを使ってひょいと割り当てます。

これで完了です。お手伝いロボットを踏み台にして、攻撃者はAWS環境全体の「マスターキー」を手に入れてしまいました。これが、PassRoleを悪用した権限昇格のカラクリです。

—

3. 実際の危ない設定と対策を見てみよう

開発現場やインフラ構築の初期段階では、「めんどくさいから、とりあえず何でもできるようにしておこう！」と、広すぎる権限（ワイルドカード *）を与えてしまいがちです。

ここでは、実務でそのまま見直せるように、「危ない設定」と「安全な防衛設定」を比較してみましょう。

危ないIAMポリシーの例（やってはいけません！）

以下のJSON設定は、どのロールでも誰にでも渡せてしまう、セキュリティ的には「ガバガバ」な状態です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*" 
            /* リソースが「*」になっているため、管理者ロールを含むすべてのロールを渡せてしまいます！ */
        }
    ]
}

安全なIAMポリシーの例（こう設定しましょう！）

「このサーバーが渡していいのは、特定の安全なロールだけですよ」と、しっかりと範囲を限定（スコープダウン）するのがプロの技です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::123456789012:role/MyApplicationSpecificRole",
            /* 渡せるロールを、このアプリ専用の安全なロールにピンポイントで制限しています */
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                    /* さらに、EC2サービスに対してのみ渡すことを許可します */
                }
            }
        }
    ]
}

このように、Resourceにワイルドカード（*）を使わず、特定のロールのARN（AWSのリソース識別子）を明記すること、そして Condition（条件）を組み合わせることが、現場で使える最強の防御策になります。

—

4. まとめ：一歩ずつ、安全なクラウド環境へ

今回は、AWS IAMにおけるPassRole権限の仕組みと、それが悪用されるリスク、そして具体的な防御策について解説しました。

セキュリティ対策は、一度にすべてを完璧にする必要はありません。「あ、うちのサーバーのポリシー、 Resource: "*" になっていないかな？」と気づき、一つひとつ確認して修正していくことが何よりも大切です。

日々の開発やインフラ運用のなかで、「最小権限の原則（その作業に必要な最小限の権限だけを渡す）」を意識する習慣をつけて、安全で堅牢なクラウド環境を作っていきましょう！

一歩ずつ、確実にスキルアップしていけるよう、これからも一緒に学んでいきましょうね。