Quattro superfici distinte: i dati sui dischi, il canale amministrativo, le porte di gestione, la catena di avvio. In tre casi su quattro il default non basta.

Cifratura dei dischi: tre livelli sovrapposti

Server-side encryption (SSE) è sempre attiva sui dischi gestiti e non si disattiva: AES-256, conforme FIPS 140-2, senza costi né impatto prestazionale. Il dettaglio che sfugge: SSE non cifra il disco temporaneo né le cache dei dischi OS e dati. Le VM di generazione 5 e successive (Dsv5, Dsv6) cifrano da sole disco temporaneo e disco OS effimero; sulle famiglie precedenti quella superficie resta scoperta.

Encryption at host chiude il buco spostando la cifratura sull’host che ospita la VM: disco temporaneo, cache e traffico verso lo storage viaggiano cifrati, senza consumare CPU della VM. Due prerequisiti bloccano chi improvvisa: la feature va registrata sulla sottoscrizione, e una VM esistente va deallocata e riallocata.

Register-AzProviderFeature -FeatureName "EncryptionAtHost" -ProviderNamespace "Microsoft.Compute"
Portale: Macchina virtuale > Dischi > Encryption at host

Azure Disk Encryption (ADE), cioè BitLocker o DM-Crypt dentro il guest, è in ritiro il 15 settembre 2028: dopo quella data i dischi cifrati non si sbloccheranno più dopo un riavvio. I due meccanismi si escludono: encryption at host non si abilita su una VM che ha, anche solo in passato, avuto ADE.

Con chiavi gestite dal cliente serve un disk encryption set, che alla creazione riceve un’identità gestita assegnata dal sistema; il key vault deve stare nella stessa regione e avere soft delete e purge protection, obbligatori per i dischi gestiti. Se la chiave viene disabilitata, eliminata o scade, le VM che la usano si spengono e l’I/O fallisce circa un’ora dopo. In Defender for Cloud la sola SSE risulta Unhealthy; encryption at host risulta Healthy.

Bastion: lo SKU decide, l’NSG non perdona

Bastion pubblica RDP e SSH su TLS 443 dal portale o dal client nativo, senza IP pubblico sulla VM e senza agent. Developer è gratuito ma condiviso, gestisce una sola VM alla volta e non supporta il peering: dichiarato inadatto alla produzione. Basic ha host dedicato e 2 istanze fisse, ma niente client nativo, shareable link, IP-connect, porte custom, trasferimento file. Standard aggiunge quelle funzioni e l’host scaling da 2 a 50 istanze. Premium aggiunge registrazione delle sessioni e deployment private-only, senza IP pubblico sul bastion.

Basic, Standard e Premium richiedono una subnet dedicata chiamata esattamente AzureBastionSubnet, /26 o più grande. Si sale di SKU dal portale; non si scende: per tornare indietro si elimina e si ricrea.

Se applichi un NSG all’AzureBastionSubnet devi scrivere tutte le regole, non solo la 443: ometterne una impedisce al bastion di ricevere gli aggiornamenti della piattaforma.

IN   Internet          -> *              : 443
IN   GatewayManager    -> *              : 443
IN   AzureLoadBalancer -> *              : 443
IN   VirtualNetwork    -> VirtualNetwork : 8080, 5701
OUT  *                 -> VirtualNetwork : 22, 3389
OUT  *                 -> AzureCloud     : 443
OUT  VirtualNetwork    -> VirtualNetwork : 8080, 5701
OUT  *                 -> Internet       : 80

Sulla subnet delle VM bersaglio serve l’ingresso su 3389 e 22 con origine ristretta al range dell’AzureBastionSubnet, non a Internet: è la regola che trasforma Bastion in un vero choke point.

JIT: chiude la porta solo se non c’è già un allow

Just-in-time richiede Defender for Servers Plan 2. Defender inserisce regole deny all inbound sulle porte scelte nell’NSG e nelle regole di Azure Firewall; a richiesta approvata apre la porta dall’IP indicato per il tempo concesso, poi ripristina gli NSG allo stato precedente. Le connessioni già stabilite non vengono interrotte.

Il tranello: se esistono già regole per quelle porte, le preesistenti hanno priorità sulle nuove deny. Una vecchia regola allow su 3389 rende JIT decorativo. Restano fuori le VM classiche e quelle protette da un Azure Firewall gestito con Azure Firewall Manager; il firewall deve usare Rules (Classic), non le Firewall policy. Senza NSG né firewall la VM finisce nella scheda Unsupported.

Abilitando JIT dalla pagina Configuration della VM i default sono 3389 (Windows) o 22 (Linux), massimo 3 ore e IP di origine Any: il primo intervento sensato è restringere l’origine. Configurare la policy richiede jitNetworkAccessPolicies/write e virtualMachines/write; per richiedere l’accesso serve invece jitNetworkAccessPolicies/initiate/action.

Security type: secure boot, vTPM e integrity monitoring

Trusted Launch è lo stato predefinito delle nuove VM Gen2 e degli scale set: portale, CLI e PowerShell lo applicano anche senza registrare feature. Nel portale il campo si chiama Security type, valore Trusted launch virtual machines, con tre caselle: Secure boot, vTPM, Integrity monitoring.

Secure boot impone che bootloader, kernel e driver siano firmati da publisher attendibili: se la verifica fallisce la VM non si avvia. Il vTPM è un TPM 2.0 dedicato, fuori dalla portata della VM, che misura l’intera catena di avvio e abilita l’attestazione remota.

Integrity monitoring non è una terza casella indipendente: installa l’estensione Guest Attestation e richiede secure boot e vTPM entrambi accesi. Si rompe quasi sempre per motivi di rete: l’estensione deve raggiungere l’endpoint di Azure Attestation.

Service tag in uscita da consentire: AzureAttestation
FQDN da consentire sul firewall:     *.attest.azure.net

Senza Defender for Cloud l’integrità di avvio non viene monitorata: è Defender che emette l’assessment di attestazione e gli alert, severità media se l’attestazione fallisce. Trusted Launch non supporta le Managed Image né l’ibernazione delle VM Linux.