Azure Security Best Practice: 12 controlli per proteggere Microsoft Azure

Proteggere Microsoft Azure non significa limitarsi ad attivare MFA o un firewall. Una configurazione sicura richiede controlli coordinati su identità, privilegi, rete, workload, dati, logging e governance. Le best practice più efficaci partono dal modello di responsabilità condivisa e applicano il principio Zero Trust: verificare esplicitamente, usare il minimo privilegio e assumere che una compromissione sia sempre possibile.

Questa checklist raccoglie i controlli prioritari per ambienti Azure e ibridi, con un approccio coerente con il Microsoft Cloud Security Benchmark e con i servizi di sicurezza nativi della piattaforma. Per una panoramica generale della piattaforma, consulta la pagina Nexsys dedicata a Microsoft Azure.

1. Partire dal modello di responsabilità condivisa

Il primo errore da evitare è considerare il cloud automaticamente sicuro. Microsoft protegge l’infrastruttura fisica e una parte crescente dello stack man mano che si passa da IaaS a PaaS e SaaS, ma il cliente mantiene sempre responsabilità rilevanti su dati, identità, account, configurazioni e accessi.

In un ambiente Azure è quindi necessario definire in modo esplicito chi gestisce sicurezza e aggiornamenti dei workload, protezione dei dati, configurazione delle risorse, autorizzazioni, logging, backup e risposta agli incidenti. Alta disponibilità e resilienza del provider non equivalgono automaticamente a una strategia di backup o di disaster recovery adeguata alle esigenze dell’organizzazione.

2. Rendere resistenti le identità con MFA, Conditional Access e passwordless

L’identità è uno dei principali perimetri di sicurezza del cloud. In Microsoft Entra ID la priorità è ridurre il rischio di compromissione degli account, soprattutto per amministratori e identità con accesso a risorse critiche.

• Applicare MFA agli account amministrativi e, progressivamente, all’intera popolazione utente.
• Preferire metodi di autenticazione resistenti al phishing, come passkey/FIDO2 e Windows Hello for Business, rispetto a metodi basati su SMS.
• Usare Conditional Access per legare l’accesso a rischio, identità, dispositivo, posizione e contesto.
• Separare gli account amministrativi dagli account usati per posta, navigazione e attività quotidiane.
• Mantenere account di emergenza (break-glass) protetti, monitorati e sottoposti a test periodico.

Per i team che devono progettare e amministrare questi controlli, il corso SC-300 Microsoft Identity and Access Administrator approfondisce gestione delle identità, accessi e privilegi in Microsoft Entra ID.

3. Applicare least privilege con RBAC e Privileged Identity Management

I privilegi permanenti amplificano l’impatto di una compromissione. È quindi opportuno assegnare il ruolo minimo necessario, limitare lo scope e rendere temporaneo l’accesso amministrativo quando possibile.

• Usare Azure RBAC con scope coerenti: management group, subscription, resource group o singola risorsa.
• Evitare assegnazioni Owner o Contributor quando un ruolo più specifico è sufficiente.
• Usare Microsoft Entra Privileged Identity Management (PIM) per accessi just-in-time, con durata limitata, MFA e approvazione dove richiesto.
• Revisionare periodicamente assegnazioni dirette, gruppi privilegiati, guest e service principal.
• Monitorare le modifiche ai ruoli e le attivazioni PIM come eventi ad alta priorità.

4. Eliminare segreti statici quando sono disponibili Managed Identities

Applicazioni, automazioni e workload non dovrebbero dipendere da password o secret incorporati nel codice o salvati in file di configurazione. Dove possibile, usare Managed Identities per autenticare le risorse Azure verso altri servizi senza gestire credenziali applicative statiche.

Quando un segreto o una chiave è realmente necessario, archiviarlo in Azure Key Vault, applicare autorizzazioni minime, rotazione, logging e criteri di scadenza. I service principal devono avere privilegi limitati e una gestione del ciclo di vita equivalente a quella degli account amministrativi.

5. Segmentare la rete e ridurre l’esposizione pubblica

La segmentazione resta essenziale anche in un modello Zero Trust. L’obiettivo è ridurre le superfici raggiungibili, controllare i flussi east-west e north-south e impedire che una singola compromissione consenta movimenti laterali indiscriminati.

