Microsoft AZ-305: Architettura della sicurezza e Zero Trust — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Solutions Architect Expert AZ-305 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’architettura di sicurezza su Azure si fonda sul principio Zero Trust: non fidarsi mai, verificare sempre, autorizzare esplicitamente e presupporre la violazione. Le architetture devono imporre un accesso basato sull’identità, la micro-segmentazione, una solida protezione dei dati e un rilevamento e una risposta continui alle minacce. Questa sezione collega i pilastri — identità e segreti, protezione dei dati, controlli di rete e difesa nativa dalle minacce cloud — in progetti coesi e allineati con le capacità della piattaforma Azure.

Fondamenti di Identità, Segreti e Zero Trust

Lo Zero Trust inizia con una solida verifica dell’identità e il principio del privilegio minimo. Ogni identità, sia di un carico di lavoro che umana, dovrebbe essere valutata al momento dell’accesso, con controlli condizionali e token di breve durata. Applicare il privilegio minimo limitando le autorizzazioni al più piccolo insieme di azioni sul confine di risorsa più ristretto possibile, e preferire l’elevazione just-in-time (JIT) con Privileged Identity Management (PIM) dove applicabile.

Azure Key Vault è centrale per la gestione di segreti e chiavi. Esistono due modelli di autorizzazione per il piano dati:

I criteri di accesso (Access policies) sono il modello ACL legacy per-vault. Concedono autorizzazioni granulari su segreti/chiavi/certificati ai principal, ma non si integrano con le assegnazioni di negazione (deny assignments) di Azure RBAC o con PIM, e complicano la governance su larga scala perché il loro ambito è limitato al singolo vault.
Azure RBAC per Key Vault è il modello moderno. Quando abilitato sul vault, le autorizzazioni del piano dati sono controllate dai ruoli Azure RBAC (ad esempio, Key Vault Secrets User, Key Vault Crypto Officer), vengono ereditate tra gli ambiti (gruppo di gestione, sottoscrizione, gruppo di risorse), supportano le assegnazioni di negazione e si integrano con PIM e Access Reviews. Scegliere RBAC per coerenza e governance centralizzata; non mescolare i due modelli sullo stesso vault.

L’eliminazione temporanea (Soft delete) e la protezione dall’eliminazione definitiva (purge protection) prevengono la perdita accidentale o dolosa. L’eliminazione temporanea conserva gli oggetti eliminati per un periodo di conservazione (configurabile da 7 a 90 giorni, predefinito 90), consentendone il ripristino. La protezione dall’eliminazione definitiva, quando abilitata, impedisce la cancellazione permanente degli elementi eliminati temporaneamente fino alla scadenza del periodo di conservazione, anche da parte di utenti con privilegi elevati. Per i vault di produzione, abilitare entrambe le funzionalità. Managed HSM fornisce moduli di sicurezza hardware (HSM) dedicati e convalidati FIPS 140-2 Level 3, sotto il controllo di Azure. Supporta solo chiavi (non segreti/certificati), utilizza Azure RBAC con ruoli come Managed HSM Administrator, Crypto Officer e Crypto User, e ha l’eliminazione temporanea e la protezione dall’eliminazione definitiva sempre attive. Utilizzare Managed HSM quando si richiede isolamento delle chiavi basato su hardware, amministrazione basata su quorum o garanzie normative per i controlli dei confini crittografici.

