Defender for Cloud non è un prodotto solo-Azure: la stessa console valuta account AWS e progetti GCP, e prova a dirti che cosa si vede della tua infrastruttura da fuori.

AWS: federazione, non chiavi salvate

Il connettore nativo si autentica «using federated trust and short-lived credentials, without storing long-lived secrets»: nessuna access key da custodire. Serve Defender for Cloud già attivo su una sottoscrizione Azure e il permesso Contributor su quella sottoscrizione; Defender CSPM richiede in più Owner, e il CIEM il ruolo Security Admin con Application.ReadWrite.All sul tenant.

Environment settings > Add environment > Amazon Web Services

Due scelte sono scomode da cambiare dopo. Il tipo di onboarding: Single account oppure Management account, che scopre e crea i connettori per gli account membri — e serve l’account di gestione vero, perché gli account amministratore delegato non sono supportati. E l’intervallo di scansione, 4, 6, 12 o 24 ore, sapendo che alcuni raccoglitori hanno cadenza fissa e ignorano l’impostazione.

All’accesso scegli fra Default access (permessi anche per capacità future) e Least privilege access, e distribuisci con CloudFormation o Terraform. Qui c’è la trappola operativa: il template CloudFormation va aggiornato ogni volta che abiliti un piano nuovo o ne cambi la configurazione. Se non lo fai, il connettore risulta collegato ma il piano non ha i permessi e i risultati non arrivano: la colonna Connectivity status è il primo posto da guardare.

Per i piani sulle macchine il connettore non basta. Defender for Servers e Defender for SQL vogliono Azure Arc sulle istanze EC2 e l’AWS SSM Agent con il criterio AmazonSSMManagedInstanceCore; senza l’agente SSM il provisioning automatico di Arc non parte, e attivarlo richiede il ruolo Owner. Da anticipare al team AWS: Defender CSPM interroga le API in sola lettura più volte al giorno, e quelle chiamate finiscono in CloudTrail sotto il ruolo CspmMonitorAws. Il connettore AWS non è disponibile nei cloud governativi.

GCP: workload identity federation e uno script gcloud

Il modello è analogo ma la meccanica cambia: federazione delle identità dei carichi di lavoro e impersonificazione di service account. Colleghi un progetto o un’organizzazione, sempre con Contributor sulla sottoscrizione Azure che ospita il connettore.

Il portale genera uno script gcloud costruito sull’ambito e sui piani scelti. Eseguito in GCP crea un pool di identità dei carichi di lavoro, un provider per ogni piano, i service account e i binding a livello di progetto. Prerequisito facile da mancare: alcune API vanno abilitate sul progetto dove esegui lo script — e sul progetto di gestione, se fai l’onboarding a livello di organizzazione.

iam.googleapis.com
sts.googleapis.com
cloudresourcemanager.googleapis.com
iamcredentials.googleapis.com
compute.googleapis.com

Vale la stessa regola di AWS: cambi i piani, rigeneri lo script e lo riesegui. E anche qui alcuni raccoglitori girano a cadenza fissa di un’ora, qualunque intervallo tu abbia scelto.

Vulnerabilità sulle VM Azure: senza agente o con agente

La soluzione integrata è Microsoft Defender Vulnerability Management, con approccio ibrido. La scansione senza agente richiede Defender for Servers Plan 2 — inventario software, vulnerabilità e segreti arrivano anche con Defender CSPM, il malware no. La scansione con agente passa dall’integrazione con Defender for Endpoint ed è disponibile in Plan 1 e Plan 2. Se una macchina è coperta da entrambe, Defender for Cloud mostra i risultati dell’agente perché sono più freschi. Con uno scanner BYOL (Qualys o Rapid7) prevalgono i risultati del partner, e la scansione senza agente copre le macchine dove l’agente manca.

L’interruttore è Agentless scanning for machines, sotto Settings del piano Defender CSPM o Defender for Servers Plan 2. Ma lo stato «attivo» non garantisce la copertura. La scansione gira una volta ogni 24 ore su una pianificazione non configurabile: una VM spenta in quella finestra salta il giro. Non sono supportate le VM con più di 14 dischi; se la somma di disco di sistema e dischi dati supera i 4 TB viene scansionato solo il disco di sistema, e solo se sta sotto i 4 TB. Restano fuori i dischi UltraSSD_LRS e PremiumV2_LRS, i dischi effimeri di AKS, le VM Databricks e file system come UFS, ReFS e ZFS.

Con dischi cifrati da chiavi gestite dal cliente serve un passaggio in più: al principale Microsoft Defender for Cloud Servers Scanner Resource Provider (ID applicazione 0c7668b5-3260-4ad0-9f53-34ed54fa19b2) vanno i permessi Get, Wrap Key e Unwrap Key su un vault a criteri di accesso, oppure il ruolo Key Vault Crypto Service Encryption User se il vault usa RBAC.

EASM: la vista da fuori, inclusa in Defender CSPM

Defender External Attack Surface Management fa la scansione «outside-in». L’integrazione «is included with the Defender Cloud Security Posture Management (CSPM) plan by default and doesn’t require a license»: nessuna risorsa EASM separata da creare.

La scoperta parte da discovery seed — domini, blocchi di indirizzi IP, host, contatti e-mail, ASN, organizzazioni Whois — e si espande in modo ricorsivo seguendo record Whois, DNS, certificati SSL e record ASN, finché non raggiunge il confine di ciò che gestisci. Ogni risorsa trovata riceve uno stato: Approved Inventory, Dependency (infrastruttura di terzi che sostiene la tua), Monitor Only, Candidate e Requires Investigation. Gli ultimi due vanno rivisti a mano: EASM dice «forse è tuo, deciderlo tocca a te».

Dentro Defender for Cloud quei dati servono a tre cose: scoprire le risorse cloud esposte a Internet, generare percorsi d’attacco che partono da IP realmente esposti, e correlarli nel cloud security explorer. Se invece usi la risorsa Defender EASM autonoma, ha ruoli propri (Owner, Contributor, Reader) e non supporta l’accesso cross-tenant, nemmeno via Azure Lighthouse.