Microsoft esegue davvero il backup della configurazione del tenant, quindi la risposta onesta a "la nostra configurazione è protetta" è sì, entro un ambito definito e su un orizzonte breve. Microsoft Entra Backup and Recovery esegue backup giornalieri automatici degli oggetti di directory supportati, comprese le policy di accesso condizionale e le named location, e conserva fino a sette giorni di storico dei backup. Le Tenant Configuration Management API in Microsoft Graph vi permettono di fotografare le impostazioni attuali come baseline e di monitorare la deriva rispetto a essa, con ogni snapshot conservato per un massimo di sette giorni. Microsoft 365 Backup protegge separatamente i dati di SharePoint, OneDrive ed Exchange con una conservazione di un anno. La domanda progettuale per una PMI del Regno Unito o per un MSP non è quindi l'assenza. È l'orizzonte e l'ambito: una finestra di ripristino di sette giorni sotto un ciclo di audit misurato in mesi.
Backup dei dati e backup della configurazione sono problemi diversi
Microsoft 365 Backup è un prodotto valido e merita una descrizione precisa. Esegue il backup di tutti o di alcuni siti SharePoint, account OneDrive e cassette postali Exchange, con un periodo di conservazione di un anno per tutti e tre e punti di ripristino a intervalli di dieci minuti per la finestra recente. Un sito completo o un account OneDrive viene ripristinato esattamente allo stato precedente, i ripristini di Exchange possono riguardare l'intera cassetta postale oppure singoli elementi trovati tramite ricerca, e i backup risiedono su storage ad aggiunta sola dentro il confine di fiducia dei dati di Microsoft 365, così da non poter essere sovrascritti da un'azione di servizio o di malware.
Ciò che protegge è il contenuto. Non protegge le impostazioni che decidono chi arriva a quel contenuto: la policy di accesso condizionale, la configurazione di condivisione, la regola di trasporto, l'assegnazione di ruolo. Perdere un file e perdere la regola che proteggeva diecimila file sono incidenti diversi con percorsi di ripristino diversi, e confonderli è il modo in cui i team danno per coperto un vuoto.
Cosa dice il modello di responsabilità condivisa di Microsoft
Microsoft pubblica apertamente la ripartizione, e la tabella merita di essere letta anziché parafrasata. Nella matrice delle responsabilità su Microsoft Learn, la riga "Configurations and settings" è responsabilità del cliente in ogni colonna: on-premises, IaaS, PaaS e SaaS. Lo sono anche "Customer data" e "Identities and users". L'articolo afferma che per tutti i tipi di distribuzione cloud i dati e le identità sono vostri, ed elenca dati, endpoint, account e gestione degli accessi come responsabilità che mantenete sempre.
Non è un vuoto della piattaforma. È il contratto, dichiarato con chiarezza, e significa che "di chi è il nostro insieme di policy di accesso condizionale" ha una risposta documentata. Decidere come dovrebbe essere fatto bene, e dimostrare com'era lo scorso trimestre, sta dal vostro lato della linea.
Dati e configurazione seguono percorsi separati, con conservazioni separate, e solo uno dei due arriva a un anno.
Cosa fornisce oggi Microsoft per la configurazione
Due funzionalità fanno gran parte del lavoro, e molti runbook non hanno recepito né l'una né l'altra.
Microsoft Entra Backup and Recovery ripristina oggetti di directory critici a uno stato precedente noto come buono dopo modifiche accidentali o una compromissione. Gli oggetti supportati comprendono utenti, gruppi, app, service principal, policy di accesso condizionale, named location, la policy dei metodi di autenticazione e la authorization policy per proprietà selezionate. I backup vengono eseguiti automaticamente una volta al giorno e conservano fino a sette giorni di storico. Nessuno può disattivarli: Microsoft afferma che nessun utente connesso né alcuna applicazione, nemmeno con i privilegi amministrativi più alti, può disattivare, eliminare o modificare i backup nel tenant. Richiede un tenant workforce con Microsoft Entra ID P1 o P2, e l'accesso passa da due ruoli, Backup Reader e Backup Administrator. La funzione più sottoutilizzata è il report delle differenze: prima di ripristinare qualsiasi cosa, confrontate lo stato attuale del tenant con un backup ed esaminate esattamente quali attributi e quali collegamenti sono cambiati. Microsoft continua ad ampliare l'elenco supportato, quindi ricontrollatelo anziché fidarvi di una nota dell'anno scorso.
Le Tenant Configuration Management API in Microsoft Graph affrontano lo stesso problema dal lato delle impostazioni, attraverso i carichi di lavoro anziché sulla sola directory. Le API di snapshot estraggono la configurazione attuale come baseline che rappresenta lo stato desiderato, e le API di monitoraggio la confrontano con quella baseline e segnalano le derive, che risolvete nell'interfaccia di amministrazione pertinente. I limiti pubblicati vi dicono come progettare intorno a esse: ogni monitor viene eseguito a un intervallo fisso di sei ore, potete creare fino a trenta monitor per tenant, e potete monitorare fino a ottocento risorse di configurazione al giorno per tenant su tutti quanti. Impostarlo significa aggiungere prima il service principal di Tenant Configuration Management al tenant e concedergli i permessi.
L'orizzonte di sette giorni, contro un ciclo annuale
Entra Backup and Recovery conserva fino a sette giorni di storico dei backup. Uno snapshot di Tenant Configuration Management viene conservato per un massimo di sette giorni, poi eliminato automaticamente. Entrambi sono dimensionati per il ripristino da incidente, che è a cosa servono, e in quello sono bravi: qualcosa si è rotto stamattina, confrontate, ripristinate, andate avanti.
Un ciclo di audit non ha quella forma. Le visite di certificazione tornano ogni anno, le revisioni dei clienti ogni trimestre, e le domande arrivano in ritardo. Se un'esclusione di accesso condizionale è stata aggiunta a marzo e un valutatore chiede a novembre com'era la policy prima, una finestra di sette giorni non può rispondere, e per impostazione predefinita non può farlo nemmeno la registrazione del cambiamento, dato che i log di audit di Microsoft Entra vengono conservati sette giorni su Entra ID Free e trenta giorni su P1 e P2. Quella metà del problema ha una trattazione a parte in quanto durano davvero le vostre evidenze di sicurezza Microsoft 365.
Quindi lo stato scade in una settimana e la registrazione del cambiamento in un mese. Qualsiasi cosa dobbiate dimostrare oltre quel punto deve essere catturata da voi, prima che la finestra si chiuda.
Cosa c'è nell'elenco supportato, e cosa no
Leggete l'elenco degli oggetti supportati come un elenco di inclusione, non come un riassunto. Entra Backup and Recovery non supporta il ripristino o la ricreazione di oggetti eliminati in modo definitivo. Utenti eliminati in modo reversibile, gruppi Microsoft 365, gruppi di sicurezza cloud, registrazioni applicazione e service principal possono essere ripristinati per trenta giorni, e il servizio integra quel comportamento anziché sostituirlo. Gli oggetti governati in Active Directory Domain Services richiedono un approccio alternativo, anche se potete creare report delle differenze per gli oggetti sincronizzati, e per alcuni tipi come i gruppi potete spostare la source of authority nel cloud.
Sul lato Tenant Configuration Management il vincolo è la quota anziché un elenco fisso. Ottocento risorse monitorate al giorno sembrano generose finché non contate ogni policy, regola e impostazione che vorreste tenere d'occhio. L'esempio svolto di Microsoft usa venti regole di trasporto e trenta policy di accesso condizionale nella baseline di un monitor, il che dà un'idea della granularità prevista.
L'esercizio utile è un inventario di una pagina: per ogni area di configurazione che porta un rischio reale, annotate quale meccanismo la copre, quale sia la conservazione, e chi si accorgerebbe di un cambiamento. La maggior parte dei team trova due o tre aree con la terza colonna vuota.
L'eliminazione è rumorosa, la modifica è silenziosa
Una policy di accesso condizionale eliminata si annuncia da sola. Gli accessi si rompono, il service desk si accende, qualcuno indaga entro l'ora, e sette giorni bastano e avanzano.
Una policy modificata non annuncia nulla. Aggiungete un gruppo a un elenco di esclusione, allentate un controllo di sessione, allargate una named location, e tutto continua a funzionare. È proprio lo scopo del cambiamento, sia che sia stato fatto in fretta per un motivo legittimo, sia da qualcuno che non avrebbe dovuto poterlo fare. Nulla si rompe, quindi nulla induce un'indagine, e lo stato che avrebbe mostrato il prima scade in silenzio.
È per questo che nel quotidiano il rilevamento conta più del ripristino. I report delle differenze e il monitoraggio della deriva rispondono entrambi a "cosa è cambiato" anziché a "rimettilo com'era", e l'intervallo di sei ore dà fino a quattro confronti al giorno con la vostra baseline. Un avvertimento merita un posto nel vostro runbook: quando un amministratore aggiorna la baseline di un monitor esistente, tutti i risultati di monitoraggio già generati e le derive rilevate per quel monitor vengono automaticamente eliminati. Rifare la baseline è legittimo dopo un cambiamento approvato, ed è anche una cancellazione, quindi registrate quando e perché lo avete fatto.
Come si presenta una risposta proporzionata
Per un'organizzazione piccola o media, o per un MSP che gestisce molti tenant, questo non deve diventare un programma. Confermate prima il diritto d'uso, dato che Entra Backup and Recovery richiede P1 o P2. Prendete come baseline le impostazioni che portano rischio anziché tutto, tenendo l'elenco dentro la quota giornaliera. Esportate quella configurazione secondo una pianificazione verso un luogo che controllate voi, datata, così che la registrazione sopravviva all'orizzonte di sette giorni. Puntate il monitoraggio della deriva sulle policy dove un cambiamento silenzioso conterebbe di più, tipicamente accesso condizionale, condivisione esterna e assegnazione di ruoli privilegiati. Instradate i log di audit verso storage o analisi con una conservazione allineata al vostro ciclo di audit. Infine, mettete per iscritto chi può cambiare cosa, e trattate ogni rifacimento della baseline come un cambiamento a sé.
I controlli su cui un valutatore fa domande sono quelli che vale la pena monitorare, e la mappatura in impostazioni Microsoft 365 rispetto a Cyber Essentials e ISO 27001 è un buon punto da cui scegliere quali impostazioni si meritano un monitor. La checklist Cyber Essentials v3.3 copre i punti in cui le dichiarazioni di ambito affossano una valutazione, e la stessa disciplina del "dimostrate il numero, non lo screenshot" vale per gli endpoint, come in perché il vostro conteggio dispositivi Intune è sbagliato.
Dove si inserisce EtherInsights
Il lavoro qui sopra è semplice una volta e faticoso ogni mese, ed è lì che gli strumenti si guadagnano il posto. EtherInsights mantiene una vista datata della configurazione del tenant accanto al quadro di costi, licenze ed endpoint, così che un cambiamento di policy compaia come un evento con un prima e un dopo anziché come qualcosa che scoprite durante un audit. Su un parco multi-tenant offre la stessa vista di baseline e deriva per ogni cliente.
L'assurance della configurazione rientra nella storia dei controlli coperta da sicurezza e conformità Microsoft 365, e la metà operativa, chi ha cambiato cosa e se era approvato, appartiene a operazioni IT e conformità. Entrambe poggiano su una sola idea: tenete una baseline, sorvegliate la deriva, e conservate l'evidenza più a lungo di quanto la piattaforma sia progettata per conservarla.
Microsoft copre più di quanto facesse due anni fa, e lo copre bene. Progettate per l'orizzonte e per l'ambito, non per un'assenza che non esiste più.
Esplora sicurezza e conformità Microsoft 365 per vedere come baseline, deriva ed evidenze si uniscono su un tenant o su molti.