에이전트 ID 관리자 권한 초과: 서비스 주체 탈취 Entra ID

TL; DR

The Microsoft 에이전트 신원 플랫폼 (미리보기)는 AI 에이전트에게 고유한 정체성을 부여합니다. Entra ID (설계도, 에이전트 ID, 에이전트 사용자)를 관리하고 보호할 수 있으므로 다른 주체와 마찬가지로 관리할 수 있습니다. 이러한 새로운 제어 평면을 관리하기 위해 Microsoft는 새로운 제어 평면을 도입했습니다. 에이전트 ID 관리자 역할입니다. 표면적으로는 에이전트 관련 객체에만 적용됩니다.

우리는 다음과 같은 계정을 발견했습니다. 만 에이전트 ID 관리자 역할은 다음과 같습니다. 인계 에이전트 신원과 전혀 관련이 없는 서비스 주체를 포함하여 임의의 서비스 주체를 소유자로 만든 다음 자격 증명을 추가하고 해당 주체로 인증함으로써 서비스 주체를 확보할 수 있습니다. 이는 완전한 서비스 제공자 인수입니다.높은 수준의 서비스 원칙을 가진 임차인들이 있는 경우, 이는 다음과 같은 문제가 됩니다. 권한 에스컬레이션 통로.

에이전트 ID 관리자 역할은 아직 널리 사용되지는 않지만, 대부분의 테넌트는 최소 하나 이상의 권한 있는 서비스 주체를 보유하고 있습니다. 또한 많은 테넌트가 이미 에이전트 ID를 사용하고 있으며, 때로는 상당한 규모로 사용하고 있는 것으로 확인되었습니다. 에이전트 ID 관리자 역할의 도입이 증가함에 따라 이러한 범위 격차는 중요한 ID 보안 위험으로 이어질 수 있습니다.

우리는 이러한 동작을 마이크로소프트 보안 대응 센터(MSRC)에 알렸고, 모든 구름 속에 고정되어 있었다.에이전트 ID 관리자 역할은 더 이상 에이전트가 아닌 서비스 주체의 소유자를 관리할 수 없습니다.

위에 설명된 개념에 이미 익숙하다면 다음 부분으로 넘어가십시오. 경계가 무너지는 곳.

아래 분석은 저희의 종합적인 연구 결과를 바탕으로 합니다.

당신이 알아야 할 것

응용 프로그램 및 서비스 원칙 Entra ID

마이크로소프트에 애플리케이션 등록하기 Entra ID 관련된 두 객체를 생성합니다. 주택 임차인이는 앱이 원래 등록된 테넌트입니다. 애플리케이션 객체 및 서비스 principal.

The 신청 객체는 앱의 전역적인 정의 역할을 하며 앱의 구성을 설명합니다.
The 서비스 책임자 테넌트 내에서 앱을 ID로 나타내며, 인증, 역할 및 권한 할당, 리소스 접근을 담당하는 객체입니다. 애플리케이션이 다음과 같이 구성된 경우 다중 테넌트앱이 다른 테넌트에서 사용될 때, 동일한 애플리케이션 객체를 기반으로 해당 테넌트에 추가 서비스 주체가 생성됩니다.

Microsoft Entra ID 다음과 같은 다양한 유형의 서비스 원칙을 가지고 있습니다. 애플리케이션 서비스 교장들과 관리되는 ID. An 응용 서비스 책임자 테넌트 내 애플리케이션 인스턴스이며, 애플리케이션 객체로부터 생성됩니다.

이 블로그에서는 이 유형에만 초점을 맞추는데, 여기에 설명된 동작은 애플리케이션 서비스 주체에만 적용되기 때문입니다.

Microsoft 에이전트 ID 입력

Microsoft 에이전트 ID 입력 이를 통해 AI 에이전트를 일급 개체로 취급할 수 있습니다. Entra ID즉, 테넌트 내 AI 에이전트에 대한 조건부 액세스, 거버넌스 및 수명 주기 관리를 제공합니다. 내부적으로는 다음을 기반으로 구축됩니다. 마이크로소프트 에이전트 ID 플랫폼AI 에이전트를 위한 ID 및 권한 부여 프레임워크입니다. 몇 가지 새로운 객체 유형(블루프린트, 에이전트 ID, 에이전트 사용자)을 도입했으며, 이 모든 것은 Microsoft Graph(현재 베타 API만 제공)를 통해 관리할 수 있습니다. 플랫폼은 아직 미리 보기 단계이지만, 역할은 이미 공개적으로 할당 및 사용할 수 있습니다.

요약하자면, 이 플랫폼은 다음과 같은 기능을 제공합니다.