• Applicare Network Security Group con regole minimali e postura default-deny.
• Non esporre RDP o SSH direttamente a Internet tramite regole 0.0.0.0/0; preferire Azure Bastion, VPN o accessi privati.
• Usare Private Endpoint e Private Link per i servizi PaaS quando compatibile con l’architettura.
• Centralizzare l’ispezione del traffico quando richiesto tramite Azure Firewall o una NVA coerente con il disegno di rete.
• Per workload che richiedono ispezione avanzata, valutare Azure Firewall Premium con IDPS e TLS inspection.
• Separare ambienti production, test e management evitando peering e route più permissivi del necessario.

La sicurezza Azure deve essere integrata con la strategia complessiva di Network Security aziendale, soprattutto negli scenari ibridi con connettività verso sedi, datacenter e servizi esterni.

6. Proteggere i workload pubblici da DDoS e attacchi applicativi

Azure include una protezione infrastrutturale DDoS per i servizi che utilizzano indirizzi pubblici, ma gli scenari esposti a Internet possono richiedere livelli dedicati di protezione e telemetria. I livelli attuali sono Azure DDoS IP Protection e Azure DDoS Network Protection.

La protezione DDoS opera principalmente sui livelli di rete L3/L4. Per le applicazioni web serve una difesa complementare a livello L7, ad esempio tramite Web Application Firewall. La scelta deve dipendere dal numero di IP pubblici, dalla criticità dei servizi, dai requisiti di risposta e dal modello economico della protezione.

7. Usare Microsoft Defender for Cloud per misurare e migliorare la security posture

Microsoft Defender for Cloud è il riferimento nativo per valutare la postura di sicurezza dei workload Azure e, nei piani compatibili, anche di ambienti multicloud. Il servizio analizza configurazioni e risorse, produce raccomandazioni e consente di prioritizzare le remediation in base al rischio.

• Verificare il Secure Score e soprattutto le raccomandazioni ad alto rischio.
• Usare il Microsoft Cloud Security Benchmark come baseline di riferimento.
• Abilitare i piani Defender necessari in base ai workload realmente presenti, evitando attivazioni indiscriminate.
• Integrare le raccomandazioni nella gestione ordinaria del backlog tecnico e non trattarle come attività una tantum.
• Definire eccezioni solo se motivate, documentate e periodicamente riesaminate.

8. Applicare governance e configurazioni coerenti con Azure Policy

Una configurazione sicura non deve dipendere dalla memoria del singolo amministratore. Azure Policy permette di valutare e, dove opportuno, imporre regole coerenti su subscription e resource group, riducendo drift e configurazioni non conformi.

• Definire management group e subscription secondo responsabilità, ambienti e requisiti di separazione.
• Applicare policy per regioni consentite, SKU, cifratura, logging, accesso pubblico e configurazioni di rete.
• Usare tagging e naming standardizzati per ownership, criticità, ambiente e centro di costo.
• Gestire le eccezioni con scadenza e owner esplicito.
• Integrare policy, template e Infrastructure as Code nel ciclo di deployment.

9. Proteggere dati, storage e chiavi

La protezione dei dati richiede controlli distinti per riservatezza, integrità e disponibilità. La cifratura fornita dalla piattaforma è una base, ma non sostituisce la corretta gestione di autorizzazioni, esposizione di rete, chiavi e lifecycle dei dati.

• Disabilitare l’accesso pubblico agli storage account quando non necessario.
• Preferire autenticazione Entra ID e autorizzazioni RBAC rispetto a chiavi condivise dove supportato.
• Usare Private Endpoint per i servizi dati sensibili quando compatibile con il disegno applicativo.
• Definire requisiti per chiavi gestite dal cliente solo quando esiste un’esigenza reale di controllo o compliance.
• Impostare retention, versioning, soft delete e backup in funzione di RPO/RTO e scenari ransomware.

10. Centralizzare log, alert e detection

Senza telemetria non è possibile distinguere una configurazione sicura da un incidente in corso. I log devono coprire identità, control plane, workload, rete e servizi critici, con retention coerente e controlli sugli alert più importanti.

• Raccogliere Activity Log, audit e diagnostic log dei servizi rilevanti.
• Definire alert per modifiche a ruoli, policy, networking, Key Vault e risorse critiche.
• Centralizzare i log in Log Analytics e, quando il modello operativo lo richiede, Microsoft Sentinel.
• Correlare alert di Defender for Cloud, identità, endpoint e workload per evitare analisi a silos.
• Testare periodicamente che le regole di detection producano gli alert attesi.

