AWS のクロスアカウント信頼関係への攻撃: ロールの連鎖はどのように最重要資産に到達するか

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

マルチアカウント AWS は大規模な環境を運用するための推奨される方法であり、クロスアカウントの IAM ロールがそれを結びつけています。セキュリティアカウントはすべてのワークロードアカウントからログを読み取ります。共有サービスアカウントは他のアカウントにデプロイします。ベンダーは自社の製品を動かすためにロールを引き受けます。これらはすべて、設計どおりに機能するクロスアカウントの信頼関係です。

それは同時に、攻撃者が辿る地図でもあります。1 つのアカウントに着地し、次のアカウントで引き受けられるロールを探し、それを繰り返します。この記事では、クロスアカウントの信頼関係がどう悪用されるか、ロールの連鎖がどのように最重要資産に到達するか、そしてその経路をひとつの変更で断ち切る方法を扱います。

クロスアカウントの信頼関係の仕組み

すべての IAM ロールには 2 つのポリシーがあります。権限ポリシーはそのロールが何をできるかを定めます。信頼ポリシー、すなわち assume-role ポリシーは、誰がそれになることを許されるかを定めます。ロールに移るには、プリンシパルが sts:AssumeRole を呼び出して一時的な認証情報を取得します。ただし、対象ロールの信頼ポリシーがそのプリンシパルを許可し、かつ呼び出し元が sts:AssumeRole の権限を持っていることが条件です。

信頼ポリシーは誰が入れるかを制御するため、クロスアカウントのセキュリティは、許可するプリンシパルをどれだけ正確に指定するかにかかっています。

信頼関係はどこで破綻するか

信頼ポリシーにおけるワイルドカードのプリンシパル

最も危険で、最も誤解されている信頼ポリシーがワイルドカードのプリンシパルです。"Action": "sts:AssumeRole" とともに "Principal": { "AWS": "*" } を許可するステートメントは、あなたのアカウント内の任意のアイデンティティを意味するのではありません。それは、そのロールを世界中のあらゆる AWS アカウントに対して開放します。第 2 の条件、すなわち呼び出し元のアイデンティティもそのロールに対する sts:AssumeRole の権限を持っていなければならない、という条件はありますが、だからこそワイルドカードは現実的なリスクなのです。攻撃者は自分自身の AWS アカウントでその権限を自らに付与するので、第 2 の条件を無償で満たします。チームはワイルドカードを「自分のチームの全員」と読み取り、そのまま公開してしまいます。彼らが公開したのは、攻撃者が自分の制御するアカウントから引き受けられるロールです。意味のある権限を持つロールでは、それはそのロールができることすべてを明け渡すことになります。どうしても広いプリンシパルが必要なら、aws:PrincipalAccount や aws:PrincipalOrgID のような Condition で制約し、さらに良いのは、信頼するつもりの正確なロール ARN を指定することです。

サードパーティのロールにおける混乱した代理

SaaS ベンダーにあなたのアカウント内のロールを引き受けさせる場合、そのベンダーは 1 つの AWS アカウントで多くの顧客にサービスを提供しています。あなたの信頼ポリシーがベンダーのアカウントだけを指定していると、そのベンダーの別の顧客が、あなたのロールを引き受けるようベンダーを仕向けることができてしまいます。対策は、external ID、すなわち条件に含める共有シークレットか、引き受けをあなた固有の関係に結びつける aws:SourceArn または aws:SourceAccount 条件です。それのないサードパーティのロールは、典型的な混乱した代理の露出です。

アカウントをまたぐロールの連鎖

1 回のホップで目標に到達することはまれなので、現実の経路は連鎖します。攻撃者は開発アカウントのロールを引き受けます。そのロールはたまたま共有サービスアカウントのロールから信頼されており、そのロールは本番環境のロールを引き受けられ、そのロールは Secrets Manager にあるデータベースの認証情報を読み取れます。正当な sts:AssumeRole の呼び出しが 4 回。こうして、最も重要度の低いアカウントの足がかりが、最も重要なデータへのアクセスに変わります。

