Microsoft AZ-500: Sicurezza di dati, storage e database — Guida allo studio

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

Fa parte della Microsoft Azure Security Engineer Associate AZ-500 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La sicurezza dei dati, dello storage e dei database in Azure si concentra sulla riduzione al minimo della fiducia (minimize trust), sull’isolamento dei piani dati, sulla crittografia onnipresente e sull’operatività del principio del privilegio minimo (least privilege) con percorsi di accesso verificabili. Questa sezione spiega come rafforzare la sicurezza (harden) di Azure Storage, Azure SQL e Azure Cosmos DB, scegliere la strategia corretta per identità e chiavi e prevenire l’esfiltrazione dei dati. Ogni controllo descritto è accompagnato dalla logica operativa che lo motiva, in modo da poter giustificare e mantenere la configurazione in produzione.

Messa in sicurezza degli account di Azure Storage e dell’accesso ai dati

Autorizzazione e condivisione degli account di storage

• Azure RBAC per Azure Storage: Preferire l’autorizzazione basata su Azure AD (per Blob e Queue) tramite ruoli predefiniti come Storage Blob Data Reader/Contributor. Logica: accesso basato su token, con scadenza temporale tramite Conditional Access, registrato in Entra ID; evita le chiavi di account perpetue e supporta l’assegnazione just-in-time.
• Chiavi condivise: Le chiavi primarie/secondarie dell’account garantiscono pieni diritti sul piano dati. Disabilitare l’uso delle chiavi nel codice ed effettuare rotazioni frequenti. Logica: le chiavi condivise sono segreti di tipo “bearer” senza alcun legame con l’utente o con una CA; una loro compromissione equivale all’esposizione totale dei dati.
• Tipi di SAS:
  • SAS di servizio: Concede un accesso limitato (scoped) a risorse specifiche (blob, file, coda, tabella) con permessi, IP, protocollo e limiti di tempo. Logica: privilegio minimo preciso per le applicazioni che non possono utilizzare i token di AD.
  • SAS di account: Superficie più ampia (ad es. tra più servizi); da usare con parsimonia. Logica: espande il raggio d’impatto (blast radius) in caso di fuga di notizie.
  • SAS di delega utente: Emessa utilizzando Azure AD e una chiave di delega utente per i Blob. Logica: si lega all’identità di Azure AD e alla CA; auditabilità e revoca superiori.
• Criteri di accesso archiviati (Stored access policies): Definiscono vincoli riutilizzabili (scadenza, permessi) per le SAS su contenitori/condivisioni; la revoca o l’aggiornamento del criterio invalida le SAS emesse con esso. Logica: revoca centralizzata senza dover rigenerare i token incorporati nei client.

Esempio: generare una SAS di delega utente per un blob con Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Sicurezza del servizio per tipo

• Blob/Queue/Table: Utilizzare Azure AD RBAC dove supportato (Blob, Queue). Impostare AllowBlobPublicAccess su false, richiedere HTTPS, abilitare il controllo delle versioni (versioning) e l’eliminazione temporanea (soft delete). Logica: rimuove i percorsi di esposizione anonima e abilita il ripristino dei dati.
• Azure Files: Utilizzare Azure AD Kerberos per SMB con Entra ID (o integrazione con AD DS) e applicare permessi di privilegio minimo a livello di condivisione/file. Richiedere la crittografia SMB. Logica: accesso legato all’identità con sicurezza a livello di trasporto su SMB; nessuna chiave condivisa nello spazio utente.
• Servizio tabelle (Table service): Utilizzare SAS con vincoli rigidi di IP/tempo ed evitare le SAS di account. Logica: la granularità a livello di servizio non è altrettanto ricca; definire l’ambito (scope) in modo aggressivo.

Isolamento di rete per tutti i servizi di storage

• Regole del firewall dello storage: Limitare l’accesso a intervalli di IP pubblici selezionati solo quando Private Link non è fattibile. Logica: riduce la superficie di attacco ma il traffico attraversa comunque la rete Internet pubblica.
• Endpoint privati: Preferire Private Link per Blob, Queue, Table e Files. Mappare le zone DNS private a nomi specifici delle risorse. Impostare l’accesso alla rete pubblica su Disabilitato (Disabled). Logica: il traffico rimane sulla backbone di Azure; l’identità della risorsa è convalidata tramite DNS privato; mitiga l’esfiltrazione verso servizi simili.
• Endpoint di servizio e criteri: Se Private Link non è un’opzione, abilitare gli endpoint di servizio e applicare i criteri degli endpoint di servizio per limitare il traffico in uscita (egress) a specifici account di storage. Logica: vincola il traffico anche in uscita dalla rete virtuale; limita il rischio di inviare dati ad account di proprietà di un utente malintenzionato.

Impostazioni operative da standardizzare

• Imporre solo HTTPS, con TLS 1.2 come versione minima.
• Disabilitare l’accesso con chiave condivisa per Blob e Queue se si utilizza AD (dipende dal supporto della funzionalità).
• Criteri di immutabilità su contenitori/condivisioni critici per la conservazione a norma di legge e la resilienza al ransomware.

Crittografia e gestione delle chiavi

Livelli di crittografia at-rest

• Chiavi gestite dal servizio (SMK): Crittografia lato server predefinita, gestita da Azure. Logica: nessun sovraccarico operativo; adatta a molti carichi di lavoro.
• Chiavi gestite dal cliente (CMK): Chiavi in Key Vault o Managed HSM per Storage, SQL e Cosmos DB. Logica: confine di fiducia (trust boundary) esternalizzato, controllo del cliente sulla rotazione/revoca e prove di conformità.
• Crittografia dell’infrastruttura (doppia crittografia): Livello aggiuntivo che utilizza chiavi separate. Logica: difesa in profondità (defense-in-depth) nel caso in cui la crittografia dei supporti di archiviazione venga aggirata o un confine crittografico venga compromesso.

Rotazione e operazioni sulle chiavi

• Le SMK vengono ruotate automaticamente; non è richiesta alcuna azione.
• Le CMK vengono ruotate creando una nuova versione della chiave, concedendo i permessi di wrap/unwrap e facendo puntare la risorsa alla versione più recente (o a un riferimento di chiave senza versione, quando supportato). Logica: rotazione non distruttiva con modifiche verificabili.
• Proteggere le chiavi con l’eliminazione temporanea (soft delete) e la protezione dall’eliminazione definitiva (purge protection) di Key Vault; controllare l’amministrazione tramite RBAC e il piano dati tramite criteri di accesso o RBAC (per Managed HSM, usare RBAC). Logica: previene la perdita distruttiva delle chiavi e applica il principio del privilegio minimo.

Esempio: impostare una CMK per un account di storage

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Ambiti di crittografia (Encryption scopes)

• Utilizzare ambiti di crittografia per contenitore (per-container encryption scopes) in Storage quando set di dati diversi richiedono chiavi distinte. Logica: segmentare il raggio d’impatto (blast radius) e abilitare cicli di vita delle chiavi differenziati.

Sicurezza della piattaforma di database: Azure SQL e Azure Cosmos DB

Autenticazione e accesso in Azure SQL

• Autenticazione con Microsoft Entra: Creare un amministratore Azure AD a livello di server; utilizzare utenti di database indipendente (contained database user) (CREATE USER FROM EXTERNAL PROVIDER). Motivazione: evita login/password SQL e abilita l’Accesso Condizionale (Conditional Access) e PIM.
• Utenti indipendenti (Contained user): L’identità risiede nel database, non nel master. Motivazione: semplifica il ripristino geografico (geo-restore) e il failover senza dover rieseguire il provisioning dei login.
• Regole del firewall: Evitare regole IP client generiche; preferire Private Link con l’accesso alla rete pubblica disabilitato. Se le regole IP sono necessarie, limitarle a indirizzi esatti e automatizzarne la revisione. Motivazione: restringe la superficie di attacco e riduce la possibilità di individuazione tramite endpoint pubblici.
• Endpoint privati: Indirizzare tutto il traffico del piano dati (data-plane) su VNet con DNS privato. Motivazione: elimina l’esposizione e semplifica la prevenzione dell’esfiltrazione dei dati.
• Pattern di autenticazione: Utilizzare l’autenticazione integrata di Active Directory (per dispositivi aggiunti a un dominio) o il flusso interattivo/codice dispositivo per ottenere i token; i carichi di lavoro dei servizi dovrebbero usare le identità gestite (managed identity). Motivazione: elimina le password e abilita la gestione della durata/policy dei token.

Funzionalità di protezione dei dati

• Transparent Data Encryption (TDE): Attivo per impostazione predefinita; crittografa dati/log/backup. Motivazione: protegge i dati at-rest senza modifiche all’applicazione. Utilizzare TDE con CMK per un controllo esternalizzato.
• Always Encrypted: Crittografia lato client per colonne sensibili con chiavi in Key Vault. Motivazione: impedisce agli operatori SQL o al motore di database di vedere i dati in chiaro; da usare per campi PII/PCI.
• Dynamic Data Masking (DDM): Offusca i risultati delle query per gli utenti non privilegiati. Motivazione: riduce l’esposizione accidentale dei dati ma non è un confine di sicurezza; da combinare con RBAC.
• Auditing: Inviare i log a Log Analytics, Event Hubs o Storage. Motivazione: crea una traccia immutabile per indagini e conformità.

Esempio: abilitare l’auditing a livello di server verso Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Vulnerability Assessment (VA): Definisce baseline ed esegue scansioni di schema/configurazione; esporta su storage; si integra con i gate DevSecOps. Motivazione: igiene continua e rilevamento delle deviazioni (drift detection) con chiare indicazioni per la risoluzione.
• Rilevamento delle minacce (Threat Detection): Rileva SQL injection, accessi anomali, accessi da località sconosciute, abusi di privilegi. Motivazione: rilevamento gestito con basso overhead operativo; integra i controlli di rete.
• Risposta agli avvisi: Indirizzare a Logic Apps, e-mail, SIEM. Creare playbook per il triage, la sospensione degli utenti, la revoca dei token e il rafforzamento del firewall. Motivazione: una risposta codificata riduce il tempo medio di contenimento (MTTC).

Sicurezza di Azure Cosmos DB

• Chiavi e token: Le chiavi primarie/secondarie sono altamente privilegiate; ruotarle regolarmente. Preferire Azure AD RBAC per le operazioni sul piano dati (data-plane) con ruoli come Cosmos DB Built-in Data Contributor/Reader. Motivazione: accesso legato all’identità con Accesso Condizionale (CA) e audit.
• Controlli di rete: Lista di indirizzi IP consentiti (allow list) nel firewall per contingenze; Endpoint Privati (Private Endpoint) come percorso predefinito; disabilitare l’accesso pubblico se possibile. Motivazione: controllo garantito del percorso e validazione dell’endpoint.
• Crittografia: At-rest per impostazione predefinita; abilitare CMK per un controllo aggiuntivo. Motivazione: soddisfa i requisiti di crittografia esterni e la separazione dei compiti (separation of duties).
• Log di diagnostica e metriche: Abilitare le categorie DataPlaneRequests, ControlPlaneRequests e quelle specifiche per le API (es. MongoRequests). Motivazione: osservabilità end-to-end per i pattern di accesso, il throttling e le richieste anomale.

Controlli di Monitoraggio, Classificazione ed Esfiltrazione

Segreti e stringhe di connessione supportati da Key Vault

• Utilizzare le identità gestite per recuperare segreti/chiavi a runtime; non archiviare mai i segreti nel codice o nelle impostazioni. Motivazione: elimina la proliferazione delle credenziali e la necessità di rotazione dei segreti nelle applicazioni.
• Riferimento a Key Vault per App Service/Functions

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• Quando possibile, preferire i token di accesso di Azure AD per SQL rispetto alle stringhe di connessione basate su segreti. Motivazione: policy e revoca più robuste.

Protezione delle informazioni e classificazione dei dati

• Etichette di riservatezza di Microsoft Purview Information Protection: Applicare etichette con crittografia e diritti di utilizzo per documenti ed e-mail; integrare con l’etichettatura automatica. Motivazione: protezione persistente che va oltre i confini dello storage.
• SQL Information Protection (Azure SQL): Utilizzare la data discovery e la classificazione integrate, consigliare etichette per le colonne ed esportare verso Purview. Motivazione: governance centralizzata e policy coerenti in tutto il patrimonio di dati (data estate).

Controlli sull’esfiltrazione dei dati e pattern di accesso sicuro

• Prima di tutto Private Link: Per Storage, SQL e Cosmos DB. Disabilitare gli endpoint pubblici. Motivazione: impedisce l’accesso dalla rete internet pubblica e impone che il traffico provenga da VNet approvate.
• Filtraggio in uscita (Egress): Utilizzare Azure Firewall con tag FQDN e regole DNAT che consentono solo gli endpoint Azure necessari; aggiungere policy per i service endpoint dove Private Link non è praticabile. Motivazione: l’allow-listing in uscita blocca la fuga di dati verso endpoint controllati da malintenzionati.
• Regole per istanze di risorsa: Per il firewall di Storage, consentire l’accesso solo a istanze di risorse attendibili specifiche (es. un workspace Synapse). Motivazione: lega l’accesso a producer/consumer noti, non solo alle reti.
• Rafforzamento delle SAS: Ove possibile, utilizzare SAS di delega utente, limitare a HTTPS, restringere gli IP, usare permessi minimi e durate brevissime; legarle a policy di accesso archiviate per la revoca. Motivazione: riduce l’uso improprio dei token e semplifica l’invalidazione in caso di emergenza.
• AKS e service endpoint: Se si utilizzano i service endpoint, usare Azure CNI in modo che i pod ottengano IP della VNet ed ereditino l’accesso tramite l’endpoint. Motivazione: collega il traffico dei container ai controlli nativi della VNet; altrimenti, gli endpoint non si applicano al traffico dei pod sottoposto a NAT.
• Logging e analisi: Abilitare i log di diagnostica di Storage, SQL e Cosmos DB verso Log Analytics; creare avvisi per volumi di dati anomali, picchi nell’emissione di SAS e frequenti errori 403. Motivazione: rilevamento precoce dei tentativi di esfiltrazione.

