Atribuie permisiuni Microsoft Graph unui Managed Identity cu PowerShell

Încă nu există un flux normal în portalul Entra pentru a acorda permisiuni de aplicație Microsoft Graph unui managed identity. Dacă ai nevoie de asta, PowerShell este calea practică, iar tocmai de aceea acest model contează pentru inginerii care construiesc Microsoft Copilot și AI agents, automatizări Azure sau joburi backend care se autentifică fără secrete.

Articolul sursă este bun și scurt. Partea importantă nu este bucla în sine, ci implicația de securitate. În momentul în care dai roluri de aplicație Graph unui managed identity, ai creat un principal non-uman cu acces API în tenant. Poate fi designul corect, dar doar dacă ești deliberat cu scopul. Un agent nu ar trebui să primească un cec în alb în tenant.

Ce atribui de fapt?

Atribui application permissions prin crearea unor app role assignments pe service principal-ul managed identity-ului. Microsoft documentează New-MgServicePrincipalAppRoleAssignment ca cmdletul pentru asta și cere cele trei ID-uri la care te-ai aștepta:

• ID-ul service principal-ului client, aici managed identity-ul
• ID-ul service principal-ului resursei, aici de obicei Microsoft Graph
• ID-ul app role pentru permisiunea acordată

Sursa folosește ID-ul aplicației enterprise Microsoft Graph 00000003-0000-0000-c000-000000000000, care este punctul corect de plecare când API-ul țintă este Graph.

Varianta practică

Eu aș întări puțin abordarea originală: filtrezi doar rolurile care permit tipul application, dai fail dacă numele managed identity-ului este ambiguu și folosești forma cu body parameter pe care Microsoft o arată în exemplele oficiale.

Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All"

$ManagedIdentityName = "My Managed Identity"
$Permissions = @(
    "User.Read.All",
    "GroupMember.Read.All"
)

$GraphSp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
$ManagedIdentity = Get-MgServicePrincipal -Filter "DisplayName eq '$ManagedIdentityName'"

if (-not $ManagedIdentity) {
    throw "Managed identity '$ManagedIdentityName' not found."
}

if (@($ManagedIdentity).Count -gt 1) {
    throw "More than one service principal matched '$ManagedIdentityName'. Use the object ID instead of display name."
}

$AppRolesToAssign = $GraphSp.AppRoles | Where-Object {
    $_.Value -in $Permissions -and $_.AllowedMemberTypes -contains "Application"
}

foreach ($AppRole in $AppRolesToAssign) {
    $Body = @{
        principalId = $ManagedIdentity.Id
        resourceId  = $GraphSp.Id
        appRoleId   = $AppRole.Id
    }

    New-MgServicePrincipalAppRoleAssignment `
        -ServicePrincipalId $ManagedIdentity.Id `
        -BodyParameter $Body
}

Acesta este modelul de bază. Se potrivește bine în pipeline-uri controlate de AI workflow automation, unde configurarea identității face parte din deployment, nu dintr-un click manual în portal.

Ce aș verifica înainte să rulez scriptul

În primul rând, scope-urile Graph necesare sunt suficient de puternice încât să le folosești doar în sesiunea de configurare. Sursa menționează Application.Read.All și AppRoleAssignment.ReadWrite.All, iar documentația Microsoft pentru cmdlet le listează ca permisiuni delegated valide. Corect. Le folosești, faci schimbarea, apoi te deconectezi.

În al doilea rând, nu mai folosi display name în automatizări de durată dacă poți evita asta. Display name-urile intră în coliziune. Pentru majoritatea organizațiilor este o mică problemă administrativă; pentru tenant-uri mari devine o problemă reală de guvernanță. Rezolvă service principal-ul o singură dată, salvează object ID-ul și tratează atribuirea de identitate ca pe cod.

În al treilea rând, acordă doar rolurile Graph de care ai nevoie exact. Discuțiile din comunitate despre acest model indică aceeași lipsă: fiindcă nu există un UX prietenos de administrare pentru managed identities aici, oamenii tind să compenseze excesiv cu permisiuni largi. Așa ajunge un cont de automatizare aparent banal să citească date din tot tenant-ul. Dacă nu ești sigur ce are deja o identitate, aici merită un audit de AI și automatizare.

Verdict

Aceasta este abordarea corectă, iar articolul sursă este corect ca direcție. Singura mea critică este cea clasică pentru scripturile de identitate: varianta ușoară este și varianta riscantă. Folosește PowerShell, dar fă-l determinist, cu least privilege și ușor de revizuit. Dacă dai permisiuni Graph manual, în producție, pentru managed identities, ești la un singur caz de permission creep tăcut distanță de un haos.