Microsoft AZ-500: Sicurezza di compute, container ed endpoint — 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

Questa sezione fornisce un riferimento operativo per la messa in sicurezza di compute, container ed endpoint di Azure in ambienti IaaS e PaaS. Si concentra su come configurare le protezioni, sulla loro importanza e su come applicarle in modo coerente con i controlli nativi di Azure.

Sicurezza di Compute ed Endpoint

Le protezioni della piattaforma e le opzioni di crittografia per le VM di Azure sono fondamentali.

• Secure Boot, vTPM e Trusted Launch: Trusted Launch rafforza la sicurezza delle VM di seconda generazione (Gen2) abilitando UEFI Secure Boot e un TPM virtuale (vTPM). Secure Boot impedisce l’esecuzione di bootloader/rootkit non firmati. Il vTPM fornisce uno store a prova di manomissione per le chiavi (ad esempio, per BitLocker) e supporta il “measured boot” (avvio misurato), in modo che la piattaforma possa attestare la catena di avvio del sistema operativo. A livello operativo, abilitare Trusted Launch al momento del deployment e imporlo tramite policy per garantire che tutte le nuove VM ottengano controlli di integrità basati su hardware, senza che gli amministratori debbano gestire impostazioni statiche di BIOS/UEFI.

• VM confidenziali: Utilizzare le serie di VM confidenziali basate su AMD SEV-SNP o Intel TDX (ad esempio, DCasv5/DCadsv5) per crittografare la memoria della VM e fornire l’attestazione. Questo protegge i workload da un host/hypervisor malevolo e da attacchi side-channel. A livello operativo, selezionare SKU confidenziali per scenari con dati in uso altamente sensibili, integrare l’attestazione nella pipeline di deployment e preferire dischi del sistema operativo effimeri quando sono necessari redeployment rapidi senza persistenza dei dati.

• Opzioni di crittografia del disco:

  • Azure Disk Encryption (ADE): BitLocker (Windows) o DM-Crypt (Linux) all’interno del sistema operativo guest, con chiavi in Key Vault (BEK/KEK). Utile quando si necessita di domini di crittografia basati sul guest, controlli di conformità all’interno del sistema operativo o di sfruttare BitLocker associato al vTPM. Richiede un agente e operazioni sul ciclo di vita per la salute dell’estensione.
  • Server-Side Encryption (SSE) con Customer-Managed Keys (CMK): Crittografia a livello di storage per i dischi gestiti utilizzando chiavi in Key Vault o Managed HSM. Nessun agente nel guest, copertura completa della piattaforma (dischi, snapshot, immagini), overhead operativo minimo. Opzione predefinita consigliata per la maggior parte dei casi d’uso; abbinare a Trusted Launch o VM confidenziali per una “defense-in-depth” (difesa in profondità) più robusta.

• Microsoft Defender for Servers:

  • Piano 1: Microsoft Defender for Endpoint (MDE) per la protezione EDR/endpoint sui server. Scegliere questa opzione se si dispone già di strumenti maturi per la gestione delle vulnerabilità e della configurazione e si necessita principalmente di EDR.
  • Piano 2: Aggiunge la valutazione delle vulnerabilità con o senza agente, l’accesso Just-In-Time (JIT) alle VM, i controlli adattivi delle applicazioni, l’irrobustimento adattivo della rete e il monitoraggio dell’integrità dei file (FIM). Scegliere quando si desidera una riduzione dell’esposizione guidata dalla piattaforma e una governance attiva senza dover integrare più strumenti.
  • Protezione degli endpoint: Distribuire MDE tramite estensioni VM o Arc per i server non-Azure per standardizzare la telemetria, la protezione dalle manomissioni e i playbook di risposta in ambienti ibridi.
  • Valutazione delle vulnerabilità: Utilizzare il segnale di Threat & Vulnerability Management di MDE o lo scanner integrato (es. Qualys) per inventariare le CVE, dare priorità in base alla sfruttabilità e orchestrare l’applicazione delle patch. A livello operativo, eseguire prima il baselining dei server critici esposti su Internet; collegare la remediation alle finestre di manutenzione (change windows).
  • Monitoraggio dell’integrità dei file: Tracciare le modifiche a file sensibili/chiavi di registro per rilevare manomissioni sospette e soddisfare i requisiti di conformità. Configurare percorsi di monitoraggio con ambito limitato (“scoped watch paths”) per evitare rumore e inoltrare gli avvisi al proprio SIEM.

