Che cos’è Microsoft Defender for Cloud Apps
Microsoft Defender for Cloud Apps è il CASB (Cloud Access Security Broker) di Microsoft, integrato nel portale Microsoft Defender XDR (security.microsoft.com). Risponde a quattro domande operative: quali app cloud usano davvero i miei utenti, quanto sono rischiose, quali dati ci finiscono dentro, e come blocco in tempo reale ciò che non voglio.
Cloud Discovery: scoprire lo shadow IT
Il Cloud Discovery individua le app non approvate analizzando il traffico di rete. Tre modalità di alimentazione:
| Sorgente | Come funziona | Quando sceglierla |
|---|---|---|
| Upload manuale di log | Carichi log di firewall/proxy (Palo Alto, Fortinet, Zscaler, Squid…) via snapshot report | Analisi una tantum, PoC, valutazione di un periodo storico |
| Log collector | Appliance Docker on-premises che riceve syslog/FTP dal firewall e invia in continuo | Reporting continuo perimetrale, ma copre solo il traffico che passa dal perimetro |
| Microsoft Defender for Endpoint | Integrazione nativa: attivi l’opzione in Defender for Endpoint e i dispositivi onboarded riportano il traffico verso app cloud | Utenti in mobilità / lavoro ibrido: la telemetria segue il dispositivo ovunque, senza appliance |
La scelta è una trappola classica: se il requisito parla di utenti fuori rete aziendale o senza VPN, la risposta è l’integrazione con Microsoft Defender for Endpoint, non il log collector.
Cloud app catalog e risk score
Il catalogo copre oltre 31.000 app SaaS, ciascuna con un risk score da 1 a 10 calcolato su circa 90 fattori raggruppati in quattro categorie: General, Security, Compliance, Legal. Puoi personalizzare i pesi (per esempio dare priorità alla conformità GDPR) e usare i filtri per creare viste operative.
Sulla singola app agisci con tre stati:
- Sanctioned — app approvata; entra nelle policy aziendali e nei report come consentita.
- Unsanctioned — app non approvata; genera lo script di blocco da importare nel firewall/proxy, oppure, se è attiva l’integrazione con Microsoft Defender for Endpoint, il blocco viene applicato direttamente sull’endpoint tramite Network Protection (che deve essere in modalità Block).
- Monitored — nessuna azione, solo osservazione.
App connector (API): visibilità sui dati a riposo
Gli app connector usano le API dei provider (Microsoft 365, Exchange Online, SharePoint Online, OneDrive, Google Workspace, Salesforce, Box, AWS, ServiceNow…) per collegarsi al tenant con un service principal.
Cosa abilitano:
- Scansione retroattiva dei file già presenti in SharePoint Online e OneDrive.
- File policy e DLP che ispezionano contenuto, etichette di sensibilità di Microsoft Purview e permessi di condivisione.
- Azioni di governance: rimuovere la condivisione pubblica, mettere in quarantena un file, applicare un’etichetta, sospendere un utente, revocare le sessioni.
Limite chiave: le API sono asincrone. L’azione arriva dopo l’evento, non lo impedisce.
Conditional Access App Control: controllo in tempo reale
Per intervenire durante la sessione serve il reverse proxy di Defender for Cloud Apps, instradato dal Conditional Access di Microsoft Entra ID. Il flusso è:
- In Entra ID crei una policy di Conditional Access con Session → Use Conditional Access App Control.
- Scegli Monitor only, Block downloads, oppure Use custom policy per rimandare alle session policy di Defender for Cloud Apps.
- L’URL dell’app viene riscritto (suffisso
.mcas.ms) e il traffico transita dal proxy.
Scenario tipico d’esame: impedire il download di file da SharePoint Online su dispositivi non conformi o non registrati. Soluzione: policy di Conditional Access con condizione Device state = non compliant / non hybrid joined + sessione con App Control, e session policy di tipo Control file download (with inspection) con azione Block. Puoi anche scegliere Protect per applicare al volo un’etichetta di Microsoft Purview con crittografia invece di bloccare.
Le session policy coprono anche upload, copia/incolla, stampa e blocco su match DLP.
Activity policy e anomaly detection
Le activity policy lavorano sul feed di attività raccolto dai connector e generano alert in Defender XDR:
- Impossible travel — accessi da località geograficamente incompatibili nel tempo trascorso.
- Mass download / mass delete — soglia su numero di attività per utente in una finestra temporale.
- Attività da indirizzo IP rischioso o da paese non consueto.
- Tentativi amministrativi falliti multipli o creazione di regole di inoltro posta sospette in Exchange Online.
Le policy di anomaly detection sono attive per default e si auto-tarano con un periodo di apprendimento (circa 7 giorni). Le azioni di remediation includono Suspend user, Require user to sign in again e la propagazione del rischio verso Entra ID Protection.
Trappole tipiche d’esame
- Scenario: devi ispezionare file già archiviati in OneDrive e rimuovere le condivisioni pubbliche → App connector via API, non session policy. Il proxy vede solo il traffico live e non tocca i dati a riposo.
- Scenario: devi impedire in tempo reale il download da un’app browser su device non gestito → Conditional Access App Control + session policy. Un app connector non può bloccare l’azione mentre avviene.
- Scenario: la session policy è configurata ma non scatta mai → manca la policy di Conditional Access in Microsoft Entra ID che instrada la sessione al proxy. Senza quella, il traffico non passa da Defender for Cloud Apps.
- Scenario: utenti in smart working senza VPN e serve discovery continuo → integrazione con Microsoft Defender for Endpoint, non log collector né upload manuale (vedono solo il perimetro).
- Scenario: un’app marcata Unsanctioned resta raggiungibile → verifica che Network Protection sia in modalità Block sugli endpoint, oppure che lo script di blocco sia stato importato nel proxy: il tag da solo non blocca nulla.
- Scenario: serve controllo su client desktop e non solo browser → il reverse proxy funziona sulle sessioni browser; per app desktop/mobile ricadi su Conditional Access classico, Microsoft Intune app protection policy o app connector.