Microsoft AZ-500: Sicurezza delle applicazioni e DevSecOps — 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 delle applicazioni e il DevSecOps in Azure si concentrano sulla prevenzione dell’uso improprio delle identità, sulla protezione dell’ingresso e delle API, sull’integrazione della sicurezza sin dalle prime fasi (shift-left) nelle pipeline, sulla protezione dei segreti a riposo (at rest) e in transito (in transit) e sull’applicazione di una solida governance dei rilasci. Una progettazione efficace elimina i segreti a lunga durata, utilizza il principio del privilegio minimo, convalida ogni chiamante e istituzionalizza il rilevamento e la correzione continui attraverso codice, dipendenze, infrastruttura e ambiente di esecuzione (runtime).

Protezione dell’Identità delle Applicazioni, dell’Ingresso e delle API

La protezione dell’identità delle applicazioni in Microsoft Entra ID (Azure AD) inizia con una registrazione dell’app con ambito ben definito e il corretto flusso OAuth 2.0:

Le autorizzazioni delegate si applicano quando un utente ha effettuato l’accesso e il consenso può essere limitato solo ad app di editori verificati o ad ambiti approvati dall’amministratore. Le autorizzazioni dell’applicazione (solo app) richiedono sempre il consenso dell’amministratore perché autorizzano demoni o servizi in background che agiscono senza un utente.
Applica il principio del privilegio minimo concedendo solo gli ambiti o i ruoli applicativi minimi necessari e richiedendo la revisione delle richieste di consenso da parte di un amministratore. Disabilita il consenso dell’utente finale o consentilo solo per editori verificati e a basso rischio per ridurre il phishing del consenso.
Preferisci le credenziali basate su certificati o le identità federate rispetto ai segreti client. I certificati offrono una garanzia maggiore e una rotazione prevedibile. Configura durate brevi e automatizza la rotazione. Blocca i flussi client pubblici a meno che non siano necessari.
Per i servizi Azure, utilizza le identità gestite invece dei segreti delle applicazioni. Assegna ruoli del piano dati come Key Vault Secrets User o Storage Blob Data Reader e limita l’accesso di rete utilizzando i Private Endpoint dove applicabile.

Application Gateway WAF v2 e Azure Front Door WAF proteggono l’ingresso pubblico dalle minacce della OWASP Top 10:

Abilita l’ultimo Core Rule Set OWASP gestito da Microsoft ed eseguilo in modalità Prevenzione (Prevention) dopo averlo ottimizzato. Inizialmente, utilizza il punteggio di anomalia (anomaly scoring) per ridurre i falsi positivi durante la fase di apprendimento.
Configura regole personalizzate per il geofencing, blocchi basati sulla reputazione degli IP, imposizione di header e limiti sulla dimensione delle richieste. Per Front Door, aggiungi regole di limitazione della frequenza (rate-limit) per IP client per mitigare il credential stuffing e attacchi DoS di base a livello 7 (L7).
Termina la connessione TLS con suite di cifratura e policy robuste; utilizza TLS end-to-end fino all’origine. Per scenari che richiedono mTLS, configura la convalida del certificato client sui listener di Application Gateway.
Associa le policy WAF ai listener/route in modo preciso; utilizza le esclusioni delle regole solo quando comprendi appieno il falso positivo. Invia i log del WAF a Log Analytics per l’ingegneria del rilevamento (detection engineering) e la risposta agli incidenti (incident response).

API Management (APIM) impone una postura di sicurezza multistrato:

Convalida i token OAuth a livello del gateway con controlli rigorosi su issuer, audience e scope. Richiedi HTTPS ovunque e imponi mTLS quando il perimetro di fiducia del client (client trust boundary) lo richiede.
Combina le chiavi di sottoscrizione con OAuth per una difesa in profondità e per il throttling basato sull’identità. Utilizza chiavi di sottoscrizione a livello di prodotto per partizionare i consumer e ruotare le chiavi senza interrompere il servizio per gli altri.
Applica la limitazione della frequenza (rate limiting) e le quote con granularità per consumer, per ambito o per sottoscrizione. Utilizza il filtraggio IP per inserire in una allowlist le reti dei partner quando appropriato.
Proteggi i servizi di backend utilizzando TLS reciproco (mutual TLS) o identità gestite. Archivia i segreti come Valori Nominativi (Named Values) supportati da riferimenti a Key Vault per evitare testo in chiaro nella configurazione.

