Mettere in sicurezza il sistema operativo: App Control, Credential Guard, OSConfig e LAPS

Il dominio «Secure Windows Server infrastructure» pesa il 10-15% di AZ-802, ed è il dominio in cui l’esame smette di chiedere che cos’è un controllo e comincia a chiedere in quale modalità, con quale parametro e a quale livello lo configuri. Sapere che Credential Guard esiste non basta: serve sapere che cosa rompe quando si accende da solo, e che cosa si fa al posto di spegnerlo.

Exploit protection: prima si misura, poi si forza

Exploit protection è l’erede di EMET e applica process mitigation a livello di sistema o per singolo eseguibile. DEP, SEHOP (a 64 bit) e validate heap integrity sono già attive di default; le altre si aggiungono a mano. Le mitigazioni più invasive — prima fra tutte Arbitrary Code Guard (ACG), che impedisce al processo di generare o modificare codice dinamico — rompono facilmente le applicazioni line-of-business, quindi il percorso documentato è sempre audit mode prima, enforcement dopo:

Set-ProcessMitigation -Name C:\Apps\LOB.exe -Enable AuditDynamicCode

Ogni mitigazione ha un parametro di audit dedicato, e non è il nome della mitigazione:

Gli eventi finiscono nel log Security-Mitigations (Kernel Mode/User Mode): ID 1 per l’audit di ACG, 3 per i processi figli, 5 per le low integrity images, 7 per le remote images, 9 per le chiamate win32k, 11 per code integrity guard. Per passare da un server pilota al parco intero si esporta la configurazione in XML con Get-ProcessMitigation -RegistryConfigFilePath e la si distribuisce con la Group Policy Use a common set of exploit protection settings, che punta al file XML. Due dettagli che l’esame ama: i servizi (di sistema e di rete) sono fuori scope per exploit protection, e le vecchie mitigazioni EAF, IAF, SimExec, CallerCheck e StackPivot sono deprecate — ACG le sostituisce.

App Control for Business: la domanda vera è il rule level

AppLocker e WDAC sono confluiti in App Control for Business. Generando una policy da un reference server con New-CIPolicy, la scelta che conta è -Level (con -Fallback per ciò che il livello primario non riesce a fidarsi).

Lo scenario classico — agent firmati da pochi vendor e aggiornati ogni mese, più un’applicazione interna non firmata — si risolve con -Level Publisher -Fallback Hash: il publisher resta lo stesso dopo ogni patch, quindi la policy non va rifatta, mentre l’hash copre l’unico binario senza firma. L’opzione di policy 3 Enabled:Audit Mode è presente di default: l’enforcement non si «attiva», si ottiene rimuovendo quell’opzione (Set-RuleOption -Option 3 -Delete) e convertendo l’XML in binario con ConvertFrom-CIPolicy. Gli eventi sono nel log CodeIntegrity: 3076 in audit, 3077 in blocco. Attenzione anche alle regole FilePath: valgono solo per il codice user-mode e, di default, solo per percorsi scrivibili dai soli amministratori.

Credential Guard e LSA protection: due cose diverse

Su Windows Server 2025 Credential Guard è abilitato per impostazione predefinita su tutti i server domain-joined che non sono domain controller, a meno che non sia stato esplicitamente disabilitato prima dell’upgrade. Da qui il guasto più citato: dopo l’aggiornamento di due host Hyper-V standalone, la live migration smette di funzionare. La causa non è Hyper-V: fino a Windows Server 2022 la live migration senza cluster usa CredSSP, e con Credential Guard attivo CredSSP non può più usare credenziali salvate o SSO. La soluzione documentata è configurare la Kerberos constrained delegation (o la resource-based constrained delegation) fra i due host, non disabilitare Credential Guard. Nella stessa famiglia di rotture: unconstrained delegation, DES, NTLMv1 e MS-CHAP in SSO, WDigest.

La LSA protection (LSASS come Protected Process Light) è un controllo complementare, non un’alternativa. Su Windows Server 2022 la policy ADMX «Configures LSASS to run as a protected process» non è disponibile (arriva con Windows 11 22H2), quindi il modo per farlo con un solo GPO è una Group Policy Preference di registro su HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, valore RunAsPPL di tipo REG_DWORD: 1 memorizza la configurazione in una variabile UEFI (UEFI lock: non si disfa più dal registro, serve il tool di opt-out), 2 la abilita senza variabile UEFI ed è applicato solo da Windows 11 22H2 in avanti. Si verifica con l’evento WinInit 12 nel log System: LSASS.exe was started as a protected process with level: 4. Prima di forzarla, l’audit si accende con AuditLevel = 8 sotto Image File Execution Options per lsass.exe e produce gli eventi CodeIntegrity 3065 e 3066 per i plug-in non firmati Microsoft.

OSConfig: baseline con drift control, ma solo su Windows Server 2025

