AWS における CTEM の検証段階を実際の数値で見る

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

継続的な脅威エクスポージャー管理は、5 つの段階からなるプログラムの枠組みです。スコーピングでは、どのシステムをプログラムの対象にするかを決めます。発見では、それらのシステムにあるエクスポージャーを見つけます。優先順位付けでは、エクスポージャーをランク付けします。検証では、ランク付けされたエクスポージャーのうち攻撃者がどれを利用できるかを証明します。動員では、証明されたものを、その担当者に修正してもらいます。定義は他の資料で十分に説明されているので、この記事では AWS における 4 番目の段階を、実際のアカウントの数値とともに取り上げます。

AWS のプログラムが停滞するところ

AWS における発見の段階は、十分なツールがそろっています。CSPM やスキャナーは、パブリックバケット、過度に広いポリシー、未使用のキー、暗号化の欠如、ワイルドカードで信頼するロールなど、数千件の検出結果を半日で生成します。優先順位付けも、深刻度スコア、悪用可能性スコア、資産の重要度タグによってリストを並べ替えられるので、十分に対応されています。

停滞は次の段階で起こります。ランク付けされた 3,000 件の検出結果は、依然として 3,000 件の検出結果であり、そのランクは推定にすぎません。SCP によってすでに囲い込まれているロールに対する重大な検出結果は、何も変えません。ベンダーのアカウントを信頼するロールに対する中程度の検出結果が、本番環境への経路になっているかもしれません。検証がなければ、チームはスコアで作業を選ぶことになり、そのスコアは攻撃が成立するかどうかを決める認可を読まずに算出されたものです。

AWS のコントロールプレーンにおける検証の姿

AWS では、攻撃者の操作は API 呼び出しです。各呼び出しは、AWS がまとめて評価する一連のドキュメントによって許可または拒否されます。呼び出し元のアイデンティティポリシー、アクセス許可の境界、組織単位にあるサービスコントロールポリシー、標的の信頼ポリシーまたはリソースポリシー、そして各ステートメントの条件です。検証とは、候補チェーンを構築し、チェーンのすべてのステップについて、AWS と同じやり方でそれらのドキュメントを解決することです。すべてのステップが許可に解決されれば、その経路は証明済みです。どれか 1 つのステップでも拒否に解決されれば、その経路はリストから取り除かれます。

そのいずれにも、何かを実行する必要はありません。証明は認可の結果であり、ポリシーを読むには読み取りアクセスだけで足ります。これが、この段階を実際に継続的なものにしています。変更ウィンドウなしで、すべてのアカウントに対して毎日実行できるのです。

ラボアカウントの数値

Pathbreak のラボアカウントは、ホームページに掲載している数値の元になっている環境です。そこで検証段階が生み出した結果は次のとおりです。

これらの数値は、検証が何のためにあるのかを示しています。数千件の候補経路は、数千件の独立した問題ではありませんでした。その大半は同じ少数のロールを経由していたため、適切なプリンシパルに対する少数の変更で、証明済みの経路の大部分を一度に断ち切ることができました。深刻度順のリストであれば、同じアカウントがほぼ同じ重みの 4,942 項目として示され、チームはそれらを 1 つずつ修正することになっていたでしょう。

動員の段階が検証から必要とするもの

5 番目の段階は、ロールの担当者が対処できない検出結果を受け取ったときに失敗します。検証が引き渡すべきものは 3 つです。1 つ目は証明済みの経路で、各ホップが明示されたチェーンとして示し、そのロールがなぜ経路上にあるのかを担当者が理解できるようにします。2 つ目はそれを断ち切る具体的な変更で、Deny ステートメント、iam:PassedToService 条件、より狭い信頼ポリシー、権限の削除などを、すぐに適用できる変更そのものとして記述します。3 つ目は確認です。変更が反映された後に経路が再評価されて結果が記録されるので、チケットは証拠に基づいてクローズされます。

ラボでは、修正の 81% が 1 コマンドで済みました。これが動員の段階で重要なのは、IAM ポリシーへの 1 行の変更なら数分でレビューを通過する一方、ロール階層の再設計は次の四半期に持ち越されるからです。

この段階を継続的にする

アカウントはデプロイのたびに変化します。新しいロール、範囲が広がった信頼ポリシー、ワイルドカードに対する iam:PassRole を与えられたパイプラインがあれば、先月閉じた経路が再び開きます。検証段階が役に立ち続けるのは、スケジュールに沿って実行され、何が変わったかを報告する場合だけです。そうすれば、チームは新たな証明済みの経路を現れたその日に把握でき、確認済みの修正がその後に後戻りしたことにも気づけます。

読み取り専用の検証なら、それを低コストで実現できます。エージェントも変更ウィンドウも不要で、テスト自体が本番環境にリスクを与えることもないため、すべてのアカウントで毎日実行するのが標準になります。

AWS について CTEM プラットフォームに確認すべきこと

経路のすべてのステップについて、SCP、アクセス許可の境界、信頼ポリシー、条件キーを解決するか。アカウントをまたいで、経路の到達先によってランク付けするか。各経路を断ち切る変更を示し、その後に変更を確認するか。アカウント内で何も実行せずに毎日実行できるか。これらの答えから、動員の段階でそのプラットフォームがチームに何を引き渡すかがわかります。

Pathbreak は、AWS におけるこの段階のために作られています。AWS のための AEV に関する記事では検証手法をさらに詳しく取り上げ、分析と検証の違いに関する記事では 1 つのチェーンを到達可能から証明済みまでたどっています。

よくある質問