AWS における攻撃経路分析と攻撃経路検証の違い

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

攻撃経路分析は、攻撃者が AWS で侵入口から標的まで移動するために使える、権限、信頼関係、露出のチェーンを見つけます。攻撃経路検証は、それらの各チェーンを AWS が呼び出しごとに評価する認可と照らし合わせて確認し、成立するものだけを残します。

互いに無関係な 3,000 件の問題のリストではなく、分析はチェーンを生成します。このパブリックインスタンスはこのロールを持ち、このロールはあのロールを Lambda に渡すことができ、あのロールは管理者である、というものです。現在ではほとんどのクラウドセキュリティプラットフォームが何らかの形でこれを提供しており、深刻度順に並べたリストと比べて大きな改善です。

検証は分析の次のステップです。AWS ではすべての判断に複数の種類のポリシーが関わるため、これは見た目以上に難しい問いであり、2 つの答えは多くのチームが想定する以上に食い違います。

攻撃経路分析が行うこと

分析はインベントリから始まります。プリンシパル、ロール、ポリシー、信頼関係、コンピューティング、ストレージ、そしてそれらの間のネットワーク上のつながりです。そこからグラフを構築し、管理者ロール、本番データベース、顧客データのバケットといった機密性の高いものに行き着くルートをグラフ上で探索します。各ホップは既知の手法です。iam:PassRole と lambda:CreateFunction の組み合わせは 1 つのホップです。信頼する側のアカウントへの sts:AssumeRole も 1 つのホップです。パブリックな関数 URL は侵入口です。

出力は候補経路の集合です。候補にとどまるのは、グラフが記述されたとおりのポリシードキュメントから構築されており、アイデンティティポリシー単体では、呼び出しが行われたときに AWS がどう判断するかがわからないためです。

分析が及ばないところ

AWS はすべての API 呼び出しを複数のドキュメントに同時に照らして評価し、そのどれか 1 つでも許可を拒否に変えることができます。グラフ上に存在する経路は、次のいずれによってもブロックされる可能性があります。

• サービスコントロールポリシー。組織単位にアタッチされた SCP は OU 全体に対して lambda:CreateFunction を拒否でき、その中のどのアイデンティティポリシーもそれを覆すことはできません。
• アクセス許可の境界。起点となるプリンシパルの境界は、そのアイデンティティポリシーが付与できる範囲に上限を設けます。境界に iam:PassRole が含まれていなければ、アイデンティティポリシーが許可していてもロールの受け渡しは失敗します。
• 信頼ポリシー。標的のロールは、そのホップが依存するサービスまたはプリンシパルを信頼している必要があります。lambda.amazonaws.com を信頼していないロールは、呼び出し元がどんな権限を持っていても Lambda に渡すことはできません。
• リソースポリシー。経路の終点にあるバケット、キー、キュー、関数にはそれぞれ独自のポリシーがあり、チェーンがたどり着いた時点のプリンシパルを拒否できます。
• 条件キー。iam:PassedToService、aws:SourceAccount、aws:PrincipalOrgID、そして sts:ExternalId のチェックは、いずれもアクションリスト上では広く見える付与を絞り込みます。
• 明示的な拒否。評価のどこかにある拒否ステートメントはすべての許可に優先し、それはグラフが読み取ったものとは別のポリシーにあることがよくあります。

これらのドキュメントを 1 つずつ読むのは簡単です。難しいのは、すべてのチェーンのすべてのステップについて、AWS と同じ順序でそれらをまとめて解決することであり、その作業こそが候補経路と証明済みの経路を分けます。これを省くとリストは長くなり、その大部分は最初の呼び出しで失敗するものになります。

AWS でクラウド攻撃経路を検証する方法

よくあるチェーンを例にとります。ci-deploy という CI ロールが、data-pipeline というロールに対する iam:PassRole に加えて、lambda:CreateFunction と lambda:InvokeFunction を持っています。data-pipeline ロールには AdministratorAccess があります。グラフ上では、これは CI ロールから管理者への 2 ホップの経路です。data-pipeline をアタッチした関数を作成して呼び出せば、その関数のコードは管理者として実行されます。

分析はこの経路を到達可能とマークします。続いて検証が、1 つずつチェックしながらこの経路をたどります。

