Il set di domande di Cyber Essentials è cambiato il 27 aprile 2026. La versione Danzell ha introdotto qualcosa che lo schema non aveva mai avuto prima: domande in cui una risposta sbagliata fa fallire del tutto la valutazione, anziché ridurre un punteggio. Diverse di esse ricadono in pieno su Microsoft 365, e due colgono cose che la maggior parte dei tenant si porta silenziosamente dietro da anni.
Abbiamo noi stessi la certificazione Cyber Essentials, quindi questo testo nasce dall'averci passato attraverso anziché dall'aver letto la specifica.
Questa è una checklist da eseguire prima di inviare la candidatura, non un sostituto del set di domande ufficiale di IASME.
Il cambiamento che coglie impreparati
Due cose contano più di tutte le altre.
Le domande sull'autenticazione a più fattori possono ora bocciarvi direttamente. In precedenza una posizione MFA imperfetta era qualcosa che si spiegava. Ora, per gli account in ambito, è promosso o bocciato.
Esiste una definizione formale dei servizi cloud in ambito. Questo chiude la scappatoia che permetteva alle organizzazioni di sostenere che Microsoft 365 stesse fuori dal perimetro della valutazione. Se i vostri utenti vi accedono e contiene dati organizzativi, è in ambito. Quella discussione è chiusa.
Insieme, significano che la valutazione ora arriva in posti che prima venivano lasciati stare.
Questo cambia la natura del lavoro. Una domanda a bocciatura automatica non è qualcosa a cui si scrive una risposta accurata; potete rispondere onestamente in modo affermativo oppure no. L'esercizio diventa scoperta anziché stesura: un elenco di ogni identità in grado di autenticarsi, di cosa la autentica e di cosa si romperebbe cambiandola. Produrre quell'elenco è gran parte dello sforzo. Il rimedio di solito è rapido.
L'ordine che rende ripetibile un esito positivo di Cyber Essentials: prima scoprire, poi decidere, poi cambiare, e conservare le evidenze.
Le due che davvero colgono impreparati
Account di servizio
Ogni tenant li ha. L'account che esegue un'esportazione pianificata. Quello con cui si autentica un'applicazione line-of-business. Quello creato per una migrazione nel 2021 che nessuno ha mai spento.
Di solito non hanno MFA, perché l'MFA romperebbe qualunque cosa automatizzino. Era tollerabile quando la domanda era a punteggio. Ora non lo è.
Trovateli prima di discuterne. Due viste vi danno l'elenco dei candidati in circa dieci minuti:
- Interfaccia di amministrazione di Microsoft Entra, Protection, Authentication methods, User registration details. Mostra ogni account e se è MFA capable e registrato. Filtrate sugli account senza nulla di registrato e state guardando la vostra esposizione.
- Entra ID, Monitoring, Sign-in logs, filtrato sugli accessi utente non interattivi. L'automazione compare qui, non nel log interattivo. Un account con migliaia di accessi non interattivi e nessun metodo registrato è un account di servizio, comunque lo si sia chiamato.
Lo stesso elenco esce da Microsoft Graph PowerShell come CSV:
Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { -not $_.IsMfaRegistered } |
Select-Object UserPrincipalName, IsAdmin, IsMfaCapable |
Export-Csv .\no-mfa.csv -NoTypeInformation
Cosa fare, in ordine di preferenza:
- Sostituite del tutto l'account. Un'identità del carico di lavoro o un'identità gestita è la risposta corretta per qualsiasi cosa venga eseguita senza presidio. Nessun accesso interattivo, nessuna questione MFA, nessun segreto condiviso in un file di configurazione.
- Se deve restare un account, togliete i diritti di accesso interattivo, delimitatelo strettamente con l'accesso condizionale, e siate in grado di mostrare cosa può e cosa non può fare.
- Documentate perché esiste. Un valutatore accetterà un'eccezione controllata molto più volentieri di un account che nessuno sa spiegare.
Un esempio concreto: un'esportazione contabile viene eseguita ogni notte sotto un account con licenza, con una password in un'operazione pianificata. La risposta giusta la sposta su una registrazione applicazione con credenziali a certificato e solo i permessi Graph di cui l'esportazione ha bisogno, rimuovendo insieme l'account e la password. Se l'applicazione non è ancora in grado di farlo, mantenete l'account, bloccate l'accesso interattivo, limitatelo tramite accesso condizionale a quel solo servizio, e registrate il controllo compensativo.
La modalità di fallimento qui è scoprirli la settimana in cui inviate la candidatura. Sono sempre più numerosi del previsto.
Cassette postali condivise
Questa è quella che sorprende. Una cassetta postale condivisa non dovrebbe avere affatto un accesso abilitato. L'accesso dovrebbe essere delegato a utenti nominali che hanno il proprio MFA.
In pratica molti tenant hanno cassette postali condivise con un account sottostante abilitato e una password che qualcuno conosce, create anni fa perché un telefono o uno scanner potessero inviare posta. Quello è un account con una password e senza MFA, che contiene dati organizzativi, e il nuovo set di domande ha un'opinione al riguardo.
Verificate ogni cassetta postale condivisa per un accesso abilitato:
Connect-ExchangeOnline
Connect-MgGraph -Scopes 'User.Read.All'
Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
ForEach-Object { Get-MgUser -UserId $_.ExternalDirectoryObjectId -Property UserPrincipalName,AccountEnabled } |
Where-Object { $_.AccountEnabled } |
Select-Object UserPrincipalName
Tutto ciò che torna indietro ha bisogno che l'accesso venga bloccato, nell'interfaccia di amministrazione di Entra sotto Users oppure con Update-MgUser -UserId <upn> -AccountEnabled:$false. Delegate l'accesso con Add-MailboxPermission per l'accesso completo e Add-RecipientPermission per l'invio come, così che ogni azione su quella cassetta postale appartenga a un'identità che porta il proprio MFA.
Se qualcosa ha davvero bisogno di inviare posta senza presidio, quello è un problema di permessi applicativi, non di password della cassetta postale. Spostatelo su una registrazione applicazione con permessi di posta strettamente delimitati, oppure su un connettore di ricezione limitato a un indirizzo statico noto. Dove l'autenticazione SMTP di base è ancora abilitata, Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled $true la chiude per singola cassetta postale e l'impostazione equivalente su Set-TransportConfig la chiude a livello di organizzazione. Verificate prima cosa supporta ogni dispositivo: un dispositivo multifunzione che smette silenziosamente di scansionare verso email è una coda di supporto di cui nessuno vi ringrazierà.
Il resto della checklist
Ogni account utente con una licenza ha l'MFA. Non "abbiamo una policy". Verificate l'applicazione effettiva, compresi gli account creati dopo la stesura della policy, i guest e chiunque sia escluso dall'accesso condizionale. Leggete nello specifico le esclusioni su ogni policy, perché è lì che vive la deriva: un gruppo di progetto aggiunto per due settimane nel 2024, un account fornitore, un ruolo di directory che aggira silenziosamente la regola.
Gli account guest sono censiti. I guest si autenticano nel loro tenant di origine, quindi il loro MFA può essere soddisfatto altrove, e le impostazioni di accesso tra tenant decidono se il vostro tenant si fida di quella dichiarazione. Non dovete fare una scelta particolare qui, ma dovete sapere quale scelta avete fatto.
Gli account di emergenza sono un'eccezione documentata. Gli account di accesso di emergenza sono ammessi. Ci si aspetta che li controlliate e li monitoriate: due account solo cloud, esclusi dalle policy che potrebbero bloccare tutti fuori, credenziali divise e custodite fisicamente, e un avviso che scatta nel momento in cui uno dei due effettua l'accesso. Le linee guida attuali privilegiano un metodo resistente al phishing anziché la sola password, quindi rivedete quel punto se la coppia ha qualche anno.
Gli account amministrativi sono separati dagli account di uso quotidiano. Un amministratore che consulta la posta dalla stessa identità è un rilievo in attesa di accadere. Dove le licenze lo consentono, l'elevazione just-in-time tramite Privileged Identity Management vi dà la separazione e un registro già pronto di chi ha ricoperto quale ruolo e quando.
L'autenticazione legacy è disattivata. Se l'autenticazione di base può ancora raggiungere qualcosa, la risposta sull'MFA non è vera nella pratica. Filtrate i log di accesso su un'app client "Other clients" e guardate cosa compare. La maggior parte dei protocolli legacy in Exchange Online è ritirata da tempo; l'autenticazione SMTP è quella che sopravvive, perché qualcosa di operativo ne dipende.
Le vostre evidenze sull'aggiornamento dei dispositivi sono esportabili. Lo schema si interessa allo stato dei dispositivi, e la risposta deve provenire da qualcosa che potete mostrare anziché affermare. Intune può produrle, e dimostrarlo da Intune è un esercizio a parte che vale la pena fare prima che serva. Quello che volete è un'esportazione datata della conformità di build e aggiornamenti per dispositivo, non uno screenshot di una dashboard che la prossima settimana avrà un aspetto diverso.
La vostra dichiarazione di ambito corrisponde alla realtà. Con i servizi cloud formalmente definiti, un perimetro inesatto ora è una bocciatura netta anziché una discussione. Percorrete l'elenco dei servizi a cui le vostre persone accedono con un'identità di lavoro, compresi quelli che un reparto ha adottato senza dirlo a nessuno.
Fatelo nell'ordine giusto
Eseguite la scoperta prima di toccare qualsiasi cosa. La tentazione è iniziare a bloccare gli accessi man mano che li trovate, ed è così che l'esecuzione pianificata delle fatture si ferma silenziosamente un venerdì pomeriggio.
L'ordine che funziona:
- Enumerate ogni account: utenti, account di servizio, cassette postali condivise, guest.
- Per ciascuno, stabilite a cosa serve e se qualcosa dipende da esso.
- Decidete lo stato di destinazione per ognuno.
- Cambiateli in modo controllato, sorvegliando cosa si rompe.
- Raccogliete le evidenze man mano, perché vi serviranno di nuovo l'anno prossimo.
Datevi circa sei settimane. Rintracciare a cosa serve un account misterioso richiede il tempo maggiore, e le policy di accesso condizionale in sola segnalazione vi permettono di misurare un irrigidimento prima che ricada su qualcuno.
Conservate le evidenze come esportazione datata per controllo anziché come cartella di screenshot: il report dei dettagli di registrazione, le policy di accesso condizionale con le esclusioni visibili, lo stato di accesso delle cassette postali condivise, la procedura per gli account di emergenza, l'esportazione della conformità dei dispositivi, e una nota per ogni eccezione.
Cyber Essentials si rinnova ogni anno, quindi qualsiasi cosa costruiate come una tantum la ricostruirete tra dodici mesi. Costruirla come qualcosa di ripetibile è la differenza tra due settimane e un pomeriggio la volta successiva.
Dove tutto questo si collega
Il problema delle evidenze e il problema della sicurezza sono lo stesso problema visto da due lati. Il nostro percorso sicurezza e conformità Microsoft 365 copre la postura, e conformità ISO e prontezza agli audit copre la tracciabilità delle evidenze. Abbiamo scritto in precedenza sulla mappatura delle impostazioni Microsoft 365 su Cyber Essentials e ISO 27001, e quella mappatura vale ancora; ciò che è cambiato è la conseguenza di sbagliarla.
L'igiene degli account si sovrappone quasi completamente al lavoro su ingressi, spostamenti e uscite, quindi eseguire correttamente la checklist di offboarding Microsoft 365 ne fa una parte al posto vostro.
Dove si inserisce EtherInsights
Raccogliere queste evidenze a mano, ogni anno, su un intero tenant è esattamente il tipo di lavoro che viene rimandato finché non diventa urgente. EtherInsights esiste anche per questo. Riporta la copertura di identità e MFA, lo stato dei dispositivi e di Intune, e la configurazione del tenant da un unico punto, così che il passaggio di scoperta diventi un report che potete rieseguire l'anno prossimo e confrontare con quello di quest'anno.
Per i fornitori di servizi gestiti la moltiplicazione è il punto: la stessa checklist su venti tenant sono venti esercizi di scoperta, e gli account che non superano la verifica in uno tendono ad apparire identici nel successivo. Eseguirla come un report ripetibile è ciò che rende sopportabile il rinnovo annuale, e sicurezza e conformità Microsoft 365 è dove postura ed evidenze stanno insieme.
Esplora sicurezza e conformità Microsoft 365 per vedere come postura, evidenze e rivalutazione annuale si uniscono in un unico posto.