Entra ID impostazioni utente predefinite del tenant limitano la registrazione delle app, la creazione di gruppi e l'accesso all'admin center

Entra ID impostazioni utente predefinite del tenant limitano la registrazione delle app solo dopo che un amministratore le modifica

Entra ID impostazioni utente predefinite del tenant limitano la registrazione delle app, la creazione di gruppi e la navigazione nell'admin center — ma solo una volta che un amministratore le modifica. Finché nessuno lo fa, la baseline documentata per un utente membro ordinario è deliberatamente generosa, e la maggior parte dei tenant non la rivede mai.

Microsoft è esplicita su ciò che un semplice utente membro può fare. Il riferimento sui permessi predefiniti afferma che «gli utenti membro possono registrare applicazioni, gestire la propria foto del profilo e il proprio numero di telefono cellulare, cambiare la propria password e invitare guest B2B. Questi utenti possono anche leggere tutte le informazioni della directory (con alcune eccezioni)». La stessa pagina indica, sotto Gruppi, che gli utenti membro possono «Creare gruppi di sicurezza» e «Creare gruppi Microsoft 365»; sotto Applicazioni, che possono «Registrare (creare) nuove applicazioni» ed «Enumerare l'elenco di tutte le applicazioni»; e sotto Ruoli e ambiti, che possono «Leggere tutti i ruoli amministrativi e le relative appartenenze» (Autorizzazioni utente predefinite).

Questa è la parte scomoda. Le due precondizioni che rendono possibili il phishing di consenso OAuth e la ricognizione della directory non sono capacità esotiche dell'attaccante — sono impostazioni del tenant. Quattro interruttori chiudono la maggior parte della falla, e nessuno di essi richiede un upgrade di licenza.

Come funziona: quattro interruttori, tre oggetti diversi

L'admin center di Microsoft Entra presenta questo come un elenco ordinato sotto Impostazioni utente e Impostazioni gruppo. Sotto la superficie, questi valori sono memorizzati in tre posizioni senza relazione tra loro — ed è esattamente per questo che gli audit parziali li perdono.

I primi due vivono sul singleton authorizationPolicy, valido per l'intero tenant. Microsoft Graph documenta allowedToCreateApps come corrispondente a «l'impostazione Gli utenti possono registrare applicazioni nel menu Impostazioni utente», e allowedToCreateSecurityGroups come corrispondente a «l'impostazione Gli utenti possono creare gruppi di sicurezza negli admin center di Microsoft Entra, API o PowerShell» (defaultUserRolePermissions). Lo stesso oggetto contiene anche allowedToCreateTenants, allowedToReadOtherUsers, allowedToReadBitlockerKeysForOwnedDevice e permissionGrantPoliciesAssigned.

La creazione di gruppi Microsoft 365 vive in tutt'altro posto: l'impostazione EnableGroupCreation all'interno del modello Group.Unified, il cui «valore predefinito è true» (Panoramica delle impostazioni di gruppo).

Il quarto interruttore è quello più delicato, ed è trattato in una sezione a parte più avanti.

La catena di attacco

Passo 1 — Ottenere un account ordinario

Nessun ruolo, nessun consenso amministrativo, nessuna escalation di privilegi. Il password spraying, il furto di token da parte di un adversary-in-the-middle o il device code phishing finiscono tutti nello stesso posto: una sessione come utente membro standard. Tutto ciò che segue è ciò a cui quella sessione ha diritto per impostazione predefinita.

Passo 2 — Mappare la directory dall'interno

Gli utenti membro possono enumerare tutti gli utenti e i contatti, tutti i gruppi, tutti i dispositivi e tutte le applicazioni, e leggere tutti i ruoli amministrativi e le relative appartenenze. In pratica, questo significa che un attaccante con una sola sessione ordinaria può elencare tutti gli amministratori globali del tenant, identificare quali account sono solo cloud, e scegliere gli obiettivi — senza mai toccare una singola superficie amministrativa.

Passo 3 — Registrare un'applicazione e aggiungervi una credenziale