Esempio di policy APIM per l’imposizione dello scope JWT e il throttling:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

Rafforzamento della Pipeline DevSecOps e Defender for DevOps

Azure DevOps e GitHub Actions devono autenticarsi in Azure senza segreti a lunga durata:

Utilizza la federazione delle identità dei carichi di lavoro (workload identity federation - OIDC) per le connessioni ai servizi. Crea una registrazione di app/principal di servizio in Entra ID, quindi aggiungi una credenziale federata che lega il repository, il branch e il workflow/ambiente all’identità. Questo produce token a breve durata senza segreti archiviati e supporta la definizione dell’ambito con privilegio minimo tramite Azure RBAC.
Blocca le autorizzazioni della pipeline: richiedi approvazioni per utilizzare le connessioni ai servizi, limita la pipeline ai branch protetti e disabilita l’opzione “Consenti agli script di accedere al token OAuth” a meno che non sia necessario. Utilizza gruppi di variabili e segreti con mascheramento; non consentire la visualizzazione dei segreti nei log tramite comandi di logging. In GitHub, preferisci i segreti a livello di ambiente e organizzazione rispetto a quelli a livello di repository per un controllo centralizzato e utilizza le impostazioni per “prevenire i segreti nei log” nei runner ospitati, dove applicabile.
Applica regole di protezione dell’ambiente: revisori obbligatori, controlli (es. ticket di change management, superamento dei test) e approvazioni basate sul tempo.

Crea una credenziale federata con la CLI di Azure (esempio OIDC per GitHub):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps si integra con Azure Repos e GitHub per evidenziare:

Risultati sulla sicurezza del codice (SAST) nei linguaggi comuni; le annotazioni nelle pull request evidenziano nuovi problemi per prevenire regressioni.
Rischio delle dipendenze (SCA) utilizzando l’intelligence sulle vulnerabilità per le librerie OSS con indicazioni per la correzione e versioni corrette.
Rilevamento dell’esposizione di segreti e rotazioni consigliate per token/chiavi trapelati.
Errori di configurazione dell’Infrastructure-as-Code in ARM/Bicep/Terraform (es. storage pubblico, NSG permissivi) con governance basata su policy e tracciamento delle deviazioni (drift). I risultati vengono aggregati in Defender for Cloud con il contesto del repository e della pipeline per la prioritizzazione. Blocca i rilasci (gate) in base a soglie di gravità per fermare le distribuzioni non sicure.

Gestione dei Segreti e Integrazione con la Piattaforma

Key Vault fornisce una gestione centralizzata di segreti, chiavi e certificati con controlli completi:

Applicare la protezione dall’eliminazione definitiva (purge protection) e l’eliminazione temporanea (soft delete) per prevenire la perdita irreversibile dei dati. Preferire il controllo degli accessi in base al ruolo (RBAC) rispetto alle policy di accesso per un’autorizzazione unificata; abilitare i Private Endpoints e disabilitare l’accesso dalla rete pubblica ove possibile; abilitare la registrazione (logging) su uno spazio di lavoro sicuro.
App Service e Functions utilizzano riferimenti a Key Vault nelle impostazioni dell’applicazione (app settings) con le identità gestite (managed identities); la rotazione dei segreti avviene in modo trasparente senza richiedere un nuovo deployment.
AKS recupera i segreti a runtime tramite il Secrets Store CSI Driver con il provider per Azure Key Vault, autenticato tramite Azure AD Workload Identity (consigliato). Evitare di inserire segreti in chiaro negli oggetti Secret di Kubernetes.

Esempio di riferimento a Key Vault per App Service:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

SecretProviderClass per AKS (abbreviato):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

