App Azure con Privilegi Eccessivi nel Tenant

Le App Azure con Privilegi Eccessivi nel Tenant sono uno dei punti in cui il privilegio diventa più facilmente invisibile. Una registrazione app può sembrare un dettaglio di integrazione, ma il suo service principal può detenere permessi applicativi di Microsoft Graph, credenziali attive e percorsi di accesso a livello di tenant che non dipendono da un utente con sessione attiva.

Quali sono i rischi delle App Registration di Azure?

Le App Registration di Azure sono gli oggetti identità dietro applicazioni personalizzate, automazioni, integrazioni e molte connessioni SaaS di terze parti in Microsoft Entra ID. Possono autenticarsi verso Microsoft Graph, le risorse Azure e altre API protette.

Il rischio emerge quando queste applicazioni mantengono più permessi del necessario, conservano le credenziali più a lungo di quanto dovrebbero, o restano nel tenant molto tempo dopo che il proprietario originale ha smesso di seguirle. In questo stato, l'applicazione si comporta come un'identità privilegiata permanente, con una visibilità umana quotidiana molto inferiore rispetto a un account utente amministratore.

Una buona revisione non consiste solo nel trovare un singolo permesso pericoloso. Consiste nel dimostrare quali applicazioni sono attive, quali hanno accesso applicativo ad alto privilegio, chi ne è il proprietario e come vengono governate le loro credenziali.

Come funziona

Le app registration di solito si autenticano con uno dei due tipi di credenziali:

• client secret
• certificati

L'applicazione agisce quindi in base ai permessi concessi al suo service principal corrispondente.

Contano due ampi modelli di permessi:

• i permessi delegati, in cui l'app agisce nel contesto di un utente con sessione attiva
• i permessi applicativi, in cui l'app agisce come se stessa, senza alcun utente presente

La documentazione di Microsoft Graph è esplicita su questa differenza: i permessi applicativi sono permessi esclusivi dell'app, usati senza un utente con sessione attiva. Un'app daemon o un servizio backend può usarli per chiamare le API come se stessa. Se l'app possiede un permesso applicativo ampio, il raggio d'impatto è determinato da quel permesso e dalla risorsa, non dalla sessione corrente di un utente interattivo.

I casi a maggior rischio sono di solito permessi applicativi che concedono un ampio accesso ai dati dell'intero tenant o la capacità di modificare la directory. Se un attaccante ottiene la credenziale dell'app, eredita tutto il potere API che l'app già possiede.

App Azure con Privilegi Eccessivi nel Tenant: cosa le rende ad alto rischio

Lo schema pericoloso è di solito una combinazione, non una singola casella:

• permessi applicativi ampi, come l'accesso a caselle di posta, file o directory a livello di tenant
• credenziali di lunga durata, con rotazione debole, o copiate in più punti
• nessun proprietario chiaro per l'app o il suo service principal
• nessuna attività di accesso recente, il che suggerisce che l'app potrebbe essere abbandonata ma comunque ancora fidata
• consenso amministratore concesso molto tempo fa, senza revisione ricorrente

Per questo una revisione dei permessi senza revisione della proprietà è incompleta. Un'app con permessi moderati e nessun proprietario può comunque diventare un incidente serio quando il secret viene divulgato e nessuno nota gli accessi.

Conta anche una seconda distinzione pratica: alcune app sono rischiose perché possono scrivere o amministrare, altre lo sono perché possono leggere silenziosamente grandi volumi di dati del tenant. Entrambi i casi meritano una revisione, anche quando il portale li etichetta come insiemi di permessi diversi.

Fatti sui permessi che cambiano il rischio

Non trattate ogni permesso di Graph come intercambiabile. Microsoft documenta che i permessi applicativi possono operare senza un utente con sessione attiva, e che alcuni permessi consentono un accesso a livello di intera organizzazione ai dati associati. Ad esempio, un ampio permesso su file, posta, directory o gestione applicazioni può essere più dannoso di un permesso delegato che funziona solo all'interno di una sessione utente limitata.