Le Identità gestite di Azure (Azure Managed Identities) eliminano la necessità di credenziali per i carichi di lavoro ospitati su Azure. Le identità assegnate dal sistema (System-assigned identities) sono legate al ciclo di vita di una singola risorsa; l’eliminazione della risorsa elimina l’identità. Sono ideali per risorse singole (una Function App o una VM) che necessitano di confini di autorizzazione indipendenti. Le identità assegnate dall’utente (User-assigned identities) sono autonome e possono essere associate a più risorse; persistono quando le risorse di calcolo vengono sostituite o scalate, rendendole adatte per flotte, deployment blue/green o quando è richiesta un’identità coerente tra più istanze. I carichi di lavoro ottengono i token senza segreti chiamando il servizio di metadati dell’istanza (IMDS) all’indirizzo 169.254.169.254 o l’endpoint dell’identità gestita della piattaforma, richiedendo un token di accesso per una risorsa (ad esempio, https://vault.azure.net per Key Vault). Utilizzare Azure RBAC per concedere all’identità i ruoli con il privilegio minimo sulle risorse di destinazione; la piattaforma ruota automaticamente le credenziali.

Azure AD Workload Identity Federation elimina la necessità di archiviare credenziali cloud in sistemi CI/CD esterni e in Kubernetes. Con GitHub Actions, creare una credenziale federata sull’applicazione Azure AD utilizzando l’issuer OIDC di GitHub (token.actions.githubusercontent.com) e vincolarla per repository, branch o ambiente. GitHub scambia il suo token OIDC con un token Azure AD a runtime; assegnare ruoli Azure a tale applicazione e applicare il privilegio minimo per ogni workflow. Per Kubernetes (AKS), abilitare OIDC sul cluster e configurare l’identità del carico di lavoro di Azure AD. Mappare il token OIDC di un ServiceAccount a un’applicazione Azure AD o a un’identità gestita assegnata dall’utente tramite una credenziale federata, quindi associare i ruoli Azure a tale identità. I pod scambiano il loro token OIDC proiettato con token Azure per chiamare servizi come Key Vault o Storage — non sono richiesti segreti o agent a livello di nodo e si ottiene un isolamento migliore rispetto al legacy aad-pod-identity.

Protezione dalle minacce, SIEM/SOAR e governance delle app cloud

Microsoft Defender for Cloud fornisce la gestione della postura di sicurezza del cloud (cloud posture management) e la protezione dei carichi di lavoro (workload protection). Il Secure Score quantifica il rischio valutando le configurazioni errate e raccomandando impostazioni di protezione avanzata (ad esempio, l’abilitazione dell’MFA, l’applicazione della crittografia dei dischi o la restrizione degli endpoint pubblici). Promuovi i miglioramenti del Secure Score tramite l’assegnazione di policy a livello di management group per standardizzare le baseline. Le protezioni dei carichi di lavoro si estendono a server, container, database, storage, Key Vault e App Service per fornire rilevamento delle minacce, valutazioni delle vulnerabilità e funzionalità come l’accesso just-in-time alle VM, i controlli adattivi delle applicazioni e il monitoraggio dell’integrità dei file. La conformità normativa mappa il tuo ambiente rispetto a standard (Azure Security Benchmark, CIS, PCI-DSS, ISO 27001) e mostra i risultati (superato/non superato) rispetto ai controlli delle policy; utilizzala per tracciare e risolvere le lacune con gli stakeholder della governance.

Microsoft Sentinel è il SIEM e SOAR cloud-native. I connettori di dati acquisiscono la telemetria da Azure Activity, dagli accessi e audit di Azure AD, da Microsoft 365, dalla suite Microsoft Defender, dalle risorse Azure e da origini non-Azure tramite Syslog/CEF o gli agenti AMA/Log Analytics. Le regole di analisi (Analytics rules) rilevano le minacce utilizzando KQL: regole pianificate (scheduled rules) per la correlazione periodica, regole quasi in tempo reale (near-real-time rules) per il rilevamento a bassa latenza e modelli di machine learning/anomalie per insight comportamentali. Ottimizza le soglie delle regole, la soppressione e la mappatura delle entità per ridurre il rumore e arricchire gli incidenti. Automatizza le risposte con i playbook SOAR creati in Logic Apps; attiva l’isolamento degli host compromessi tramite Defender for Endpoint, disabilita gli account sospetti in Azure AD, revoca le sessioni, elimina le email dannose o invia notifiche e apri ticket. Usa le regole di automazione (automation rules) per instradare gli incidenti, assegnare tag in base alla gravità e richiamare i playbook in base alle proprietà dell’incidente.

Microsoft Defender for Cloud Apps governa l’utilizzo delle applicazioni SaaS. La funzionalità di Shadow IT discovery acquisisce i log di firewall/proxy e la telemetria degli endpoint per identificare le app non approvate (unsanctioned), classificarle in base al rischio e consentirti di approvarle/non approvarle (sanction/unsanction). Integralo con Defender for Endpoint per un rilevamento continuo. I controlli di sessione (Session controls) applicano il Conditional Access App Control in tempo reale tramite un reverse proxy per applicare policy come il blocco del download per i dispositivi non gestiti, la richiesta di etichettatura dei documenti prima del download, l’applicazione di filigrane (watermarking) o la restrizione delle operazioni di taglia/copia/incolla, senza modificare l’app SaaS.

Protezione dei dati e Confidential Computing

Azure Information Protection rende operativa la classificazione e la protezione dei dati tramite le etichette di riservatezza (sensitivity labels). Le etichette definiscono la classificazione, i contrassegni visivi, la crittografia (Azure Rights Management) e i diritti di utilizzo (visualizzazione, stampa, inoltro, accesso offline). Pubblica le etichette tramite le policy delle etichette (label policies) per utenti selezionati e richiedi l’etichettatura obbligatoria dove appropriato. Le policy di etichettatura automatica (Auto-labeling policies) possono applicare etichette nelle app di Office sugli endpoint in base all’analisi del contenuto (ad esempio, pattern PII, parole chiave) e sui dati a riposo (at rest)/in transito (in transit) nei servizi tramite strumenti di data governance, riducendo l’errore umano e rafforzando la protezione di base. Utilizza le richieste di giustificazione per i downgrade delle etichette e controlla le modifiche alle etichette per supportare la governance.

Azure Confidential Computing protegge i dati in uso (data in use) eseguendo i carichi di lavoro all’interno di ambienti di esecuzione attendibili (Trusted Execution Environments) basati su hardware. Le Confidential VM (ad esempio, AMD SEV-SNP o Intel TDX) crittografano la memoria della VM e ne garantiscono l’integrità, proteggendo i carichi di lavoro guest dall’host cloud e da altri tenant. Utilizzale per scenari di lift-and-shift che richiedono protezioni a livello di enclave senza modifiche alle applicazioni. I confidential container su AKS eseguono carichi di lavoro containerizzati su pool di nodi confidential; combinali con immagini di container crittografate e l’attestazione (attestation) per garantire che vengano eseguiti solo carichi di lavoro attestati. L’attestazione viene eseguita utilizzando Azure Attestation per verificare le misurazioni (quotes) della piattaforma e del carico di lavoro prima di rilasciare i segreti. Integra i controlli di attestazione nel tuo control plane o nella tua pipeline di deployment; solo a seguito di un’attestazione riuscita, Key Vault o un KMS esterno dovrebbero rilasciare le chiavi di decrittografia al carico di lavoro, completando la protezione dei dati in uso.

Segmentazione della Rete, Perimetro e Difesa DDoS Stratificata

La micro-segmentazione della rete limita il movimento laterale e si abbina alla verifica dell’identità per applicare il modello Zero Trust. I Gruppi di Sicurezza di Rete (NSG) sono filtri di pacchetti stateful applicati a subnet o NIC; utilizza i tag di servizio e le negazioni esplicite per limitare i flussi est-ovest e nord-sud, nega per impostazione predefinita le porte non necessarie e registra i log con i log di flusso NSG. I Gruppi di Sicurezza delle Applicazioni (ASG) astraggono gruppi di carichi di lavoro dinamici, consentendo di scrivere regole NSG in base al ruolo dell’applicazione anziché agli indirizzi IP. Questo abilita una segmentazione basata sull’intento (intent-based) che scala con l’autoscaling e gli indirizzi effimeri.

Azure Firewall fornisce un controllo centralizzato e completamente stateful a livello L3–L7 con regole di applicazione e di rete, filtraggio FQDN, DNAT/SNAT, filtraggio basato sulla threat intelligence e funzionalità Premium come l’ispezione TLS e l’IDPS per un’ispezione approfondita del traffico in uscita e in entrata. Utilizza la Firewall Policy per una configurazione basata sull’intento e per l’ereditarietà tra le diverse region. Instrada il traffico in uscita (egress) attraverso Azure Firewall con route definite dall’utente e abbinalo a Endpoint Privati per mantenere il traffico PaaS al di fuori della rete Internet pubblica.

Le applicazioni esposte sul web dovrebbero essere protette da un Web Application Firewall (WAF). Implementa il WAF su Application Gateway per il bilanciamento del carico di livello 7 a livello regionale e integrato con la VNet, oppure su Azure Front Door per un punto di ingresso anycast globale e l’integrazione con la CDN. Abilita le regole gestite da OWASP e aggiungi regole personalizzate per il filtraggio basato su percorso/geografia/IP e per le difese contro i bot, e integra il tutto con le strategie DDoS a livello di edge.

DDoS Protection Standard aggiunge la mitigazione adattiva in tempo reale per gli endpoint pubblici nelle VNet, la telemetria e la protezione dei costi per lo scale-out durante un attacco. Applica i Piani di Protezione DDoS a livello di VNet per tutte le risorse IP pubbliche associate, esegui test con traffico simulato e revisiona le metriche e gli avvisi. Stratifica la tua difesa: DDoS a livello di edge, WAF a livello L7, Azure Firewall per le policy L3–L7, NSG/ASG per la micro-segmentazione e Accesso Condizionale (Conditional Access) più conformità dei dispositivi per un’applicazione basata sull’identità.

Scenario di un Problema Pratico

Starbucks sta modernizzando una piattaforma di ordinazione multi-regionale su Azure utilizzando AKS, Azure SQL Database ed Event Hubs. L’architettura deve adottare il modello Zero Trust: eliminare i segreti hardcoded, segmentare le reti, proteggere i dati in uso e implementare il rilevamento unificato delle minacce e la risposta automatizzata su cloud e SaaS.

Applicare l’accesso basato sull’identità per i carichi di lavoro

Implementare identità gestite assegnate dall’utente per i carichi di lavoro AKS che necessitano di accesso a Key Vault e Storage. Assegnare ruoli RBAC con privilegi minimi (Key Vault Secrets User, Storage Blob Data Reader) a livello di gruppo di risorse. Scelta motivata dal fatto che le identità gestite eliminano i segreti, supportano pod in scale-out che condividono un’identità stabile e si integrano con PIM/Access Reviews tramite Azure RBAC.

Federare la CI/CD senza credenziali memorizzate

Configurare la federazione delle identità dei carichi di lavoro di Azure AD per GitHub Actions utilizzando l’issuer OIDC di GitHub e vincoli su repository/ambiente. I workflow ottengono i token di Azure a runtime per distribuire Bicep e Helm. Scelta motivata per eliminare PAT/segreti, ridurre il raggio d’impatto (blast radius) a specifici repository/branch e abilitare claim condizionali.

Proteggere chiavi e segreti con garanzie di ripristino

Utilizzare Azure Key Vault con il modello di autorizzazione RBAC, con l’eliminazione temporanea (soft delete) e la protezione dall’eliminazione definitiva (purge protection) abilitate. Archiviare stringhe di connessione e segreti delle applicazioni; archiviare le chiavi di protezione TDE per Azure SQL in un Managed HSM per la garanzia FIPS Level 3. Scelta motivata per l’auditing centralizzato, la recuperabilità e l’isolamento delle chiavi basato su hardware per il materiale crittografico critico.

Segmentare le reti e centralizzare il traffico in uscita (egress)

Applicare NSG con negazione predefinita (default-deny) e ASG per i diversi livelli (web, api, dati). Forzare tutto il traffico in uscita (egress) attraverso Azure Firewall Premium con IDPS e ispezione TLS; utilizzare Endpoint Privati per Azure SQL e Key Vault. Scelta motivata per implementare la micro-segmentazione a livello di subnet/NIC, l’ispezione approfondita dei pacchetti (deep packet inspection) per il controllo dell’esfiltrazione e l’accesso privato ai servizi PaaS.

Proteggere il perimetro pubblico (public edge)

Proteggere il livello web con Azure Front Door, utilizzando policy WAF con OWASP CRS e regole personalizzate per il throttling geografico/IP e le firme dei bot. Abilitare DDoS Protection Standard sulla VNet hub che ospita l’Application Gateway per il failover regionale. Scelta motivata per assorbire attacchi volumetrici a livello globale e bloccare gli exploit L7 prima che raggiungano AKS.

Governare l’accesso SaaS e i dispositivi non gestiti

Integrare Microsoft Defender for Cloud Apps con l’App Control dell’Accesso Condizionale per applicare controlli di sessione su M365 e SaaS di terze parti approvati: bloccare i download su dispositivi non gestiti, richiedere etichette di riservatezza al momento del download e applicare una filigrana (watermark). Scelta motivata per i controlli in tempo reale senza modifiche alle app e per un’applicazione coerente su tutto l’ecosistema SaaS.

Classificare e proteggere i dati sensibili

Definire etichette di riservatezza di Azure Information Protection (Pubblico, Riservato, Altamente Riservato – Dati Cliente) con crittografia e diritti di utilizzo. Abilitare policy di etichettatura automatica per i pattern PII in Office e sui dati a riposo (at rest) in SharePoint/OneDrive. Scelta motivata per standardizzare la gestione dei dati, ridurre l’errore umano e mantenere una protezione persistente.

Proteggere i dati in uso per l’elaborazione dei pagamenti

Eseguire i microservizi di pagamento su pool di nodi confidenziali di AKS e i modelli di rischio batch su VM confidenziali (AMD SEV-SNP). Controllare l’accesso alle chiavi di decrittazione tramite Azure Attestation; solo i nodi/pod attestati ricevono i segreti da Key Vault. Scelta motivata per proteggere la memoria dall’accesso dell’host/tenant e per stabilire un avvio misurato (measured boot) e l’integrità del carico di lavoro.

Stabilire la gestione della postura di sicurezza e la conformità

Abilitare Microsoft Defender for Cloud a livello di gruppo di gestione con gli standard Azure Security Benchmark e PCI-DSS. Attivare i piani Defender pertinenti (container, server, SQL, Key Vault) e l’accesso JIT alle VM. Scelta motivata per il Secure Score centralizzato, le mappature normative e le protezioni native dei carichi di lavoro.

Centralizzare il rilevamento e orchestrare la risposta

Inviare la telemetria a Microsoft Sentinel tramite i connettori dati (Azure AD, Azure Activity, M365, Defender, log di AKS, Firewall). Implementare regole di analisi per il furto di credenziali, il traffico in uscita sospetto, le evasioni di container (container escape) e l’attività amministrativa anomala. Automatizzare con i playbook di Logic Apps per disabilitare account compromessi, isolare nodi AKS, bloccare il traffico in uscita in Azure Firewall e aprire ticket. Scelta motivata per un SIEM/SOAR cloud-native, l’implementazione rapida di regole e la stretta integrazione con i segnali di sicurezza Microsoft.

Questo design applica il modello Zero Trust end-to-end: le identità vengono verificate continuamente, i privilegi sono minimi e just-in-time, le reti sono micro-segmentate con ispezione centralizzata, i dati sono classificati e protetti sia a riposo (at rest) che in uso, e il rilevamento continuo delle minacce con risposta automatizzata riduce il tempo medio di contenimento.

← Alta disponibilità · Tutti i domini · Architettura di integrazione e messaggistica →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →