Defender: postura, antivirus e detection non sono la stessa cosa

I tre prodotti Defender che compaiono nelle domande AZ-140 rispondono a esigenze distinte. Microsoft Defender for Cloud lavora sulla postura: valuta la configurazione dei session host e delle risorse Azure di contorno, produce raccomandazioni e un punteggio, e abilita i piani di protezione (fra cui Defender for Servers, che porta con sé l’integrazione con Defender for Endpoint e il just-in-time VM access). È lo strumento da citare quando lo scenario chiede “visibilità sullo stato di sicurezza” o “compliance rispetto a un benchmark”, non quando chiede di bloccare un attacco in corso.

Microsoft Defender Antivirus è attivo per default sulle immagini Windows, e il punto critico in Azure Virtual Desktop sono le esclusioni per FSLogix. I file dei container (profile container e ODFC container) sono VHD/VHDX aperti e scritti di continuo: senza le esclusioni documentate — sui file dei container e sui processi dell’agent FSLogix — si ottengono logon lentissimi, container che non montano o corruzioni. Le esclusioni vanno applicate sia sui session host sia su qualunque antimalware analizzi la share SMB che ospita i container. Ciò che non si fa è disattivare la real-time protection: si escludono i percorsi giusti, si pianificano le scansioni complete in fascia off-peak e si limita il carico CPU concesso alla scansione, perché su un host multi-sessione ogni ciclo speso dall’antivirus è tolto a decine di utenti contemporanei.

Microsoft Defender for Endpoint aggiunge EDR: rilevamento comportamentale, indagine e risposta. L’onboarding può avvenire tramite Defender for Cloud, policy di gestione o script; per le VM non persistenti esiste una procedura di onboarding dedicata al VDI, pensata per evitare che ogni host ricreato dall’immagine generi voci duplicate nell’inventario. Evita di “congelare” nell’immagine dell’Azure Compute Gallery uno stato di onboarding già consumato.

Rete: NSG, UDR e Azure Firewall senza rompere il servizio

Il traffico di Azure Virtual Desktop è reverse connect: l’agent sul session host stabilisce una connessione in uscita verso il control plane, quindi non serve alcuna porta inbound da Internet, RDP compreso. Sull’NSG della subnet dei session host si nega l’inbound da Internet e si controlla il traffico est-ovest; l’outbound verso gli endpoint del servizio, invece, deve restare consentito usando i service tag e gli FQDN documentati da Microsoft.

Con una UDR si forza il percorso verso un firewall o un NVA, tipicamente per ispezione e logging dell’uscita. Azure Firewall applica poi application rule (l’FQDN tag dedicato ad Azure Virtual Desktop, più Windows Update, attivazione, storage) e network rule per DNS e servizi di piattaforma. Il trade-off è di rischio operativo: quanto più aggressivo è il filtro, tanto più facile è tagliare fuori un endpoint necessario e trovarsi gli host in stato “unavailable”. L’ispezione TLS verso il control plane è una fonte classica di rotture.

Accesso amministrativo: Bastion o just-in-time

Le porte di gestione non devono restare esposte. Azure Bastion consente RDP/SSH verso VM prive di IP pubblico, con il traffico che passa dalla subnet dedicata: è la scelta quando il requisito è “nessun IP pubblico sui session host”. L’accesso just-in-time di Defender for Cloud segue una logica diversa: apre la porta per una finestra temporale limitata, a un IP di origine, e la richiude — quindi presuppone comunque un endpoint raggiungibile. Le due cose sono combinabili, ma rispondono a requisiti formulati in modo diverso.

Piattaforma e sistema operativo

App Control for Business definisce quale codice può essere eseguito: è enforcement a livello di dispositivo, va sempre distribuito prima in audit mode e conviene appoggiarsi a un managed installer per non dover firmare a mano ogni aggiornamento. Controlled Folder Access protegge le cartelle utente dal ransomware, ma su multi-sessione blocca facilmente applicazioni legittime: audit mode e allow-list prima dell’enforcement. Sul piano della VM, Trusted Launch (Gen2, secure boot, vTPM, guest attestation) protegge l’avvio e l’integrità del sistema, mentre le confidential VM cifrano la memoria e proteggono i dati in uso tramite TEE hardware, a costo di scelte più ristrette di size, regioni e immagini.

Trappole tipiche d’esame

  • Logon lentissimi e container FSLogix corrotti → esclusioni antivirus, non disattivazione: vanno escluse le VHD/VHDX dei container e i processi dell’agent, sia sui session host sia sull’antimalware che analizza la share.
  • “Nessun IP pubblico sui session host” → Azure Bastion: il just-in-time riduce la finestra di esposizione ma non elimina l’endpoint pubblico.
  • UDR 0.0.0.0/0 verso un NVA e nessuno si connette più → è l’uscita, non l’ingresso: il reverse connect richiede l’outbound verso gli endpoint del servizio; aprire porte inbound non risolve nulla.
  • “Limitare le app eseguibili solo a un gruppo di utenti sullo stesso host” → AppLocker: App Control for Business applica la policy all’intero dispositivo, non per utente.
  • “Proteggere i dati mentre sono in memoria” → confidential VM: Trusted Launch copre boot e integrità del sistema, non la cifratura della memoria in esecuzione.
  • “Punteggio e raccomandazioni di postura” → Defender for Cloud; “indagine su un alert sull’host” → Defender for Endpoint: distinguere postura da detection e response è metà della domanda.