Le pipeline dovrebbero recuperare i segreti al momento dell’esecuzione del job:

Azure DevOps: utilizzare il task di Key Vault con una service connection basata su identità gestita; limitare il download dei segreti al minor numero di stage possibile.
GitHub Actions: usare azure/login per l’autenticazione OIDC e azure/keyvault per estrarre solo i nomi dei segreti necessari.

SDLC sicuro, container, logging e rilasci

Le pratiche di SDLC sicuro riducono il rischio prima del deployment:

Il threat modeling (modellazione delle minacce) nelle fasi iniziali con STRIDE o un metodo equivalente assicura che l’autenticazione, l’autorizzazione e i flussi di dati siano validati esplicitamente. I modelli vanno aggiornati con l’evolversi dell’architettura.
L’analisi SAST viene eseguita su ogni PR; le build vengono interrotte in caso di problemi ad alta gravità con una chiara attribuzione della responsabilità. L’analisi DAST viene eseguita dopo il deploy in uno slot/ambiente di staging con dati di test sicuri.
L’analisi SCA monitora continuamente i pacchetti; impone versioni fisse e la conformità delle licenze.
Rigorosa revisione del codice con policy dei branch: revisori obbligatori, work item collegati, validazione della build e commit firmati.

La sicurezza delle immagini dei container è fondamentale per l’integrità della supply chain:

Generare e archiviare SBOM (SPDX o CycloneDX) durante le build, pubblicandoli insieme alle immagini come artefatti OCI per la tracciabilità.
Scansionare le immagini prima del push e at-rest nei registri utilizzando la scansione dei container di Defender for Cloud; bloccare la promozione in caso di risultati critici.
Firmare immagini e attestazioni usando Notary v2/artefatti OCI con cosign. Imporre la verifica della firma in fase di ammissione (ad es. con Gatekeeper/OPA o AKS Policy per Kubernetes).
Controlli del registro in Azure Container Registry (ACR): disabilitare l’utente amministratore, limitare l’accesso di rete tramite Private Endpoint, abilitare le chiavi gestite dal cliente, usare token con ambito a livello di repository per un accesso granulare e applicare pattern di conservazione e quarantena. Concedere solo il ruolo AcrPull ai runtime e AcrPush alla CI. Per AKS, collegare l’ACR con il comando supportato per creare l’assegnazione corretta anziché configurare manualmente il ruolo.
Se i container devono usare service endpoint di una VNet da un host VM, installare un plugin CNI supportato in modo che il traffico di ogni container provenga dalla subnet.

Il logging delle applicazioni non deve esporre segreti o PII:

Configurare Application Insights per redigere o eliminare campi sensibili con i Telemetry Processor; evitare di registrare header, token o payload grezzi che contengono segreti o PII. Limitare i campi di dati alle necessità di business e abilitare il campionamento per ridurre l’esposizione.
Indirizzare la diagnostica a un workspace di Log Analytics dedicato con un RBAC restrittivo (privilegio minimo di Log Analytics Reader) e storage immutabile quando si esporta su Storage (blocchi di conservazione basati sul tempo).
Proteggere gli endpoint di ingestione e di query della telemetria con Private Link, dove disponibile. Archiviare le stringhe di connessione della strumentazione in Key Vault e ruotarle regolarmente.

Le pratiche di rilascio sicuro impongono una promozione controllata:

I gate di approvazione in Azure DevOps Environments o GitHub Environments richiedono revisori designati, il superamento di controlli di qualità e ticket di modifica. Automatizzare le finestre di sospensione (hold-back window) per i deployment ad alto rischio.
Applicare il principio del privilegio minimo alle connessioni di servizio e agli agenti; definire l’ambito a livello di gruppi di risorse o sottoscrizioni per ogni ambiente. Usare identità gestite con ruoli dall’ambito ristretto.
Segregazione degli ambienti Dev, Test e Prod con sottoscrizioni, VNet, Key Vault e ACR separati; non consentire il movimento laterale tra ambienti e usare segreti/chiavi diversi in ciascun ambiente.

