Per dimostrare che un'impostazione Microsoft 365 non è cambiata dall'ultimo audit servono tre cose che la piattaforma non conserva al posto vostro: uno snapshot datato della configurazione, una registrazione di ogni cambiamento tra uno snapshot e l'altro, e una nota su chi ha autorizzato ciascuno di essi. I soli log non bastano. Microsoft Entra conserva i dati di audit e di accesso per 7 giorni sul piano Free e 30 giorni su P1 e P2. Microsoft Purview Audit (Standard) conserva la maggior parte dei record per 180 giorni. Il vostro ciclo di certificazione è 365. Il divario tra questi numeri è la parte dell'anno che non potete dimostrare con la sola piattaforma.
Non è una critica alle impostazioni predefinite. La conservazione è dimensionata per l'indagine operativa, dove la finestra utile si misura in giorni. L'assurance pone una domanda diversa su un arco più lungo, e colmare la differenza è compito vostro.
La domanda a cui nessuno si prepara
La maggior parte dei team si prepara alla valutazione sbagliata. Fotografa lo stato attuale, conferma che l'autenticazione a più fattori è applicata oggi, e produce un pacchetto ordinato che mostra un tenant in salute.
Poi il valutatore pone una domanda di forma diversa. Non "questa policy è attiva" ma "è stata attiva dall'ultima volta che ci siamo parlati, e se è mai stata disattivata, chi l'ha disattivata e chi ha ritenuto accettabile la cosa". Venite verificati sul fatto che la configurazione abbia retto per l'intero periodo.
Nella maggior parte dei tenant nessuno lo sa. Qualcuno può aver aggiunto un'esclusione a febbraio e averla rimossa a marzo, e in autunno nulla se ne ricorda. Il cambiamento era legittimo. È l'assenza di una registrazione a diventare il rilievo.
Cosa conserva la piattaforma, e per quanto
Contano tre finestre di conservazione, e non sono la stessa.
Log di audit e di accesso di Microsoft Entra. Sette giorni su Microsoft Entra ID Free, 30 giorni su P1 e P2. È qui che vivono i cambiamenti di directory: modifiche alle policy di accesso condizionale, assegnazioni di ruolo, consensi applicativi. Le modifiche alla conservazione non sono retroattive, quindi passare da Free a P1 vi dà 30 giorni da lì in avanti, non 30 giorni di storico.
Microsoft Purview Audit (Standard). 180 giorni per impostazione predefinita, non 90. È cambiato il 17 ottobre 2023, e molta documentazione interna dice ancora 90. I record generati prima di quella data mantengono il vecchio periodo di 90 giorni; quelli successivi ottengono 180 giorni. Questo è il log di audit unificato che copre Exchange, SharePoint, OneDrive, Teams e altro, un sistema separato dai log Entra.
Microsoft Purview Audit (Premium). La policy di conservazione predefinita di un anno è più stretta di quanto il nome suggerisca. Copre i record di Microsoft Entra, Exchange, SharePoint e OneDrive, e solo per gli utenti che hanno una licenza Office 365 o Microsoft 365 E5, una licenza Microsoft Purview Suite, oppure il componente aggiuntivo E5 eDiscovery and Audit. Gli utenti non E5 e i guest restano a 180 giorni, così come l'attività degli altri carichi di lavoro, salvo diversa indicazione di una policy personalizzata.
I log della piattaforma scadono secondo un calendario operativo; l'assurance corre su uno da dodici mesi.
Il disallineamento, svolto con date reali
Prendete un tenant certificato il 14 ottobre 2025 con il rinnovo fissato per ottobre 2026. Il 12 ottobre 2026 il valutatore chiede se la policy che impone l'autenticazione a più fattori sia stata applicata senza interruzioni da quando è stato emesso il certificato, e se siano state aggiunte esclusioni. Tornate indietro da quella data su Entra ID P1:
- Il log di audit di Entra risponde fino al 12 settembre 2026. Trenta giorni. Mostra qualsiasi modifica di policy dell'ultimo mese e chi l'ha fatta.
- Purview Audit (Standard) risponde fino a circa il 15 aprile 2026. Sei mesi, meno della metà dell'anno di certificato.
- Purview Audit (Premium), se lo avete, risponde fino al 12 ottobre 2025 per i record Entra, ma solo per gli utenti coperti da una licenza di classe E5. Su Business Premium o su un parco misto, quella porta è chiusa.
Quindi sul tenant che la maggior parte delle organizzazioni gestisce, dal 14 ottobre 2025 alla metà di aprile 2026 non esiste alcuna registrazione della piattaforma interrogabile: sei mesi dell'anno di certificato in cui la risposta a "questa policy era applicata" è un'alzata di spalle.
Un dettaglio coglie chi risolve la cosa tardi. In Purview la conservazione applicata a un record viene decisa quando entra nella pipeline, quindi una policy personalizzata più lunga creata a settembre non estende i record generati a marzo. La conservazione si decide in anticipo, oppure non si decide.
La mappatura delle impostazioni Microsoft 365 sui controlli Cyber Essentials e ISO 27001 vi dice quali impostazioni portano un controllo. Questo articolo parla di dimostrare che hanno retto.
Tre artefatti che sopravvivono ai log
Lo snapshot di configurazione. Un'esportazione datata e leggibile da una macchina delle impostazioni che portano i vostri controlli. Non uno screenshot: uno screenshot dimostra come appariva una pagina, mentre un'esportazione JSON di una policy di accesso condizionale dimostra cosa conteneva, esclusioni comprese, e può essere confrontata con la copia del mese scorso.
La registrazione della deriva. La differenza tra snapshot consecutivi. Trasforma un mucchio di esportazioni in un ragionamento: ecco il 1 marzo, ecco il 1 aprile, ecco le quattro cose che sono cambiate. La deriva risponde a "è cambiato", la vera domanda del valutatore.
La registrazione di autorizzazione. Per ogni cambiamento nella registrazione della deriva, chi lo ha richiesto, chi lo ha approvato, e a fronte di quale ticket o decisione di rischio. Le organizzazioni quasi mai hanno questa, ed è quella che trasforma un rilievo in una risposta pulita.
Questi sopravvivono a qualsiasi periodo di conservazione dei log, perché siete voi a controllare dove risiedono. Conservateli in un luogo immutabile o versionato con diritti di scrittura ristretti, e calcolatene l'hash.
Costruire una baseline difendibile
Una baseline deve essere abbastanza completa da contare e abbastanza piccola da essere eseguita. Coprite le impostazioni da cui dipendono i vostri controlli: le policy di accesso condizionale con le loro esclusioni, la policy dei metodi di autenticazione, le assegnazioni di ruoli di directory comprese quelle idonee, le impostazioni di accesso tra tenant, i profili di conformità dei dispositivi, le impostazioni di condivisione a livello di tenant, e le applicazioni che detengono permessi consentiti. Un primo passaggio:
Connect-MgGraph -Scopes 'Policy.Read.All','Directory.Read.All','RoleManagement.Read.Directory'
$stamp = (Get-Date).ToString('yyyy-MM-dd')
$out = ".\baseline-$stamp"
New-Item -ItemType Directory -Path $out -Force | Out-Null
Get-MgIdentityConditionalAccessPolicy -All | ConvertTo-Json -Depth 12 | Set-Content "$out\conditional-access.json"
Get-MgPolicyAuthenticationMethodPolicy | ConvertTo-Json -Depth 12 | Set-Content "$out\auth-methods.json"
Get-MgDirectoryRole -All | ConvertTo-Json -Depth 8 | Set-Content "$out\directory-roles.json"
Get-ChildItem "$out\*.json" | Get-FileHash | Export-Csv "$out\hashes.csv" -NoTypeInformation
Contano due regole.
Eseguitela secondo una pianificazione. Una baseline non pianificata ha buchi che non potete spiegare, e un buco fa peggiore impressione di un cambiamento.
Fissate la cadenza più breve della vostra conservazione dei log più corta. Se il log di audit di Entra tiene 30 giorni e voi fate uno snapshot ogni trimestre, quando compare una differenza non riuscite a scoprire chi l'ha prodotta, perché la voce di audit che la nomina è scaduta settimane prima. Fate uno snapshot ogni settimana, o ogni due settimane come minimo, e ogni differenza resta attribuibile mentre il log che la spiega è ancora vivo.
Trasformare una registrazione di deriva in evidenza
Un diff vi dice cosa è cambiato. Un valutatore vuole sapere chi lo ha cambiato e chi era d'accordo. Unire le due cose è tutto l'esercizio, e deve avvenire dentro la finestra dei log. Per ogni oggetto modificato, estraete la voce corrispondente dal log di audit di Entra, che registra l'attore che ha avviato l'azione:
$since = (Get-Date).AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ')
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $since and category eq 'Policy'" -All |
Select-Object ActivityDateTime, ActivityDisplayName,
@{n='Actor';e={$_.InitiatedBy.User.UserPrincipalName}},
@{n='Target';e={$_.TargetResources[0].DisplayName}} |
Export-Csv ".\policy-changes-$((Get-Date).ToString('yyyy-MM-dd')).csv" -NoTypeInformation
Poi aggiungete ciò che la piattaforma non può conoscere: il riferimento di change e l'approvatore. Basta una riga per cambiamento. Data, oggetto, cosa è cambiato, chi lo ha cambiato, ticket, approvatore. Aggiunta a un registro che non viene mai troncato, quella riga risponde ancora alle domande fra tre anni.
Dove un cambiamento non ha né ticket né approvatore, registrate anche quello. Un valutatore è molto più a suo agio con "questo non era documentato, ecco cosa abbiamo fatto al riguardo" che con un registro che non contiene alcuna eccezione.
Deriva e igiene delle identità arrivano insieme, quindi un uscito che ha mantenuto un'esclusione è un ritrovamento comune; la checklist di offboarding copre quel punto.
Dove si rompe
Microsoft Entra ID Free. Sette giorni non è una finestra su cui far girare un processo mensile. Sistemate prima questo, ricordando che l'aggiornamento non riempie il passato.
Guest e utenti non E5. Il comportamento predefinito Premium si ferma al confine della licenza, quindi un parco misto ha una posizione di conservazione mista. Sappiate quali utenti sono coperti prima di contare su un anno di storico che esiste solo per alcuni di loro.
Esportazioni che nessuno può interrogare. Una cartella di PDF è un compito svolto, non un'evidenza. Se rispondere a "cosa è cambiato a marzo" significa aprire i file a mano, il processo verrà abbandonato.
Accesso delegato presso i fornitori di servizi gestiti. Quando è un partner a fare il cambiamento, l'attore nel log di audit del cliente è un'identità del partner mentre l'approvazione vive nel sistema del partner. Decidete quale parte detiene la registrazione di autorizzazione e come il cliente la ottiene, perché al rinnovo è il cliente a essere valutato. Questo appartiene al pacchetto di reporting mensile.
Dare per scontato che il rinnovo sia l'unica scadenza. Questionari assicurativi, revisioni di sicurezza dei clienti e richieste di assurance dei fornitori pongono la stessa domanda.
Dove si inserisce EtherInsights
Fare uno snapshot ogni settimana, confrontarlo e tenere un registro attribuibile è facile da descrivere e faticoso da sostenere a mano. EtherInsights esiste anche per questo: cattura la configurazione del tenant e lo stato delle identità, traccia cosa si è mosso tra una cattura e l'altra, e mantiene la registrazione interrogabile molto dopo che i log della piattaforma sono scaduti, così che l'evidenza per un rinnovo sia un report da rieseguire anziché due settimane di archeologia.
Per i partner la moltiplicazione è il punto, perché la stessa domanda arriva da ogni cliente nelle stesse poche settimane ogni autunno, e sicurezza e conformità Microsoft 365 è dove postura ed evidenze stanno insieme. La nostra checklist Cyber Essentials v3.3 copre cosa sistemare; questo copre come dimostrare che è rimasto sistemato. Conformità ISO e prontezza agli audit riprende la traccia di evidenze più ampia.
Esplora sicurezza e conformità Microsoft 365 per vedere come baseline, deriva e registrazione di autorizzazione si uniscono prima della prossima valutazione.