1. ci-deploy のアイデンティティポリシーは、data-pipeline の ARN、またはそれを含むワイルドカードに対して iam:PassRole を許可しているか。はい、arn:aws:iam::*:role/data-* に対して許可しています。
2. ロールの受け渡しは iam:PassedToService で絞り込まれているか。条件がないため、どのサービスでも受け入れられます。
3. data-pipeline の信頼ポリシーは lambda.amazonaws.com を信頼しているか。はい、Lambda ベースのパイプライン用に作成されたロールです。
4. アカウントの OU にある SCP は lambda:CreateFunction または iam:PassRole を拒否しているか。OU には SCP がありますが、どちらも拒否していません。
5. ci-deploy のアクセス許可の境界は、どちらかのアクションを除外しているか。このロールには境界がありません。
6. 関数の実行は重要なものに到達するか。data-pipeline は管理者なので、答えはアカウント内のすべてであり、2 つのクロスアカウント信頼を通じて、さらに 2 つのアカウントにも及びます。

すべてのチェックを通過したので、この経路は証明済みです。関数は作成されず、何も呼び出されていません。各ステップは AWS と同じドキュメントを同じ順序で解決し、同じ判断を返しました。コントロールプレーンにおける検証とはこういうことです。エクスプロイトが権限である以上、その証明は認可の結果です。

修正はステップ 2 から導かれます。最も影響範囲の小さい変更は、ロールの受け渡しの付与に iam:PassedToService を追加して意図したサービスだけがロールを受け取れるようにするか、ワイルドカードの ARN を CI が必要とする単一のロールに置き換えることです。変更後に同じ 6 つのチェックを再実行すると、ステップ 2 が失敗します。経路は消え、その確認結果が検出結果の横に記録されます。このチェーンのマップ項目に、CloudTrail イベントと詳しい解説があります。

攻撃経路の検証を本番環境で実行しても安全か

読み取り専用の検証であれば安全です。Pathbreak は、お客様が作成し、いつでも取り消せる、最小権限の読み取り専用 IAM ロールを通じて接続します。Pathbreak が行う呼び出しはすべて読み取り（Get、List、Describe）であり、各ステップの認可は、それらの呼び出しが返すポリシードキュメントから解決されます。関数は作成されず、経路上のロールが引き受けられることもなく、リソースも変更されないため、本番のワークロードはそのまま動き続けます。

ロールのセッションと読み取りは、CloudTrail に Pathbreak ロールによる管理イベントとして記録されるため、アクティビティを簡単に監査できます。Pathbreak は構成を読み取ります。これには、インスタンスのユーザーデータ、関数の環境変数、スタックの出力など、認証情報が露出しやすい場所も含まれます。オブジェクトストレージやデータベースの内容は読み取りません。

読み取り専用の検証は、各ステップについて 1 つの問いに答えます。AWS はこのプリンシパルのこの呼び出しを認可するか、という問いです。アプリケーションコード、稼働中のホストに対するエクスプロイト、検知と対応が攻撃者を捕捉できるかどうかはテストしません。それらは手動の AWS セキュリティ評価でカバーされ、Pathbreak はそれと並行して利用できます。環境内で攻撃ステップを実行して検証するツールもあり、こちらの比較でそれぞれのアプローチが適する場面を説明しています。

この違いが、最初に何を修正するかを決める理由

経路を影響度でランク付けすることに意味があるのは、その経路が実在する場合だけです。証明済みのチェーンと、すでに SCP がブロックしているチェーンが混在したリストは、チームを何も変わらない作業へと向かわせます。Pathbreak のラボアカウントでは、分析によって 4,942 件の候補経路が生成されました。検証と影響範囲によるランク付けの後、1 つのロールに対する 1 つの Deny で残り 4,087 件のうち 3,893 件の経路が取り除かれ、2 つの変更を合わせてアカウントのリスクの 80% が取り除かれました。この順序は、各経路を実際の認可に照らして解決して初めて見えてきます。

Pathbreak の方法

Pathbreak はグラフを構築し、それを推論して候補チェーンを生成したうえで、AWS が評価する認可、つまりアイデンティティポリシーとリソースポリシー、信頼ポリシー、SCP、境界、条件を解決することで、各チェーンを最初から最後まで検証します。アクセスは読み取り専用で、何も実行されません。検証済みの各経路は到達先によってランク付けされ、それを断ち切る具体的な変更が添えられます。変更が反映された後に経路が再評価されて結果が記録されるので、修正は証拠をもって確認されます。

よくある質問