Audita Entra ID prima che la deriva cloud diventi compromissione
EtcSec esegue 158 rilevazioni in 9 categorie Microsoft Entra ID. La copertura si concentra sui controlli che gli attaccanti abusano per primi in Microsoft 365 e Azure: gap in Conditional Access, MFA mancante, admin permanenti rischiosi, permessi applicativi pericolosi, deriva guest e risposta debole a utenti o sign-in a rischio.
La raccolta usa Microsoft Graph API solo con application permissions. Non è richiesta alcuna sessione delegata, non viene installato nessun agent sugli endpoint e l’audit non modifica il tenant.
L’audit verifica se tutti gli utenti e i ruoli admin sono coperti, se MFA è obbligatoria, se legacy auth è bloccata, se vengono usati device compliance o token protection e se esclusioni troppo ampie lasciano buchi.
Il collector osserva utilizzo di PIM, assegnazioni permanenti, account di emergenza, impostazioni di approval e justification, durata di attivazione e service principal che portano ruoli admin.
Il catalogo copre tenant-wide consent, policy di admin consent, permessi Graph ad alto privilegio, implicit grant, multi-tenant, owner mancanti, secret scaduti e credenziali con durata eccessiva.
Guest admin, inviti senza controllo, account guest obsoleti, MFA guest assente, fiducia cross-tenant ed esposizione B2B fanno parte della review Entra di base.
Le 9 categorie seguono il modo reale in cui l’identità cloud viene abusata
L’audit Entra non è un generico score cloud. È una review di controlli organizzata attorno a Conditional Access, privilegi, consenso applicativo, governance esterna e risposta basata sul rischio.
Identity e MFA
25 rilevazioni che coprono policy di registration, metodi forti, passwordless, account utente obsoleti, SSPR e protezione delle password.
Applicazioni e service principal
24 rilevazioni su permessi Graph pericolosi, tenant-wide consent, owner delle app, implicit grant, multi-tenant e hygiene dei secret.
Conditional Access
20 rilevazioni su copertura di tutti gli utenti e admin, MFA, blocco della legacy auth, device compliance, policy basate sul rischio ed esclusioni.
Privileged Access e PIM
18 rilevazioni su PIM, assegnazioni permanenti, account di emergenza, approval, justification, MFA in attivazione e numero di Global Admin.
Guest, gruppi e configurazione
39 rilevazioni su guest, fiducia cross-tenant, gruppi dinamici, gruppi role-assignable, impostazioni del tenant ed export dei log.
Conformità e Risk Protection
18 rilevazioni su licenze P2, access reviews, postura Identity Protection, utenti a rischio e gap nella risposta automatizzata.
Perché i team usano EtcSec per review Entra ID
L’identità cloud cambia continuamente. Un audit utile deve poter essere rieseguito dopo cambi di policy, onboarding applicativo, collaborazione esterna o review di accesso privilegiato.
Workflow Graph in sola lettura
L’audit si basa su application permissions di Graph. Non servono sessioni utente delegate né mutazioni del tenant per produrre i finding.
Abbastanza veloce per seguire le finestre di cambiamento
Il runtime tipico va da 8 a 30 secondi a seconda della dimensione del tenant e del throttling Graph. Questo rende realistica una review ricorrente.
Finding nominati allineati ai compiti degli operatori
I responsabili di Conditional Access, IAM, piattaforma applicativa e governance vedono i finding del proprio perimetro invece di uno score cloud mescolato.
Un collector per cloud e on-prem
Lo stesso ETC Collector può auditare Active Directory e Microsoft Entra ID, cosa importante nei programmi ibridi in cui la deriva di un piano amplifica il rischio dell’altro.
Cosa deve rendere esplicito un audit Entra ID serio
La postura cloud viene troppo spesso ridotta a “abbiamo MFA?”. Il catalogo pubblicato mostra perché non basta: permessi, impostazioni del tenant, governance guest e risposta al rischio interagiscono.
Raccolta Graph in sola lettura ed endpoint chiave
L’audit legge `/users`, `/groups`, `/applications`, `/servicePrincipals`, `/identity/conditionalAccess/policies`, `/roleManagement/directory`, `/policies/authorizationPolicy` e gli endpoint rilevanti di audit o Identity Protection. I finding restano così collegati a oggetti concreti invece che a dichiarazioni generiche sulla cloud posture.
L’uso di application permissions rende inoltre il workflow adatto all’automazione. I team di sicurezza non hanno bisogno di una sessione admin interattiva per verificare se una policy protegge ancora tutti gli admin o se l’onboarding di una nuova applicazione ha reintrodotto permessi eccessivi.
Le 9 categorie e le domande operative a cui rispondono
| Categoria | Controlli | Cosa apprende l’operatore |
|---|---|---|
| Identity | 25 | Se MFA, password policy, SSPR, enrollment e account obsoleti resistono agli attacchi moderni. |
| Applications | 24 | Se app registration, service principal, consent e credenziali concedono accesso eccessivo o orfano. |
| Conditional Access | 20 | Se la copertura è completa per tutti gli utenti, admin, legacy, rischio e sessioni. |
| Privileged Access | 18 | Se PIM è usato bene, se esistono account di emergenza e se i ruoli admin restano permanenti. |
| Guest External | 15 | Se guest, inviti e collaborazione cross-tenant restano limitati e auditabili. |
| Config | 12 | Se impostazioni del tenant, diagnostica, consent e app registration supportano un’operatività sicura. |
| Groups | 12 | Se gruppi dinamici, role-assignable o guidati da esterni nascondono privilegio. |
| Compliance | 8 | Se il tenant è licenziato e configurato per access review e Identity Protection. |
| Risk Protection | 10 | Se utenti e sign-in a rischio vengono rilevati e trattati automaticamente. |
Le famiglie di detection che più spesso innescano remediation
Gap in Conditional Access
I finding chiave includono CA_NO_MFA_REQUIREMENT, CA_NO_POLICY_ALL_USERS, CA_NO_POLICY_ADMINS, CA_NO_LEGACY_AUTH_BLOCK, CA_NO_DEVICE_COMPLIANCE, CA_NO_RISK_BASED_SIGNIN e CA_POLICY_REPORT_ONLY.
- Mostra se il tenant si appoggia a copertura parziale.
- Separa i controlli basati sul rischio dal baseline MFA.
- Rende visibili eccezioni che spesso restano nascoste nel JSON.
Deriva di accesso privilegiato
PA_PIM_NOT_ENABLED, PA_PERMANENT_ADMIN_ASSIGNMENTS, PA_NO_EMERGENCY_ACCOUNTS, PA_GLOBAL_ADMIN_NOT_MFA, PA_TOO_MANY_GLOBAL_ADMINS e PA_SERVICE_PRINCIPAL_ADMIN descrivono se il privilegio resta permanente e poco protetto.
- Utile per IAM, cloud platform e governance.
- Separa il design degli account di emergenza dall’igiene PIM.
- Porta l’attenzione sui service principal perché lì MFA non compensa.
Rischio applicativo e consenso
APP_USER_CONSENT_UNRESTRICTED, APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_ROLE, APP_NO_OWNER, APP_SECRET_EXPIRED, APP_SECRET_LONG_EXPIRY e SP_HIGH_PRIVILEGE espongono i percorsi di escalation ed esfiltrazione più frequenti.
- Combina review di app registration e postura dei service principal.
- Fa emergere l’igiene delle credenziali, non solo i permessi.
- Aiuta a ripulire dopo M&A o cloud sprawl.
Governance guest e cross-tenant
GUEST_ADMIN_ROLE, GUEST_NO_MFA_REQUIRED, GUEST_INVITATION_UNRESTRICTED, B2B_CROSS_TENANT_OPEN, GUEST_STALE_90_DAYS e GUEST_NO_ACCESS_REVIEW mostrano se la collaborazione esterna resta controllata.
- Particolarmente utile in ambienti partner o M&A.
- Distingue la invitation policy dalla popolazione guest realmente obsoleta.
- Mostra dove i guest sono già presenti in gruppi sensibili.
Identity Protection e risposta al rischio
RISK_NO_SIGNIN_RISK_POLICY, RISK_NO_USER_RISK_POLICY, RISK_HIGH_RISK_USERS_ACTIVE, RISK_LEAKED_CREDENTIALS e RISK_USERS_NOT_REMEDIATED mostrano se il tenant sa reagire quando Microsoft segnala un account o un sign-in a rischio.
- Detection senza risposta significa compromissione ancora attiva.
- Collega licenza, configurazione della policy e risposta operativa.
- Distingue telemetria semplice da protezione effettivamente applicata.
Come i finding si mappano ai confini di responsabilità
I responsabili di Conditional Access guardano prima la categoria CA, ma le loro decisioni determinano anche la protezione di admin, guest e utenti a rischio. I team piattaforma applicativa hanno bisogno dei finding Applications perché consent e privilegi dei service principal spesso emergono fuori dal flusso IAM centrale. Governance si concentra su Compliance e Risk Protection, perché queste categorie rivelano se PIM, Identity Protection e access review vengono davvero usati.
Una pagina Entra utile deve quindi fare più che promettere “auditiamo Entra ID”. Deve mostrare come i finding si collegano a modelli operativi concreti: onboarding applicativo, assegnazione di ruoli admin, collaborazione esterna, automazione della risposta al rischio e visibilità ibrida.
- IAM e cloud engineering possiedono le decisioni di Conditional Access e PIM.
- I team applicativi possiedono registration, owner e rotazione dei secret.
- Governance possiede access review, evidenze di conformità e risposta al rischio.
- I programmi ibridi hanno bisogno di un workflow comune fra cloud e on-prem.
Perché il collector conta anche in una review puramente cloud
La documentazione del collector mostra lo stesso workflow per Entra via Graph e per Active Directory via LDAP o SMB. Così i rischi ibridi possono essere letti in una revisione unica invece di separare il mondo cloud da quello on-prem.
EtcSec aggiunge il layer di dashboard e operating sopra al collector. Il risultato è il passaggio da una review grezza dei controlli cloud a remediation ricorrente e storico, non un semplice export CSV.
Domande frequenti
Cosa copre esattamente l’audit Entra ID?
Il catalogo pubblicato elenca 158 rilevazioni in Identity (29), Applications (28), Conditional Access (20), Privileged Access (24), Guest External (15), Config (12), Groups (12), Compliance (8) e Risk Protection (10).
L’audit richiede permessi delegati o una sessione admin interattiva?
No. La review si basa su application permissions di Microsoft Graph e non richiede sessioni delegate interattive. Questo rende il workflow compatibile con l’automazione.
Si possono rivedere Entra e Active Directory nello stesso workflow?
Sì. ETC Collector supporta Entra ID e Active Directory in modo che i team ibridi possano eseguire entrambe le review con lo stesso modello di raccolta.
Perché trattare permessi applicativi e governance guest come temi di primo livello?
Perché molti incidenti di identità cloud iniziano con consent phishing, permessi Graph eccessivi, service principal obsoleti o impostazioni di collaborazione esterna troppo aperte, e non solo con una casella MFA mancante.
Pagine correlate alla sicurezza dell’identità
Guarda il catalogo on-prem che completa la review Entra nei programmi di identità ibrida.
Ispeziona le rilevazioni nominate che alimentano le pagine cloud e on-prem.
Comprendi il workflow di raccolta, la modalità standalone, il daemon e la superficie API.
Confronta il motore di raccolta open-source con il layer SaaS per dashboard e follow-up.
Avvia il tuo audit Microsoft Entra ID
Connettiti con permessi Graph read-only, rivedi Conditional Access, privilegi, applicazioni, guest e rischio, poi trasforma l’output in remediation ricorrente.