連鎖を危険にするのは、どのホップも認可されており、何も悪用されず、認証情報が一時的で想定どおりだという点です。CloudTrail から見れば、ロールが自分の仕事をしているように見えます。危険を見抜く唯一の方法は、各信頼関係を単体で判断するのではなく、連鎖全体を一度に見て、それがどこで終わるかを問うことです。

AWS はいくらか摩擦を加えてはいます。連鎖したロールのセッションは 1 時間に制限され、さらに連鎖して更新することはできません。それはセッションの存続時間を制限しますが、経路を閉じるわけではありません。

なぜアカウント境界は実際よりも安全に感じられるのか

チームはアカウント境界をセキュリティ境界として扱い、それは影響範囲という点では優れた境界です。問題は、クロスアカウントのロールが意図的にその境界を貫通しており、そのそれぞれがそのアカウントの所有者によって個別にレビューされるため、誰も連鎖全体をレビューしないことです。開発チームの都合の良い信頼関係と、プラットフォームチームの共有ロールは、それぞれは妥当であり、合わさるとどちらのチームも自分の立場からは見えない経路を形づくります。個別のレビューがクロスアカウントの経路を見逃すのは、IAM の昇格を見逃すのと同じ理由です。リスクはロールのつながり方にあり、ロールを 1 つずつレビューしても、それが見えることは決してありません。

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

グラフベースのツールが役立ちます。PMapper と Cartography はアカウントをまたいだロールと信頼関係をモデル化でき、AWS IAM Access Analyzer はあなたのロールへの外部アクセスを、忘れているかもしれないクロスアカウントの信頼関係も含めて報告します。これらは候補となるエッジを提供します。残る問いは、それらの候補となる連鎖のうち、すべてのホップ、すべての条件、有効なすべての権限ポリシーを踏まえて、どれがあなたの気にかけるものへと成立するか、ということです。機密性のない場所にしか通じない信頼のエッジはノイズであり、本番データへの 4 ホップの連鎖こそ、あなたが修正すべきものです。

連鎖を断ち切る方法

どの経路でも同じように、エッジを 1 つ切れば十分です。信頼ポリシーのルートアカウントのプリンシパルを、正確なロール ARN に置き換えます。すべてのサードパーティのロールに external ID または aws:SourceArn 条件を要求します。もはや目的を果たしていないクロスアカウントの信頼関係を削除します。休眠中のベンダーロールはよく見つかります。可能な場合は、サービスコントロールポリシーを使って、特定のクラスのアカウント全体が機密性の高いロールを引き受けられないようにします。そして、予期しないソースからの重要なロールへの AssumeRole の呼び出しにアラートを設定します。

判断が求められるのは、どのエッジを切るかです。適切なエッジは、正当なものに一切触れずに攻撃者の経路を断ち切り、誤ったエッジはパイプラインを壊します。それには、各連鎖がどこに通じているかを知る必要があります。

Pathbreak のアプローチ

Pathbreak はあなたの AWS アカウント全体にわたる完全な信頼グラフを構築し、それを攻撃者と同じように 1 つのつながった空間として扱います。各 AssumeRole のホップを、実際の信頼ポリシー、権限ポリシー、条件に照らして解決し、どの連鎖が本番データ、バックアップ、組織管理などの最重要資産に到達するかを確認します。読み取り専用で動作するため、信頼関係をマッピングしても、それに手を触れることは決してありません。

成立するすべての連鎖について、Pathbreak はホップを示し、それを断ち切るたった 1 本の信頼のエッジを指し示します。多くの場合、1 つの広すぎる信頼ポリシーか、1 つの忘れられたベンダーロールです。私たちがカバーする連鎖は 攻撃経路 のページで、仕組みは 仕組み で、最小権限アクセスの扱いは トラストとセキュリティ のページでご覧いただけます。同じ推論が 1 つのアカウント内でどう当てはまるかについては、AWS IAM の権限昇格 に関する記事をご覧ください。

よくあるご質問