Con allowedToCreateApps lasciato al suo valore predefinito, l'account crea una registrazione di applicazione. Microsoft documenta la conseguenza: «quando un utente registra un'applicazione, viene automaticamente aggiunto come proprietario dell'applicazione». I proprietari possono quindi aggiornare applications.credentials, tra le altre proprietà.

Questo è il punto di pivot. Aggiungere un segreto o un certificato controllato dall'attaccante a un'applicazione o a un service principal è catalogato da MITRE ATT&CK come T1098.001 — Account Manipulation: Additional Cloud Credentials, che nota come «gli avversari possano aggiungere credenziali per service principal e applicazioni oltre alle credenziali legittime esistenti in Azure / Entra ID. Queste credenziali includono sia chiavi x509 che password». Una credenziale su un oggetto applicazione non è legata alla password dell'utente compromesso, quindi reimpostare quella password non estromette l'attaccante.

L'applicazione ha ancora bisogno di permessi per essere utile, ed è qui che entra in gioco il lato del consenso del tenant: «per impostazione predefinita, a tutti gli utenti è consentito dare il consenso alle applicazioni per permessi che non richiedono il consenso dell'amministratore» (Configurare come gli utenti danno il consenso alle applicazioni). Trattiamo questa metà del problema in dettaglio in OAuth consent phishing: come le app malevole aggirano il furto di password e in Permessi Graph API pericolosi nell'app registration di Entra.

Passo 4 — Creare un gruppo che nessuno governa

La creazione di gruppi self-service non è, di per sé, un'escalation di privilegi — un nuovo gruppo non dà accesso a nulla. Il danno è di governance. Un utente membro che crea un gruppo viene normalmente aggiunto automaticamente come proprietario, con diritti su groups.members e groups.owners — con un'eccezione documentata: per i gruppi di sicurezza creati nel portale Azure, Microsoft nota che il «proprietario non viene assegnato automaticamente alla creazione del gruppo». Microsoft nota inoltre che «i gruppi di sicurezza creati in self-service tramite il portale I miei gruppi sono disponibili per l'adesione di tutti gli utenti, che siano approvati dal proprietario o auto-approvati» (Configurare la gestione self-service dei gruppi).

Il risultato è una directory con migliaia di gruppi la cui proprietà non significa nulla, in cui un gruppo posseduto da un attaccante è indistinguibile dagli altri — finché un amministratore non concede a quel gruppo l'accesso a un'applicazione, un sito o un'esclusione di Accesso condizionale.

Perché l'interruttore dell'admin center è attrito, non un controllo

Questo è l'interruttore più spesso segnalato come «rafforzato» e più spesso frainteso. La documentazione stessa di Microsoft riporta un avvertimento sopra la tabella: l'impostazione Limita l'accesso al portale di amministrazione di Microsoft Entra «limita l'accesso a un insieme di pagine dell'admin center visitate comunemente. Non è una misura di sicurezza».

Il dettaglio merita una lettura attenta. Impostarlo su Sì «aggiunge un livello di attrito alla navigazione occasionale» impedendo ai non amministratori di caricare pagine visitate di frequente come la home, la panoramica del tenant e l'elenco utenti. Ma Microsoft precisa che «non blocca l'accesso programmatico ai dati di Microsoft Entra tramite PowerShell, l'API Microsoft Graph, o altri strumenti come Visual Studio», che «non si applica agli utenti con un ruolo amministrativo», e che «la maggior parte delle pagine dell'admin center resta raggiungibile se l'utente dispone di un link diretto (profondo)».

Ogni passo della catena di attacco sopra descritta passa attraverso Microsoft Graph. Nessuno è influenzato da questo interruttore.

C'è una seconda conseguenza per gli auditor: a differenza delle altre tre impostazioni, questa non ha alcuna proprietà sulla risorsa authorizationPolicy. Il suo elenco di proprietà documentato — sia in v1.0 che in beta — contiene defaultUserRolePermissions, guestUserRoleId, allowInvitesFrom, blockMsolPowerShell e simili, e nulla per l'accesso al portale di amministrazione. Se la baseline del vostro tenant afferma di leggere questa impostazione da Graph, verificate cosa sta leggendo realmente.

