単一の管理画面など存在しない――Azure権限乗っ取りの解剖

発端――一つの認証情報、多くの手

侵入口は地味で、極めてありふれたものでした。漏洩したサービスプリンシパルのクライアントシークレットです。サービスプリンシパルはAzureにおける非人間ID(NHI)であり、アプリやオートメーション、CI/CDパイプラインが認証に使うアカウントです。Sysdig 2026年版クラウドネイティブセキュリティ・利用状況レポートによれば、Azureのサービスプリンシパルのうち38%強がリスクありと見なされています。つまり、長期間有効なシークレットや証明書を保持していたり、過剰な権限を持っていたり、あるいはこうしたIDが地球の裏側からログインしても誰にもプッシュ通知が届かなかったりする、ということです。

この特定のシークレットは、攻撃者に発見されるまで約2週間にわたり露出していました。その間、シークレットは商用VPN、Torの出口ノード、米国・ドイツ・スウェーデン・香港・オランダに点在する小規模ホスティングプロバイダーなど、次々と入れ替わる匿名化インフラから再利用されていました。この出所の多様性そのものが一つの発見です。これは追跡可能な単一の人物の仕業ではなく、何らかの共有プールまたは自動化されたプールに置かれた認証情報が、複数の独立した便乗的な利用者によって拾われ、再利用されていたことを示しています。そのほとんどは偵察活動しか行っていませんでした。ARMを列挙し、Graphを探り、ストレージやKey Vaultを一覧表示する程度です。

そして、あるセッションが偵察をやめ、権限昇格を開始しました。

Sysdig TRTが観測した内容

以下の時刻はすべてUTCです。以下の各操作はすべて成功として返されています。

本当の問題――決して交わらない5つの権限プレーン

そしてNHIの氾濫という問題

フェーズ1でさらりと触れた一文に立ち戻りましょう。攻撃者は26個のアプリケーション登録にシークレットを埋め込みました。

これは永続化であり、しかもまさに私たちがここまで説明してきた断片化を前提に設計されたものです。各アプリケーション登録は、独自の認証情報リストと(しばしば忘れ去られた)独自の権限フットプリントを持つ、独立した非人間IDです。GA付与を削除しても、これらには何の影響もありません。漏洩した元のシークレットをローテーションしても同様です。それぞれが、別個の有効な再侵入経路なのです。

そして、「自分のテナント内のすべてのアプリケーション登録上のすべての認証情報」を一覧表示するAzureの単一のビューは存在しません。26個すべてを見つけるには、アプリケーション登録を列挙し、そのpasswordCredentialsを一つずつ調べるか、たまたま監査ログを取得していた場合はそこから再構築するしかありません。永続化の被害範囲そのものが、大半のIDダッシュボードが後回しにしているプレーン(アプリ/SPの認証情報)を力任せに列挙することでしか把握できないのです。

Sysdig 2026年版クラウドネイティブセキュリティ・利用状況レポートによれば、NHIはクラウド環境内で管理されているIDの約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ネイティブの画面は存在しません。

1. このプリンシパルが到達できるものすべてを見せてほしい――ディレクトリロール、あらゆるスコープでのRBAC、リソースローカルのポリシー、そして発行済みのベアラーキーを含めて。
2. このリソースに到達できるものすべてを見せてほしい――アクセスポリシーのエントリ、RBACの割り当て、そしてそれに紐づいてどこかに漂っているIDを持たない鍵を含めて。

これらの問いは5つのプレーンすべてにまたがっており、そのプレーン間には共有の結合キーがありません。サービスプリンシパルのオブジェクトID、RBAC割り当てのスコープパス、Key Vaultアクセスポリシーのエントリ、ストレージアカウントのキーは、突き合わせる共通点をほとんど持ちません。この断片化はAzureのUIだけの話ではなく、私たちの大半がAzureをどう監視するかにも波及しています。なぜなら、私たちは与えられたプレーンの形状に沿って検知の仕組みを構築してしまうからです。

今回の調査を救った唯一の要素は、地味なものでした。私たちはコントロールプレーンのログを、攻撃者が手を出せない、変更不可能なテナント外のストレージに取得していたのです。攻撃者はテレメトリパイプラインのEvent Hubルートキーを握っており、稼働中のワークスペースを盲目化したり汚染したりすることもできました。しかし恒久保存されたコピーは彼らの被害範囲の外にあったため、全体の連鎖を完全に再構築することができました。証跡の耐久性は、攻撃者が支配するプレーンから独立していなければなりません。これが教訓のゼロ番目であり、このブログ記事が書かれた唯一の理由です。

これにどう対処すべきか

Azureの権限モデル自体を直すことはできませんが、それに驚かされない状態を作ることはできます。具体的には以下の通りです。

