Test di sicurezza Entra ID Maester ScubaGear: guida

Che cosa sono i test di sicurezza Entra ID Maester ScubaGear?

I test di sicurezza Entra ID Maester ScubaGear trasformano la revisione della configurazione di sicurezza in una valutazione ripetibile: scegliere asserzioni documentate, raccogliere le impostazioni del tenant, valutarle e conservare i risultati. Maester offre l’automazione dei test in PowerShell; ScubaGear valuta la configurazione di Microsoft 365 rispetto alle baseline CISA SCuBA. Il loro valore è una revisione che si può ripetere dopo una modifica, conservando l’ambito e le evidenze.

Un risultato di baseline risponde a una domanda delimitata. Può stabilire che un’asserzione corrisponde alla configurazione disponibile per la valutazione. Non stabilisce che tutti i percorsi di autenticazione siano protetti o che non si sia verificato alcun attacco alle identità. Il flusso seguente separa la misurazione della configurazione, l’analisi dei risultati, la correzione controllata e la verifica successiva. Include comandi documentati e identificativi di test reali, senza presentare un esempio come una valutazione di tenant che abbiamo eseguito.

Per le domande sulla copertura delle policy che precedono la scelta degli strumenti, consultare le lacune di copertura delle policy di base di accesso condizionale in Entra ID. L’articolo esamina l’esistenza di policy per amministratori, utenti, risorse e dispositivi. Questa guida si concentra sulla ripetibilità di una valutazione e sull’interpretazione dei suoi risultati.

Come funzionano gli strumenti: test Pester e valutazione delle policy SCuBA

Maester e le sue distinte suite di test

Maester è un framework PowerShell open source per mantenere la configurazione di sicurezza tramite test automatizzati. Il suo repository documenta test Pester personalizzati, esportazioni dei risultati e integrazioni nelle pipeline. Pester fornisce il modello di esecuzione dei test; Maester aggiunge test di sicurezza e report a quel modello. Il framework può essere esteso, quindi registrare i test effettivamente installati anziché considerare il nome del prodotto come una dichiarazione fissa di copertura. README del repository Maester.

Le suite hanno origini diverse. La suite Maester contiene test di configurazione di sicurezza della comunità. La suite EIDSCA si basa su Entra ID Security Config Analyzer e verifica le mitigazioni per scenari di attacco alle identità. La suite CISA verifica la configurazione di Microsoft 365 rispetto alle indicazioni SCuBA. Conservare la suite e l’identificativo del test insieme a ogni risultato, per consentire al lettore di distinguerne le fonti.

I test CISA di Maester non stabiliscono che Maester esegua il motore OPA di ScubaGear. Condividere le indicazioni di baseline non stabilisce nemmeno che le implementazioni siano identiche. Nel confrontare i riscontri, usare il requisito, l’implementazione del test e la versione esaminata. Due test con nomi simili possono verificare condizioni diverse, come mostrano gli esempi di autenticazione legacy qui sotto.

ScubaGear e le baseline per prodotto

ScubaGear appartiene al progetto Secure Cloud Business Applications di CISA. La sua valutazione documentata separa raccolta e valutazione: PowerShell interroga le API Microsoft 365, Open Policy Agent valuta le impostazioni raccolte rispetto alle policy Rego e lo strumento genera risultati HTML, JSON e CSV. Il documento di baseline descrive l’aspettativa di sicurezza; la sua implementazione automatizzata determina ciò che l’esecuzione può misurare. README di ScubaGear.

Il repository fornisce documenti di baseline separati per Entra ID, la suite di prodotti di sicurezza, Exchange Online, Power BI, Power Platform, SharePoint e Teams. La presenza di un documento di baseline non prova che ogni versione possa eseguire la valutazione di ogni prodotto. In particolare, la tabella dei parametri v1.8.0 indica Entra ID come aad ed elenca i selettori di prodotto accettati. Controllare quella tabella prima di scegliere un prodotto. README della versione, parametri v1.8.0.

