I server on-premises e quelli su AWS o GCP vanno portati sotto lo stesso piano di controllo. Il ponte si chiama Azure Arc.
Arc: risorsa ARM, e un agente con lucchetti propri
L’Azure Connected Machine agent registra la macchina come risorsa Azure con un proprio resource ID: entra in un resource group e riceve RBAC e policy come una VM nativa. Arc non serve, e non è supportato, per le VM che girano già in Azure. L’agente manda un heartbeat ogni cinque minuti; senza, passa a Disconnected entro 15-30 minuti e dopo 45 giorni a Expired, da riconnettere a mano.
Dentro ci sono servizi con privilegi molto diversi: Hybrid Instance Metadata Service (HIMDS), non privilegiato, che gestisce registrazione, heartbeat e identità gestita; extension manager, che gira come Local System o root perché installa software; guest configuration, anch’esso Local System o root.
I controlli locali dell’agente hanno precedenza sulle restrizioni impostate nel cloud: reggono anche contro un amministratore di sottoscrizione legittimo che disattivi una policy. Su un asset Tier 0 servono una sottoscrizione dedicata e questi lucchetti:
azcmagent config set incomingconnections.enabled false
azcmagent config set guestconfiguration.enabled false
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor/AzureMonitorWindowsAgent,Microsoft.Azure.AzureDefenderForServers/MDE.Windows"
L’allowlist è il modo per escludere il Custom Script Extension, che altrimenti è esecuzione di codice remoto legittimata.
Quale piano, e a che livello si accende
Plan 1 è l’EDR: onboarding automatico di Defender for Endpoint, alert integrati, inventario software, vulnerability scanning agent-based, valutazione di conformità. Plan 2 aggiunge scansione agentless (posture, vulnerabilità, segreti, malware), alert DNS e di rete, baseline OS del Microsoft Cloud Security Benchmark, valutazione aggiornamenti, file integrity monitoring, JIT, network map, funzioni premium di Defender Vulnerability Management e 500 MB al giorno di ingestione gratuita.
Asimmetria da ricordare: Plan 1 si abilita e si disabilita anche sulla singola risorsa; Plan 2 si abilita solo a livello di sottoscrizione, ma si può disabilitare su singole macchine. L’attivazione fa partire un trial di 30 giorni che non si mette in pausa.
Per le macchine fuori Azure onboardale come Arc. Non è formalismo: col solo agente Defender for Endpoint installato a mano ottieni Plan 1 più le funzioni premium di Defender Vulnerability Management, e poco altro di Plan 2. Baseline OS e valutazione aggiornamenti su AWS e GCP valgono solo per le macchine Arc.
Defender for Servers non usa più Log Analytics agent né Azure Monitor Agent per la maggior parte delle funzioni: AMA e il workspace servono solo per il beneficio dei 500 MB e per FIM.
Impostazioni del piano: EDR, vulnerabilità, FIM
Defender for Cloud > Environment settings > sottoscrizione > Defender for Servers > Settings
In Settings and monitoring ci sono quattro interruttori. Vulnerability assessment ed Endpoint protection sono accesi per default con Plan 1 e Plan 2. Agentless scanning è acceso per default con Plan 2 o con Defender CSPM. File integrity monitoring non è acceso per default: è l’unico che devi accendere tu.
L’integrazione con Defender for Endpoint installa l’estensione MDE.Windows o MDE.Linux; su Linux si verifica con mdatp health. Due eccezioni operative: le VM create da immagini generalizzate non vengono provisionate automaticamente, e su Linux l’autoaggiornamento si disattiva con il tag ExcludeMdeAutoUpdate impostato a true.
C’è poi un secondo livello: Defender valuta agentless la configurazione dell’EDR e apre raccomandazioni come EDR configuration issues should be resolved on virtual machines. I controlli guardano se l’antivirus è spento o parziale, se le firme sono vecchie, se l’ultima scansione risale a più di sette giorni.
Scansione agentless: come funziona e cosa salta
Defender crea uno snapshot dei dischi, lo analizza fuori banda in un ambiente regionale volatile e isolato, e lo elimina subito: i dati restano pochi minuti, la VM non ne risente. Il ciclo è ogni 24 ore, non configurabile, e la macchina deve essere accesa in quella finestra.
I limiti sono quelli che fanno sparire risultati senza spiegazione: più di 14 dischi, somma dei dischi oltre 4 TB (viene scansionato il solo disco OS, e solo se sotto i 4 TB), dischi UltraSSD_LRS o PremiumV2_LRS o dischi OS effimeri AKS, file system UFS, ReFS o ZFS, formati OracleASM, DRBD o Linux_Raid_Member, partizioni swap o DM_Verity_Hash, VM Databricks.
In Azure i permessi arrivano dal ruolo VM scanner operator, in sola lettura sui dischi. Sui dischi cifrati con chiave del cliente serve un passaggio in più:
Applicazione: Microsoft Defender for Cloud Servers Scanner Resource Provider
Application ID: 0c7668b5-3260-4ad0-9f53-34ed54fa19b2
Vault con access policy: Get, Wrap Key, Unwrap Key
Vault con RBAC: Key Vault Crypto Service Encryption User
Le esclusioni si fanno per tag, in Agentless scanning for machines.
Machine Configuration: audit, apply, autocorrect
Machine Configuration valuta e applica impostazioni dentro il sistema operativo, su VM Azure e su macchine Arc, in tre modalità: Audit (solo report), Apply and Monitor (applica e poi osserva), Apply and Autocorrect (riporta in conformità quando deriva).
Prerequisito che blocca metà delle prime prove: sulle VM Azure servono l’estensione e un’identità gestita assegnata dal sistema, e sono due raccomandazioni distinte, Guest Configuration extension should be installed on machines e la sua variante con system-assigned managed identity. Su Arc, AWS e GCP con provisioning Arc l’estensione arriva già installata. Le baseline compute del Microsoft Cloud Security Benchmark richiedono Plan 2. Massimo 50 guest assignment per macchina; VMSS Uniform non supportato, VMSS Flex sì.