Il servizio di identità sotto Microsoft 365
Microsoft Entra ID è il prodotto fondativo della famiglia Microsoft Entra: la documentazione lo descrive come un servizio cloud di identity and access management che fornisce authentication, policy enforcement e protezione per utenti, dispositivi, app e risorse. Non è un acquisto separato: chi ha un abbonamento a Microsoft 365 sta già usando Entra ID, perché ogni tenant è automaticamente un tenant Microsoft Entra. Le identità con cui Copilot e gli agenti stabiliscono chi sta chiedendo, e a cosa quella persona ha diritto, vivono lì.
Il portale dedicato è il Microsoft Entra admin center, distinto dal Microsoft 365 admin center dove invece si assegnano le licenze e si governano gli agenti. La famiglia comprende anche Microsoft Entra ID Protection (rileva i rischi legati all’identità), Microsoft Entra ID Governance (richieste, assegnazioni e revisioni di accesso) e Microsoft Entra Agent ID, che estende i costrutti di identità agli agenti AI.
Va fissata la coppia di termini che le domande scambiano più spesso. L’authentication è “the process of proving that you are who you say you are”, abbreviata AuthN; l’authorization è “the act of granting an authenticated party permission to do something”, abbreviata AuthZ. La multifactor authentication appartiene alla prima categoria: è un fattore di verifica in più, non una regola di accesso.
Conditional Access: la policy che decide caso per caso
Conditional Access è il motore di policy Zero Trust di Microsoft: “brings signals together, to make decisions, and enforce organizational policies”. Nella forma più semplice una policy è un’affermazione if-then: se un utente vuole accedere a una risorsa, allora deve completare un’azione, per esempio una multifactor authentication.
I segnali valutati includono User, group, or agent (gli agenti in Preview), IP location information, Device, Application, il rilevamento del rischio in tempo reale che arriva da Entra ID Protection e i segnali di Microsoft Defender for Cloud Apps. Le decisioni sono Block access, la più restrittiva, oppure Grant access, eventualmente subordinato a controlli come Require multifactor authentication, Require device to be marked as compliant o Require terms of use. Nella struttura della policy la parte Assignments definisce chi, cosa e dove (Users and groups, Target resources, Network, Conditions), mentre Access controls definisce come si applica, con le sezioni Grant e Session. Un report-only mode permette di provarla prima di imporla.
Qui si annida la confusione tipica dell’esame. Un accesso condizionale non è un metodo di autenticazione: è la regola che decide se e come un controllo aggiuntivo viene richiesto. La doc è esplicita anche sull’ordine: “Conditional Access policies are enforced after first-factor authentication is completed”. Serve almeno una licenza Microsoft Entra ID P1, mentre chi sta sul tier gratuito parte dai security defaults, un livello base uguale per tutti (registrazione MFA obbligatoria, blocco della legacy authentication) senza personalizzazione. I due meccanismi non convivono per lo stesso scopo: “Organizations that choose to implement Conditional Access policies that replace security defaults must disable security defaults”.
Single sign-on: accedere una volta sola
Il single sign-on “lets users sign in once and reach many applications”: l’utente si autentica con un solo set di credenziali e apre poi tutte le applicazioni assegnate senza ripetere l’accesso. Entra ID, come identity provider, verifica l’utente e conferma la sua identità all’app: le applicazioni non gestiscono più username e password proprie. Gli utenti trovano le app assegnate nel My Apps portal.
Il beneficio non è solo comodità. Fra i vantaggi la doc elenca una migliore esperienza (meno credenziali, accessi meno frequenti), meno reset di password sul service desk e una sicurezza più forte, perché “Central sign-in limits credential exposure and applies consistent policies”. Meno password sparse in altrettanti database applicativi significa meno superficie da attaccare e un unico punto dove applicare Conditional Access. Le opzioni includono la federazione con SAML 2.0 e OpenID Connect e il password-based SSO.
Utente o gruppo: scegliere l’oggetto di sicurezza
Con i gruppi di Microsoft Entra “you can grant access and permissions to a group of users instead of to each individual user”. Assegnare a un singolo utente ha senso per un’eccezione; assegnare a un gruppo è la scelta normale quando il criterio è la funzione o il reparto, perché il diritto segue l’appartenenza e sopravvive al turnover. Vale per l’ambito di una Conditional Access policy, per il group-based licensing e per gli agenti: nel Copilot Control System del Microsoft 365 admin center un agente approvato si rende “available to users or groups within your organization”.
Nel Microsoft Entra admin center si gestiscono due group types: i Security groups, usati per l’accesso alle risorse condivise, i cui membri possono essere utenti, dispositivi e service principal; e i Microsoft 365 groups, orientati alla collaborazione, dove “Members of a Microsoft 365 group can only include users”. I membership types sono Assigned groups, Dynamic membership group for users e Dynamic membership group for devices: un gruppo dinamico vale per gli utenti oppure per i dispositivi, non per entrambi.
Attenzione al portale, altra distinzione verificabile: distribution groups, mail-enabled security groups, dynamic distribution groups e shared mailboxes stanno nella sezione Groups del Microsoft 365 admin center e si gestiscono lì o nell’Exchange admin center, non nel Microsoft Entra admin center. Se una domanda chiede di inviare una notifica via email a un insieme di persone l’oggetto è un distribution group; se chiede di concedere accesso a un sito SharePoint, è un security group.