.jpeg){kind=logo}
この記事では、すべての顧客テナント内でひっそりと稼働してきたAzureのIDタイプについて、その実態を探り、名称を付け、定義し、脅威モデルを構築していきます。このIDタイプは、これまで単一の名称で文書化されたことがなく、ユーザーが所有するものでもなく、ユーザーには完全には可視化されていませんでした。もしAzureチームの誰かが、これらのIDに関する正式な用語について正確な情報を提供したい場合は、DMで連絡をお待ちしています。
はじめに
セキュリティチームがAzureのマネージドIDについて考える際、頭に浮かぶのは、自らが作成するIDです。具体的には、仮想マシンにシステムによって割り当てられるIDや、App Serviceに紐付けられたユーザー割り当て型のマネージドIDなどです。これらは顧客が管理するものであり、作成、命名、ロールの割り当て、削除はすべてユーザー自身が行います。
しかし、ユーザーが作成しておらず、ポータル上では確認できず、制御することもできない別の種類のマネージド ID が存在します。これらは、Azure がユーザーに代わってプラットフォームを運用するために、自身で作成する ID です。
私はこれらを「プラットフォームレベル管理ID（PLMI）」と呼んでいます。
それらは何か
プラットフォームレベルのマネージド ID は、Azure によって管理される ID です。これらは、他のすべてのマネージド ID と同様に、同じトークン パス、同じメタデータ エンドポイント、同じ RBAC モデルを使用しますが、その所有権とライフサイクルは、私たちが慣れ親しんでいるシステム割り当て型マネージド ID やユーザー割り当て型マネージド ID とは根本的に異なります。
これらのIDは、Azureを構成するバックエンドサービスであるAzureリソースプロバイダーに割り当てられます。たとえば、API接続やロジックアプリをデプロイする場合、その裏側で動作し、ユーザーに代わってアクションを実行してサービスの機能を実現するのは、プラットフォームレベルのIDです。
命名の問題
これらの識別子について、一般向けに統一された呼称は存在しません。ただし、Microsoftのエコシステム全体にわたるドキュメントでは、これらがさまざまな名称で呼ばれてきました：
- プラットフォーム ID またはプラットフォーム MSI — Azure 自体が所有する ID を指す、社内で使用される包括的な呼称
- リソースプロバイダーの識別子 - 例：Microsoft.ApiManagement や Microsoft.Logic で使用される識別子
- 自社管理のID
- サービスIDまたはサービスMSI - Azureサービスで使用されるIDの総称
- 「バックエンドID」または「バックエンドプリンシパル」 - 社内ツールで見られる用語
- 内部管理対象ID（Internal MSI）
⚠️ これらが「何ではないか」について：プラットフォームレベルの管理対象IDは、ファーストパーティ・サービスプリンシパル（Microsoftファーストパーティ・アプリケーション、またはFPSPとも呼ばれる）と混同しないでください。FPSPとは、私が 『CSP管理型マシンIDの比較』 で解説しているIDです。これらはEntra ID内にエンタープライズアプリケーション（例：SharePoint Online、Microsoft Teams）として存在し、テナント内で確認できます。プラットフォームレベルの管理対象IDは、これとは全く別のカテゴリです。
Azureにお勤りで、これらを何と呼ぶべきかについて明確な答えをお持ちの方は、ぜひご連絡ください。
見分ける方法
プラットフォームレベルの管理対象IDは、お客様のテナントではなくMicrosoftのテナント内に存在するため、表示されるのは、プリンシパルがお客様のテナント外から来ていることを示すRBACログエントリのみです。以下のログエントリは、PLMIが動作している様子を示すAzureテナントから取得した例です（個人を特定できる情報は伏せてあります）。
An object ID that returns no result when you run az ad sp show --id <objectId> is a strong indicator that you are looking at a Platform-Level Managed Identity.
主な建築的特徴
このアーキテクチャの概要は以下の通りです：
- Microsoft 内部テナント：プラットフォームレベルの MI は、Microsoft 自身の内部テナント内に配置されています。
- 顧客テナント：顧客が下流のリソース（Key Vault、Storageなど）を保有しています。
- 顧客によるRBACの割り当て：重要な点として、AWSやGCPの同等の機能とは異なり、PLMIがリソースにアクセスすることを許可するRBAC権限は、顧客が自身のテナント内で割り当てるものです。
- テナント間のアクセス：PLMIは、顧客によって割り当てられたこれらの権限を使用して、テナントの境界を越えて操作を実行します。
これらを顧客管理型IDと区別する2つの特徴は次のとおりです：
- マルチテナント：特定のリソースプロバイダーに対して設定された単一のプラットフォームレベルのマネージド ID が、すべての顧客テナントにわたって運用に使用されます。これは顧客ごとのものではなく、グローバルな役割を果たします。
- CSPによる完全管理：ID自体はMicrosoftの環境内に存在します。お客様は、これを直接操作、制限、あるいは列挙することさえできません。
ここに根本的な矛盾があります。これらのIDは、極めて特権的なグローバルアクターなのです。これらはユーザーの環境外に存在するため、ユーザーがこれらに対して直接行使できる制御手段は、割り当てたRBAC権限に限られます。しかし後で見るように、こうした権限の割り当ては、通常、PaaSの機能を利用するために必要不可欠なものです。多くの場合、唯一の「オプトアウト」手段は、単にそのサービスを利用しないことだけです。
何が問題になるでしょうか？
上記のアーキテクチャは、特定の種類の脆弱性、すなわち「クロステナント・コンフューズド・デピュティ」を引き起こす。
「代理人の誤認攻撃」とは、複数のプリンシパルを代表して動作する強力な仲介者（サービスやプロセス）が、悪意のある攻撃者に騙され、自身の権限を利用して権限のない第三者のために操作を実行してしまう事態を指します。この仲介者がマルチテナント環境にある場合、その影響範囲は組織の境界を越えて広がることになります。
事例研究：バイナリー・セキュリティAPI接続に関する調査
2025年3月、Binary Securityの研究者らは、プラットフォームレベルのマネージドIDが「混同された代理人（confused deputy）」として悪用された事例について、これまでに公表された中で最も具体的な調査結果を発表した。
背景：API接続とは？
API 接続は Azure リソースであり、Logic App にアクションを追加すると、多くの場合自動的に作成されます。Key Vault からシークレットを取得するなど、Logic App が特定のアクションを実行するように構成すると、そのバックエンド サービスの認証コンテキストを格納する API 接続リソースがサブスクリプション内に作成されます。この API 接続が、Key Vault へのアクセス権限を保持し、使用する役割を担っています。
裏側では、そのAPI接続は、Microsoft.Webリソースプロバイダーに属するプラットフォームレベルのマネージドIDによって運用されています。Logic Appを設定したユーザーによって接続が承認された際、その承認には、バックエンドリソースにおけるこのプラットフォームレベルのIDに対するRBACの許可が必要でした。
脆弱性
Microsoft.Web PLMI に対して RBAC 権限を付与する必要性は妥当に見えたものの、Binary Security は APIM サービスの /extensions/proxy/{action} エンドポイントにパストラバーサル脆弱性を発見しました。この脆弱性により、サブスクリプションへの「Reader」アクセス権を持つ者であれば誰でも、そのデピュティを利用して、Microsoft.Web でアクセス設定が行われている限り、あらゆるテナントの Key Vault シークレット、SQL インスタンス、または外部接続を呼び出すことが可能となっていました。
攻撃者の手の届く範囲にあったもの：
バックエンドリソース
API接続プロキシ経由でアクセス可能
Azure Key Vault
すべてのシークレットを一覧表示する；シークレットの値を取得する
Azure SQL Database
データベース、データセット、テーブルを一覧表示する；テーブルの行を読み込む
Jira
プロジェクト、ユーザー、課題を一覧表示する；課題の内容を確認する
セールスフォース
アカウントデータ、連絡先レコード
Azure Defender ATP
アラート、インシデント、および調査データ
Azure Storage Blobs
ブロブの内容
Jiraの事例では、Binary SecurityはSSRFも発見しました。X-Request-Jirainstanceヘッダーの検証が行われていなかったため、攻撃者はリクエストを自身が制御するサーバーにリダイレクトし、接続情報に保存されていたJira APIトークンを盗み出すことが可能でした。
攻撃パターン
攻撃がどのように展開されるか、その概要は以下の通りです：
- 手順 1：攻撃者（被害者のサブスクリプションに対して「Reader」アクセス権のみを持つ）は、意図した API スコープを回避するために、パストラバーサル攻撃用のペイロード（「../../../」）を使用して、接続のプロキシエンドポイントに GET リクエストを送信します。
- ステップ 2: Azure Resource Manager (ARM) は、攻撃者に「Reader」アクセス権があるかどうかを確認します。これは GET リクエストであるため、ARM は「✅ はい - 処理を続行」と判定します。
- ステップ3：ARMは、バックエンドAPIを呼び出すために、その呼び出しをプラットフォームレベルのMIに転送します。
- ステップ 4: プラットフォームレベルの MI は、Key Vault に対する自身の RBAC 権限を確認します。接続の作成時にアクセス権が付与されていたため、処理を続行します。
- ステップ 5: プラットフォームレベルの MI が Key Vault から秘密鍵を取得し、それを ARM に返します。ARM はその秘密鍵を攻撃者に渡します。
なぜこれがテナント間の混乱を招く副官なのか
上記のフローは、これが「混乱した代理人（confused deputy）」として機能する様子を示していますが、この脆弱性の真の深刻さは、テナントを跨ぐ影響力にあります。PLMIはグローバルなアクターであるため、全く別のテナントにいる攻撃者が、公開されたプロキシエンドポイントを発見した場合、PLMIの権限を利用してテナントの境界を越えることが可能になります。 この「混乱した代理人」であるプラットフォームレベルの管理ID（PLMI）は、複数の顧客にわたって正当な権限を持っていました。しかし、別のテナントの権限のない当事者に代わってその権限を行使するよう騙されたため、単なるローカルな権限昇格にとどまらず、テナントをまたぐ問題となってしまいました。
それに対して、私たちは何をしているのでしょうか？
AWSでは、顧客がリソースポリシーに条件キーを追加して「コンフューズド・デピュティ攻撃」を制限する権限と責任の両方を有しているのに対し、Azureの顧客にはテナント間への影響を制御する手段がありません。ただし、PLMIに対するRBAC権限は自動的に割り当てられず、管理者が手動で割り当てる必要があるため、同一テナント内のコンフューズド・デピュティリスクについては制御が可能です。 しかし、批判的に考えてみると、（RBAC権限を割り当てないという形で）この制御機能を利用するためには、単にそのサービス機能を使用しないという選択を迫られることになる。これでは、果たしてどれほど有効な制御と言えるだろうか。さらに、真のテナント間リスクの軽減に対する責任は、完全にマイクロソフトに委ねられている。
これは、Google Cloud Service Agentsで見られるパターンと同様です。つまり、プロバイダーがIDを管理しているため、その利用に関するセキュリティの責任もプロバイダーが負わなければなりません。顧客側での制御機能がないのは、単にツールが不足しているからではなく、プロバイダーが自らのセキュリティ負担を背負っているからです。
緩和策 1：サービスレベル・パス強制（プロバイダー側）
特にAPI管理のケースにおいては、想定されていた緩和策として、API Connectionプロキシを通じて呼び出せるパスを制限するSwagger/OpenAPIドキュメントが採用されていました。プラットフォームIDは、Swaggerドキュメントで有効と宣言されたバックエンドパスに対してのみ呼び出しを行うようになっていました。
これは原則として妥当な対策である。誰が要求したかに関わらず、PLMIの対象となり得るアクションを制限する。
問題点：Binary Security社は、このSwaggerの検証機能にパストラバーサル攻撃の脆弱性があることを発見しました。攻撃者はパスを操作することで、宣言されたスコープを逸脱し、任意のバックエンドエンドポイントにアクセスすることが可能でした。マイクロソフトはこの問題を黙って修正しました。つまり、顧客は、必要だと知らされることもなく適用されたパッチによって、知らず知らずのうちに保護されていたのです。
より根本的な問題として、この種のパスレベルでの強制は、Azureのすべてのサービスに普遍的に適用できるものではありません。これは、APIMサービスがAPI接続リクエストを処理する方法に固有の制御機能です。プラットフォームレベルのマネージドIDを使用する他のリソースプロバイダーには、これと同等の制御機能はありません。
緩和策 2：接続確立時の RBAC 認証（顧客の責任）
2つ目の緩和策は、たとえ間接的であっても、顧客の管理下にあるものです。それは、API接続を作成する際の承認手順です。
Logic App 開発者が Key Vault への API 接続を作成する場合、その開発者（または適切なアクセス権を持つ者）が接続を承認する必要があります。この承認手順により、バックエンドリソース上のプラットフォームレベルのマネージド ID に対して RBAC グラントが付与されます。
このフローにおいて、これが唯一の重要なチェックポイントとなります：
この承認ゲートは重要ですが、マイクロソフトが考えているほどではありません。この緩和策（RBAC権限を割り当てないこと）を利用するには、実質的にそのサービスを利用しないことを選択することになります。 確かに、厳密な意味では、これは緩和策の一つです（脆弱なコードがあるなら、アプリを削除すればよい！）。しかし、これにのみ依存すると、PaaS機能を有効にするためにグローバルスコープのPLMIへのアクセス権限が付与された後、悪意のあるテナントがリソースにアクセスするのを防ぐための顧客側の制御手段が一切存在しなくなることになります。
緩和策 3：参照によるリンク（プロバイダー側）
Azure には、「参照によるリンク」制御として機能する追加のコントロールプレーンチェックが用意されています。この制御により、ARM デプロイ中に下流のリソースを参照する呼び出し元が、実際にそのリソースに対する同等の権限を保有していることを確認することで、PLMI の悪用をある程度軽減します。
たとえば、仮想マシン スケール セット (VMSS) を対象とする Azure Monitor オートスケール設定を作成しようとすると、ARM は、その VMSS に対して Microsoft.Compute/virtualMachineScaleSets/Write 権限を持っているかどうかを確認します。この権限がない場合、プラットフォーム ID が関与する前に、LinkedAuthorizationFailed エラーが発生し、デプロイは失敗します。
では、なぜこの緩和策がAPI Management/Logic Appsサービスには実装されていなかったのでしょうか？その理由は、「参照によるリンク」という制御が、通常、リソースのコントロールプレーンの作成または更新時にAzure Resource Manager（ARM）によって強制されるためです。 APIMの脆弱性は、ターゲットリソースのURIを動的に受け入れてリクエストを即座に転送するデータプレーンのプロキシランタイムエンドポイント（/extensions/proxy/{action}）に関連していました。このプロキシエンドポイントは、標準的なARMリソース作成フローの外で動作しており、転送先のパスに対するリンク済みリソースのチェックを独自に実装していなかったため、呼び出し元のターゲット側権限を検証することなく、プラットフォームIDが呼び出されてしまいました。
顧客向け操作機能の欠落
Azureの「プラットフォームレベルのマネージドID」において欠けている重要な制御機能は、テナント間の「コンフューズド・デピュティ」問題を防止するための、顧客側によるあらゆる形態の予防的制御です。AWSはリソースポリシーにおける条件付きキーによってこのような制御を実現しており、Google CloudはグローバルサービスIDを一切採用しないことでこの問題を軽減しています。 マイクロソフトが見落としているのは、高い権限を持つグローバルなアクターには、組織の境界を越えてリソースを悪用する能力が本質的に備わっているという点です。このようなシナリオにおいて、クラウドサービスプロバイダーは、予防的な制御手段を顧客の手に直接委ね、顧客との信頼関係を根本から損なうような悪用を確実に防止できるという安心感を提供しなければなりません。
この記事で紹介する調査は、 「Binary Security API Connections」の開示情報 （2025年3月）、および 『CSP管理型マシンIDの比較』ホワイトペーパー （Vectra AI、2025年10月）、およびRSA Conference 2026で発表された独自の調査に基づいています。
📣 Azureチームの皆様へ：Platform-Level Managed Identitiesに関する公式ドキュメント（正規の命名規則やポリシーの適用範囲など）をご存知でしたら、ぜひご教示ください。もし私の認識が間違っている場合は、ぜひご指摘いただければ幸いです。