I permessi di gestione delle applicazioni meritano un'attenzione particolare. La reference dei permessi di Microsoft Graph avverte che i permessi in grado di gestire credenziali possono consentire a un'applicazione di agire come altre entità e di usare i privilegi loro concessi. Si tratta di una classe di rischio diversa da quella di un'app che si limita a leggere il proprio profilo.

Anche il consenso amministratore fa parte del confine di controllo. I permessi applicativi possono essere concessi solo da un amministratore, mai da un utente finale. Nello specifico per i permessi applicativi di Microsoft Graph, Microsoft documenta che solo Privileged Role Administrator e Global Administrator possono dare il consenso; Application Administrator e Cloud Application Administrator possono consentire permessi applicativi esclusi quelli di Microsoft Graph. Se il tenant non dispone di una revisione ricorrente delle applicazioni con consenso amministratore, il modello di accesso effettivo può derivare per anni dopo la fine del progetto originale.

La catena di attacco

Passo 1 - Enumerare le app registration e i loro permessi

Connect-MgGraph -Scopes 'Application.Read.All'

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"
  $appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

  [PSCustomObject]@{
    AppName      = $app.DisplayName
    AppId        = $app.AppId
    Created      = $app.CreatedDateTime
    SecretExpiry = ($app.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime
    Permissions  = ($appRoles | ForEach-Object { "$($_.ResourceDisplayName):$($_.AppRoleId)" }) -join ', '
  }
} | Where-Object { $_.Permissions -ne '' }

Passo 2 - Dare priorità alle combinazioni più sensibili

Concentratevi prima sulle applicazioni che combinano permessi ampi a livello di tenant con credenziali obsolete o proprietà poco chiara. I service principal che detengono direttamente ruoli admin di Entra sono un caso a parte, spesso peggiore, trattato in Ruolo Admin di Service Principal di Entra Sovraprivilegiato: Rilevamento e Correzione.

Un ordine di triage utile:

1. applicazioni con permessi applicativi verso Microsoft Graph o carichi di lavoro Exchange
2. applicazioni con permessi di gestione app o di gestione della directory
3. service principal con credenziali attive ma senza evidenza di accesso recente
4. app con più secret o certificati attivi che nessun proprietario sa spiegare
5. app con consenso amministratore ma senza un proprietario di business attuale

Passo 3 - Recuperare la credenziale

I client secret vengono spesso esposti tramite repository di codice, pipeline di deployment, file di configurazione locali o note operative copiate. Il problema non è che i secret possano teoricamente trapelare. Il problema è che molti tenant si affidano ancora a secret di lunga durata per app di alto valore.

Passo 4 - Autenticarsi come l'app e usare lo scope concesso

import msal

app = msal.ConfidentialClientApplication(
    client_id='APP_CLIENT_ID',
    client_credential='STOLEN_SECRET',
    authority='https://login.microsoftonline.com/TENANT_ID'
)
result = app.acquire_token_for_client(scopes=['https://graph.microsoft.com/.default'])
token = result['access_token']

A questo punto, il percorso d'attacco è determinato dai permessi già concessi all'app, non da un nuovo exploit amministrativo.

Rilevamento

Segnali di audit e accesso Entra

Microsoft documenta i log di accesso dei service principal separatamente dagli accessi utente interattivi e non interattivi. Questi log sono importanti perché l'autenticazione esclusivamente applicativa non coinvolge un utente umano. Microsoft documenta inoltre che questi eventi vengono aggregati: gli accessi vengono raggruppati in un'unica riga quando corrispondono nome o ID del service principal, stato, indirizzo IP e nome o ID della risorsa, quindi espandete una riga prima di concludere che un'app ha effettuato l'accesso una sola volta. Gli accessi delle managed identity non compaiono in questo log; hanno il proprio. Per gli schemi di rilevamento specifici per questo log, vedere Entra Service Principal: Rilevamento delle Anomalie di Accesso, Punti Ciechi dell'Identità del Carico di Lavoro.

Domande pratiche di revisione

