AWS IAM の権限昇格: 攻撃経路はどう形成され、どう断ち切るか

Pathbreak チーム · 2026年8月11日 · 7 分で読めます

深刻な AWS のインシデントは、ほとんどが同じように展開します。攻撃者は低権限のアイデンティティ、すなわち漏えいしたアクセスキー、侵害された CI ロール、アプリの認証情報に着地し、数ステップのうちに管理者になります。こうしたケースのほとんどにゼロデイはありません。攻撃者は、アカウントが意図的に付与した権限を、誰も意図しなかった組み合わせで使います。

その組み合わせが IAM の権限昇格の経路です。この記事では、そうした経路が AWS でどのように形成されるか、それを生み出す権限の組み合わせ、なぜ通常のレビューから隠れてしまうのか、そしてそれを見つけて断ち切る方法を解説します。

IAM の権限昇格とは何か

IAM の権限昇格とは、あるアイデンティティがすでに持っているアクセス権を使って、本来持つべきでなかったアクセス権を自らに付与する、あるいはそこに到達することです。AWS では、これはほとんどの場合、ワークロードに侵入するのではなく、アイデンティティと権限を管理する API 層であるコントロールプレーン上で起こります。

AWS は、あなたが指示したとおりのことを正確に実行します。あるアイデンティティがポリシーを編集でき、ロールを渡せて、キーを作成できるなら、AWS はそれを許可します。昇格は通常、意図的に付与された権限から、誰も辿らなかった二次的な効果とともに生まれます。

権限昇格の経路はどう形成されるか

AWS の昇格経路のほとんどは、いくつかの系統に分類されます。そのどれも管理者権限を必要としません。それぞれが、限定的な書き込み権限を広範な力へと変えます。

自分が制御するサービスへロールを渡す

最も一般的なのは、iam:PassRole とコンピュートサービスの組み合わせです。あるアイデンティティが特権ロールを EC2 インスタンス、Lambda 関数、ECS タスク、あるいは Glue ジョブに渡すことができ、さらにそのサービスを起動できるなら、特権ロールとしてコードを実行し、その権限を継承できます。そのアイデンティティは、自分に欠けていた権限を持つロールを借りたのです。だからこそ iam:PassRole は最も注意して監視すべき権限であり、どのロールをどのサービスに渡せるかで常に制約されるべきなのです。

編集を許可されたポリシーを書き換える

あるアイデンティティが iam:CreatePolicyVersion を持っていれば、カスタマー管理ポリシーの新しいバージョンを好きな権限で公開し、そのバージョンをデフォルトに設定できます。1 つのバケットへの読み取りアクセスを付与していたポリシーが、すべてを付与するポリシーに変わります。同じ考え方は、インラインポリシーに対する iam:PutUserPolicy、iam:PutRolePolicy、iam:PutGroupPolicy にも当てはまります。この権限は日常的なポリシーの保守のように見えますが、そのポリシーが付与するものを何でも書き換えられます。

より強力なポリシーをアタッチする

iam:AttachUserPolicy、iam:AttachRolePolicy、iam:AttachGroupPolicy のような権限は、既存の管理ポリシーを自分自身や自分が制御するプリンシパルにアタッチすることを可能にします。AdministratorAccess をアタッチすれば、昇格はたった 1 回の呼び出しで完了します。これは、権限のスコープが広すぎたために成立します。

より強力なアイデンティティのために新しい認証情報を作成する

いくつかの権限は、すでにより多くの特権を持つプリンシパルのために、新しい認証情報を作成することを可能にします。別のユーザーに対する iam:CreateAccessKey は、そのユーザーに新しいキーを発行します。iam:CreateLoginProfile は、コンソールのパスワードを持たないユーザーにパスワードを設定します。iam:UpdateLoginProfile はそれをリセットします。いずれの場合も、攻撃者はすでに持っているアイデンティティに権限を追加するのではなく、認証に使えるより強力なアイデンティティを手に入れます。

信頼ポリシーを緩める

ロールの信頼ポリシーは、誰がそれを引き受けられるかを決めます。あるアイデンティティが特権ロールに対する iam:UpdateAssumeRolePolicy を持っていれば、その信頼ポリシーを自分自身を許可するように書き換え、sts:AssumeRole を呼び出してそのロールになれます。関連するリスクは、すでに信頼範囲が広すぎるロール、すなわちワイルドカードのプリンシパルやアカウント全体を信頼するロールです。その場合、ロールを引き受けるのに何も編集する必要すらありません。