Per attività focalizzate su Entra, consigliamo di iniziare con il selettore aad e verificarne i prerequisiti. Estendere agli altri prodotti quando le connessioni necessarie, i ruoli e i responsabili delle evidenze sono pronti. È una raccomandazione operativa, non un’affermazione che il resto di Microsoft 365 sia valutato soltanto tramite Graph.

Separare le versioni dalla documentazione in evoluzione

I riferimenti alle versioni verificati il 3 ottobre 2026 per questa guida sono Maester 2.2.0 e ScubaGear v1.8.0. Alla data della revisione, il README main di ScubaGear descrive già la v2.0.0. Questa guida identifica quindi esplicitamente i riferimenti a esecuzione e autorizzazioni v1.8.0; le affermazioni sulla documentazione delle baseline in evoluzione sono citate separatamente. Prima di adottare questi esempi, fissare la versione del modulo, le versioni delle dipendenze e la revisione dei test come specifica della valutazione.

Preparare l’accesso Graph in lettura prima della valutazione

L’accesso in lettura ha due dimensioni: ciò che fa lo strumento e ciò che la sua identità è autorizzata a fare. Microsoft Graph distingue l’accesso delegato, per conto di un utente connesso, dall’accesso applicativo senza quell’utente. Il consenso e i ruoli di directory supportati restano rilevanti. Creare un’applicazione, concedere il consenso o configurare l’autenticazione è preparazione amministrativa; va distinta dalle successive letture della configurazione. Riferimento delle autorizzazioni Graph, autenticazione Graph PowerShell.

Ad esempio, elencare le policy di accesso condizionale è un’operazione Graph in lettura la cui autorizzazione documentata è Policy.Read.All. Il requisito di quell’endpoint non è evidenza sufficiente per concedere accesso a un’intera suite di valutazione: altri test leggono altre risorse. List conditionalAccessPolicies.

Ambiti predefiniti di Maester

Il codice sorgente Get-MtGraphScope 2.2.0 definisce gli ambiti di lettura predefiniti, inclusi gli accessi a directory, policy, audit, report, gestione dei dispositivi, rischio delle identità e metodi di autenticazione. È l’elenco del framework, non il minimo per un singolo test di accesso condizionale. Directory.Read.All, ad esempio, è più ampio della sola lettura della raccolta di policy.

Lo stesso codice separa le aggiunte facoltative: -Privileged aggiunge ReportSettings.ReadWrite.All, -SendMail aggiunge Mail.Send e -SendTeamsMessage aggiunge ChannelMessage.Send. Tenere queste aggiunte fuori da una valutazione Graph predefinita in lettura, salvo che un requisito esaminato separatamente le richieda. Connect-Maester spiega le connessioni facoltative e il comportamento degli ambiti privilegiati.

Non descrivere Maester come incapace di leggere i log. Il suo elenco predefinito include AuditLog.Read.All e ThreatHunting.Read.All; le definizioni delle autorizzazioni di Microsoft descrivono letture di audit e query di ricerca delle minacce. Il punto più circoscritto è che i test di baseline qui trattati sono asserzioni di configurazione. Il loro successo non prova che uno specifico accesso sia stato bloccato.

Prerequisiti Entra di ScubaGear

ScubaGear v1.8.0 documenta Global Reader per la valutazione interattiva di Entra e queste autorizzazioni Graph: Directory.Read.All, Policy.Read.All, PrivilegedAccess.Read.AzureADGroup, PrivilegedEligibilitySchedule.Read.AzureADGroup, RoleManagement.Read.Directory, RoleManagementPolicy.Read.AzureADGroup e User.Read.All. Esaminare il processo effettivo di consenso con l’amministratore del tenant prima dell’esecuzione. Prerequisiti interattivi.

I suoi prerequisiti non interattivi elencano le autorizzazioni per prodotto. Spiegano inoltre che SharePoint e Power Platform richiedono autorizzazioni con privilegi di scrittura a causa dei requisiti delle API, mentre ScubaGear non usa tali privilegi per le valutazioni. Di conseguenza, una valutazione di tutti i prodotti non va descritta come basata esclusivamente su autorizzazioni di lettura. Questa distinzione vale anche quando si esaminano le connessioni di servizio facoltative di Maester.