Scenario Pratico

Spotify deve impedire l’esfiltrazione di dati dalle subnet degli sviluppatori e dai carichi di lavoro AKS verso endpoint Storage e SQL non autorizzati, consentendo al contempo alle pipeline di CI/CD di eseguire test di integrazione.

1. Disabilitare l’accesso dalla rete pubblica e creare Private Endpoint per tutti gli account Storage e i server Azure SQL di produzione. Motivazione: Forza tutti i flussi del data-plane a passare su Private Link, eliminando l’ingresso/uscita pubblici e abilitando una rigida applicazione dell’origine tramite VNet e DNS privato.

2. Configurare zone DNS private con record A che mappano gli FQDN delle risorse di storage e database agli IP dei private endpoint; collegare tutte le VNet necessarie. Motivazione: Impedisce la risoluzione DNS verso endpoint pubblici (DNS leakage) e garantisce che i client risolvano le risorse private previste.

3. Nei firewall di Storage, aggiungere regole per istanze di risorsa solo per le identità del cluster AKS di produzione e del scale set degli agenti di build; impostare l’azione predefinita su ’nega’ (deny). Motivazione: Anche all’interno della stessa VNet, solo le identità delle risorse approvate possono accedere all’account, contrastando i movimenti laterali e l’esfiltrazione da carichi di lavoro non attendibili.

4. Imporre l’uso di Azure CNI su AKS e abilitare i service endpoint con policy per service endpoint per consentire ai namespace di sviluppo di raggiungere solo un account di storage non di produzione dedicato. Motivazione: I pod di sviluppo ottengono IP della VNet, quindi le policy di rete vengono applicate; le policy per gli endpoint limitano qualsiasi traffico non privato strettamente agli account autorizzati.

5. Sostituire le chiavi condivise con Azure AD RBAC per Blob e Queue nel codice dell’applicazione; dove la condivisione è inevitabile per i test, emettere SAS di delega utente con policy di accesso archiviate e scadenza di 1 ora. Motivazione: I token legati a un’identità sono verificabili e revocabili; le SAS a breve durata minimizzano il rischio se un token viene esposto nei log di build.

6. Abilitare Defender for SQL con rilevamento delle minacce e Vulnerability Assessment; instradare gli avvisi e i log di audit di SQL a un workspace Log Analytics centrale con Logic Apps automatizzate per il triage (disabilitare l’utente, revocare le sessioni, aggiungere una regola di ’nega’ temporanea al firewall). Motivazione: I rilevamenti gestiti accelerano il contenimento di SQL injection e accessi anomali, mentre i playbook standardizzano e velocizzano la risposta.

7. Utilizzare Key Vault per la CMK che protegge TDE e gli ambiti di crittografia di Storage; abilitare l’eliminazione temporanea (soft delete) e la protezione dall’eliminazione definitiva (purge protection); ruotare le chiavi trimestralmente e aggiornare i riferimenti delle risorse alla versione più recente della chiave. Motivazione: Il controllo crittografico esternalizzato con una rotazione sicura soddisfa la conformità e riduce il rischio di errori operativi.

8. Classificare le colonne sensibili in Azure SQL con SQL Information Protection e integrarle in Microsoft Purview; applicare etichette di riservatezza MIP per le esportazioni a valle. Motivazione: L’etichettatura persistente viaggia con i dati estratti, limitandone l’uso improprio e consentendo agli strumenti DLP di applicare controlli su diversi strumenti e dispositivi.

9. Bloccare il traffico in uscita (egress) con Azure Firewall consentendo solo i servizi Azure richiesti da build/test, utilizzando tag FQDN per Storage e SQL e negando il traffico HTTP(S) in uscita con wildcard. Motivazione: Un modello di sicurezza positivo garantisce che il traffico possa raggiungere solo gli endpoint approvati, impedendo che i dati vengano inviati a domini di malintenzionati.

Questa sequenza impedisce l’accesso pubblico, limita chi e cosa può raggiungere i dati, lega l’accesso alle identità anziché ai segreti e rende operativi il monitoraggio e la risposta rapida, il tutto preservando la velocità di sviluppo attraverso eccezioni mirate e a tempo.

← Sicurezza di compute · Tutti i domini · Gestione delle chiavi →

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

Sfoglia Microsoft →