Entra PIM Attivazione Approvazione MFA Giustificazione Configurazione Errata

Entra PIM Attivazione Approvazione MFA Giustificazione Configurazione Errata Spiegata

Attivare Microsoft Entra Privileged Identity Management (PIM) è la parte facile. La Entra PIM attivazione approvazione MFA giustificazione configurazione errata è ciò che accade dopo: PIM è distribuito, i ruoli sono idonei invece che permanenti, ma il passaggio di attivazione stesso resta completamente aperto — nessuna approvazione richiesta, nessun MFA all'attivazione, nessuna giustificazione registrata, e una finestra di attivazione di 8 ore o più. Il risultato sembra un accesso just-in-time su una dashboard, ma nella pratica si comporta come un accesso admin permanente: chiunque sia idoneo per un ruolo lo ottiene nel momento in cui clicca su "Attiva", senza secondo fattore, senza traccia di responsabilità, e con una finestra abbastanza lunga da superare la maggior parte dei cicli di rilevamento.

Questa è una modalità di fallimento distinta da "PIM non è affatto abilitato". Un tenant può superare quel primo controllo e restare comunque esposto, perché il valore di sicurezza di PIM deriva quasi interamente da come è configurata l'attivazione, non dal semplice fatto che esistano assegnazioni idonee. Ciascuno dei quattro controlli di attivazione — approvazione, MFA, giustificazione e durata — è opzionale per ruolo in Microsoft Entra, e nessuno di essi è richiesto per default.

Come Funzionano i Controlli di Attivazione di PIM

Microsoft Entra espone le impostazioni di ruolo PIM — chiamate internamente policy — attraverso l'Interfaccia di amministrazione di Microsoft Entra (ID Governance > Privileged Identity Management > Ruoli di Microsoft Entra > Ruoli > [ruolo] > Impostazioni di ruolo) o tramite la risorsa Microsoft Graph unifiedRoleManagementPolicy. Ogni policy è composta da regole indipendenti, e quattro di esse definiscono cosa accade al momento dell'attivazione (Configurare le impostazioni di ruolo di Microsoft Entra in PIM, Aggiornare le regole in PIM usando Microsoft Graph):

Tutti e quattro sono configurati per ruolo e nessuno è mutuamente esclusivo — un ruolo ben rafforzato ha in genere approvazione e MFA e giustificazione e una durata breve, non solo uno di questi elementi.

Perché "PIM Abilitato" Non È Lo Stesso Di "Attivazione Protetta"

Un controllo correlato, più basilare, è se PIM sia configurato per i ruoli privilegiati in generale — questo è un gap distinto e più severo, che trattiamo in Accesso Privilegiato Azure: Troppi Admin Globali. Questo articolo presuppone che quel controllo sia già superato: PIM è attivo, i ruoli sono idonei, e il tenant appare conforme a un primo sguardo. Il gap qui è un livello più in profondità — è ciò che accade dentro PIM una volta che qualcuno attiva un ruolo.

I quattro default contano perché nessuno di essi propende verso la sicurezza di serie:

• L'approvazione è disattivata per default. Qualsiasi utente idoneo può auto-attivarsi immediatamente, senza che una seconda persona sia coinvolta.
• L'MFA all'attivazione ha un punto cieco documentato. La documentazione ufficiale di Microsoft indica che "agli utenti potrebbe non essere richiesta l'autenticazione a più fattori se si sono autenticati con credenziali forti o hanno fornito l'autenticazione a più fattori in precedenza nella sessione" — quindi una sessione che ha già soddisfatto l'MFA al login può attivare un ruolo privilegiato senza alcuna verifica aggiuntiva. Questo è lo stesso punto cieco di riautenticazione trattato in Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta.
• La giustificazione è disattivata per default, quindi le attivazioni non portano alcuna motivazione aziendale registrata — il che indebolisce sia la revisione in tempo reale sia l'audit successivo.
• La durata massima di attivazione è di 8 ore per default e può essere impostata fino a 24 — abbastanza a lungo perché una sessione o un token dirottato restino utilizzabili per un'intera giornata lavorativa.

🚨 Pericolo: poiché l'impostazione MFA all'attivazione non forza la riautenticazione quando l'MFA è già stato soddisfatto nella sessione, un attaccante che ha rubato un token di sessione valido può attivare un ruolo privilegiato senza mai toccare un secondo fattore. La mitigazione documentata da Microsoft per questo gap specifico è il contesto di autenticazione Conditional Access combinato con la frequenza di accesso impostata su "Ogni volta" — non la semplice casella MFA all'attivazione.

Rilevamento

Cosa verificare per ruolo

Recuperate la policy di attivazione corrente per ogni ruolo di directory di Microsoft Entra e confrontatela con i quattro controlli sopra. Manualmente, questo significa aprire Impostazioni di ruolo per ogni ruolo nell'interfaccia di amministrazione. Su larga scala, interrogatela tramite Graph:

GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'&$expand=rules

Oppure con Microsoft Graph PowerShell:

# Richiede RoleManagement.Read.Directory o RoleManagement.ReadWrite.Directory
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$policies = Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/' and scopeType eq 'DirectoryRole'"
foreach ($p in $policies) {
    Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $p.PolicyId |
        Where-Object { $_.Id -in @('Approval_EndUser_Assignment','Enablement_EndUser_Assignment','Expiration_EndUser_Assignment') }
}