🚨 Pericolo: non considerate l'interruttore del portale come un controllo compensativo per una registrazione di applicazioni aperta. La raccomandazione di Microsoft è di usare una policy di Accesso condizionale mirata all'API Windows Azure Service Management per bloccare l'accesso non amministrativo agli endpoint di gestione di Azure.

Rilevamento

Leggete lo stato reale invece del rendering dell'admin center. Tre delle quattro impostazioni sono recuperabili con ambiti di sola lettura; la quarta — l'interruttore dell'admin center — non ha alcuna proprietà da leggere, per il motivo indicato sopra.

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
$policy.defaultUserRolePermissions

$settings = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/groupSettings"
$settings.value

Un tenant che non è mai stato rafforzato restituisce qualcosa di simile a questo, con una collezione groupSettings vuota:

{
  "allowedToCreateApps": true,
  "allowedToCreateSecurityGroups": true,
  "allowedToCreateTenants": true,
  "allowedToReadOtherUsers": true,
  "permissionGrantPoliciesAssigned": ["managePermissionGrantsForSelf.microsoft-user-default-legacy"]
}

Abbinate la lettura della configurazione al log di audit. Questi nomi di attività sono esatti, e sono tutti raggiungibili nel log di audit di Microsoft Entra:

Fonte per ogni nome di attività: il riferimento delle attività del log di audit di Microsoft Entra.

Da qui derivano due rilevamenti pratici. Primo, allertate su Add application o Add service principal quando il principal che origina l'azione non detiene alcun ruolo di directory — in un tenant con una popolazione di sviluppatori controllata, dovrebbe essere un elenco breve. Secondo, allertate su Update authorization policy senza condizioni; ci sono pochissime ragioni legittime perché quella policy cambi, e un attaccante che raggiunge il ruolo di Amministratore ruoli con privilegi lo userà per riaprire ciò che avete chiuso. Se il vostro tenant non conserva questi log abbastanza a lungo da poter indagare, correggete prima questo — vedi Conservazione dei log Entra ID e impostazioni di diagnostica.

Correzione

1. Chiudete i permessi del ruolo utente predefinito. L'esempio PowerShell di Microsoft per disattivare la creazione di applicazioni funge da base; le due proprietà aggiuntive sono documentate sullo stesso oggetto.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$params = @{
    defaultUserRolePermissions = @{
        allowedToCreateApps           = $false
        allowedToCreateSecurityGroups = $false
        allowedToCreateTenants        = $false
    }
}

Update-MgPolicyAuthorizationPolicy -BodyParameter $params

Impostare allowedToCreateTenants su $false limita la creazione di tenant al ruolo Tenant Creator. Questo conta più di quanto sembri: Microsoft nota che «per impostazione predefinita, all'utente che crea un tenant Microsoft Entra viene automaticamente assegnato il ruolo di Amministratore globale», e l'evento viene registrato come Create Company.

2. Chiudete la creazione di gruppi Microsoft 365 e delegatela. Questo richiede un oggetto groupSettings creato a partire dal modello Group.Unified, perché un tenant predefinito non ne ha nessuno. Recuperate prima l'id del modello dal vostro stesso tenant con GET https://graph.microsoft.com/v1.0/groupSettingTemplates invece di codificarlo direttamente.

{
  "templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
  "values": [
    { "name": "EnableGroupCreation", "value": "false" },
    { "name": "GroupCreationAllowedGroupId", "value": "<object-id-of-your-approved-creators-group>" }
  ]
}

GroupCreationAllowedGroupId è documentato come «l'identificatore del gruppo di sicurezza i cui membri possono creare gruppi Microsoft 365 anche quando EnableGroupCreation è false» — questa è la vostra via d'uscita, e non richiede alcuna licenza P1.