Eseguire i comandi documentati e conservarne l’ambito

I comandi seguenti sono esempi della documentazione. Non sono stati eseguiti su un tenant per questo articolo. Predisporre e verificare prima l’ambiente di valutazione; poi usare la documentazione corrispondente alla versione selezionata.

Passaggio 1: preparare i test Maester

La guida all’installazione fornisce il comando di installazione di Pester:

Install-Module Pester -MinimumVersion 5.7.1 -MaximumVersion 5.7.1 -SkipPublisherCheck -Force -Scope CurrentUser

Installa Maester separatamente:

Install-Module Maester -Scope CurrentUser

Quel comando non fissa la versione di Maester. Determinare la versione prevista prima di usarlo per produrre evidenze riproducibili. Dalla directory di test scelta, la guida installa i test forniti:

Install-MaesterTests

Passaggio 2: connettersi e valutare

L’esempio di connessione Graph in Connect-Maester è:

Connect-Maester

La stessa documentazione e la funzione di supporto degli ambiti della versione forniscono questo equivalente Graph diretto. Usa l’elenco di ambiti fornito dal modulo Maester installato:

Connect-MgGraph -Scopes (Get-MtGraphScope)

Sono approcci alternativi di connessione. L’esempio Graph diretto non è un motivo per eseguirli entrambi. Una volta disponibili i test, il comando di valutazione documentato è:

Invoke-Maester

Il riferimento Invoke-Maester descrive selezione del percorso dei test, tag, esclusioni e output dei report. Registrare la selezione usata nell’esecuzione. Fornisce anche un esempio esplicito di output HTML:

Invoke-Maester -OutputHtmlFile './test-results/TestResults.html'

Scegliere quella variante di report quando opportuno. È un’altra invocazione della valutazione, non un semplice comando che rinomina un report esistente. Moduli o connessioni di servizio facoltativi mancanti possono causare l’omissione di test, come spiega la guida all’installazione.

Passaggio 3: scegliere deliberatamente i prodotti ScubaGear

La guida all’esecuzione v1.8.0 descrive l’esecuzione su Windows, le dipendenze richieste e l’importazione di un modulo scaricato in PowerShell 5.1. Il suo esempio letterale per tutti i prodotti è:

Invoke-SCuBA -ProductNames *

Questo illustra il carattere jolly documentato; usarlo solo dopo aver esaminato i prerequisiti dell’ambito esteso. Per la raccomandazione di questa guida limitata a Entra, sostituire il carattere jolly con aad, usando il parametro di prodotto documentato. Questa sostituzione è un adattamento dell’esempio, non un comando riportato alla lettera dalla guida all’esecuzione. Conservare la selezione di prodotti risultante nel registro dell’esecuzione.

Misurare ciò che i risultati stabiliscono effettivamente

Maester fornisce risultati dei test ed esportazioni dei report. ScubaGear fornisce un report HTML globale, report dei singoli prodotti, JSON strutturato e CSV dei risultati. Il JSON di ScubaGear può conservare il contesto di esecuzione e l’output del provider, secondo le opzioni; ScubaResults.csv è un’esportazione di risultati più limitata. Il suo ActionPlan.csv filtra i controlli SHALL falliti e include spazio per spiegazioni dei fallimenti e scadenze di correzione. Non è il registro completo della valutazione. Funzioni di esportazione Maester, report ScubaGear.

Consigliamo di esaminare i risultati in code separate:

Queste sono raccomandazioni di gestione, non etichette di risultati inventate per ogni versione di uno dei due strumenti. Evitano di scambiare una variazione della popolazione valutata per un miglioramento. Un confronto operativo utile registra quali asserzioni sono state eseguite con successo, quali non hanno potuto essere eseguite e quali richiedono un altro metodo.

La baseline Entra SCuBA attuale limita esplicitamente la valutazione automatizzata delle condizioni di accesso condizionale a quelle specificate nelle sue implementazioni. Indica inoltre alcuni requisiti come manuali. Un risultato automatizzato positivo lascia quindi aperte domande su condizioni, eccezioni e verifica operativa che l’asserzione non copre.