1. 5つのプレーンすべてを一つの資産として棚卸しする。 EntraロールとAzure RBACだけをカバーするアクセスレビューは、リソースローカルのポリシー(Key Vaultなど)、ベアラーキー、Graph APIアプリケーション権限を完全に見落としています。これら5つすべてを一つの権限グラフの一部として扱ってください。攻撃者にとってはまさにそうなのですから。

2. NHIをファーストクラスのIDとして扱い、そのGraph権限も含めて監視する。 サービスプリンシパルとその認証情報は、ユーザーアカウントと同等の精査が必要です。すべてのアプリケーション登録のシークレット/証明書を棚卸しし、認証情報の追加にアラートを設定し、長期間有効なシークレットを期限切れにしてください。そして、それらが保持しているGraph APIアプリケーション権限を監査してください。管理者が同意したRoleManagement.ReadWrite.Directory(あるいはAppRoleAssignment.ReadWrite.All、Application.ReadWrite.Allなど)は実質的にテナント乗っ取りに等しく、短く意図的に管理された許可リストに載せるべきものです。これらのいずれかに対する管理者同意の付与そのものが、アラートを設定すべき高シグナルのイベントです。まさにその権限を保持していた漏洩NHIこそが、今回の事案全体の玄関口だったのです。

3. プレーン間の橋渡しを監視する。攻撃者が渡り歩くのはそこであり、可視性が最も薄い場所だからです。 アラートを設定すべき、高シグナルかつ低ノイズなイベントは以下の通りです。

• Microsoft.Authorization/elevateAccess/action ― 正当な利用はほぼゼロで、Entra→リソースの橋渡しです。発生するたびにアラートを出してください。
• 特権的なディレクトリロールの付与(グローバル管理者、特権ロール管理者、User Access Administrator)、特に付与先がサービスプリンシパルである場合。
• vaults/accessPolicies/writeとKey VaultのroleAssignments/write、つまりリソースローカルの自己付与。
• ストレージ、Event HubなどでのlistKeys／SAS発行――ID紐づきの権限付与がIDを持たない鍵へと変わる瞬間です。この鍵を見られる唯一のチャンスであり、これを過ぎれば不可視になります。

4. IDを持たないプレーンを干上がらせる。 可能な場所では、ストレージアカウントの共有キーアクセスを無効にし、Entraベース(RBAC)のデータプレーン認証を優先してください。そうすればアクセスは、実際にレビューし取り消すことのできるIDに紐づいたままになります。排除する共有キー一つひとつが、単一の管理画面に戻ってくる行になります。

5. 露出する前にロギングをオンにする。デフォルトではオンになっていません。 Azureのデフォルト設定は、まさに今回の攻撃者が活動した場所であなたを静かに盲目にします。コントロールプレーンは記録されますが、必ずしもクエリやアラートを設定できる場所にルーティングされているとは限りません。データプレーンとGraphプレーンはほぼオフのままです。以下は「あれば良いもの」ではなく、稼働開始前の必須要件として扱ってください。

• アクティビティログとEntraの監査・サインインログをワークスペースにルーティングする。 これらはデフォルトでポータル内に保持されますが、診断設定を作成するまではクエリやアラートの対象にはなりません(サインインログにはEntra P1が必要です)。ここにelevateAccess、特権ロールの付与、listKeys呼び出しが記録されています。
• MicrosoftGraphActivityLogsを有効化する(テナント診断設定、P1)。これはデフォルトでオフになっており、Graphプレーンでの偵察やアプリ登録の改ざんを確認できる唯一の場所です。この事案では、途中からしかログが流れ始めておらず、権限昇格を完全に見逃していました。
• ベアラーキーを発行するリソースでデータプレーン診断を有効化する: ストレージ、Event Hubs、Key Vaultです。これらもすべてデフォルトでオフです。これがなければ、盗まれた鍵のあらゆる使用は不可視になります(プレーン4を参照)。今回、実際に得られたデータプレーンのシグナル――Key Vaultのシークレット読み取り――は、そのロギングがポリシーによって明示的に義務付けられていたからこそ存在していたにすぎません。標準設定のままなら、それすら暗闇の中だったでしょう。

6. テレメトリを統合し、プレーンごとではなくIDごとに相関させる。 AuditLogs、AzureActivity、リソース診断ログ、Microsoft Graphアクティビティログは、それぞれが一つの断片を保持しているだけです。価値があるのはそのどれか一つの中にではなく、それらを一つのID中心のタイムラインに縫い合わせることにあります。そうすれば「SPが自分自身にGAを付与 → ルートUAAに昇格 → Ownerを割り当て → 鍵を収集」という流れが、5つの表に散らばった5つの無関係なログ行としてではなく、一つの権限昇格ストーリーとして読み取れるようになります。これはまさに、クラウド検知・対応(CDR)やクラウドインフラ権限管理(CIEM)ツールが埋めようとしているギャップそのものです。Azureが分離したままにしているプレーンをまたぐ権限グラフとイベントストリームを提供するのです。