• quali app detengono permessi applicativi con portata sull'intero tenant
• quali app hanno più secret attivi o vecchi secret mai rimossi
• quali app non hanno accessi recenti ma conservano accesso privilegiato
• quali app non hanno un proprietario attivo né uno sponsor di business
• quali app possono gestire applicazioni, service principal, credenziali, grant o assegnazioni di ruoli

Query di rilevamento SIEM (Elastic KQL)

data_stream.dataset: "azure.auditlogs"
    and azure.auditlogs.operation_name: "Add service principal credentials"
    and event.outcome: "success"

Usate il nome dell'attività esattamente come pubblicato da Microsoft nella reference delle attività di audit. Una credenziale aggiunta sull'oggetto application viene registrata sotto un'attività diversa, Update application - Certificates and secrets management, quindi una regola che monitora solo l'attività del service principal si perde metà dei casi. Questo evento diventa molto più utile arricchendolo con il proprietario dell'app, l'inventario precedente delle credenziali e il livello di permessi del service principal interessato.

Logica di rilevamento che riduce i falsi positivi

Un nuovo secret su un'app di test a basso privilegio non è la stessa cosa di un nuovo secret su un'app con permessi applicativi Graph e senza proprietario. Date priorità incrociando l'attività di audit con l'inventario delle app:

• i permessi attuali dell'app e lo stato del consenso
• se l'app usa permessi applicativi o permessi delegati
• il numero di credenziali e le relative date di scadenza
• l'orario dell'ultimo accesso del service principal
• il numero di proprietari e se sono ancora dipendenti attivi
• se l'IP di origine o il workload sono cambiati rispetto alla baseline storica

Correzione

Vittoria rapida: censite ogni applicazione con permessi applicativi ampi e fate attestare al proprietario che il permesso e la credenziale sono ancora necessari.

1. Rimuovere o disabilitare le applicazioni non usate

Partite dall'anzianità, ma non confondete anzianità con non utilizzo. La query seguente elenca le applicazioni registrate da più di 90 giorni, che in un tenant maturo sono la maggior parte. Produce una lista di candidate alla revisione, non una lista di applicazioni inutilizzate.

$cutoff = (Get-Date).AddDays(-90)
Get-MgApplication -All | Where-Object { $_.CreatedDateTime -lt $cutoff } |
  Select-Object DisplayName, AppId, CreatedDateTime

Il segnale di non utilizzo è l'autenticazione, non la data di creazione: controllate i log di accesso del service principal per l'app, oppure il report Service principal sign-in activity usage and insights, ancora in preview al momento della scrittura. Combinate revisione di attività, proprietà e dipendenze. Se nessuno sa spiegare perché l'app esiste ancora, non dovrebbe conservare un accesso permanente.

2. Ruotare e ridurre le credenziali

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $app.PasswordCredentials |
    Where-Object { $_.EndDateTime -lt (Get-Date).AddDays(30) } |
    Select-Object @{n='AppName';e={$app.DisplayName}}, DisplayName, EndDateTime
}

Ruotate i secret vecchi, rimuovete i secret sostituiti ed evitate di lasciare attive più credenziali valide senza motivo. Se una credenziale è stata copiata in codice, pipeline o documentazione, considerate la rotazione come un solo passaggio tra altri. Va ripulita anche la vecchia posizione di archiviazione.

3. Preferire una gestione delle credenziali più robusta

Microsoft pubblica un ordine di preferenza esplicito, che non inizia con i certificati. Usate una managed identity ogni volta che il workload gira su Azure: Microsoft la definisce l'opzione più sicura e la raccomanda con forza. Se il workload gira altrove, su una piattaforma che offre gestione automatizzata delle credenziali, usate invece la workload identity federation. Solo quando nessuna delle due è possibile dovreste ricorrere alle credenziali con certificato, archiviate in un key vault ed emesse da una CA di fiducia anziché autofirmate.

Le indicazioni di Microsoft sui secret sono dirette: «Don't use password credentials, also known as secrets». I secret sono comodi, ed è proprio per questo che finiscono copiati negli strumenti di sviluppo e operativi. I criteri di gestione delle applicazioni possono anche limitare la durata dei secret o bloccarne del tutto l'uso.

