Il tuo tenant Microsoft 365 è infrastruttura cloud: centinaia di impostazioni rilevanti per la sicurezza tra Entra ID, Exchange Online, SharePoint e Teams, e vanno in drift esattamente come un account AWS non gestito. Un admin cambia un'impostazione durante un incidente e non la rimette mai a posto. Microsoft cambia un default in un aggiornamento del servizio. Un fornitore ottiene accesso guest per un pilot finito due trimestri fa. Nessuno rivede niente di tutto questo, perché il tenant è "una cosa dell'IT", non "una cosa di infrastruttura". Il posture scanning è la soluzione noiosa ed efficace: confrontare in modo continuo la configurazione reale del tenant con una baseline di sicurezza pubblicata e riportare le lacune. E nel 2026 il modo pratico di eseguire quello scanner è come SaaS, il che significa controllare il cloud con il cloud. Questo post è il 101, con Aether365 come esempio. Trasparenza totale: Aether365 è un mio prodotto.

Un principio prima di iniziare: read-only è il default. Nulla ottiene accesso in scrittura al tuo tenant senza un consenso separato ed esplicito.

Tratta il tenant come un account di produzione

Se qualcuno gestisse AWS in produzione senza audit della configurazione, senza rilevamento del drift e senza cronologia delle modifiche, lo chiameresti negligenza. La maggior parte delle organizzazioni gestisce Microsoft 365 esattamente così, mentre contiene il loro identity provider, tutta la loro posta e la maggior parte dei loro file. Il tenant è il piano di identità per tutto il resto che gestisci; una configurazione sbagliata di Conditional Access lì vale per un attaccante più di un bucket S3 pubblico.

La mentalità da infrastruttura si trasferisce direttamente. Ti servono una baseline dichiarata, un confronto pianificato della realtà con quella baseline e un avviso quando le due divergono. Nel mondo AWS useresti le regole di Config o gli standard di Security Hub. Per Microsoft 365, gli equivalenti sono i benchmark di postura.

I tre benchmark da conoscere

Tre baseline coprono la maggior parte di ciò che conta, e ogni scanner serio si mappa su almeno una di esse:

  • CIS Microsoft 365 Foundations Benchmark: il più ampio, oltre 800 controlli sull'intera suite, dall'applicazione dell'MFA all'auditing delle mailbox alle policy di condivisione. La risposta di default a "audit rispetto a cosa?"
  • EIDSCA (Entra ID Security Configuration Analyzer): concentrato interamente su Entra ID, le impostazioni che decidono chi può autenticarsi, dare consensi e registrare applicazioni. Superficie piccola, raggio di esplosione massimo.
  • CISA ScuBA (Secure Cloud Business Applications): la baseline del governo federale statunitense per M365. Più severa e più opinionata; utile anche fuori dal settore pubblico come riferimento del tipo "cosa farebbe un bersaglio difficile".

I benchmark si sovrappongono, e va bene così. La sovrapposizione sui controlli di identità ti dice dove sta il consenso generale, e i finding su cui c'è consenso sono quelli da correggere per primi.

Script o SaaS: il vero trade-off

Puoi assolutamente eseguire questi controlli da solo. La Graph API è lì a disposizione, tooling di community come Maester ne incapsula buona parte, e un'esecuzione PowerShell pianificata contro un singolo tenant è un progetto da weekend. Mi piace questo approccio per imparare cosa fanno davvero i controlli.

Smette di scalare su tre assi. Manutenzione: i benchmark cambiano versione, gli endpoint di Graph cambiano, e la tua collezione di script diventa in silenzio un prodotto di cui sei proprietario. Cronologia: uno script puntuale ti dice lo stato di oggi, ma le domande di postura sono domande di tendenza, quando è regredito questo controllo e cosa è cambiato intorno. Multi-tenancy: nel momento in cui gestisci più di un tenant, un MSP con trenta clienti, per dire, gli script e le credenziali per tenant diventano loro stessi il rischio.

Uno scanner SaaS inverte lo scambio: gli concedi un consenso Microsoft Graph in sola lettura, esegue scansioni di conformità ed esposizione su pianificazione, giornaliera, settimanale o mensile, e conserva la cronologia. Il modello di consenso è la parte da esaminare con attenzione, perché stai collegando un servizio esterno al tuo piano di identità. La sola lettura deve essere il default e qualsiasi cosa oltre deve essere un consenso separato ed esplicito che puoi rifiutare. È quella singola proprietà a rendere il controllare-il-cloud-con-il-cloud accettabile per un tenant UE regolamentato.

Cosa copre Aether365

Aether365 è la mia versione di quello scanner. Il nucleo è la scansione di conformità rispetto a tutti e tre i benchmark sopra più la scansione dell'esposizione, pianificata per tenant, con gestione multi-tenant per gli MSP, notifiche via Teams ed email, e una REST API più un server MCP integrato se vuoi che il tuo assistente AI interroghi i risultati delle scansioni. Ha sede nell'UE ed è conforme al GDPR, scegli la tua regione dati alla registrazione, e i dati di scansione non vengono mai usati per addestrare alcun modello.

Due capacità vanno oltre la vista interna del tenant. External Attack Surface controlla cosa il tenant espone dall'esterno: i record SPF, DKIM e DMARC, che sono portanti per la posta di M365, la scadenza dei certificati con avvisi a 90 giorni, DNS pendenti e rischio di subdomain takeover, endpoint di autenticazione legacy lasciati aperti, e condivisioni pubbliche di SharePoint e OneDrive. E AI Pilot, opt-in e solo per i piani Pro ed Enterprise, trasforma i finding in fix Microsoft Graph concreti che approvi voce per voce prima che qualcosa venga applicato, con un audit trail verificato. La sola lettura resta il default; il percorso di scrittura è un consenso Microsoft separato che abiliti solo se lo vuoi. C'è un piano Free con scansioni mensili su un tenant, sufficiente per vedere il tuo primo punteggio CIS, e quel primo punteggio di solito è la motivazione.

Il punto da portare a casa

Il 101 è semplice: il tuo tenant Microsoft 365 merita la stessa disciplina di postura dei tuoi account cloud, i benchmark contro cui misurare esistono già, e la domanda operativa è solo se esegui lo scanner da solo o dai a un SaaS il consenso per farlo in sola lettura su pianificazione. Gli script ti insegnano i controlli; un servizio ti tiene onesto nel tempo. In entrambi i casi, la modalità di fallimento da evitare è il default attuale: nessuno che controlla nulla.

Leggi questo dopo

Per il lato AI della stessa piattaforma, perché la remediation ha bisogno di un gate di approvazione e a cosa serve davvero la reportistica generata dall'AI, leggi M365 Security 101: AI Pilot e Business Impact Reports su ercan.ai. Per consulenza su cloud, postura di sicurezza e lavoro di piattaforma, o anche solo per un saluto, parti da ercanermis.com.