【テクニカル・上級編】 IAMロールの過剰な権限付与と権限昇格のメカニズム – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

クラウドの「神」を殺す：IAM権限昇格という終わりのないチェスゲーム

クラウドアーキテクチャにおいて、IAM（Identity and Access Management）は単なるアクセス制御リストではない。それは、インフラそのものを支配する「OSのカーネル」に相当する。多くのエンジニアが「必要な権限」を付与しているつもりが、実態は「攻撃者に鍵を渡している」状態であることに気づいていない。

今日は、攻撃者がどのようにIAMの隙間を縫い、ワイルドカードの迷宮を抜け、最終的に特権を奪取するのか。その「泥臭い現実」と、我々が実装すべき防衛の深層について解説する。

—

1. ワイルドカードという「脆弱性の招待状」

IAMポリシーにおけるワイルドカード（*）の乱用は、サイバー犯罪者にとって最も美しいバックドアだ。

例えば、ある開発者が利便性のために付与した以下のようなポリシーを考えてみてほしい。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

このポリシーは一見、IAM操作のための特権を与えているだけに見えるが、攻撃者はここからiam:CreateAccessKeyを呼び出し、新しいアクセスキーを生成することで、環境の永続性を確保する。さらに深刻なのは、ワイルドカードが「サービス単位」ではなく「アクション単位」で許可されている場合だ。

攻撃者は、特定のサービス（例えばS3）だけでなく、権限昇格に直結するiam:PutRolePolicyやiam:CreatePolicyVersionを狙い撃ちにする。これらは防御側が「まさか開発者がここを触るはずがない」と高を括っているポイントであり、ここが突破口となる。

—

2. PassRole：権限昇格の「トロイの木馬」

ペネトレーションテストにおいて、最も頻繁に利用されるのが iam:PassRole を悪用した権限昇格だ。

iam:PassRole は、あるIAMロールを特定のサービス（EC2やLambdaなど）に「紐付ける」ことを許可する権限である。もし攻撃者が、管理者権限を持つロールを別のリソースに紐付け可能であれば、ゲームはそこで終了する。

攻撃シナリオ：

1. 初期侵入: 低権限のEC2インスタンスへ侵入。
2. 権限確認: aws iam simulate-principal-policy 等を使用し、自身が iam:PassRole を持っているか確認。
3. 昇格: 自身のリソースに「管理者ロール」を紐付け（aws ec2 associate-iam-instance-profile）、そのインスタンスから管理者として再認証。

これを防ぐには、iam:PassRole に厳格な条件（iam:PassedToService や iam:AssociatedResourceArn）を設定する必要がある。

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/Target-Limited-Role",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ec2.amazonaws.com"
    }
  }
}

このように、「どのロールを、どのサービスに渡すか」を明示的に制限するガードレイルが、攻撃者の足元をすくう。

—

3. 防御の自動化：Access Analyzerを「武器」に変える

インシデントハンドリングの現場では、静的なポリシー分析だけでは限界がある。AWS IAM Access Analyzerは、単なる監査ツールではない。これは攻撃者のロジックを逆手に取るための「シグナル分析装置」だ。

実務的な監査の自動化ポイント

1. 外部エンティティの特定: 組織外からのアクセスを許可しているポリシーを洗い出し、意図しないパブリック公開を即座にブロックする。
2. 未使用権限の剥奪: Last Accessed 情報を利用し、90日間使用されていないアクションを自動的に削除するパイプラインを構築する。

プロアクティブな防御を目指すなら、CI/CDパイプラインに cfn-lint や checkov を組み込み、ポリシーのデプロイ前に「ワイルドカードが存在しないか」を静的解析で叩き落とす仕組みが不可欠だ。

—

4. セキュリティアーキテクトへの提言：次世代の防御へ

耐量子暗号（PQC）への移行や、生成AIを利用した自動アタックサーフェス管理が叫ばれる中、IAMの重要性は増す一方だ。特に、AIエージェントがクラウドAPIを叩く時代において、IAMは「人間と機械の境界」を制御する唯一の盾となる。

以下の3点を、明日からの設計指標として取り入れてほしい。

最小権限の強制（Zero Trust IAM）: iam:* は禁止。アクションはAPIレベルで具体的に列挙する。
ガードレイルの設定: Service Control Policies (SCP) を用いて、リージョン制限やルートユーザーの利用制限を強制する。
継続的モニタリング: CloudTrail のイベントログを Amazon EventBridge で拾い、異常な iam:Create* 呼び出しを検知した瞬間に当該IAMユーザーを無効化する自動遮断スクリプトを用意する。

セキュリティとは、完璧な壁を築くことではない。攻撃者が侵入した瞬間に「地雷」を踏ませ、その動きを完全に可視化し、即座に無力化する「動的なエコシステム」を構築することに他ならない。

技術を愛し、攻撃者の裏をかき続けること。それが我々エンジニアに課せられた、終わりのない使命だ。