Per ogni ruolo, segnalatelo se: isApprovalRequired è false, enabledRules della regola di enablement non include MultiFactorAuthentication, enabledRules non include Justification, oppure maximumDuration della regola di scadenza supera la vostra soglia di policy (in genere 1-4 ore per i ruoli Tier-0). Date priorità ad Amministratore Globale, Amministratore di Ruolo Privilegiato, Amministratore della Sicurezza, Amministratore di Accesso Condizionale, e a qualsiasi ruolo personalizzato con permessi di scrittura a livello di directory — questi sono i ruoli in cui il gap ha il raggio d'impatto più elevato.

Cosa monitorare nel log di audit

Microsoft Entra conserva la cronologia delle policy e delle attivazioni PIM nel riquadro Controllo delle risorse (ID Governance > Privileged Identity Management > Ruoli di Microsoft Entra > Controllo delle risorse), conservato per 30 giorni per default (Visualizzare il report del log di controllo per i ruoli di Microsoft Entra in PIM) — se questa finestra predefinita è un problema per le vostre tempistiche di indagine, vedete Logging Entra ID: Retention, Diagnostic Settings, SIEM Esportazione per instradare questi log verso uno storage a più lungo termine. Due tipi di attività contano di più:

Correzione

1. Censite la policy attuale di ogni ruolo usando la query Graph o PowerShell sopra, per avere una baseline prima/dopo invece di una semplice stima per ruolo.
2. Richiedete l'approvazione per attivare i ruoli Tier-0, con almeno due approvatori designati configurati esplicitamente. Non lasciate vuota la lista degli approvatori: la stessa documentazione Microsoft avverte che un tenant può restare bloccato se tutti gli Amministratori di Ruolo Privilegiato/Amministratori Globali hanno solo assegnazioni idonee (non attive), l'approvazione è richiesta, e nessun approvatore è configurato — create account di accesso di emergenza correttamente monitorati, come assegnazioni attive e permanenti, prima di attivare questa impostazione.
3. Richiedete l'MFA all'attivazione, e dove il ruolo lo giustifica, aggiungete il contesto di autenticazione Conditional Access (vedi Lacune accesso condizionale Entra ID: quali errori lasciano una reale esposizione) con la frequenza di accesso impostata su "Ogni volta" — questa è l'impostazione che forza realmente la riautenticazione all'attivazione, invece di accettare silenziosamente una prova MFA ottenuta in precedenza nella sessione.
4. Richiedete la giustificazione all'attivazione (e valutate di richiedere anche informazioni sul ticket) affinché ogni attivazione porti una motivazione aziendale registrata e verificabile.
5. Riducete la durata massima di attivazione. Sia il default di 8 ore sia il tetto di 24 ore esistono per comodità, non per sicurezza — la maggior parte dei task operativi rientra in 1-4 ore. Impostatela con maximumDuration della regola di scadenza in formato ISO 8601 (PT2H per due ore, PT4H per quattro).
6. Applicate la stessa policy a tutti i ruoli equivalenti, non solo a quello testato. Le impostazioni di ruolo sono indipendenti, quindi uno script che corregge solo Amministratore Globale lascia invariati Amministratore di Ruolo Privilegiato, Amministratore della Sicurezza e i ruoli di directory personalizzati.
7. Rieseguite la query Graph di enumerazione dopo la modifica e confermate isApprovalRequired: true, che enabledRules include MultiFactorAuthentication e Justification, e che maximumDuration riflette il vostro nuovo tetto — poi ripetete questo controllo a intervalli regolari, poiché un futuro evento Update role setting in PIM può annullare tutto silenziosamente.

Come EtcSec Rileva Questo

L'audit Azure di EtcSec verifica la policy di attivazione PIM a ogni scansione, indipendentemente dal fatto che PIM stesso sia abilitato.

PA_PIM_NO_APPROVAL_REQUIRED segnala le assegnazioni di ruolo idonee dove l'attivazione non richiede approvazione.

PA_PIM_NO_MFA_ON_ACTIVATION segnala i ruoli la cui policy di attivazione non richiede l'autenticazione a più fattori.

PA_PIM_NO_JUSTIFICATION segnala i ruoli la cui attivazione non richiede una giustificazione aziendale.

PA_PIM_LONG_ACTIVATION segnala i ruoli configurati con una durata massima di attivazione abbastanza lunga da estendere materialmente l'esposizione dopo un'attivazione compromessa.

Controlli Correlati

Il rafforzamento dell'attivazione PIM è uno strato del controllo dell'accesso privilegiato. Rivedetelo insieme a Accesso Privilegiato Azure: Troppi Admin Globali per sapere se PIM è distribuito e se il numero di admin permanenti è sotto controllo, Account di Accesso di Emergenza Break Glass Entra ID: Assenti, Non Monitorati, Non Esclusi prima di richiedere l'approvazione sui ruoli Tier-0, Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta per il punto cieco di riautenticazione che l'MFA all'attivazione da solo non chiude, e Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica per la checklist completa di revisione dell'identità in cui questo argomento si inserisce.

Riferimenti Principali

• Configurare le impostazioni di ruolo di Microsoft Entra in PIM — Microsoft Learn
• Approvare o rifiutare richieste per i ruoli di Microsoft Entra in PIM — Microsoft Learn
• Aggiornare le regole in PIM usando Microsoft Graph — Microsoft Learn
• Visualizzare il report del log di controllo per i ruoli di Microsoft Entra in PIM — Microsoft Learn
• Gestire gli account di accesso di emergenza in Microsoft Entra ID — Microsoft Learn