Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年7月14日に Lydia Graslieが投稿したブログ (https://www.sysdig.com/blog/no-single-pane-of-glass-anatomy-of-an-azure-permission-takeover) を元に日本語に翻訳・再構成した内容となっております。
Sysdig 脅威リサーチチーム（TRT）は最近、攻撃者が漏洩したサービスプリンシパルの認証情報ひとつを起点に、翌朝にはテナントを完全に掌握する様子を観測しました。この攻撃者は、ディレクトリのグローバル管理者（GA）権限とすべてのリソースに対するルートレベルのアクセス権を握り、テナントを二つの制御プレーンにわたって完全に支配しました。数十のアイデンティティにわたって永続化を仕込み、本来は攻撃者を監視するはずだったテレメトリパイプラインの鍵まで奪い取ったのです。
この攻撃を止めること自体は簡単でした。しかし、攻撃を分析する作業は実はかなり複雑で、突き詰めると答えが複数ある一つの問いに行き着きました。
この攻撃のあと、このテナントに実際に触れられるのは「誰」で「何」なのか？
Azure において、この問いには単一の答えがなく、答えを見つけられる単一の場所も存在しません。権限は、Azure が統合していない少なくとも5つの分断されたシステムに散在しています。これらの権限システムは識別子を共有しておらず、ログもデータモデルも異なります。攻撃者はこれらの間を検知されずに飛び移ることができます。まさに、防御側が一度に複数を見ることがめったにないがゆえにです。
そこで、ひとつの認証情報がどのように5つの権限システムすべてを渡り歩いたのか、そしてクラウドアイデンティティの「シングルペインオブグラス（単一の統合ビュー）」がなぜ今なお概ね理想論にとどまっているのかを見ていきましょう。
始まりは：ひとつの認証情報、多くの手
侵入口は地味で、きわめてありふれたものでした。漏洩したサービスプリンシパルのクライアントシークレットです。サービスプリンシパルは Azure の非人間アイデンティティ（NHI）であり、アプリケーション、自動化、CI/CD パイプラインが認証に使うアカウントです。Sysdig 2026 クラウドネイティブセキュリティ利用状況レポートによれば、Azure サービスプリンシパルの38%強がリスクありと見なされています。これはつまり、長寿命のシークレットや証明書を保持している、過剰な権限を持っている、あるいはこうしたアイデンティティのひとつが地球の裏側からログインしてもプッシュ通知を受け取る人が誰もいない、といった状態を意味します。
今回のシークレットは、攻撃者が見つけるまで約2週間にわたって露出していました。その期間中、シークレットは巡回する匿名化インフラ群から繰り返し再利用されました。商用 VPN のレンジ、Tor 出口ノード、そして米国・ドイツ・スウェーデン・香港・オランダにまたがる小規模ホスティングプロバイダーです。発信元が多様であること自体がひとつの発見でした。これは追跡可能なひとりの人物ではなく、共有プールや自動化プールのどこかに置かれた認証情報が、複数の独立した日和見的な利用者に拾われ、繰り返し再利用されていたのです。そのほとんどは偵察しか行いませんでした。ARM の列挙、Graph の探り、ストレージと Key Vault の一覧取得です。
そして、あるセッションが偵察をやめ、権限昇格を始めました。
Sysdig TRT が観測したこと
時刻はすべて UTC です。以下の操作はすべて成功を返しました。
フェーズ1：ディレクトリでの権限昇格（03:27〜03:50）
- 03:27 — オランダのホスティング ASN から、サービスプリンシパルとして最初の有効なサインイン。
- 03:28 — ロールへのメンバー追加（自分自身）。
- 03:29:57 — PIM 外でのロールへのメンバー追加（恒久的） → ディレクトリルートでグローバル管理者に。最初のログインから Entra ディレクトリ全体の掌握まで、約2分半。（注：サービスプリンシパルがどうやって自分自身に GA を付与できたのか？ まさにそれを可能にする Graph API 権限をすでに保持していたのです。後述の「5つ目の面」を参照。）
- 03:29〜03:50 — 攻撃者が管理するクライアントシークレットを26個のアプリケーション登録に追加。（この数字がなぜ重要かは後述。）
フェーズ2：リソースプレーンでの権限昇格＋鍵の収集（04:32〜04:37）
- 04:32:37 —
Microsoft.Authorization/elevateAccess/action→ Azure リソースに対してルートでユーザーアクセス管理者に。 - 04:32:44 — サブスクリプションスコープでの
roleAssignments/write（所有者クラスのロールを自分自身に割り当て）。 - 04:33 — 4つのストレージアカウントに対する
storageAccounts/listKeys。 - 04:33:37〜38 — 両方の Event Hub 名前空間の
rootmanagesharedaccesskeyに対するlistKeys。これらはテナント自身の監査テレメトリを運ぶものでした。 - 04:34 — 3つの Key Vault に対する
Microsoft.KeyVault/vaults/accessPolicies/write（自己追加）、続いて同じ Vault に対するroleAssignments/write。その後、データプレーンでのシークレット読み取りが続きました。
フェーズ3：永続化と再訪（〜09:57頃まで）
- 午前中を通じてアクセスが継続。仕込まれたシークレットのひとつが後に別のエグレスから再利用され、バックドアが機能することが確認されました。その後、攻撃者は沈黙しました。
最初のログインから、ディレクトリ、すべてのサブスクリプションリソース、ストレージ鍵、Event Hub 鍵、Key Vault の掌握まで、攻撃者が要した実働はある午前中にわたる約1時間でした。マルウェアもエクスプロイトもゼロデイもなく、あったのは権限だけ――付与され、昇格され、収集された権限が、完全に正当な Azure API を通じて使われたのです。
インシデント後、09:57 の時点で攻撃者が支配しているものすべてを特定するには、完全な答えを得るために少なくとも5つの異なる場所を参照する必要があり、そのどれもが「他の場所が持っているピースが自分には欠けている」とは教えてくれません。
本当の問題：決して交わらない5つの権限プレーン
プレーン1：Entra ディレクトリロール
グローバル管理者（GA）の付与は、Entra ID（旧 Azure AD）のディレクトリロール管理に存在します。これは、ほとんどの人が「Azure の権限」として思い浮かべるプレーンです。グローバル管理者、特権ロール管理者、そして人やアプリケーションに割り当てるディレクトリロールです。
インシデント後にこのプレーンだけを確認すると、GA 付与が見えて「その割り当てを削除すれば大丈夫」と結論づけてしまうでしょう。しかしそれは大きな間違いです。攻撃者はすでにこのプレーンを離れ、次のプレーンへ移っているからです。
プレーン2：Azure ロールベースアクセス制御（RBAC）
Azure RBAC はリソースの制御プレーンです。これには、サブスクリプション、リソースグループ、リソースに割り当てる所有者／共同作成者／ユーザーアクセス管理者のロールが含まれます。これは Entra ディレクトリロールとは完全に別のシステムであり、ロール定義も、割り当ての格納先も、スコープモデルも異なります。GA はデフォルトでは、あなたのサブスクリプションの所有者ではありません。
プレーン1とプレーン2の間の橋渡しは、（私たちの見解では）Azure 全体でもっとも奇妙で、もっとも監視されていない動きのひとつです。elevateAccess です。
GA は Microsoft.Authorization/elevateAccess/action を呼び出すことで、テナント内のすべてのサブスクリプション（現在および将来のもの）に対して、ルートスコープ（/）でユーザーアクセス管理者権限を即座に自分自身に付与できます。API 呼び出しひとつです。これは「自分のサブスクリプションから自分を締め出してしまった」場合の正当な復旧手段として存在します。そしてこれは、「ディレクトリを所有している」状態から「すべてのリソースを所有している」状態へ移行する、この上なくクリーンな方法なのです。
ここで可視性の落とし穴があります。elevateAccess は、あなたが予想する場所には表示されません。これは通常のロール割り当てではないため、削除対象として見つけられる所有者としてサブスクリプションの RBAC ブレードには現れません。また、他のリソースプレーン操作が記録される、エクスポート済みの AzureActivity（Azure リソース）ログにも落ちてきません。elevateAccess はポータルのディレクトリアクティビティログに現れますが、これらのログは Azure アクティビティログ API 経由ではエクスポートされず、Entra 監査ログのロール管理カテゴリの下に記録されます。
これが分断の縮図です。二つの権限システムを橋渡しする動きが、どちらの「通常の」ビューにも表示されないのです。
プレーン3：Key Vault
ユーザーは、Entra ロールと Azure RBAC を監査すれば「権限」をカバーできたと思い込むかもしれません。そうではありません。一部のリソースは、リソースそのものに存在する独自の3つ目の権限モデルを持っているからです。
Key Vault はその典型的な例です。Vault は2つのアクセスモードのいずれかを取ります。RBAC（Azure RBAC 経由の権限、プレーン2）か、アクセスポリシー（Vault 上に格納された権限リストで、シークレット・鍵・証明書に対する get/list/set をプリンシパルに付与するもの）です。これらは、同じリソースに対する並列かつ独立した認可モデルです。
Sysdig TRT が観測した事例では、攻撃者は vaults/accessPolicies/write を使って3つの Vault のアクセスポリシーに自分自身を追加し、さらに同じ Vault に対して roleAssignments/write も実行して、両方のモデルを一度にカバーしました。つまり、単一のリソースタイプの内側においてすら、「このシークレットを読めるのは誰か？」は、別々に確認しなければならない2つの異なる権限ストアの和集合なのです。アクセスポリシーのエントリを見落とせば、あなたの「クリーンアップ」は、RBAC ブレードでは決して見えないドアを開けたままにしてしまいます。
プレーン4：ベアラー鍵と SAS
これは「シングルペインオブグラス」を完全に破綻させるものです。なぜなら、そもそもこれはアイデンティティシステムですらないからです。
ストレージアカウント、Event Hubs、Service Bus、Cosmos DB などは、共有鍵と共有アクセス署名（SAS）をサポートしています。これらは長大で高権限のシークレットであり、それを保持する者なら誰にでもデータプレーンへのアクセスを付与します。プリンシパルも、ロール割り当ても、いかなる IAM ビューのエントリも存在しません。鍵を持っていれば認可されている、それだけです。
攻撃者は4つのストレージアカウントと両方の Event Hub 名前空間に対して listKeys を呼び出し、データおよびテレメトリ転送に対するベアラー認証情報を手にして立ち去りました。ここで、あるユーザーが「このストレージアカウントに誰がアクセスできるか？」を調べるツールにデータを読める人物を問い合わせると、ツールは RBAC のロール割り当てを自信満々に表示して、このアカウントはロックダウンされていると答えるでしょう。しかしその間ずっと、アカウント鍵のコピーが攻撃者のポケットの中にあり、フルの読み書きを許可しながら、いかなるアクセスレビューにも、RBAC レポートにも、アイデンティティグラフにも現れないのです。
共有鍵は権限のロンダリングです。アイデンティティにスコープされた付与（listKeys は権限を必要とし、ログにも残ります）を、その後どこにも現れないアイデンティティレスなベアラーシークレットへと変換してしまいます。鍵を発行する行為はアクティビティログに一瞬だけ見えます。それ以降のあらゆる使用は匿名です。listKeys 呼び出しをそれが起きたまさにその瞬間に監視していなければ、結果として生じるアクセスは永遠に不可視です。
そしてアイデンティティレスであるだけでなく、事態はさらに悪化します。デフォルトでは、これはログにも残りません。Azure は制御プレーンの付与（listKeys 呼び出しはアクティビティログに落ちる）を記録しますが、結果として得られた鍵のデータプレーンでの使用――BLOB の読み取り、Event Hub の吸い出し――は、リソースごとのデータプレーン診断を明示的に有効化した場合にのみログに残ります。そしてこれは、ストレージ、Event Hubs、そしてほとんどのリソースタイプでデフォルトでは無効です。今回のインシデントでは、Event Hub 名前空間には診断設定がまったくなかったため、盗まれたルート鍵の使用は一切の痕跡を残さなかったはずです。ストレージアカウントにもデータプレーンのログはありませんでした。したがって、listKeys 呼び出しは、単にベアラー鍵を見る最良のチャンスというだけではありません。デフォルト状態では、唯一のチャンスなのです。その制御プレーンイベントをひとつ見逃せば、それが作り出したアクセスはアイデンティティレスかつ不可視となり、それが永続します。二重の盲点です。
プレーン5：Graph API アプリケーション権限
5つ目の権限システムは、あなたが「権限」だとはもっとも思わないであろうものであり、そもそもフェーズ1を可能にしたものです。
漏洩したサービスプリンシパルは、Microsoft Graph のアプリケーション権限 RoleManagement.ReadWrite.Directory を保持していました。ポータルでは「すべてのディレクトリ RBAC 設定の読み取りと書き込み」と当たり障りなく記述されています。この単一のアプリケーション権限は、テナント乗っ取りに等しいものです。これはアプリケーションが任意のディレクトリロールを誰にでも割り当てることを許し、自分自身に GA を付与することさえ可能にします。プレーン1で見た03:29 の GA 自己付与は、攻撃者が偶然たどり着いた権限ではありません。管理者がはるか昔に同意していた Graph 権限の、直接的かつ意図された能力だったのです。Graph API 権限は独自の面――独自のスコープモデル、独自の同意システム、ポータル上の独自の場所――を持ち、上記の他の4プレーンのどこにも現れません。
残酷なのは、あなたが自然に見るであろう場所からはこれが見えないことです。防御側がやるように、この一つのアプリを掘り下げてたどってみましょう。
アプリケーションの「ロールと管理者」ペインは「このアプリは何ができるか？」に答える場所のように見えますが、信頼できる真実の情報源ではありません。ここにはこの場所で割り当て可能なアプリ管理ロール（クラウドアプリケーション管理者）だけが列挙され、ディレクトリレベルのロールは「ディレクトリレベルでのみ割り当て可能」だと脚注が説明しています。これを注意深く読んでください。もしこのアプリが GA やユーザーアクセス管理者を保持していても、このペインには表示されないのです。もっとも強力なロールは、アプリごとのビューからは単純に不可視です。ディレクトリロールのメンバーシップを反対方向から確認しなければならないことを、あらかじめ知っておく必要があります。
そして、乗っ取りを実際に可能にした能力は、そもそもロールですらありません。それは隣のブレードにあります。
これは同じアプリの API 権限です。そこにあります。RoleManagement.ReadWrite.Directory が管理者同意済みで、別のモデルと別の心理的カテゴリを持つ別のブレードに。このアプリのロールを監査する防御側は、何も警戒すべきものを見ません。乗っ取りの鍵は、ずっとタブひとつ隣にあったのです。
ですから、たったひとつのアイデンティティにまで絞り込み、可能な限り単純な問い――「この一つのアプリは何ができるか？」――を投げかけたときですら、答えは互いを参照し合わないペインにまたがって散らばっており、もっとも危険な能力は、ユーザーが開く可能性がもっとも低いことの多い場所に存在しています。分断は5つのプレーンにわたるテナント全体のものだけではありません。単一アプリケーションの詳細ページの内側でも再現されているのです。
さらに NHI のスプロール（拡散）問題
フェーズ1のさりげない一文に立ち返りましょう。攻撃者は26個のアプリケーション登録にシークレットを仕込みました。
これは永続化であり、まさに私たちがこれまで説明してきた分断を狙って設計された永続化です。各アプリケーション登録は、独自の認証情報リストと独自の（しばしば忘れられた）権限フットプリントを持つ、独立した非人間アイデンティティです。GA 付与を削除してもこれらには何の影響もなく、元の漏洩したシークレットをローテーションしても同様です。それぞれが、再侵入するための別個で有効な経路なのです。
そして「テナント内のすべてのアプリ登録のすべての認証情報」を一覧表示する単一の Azure ビューは存在しません。26個すべてを見つけるには、アプリ登録を列挙し、その passwordCredentials をひとつずつ調べるか――あるいはたまたま監査ログを取得していたなら、そこから再構築するしかありません。永続化のブラストラディウス（影響範囲）自体が、ほとんどのアイデンティティダッシュボードが後付け程度にしか扱わないプレーン（アプリ／SP の認証情報）を、総当たりで列挙することによってのみ知り得るのです。
Sysdig 2026 クラウドネイティブセキュリティ利用状況レポートによれば、NHI はクラウド環境における管理対象アイデンティティの約97%を占め、もっとも長寿命のシークレットを保持し、権限資産全体の中でもっとも計測・監視の行き届いていない領域です。今回のインシデントは1つの漏洩した NHI から始まり、26個のバックドア化された NHI で終わりましたが、それらを明確に可視化するツールは、デフォルトでは概ね存在しないのです。
これは可視性の問題であって、単なる攻撃者の問題ではない
攻撃者は身を隠すために何も巧妙なことをしていません。すべての操作は、ログに残る正当な API 呼び出しでした。全体像を組み立てるのが難しかった理由は構造的なものです。「今、誰と何がアクセス権を持っているか」を再構築するには、互いに会話しない5つの異なる面をクエリしなければなりませんでした。
- Entra ディレクトリロール → Entra 監査ログ（
AuditLogs） - Azure RBAC ＋鍵の収集 → Azure アクティビティログ（
AzureActivity） - Key Vault データプレーンアクセス → リソース診断ログ（
AzureDiagnostics） - NHI 認証情報の永続化 → アプリ登録を列挙（または監査から再構築）
- Graph API アプリケーション権限 → 各アプリの API 権限設定（または
AuditLogsに戻ってAdd app role assignment／同意イベント）
……そして elevateAccess、もっとも重大なイベントは、リソースプレーンの付与であるにもかかわらず Entra テーブルに存在しています。まさに油断させないためかのように。
防御側がしばしば抱える2つの問いのどちらにも答えられる、ネイティブな Azure 画面は存在しません。
- このプリンシパルが到達できるすべてを見せて――ディレクトリロール、あらゆるスコープの RBAC、リソースローカルのポリシー、そしてそれが発行したあらゆるベアラー鍵にわたって。
- このリソースに到達できるすべてを見せて――アクセスポリシーのエントリ、RBAC 割り当て、そしてそれに対して漂っているアイデンティティレスな鍵を含めて。
これらの問いは5つのプレーンすべてにまたがりますが、プレーンは結合キーを共有していません。サービスプリンシパルのオブジェクト ID、RBAC 割り当てのスコープパス、Key Vault アクセスポリシーのエントリ、ストレージアカウント鍵には、相関を取るための共通点がほとんどありません。分断は Azure の UI の中だけにあるのではありません。それは、私たちの多くが Azure を監視する方法にも伝播します。なぜなら、私たちは与えられたプレーンの形に合わせて検知を組み立てるからです。
調査を救ったものは、地味なものでした。私たちは制御プレーンのログを、攻撃者が到達できない改ざん不可能なテナント外ストレージに取得していました。攻撃者はテレメトリパイプラインの Event Hub ルート鍵を握っており、稼働中のワークスペースを目隠しにしたり汚染したりすることもできましたが、耐久性のあるコピーは彼らのブラストラディウスの外にあったため、攻撃の全チェーンを完全に再構築できたのです。証拠の耐久性は、攻撃者が支配するプレーンから独立していなければなりません。それが第0の教訓であり、このブログ記事が書ける唯一の理由です。
ではどうすればよいか
Azure の権限モデルを直すことはできませんが、それに驚かされ続けるのをやめることはできます。具体的には次のとおりです。
1. 5つのプレーンすべてを、ひとつの資産として棚卸しする。 Entra ロールと Azure RBAC だけをカバーするアクセスレビューは、リソースローカルのポリシー（Key Vault など）、ベアラー鍵、Graph API アプリケーション権限を丸ごと見落としています。5つすべてをひとつの権限グラフの一部として扱ってください。攻撃者にとってはまさにそうなのですから。
2. NHI を、その Graph 権限も含めて、一級のアイデンティティとして扱う。 サービスプリンシパルとその認証情報には、ユーザーアカウントと同じ精査が必要です。すべてのアプリ登録のシークレット／証明書を棚卸しし、認証情報の追加をアラートし、長寿命のシークレットを期限切れにしていきましょう。そして、それらが保持する Graph API アプリケーション権限を監査してください。管理者同意済みの RoleManagement.ReadWrite.Directory（あるいは AppRoleAssignment.ReadWrite.All、Application.ReadWrite.All など）はテナント乗っ取りに等しく、短く、意図的に維持された許可リストに載せるべきものです。これらのいずれかの管理者同意付与そのものが、アラートすべき高シグナルなイベントです。まさにその権限を保持した漏洩 NHI が、今回の玄関口そのものだったのです。
3. プレーン間の橋を監視する。攻撃者が渡るのはそこであり、可視性がもっとも薄いのもそこだから。 アラートすべき高シグナル・低ノイズなイベント：
Microsoft.Authorization/elevateAccess/action――正当な使用はほぼゼロ。Entra→リソースの橋です。すべての発生でアラートしてください。- 特権ディレクトリロールの付与（グローバル管理者、特権ロール管理者、ユーザーアクセス管理者）。とくに付与先がサービスプリンシパルの場合。
vaults/accessPolicies/writeと Key Vault のroleAssignments/write、リソースローカルの自己付与。- ストレージや Event Hub などに対する
listKeys／SAS 発行。アイデンティティ付与がアイデンティティレスな鍵になるまさにその瞬間です。これがその鍵を見る唯一のチャンスです。これ以降は不可視になります。
4. アイデンティティレスなプレーンを飢えさせる。 可能な場所では、ストレージアカウントの共有鍵アクセスを無効化し、Entra ベース（RBAC）のデータプレーン認証を優先してください。そうすればアクセスは、実際にレビューし取り消せるアイデンティティに紐づいたままになります。排除した共有鍵ひとつひとつが、あなたのシングルペインオブグラスに戻ってくる一行です。
5. 露出する前にログを有効化する。デフォルトでは有効になっていない。 Azure のデフォルト設定は、まさにこの攻撃者が活動した場所であなたを静かに盲目にします。制御プレーンは記録されますが、必ずしもクエリやアラートができる場所に転送されるわけではありません。データプレーンと Graph プレーンは概ね無効です。以下を、あればうれしい機能ではなく、本番稼働の前提条件として扱ってください。
- アクティビティログと Entra 監査＋サインインログをワークスペースに転送する。 これらはデフォルトでポータル内に保持されますが、診断設定を作成するまではクエリ／アラートができません（サインインログには Entra P1 が必要）。ここに
elevateAccess、特権ロールの付与、listKeys呼び出しが存在します。 MicrosoftGraphActivityLogsを有効化する（テナント診断設定、P1）。これはデフォルトで無効であり、Graph プレーンの偵察やアプリ登録の改ざんを見られる唯一の場所です。今回のインシデントでは、攻撃の途中で流れ始め、権限昇格を完全に見逃しました。- ベアラー鍵を発行するリソース――ストレージ、Event Hubs、Key Vault――でデータプレーン診断を有効化する。 これらもすべてデフォルトで無効です。これらがなければ、盗まれた鍵のあらゆる使用は不可視です（プレーン4を参照）。今回唯一得られたデータプレーンのシグナル――Key Vault のシークレット読み取り――が存在したのは、そのログがポリシーによって明示的に義務づけられていたからにほかなりません。デフォルト状態では、それすら闇の中だったでしょう。
6. テレメトリを統合し、そのうえでプレーンではなくアイデンティティで相関させる。 AuditLogs、AzureActivity、リソース診断ログ、Microsoft Graph アクティビティログは、それぞれひとつの断片を保持しています。価値はそのどれか一つにあるのではなく、それらをひとつのアイデンティティ中心のタイムラインに縫い合わせることにあります。そうすれば「SP が自分に GA を付与 → ルート UAA へ昇格 → 所有者を割り当て → 鍵を収集」が、5つのテーブルに散らばった無関係な5行のログではなく、ひとつの権限昇格ストーリーとして読めるのです。これこそ、クラウド検知＆対応（CDR）とクラウドインフラストラクチャエンタイトルメント管理（CIEM）のツールが埋めるために存在するギャップそのものです。Azure が引き離しているプレーンをまたぐ、権限グラフとイベントストリームです。
プレーンをまたいで発火する Sysdig の検知
これを調査しにくくしている分断は、これを検知しにくくしているものと同じです。検知層がすべてのプレーンをひとつのストリームとして読まない限りは。Sysdig のエージェントレスなクラウド検知は、Entra 監査ログと Azure アクティビティログの両方を取り込み、単一のアイデンティティをキーとしたタイムラインに対して Falco ルールで評価します。この性質こそがすべての鍵です。elevateAccess イベント（Entra プレーンに存在）と listKeys による収集（アクティビティプレーンに存在）が、同じプリンシパルについて同じタイムラインに落ちてくるので、権限昇格が、2つのシステムにまたがる無関係な2行のログではなく、ひとつのストーリーとして読めるのです。
今回のインシデントの正確なキルチェーンを追いながら、攻撃者の各動きに対して発火する Sysdig の検知ルールを以下に示します。
| 攻撃者の動き | プレーン | Sysdig 検知ルール |
|---|---|---|
| SP が自分自身にグローバル管理者を付与 | Entra ディレクトリ | Entra Add Member to Administrative Role（ユーザーまたはサービスプリンシパルが管理者ロールに追加されると発火） |
| elevateAccess → ルートのユーザーアクセス管理者 | Entra↔RBAC の橋 | Entra Elevate Access to User Access Administrator at Root † |
| サブスクリプションスコープでの roleAssignments/write | Azure RBAC | Azure Create/Update a Role Assignment |
| storageAccounts/listKeys ×4 | ベアラー鍵の発行 | Azure Read the Access Keys for a Storage Account |
| Event Hub listKeys | ベアラー鍵の発行 | Azure Read the Keys for an Event Hub Namespace † |
| Key Vault accessPolicies/write の自己付与 | リソースローカルのポリシー | Azure Modify a Key Vault Access Policy † |
| Function App host/listKeys | ベアラー鍵の発行 | Azure Read the Host Keys for a Function App † |
もっとも価値の高いエントリは elevateAccess ルール（†）です。この動きは乗っ取り全体の要――「ディレクトリを所有」から「すべてのリソースを所有」へ渡る単一の呼び出し――であり、まさに別のプレーンのログ（アクティビティではなく Entra 監査）に隠れるものです。これを求めて Entra プレーンを監視しつつ、鍵の収集を求めてアクティビティプレーンも監視する検知は、2プレーンにわたる攻撃を、ひとつのアラート可能なチェーンへと畳み込みます。それが、ネイティブのコンソールでは得られないプレーン間相関です。
† を付けた4つの検知は、このインシデントが露呈させたギャップに直接対応して、私たちが Sysdig のオープンソース Falco ルールに貢献したものです。プレーン間の橋（elevateAccess）、リソースローカルの自己付与（Key Vault アクセスポリシー）、そして専用ルールがなかった2つのベアラー鍵発行（Event Hub ルート鍵と Function App ホスト鍵）です。これらは、上記のプレーン2・3・4に正確に対応する盲点を塞ぎます。中でもテレメトリパイプライン自身の鍵（Event Hub）の収集は、攻撃者が次にあなたの可視性を狙う手口であるため、もっとも大声でアラートする価値のあるものです。
まとめ
- 「誰がアクセス権を持っているか？」は、Azure では単一クエリで答えられる問いではない。 権限は少なくとも5つの分断されたシステム――Entra ディレクトリロール、Azure RBAC、リソースローカルのアクセスポリシー、アイデンティティレスなベアラー鍵、Graph API アプリケーション権限――に存在し、それらは識別子を共有せず、異なる場所にログを残し（あるいは異なる場所に現れ）ます。この乗っ取り全体を可能にしたのは Graph 権限であり、それはアプリ自身のロールペインからは不可視です。
- もっとも危険な動きはプレーン間のものである。
elevateAccessはディレクトリとリソースの制御を単一の呼び出しで橋渡しし、影響を及ぼすプレーンとは反対のプレーンにログを残します。橋を狩ってください。 - ベアラー鍵は恒久的な盲点である。 盗まれたストレージや Event Hub の鍵は、二度といかなる IAM ビューにも現れないアクセスを付与します。
listKeys呼び出しが、それを見られる唯一の瞬間です。アイデンティティベースのデータプレーン認証を優先し、共有鍵を無効化してください。 - NHI は柔らかい急所である。 1つの漏洩したサービスプリンシパルがドアを開けました。26個のバックドア化された NHI がそれを開けたままにし、それらはプレーンごとに認証情報を列挙することによってしか見つけられません。
- 継ぎ目をまたぐ可視性を構築する。 あなたの監視が Azure の権限プレーンの形をしているなら、その間を渡る攻撃者はあなたの視界の外へ渡っていきます。5つのプレーンすべてにわたって、アイデンティティで相関させてください。さもなければ、あなたが手にしているのはシングルペインオブグラスではなく、5枚のペインと大量の希望的観測です。
- 橋で検知する。 各要所の動きは、それ単体では高シグナル・低ノイズです。
elevateAccess、特権ロールの付与、Key Vault アクセスポリシーの自己付与、listKeys。レバレッジは、Entra とアクティビティのプレーンをひとつのアイデンティティタイムラインとして評価することから生まれ、そうすればプレーン間のチェーンがチェーンとしてアラートされます。Sysdig のセキュアクラウドルールは、上記チェーンのすべてのステップをカバーします。