• Riduzione dell’esposizione con Defender for Cloud:

  • Accesso Just-In-Time alle VM: Chiude le connessioni RDP/SSH in entrata. Gli amministratori richiedono un accesso limitato nel tempo; Defender apre la regola NSG o Azure Firewall e registra l’attività. Il risultato è una superficie di attacco drasticamente ridotta con eccezioni verificabili.
  • Controlli adattivi delle applicazioni: Apprende i processi normali e crea delle allowlist (AppLocker su Windows, regole di audit per Linux). Questo blocca binari e script non approvati, risultando particolarmente efficace contro attacchi “fileless” o LOLBin.
  • Irrobustimento adattivo della rete: Utilizza l’analisi del traffico e la threat intelligence per proporre un irrigidimento delle regole NSG. Adottare una cadenza di revisione e applicazione per limitare in modo iterativo l’esposizione, evitando al contempo interruzioni del servizio.
  • Configurazione del guest: Azure Policy per l’audit/remediation all’interno del guest (Windows e Linux) tramite un agente o Azure Arc. Utilizzarlo per imporre baseline del sistema operativo, policy delle password e impostazioni allineate a CIS quando si necessita di uno stato di configurazione dimostrabile, non solo della postura della piattaforma.

Calcolo PaaS: App Service e Functions

I pattern sicuri per impostazione predefinita riducono la superficie di attacco del PaaS.

• Azure App Service:

  • Autenticazione/Autorizzazione: Abilita l’autenticazione di App Service per delegare l’autenticazione a Microsoft Entra ID o altri provider. Usa Easy Auth per i flussi OIDC/OAuth2 standard, quindi imponi il login su tutte le route per eliminare l’esposizione non autenticata.
  • Restrizioni di accesso: Consenti o nega il traffico per IP/CIDR, tag di servizio o traffico di rete virtuale tramite endpoint privati. Mantieni regole separate per l’endpoint scm e l’endpoint dell’app per proteggere il tuo piano di distribuzione in modo indipendente.
  • Endpoint privati: Esponi l’app tramite un IP privato nella tua VNet e, facoltativamente, disabilita l’accesso pubblico. Utilizza zone DNS private e limita le dipendenze in uscita con l’integrazione VNet e un firewall di egress centralizzato.
  • Identità gestite: Preferisci le identità assegnate dal sistema o dall’utente per accedere a Key Vault, Storage e altri servizi. Ciò elimina i segreti incorporati e consente l’assegnazione centralizzata dei ruoli e la rotazione delle chiavi.

• Azure Functions:

  • Gestione delle chiavi: Le Functions utilizzano chiavi di funzione, chiavi host e la chiave master. Ruota regolarmente le chiavi e archivia le chiavi utilizzate esternamente in Key Vault, o sostituisci le chiavi con flussi OAuth appropriati, se possibile.
  • Integrazione di rete: Utilizza endpoint privati per l’accesso in entrata all’app Function e l’integrazione VNet regionale per i controlli in uscita. Limita l’account di archiviazione utilizzato dalle Functions solo a reti selezionate e aggiungi l’endpoint privato della Function alle reti consentite.
  • Identità: Usa identità gestite per l’autenticazione da servizio a servizio invece di chiavi o stringhe di connessione. Applica il principio del privilegio minimo con assegnazioni RBAC a ambito ristretto.
  • Controlli di distribuzione: Imponi l’uso esclusivo di FTPS, disabilita l’autenticazione di base per il sito scm, limita gli IP di scm e utilizza Run From Package per garantire distribuzioni immutabili. Integra la CI/CD con la federazione delle identità del carico di lavoro per eliminare i segreti a lunga durata.

Sicurezza di Kubernetes e dei container

Rafforza i cluster e le catene di approvvigionamento end-to-end.