Per l’indagine complementare, leggere le lacune di accesso condizionale e le evidenze di accesso. L’articolo esamina l’applicazione effettiva delle policy, le esclusioni e i percorsi di autenticazione. Integra un report di baseline senza trasformare i test di configurazione in un’affermazione su ogni accesso.

Rilevamento tramite valutazioni ricorrenti e CI

La valutazione ricorrente delle baseline rileva cambiamenti tra configurazioni osservate con successo. Consigliamo di conservare identificativo del tenant, timestamp, versione, revisione dei test, ambito dei prodotti, profilo delle autorizzazioni, errori, report ed eccezioni per ogni esecuzione. Confrontare elementi omogenei. Se cambia una suite o una dipendenza, identificare prima se la differenza deriva dalla configurazione del tenant, dalla logica dei test o dalla copertura della raccolta.

La guida al monitoraggio GitHub di Maester documenta la federazione delle identità dei workload con OIDC, le autorizzazioni applicative, l’esecuzione pianificata e l’avvio manuale dei workflow. Il suo esempio di pianificazione viene eseguito ogni giorno alle 07:30 UTC. Scegliere una frequenza adatta alle esigenze operative; l’esempio non stabilisce un intervallo di risposta appropriato per ogni tenant. -NonInteractive controlla la presentazione, inclusa la soppressione dell’apertura del browser, e non configura l’autenticazione. Riferimento dei parametri Invoke-Maester.

La documentazione di esecuzione di ScubaGear descrive l’esecuzione con un’entità servizio basata su certificato per pipeline e processi pianificati. I prerequisiti della versione devono governare l’impostazione delle autorizzazioni. Consigliamo di tenere gli identificativi delle applicazioni e i riferimenti ai certificati nella configurazione del processo, gestendo la chiave privata effettiva tramite la procedura per le credenziali approvata dall’organizzazione. Trattare provisioning e manutenzione delle credenziali come attività amministrative separate.

Per entrambi gli strumenti, consigliamo di fissare insieme modulo, test, dipendenze e revisione dell’azione CI. Un fallimento del processo deve avviare un’indagine operativa anziché riutilizzare il risultato favorevole di ieri come evidenza di oggi. Indirizzare le regressioni di configurazione ai rispettivi responsabili e conservare il motivo di ogni eccezione accettata. Sono raccomandazioni di flusso di lavoro; qui non si afferma alcuna esecuzione di pipeline né alcuna prestazione di risposta.

Una pianificazione delle valutazioni produce osservazioni al momento delle esecuzioni. Non può provare che la configurazione sia rimasta invariata tra l’una e l’altra. Affiancare la valutazione ricorrente al processo esistente di monitoraggio della sicurezza e rendere visibile ai revisori la data dell’ultima raccolta riuscita.

Correzione: da un test fallito a una modifica verificata (Remediation)

Passaggio 1: leggere con precisione Maester MT.1009

MT.1009 verifica la presenza di una policy di accesso condizionale che blocca altre autenticazioni legacy. L’implementazione esaminata seleziona le policy abilitate, rimuove quelle contenenti passwordChange e cerca una concessione di blocco con tipo di client other, applicazioni incluse All e utenti inclusi All. Restituisce false se nessuna corrisponde. Una condizione di licenza Entra Free o un errore intercettato può invece produrre un risultato omesso.

Se quel test fallisce nella valutazione, esaminare i dati selezionati e confermare che il fallimento rappresenti il requisito previsto. La funzione non prova che non esistano esclusioni o che ogni connessione pertinente sia bloccata. La sua implementazione è un punto di partenza concreto per l’indagine, non un simulatore completo di policy. Conservare la revisione del codice sorgente insieme al riscontro per distinguere i successivi cambiamenti di implementazione dalla correzione.

Passaggio 2: confrontare SCuBA MS.AAD.1.1v1 senza presumere equivalenza

