エージェントID管理者のスコープの逸脱: サービスプリンシパルの乗っ取り Entra ID

TL; DR

その Microsoft エージェントIDプラットフォーム (プレビュー）は、AIエージェントに独自のIDを与えます Entra ID （設計図、エージェント ID、エージェントユーザー）を管理し、他のプリンシパルと同様に保護します。この新しいコントロールプレーンを管理するために、Microsoft は エージェントID管理者 役割。建前上は、エージェント関連のオブジェクトのみに範囲が限定されている。

私たちは、アカウントがのエージェントID管理者ロールは 引き継ぐ エージェントのIDとは全く関係のないものも含め、任意のサービスプリンシパルを所有者として取得し、資格情報を追加してそのプリンシパルとして認証する。 それは完全なサービスによる主要買収です特権的なサービス提供者が存在するテナントでは、 特権昇格 パス。

エージェントID管理者ロールはまだ広く利用されていませんが、ほとんどのテナントには少なくとも1つの特権サービスプリンシパルが存在します。また、多くのテナントが既にエージェントIDを使用しており、場合によっては大規模な利用が行われていることも確認されています。エージェントID管理者ロールの導入が進むにつれて、このスコープのギャップは重大なIDセキュリティリスクとなる可能性があります。

私たちはこの行動をマイクロソフトセキュリティレスポンスセンター (MSRC) に報告し、 あらゆる雲の中で固定されていたエージェントID管理者ロールでは、エージェント以外のサービスプリンシパルの所有者を管理できなくなりました。

上記の概念を既に理解している場合は、次の項目に進んでください。 境界線が破れる場所.

以下の分析は、当社の包括的な調査結果に基づいています。

あなたが知っておくべきこと

アプリケーションとサービス原則 Entra ID

Microsoftへのアプリケーションの登録 Entra ID 関連するオブジェクトを 2 つ作成します 住宅賃借人アプリが最初に登録されたテナントは、 アプリケーションオブジェクト と メインサービス.

そのオブジェクトはアプリのグローバル定義として機能し、その構成を記述します。
その サービス責任者 アプリケーションはテナント内の ID として表現され、認証、役割と権限の割り当て、リソースへのアクセスを行うオブジェクトです。アプリケーションが次のように構成されている場合 マルチテナントアプリが他のテナントで使用される場合、同じアプリケーションオブジェクトに基づいて、追加のサービスプリンシパルが他のテナントにも作成されます。

Microsoft Entra ID さまざまなタイプのサービス原則があります。 アプリケーションサービス 校長先生と 管理されたID。 An アプリケーションサービスプリンシパル これは、アプリケーションオブジェクトから作成された、テナント内のアプリケーションのインスタンスです。

このブログでは、ここで説明する動作がアプリケーションサービスプリンシパルに特有のものであるため、このタイプのみに焦点を当てます。

Microsoft エージェントIDを入力

Microsoft エージェントIDを入力 AIエージェントを第一級のアイデンティティとして扱うことができます Entra IDつまり、テナント内の AI エージェントに対する条件付きアクセス、ガバナンス、ライフサイクル管理を意味します。内部的には、 MicrosoftエージェントIDプラットフォームAIエージェント向けのIDおよび認証フレームワークです。いくつかの新しいオブジェクトタイプ（ブループリント、エージェントID、エージェントユーザー）が導入され、これらはすべてMicrosoft Graph（現在はベータ版APIのみ）を介して管理できます。プラットフォームはまだプレビュー段階ですが、役割は既に公開されており、割り当てて使用できます。

要するに、このプラットフォームは以下の機能を提供します。

設計図 エージェントのIDを定義および作成するテンプレート。
設計図の原則: テナントに追加された際の、テナント固有のブループリントのインスタンス。
エージェントのIDAIエージェントがAPIやサービスへの認証に使用する特別なサービスプリンシパル。
エージェントユーザーこれらは、UPNまたはメールアドレスを必要とするエージェント向けのオプションのユーザーライクオブジェクトであり、代理認証フローで使用されます。

なぜこれが重要なのか： エージェントのIDは、アプリケーション、サービスプリンシパル、ユーザーといった、おなじみのディレクトリの基本要素に基づいて構築されています。まさにこの共通基盤こそが、今回の発見の核心なのです。

エージェントID管理者ロール

マイクロソフトはエージェントID管理者新しいエージェントID制御プレーンを管理する役割。ドキュメントによると、それはだ対象範囲:

言い換えると： エージェント関連のみただし、すべてのサービスプリンシパルがそうとは限りません。この区別は重要です。サービスプリンシパルは、自動化、CI/CD、セキュリティツール、特権統合の背後にあるIDです。これらを制御する者は、環境の大部分を制御することになります。

もう一つ気づいたことがあります: ドキュメントによると、この役割は 特権を持つしかし、EntraのUI（ベータ版のディレクトリロール定義に基づいている）では、そのように表示されません。そのため、管理者は特権ロールに与えるような厳密な審査を行わずに、このロールを割り当ててしまう可能性があります。

Microsoftは、Entra UIとドキュメントの間の不一致を確認した。に対する「特権」指標 修正されます.

境界線が破れる場所

確認された内容は以下のとおりです。エージェントID管理者ロールを割り当てられたユーザーは、エージェント関連のIDだけでなく、テナント内の任意のサービスプリンシパルを含む、サービスプリンシパルの所有者として自身を追加できます。そこから、資格情報を追加し、それらのアプリケーションとして認証を行うことができます。

ステップ1：追加所有者 （非代理人サービス提供者に対して成功しました。ご自身または他の提供者を追加できます。）

ステップ2：認証情報を追加する （私たちがオーナーになってから初めて機能しました）：

結論： 所有権とは 乗っ取り原始 所有者になり、秘密鍵を追加して、そのサービスプリンシパルとして認証します。

この役割は エージェント 実際には、アイデンティティの所有権が変わる可能性があります どれか サービス責任者。

なぜこのようなことが起こるのか、その理由として考えられること： エージェントIDの一部は、サービスプリンシパル（および関連するタイプ）として実装されています。この役割には、次のようなアクションがあります。

microsoft.directory/agentIdentities/owners/update
microsoft.directory/agentIdentityBlueprintPrincipals/owners/update

つまり、管理者はエージェントオブジェクトの所有者を管理できます。これらのチェックがエージェントを基盤とするサービスプリンシパルに厳密に限定されていない場合、権限が一般的なサービスプリンシパルの領域に漏洩してしまいます。
典型的なスコープ設定のギャップ あるオブジェクト型が別のオブジェクト型を継承する場合。

私たちでした同じものを参照アプリケーションリソースの所有者として自身を追加することが拒否されました。したがって、この問題はサービスプリンシパルのサーフェスに特有のものと思われます。

この修正後、エージェントID管理者ロールを使用して非エージェントサービスプリンシパルの所有権を割り当てようとすると、ブロックされるようになりました。この操作を実行すると、次のエラーが発生します。

影響

サービスプリンシパルの買収

サービスプリンシパルの所有権を取得することは、攻撃経路における強力な足がかりとなります。攻撃者が所有者になると、認証情報を追加したり、サービスプリンシパルとして認証したり、APIアクセス、ディレクトリロール、統合などの既存の権限の範囲内で操作したりすることが可能になります。

影響は、対象となるサービスプリンシパルに割り当てられている権限によって異なります。サービスプリンシパルが広く使用されている環境や、高い権限を持つ環境では、重大な権限昇格につながる可能性があります。テナントの姿勢も影響を及ぼし、例えば、広範な同意を得たアプリケーションや、許可度の高い構成の場合などが挙げられます。

修正前は、エージェントID管理者ロールでは、エージェント関連のID以外のサービスプリンシパルに対する所有権を割り当てることが可能であり、アプリケーション管理者などのロールと同様の機能を実質的に実現していましたが、エージェントの使用事例に特化したものではありませんでした。

対象が特権を持っている場合

エスカレーションの角度は単純だ。 if サービスプリンシパルは高い権限（ディレクトリロール、影響力の大きいGraph権限など）を持っており、それを引き継ぐことでこれらの権限を取得できます。多くの組織がこのようなサービスプリンシパルを保有しています。

どのサービスプリンシパルが特権を持っているかを特定し、それらをターゲットにすることができます。実際には、これは2種類のチェックを意味します。

特権ディレクトリロールを持つサービスプリンシパル: Microsoft Graph API (ベータ版、 isPrivileged 役割定義に基づいて、どのサービスプリンシパルが管理者レベルのディレクトリロールを保持しているかを一覧表示します。
影響力の大きいGraph権限を持つサービスプリンシパル: 機密性の高いアクセス許可について、Microsoft Graph へのアプリロール割り当てを照会します (例: Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Application.ReadWrite.All).

特権サービスプリンシパルを列挙する

次の操作を実行してください az login。必要です jq役割割り当てとアプリの役割割り当てを読み取ることができるアカウント（例：エージェントID管理者）を使用してください。

1. 特権ディレクトリロールを持つサービスプリンシパル

BASE="https://graph.microsoft.com"
roles="$(az rest -m GET --url "${BASE}/beta/roleManagement/directory/roleDefinitions?\$filter=isPrivileged eq true&\$select=id,displayName" -o json)"
u="${BASE}/beta/roleManagement/directory/roleAssignments?\$expand=principal(\$select=id,displayName)&\$top=999"
{
  echo -e "SP_NAME\tSP_ID\tROLE"
  echo -e "--------\t------\t----"
  while :; do
    j="$(az rest -m GET --url "$u" -o json 2>/dev/null)" || break
    jq -r --argjson roles "$roles" '
      ($roles.value | map(select(.displayName|test("Reader";"i")|not) | {key:.id, value:.displayName}) | from_entries) as $r
      | .value[]
      | select(.principal."@odata.type"=="#microsoft.graph.servicePrincipal")
      | select($r[.roleDefinitionId] != null)
      | [.principal.displayName, (.principal.id // .principalId), $r[.roleDefinitionId]] | @tsv
    ' <<<"$j"
    u="$(jq -r '."@odata.nextLink"//empty' <<<"$j")"
    [[ -z "$u" ]] && break
  done | sort -t$'\t' -k1,1
} | column -t -s $'\t'

2. Graphアプリの権限が大きな影響を与えるサービスプリンシパル

BASE="https://graph.microsoft.com"
PERM_IDS='["9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8","06b708a9-e830-4db3-a914-8e69da51d44f","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9","19dbc75e-c2e2-444c-a770-ec69d8559fc7","dd199f4a-f148-40a4-a2ec-f0069cc799ec","50483e42-d915-4231-9639-7fdb7fd190e5","01c0a623-fc9b-48e9-b794-0756f8e8f067","62a82d76-70ea-41e2-9197-370581804d09","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7"]'
PERM_NAMES='{"9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8":"RoleManagement.ReadWrite.Directory","06b708a9-e830-4db3-a914-8e69da51d44f":"AppRoleAssignment.ReadWrite.All","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9":"Application.ReadWrite.All","19dbc75e-c2e2-444c-a770-ec69d8559fc7":"Directory.ReadWrite.All","dd199f4a-f148-40a4-a2ec-f0069cc799ec":"RoleAssignmentSchedule.ReadWrite.Directory","50483e42-d915-4231-9639-7fdb7fd190e5":"UserAuthenticationMethod.ReadWrite.All","01c0a623-fc9b-48e9-b794-0756f8e8f067":"Policy.ReadWrite.ConditionalAccess","62a82d76-70ea-41e2-9197-370581804d09":"Group.ReadWrite.All","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7":"User-PasswordProfile.ReadWrite.All"}'
GRAPH_SP_ID="00000003-0000-0000-c000-000000000000"
az rest --method GET --url "${BASE}/v1.0/servicePrincipals(appId='${GRAPH_SP_ID}')/appRoleAssignedTo" -o json 2>/dev/null \
  | jq -r --argjson ids "$PERM_IDS" --argjson names "$PERM_NAMES" '
    ["SP_NAME", "SP_ID", "PERMISSIONS"], ["--------", "------", "-------------"],
    ([.value[] | select(.appRoleId as $rid | $ids | index($rid))] | group_by(.principalId)[] |
      [.[0].principalDisplayName, .[0].principalId, ([.[].appRoleId | $names[.]] | join(", "))]) | @tsv
  ' | column -t -s $'\t'

注意： これらの手法は、エージェント以外のサービス提供者を特にフィルタリングするものではありません。

エンドツーエンドの攻撃フロー

下の図は引っ張る列挙（上記のスクリプト） 乗っ取り 単一のビューに統合する。

デモ録音

この動画では、特権を持つサービスプリンシパルを見つけ（デモではディレクトリロールのみを検索）、それを乗っ取り、サインインするという流れを示しています。

デモ: テストユーザー エージェントID管理者 特権を奪う 非エージェント サービスプリンシパル（グローバル管理者ロールが割り当てられている）が新しい認証情報でサインインすると、権限昇格が行われます。

デモは シミュレーションした グラフベータ API; 私たちは 確認済み バグの挙動は同じです v1.0.

現実世界のスナップショット

顧客環境を調査しました。 エージェントID管理者 この役割はまだ広く使われていませんが、エスカレーションパスの設定は既に行われています。 テナントの約99％ 少なくとも1つの特権サービスプリンシパル（必ずしもエージェント関連である必要はない）を持つこと。 半分強 エージェントIDを使用する組織は多く、そのうちほぼ半数が100を超えるIDを保有している。エージェントIDの管理を担当する役割を割り当てる組織が増えるにつれ、スコープのギャップは深刻なリスクとなる。

主なポイント

マイクロソフトはこの問題に対処しましたが、重要な点は変わりません。新しいIDタイプは既存の基本要素の上に構築されることが多く、ロール権限の範囲設定に抜け穴が生じる可能性があります。今回のケースでは、意図したよりも広いアクセス権限が付与されてしまいました。これらの前提を検証することが不可欠です。さらに、全体的なリスクはテナントの姿勢、特に特権サービスプリンシパルの挙動によって左右されます。特権サービスプリンシパルでは、所有権の悪用が依然としてよく知られた、影響力の大きい攻撃経路となっています。

なぜこれが見落とされやすかったのか

サービスプリンシパルの所有権の変更は、誰がその操作を実行したかと対象のサービスプリンシパルの種類を関連付けない限り、通常のアプリケーション管理者の活動のように見えることがあります。
Entraのユーザーインターフェースで明確に高い権限を持つとマークされていない役割は、より緩やかな審査で割り当てられる可能性があります。
役割が想定される範囲外で動作していることを示す組み込みのシグナルはありません。そのため、役割の活動と影響を受けるリソースを関連付ける必要があります。

クライアントの声

機密性の高い役割の使用状況を監視する特に、サービス提供者の所有権や認証情報の変更に関わる行為。
サービス提供者の所有権変更に関するアラートこれらはEntraアプリのガバナンスにおいて、最もシグナル強度の高いイベントの一部です。
特権的なサービス責任者は至宝として扱う: ディレクトリロールまたは影響力の大きいGraph権限を持つサービスプリンシパルを監査し、それらを保護および監視します。
サービスプリンシパルに対する監査認証情報の作成: 価値の高いサービスプリンシパルに関する新しい秘密情報や証明書は稀であるべきであり、定期的に見直されるべきである。

検出

お願いこれらの検出機能は、前述の問題に対応するために作成されたものですが、既に修正されているため、同様のパターンを特定するためのテンプレートとして使用できます。

エージェントID管理者に割り当てられたアカウント

Azure CLI 経由: 現在の課題を取得する:

# Role definition ID for Agent ID Administrator
     az rest --method GET \
       --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=roleDefinitionId eq 'db506228-d27e-4b7d-95e5-295956d6615f'" \
       --query "value[].principalId" -o tsv

ログ分析（AuditLogs）経由エージェントID管理者ロールの役割割り当てアクティビティを照会します（必要に応じてテーブルと時間範囲を調整してください）。

AuditLogs
| where OperationName has "Add member to role"
| where tostring(TargetResources) has "db506228-d27e-4b7d-95e5-295956d6615f" //
Agent ID Administrator
| mv-expand TR = TargetResources
| summarize
    Role = max(iff(TR.type == "Role", tostring(TR.displayName), "")),
    Assignee = max(iff(TR.type != "Role", tostring(TR.displayName), "")),
    AssigneeUPN = max(iff(TR.type != "Role", tostring(TR.userPrincipalName),"")),
    AssigneeId = max(iff(TR.type != "Role", tostring(TR.id), ""))
by TimeGenerated,
   Result,
   Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName),
                    tostring(InitiatedBy.app.displayName))
| order by TimeGenerated desc

アクティビティ（ログ分析／監査ログ）

サービスプリンシパルに所有者を追加する：成功したイベント。必要に応じて時間範囲を調整してください。

let AgentIdAdminActors = dynamic(["obj-id1","obj-id2"]);  // principals assigned
Agent ID Administrator
AuditLogs
| where OperationName == "Add owner to service principal"
| where Result == "success"
| where coalesce(InitiatedBy.user.id, InitiatedBy.app.id) in (AgentIdAdminActors)
| order by TimeGenerated desc

サービスプリンシパルに資格情報を追加する成功したイベント。

AuditLogs
| where OperationName == "Add service principal credentials"
| where Result == "success"
| project
    TimeGenerated,
    OperationName,
    Result,
    Actor = coalesce(InitiatedBy.user.userPrincipalName,
                     InitiatedBy.app.displayName),
    TargetSP = TargetResources[0].displayName,
    TargetSPId = TargetResources[0].id
| order by TimeGenerated desc

情報開示のタイムライン

2026年2月24日 – 脆弱性が特定されました
2026年3月1日 – マイクロソフト（MSRC）に報告書を提出
2026年3月3日 – マイクロソフトが訴訟を提起
2026年3月26日 – マイクロソフトはこの動作を確認した
2026年4月4日 – 修正版がリリース前段階に達し、この動作は再現しなくなりました。
2026年4月9日 – MSRCは修正プログラムが完全に展開されたことを確認しました。

マイクロソフトはこの問題を認識し、情報開示プログラムの一環としてバグ報奨金を支給した。

終わりの思考

エージェントのID これらは、AIエージェント時代に向けて構築された、非人間型アイデンティティへの広範な移行の一環です。Microsoft Agent Identity Platformは、組織がこれらのアイデンティティを管理・統制する方法において、大きな前進となります。

この研究は、そのモデルの重要な側面を浮き彫りにしています。エージェントのアイデンティティは、サービスプリンシパルなどの既存のアイデンティティコンポーネントに依存しています。厳密なスコープ設定なしに共有基盤の上にロール権限を適用すると、アクセス範囲が当初の意図を超えて拡大する可能性があります。このケースでは、そのギャップが、特に特権を持つサービスプリンシパルが関与している場合に、より広範なアクセスにつながりました。

マイクロソフトはこの問題に対処しましたしかし、これはより広範な教訓を改めて強調するものである。特に共有IDコンポーネントを扱う場合、役割の範囲と権限の適用範囲を検証することが不可欠である。

環境の監視と強化に関する実践的なガイダンスについては、以下を参照してください。 クライアントの声 下 主なポイント 上記のセクション。