Audit dei consensi alle app OAuth in Microsoft Entra ID

In un tenant Microsoft Entra ID con configurazione predefinita, qualsiasi utente può approvare un'app di terze parti che legge la sua casella di posta, senza che nessuno in IT venga interpellato. Se non ha mai verificato questa impostazione, parta dal presupposto che esistano già dei grant e li sottoponga ad audit prima di modificare la policy.

Cosa consente la configurazione predefinita

Un utente può dare il consenso a un'app che legge la propria casella di posta. Non può invece concedere a un'app accesso illimitato in lettura e scrittura a tutti i file dell'organizzazione, perché serve un amministratore. Microsoft raccomanda di consentire il consenso utente solo per le app di un verified publisher, per ridurre il rischio che app malevole inducano gli utenti a concedere l'accesso.

Inoltre un grant non è una password. Secondo OAuth 2.0 (RFC 6749) l'app riceve un access token con uno scope e una durata definiti, emesso al posto delle credenziali dell'utente. Il grant è un oggetto a sé stante, che Lei deve individuare e rimuovere.

Elencare i grant concessi

Serve almeno il ruolo Cloud Application Administrator o Application Administrator. Nel Microsoft Entra admin center vada su Entra ID > Enterprise apps > All applications, selezioni l'app e apra Permissions. La scheda Admin consent mostra i permessi concessi per l'intera organizzazione. La scheda User consent mostra ciò che hanno concesso utenti o gruppi specifici.

Il portale lavora app per app, quindi per avere una visione dell'intero tenant serve un ciclo. Gli endpoint Graph indicati nella guida Microsoft alla revoca hanno ciascuno come ambito un singolo service principal: oauth2PermissionGrants restituisce i permessi delegati e appRoleAssignments restituisce i permessi applicativi. Lo script seguente usa i cmdlet equivalenti e risolve gli ID in nomi, compresi i ruoli applicativi come Mail.Read:

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

$sps  = Get-MgServicePrincipal -All
$name = @{}
$role = @{}
foreach ($s in $sps) {
  $name[$s.Id] = $s.DisplayName
  foreach ($r in $s.AppRoles) { $role["$($s.Id)|$($r.Id)"] = $r.Value }
}

$rows = @()
foreach ($g in Get-MgOauth2PermissionGrant -All) {
  $rows += [pscustomobject]@{ App=$name[$g.ClientId]; Type="Delegated"
    Resource=$name[$g.ResourceId]; Detail=$g.Scope }
}
foreach ($sp in $sps) {
  $assigned = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All |
    Where-Object { $_.PrincipalType -eq "ServicePrincipal" }
  foreach ($a in $assigned) {
    $rows += [pscustomobject]@{ App=$sp.DisplayName; Type="Application"
      Resource=$name[$a.ResourceId]; Detail=$role["$($a.ResourceId)|$($a.AppRoleId)"] }
  }
}
$rows | Export-Csv consent-audit.csv -NoTypeInformation

Questi scope provengono dagli esempi di revoca di Microsoft e includono l'accesso in scrittura, di cui un audit in sola lettura non ha bisogno. Richieda scope più ristretti se il Suo tenant lo consente e provi lo script prima su un piccolo insieme di dati.

Ordine di triage

Questo ordine è nostro, non una indicazione di Microsoft. Parta dai grant delegati i cui scope leggono o inviano e-mail oppure leggono file. Filtri la colonna Detail per Mail e Files. Poi passi a tutti i permessi applicativi.

Un grant malevolo nel portale ha un aspetto ordinario, con un nome plausibile e pochi scope. Il pattern da cercare è quello di più utenti che danno il consenso alla stessa app sconosciuta, di un publisher che non riesce a verificare. Se ne trova uno, lo tratti come un incidente e coinvolga il nostro team di incident response o il Suo.

Rimuovere i grant rischiosi

Per i permessi concessi dagli amministratori, apra la scheda Admin consent, selezioni il controllo ... accanto al permesso e scelga Revoke permission. Dalla scheda User consent non è possibile revocare nulla nel portale: per questi servono Graph o PowerShell.

In Graph, elimini un grant delegato tramite il suo ID, oppure rimuova un permesso applicativo tramite l'ID della sua assegnazione:

DELETE https://graph.microsoft.com/v1.0/oAuth2PermissionGrants/{id}
DELETE https://graph.microsoft.com/v1.0/servicePrincipals/{resource-servicePrincipal-id}/appRoleAssignedTo/{appRoleAssignment-id}