MS.AAD.1.1v1 nella baseline v1.8.0 richiede il blocco dell’autenticazione legacy. Le istruzioni di implementazione richiedono di identificare le dipendenze legacy esistenti, selezionare tutti gli utenti e tutte le risorse, selezionare Exchange ActiveSync e Other clients e concedere Block Access. Il solo test other di MT.1009 non rappresenta tutte queste istruzioni. Sono identificativi Maester e SCuBA, non numeri di controlli CIS.

Consigliamo di aprire una scheda di correzione contenente l’identificativo fallito, i dati di policy valutati, il requisito pertinente, il responsabile, le dipendenze interessate e la modifica proposta. Se un risultato è omesso, aprire prima un’indagine sui prerequisiti. Se è manuale, documentare il metodo manuale. Nessuno di questi esempi è un fallimento osservato in un tenant valutato per questo articolo.

Passaggio 3: convalidare l’impatto prima dell’applicazione

La guida Microsoft al blocco dell’autenticazione legacy avvia la nuova policy in report-only, verifica l’impatto e la porta a On dopo la convalida. Seguire il trattamento documentato degli account di accesso di emergenza e degli eventuali rilasci graduali necessari. Identificare le dipendenze legacy legittime e pianificarne la migrazione o un’eccezione esplicitamente governata prima dell’applicazione estesa.

Consigliamo di testare percorsi rappresentativi degli accessi previsti e verificare con i loro responsabili le evidenze dell’impatto della policy. Registrare esattamente quando viene abilitata l’applicazione. Una policy report-only è utile per valutare l’impatto, ma non può stabilire che il blocco previsto sia stato applicato. Non eliminare la convalida soltanto per soddisfare un’asserzione automatizzata che cerca uno stato abilitato.

Passaggio 4: rieseguire e pianificare la stessa revisione

Dopo la modifica approvata, rieseguire i test Maester pertinenti o la valutazione del prodotto ScubaGear con la selezione e le versioni conservate. Esaminare i nuovi dati oltre al risultato. Allegare entrambe le valutazioni alla scheda di correzione e confermare separatamente il comportamento previsto tramite il processo documentato di revisione dell’impatto delle policy e degli accessi. Riferimento di esecuzione Maester, esecuzione ScubaGear, procedura di convalida Microsoft.

Consigliamo di aggiungere l’asserzione risolta alla revisione ricorrente, con un responsabile delle regressioni e una scadenza delle eccezioni. Se l’esecuzione successiva perde autorizzazioni o omette il test, riaprire la questione delle evidenze. Chiudere una scheda di correzione dovrebbe significare che il requisito definito è stato ricontrollato e la sua convalida operativa completata.

Come EtcSec rileva queste lacune

AZ_CIS_BENCHMARK_GAPS di EtcSec è un aggregato di configurazione che contiene quattro controlli indipendenti. L’implementazione letta è public/internal/audit/detectors/azure/compliance/standards/cis-benchmark-gaps.go, con Detect() che inizia alla riga 68. Ogni condizione conteggiata aggiunge uno; Count va da 0 a 4. Non è una percentuale né l’intero CIS Microsoft 365 Foundations Benchmark.

Queste condizioni sono visibili nello stesso file alle righe 82–178. L’avviso AZURE_CONDITIONAL_ACCESS_POLICIES_FAILED sopprime i tre controlli basati sulle policy. Dati del tenant mancanti possono lasciare non conteggiato il controllo Security Defaults. Senza quell’avviso, una raccolta di policy vuota conta le tre assenze di policy. Quindi Count = 0 non prova che tutte e quattro le condizioni siano state valutate con successo.

La funzione restituisce il riscontro anche a zero; un conteggio positivo e IncludeDetails governano l’inclusione dei dettagli delle lacune. Legge configurazione e avvisi di raccolta, senza consumare risultati Maester, report ScubaGear o evidenze di accesso. Usarla per seguire queste quattro condizioni negli audit EtcSec, poi indagarne l’ambito. Mantenere la valutazione completa delle baseline e la convalida operativa dell’applicazione come parti distinte della revisione.