• Identità e autorizzazione in AKS:

  • Integrazione con Microsoft Entra: Abilita AAD gestito per AKS per autenticare kubectl utilizzando token e gruppi di Entra. Ciò centralizza il ciclo di vita degli utenti e l’MFA/Accesso Condizionale.
  • RBAC di Kubernetes: Mappa utenti/gruppi di Entra a ruoli e associazioni di ruolo di Kubernetes per il privilegio minimo con ambito a livello di namespace.
  • RBAC di Azure per Kubernetes: Usa i ruoli predefiniti (ad es. Azure Kubernetes Service RBAC Viewer/Admin) quando desideri che Azure RBAC autorizzi direttamente le azioni dell’API di Kubernetes. Ciò unifica l’autorizzazione e l’audit con il piano di controllo di Azure.

• Rete e privacy in AKS:

  • Policy di rete: Applica policy al traffico da pod a pod e da pod a servizio con Azure NPM o Calico. Nega per impostazione predefinita e consenti esplicitamente l’egress richiesto; la policy-as-code previene i movimenti laterali.
  • Cluster privati: Rendi privato il server API, accessibile solo tramite endpoint privati. Abbinalo ad Azure Bastion/Private Link e a una strategia di egress con firewall (NAT Gateway + UDR) per mantenere il piano di gestione fuori da Internet.

• Sicurezza di Container Registry (ACR):

  • RBAC: Assegna AcrPull ai carichi di lavoro che devono solo scaricare immagini e AcrPush alle pipeline di compilazione; evita il ruolo Owner, eccessivamente privilegiato. AcrPull e AcrPush sono in linea con il principio del privilegio minimo.
  • Content trust e firma: Firma le immagini con cosign e imponi la verifica con un controller di ammissione (Gatekeeper + Ratify) prima che i pod vengano avviati. Questo protegge dalle immagini manomesse.
  • Scansione delle immagini: Abilita Microsoft Defender for Cloud per scansionare ACR al momento del push/import e secondo una pianificazione. Blocca la distribuzione di immagini con CVE critiche non corrette utilizzando le policy di ammissione.
  • Pattern di quarantena: Indirizza le nuove immagini a un repository o tag di quarantena, esegui la scansione e i controlli delle policy, quindi promuovile riassegnando il tag dopo l’approvazione.
  • Accesso privato: Disabilita l’accesso alla rete pubblica e utilizza endpoint privati e regole firewall del registro. Collega AKS ad ACR utilizzando un’assegnazione di ruolo a livello di risorsa anziché un ruolo di directory.

Breve esempio per collegare ACR ad AKS utilizzando l’identità gestita del cluster:

az aks update -g rg-aks -n myAKS --attach-acr myAcrName

• Microsoft Defender for Containers: Distribuisce un sensore del piano dati su AKS, monitora i log di audit di Kubernetes e i segnali di runtime e li correla con i risultati della scansione delle immagini. Rileva comandi exec sospetti nei pod, crypto-mining, dashboard esposte e operazioni rischiose sul piano di controllo. Abilita il provisioning automatico e collega gli avvisi al tuo SIEM/SOAR per il triage.

Governance, policy e applicazione

Un controllo coerente richiede policy sia in fase di deploy che a runtime.

• Azure Policy per compute e dischi:
  • Negare la creazione di VM senza trusted launch o senza SSE con CMK.
  • Imporre l’uso di estensioni VM per la protezione degli endpoint utilizzando DeployIfNotExists per installare automaticamente gli agenti richiesti.
  • Verificare la conformità della configurazione guest; correggere le deviazioni (drift) secondo una pianificazione.

Breve frammento di policy per distribuire un’estensione VM richiesta se mancante:

"policyRule": {
  "if": { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "MDE.Windows"
    }
  }
}

• Controlli di ammissione di Kubernetes:
  • L’add-on Azure Policy per AKS utilizza Gatekeeper (OPA) per valutare le specifiche dei pod in fase di ammissione. Applicare regole come “eseguire il pull solo da ACR”, “nessun container privilegiato” e “richiedere firme per le immagini”.
  • Mantenere iniziative separate per la baseline (indispensabili) e per la protezione rafforzata (namespace sensibili) per consentire un hardening progressivo.

Breve vincolo di Gatekeeper per limitare i registry:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-acr-only
spec:
  parameters:
    repos:
    - myacr.azurecr.io/