Per competenze operative su detection, hunting e risposta agli incidenti con l’ecosistema Microsoft, consulta il corso SC-200 Microsoft Security Operations Analyst.

11. Gestire vulnerabilità, patch e hardening dei workload

Il cloud non elimina la gestione delle vulnerabilità. Nei workload IaaS il cliente mantiene la responsabilità del sistema operativo, delle applicazioni e delle configurazioni. È quindi necessario combinare inventario, vulnerability management, patching, hardening e protezione endpoint/server.

• Inventariare VM, immagini, container e componenti esposti.
• Applicare patch con SLA differenziati in base alla criticità della vulnerabilità e del workload.
• Rimuovere protocolli, porte, agent e software non necessari.
• Usare immagini standardizzate e baseline di hardening ripetibili.
• Validare periodicamente l’esposizione con vulnerability assessment e penetration test quando applicabile.

12. Integrare la sicurezza nel ciclo DevOps e Infrastructure as Code

La sicurezza deve essere verificata prima del deployment, non aggiunta solo dopo. Pipeline e Infrastructure as Code consentono di rendere ripetibili configurazioni, controlli e remediation, ma possono anche propagare rapidamente un errore se template e permessi non sono governati.

• Versionare template e policy e sottoporli a code review.
• Eseguire scanning di dipendenze, immagini container, Infrastructure as Code e secret.
• Proteggere service connection, federated credential e identità usate dalle pipeline.
• Separare approvazione, sviluppo e deployment sugli ambienti critici.
• Integrare security gate nei processi CI/CD in modo proporzionato al rischio.

Checklist Azure Security: controlli minimi da verificare

Best practice Azure: il criterio corretto è ridurre il rischio, non accumulare servizi

La sicurezza di Azure non migliora automaticamente aumentando il numero di prodotti attivi. Il risultato dipende dalla coerenza tra identità, autorizzazioni, rete, dati, workload, logging e processi operativi. Una misura è efficace quando riduce una superficie di attacco concreta, produce segnali utilizzabili e può essere mantenuta nel tempo.

Il riferimento pratico deve quindi essere una baseline misurabile, con ownership, priorità di remediation e verifiche periodiche. Microsoft Cloud Security Benchmark, Defender for Cloud e Azure Policy forniscono una base tecnica utile, ma la configurazione deve essere adattata all’architettura e al rischio effettivo dell’organizzazione.

Garantire soli i privilegi necessari

Buona cosa è ridurre al minimo il numero di persone, il relativo periodo temporale e i privilegi concessi alle risorse Azure: si riduce la possibilità che un malintenzionato ottenga un accesso amministrativo oppure che un utente autorizzato inavvertitamente modifica su una specifica risorsa. È possibile far eseguire azioni amministrative agli utenti autorizzati in modalità just-in-time alle risorse Azure ed Azure AD, servendosi del servizio Azure Active Directory Privileged Identity Management, la quale fornisce l'attivazione dei ruoli basata solo per il tempo necessario in modo mitigare i rischi di autorizzazioni di accesso eccessiv.

Segmentazione

Per limitare ulteriormente i rischi legati ai modelli di sicurezza convenzionali, basati su una sicurezza perimetrale, la quale tutto quello che avviene al suo interno è “trusted”, è bene adottare una strategia di micro-segmentazione con un approccio zero-trust, ossia le risorse sono segmentate in base ai ruoli e tutti i passaggi di informazioni tra i vari sistemi devono essere vagliati secondo le policy granulari.

Implementare una strategia firewall

È opportuno integrare una soluzione firewall che filtra e protegga tutte le informazioni in transito per la rete. Microsoft ha sviluppato Azure Firewall, in modo da registrare e controllare alle proprie risorse, filtrando le connessioni in entrata e uscita, supervisionando le reti ibride della propria infrastruttura, governando il traffico HTTP e HTTPS generate dalle applicazioni. Alternativamente, è possibile servirsi di prodotti di marchi che già conosci come network virtual appliance su Azure, in modo da avere un ambiente familiare che il proprio gruppo conosce e per sfruttare le conoscenze già in possesso.

Protezione dagli attacchi DDOS