청사진에이전트 ID를 정의하고 생성하는 템플릿입니다.
설계 원칙테넌트에 추가될 때 테넌트별로 생성되는 블루프린트 인스턴스입니다.
에이전트 신원인공지능 에이전트가 API 및 서비스에 인증하는 데 사용하는 특수 서비스 주체입니다.
에이전트 사용자: 이는 UPN 또는 메일이 필요한 에이전트를 위한 선택적 사용자 유사 객체이며, 대리 인증 흐름에 사용됩니다.

이것이 중요한 이유 : 에이전트 ID는 애플리케이션, 서비스 주체, 사용자와 같은 익숙한 디렉터리 기본 요소 위에 구축됩니다. 바로 이 공통된 기반 위에 우리의 발견이 자리 잡고 있습니다.

에이전트 ID 관리자 역할

마이크로소프트가 추가했습니다 에이전트 ID 관리자 새로운 에이전트 ID 제어 평면을 관리하는 역할입니다. 문서에 따르면, 그건 범위 지정 대상:

다른 말로: 요원 관련 내용만 해당모든 서비스 주체가 그런 것은 아닙니다. 이 차이점은 중요합니다. 서비스 주체는 자동화, CI/CD, 보안 도구 및 권한 있는 통합을 담당하는 주체입니다. 누가 이들을 제어하느냐에 따라 환경의 상당 부분을 제어하게 됩니다.

한 가지 더 말씀드리겠습니다.문서에는 이 역할이 다음과 같다고 나와 있습니다. 특권하지만 Entra UI(베타 디렉터리 역할 정의 기반)에서는 그렇게 표시되지 않습니다. 이로 인해 관리자는 권한 있는 역할에 부여하는 것과 같은 수준의 검토 없이 해당 역할을 할당할 수 있습니다.

마이크로소프트는 엔트라 사용자 인터페이스와 설명서 간의 불일치를 확인했습니다. 에 관한 “특권” 지표 수정될 것입니다.

경계가 무너지는 곳

저희가 확인한 바는 다음과 같습니다. 에이전트 ID 관리자 역할을 부여받은 사용자는 에이전트 관련 ID 외에도 테넌트 내의 임의의 서비스 주체를 포함하여 서비스 주체의 소유자로 자신을 추가할 수 있습니다. 그런 다음 자격 증명을 추가하고 해당 애플리케이션으로 인증할 수 있습니다.

1 단계 : 추가소유자(들) (대리인이 아닌 서비스 주체에 대해 성공했습니다. 본인 또는 다른 주체를 추가할 수 있습니다.)

2단계: 자격 증명 추가 (우리가 소유주가 된 후에만 효과가 있었습니다):

결론: 소유권은 원시적 것을 장악하다 - 소유자가 된 다음 비밀 키를 추가하고 해당 서비스 주체로 인증하십시오.

이 역할은 다음과 같은 목적을 가지고 있습니다. 대리인 신원과 관련하여 실제로는 소유권이 변경될 수 있습니다. 어떤 서비스 책임자.

이러한 현상이 발생하는 이유에 대한 우리의 생각은 다음과 같습니다. 일부 에이전트 ID는 서비스 주체(및 관련 유형)로 구현됩니다. 해당 역할에는 다음과 같은 작업이 포함됩니다.

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

따라서 관리자는 에이전트 객체의 소유자를 관리할 수 있습니다. 이러한 권한 확인이 에이전트 기반 서비스 주체로 엄격하게 제한되지 않으면 권한이 일반 서비스 주체 영역으로 유출될 수 있습니다.
전형적인 범위 설정 격차 한 객체 유형이 다른 객체 유형을 상속할 때.

우리는 한 지원 동일한 것을 참조하십시오 어플리케이션애플리케이션 리소스에 자신을 소유자로 추가하는 것이 거부되었습니다. 따라서 이 문제는 서비스 주체 표면과 관련된 것으로 보입니다.

수정 사항이 적용됨에 따라 에이전트 ID 관리자 역할을 사용하여 에이전트가 아닌 서비스 주체에 대한 소유권을 할당하려는 시도가 차단됩니다. 해당 작업은 다음과 같은 오류를 발생시킵니다.

영향

서비스 제공업체 인수

서비스 주체에 대한 소유권을 확보하는 것은 공격 경로에서 강력한 발판을 마련하는 것입니다. 공격자가 소유권을 획득하면 자격 증명을 추가하고 서비스 주체로 인증하여 API 액세스, 디렉터리 역할 또는 통합과 같은 기존 권한 범위 내에서 작업을 수행할 수 있습니다.

영향은 대상 서비스 주체에 할당된 권한에 따라 달라집니다. 서비스 주체가 광범위하게 사용되거나 높은 권한을 보유한 환경에서는 심각한 권한 상승으로 이어질 수 있습니다. 테넌트 상태 또한 영향에 영향을 미칠 수 있는데, 예를 들어 광범위하게 승인된 애플리케이션이나 허용적인 구성의 경우 그렇습니다.

