Microsoft AZ-400: Sicurezza, conformità e DevSecOps — Guida allo studio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fa parte della Microsoft DevOps Engineer Expert AZ-400 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La sicurezza, la conformità e il DevSecOps nelle pipeline di delivery incentrate su Azure richiedono di anticipare il rilevamento dei rischi alle primissime fasi (shift-left), di applicare le policy in modo continuo e di automatizzare la raccolta delle evidenze. Le implementazioni efficaci unificano i test di sicurezza delle applicazioni (SAST/DAST/SCA), la governance dei segreti, la scansione dell’infrastructure-as-code (IaC) e i controlli normativi all’interno del ciclo di vita CI/CD. In Azure DevOps e GitHub, questo significa eseguire analizzatori su ogni pull request, controllare i merge con soglie di qualità, effettuare il deploy con identità a privilegi minimi che recuperano segreti a tempo da Azure Key Vault e monitorare continuamente la postura di sicurezza con Microsoft Defender for DevOps e Defender for Cloud. L’obiettivo non è solo trovare problemi, ma impedire che modifiche non sicure raggiungano le risorse protette, dimostrare la conformità attraverso tracce di audit e sostenere una velocity sicura.

Sicurezza shift-left, mitigazioni OWASP Top 10 e hardening delle pipeline

La sicurezza shift-left inizia con SAST e SCA al momento della PR, aumentati dalla scansione dei segreti e da DAST mirati prima della promozione in ambienti successivi. Il SAST fa emergere vulnerabilità a livello di codice come punti di injection, deserializzatori non sicuri e codifica di output mancante. Integrare SonarQube/SonarCloud o la scansione del codice di GitHub (es. CodeQL) per analizzare ogni set di modifiche; arricchire le pull request con i problemi legati a righe di codice specifiche; e imporre quality gate che facciano fallire la build quando le soglie di vulnerabilità o di copertura non vengono rispettate. Concentrare il SAST sulle classi OWASP Top 10:

• Injection: imporre l’uso di query parametrizzate/ORM, validare/normalizzare l’input e vietare SQL dinamico/concatenazione di stringhe. Applicare queste regole tramite ruleset SAST e unit test che verifichino l’uso di helper per l’accesso ai dati approvati.
• Cross-Site Scripting (XSS): richiedere la codifica dell’output e una Content Security Policy. La taint analysis del SAST dovrebbe tracciare l’input non attendibile fino ai sink (innerHTML, Response.Write).
• Cross-Site Request Forgery (CSRF): imporre l’uso di token anti-forgery e cookie SameSite. Le pipeline possono eseguire analizzatori del framework per assicurare che i middleware/le impostazioni siano abilitati.
• Deserializzazione Insicura: non consentire serializzatori binari/XML non sicuri, limitare i tipi permessi e preferire serializzatori JSON configurati con default sicuri. I controlli SAST e le policy sulle dipendenze impediscono l’uso di librerie note per essere insicure.

Il DAST valida le build in esecuzione in un ambiente di staging. Automatizzare OWASP ZAP o un equivalente come un job della pipeline post-deploy in un ambiente non di produzione, usando scansioni autenticate e un ruleset ottimizzato per il profilo della propria applicazione. Controllare la promozione in base a una baseline di vulnerabilità: bloccare in caso di nuovi risultati di livello High/Critical e rendere persistenti le eccezioni accettate con una data di scadenza.

La Software Composition Analysis (SCA) rileva pacchetti di terze parti vulnerabili prima del merge. Usare Dependabot per creare PR di aggiornamento versione e OWASP Dependency-Check per produrre SBOM e report CVE nella CI. Garantire la conformità delle licenze definendo liste di permessi/divieti (es. negare licenze copyleft per prodotti proprietari) e facendo fallire le build che includono licenze non consentite. La scansione dei segreti deve essere eseguita al commit e nella CI: adottare la scansione dei segreti di GitHub Advanced Security o integrare Gitleaks/Microsoft Security DevOps per intercettare credenziali, token e chiavi hardcoded; bloccare il merge quando viene rilevato il pattern di un segreto e procedere alla rotazione delle credenziali interessate.