La pagina sulla revoca contiene anche script PowerShell che rimuovono tutti i permessi delegati e applicativi di una singola app. Li legga con attenzione prima di eseguirli, perché eliminano tutto per quel service principal.

La revoca non impedisce a un utente di approvare di nuovo la stessa app. Microsoft indica due rimedi: impedire all'app di richiedere i permessi tramite dynamic consent, oppure bloccare del tutto il consenso utente. Per le app di terze parti non si può cambiare ciò che richiedono, quindi a nostro avviso il blocco è il controllo che resta nelle Sue mani.

Limitare il consenso utente

Serve il ruolo Privileged Role Administrator. Il ruolo Global Administrator è richiesto solo se usa l'admin center, dove l'impostazione si trova in Identity > Applications > Enterprise apps > Consent and permissions > User consent settings.

Entra include due policy predefinite per questo scopo:

La policy low dipende dalla classificazione dei permessi da parte Sua, che è il modo in cui sceglie ciò che gli utenti possono approvare. Faccia questo per primo, poi verifichi con un account utente ordinario.

Prima di modificare qualcosa in PowerShell o Graph, recuperi l'authorizationPolicy corrente. Nel Suo tenant potrebbero essere assegnate policy ManagePermissionGrantsForOwnedResource.*, come quella che permette agli sviluppatori di gestire il consenso per le app di cui sono proprietari. Le mantenga nella collezione, altrimenti le rimuoverà. Disattivare il consenso utente con Graph PowerShell si fa così:

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$body = @{
  "permissionGrantPolicyIdsAssignedToDefaultUserRole" = @(
    "managePermissionGrantsForOwnedResource.{other-current-policies}"
  )
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $body

Per consentire invece il consenso con la policy a basso impatto, aggiunga managePermissionGrantsForSelf.microsoft-user-default-low al PATCH Graph di defaultUserRolePermissions.permissionGrantPoliciesAssigned. Una modifica della policy incide solo sui consensi futuri, quindi i grant esistenti restano al loro posto finché non li rimuove.

Offrire agli utenti un modo per fare richiesta

Se blocca il consenso senza offrire alternative, gli utenti cercheranno scorciatoie. L'admin consent workflow permette loro di chiedere un'approvazione. Un Global Administrator lo attiva in Entra ID > Enterprise apps > Consent and permissions > Admin consent settings. Imposti su Yes l'opzione "Users can request admin consent to apps they are unable to consent to", quindi scelga:

• Reviewer: utenti, gruppi o ruoli. Essere reviewer non aumenta i privilegi, quindi ciascuno deve già disporre dei permessi per concedere il consenso all'app richiesta. Solo i Global Administrator possono approvare le app che richiedono app role di Microsoft Graph (permessi applicativi).
• Notifiche e-mail: se le disattiva per i reviewer, vengono disattivate anche le notifiche ai richiedenti.
• Durata della richiesta e promemoria di scadenza: la durata è il numero di giorni per cui una richiesta resta valida. Il primo promemoria arriva circa a metà periodo, quindi al secondo giorno per una richiesta di tre giorni.

Salvi, poi attenda fino a un'ora perché il workflow diventi effettivo. Un reviewer rimosso mantiene l'accesso alle richieste effettuate mentre ricopriva il ruolo. I nuovi reviewer non possono agire sulle richieste create prima della loro aggiunta.

Anche i ruoli integrati di Entra, Exchange RBAC e il resource-specific consent di Teams possono concedere accesso, quindi li includa in una revisione più ampia.

Da dove iniziare

1. Esegua lo script di inventario e riveda separatamente l'elenco dei grant delegati e quello dei permessi applicativi. Contrassegni le app che nessuno sa giustificare.
2. Revochi i grant rischiosi: quelli con consenso admin nel portale, quelli con consenso utente tramite Graph o PowerShell.
3. Legga l'authorizationPolicy corrente, poi imposti il consenso utente su microsoft-user-default-low con permessi classificati, oppure lo disattivi, mantenendo le voci ManagePermissionGrantsForOwnedResource.*.
4. Attivi l'admin consent workflow. Indichi reviewer i cui ruoli possano concedere il consenso per ciò che gli utenti chiederanno e mantenga tra loro un Global Administrator, perché solo quel ruolo approva i permessi applicativi di Microsoft Graph.
5. Ripeta la revisione a intervalli regolari. Se Le manca il tempo, il nostro team di consulenza può svolgerla come assessment e il nostro servizio di sicurezza gestita può occuparsi del monitoraggio.