4. Ridurre l'ambito dei permessi

Verificate se l'app ha davvero bisogno di permessi applicativi. Dove possibile:

• sostituite i permessi di scrittura ampi con permessi di lettura o con ambito più ristretto
• preferite i permessi delegati quando esiste un vero contesto utente
• rimuovete il consenso amministratore non più giustificato dal workload
• evitate di concedere permessi di gestione app a meno che il workload non gestisca realmente applicazioni
• documentate perché ogni permesso applicativo rimanente è necessario

5. Stabilire chi può creare app e concedere il consenso

Microsoft fornisce impostazioni di tenant e ruoli delegati per controllare chi può registrare applicazioni e chi può concedere il consenso alle applicazioni. Disabilitate la registrazione app ampia da parte degli utenti e il consenso utente dove il business non ne ha bisogno, quindi assegnate ruoli espliciti ai team che ne hanno bisogno.

Questo non è solo governance. Impedisce al tenant di reintrodurre lo stesso problema dopo la pulizia. Se chiunque può creare app e richiedere permessi ampi senza un percorso di revisione, la proliferazione di app privilegiate tornerà.

Convalidare prima di chiudere il finding

Una revisione delle app registration non è completa solo perché il portale appare più pulito. Convalidate il risultato rispetto al comportamento reale del tenant.

• esportate le app ad alto rischio rimanenti, i loro proprietari, le credenziali attive e i permessi effettivi
• confermate che i vecchi secret siano stati rimossi, non solo sostituiti mentre la credenziale precedente restava attiva
• verificate che l'app funzioni ancora dopo la riduzione dei permessi o la rotazione delle credenziali
• confermate che le applicazioni abbandonate siano state effettivamente disabilitate o eliminate, invece di restare come eccezioni non documentate
• rivedete i log di accesso del service principal dopo la modifica per confermare che non restino IP di origine o risorse inattese
• ricontrollate i permessi con consenso amministratore e confermate che l'elenco corrisponda all'inventario delle applicazioni

Rivedete anche il percorso di governance circostante: chi può creare app, chi può concedere il consenso amministratore, e chi deve approvare l'accesso applicativo privilegiato. Senza questo controllo, lo stesso schema tornerà nel prossimo ciclo di progetto.

Come EtcSec rileva questo problema

EtcSec rende utilizzabili i finding sulle app registration combinando privilegio, anzianità delle credenziali, lacune di proprietà e segnali di attività. Un tenant di solito non fallisce perché ha molte applicazioni. Fallisce perché un numero ridotto di applicazioni ha permessi ampi, scarsa igiene delle credenziali e nessun percorso di revisione chiaro.

Il modello di rilevamento è basato sull'esposizione: permessi applicativi ampi, credenziali che restano valide, proprietà poco chiara e attività del service principal che non corrisponde al caso d'uso documentato. Ciascuno di questi elementi corrisponde a un controllo dedicato: permessi pericolosi su posta, file, directory e ruoli concessi a un'app; applicazioni con più secret attivi o senza rotazione delle credenziali; applicazioni e service principal senza proprietario; concessioni di consenso a livello di intero tenant; e service principal che conservano ancora credenziali obsolete. Il valore sta nell'incrocio dei dati, non in un singolo indicatore isolato.

Approfondimenti correlati

• Azure Tenant Hardening: Security Defaults
• Accesso Privilegiato Azure: Troppi Admin Globali
• Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione
• Account Guest Azure: la Superficie di Attacco Dimenticata nel Tuo Tenant
• Azure Identity Protection: Bloccare le Credenziali Divulgate

Riferimenti principali

• Microsoft Graph permissions overview
• Microsoft Graph permissions reference
• Permissions and consent in the Microsoft identity platform
• Service principal sign-in logs in Microsoft Entra ID
• Security best practices for application properties
• Delegate application management administrator permissions
• Microsoft Entra audit log activity reference