L’hardening della pipeline non è negoziabile. Bloccare le protezioni dei branch, richiedere revisioni delle PR e imporre status check per SAST/SCA/DAST. In Azure Pipelines, usare risorse protette, approvazioni e controlli sugli ambienti e template obbligatori per standardizzare le fasi di sicurezza. Preferire token a vita breve e con privilegi minimi; evitare completamente le credenziali statiche grazie alla federazione delle identità di workload. Limitare gli agenti self-hosted a reti private, definire lo scope minimo per le loro identità e disabilitare l’injection di script imponendo template che non consentano passaggi di script arbitrari per repository non attendibili.

Segreti, identità, Azure Key Vault e rotazione dei certificati

Azure Key Vault è l’archivio autorevole per segreti, chiavi e certificati. Integrarlo direttamente con la CI/CD per eliminare i segreti in chiaro:

• Segreti della pipeline: in Azure DevOps, collegare un gruppo di variabili a un Key Vault usando una service connection il cui scope è limitato solo ai nomi dei segreti necessari. I segreti vengono recuperati a runtime e mascherati nei log. In GitHub Actions, usare azure/login con un’identità federata per ottenere token e chiamare Key Vault; evitare di archiviare i segreti client nelle impostazioni del repository.
• Accesso con identità gestita: quando possibile, consentire ai workload e agli agenti di deploy di autenticarsi con Microsoft Entra ID usando un’identità gestita o la federazione delle identità di workload, in modo che non vengano archiviati segreti. Limitare l’accesso a Key Vault usando RBAC o policy di accesso secondo il principio del privilegio minimo (solo get/list per versioni specifiche dei segreti; nessun permesso di purge/delete).
• Rotazione dei certificati: archiviare i certificati TLS/MTLS in Key Vault Certificates con rotazione automatica tramite CA integrate. Configurare i servizi che li utilizzano (App Service, Application Gateway, AKS Ingress tramite CSI Secrets Store) per fare riferimento a Key Vault, in modo che i certificati rinnovati vengano recepiti senza un nuovo deploy. Usare Event Grid sugli eventi certificateNearExpiry di Key Vault per attivare un runbook di automazione o una Function che convalidi i binding e riscaldi le cache. Tracciare l’uso della versione del certificato nei manifest di deployment; effettuare il pinning delle versioni quando necessario e avanzare deliberatamente di versione durante le finestre di manutenzione.

Eseguire l’hardening di Key Vault con endpoint privati, regole firewall, protezione dall’eliminazione definitiva (purge protection), soft-delete e logging su Log Analytics o storage per l’audit. Negare l’accesso cross-tenant a meno che non sia esplicitamente giustificato e ruotare regolarmente l’accesso per gli account di break-glass (emergenza).

Dipendenze, container, IaC e compliance as code

La scansione delle dipendenze deve gestire sia i difetti di sicurezza che le licenze. Dependabot propone continuamente aggiornamenti sicuri; utilizzare policy di revisione delle dipendenze per bloccare le PR che introducono versioni vulnerabili. OWASP Dependency-Check (o strumenti nativi dell’ecosistema come npm audit, pip-audit) dovrebbe essere eseguito nella CI per generare SBOM (CycloneDX/SPDX) e far fallire la build quando vengono violate le soglie di severità o le regole di licenza. Per una governance avanzata delle licenze, abbinarlo a una piattaforma SCA in grado di applicare policy legali e flussi di lavoro di remediation.

La sicurezza delle immagini dei container inizia nella CI e prosegue nel registry e in fase di runtime:

• Trivy: eseguirlo come step della pipeline per scansionare Dockerfile e immagini compilate alla ricerca di CVE e configurazioni errate a livello di sistema operativo/pacchetti; interrompere la build in caso di risultati di livello Critico/Alto. Imporre l’uso di immagini di base minimali e container rootless.
• Scansione delle vulnerabilità di Azure Container Registry: abilitare Microsoft Defender for Containers per scansionare le immagini al momento del push/import e secondo una pianificazione. Mostrare i risultati in Defender for Cloud, esportarli in work item e applicare gate di deployment che bloccano le immagini con problemi irrisolti di livello Critico/Alto.
• Defender for Containers: estendere la protezione ad AKS/ECS/Kubernetes con rilevamento delle minacce in fase di runtime, controlli in stile kube-bench e admission control. Usare le policy per effettuare il pull solo da ACR attendibili firmati con Notation/ACR content trust e verificare le firme nella CI e all’ammissione nel cluster.

La sicurezza dell’IaC garantisce che le risorse cloud siano approvvigionate in modo sicuro per impostazione predefinita:

• Checkov e tfsec: scansionare i manifest di Terraform e Kubernetes alla ricerca di configurazioni non sicure (storage pubblico, security group aperti, crittografia mancante). Far fallire le build al superamento delle soglie di severità; definire una baseline del debito esistente per concentrarsi sulle risorse nuove/modificate.
• Linting di ARM/Bicep: abilitare il linter di Bicep (bicepconfig.json) e l’ARM Template Tool Kit (arm-ttk) per applicare regole per il tagging, endpoint solo HTTPS, chiavi gestite dal cliente e impostazioni di diagnostica. Combinare con i deployment what-if per rilevare il drift prima dell’applicazione.

La Compliance as Code utilizza Azure Policy e Defender for Cloud per applicare e creare report sui controlli in modo continuo:

• Assegnare iniziative di Azure Policy allineate a CIS, NIST, ISO 27001 o a baseline interne; selezionare effetti come Deny per i guardrail critici (ad es. IP pubblici sui database), DeployIfNotExists per la diagnostica e Audit per l’osservabilità. Archiviare le definizioni delle policy come artefatti versionati, testarle con pipeline di policy-as-code e promuoverle tramite pull request.
• Utilizzare le dashboard di conformità normativa di Defender for Cloud per visualizzare la conformità dei controlli tra sottoscrizioni e gruppi di gestione. Integrare con Azure Monitor ed esportare le evidenze su Log Analytics o Event Hubs per l’ingestione nel SIEM.
• Mantenere le tracce di audit: Azure Activity Logs per eventi e assegnazioni di policy, Resource Graph per query di conformità, log di audit di Azure DevOps/GitHub per le modifiche a repo e pipeline, e prove di rilascio catturate automaticamente come artefatti dell’esecuzione della pipeline.

SonarQube/SonarCloud, sicurezza delle pipeline e Microsoft Defender for DevOps

SonarQube/SonarCloud fornisce quality gate applicabili che allineano la qualità ingegneristica con la sicurezza. Adotta il principio “Clean as You Code” impostando gate sul nuovo codice: copertura minima del codice sulle righe nuove/modificate (es. 80%+), zero nuove vulnerabilità critiche o code smell bloccanti e bassa duplicazione. Il fallimento del gate deve causare il fallimento della pipeline. Pubblica la copertura dai framework di test (JaCoCo, Cobertura, VSTest) e ottimizza i profili di qualità per ogni linguaggio per includere hotspot di sicurezza e regole allineate a OWASP. Traccia gli indici di debito tecnico e i tempi di remediation; reportizza i trend per promuovere la responsabilità del team.

La sicurezza delle pipeline si basa su connessioni di servizio con privilegio minimo, risorse protette e un mascheramento completo dei secret:

• Le connessioni di servizio dovrebbero usare la federazione delle identità dei carichi di lavoro o identità gestite con ambiti ristretti (sottoscrizione/gruppo di risorse, un ACR specifico o un Key Vault). Abilita approvazioni e controlli sulle connessioni di servizio e sugli ambienti in modo che i proprietari debbano autorizzarne l’uso. Limita i permessi di “Uso” alle pipeline fidate; disabilita “Concedi il permesso di accesso a tutte le pipeline”.
• Le risorse protette in Azure DevOps proteggono connessioni di servizio, gruppi di variabili, file sicuri e ambienti. Richiedi controlli come approvatori, finestre di orario lavorativo, risultati di query di Azure Monitor e motori di policy REST esterni. Trattali come gate prima delle distribuzioni e come precondizioni per letture sensibili (es. recupero di secret di produzione).
• Il mascheramento dei secret deve essere applicato su tutti i log; limita l’espansione delle variabili negli script; evita di visualizzare i secret in output; e preferisci le API con scope system.accessToken piuttosto che archiviare PAT. Scansiona periodicamente i log della pipeline alla ricerca di fughe accidentali di secret e procedi alla loro rotazione se rilevati.

Microsoft Defender for DevOps unifica la postura di sicurezza dei repository e delle pipeline su GitHub e Azure DevOps. Connetti organizzazioni/progetti a Defender for Cloud per ingerire segnali di rischio da codice, secret, IaC e dipendenze e presentare raccomandazioni consolidate. Correla i risultati ai rispettivi proprietari, supporta flussi di lavoro per la soppressione con scadenza e misura l’adozione delle protezioni dei branch, dei revisori richiesti e dei controlli di stato. Abbina Defender for DevOps con il task/action Microsoft Security DevOps per orchestrare più analizzatori (es. Semgrep, Trivy, tfsec, Gitleaks, Bandit) in un unico passaggio e pubblicare i risultati in formato SARIF nella scansione del codice. Usa Defender for Cloud per creare iniziative di governance che tracciano e applicano le best practice DevOps (es. scansione dei secret abilitata, numero di revisori richiesti ≥ 2, merge da non amministratori disabilitati), elevando l’igiene del repository a un controllo verificabile.

Scenario Pratico del Problema

Spotify deve standardizzare la delivery sicura per un nuovo stack di microservizi ospitato su AKS che comprende .NET e Node.js, con repository in GitHub Enterprise Cloud e distribuzioni tramite pipeline YAML multi-stage di Azure DevOps. La sfida consiste nel bloccare le dipendenze vulnerabili e l’infrastruttura mal configurata prima del merge, eliminare le credenziali statiche e impedire la promozione di immagini con CVE critiche, producendo al contempo prove di conformità verificabili.

1. Applicare la scansione SAST/SCA e dei secret al momento della PR

• Scegliere SonarCloud per il SAST multi-linguaggio con decorazione delle PR e quality gate; impostare una copertura del nuovo codice ≥ 80% e zero nuove vulnerabilità critiche. Abilitare Dependabot per PR automatiche di aggiornamenti sicuri e la revisione delle dipendenze di GitHub per bloccare le PR che introducono CVE note. La scansione dei secret di GitHub Advanced Security, unita a Gitleaks nella CI, assicura una difesa in profondità contro l’esposizione di credenziali.

2. Aggiungere DAST autenticato prima della promozione

• Utilizzare OWASP ZAP in uno stage della pipeline che punta all’ambiente di staging con account di test pre-configurati. Un controllo di rilascio blocca la produzione se emergono nuove problematiche di livello Alto/Critico. ZAP viene scelto per la sua copertura allineata a OWASP e la facile automazione in CI.

3. Mettere in sicurezza identità e secret con Key Vault e la federazione delle identità dei carichi di lavoro

• Sostituire i client secret delle service principal con la federazione delle identità dei carichi di lavoro di Microsoft Entra per le connessioni di servizio, eliminando i secret archiviati. Le pipeline recuperano i secret di runtime e le credenziali del DB da Azure Key Vault tramite permessi di get/list con privilegio minimo. Questo elimina le credenziali a lunga durata e centralizza la loro rotazione.