プレーンをまたいで発火するSysdigの検知

調査を難しくしているこの断片化は、検知を難しくしている原因でもあります。検知レイヤーがすべてのプレーンを一つのストリームとして読み取らない限りは。Sysdigのエージェントレス・クラウド検知は、Entra監査ログとAzureアクティビティログの両方を取り込み、単一のID起点のタイムラインに対してFalcoルールを評価します。この特性こそがすべてなのです。elevateAccessイベント(Entraプレーンに存在)とlistKeysによる鍵収集(Activityプレーンに存在)が、同一のプリンシパルに対する同一のタイムライン上に着地するため、権限昇格は、2つのシステムの2つの無関係なログ行としてではなく、一つのストーリーとして読み取れるようになります。

今回の事案の正確なキルチェーンをたどると、攻撃者の各動きに対して発火するSysdigの検知ルールは以下の通りです。

‍

最も価値の高いエントリはelevateAccessルール(†)です。この動きこそが今回の乗っ取り全体の要でした。「ディレクトリを支配する」から「すべてのリソースを支配する」へと渡った、まさにその単一の呼び出しであり、それはまさに別のプレーンのログ(Activityではなく、Entra監査)に隠れているものなのです。Entraプレーンでこれを監視すると同時に、Activityプレーンで鍵の収集を監視する検知があれば、2つのプレーンにまたがる攻撃を、一つのアラート可能な連鎖として一つにまとめ直すことができます。これがまさに、ネイティブのコンソールでは得られないプレーン横断の相関分析です。

†印が付いた4つの検知は、今回の事案が露呈させたギャップに直接対応する形で、私たちがSysdigのオープンソースFalcoルールに寄与したものです。プレーン間の橋渡し(elevateAccess)、リソースローカルの自己付与(Key Vaultアクセスポリシー)、そして専用ルールが存在していなかった2つのベアラーキー発行(Event Hubルートキーと Function Appホストキー)です。これらは上述のプレーン2、3、4に正確に対応する盲点を塞ぐものであり、中でもテレメトリパイプライン自身の鍵(Event Hub)の収集は、攻撃者が次にあなたの可視性そのものを狙ってくる手口だけに、最も大声でアラートを出す価値があります。

まとめ

• 「誰がアクセス権を持っているか」はAzureにおいて一発のクエリで答えられる問いではありません。 権限は少なくとも5つのバラバラなシステム――Entraディレクトリロール、Azure RBAC、リソースローカルのアクセスポリシー、IDを持たないベアラーキー、Graph APIアプリケーション権限――に存在しており、これらは識別子を共有せず、異なる場所にログを記録します(あるいは表示されます)。今回の乗っ取り全体を可能にしたのはGraph権限であり、それはアプリ自身のロールペインからは見えません。
• 最も危険な動きは、プレーンをまたぐものです。 elevateAccessは単一の呼び出しでディレクトリとリソースの制御を橋渡しし、影響を与えるのとは反対側のプレーンに記録されます。橋渡しを探してください。
• ベアラーキーは恒久的な盲点です。 盗まれたストレージやEvent Hubの鍵は、それ以降二度とどのIAMビューにも現れないアクセス権を与えます。listKeys呼び出しこそが、それを見られる唯一の瞬間です。IDベースのデータプレーン認証を優先し、共有キーを無効化してください。
• NHIは柔らかい急所です。 1つの漏洩したサービスプリンシパルが扉を開き、26個のバックドア化されたIDがそれを開けたままにしていました。それらを見つけるには、プレーンごとに認証情報を列挙するしかありません。
• 継ぎ目をまたぐ可視性を構築してください。 監視の仕組みがAzureの権限プレーンの形状に沿ったものであれば、それらの間を渡り歩く攻撃者は、あなたの視界の外に出てしまいます。5つのプレーンすべてにわたってIDで相関させてください。さもなければ、あなたが持っているのは単一の管理画面ではなく、5枚のパネルと多くの希望的観測にすぎません。
• 橋渡しの場所で検知してください。 重要な動きはそれぞれ単独でも高シグナル・低ノイズです。elevateAccess、特権ロールの付与、Key Vaultアクセスポリシーの自己付与、listKeys。真の効果は、EntraプレーンとActivityプレーンを一つのIDタイムラインとして評価することから生まれます。そうすればプレーンをまたぐ連鎖は、連鎖としてアラートされます。Sysdigのセキュアクラウドルールは、上記の連鎖のすべてのステップをカバーしています。