Scenario di un problema pratico

Fabrikam, Inc. sta pubblicando su Internet un’API SaaS multi-tenant. I requisiti sono: bloccare gli attacchi della Top 10 di OWASP, validare gli scope OAuth per ogni operazione, impedire la presenza di segreti nei repository, limitare (throttling) i client abusivi e garantire che in produzione vengano eseguite solo immagini di container firmate.

Fronting e WAF

Eseguire il deploy di Azure Front Door Standard con una policy WAF che utilizzi il più recente set di regole gestite OWASP in modalità Prevenzione, più regole personalizzate di rate-limit e blocco geografico. Motivazione: l’applicazione centralizzata a livello di edge globale riduce la superficie di attacco e assorbe gli attacchi L7 prima che raggiungano l’origine.

Policy del gateway API

Posizionare Azure API Management dietro Front Door; implementare la policy

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

con controlli su issuer/audience/scope per ogni operazione e chiavi di sottoscrizione a livello di prodotto con quote. Motivazione: APIM fornisce un’applicazione basata sull’identità e l’isolamento dei tenant; le chiavi più OAuth offrono una difesa a più livelli e un throttling preciso.

Identità e consenso

Registrare le app SPA e daemon in Entra ID con scope delegati per i flussi utente e ruoli applicazione per il daemon; limitare il consenso dell’utente ai publisher verificati e richiedere il consenso dell’amministratore per le autorizzazioni delle app. Usare credenziali basate su certificato per il daemon. Motivazione: elimina i segreti deboli, applica il principio del privilegio minimo e riduce l’esposizione al phishing del consenso.

DevSecOps con OIDC

Configurare GitHub Actions per usare la federazione OIDC verso un service principal di Azure con ambito limitato a una sottoscrizione non di produzione per la build e a un principal con ambito di produzione per il rilascio, ciascuno con ruoli minimi (AcrPush per la build, Contributor limitato a un RG di produzione per il rilascio). Motivazione: nessun segreto archiviato; il blast radius è minimizzato per ogni ambiente.

Supply chain dei container

Creare le immagini tramite ACR Tasks, generare SBOM (CycloneDX) e firmare le immagini con cosign; archiviare le attestazioni come artefatti OCI. Configurare l’ammissione in AKS con una policy che richieda firme valide. Motivazione: la provenienza e l’integrità sono verificabili al momento del deploy, bloccando le immagini manomesse.

Controlli del registro e del runtime

Disabilitare l’utente amministratore di ACR, abilitare il Private Endpoint, assegnare il ruolo AcrPull all’identità kubelet di AKS tramite il flusso supportato

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

e abilitare la scansione delle immagini di Defender for Cloud. Motivazione: l’hardening della rete e dell’identità rimuove le backdoor predefinite; la scansione rileva i CVE noti prima del runtime.

Segreti e configurazione

Usare Key Vault con Private Endpoint e RBAC; App Service e Functions consumano i riferimenti a Key Vault, mentre AKS usa il driver CSI Secret Store con Workload Identity. Motivazione: i segreti non risiedono mai nei repository o nelle configurazioni delle app; la rotazione è centralizzata e verificabile.

Governance dei rilasci

Proteggere il branch

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

di GitHub con revisioni e controlli obbligatori; richiedere approvazioni dell’ambiente e il superamento dei gate di sicurezza (nessun risultato critico da SAST/SCA/IaC) prima del deploy in produzione. Motivazione: assicura che solo le build validate e sicure avanzino; la supervisione umana rimane per le modifiche ad alto rischio.

Igiene dell’osservabilità

Configurare Application Insights per redigere i PII con Telemetry Processor personalizzati e indirizzare la diagnostica di WAF/APIM a un workspace di Log Analytics protetto con accesso di tipo Reader con privilegi minimi. Motivazione: preserva il valore forense senza esporre dati sensibili; l’accesso è verificabile e limitato.

← Microsoft Sentinel e operazioni di sicurezza · Tutti i domini · Sicurezza ibrida e multi-cloud →

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