Che cosa sono le regole ASR Defender tramite GPO?
Le regole ASR Defender tramite GPO consentono agli amministratori di distribuire protezioni basate sul comportamento ai dispositivi Windows tramite Criteri di gruppo. Le regole di riduzione della superficie di attacco (ASR) intervengono su attività come la creazione di processi figlio da parte delle applicazioni Office o l’avvio di eseguibili scaricati da parte di script. La domanda utile è quali GUID di regole, modalità ed esclusioni siano effettivamente presenti sul dispositivo di destinazione, anziché limitarsi a verificare l’esistenza di un criterio ASR. Guida alla configurazione Microsoft
Un criterio può descrivere una protezione prevista senza dimostrare che ogni computer la riceva. La modalità Audit può registrare attività pertinenti senza bloccarle; le esclusioni possono cambiare ciò che una regola valuta. Esaminate insieme l’origine della distribuzione e la configurazione dei dispositivi prima di dichiarare la copertura.
Questa guida utilizza pagine Microsoft Learn controllate il 3 ottobre 2026 e l’implementazione esaminata di etc-collector. I comandi PowerShell sono esempi basati sulla documentazione per un amministratore Windows autorizzato; non sono stati eseguiti su un parco Windows per questo articolo. Non si affermano copertura dei dispositivi, prevalenza degli attacchi o correzioni riuscite.
Funzionamento: una matrice di regole, modalità ed esclusioni
La configurazione ASR è un elenco di regole con azioni individuali. In Gestione Criteri di gruppo, modificate la GPO prevista in Configurazione computer → Modelli amministrativi → Componenti di Windows → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Riduzione della superficie di attacco. Aprite Configura regole di riduzione della superficie di attacco, selezionate Attivato, quindi usate Mostra... per inserire ogni GUID di regola come nome del valore e la relativa modalità come valore. I modelli meno recenti possono usare Windows Defender Antivirus nel percorso. Procedura GPO di Microsoft
Le azioni numeriche documentate da Learn sono:
| Valore | Modalità | Significato per la verifica |
|---|---|---|
0 | Disattivata (Off) | La regola è disattivata. |
1 | Blocco (Block) | La regola è configurata per bloccare il comportamento previsto. |
2 | Audit | La regola registra l’attività per valutarla senza bloccare gli utenti. |
5 | Non configurata (Not configured) | Questa voce non stabilisce una decisione di applicazione. |
6 | Avviso (Warn) | Usare solo per le regole che supportano questa modalità; esaminare le deroghe degli utenti. |
I valori provengono dalla pagina di configurazione ASR. La disponibilità delle modalità, le dipendenze e il supporto del sistema operativo richiedono comunque una verifica specifica per ciascuna regola nella documentazione di riferimento delle regole ASR.
Create una matrice con una riga per ogni regola prevista e popolazione di destinazione. Le righe seguenti sono esempi di verifica, non un insieme completo di regole consigliato né misurazioni provenienti da un ambiente:
| Regola | GUID da Learn | Modalità prevista da registrare | Verifica delle esclusioni |
|---|---|---|---|
| Impedire a tutte le applicazioni Office di creare processi figlio | d4f940ab-401b-4efc-aadc-ad5f3c50688a | Registrare l’azione del progetto pilota, poi l’azione di applicazione approvata | Identificare i flussi di lavoro Office legittimi che avviano un altro processo; registrare eventuali eccezioni approvate. |
| Bloccare il furto di credenziali dal sottosistema dell’autorità di sicurezza locale di Windows | 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 | Registrare l’azione selezionata; Warn non è supportata | Esaminare l’applicabilità insieme alla protezione LSA esistente e a Credential Guard. |
Microsoft documenta una condizione sulla posizione di installazione per la regola Office: Office deve essere installato in %ProgramFiles% o %ProgramFiles(x86)%. Indica inoltre che la regola LSASS non è necessaria e non offre protezione aggiuntiva quando la protezione LSA è attivata, raccomandando tale protezione insieme a Credential Guard. Non considerate ogni regola disponibile un requisito incondizionato. Dettagli specifici delle regole
La nostra guida a Credential Guard dopo un aggiornamento spiega come verificare l’isolamento delle credenziali basato su VBS e una disattivazione ereditata. Queste evidenze non dimostrano la configurazione dell’insieme più ampio di regole comportamentali ASR. Tenete separate l’applicabilità delle protezioni e le rispettive misurazioni.
Stabilire quale origine di gestione prevale
Una voce GPO e un profilo Intune possono entrare in conflitto per la stessa regola. L’attuale pagina di configurazione Learn documenta che le impostazioni basate su criteri hanno precedenza sulle impostazioni locali Set-MpPreference all’avvio. La pagina descrive Criteri di gruppo come prevalente per impostazione predefinita rispetto a MDM, con MDMWinsOverGP=1 che favorisce MDM, e sconsiglia di configurare le stesse regole ASR tramite entrambe le origini. La guida alla risoluzione dei problemi di Defender, pubblicata separatamente da Microsoft, avverte che questo parametro non si applica alle regole ASR su Windows 10. Le pagine differiscono su questo limite: verificate il sistema operativo di destinazione e il risultato osservato del criterio anziché presumere che il parametro risolva ogni conflitto.
Esiste un altro limite esplicito: la configurazione controllata applica le impostazioni Intune o quelle della gestione delle impostazioni di sicurezza di Defender for Endpoint e ignora le impostazioni in conflitto di Criteri di gruppo, Configuration Manager e quelle locali. Verificate se questo meccanismo si applica prima di attribuire la responsabilità alla GPO. Gestione dei conflitti tra criteri di Microsoft
Registrate l’origine di gestione prevista, la popolazione di dispositivi, i profili in conflitto e le evidenze della configurazione che prevale. Una modifica temporanea con PowerShell locale può scomparire quando entra in vigore il criterio gestito. Non è quindi adatta come unica prova che la distribuzione gestita sia stata corretta.
Rilevamento: confrontare l’intento della GPO con la configurazione dei dispositivi
Passaggio 1: conservare il criterio previsto
Leggete l’elenco di GUID/azioni configurati e le esclusioni dalla GPO effettiva. Esaminate i suoi dati registry.pol decodificati per il ramo ASR di Windows Defender Exploit Guard, conservando l’identità della GPO e l’ora di raccolta insieme alle evidenze. Un file di criteri binario richiede una decodifica capace di interpretare i criteri; il solo nome del file non ne rivela le impostazioni.
Tenete distinto l’elenco per regola dal DWORD aggregato exploitguard_asr_rules usato dal parser del collector descritto più avanti. Un’impostazione aggregata attivata non è un inventario di GUID e azioni.
La nostra guida ai quattro controlli di sicurezza GPO Active Directory applica lo stesso metodo di verifica a LLMNR, WSUS, alla protezione LSA e ai percorsi UNC: confrontare l’intento del criterio, l’ambito di destinazione e le evidenze del client. Questi quattro controlli non dimostrano la copertura ASR; il loro rigore di verifica è utile in questo contesto.
Passaggio 2: leggere le preferenze del dispositivo di destinazione
Su ogni dispositivo valutato, recuperate le preferenze Defender. La documentazione di riferimento Get-MpPreference documenta il cmdlet e il comportamento locale predefinito. La pagina di configurazione ASR documenta le proprietà degli identificatori di regole e delle azioni.
Eseguite separatamente i comandi seguenti nella sessione PowerShell amministrativa del dispositivo:
$p = Get-MpPreference
$p.AttackSurfaceReductionRules_Ids
$p.AttackSurfaceReductionRules_Actions
Abbinate le voci secondo la posizione negli array: l’azione a un indice appartiene all’identificatore di regola allo stesso indice. Conservate l’output originale. Se manca uno degli elenchi, le lunghezze differiscono o la raccolta fallisce, registrate il risultato come irrisolto anziché scartare silenziosamente le voci o dichiarare la conformità.
Per una coppia di array allineati e non vuoti, questo esempio mostra la corrispondenza:
for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
[pscustomobject]@{
Id = $p.AttackSurfaceReductionRules_Ids[$i]
Action = $p.AttackSurfaceReductionRules_Actions[$i]
}
}
Esaminate le esclusioni ASR globali con il comando di lettura documentato da Microsoft:
(Get-MpPreference).AttackSurfaceReductionOnlyExclusions
Esaminate anche le esclusioni per regola nel criterio di gestione autorevole. Il solo elenco globale non costituisce una verifica completa delle eccezioni quando sono configurate esclusioni specifiche per regola. Configurazione delle esclusioni Microsoft
Confrontate ogni GUID e modalità previsti con l’output del dispositivo. Indagate sulle regole mancanti, sulle azioni inattese e sulle esclusioni inattese. Includete l’host, l’ora di osservazione e l’origine di gestione nel registro; ripetete dopo l’applicazione del criterio per distinguere un’impostazione locale transitoria dal risultato gestito. Queste preferenze dimostrano la configurazione del dispositivo, mentre la telemetria di attività fornisce evidenze dell’attivazione di una regola.
Passaggio 3: esaminare gli eventi ASR
Nel Visualizzatore eventi, passate a Registri applicazioni e servizi → Microsoft → Windows → Windows Defender → Operational. Microsoft elenca i seguenti eventi delle regole ASR nella sua pagina sul Visualizzatore eventi Windows:
| ID evento | Segnale documentato | Limite di interpretazione |
|---|---|---|
1121 | La regola si attiva in modalità Block | Esaminare la regola e l’attività nell’evento; non è una prova per tutte le regole configurate. |
1122 | La regola si attiva in modalità Audit | L’evento registra attività valutata, non un’operazione bloccata. |
1129 | L’utente supera un blocco in modalità Warn | Esaminare la deroga e il flusso di lavoro interessato. |
5007 | Modifica delle impostazioni | Esaminare l’impostazione modificata; il solo ID non identifica una modifica ASR. |
Correlate l’identificatore della regola, il dispositivo, l’ora e l’attività con la matrice di configurazione. Microsoft documenta inoltre Windows Event Forwarding per centralizzare la raccolta. La sua guida ai test della distribuzione distingue il Visualizzatore eventi locale dalle funzionalità di report che dipendono dal prodotto Defender e dal piano.
Correzione: testare, esaminare e applicare le regole approvate (Remediation)
Passaggio 1: definire un progetto pilota rappresentativo
Scegliete una popolazione controllata di dispositivi e i responsabili delle applicazioni. Verificate il supporto e le dipendenze delle regole selezionate, stabilite l’origine di gestione e registrate le preferenze iniziali dei dispositivi. Includete i flussi di lavoro aziendali che probabilmente attiveranno le regole, anziché considerare un dispositivo inattivo come un test di compatibilità.
La guida alla distribuzione di Microsoft organizza il lavoro in pianificazione, test, attivazione e monitoraggio continuo. Indica che le regole di protezione standard possono in genere iniziare in Block o Warn senza test, mentre le altre regole devono essere valutate prima in Audit. Qui un progetto pilota Audit è una scelta deliberata di valutazione, non l’affermazione che Microsoft richieda la stessa sequenza per ogni regola.
Passaggio 2: configurare Audit tramite il criterio responsabile
Per il progetto pilota gestito tramite GPO, attivate Configura regole di riduzione della superficie di attacco e compilate Mostra... con i GUID selezionati e l’azione 2. Usate i valori documentati senza virgolette, caratteri aggiuntivi o spazi iniziali e finali. Confermate che i computer previsti per il progetto pilota ricevano quella GPO, quindi ripetete la raccolta delle preferenze dei dispositivi.
Ad esempio, il nome del valore della regola Office sui processi figlio è d4f940ab-401b-4efc-aadc-ad5f3c50688a; il suo valore Audit è 2. Questo illustra la corrispondenza GUID/azione di Microsoft, non una configurazione rilevata. Configurazione GPO delle regole
Passaggio 3: esaminare gli eventi e documentare le eccezioni applicative
Usate l’attività Audit per identificare i flussi di lavoro legittimi che l’applicazione delle regole potrebbe interrompere. Esaminate il contesto effettivo del processo e del file con il responsabile dell’applicazione prima di approvare un’esclusione. Registrate la regola interessata, l’eccezione esatta, il motivo, il responsabile e la decisione della verifica.
Criteri di gruppo offre sia esclusioni globali sia esclusioni per regola. Nella procedura GPO globale, Learn documenta che le esclusioni di file specifici sono preferibili all’esclusione di un’intera cartella. Le esclusioni specifiche per regola richiedono i modelli amministrativi appropriati; la pagina attuale identifica i modelli 24H2 o successivi quando l’impostazione non è presente in GPMC. Verificate l’impostazione disponibile prima di progettare la distribuzione intorno ad essa. Esclusioni GPO Microsoft
Passaggio 4: passare a Block o a Warn supportata, poi verificare nuovamente
Modificate le azioni delle regole approvate nel criterio responsabile impostando Block 1, oppure Warn 6 dove supportata e appropriata. La regola contro il furto di credenziali LSASS non supporta Warn. Estendete la distribuzione attraverso anelli dopo aver esaminato il comportamento delle applicazioni e la configurazione dei dispositivi. Guida alla distribuzione e documentazione di riferimento delle regole
Ripetete il confronto GUID/azione ed esaminate gli eventi Block o le deroghe Warn. Una modifica GPO completata non è il criterio di accettazione. Chiudete la decisione di distribuzione per una popolazione quando la configurazione prevista viene osservata sui suoi dispositivi valutati, i flussi di lavoro pertinenti sono stati esaminati e le eccezioni rimanenti o i dispositivi sconosciuti sono espliciti.
Evitate di sostituire un elenco di regole gestito con un comando locale di comodo. Microsoft avverte che Set-MpPreference sovrascrive le regole e le azioni esistenti fornite tramite quel cmdlet e che le impostazioni gestite sovrascrivono le modifiche locali in conflitto all’avvio. Risolvete il conflitto tra origini e preservate la configurazione non correlata. Comportamento della configurazione PowerShell
Come EtcSec rileva questa configurazione
L’etc-collector di EtcSec include DEFENDER_ASR_NOT_CONFIGURED, un controllo di configurazione GPO con gravità Medium. L’implementazione esaminata di defender-asr.go chiama FindRegistrySettingInt per DefenderASREnabled. Un valore mancante o diverso da 1 produce Count 1; un valore di 1 lascia Count 0.
L’helper dà priorità a un valore non nullo di Default Domain Controllers Policy, poi di Default Domain Policy, quindi di un’altra GPO disponibile. Questo è l’ordine di ricerca del collector, non la precedenza dei criteri Windows per un singolo dispositivo. Non calcola i collegamenti effettivi, i filtri, l’ereditarietà o i conflitti MDM di ciascun computer.
Il registrypol_parser.go esaminato popola il campo solo da un DWORD denominato exploitguard_asr_rules in una chiave contenente Windows Defender e ASR. Non popola l’inventario completo di GUID/azioni per questo controllo. Il valore aggregato confrontato con 1 non deve essere interpretato come l’azione Block di ogni regola.
Usate questo segnale per aprire un’indagine mirata sulla configurazione. Allegate l’elenco GPO previsto, le preferenze dei dispositivi e gli eventi ASR pertinenti al registro della correzione. Mantenete irrisolte le misurazioni non disponibili fino alla raccolta: un controllo di configurazione a livello di dominio non può sostituire le evidenze dei dispositivi.
Esplora le pagine di identity security collegate a questo tema