OSConfig non supporta versioni precedenti a Windows Server 2025. È questo il discrimine quando il parco è misto: sui 2019 e 2022 restano Security Compliance Toolkit e GPO. Si installa il modulo con Install-Module -Name Microsoft.OSConfig -Scope AllUsers e si applica lo scenario che corrisponde al ruolo della macchina:

Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer -Default

Il valore aggiunto rispetto a una GPO è il drift control: dopo l’applicazione OSConfig riporta da solo le impostazioni deviate al valore desiderato, senza che tu configuri niente d’altro. Si verifica con Get-OSConfigDesiredConfiguration, si personalizza con -Setting e -Value mantenendo il drift control, si rimuove con Remove-OSConfigDesiredConfiguration; applicazione e rimozione richiedono il riavvio. Esistono scenari companion indipendenti: SecuredCore, Defender/Antivirus/WindowsServer/2025 e LAPS/WindowsServer/2025/MemberServer. Conseguenza operativa da ricordare: se la stessa impostazione arriva da OSConfig e da una GPO, i due valori si rincorrono — una delle due sorgenti va tolta.

Windows LAPS e Group Policy

Windows LAPS è in-box: nativo su Windows Server 2025 e disponibile su 2019 e 2022 a partire dall’aggiornamento dell’11 aprile 2023; il vecchio prodotto Microsoft LAPS (MSI separato) è deprecato. Ruota la password dell’amministratore locale e la salva o in AD DS o in Microsoft Entra ID — mai in entrambi — e sui domain controller può gestire la password DSRM. La legacy emulation mode legge le vecchie GPO, ma scrive la password in AD in chiaro: niente cifratura, niente password history.

Le impostazioni di sistema di questo dominio restano quasi tutte Group Policy: l’XML di exploit protection, il valore RunAsPPL, il deploy delle policy App Control e SmartScreen, che si configura in Windows Components > Windows Defender SmartScreen > Explorer > Configure Windows Defender SmartScreen scegliendo fra avviso semplice e Warn and prevent bypass (l’utente non può ignorare il blocco), più le voci corrispondenti sotto Microsoft Edge > SmartScreen settings. SmartScreen valuta la reputazione di contenuti provenienti da Internet: non protegge file su share UNC o SMB interne.

Firewall e connection security rules

Una firewall rule decide chi passa; una connection security rule decide come i due peer si autenticano (IPsec) e da sola non consente né blocca nulla. Per la domain isolation la coppia di parametri è tutta la risposta:

New-NetIPsecRule -DisplayName "Domain Isolation" -InboundSecurity Require -OutboundSecurity Request -PolicyStore contoso.com\Domain_Isolation

Require in ingresso scarta le connessioni da peer che non autenticano con IPsec; Request in uscita tenta l’autenticazione ma lascia riuscire il traffico verso dispositivi che non la supportano. Sulla precedenza: un allow esplicito batte il blocco di default, un block esplicito batte qualsiasi allow in conflitto, e fra regole non in conflitto vince la più specifica. Windows Firewall non supporta un ordinamento pesato assegnato dall’amministratore.

Trappole tipiche d’esame

• ACG da validare su un’app LOB prima di forzarla: Set-ProcessMitigation -Name <percorso> -Enable AuditDynamicCode e eventi Security-Mitigations ID 1. La trappola è cercare -Audit come parametro, o -Enable DynamicCode, che invece la applica subito.
• Policy App Control da un reference server con software firmato e patchato ogni mese: -Level Publisher (con -Fallback Hash per l’app interna non firmata). Hash e FilePublisher obbligano a rigenerare la policy a ogni aggiornamento.
• Live migration rotta dopo l’upgrade a Windows Server 2025: è Credential Guard abilitato di default che blocca CredSSP; si configura la Kerberos constrained delegation, non si disattiva Credential Guard e non si tocca il virtual switch.
• LSASS come protected process con un solo GPO su Server 2022 con UEFI e Secure Boot: GPP di registro RunAsPPL = 1 (con UEFI lock). Il valore 2 non è applicato su quel sistema, e la policy ADMX «Configures LSASS to run as a protected process» lì non c’è.
• Baseline Microsoft per ruolo con correzione automatica delle deviazioni: OSConfig con lo scenario del ruolo e -Default — ma solo sui Windows Server 2025; per i 2019/2022 della stessa foresta serve un’altra strada.
• Mantenere l’EDR di Defender for Endpoint su alcune VM senza il Plan 2 della subscription: si configura Plan 1 a livello di risorsa (REST API pricings con subPlan P1, script o Azure Policy «granular pricing» su tag). A livello di risorsa si può abilitare solo il Plan 1; il Plan 2 si può solo disabilitare. E ricorda che JIT VM access richiede il Plan 2, e che Defender for Servers non si appoggia più al Log Analytics agent né all’Azure Monitor Agent per la maggior parte delle funzioni.
• Inbound solo da peer autenticati ma outbound libero: -InboundSecurity Require -OutboundSecurity Request. Invertirli, o mettere Require su entrambi, è l’errore che l’esame propone come distrattore plausibile.