なぜ孤立した権限は経路を隠すのか

ポリシーレビューでこれらの権限のどれか 1 つを見れば、妥当に見えます。デプロイ用のアイデンティティには iam:PassRole が必要です。プラットフォームチームにはポリシーの管理が必要です。自動化用のユーザーにはキーのローテーションが必要です。どの付与にも、もっともらしい理由があります。

昇格は、その付与がどこに到達できるかとつなげて初めて現れます。iam:PassRole は、どのロールを渡せるのか、そしてそのアイデンティティがそれらを実行するサービスを起動できるのかを問うまでは無害です。管理ポリシーの編集は、そのポリシーが管理者ロールにアタッチされていることに気づくまでは問題ありません。経路はグラフ全体を見たときにのみ現れますが、ポリシーを 1 つずつ扱うレビューがそれを見ることは決してありません。だからこそレビューは、何百もの検出を返しながら、管理者に到達する連鎖を見逃し得るのです。

それをマッピングするツール

これを手作業で推論する必要はありません。AWS IAM Access Analyzer は外部アクセスや未使用のアクセスを報告し、ポリシーを検証できます。オープンソースのツールは関係性をモデル化します。PMapper は誰が誰に到達できるかのグラフを構築し、Cloudsplaining は昇格を招きやすい権限を持つポリシーを指摘し、Pacu のようなオフェンシブなフレームワークは既知の昇格手法を列挙します。これらは有用であり、候補、すなわち機能し得る動きをマッピングします。

ほとんどのツールは証明の手前で止まります。あるアイデンティティが iam:PassRole を持っていると分かることは、有効なすべてのポリシー、境界、サービスコントロールポリシーを踏まえて、そのアイデンティティが今日管理者に到達できると分かることとは違います。それを確認することが、候補を検証済みの経路に変えるのです。

ディフェンダーはこれらの経路をどう断ち切るか

連鎖について良い知らせは、エッジを 1 つ切るだけでよいということです。いくつかの持続的な対策が、ほとんどの昇格経路を閉じます。

iam:PassRole を制約し、アイデンティティが特定のロールだけを渡せるようにし、iam:PassedToService 条件を追加して、Lambda 向けのロールが EC2 に渡せないようにします。iam: の書き込みアクション、とりわけポリシーの編集、アタッチ、認証情報の作成を高特権として扱い、限定的に付与します。IAM の書き込み権限を持たざるを得ないアイデンティティには権限境界を設定し、上限を超えられないようにします。サービスコントロールポリシーを使って組織全体で実効的な特権に上限を設け、設定ミスのあるアカウントでも管理者に到達できないようにします。ロールの信頼ポリシーを厳しくして、むき出しのアカウントやワイルドカードではなく、正確なプリンシパルを指定します。そして CloudTrail で、それと分かる呼び出しを監視します。すなわち、普段はそれらを行わないアイデンティティによる CreatePolicyVersion、AttachRolePolicy、UpdateAssumeRolePolicy、CreateAccessKey です。

難しいのは、あらゆるコントロールが相互作用した後にどの経路が残るかを知り、ポリシーが日々変わるなかでその答えを最新に保つことです。

Pathbreak のアプローチ

Pathbreak は IAM を、攻撃者と同じように、ポリシーのリストではなく到達可能性のグラフとして扱います。あなたの実際のアイデンティティ、ロール、ポリシー、境界、信頼関係に対して推論し、認可を解決して、どのアイデンティティが管理者に昇格できるか、あるいは機密データに到達できるかを確認します。これを読み取り専用で行います。あなたのアカウントに対して何も実行されず、何も変更されません。

経路が成立すると、Pathbreak は連鎖の全体を示し、それを断ち切るひとつの変更をお渡しします。削除すべき PassRole の付与、厳しくすべきポリシー、閉じるべき信頼関係です。順位付けされていない 1,000 件の検出をトリアージする代わりに、そのエッジを修正できます。仕組みは 仕組み のページで、私たちがカバーする連鎖は 攻撃経路 のページで、アクセスの扱いは トラストとセキュリティ のページでご覧いただけます。

よくあるご質問