수정 전에는 에이전트 ID 관리자 역할이 에이전트 관련 ID 외에도 서비스 주체에 대한 소유권을 할당할 수 있도록 허용하여, 애플리케이션 관리자와 같은 역할과 유사한 기능을 제공했지만 에이전트 사용 사례에 국한되지는 않았습니다.

대상에 권한이 있는 경우

확대 전망은 간단합니다. if 서비스 주체는 높은 수준의 권한(디렉터리 역할, 영향력이 큰 Graph 권한)을 가지고 있으며, 해당 서비스 주체를 인수하면 해당 권한도 함께 얻게 됩니다. 많은 조직에서 이러한 서비스 주체를 보유하고 있습니다.

어떤 서비스 주체가 권한을 가지고 있는지 파악한 다음 해당 주체를 대상으로 공격할 수 있습니다. 실제로 이는 두 가지 유형의 검사를 의미합니다.

특권 디렉터리 역할을 가진 서비스 주체: Microsoft Graph API(베타)를 사용하세요. isPrivileged 역할 정의를 참조하여 관리자 수준의 디렉터리 역할을 보유한 서비스 주체를 나열합니다.
영향력이 큰 그래프 권한을 가진 서비스 주체민감한 권한(예: 앱 역할 할당)에 대한 정보를 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. 영향력이 큰 그래프 앱 권한을 가진 서비스 주체

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% 적어도 하나의 특권 서비스 주체(반드시 에이전트 관련일 필요는 없음)를 보유해야 합니다. 절반보다 조금 더 에이전트 ID를 사용하는 기업이 많으며, 그중 거의 절반은 100개 이상의 ID를 보유하고 있습니다. 더 많은 조직에서 에이전트 ID 관리 역할을 부여함에 따라, 이러한 범위 격차는 심각한 위험 요소가 되고 있습니다.

테이크 아웃

마이크로소프트는 이 문제를 해결했지만, 핵심은 여전히 남아 있습니다. 새로운 ID 유형은 기존 기본 요소 위에 구축되는 경우가 많아 역할 권한 범위 설정에 허점이 생길 수 있습니다. 이 사례에서는 의도했던 것보다 더 광범위한 액세스 권한이 부여되었습니다. 이러한 가정을 검증하는 것이 필수적입니다. 또한, 전반적인 위험은 테넌트의 보안 상태, 특히 권한 있는 서비스 주체(PS)와 관련된 부분에 따라 달라지는데, 소유권 남용은 여전히 잘 알려진 공격 경로이며 큰 영향을 미칩니다.

이것을 놓치기 쉬웠던 이유는 무엇일까요?

서비스 주체의 소유권 변경은 누가 작업을 수행했는지와 대상 서비스 주체 유형을 연관시키지 않으면 일반적인 애플리케이션 관리자 활동처럼 보일 수 있습니다.
Entra 사용자 인터페이스에서 높은 권한으로 명확하게 표시되지 않은 역할은 비교적 간과된 방식으로 할당될 수 있습니다.
역할이 예상 범위를 벗어나 활동하는 시점을 알려주는 내장된 신호는 없습니다. 따라서 역할 활동과 영향을 받는 리소스를 연관시켜 분석해야 합니다.

탐지

주의 사항이러한 탐지 결과는 앞서 설명한 문제를 해결하기 위해 생성되었지만, 문제가 해결되었으므로 유사한 패턴을 식별하는 데 템플릿으로 사용할 수 있습니다.

에이전트 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는 해당 수정 사항이 완전히 배포되었음을 확인했습니다.

마이크로소프트는 이 문제를 인정하고 버그 공개 프로그램의 일환으로 버그 현상금 제도를 운영했습니다.

닫는 생각

에이전트 신원 이는 AI 에이전트 시대를 위해 구축된 비인간형 신원 시스템으로의 광범위한 전환의 일환입니다. 마이크로소프트 에이전트 신원 플랫폼은 조직이 이러한 신원 시스템을 관리하고 거버넌스하는 방식을 한 단계 더 발전시킨 것입니다.

이 연구는 해당 모델의 중요한 측면, 즉 에이전트 ID가 서비스 주체와 같은 기존 ID 구성 요소에 의존한다는 점을 강조합니다. 엄격한 범위 지정 없이 공유 기반 위에 역할 권한이 적용될 경우, 접근 권한이 원래 의도했던 범위를 넘어 확장될 수 있습니다. 이 경우, 특히 권한이 있는 서비스 주체가 관련된 경우 이러한 격차로 인해 접근 범위가 넓어졌습니다.

마이크로소프트는 이 문제를 해결했습니다.하지만 이는 더 광범위한 교훈을 강조합니다. 특히 공유 ID 구성 요소를 다룰 때 역할 범위와 권한 적용 위치를 검증하는 것이 필수적입니다.

환경 모니터링 및 보안 강화에 대한 실질적인 지침은 다음을 참조하십시오. 추천 아래 테이크 아웃 섹션을 참조하십시오.