Un attacco DDoS (Distributed Denial of Service) è un tentativo di interrompere il lavoro di un server, un servizio, una infrastruttura investendo l'obiettivo con un elevato traffico Internet. Gli attacchi DDoS vengono portati a termine utilizzando più sistemi informatici compromessi come fonti di traffico di attacco.

In Azure vi sono due livelli di protezione da attacchi DDos, Basic e Standard.

La protezione di base è compresa in Azure ed è gratuita. Fornisce difesa contro gli attacchi comuni a livello di rete attraverso il monitoraggio del traffico sempre attivo e la mitigazione in tempo reale. La protezione di base difende anche da attacchi di query DNS di livello 7 e dagli attacchi volumetrici che prendono di mira le zone DNS di Azure. La protezione standard offre funzionalità aggiuntive, ottimizzate per le necessità specifiche dell’ambiente di lavoro; le policy sono personalizzate attraverso un processo di machine learning che adatta le impostazioni in base al traffico generato dal proprio applicativo.

Azure Security Center

Questo servizio consente di prevenire eventuali minacce che interessano ambienti Azure e ibridi; anche qui si hanno due possibili licenze: licenza gratuita, la quale fornisce delle raccomandazioni in modo continuo sul nostro ambiente di lavoro, e la licenza standard, che aggiunge funzionalità avanzate di rilevamento delle minacce, contrastando exploit e zero day utilizzando metodologie di analisi comportamentale. È possibile effettuare in modo integrato un vulnerability assessment per le macchine virtuali.

Implementare la metodologia DevOps

L’utilizzo di tale metodologia permette di implementare un alto livello di sicurezza nei servizi e nelle applicazioni: coinvolgendo tra loro i gruppi di lavoro dedicati alle varie fasi di lavoro, si otterranno benefici sia in termini di sicurezza che di ottimizzazione delle tempistiche.

Non utilizzare tecnologia sorpassata

Nell’ambiente Azure non è consigliato servirsi di tecnologia che utilizza sistemi di IDS/IPS in quanto lo stesso Azure incorpora filtri di protezione e l’utilizzo di tale tecnologia legacy potrebbe generare falsi positivi.

Quali sono le best practice più importanti per la sicurezza di Azure?

Le priorità sono proteggere le identità con MFA e Conditional Access, applicare il minimo privilegio con RBAC e PIM, ridurre l’esposizione di rete, usare Defender for Cloud per la security posture, centralizzare i log, proteggere dati e workload e applicare governance tramite Azure Policy.

Microsoft Azure è sicuro di default?

Azure fornisce controlli e protezioni di piattaforma, ma la sicurezza segue un modello di responsabilità condivisa. Il cliente resta responsabile, tra l’altro, di dati, identità, account, configurazioni e controlli di accesso. Una risorsa cloud può quindi risultare esposta anche se la piattaforma sottostante è sicura.

Che differenza c’è tra Microsoft Defender for Cloud e Microsoft Sentinel?

Microsoft Defender for Cloud è orientato alla gestione della security posture e alla protezione dei workload cloud. Microsoft Sentinel è una piattaforma SIEM/SOAR usata per centralizzare, correlare e analizzare eventi di sicurezza e supportare detection, investigation e incident response.

A cosa serve Microsoft Entra Privileged Identity Management?

Privileged Identity Management consente di gestire l’accesso privilegiato in modalità just-in-time. Gli amministratori possono attivare un ruolo solo quando serve, per un tempo limitato e con controlli aggiuntivi come MFA, approvazione e auditing.

Azure Firewall sostituisce i Network Security Group?

No. NSG e Azure Firewall operano a livelli diversi e sono complementari. Gli NSG applicano filtri di rete a subnet e interfacce, mentre Azure Firewall può centralizzare il controllo del traffico e, nelle funzionalità avanzate, offrire ispezione applicativa, threat intelligence, TLS inspection e IDPS.

Quale protezione DDoS è disponibile in Azure?

Azure offre una protezione DDoS infrastrutturale per i servizi con indirizzi pubblici e livelli dedicati denominati DDoS IP Protection e DDoS Network Protection. Per gli attacchi applicativi di livello 7 è necessario affiancare un Web Application Firewall.

Come si misura la security posture di un ambiente Azure?

Microsoft Defender for Cloud fornisce raccomandazioni e Secure Score. Il Microsoft Cloud Security Benchmark può essere usato come baseline per valutare controlli su identità, rete, privilegi, dati, logging, vulnerability management e altre aree di sicurezza.