4. Implementare l’automazione dei certificati

• Archiviare i certificati di ingress e mTLS in Key Vault con rotazione automatica. AKS preleva i certificati tramite il driver CSI Secrets Store per evitare di copiare i secret in Kubernetes. Event Grid attiva una Function per verificare i binding dopo il rinnovo. Questo design minimizza i tempi di inattività e l’errore umano durante la rotazione.

5. Eseguire l’hardening di container e registri

• Eseguire Trivy nella CI per scansionare Dockerfile e immagini buildate; fallire in caso di vulnerabilità Critiche/Alte. Eseguire il push solo di immagini pulite su ACR. Abilitare Defender for Containers per scansionare ACR al push e periodicamente, mostrando i risultati in Defender for Cloud. Controlli di rilascio basati su policy bloccano la distribuzione di immagini con CVE Critiche/Alte non risolte. Trivy fornisce un feedback rapido; Defender aggiunge una garanzia continua e nativa del registro.

6. Scansionare IaC ed eseguire il linting di Bicep/ARM

• Utilizzare Checkov e tfsec per scansionare i chart di Terraform e Helm; imporre tagging, crittografia e controlli di rete. Il linter di Bicep e l’ARM TTK vengono eseguiti nella CI per i template nativi di Azure. I controlli falliti bloccano i merge; le baseline limitano il rumore alle risorse nuove/modificate. Questi strumenti sono scelti per l’ampia copertura di regole e il forte supporto per Azure.

7. Codificare la conformità e le prove

• Assegnare iniziative di Azure Policy per le baseline CIS Azure e aziendali; applicare l’effetto Deny sulle misure di protezione critiche e DeployIfNotExists per la diagnostica. Inviare i risultati alle dashboard normative di Defender for Cloud. Esportare i Log di Attività e le raccomandazioni di Defender su Log Analytics per ottenere prove immutabili. Le policy forniscono un’applicazione continua; le dashboard offrono viste pronte per l’audit.

8. Mettere in sicurezza pipeline e risorse protette

• Limitare le connessioni di servizio a sottoscrizioni/gruppi di risorse specifici; richiedere approvazioni per l’ambiente e controlli basati su query di Azure Monitor per la produzione. Proteggere i gruppi di variabili e i file sicuri; mascherare tutti i secret. Eseguire l’hardening degli agenti self-hosted con networking privato. Queste funzionalità riducono il blast radius e assicurano un intervento human-in-the-loop per le azioni ad alto rischio.

9. Consolidare la postura di sicurezza con Microsoft Defender for DevOps

• Connettere l’organizzazione GitHub e il progetto Azure DevOps a Defender for Cloud per aggregare i risultati delle scansioni di codice, secret e IaC e per tracciare l’adozione delle protezioni dei repository. Utilizzare l’action/task Microsoft Security DevOps per orchestrare Semgrep, Trivy, tfsec e Gitleaks con pubblicazione in formato SARIF, garantendo una scansione standardizzata tra i servizi. Questo centralizza la gestione del rischio e i flussi di lavoro di remediation.

Ogni strumento/funzionalità è selezionato per il rilevamento più precoce possibile, l’applicazione automatica e la verificabilità: SonarCloud e ZAP fungono da gate per i rischi del codice e di runtime; Dependabot e Trivy accelerano gli aggiornamenti sicuri; Key Vault e la federazione delle identità eliminano i secret statici; Checkov/tfsec e Azure Policy prevengono il drift; le risorse protette e le approvazioni controllano il blast radius; Defender for DevOps e Defender for Cloud offrono una gestione unificata e operativa della postura di sicurezza.

← Gestione dei rilasci e strategie di distribuzione · Tutti i domini · Strategia di test e ingegneria della qualità →

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

Sfoglia Microsoft →