3. Restringete la gestione self-service dei gruppi. Nell'admin center, sotto Gruppi → Impostazioni generali, impostate Gli utenti possono creare gruppi di sicurezza nei portali Azure, API o PowerShell e Gli utenti possono creare gruppi Microsoft 365 nei portali Azure, API o PowerShell su No. Microsoft è esplicita sulla via d'uscita: «se volete consentire ad alcuni, ma non a tutti i vostri utenti, di creare gruppi, potete assegnare loro un ruolo in grado di creare gruppi, come Amministratore gruppi». Conoscete il limite dell'interruttore vicino prima di affidarvi ad esso — Limita la capacità degli utenti di accedere alle funzionalità dei gruppi nel Pannello di accesso «limita solo l'accesso alle informazioni di gruppo in I miei gruppi. Non limita l'accesso alle informazioni di gruppo tramite altri metodi come le chiamate all'API Microsoft Graph o l'admin center di Microsoft Entra».

4. Sostituite l'interruttore dell'admin center con un controllo reale. Impostatelo su Sì se volete l'attrito, ma implementate il controllo che Microsoft raccomanda realmente: una policy di Accesso condizionale mirata all'API Windows Azure Service Management che blocchi l'accesso non amministrativo agli endpoint di gestione di Azure. Verificatela prima in modalità solo report — vedi Accesso condizionale solo report, esclusioni obsolete.

5. Verificate, e attenzione alle due trappole. Rieseguite il blocco di rilevamento sopra e confermate che ogni valore sia effettivamente cambiato. Due comportamenti documentati potrebbero altrimenti farvi credere che la modifica sia fallita o riuscita quando non è così:

• Le impostazioni di gruppo «possono richiedere fino a 15 minuti per avere effetto».
• «Queste impostazioni riguardano gli utenti e non influiscono sui service principal. Ad esempio, se aveste un service principal con il permesso di creare gruppi, anche impostando queste impostazioni su No, il service principal potrebbe comunque creare gruppi».

Questo secondo punto è il motivo per cui questo intervento di hardening deve accompagnarsi a un inventario delle applicazioni. Chiudere la creazione lato utente lasciando in essere service principal con permessi eccessivi sposta il problema invece di risolverlo — vedi App Azure con privilegi eccessivi nel tenant e la più ampia baseline di hardening del tenant Azure.

Come EtcSec rileva questo problema

EtcSec suddivide questa superficie in quattro riscontri distinti su ogni audit Azure, invece di raggrupparli in un vago punteggio di «hardening del tenant». Tutti e quattro vengono riportati a severità media.

• AZ_APP_REGISTRATION_OPEN — Registrazione applicazioni aperta a tutti gli utenti: sollevato quando authorizationPolicy → defaultUserRolePermissions.allowedToCreateApps risulta true. Questo viene letto direttamente da Microsoft Graph.
• AZ_SELF_SERVICE_GROUPS_OPEN — Creazione di gruppi self-service aperta: sollevato quando il tenant non ha alcuna restrizione sulla creazione di gruppi — condizione in cui si trova un tenant predefinito, poiché EnableGroupCreation resta true finché non esiste un oggetto Group.Unified.
• AZ_GROUP_SELF_SERVICE — Gestione self-service dei gruppi non limitata: lo stesso stato non limitato valutato dal lato gruppi — gruppi senza governance, e una proprietà che non significa nulla.
• AZ_ADMIN_PORTAL_ACCESS_OPEN — Accesso al portale di amministrazione non limitato: sollevato a meno che il tenant non sia registrato come limitante l'accesso all'admin center ai soli amministratori. Riportato come igiene della configurazione, non come un confine di sicurezza, in linea con l'avvertenza stessa di Microsoft.

Tenerli separati conta perché la correzione differisce per ciascun riscontro: uno è un aggiornamento di authorizationPolicy, due richiedono di creare prima un oggetto groupSettings, e il quarto è una policy di Accesso condizionale. Per la sequenza completa, vedi Come auditare la sicurezza di Microsoft Entra ID.