• Cadenza operativa:
  • Rilevare: Utilizzare le raccomandazioni di Defender for Cloud e gli avvisi dei workload come segnali di deviazione (drift) e minaccia.
  • Decidere: Effettuare il triage in base all’impatto sul business e alla sfruttabilità; assegnare i proprietari tramite tag.
  • Applicare: Convertire i progetti pilota di successo in policy di negazione/vincoli di ammissione; misurare i tentativi bloccati per rilevare lo shadow IT.

Scenario di un problema pratico

Adobe Inc. sta migrando un microservizio di pagamenti su Azure. I requisiti di sicurezza impongono zero esposizione pubblica, solo immagini firmate e accesso amministrativo a tempo limitato alle VM legacy durante la transizione (cutover).

1. Rendere privato il control plane di AKS e bloccare il traffico in uscita (egress).

• Motivazione: Un server API di AKS privato rimuove il piano di gestione da Internet. Un NAT Gateway abbinato a un Azure Firewall con regole di uscita esplicite garantisce che i workload raggiungano solo endpoint approvati (ACR, Key Vault, repository di pacchetti Microsoft).

2. Imporre l’uso di immagini firmate e limitare i registry.

• Motivazione: Configurare Gatekeeper con vincoli che consentano solo immagini provenienti da myacr.azurecr.io e richiedano firme cosign convalidate da Ratify. Ciò impedisce l’esecuzione di immagini manomesse o non attendibili, chiudendo un importante rischio nella supply chain.

3. Mettere in sicurezza ACR con endpoint privati e ruoli con privilegi minimi (least-privilege).

• Motivazione: Disabilitare l’accesso dalla rete pubblica ed esporre ACR tramite un endpoint privato nella VNet di AKS. Concedere all’identità gestita di AKS solo il ruolo AcrPull; concedere alla pipeline di build il ruolo AcrPush. Questo segue il principio dei privilegi minimi ed elimina la dipendenza da Internet.

4. Abilitare Defender for Containers e la scansione delle immagini di ACR.

• Motivazione: La scansione continua delle immagini al momento del push e il rilevamento delle minacce a runtime forniscono una copertura a più livelli. Gli avvisi unificano errori di configurazione, vulnerabilità note e comportamenti sospetti per una risposta rapida.

5. Proteggere gli strumenti di amministrazione basati su App Service con autenticazione e accesso privato.

• Motivazione: Utilizzare l’autenticazione di App Service con Microsoft Entra ID per richiedere MFA e l’accesso condizionale (Conditional Access). Creare un endpoint privato per l’app di amministrazione e limitare separatamente l’accesso a scm. Le identità gestite eliminano la necessità di secret per l’accesso a Key Vault.

6. Utilizzare l’accesso Just-in-Time (JIT) alle VM per gli host legacy durante la transizione (cutover).

• Motivazione: JIT chiude RDP/SSH per impostazione predefinita e li apre solo su richieste approvate per durate limitate. Ciò delimita rigorosamente le finestre di esposizione, preservando al contempo l’accesso di emergenza.

7. Standardizzare le scelte di crittografia: SSE con CMK per i dischi; Trusted Launch per le VM.

• Motivazione: SSE con CMK minimizza il carico operativo e centralizza il ciclo di vita delle chiavi in Key Vault, mentre Trusted Launch/vTPM aggiunge integrità all’avvio e protezione delle chiavi. ADE è riservato solo ai casi in cui è contrattualmente richiesta una prova del dominio crittografico basata sul guest.

8. Applicare Azure Policy e i controlli di ammissione come guardrail.

• Motivazione: Le iniziative di Azure Policy impongono l’uso di trusted launch, le estensioni VM richieste e negano l’accesso pubblico ad ACR/Function. I vincoli di Gatekeeper implementano controlli di ammissione a runtime per AKS. Insieme, garantiscono che le configurazioni rimangano conformi man mano che i team iterano.

9. Convalidare e operare con una governance continua.

• Motivazione: Collegare gli avvisi di Defender for Cloud e MDE al SIEM di Adobe, misurare l’effetto delle policy (deny vs. audit) e rivedere le eccezioni mensilmente. Questo trasforma i controlli una tantum in un modello operativo di sicurezza duraturo.

← Architettura della sicurezza di rete · Tutti i domini · Sicurezza di dati →

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

Sfoglia Microsoft →