Rete HSM dedicata di Azure

HSM dedicato di Azure richiede un'infrastruttura di rete affidabile e sicura in tutti gli scenari di distribuzione. Se ci si connette dal cloud di Azure all'ambiente locale, implementando applicazioni distribuite o stabilendo configurazioni a disponibilità elevata, la sicurezza completa è essenziale. Rete di Azure offre la sicurezza tramite quattro aree di rete critiche che richiedono un'attenta pianificazione e implementazione.

• Creazione di dispositivi HSM all'interno della rete virtuale in Azure
• Connessione locale a risorse basate sul cloud per la configurazione e la gestione dei dispositivi HSM
• Creazione e connessione di reti virtuali per la connessione tra le risorse dell'applicazione e i dispositivi HSM
• Connessione di reti virtuali tra aree per la comunicazione e anche per abilitare scenari di disponibilità elevata

Rete virtuale per HSM dedicati

I moduli di protezione hardware dedicati sono integrati in una rete virtuale e inseriti nella propria rete privata dei clienti in Azure. In questo modo è possibile accedere ai dispositivi dalle macchine virtuali o dalle risorse di calcolo nella rete virtuale.
Per altre informazioni sull'integrazione dei servizi di Azure nella rete virtuale e sulle funzionalità offerte, vedere la documentazione relativa alla rete virtuale per i servizi di Azure .

Reti virtuali

I clienti devono creare una rete virtuale in Azure prima del provisioning o usarne una già esistente nella sottoscrizione dei clienti. La rete virtuale definisce il perimetro di sicurezza per il dispositivo HSM dedicato. Per altre informazioni sulla creazione di reti virtuali, vedere la documentazione della rete virtuale.

Subnetti

Le subnet segmentano la rete virtuale in spazi di indirizzi separati usabili dalle risorse di Azure contenute. I moduli di protezione hardware dedicati vengono distribuiti in una subnet nella rete virtuale. Ogni dispositivo HSM dedicato distribuito nella subnet del cliente riceve un indirizzo IP privato da questa subnet.

La subnet in cui viene distribuito il dispositivo HSM deve essere delegata in modo esplicito al servizio: Microsoft.HardwareSecurityModules/dedicatedHSMs. In questo modo vengono concesse determinate autorizzazioni al servizio HSM per la distribuzione nella subnet. La delega agli HSM dedicati impone alcune limitazioni per i criteri della subnet. I gruppi di sicurezza di rete (NSG) e le route definite dall'utente (UDR) non sono attualmente supportati nelle subnet delegate. Di conseguenza, una volta delegata una subnet a moduli di protezione hardware dedicati, può essere usata solo per distribuire le risorse del modulo di protezione hardware. La distribuzione di qualsiasi altra risorsa del cliente nella subnet ha esito negativo. Non è necessario specificare quanto grande o piccola sia la subnet per HSM dedicato, ma ogni dispositivo HSM usa un indirizzo IP privato, quindi deve essere garantito che la subnet sia sufficientemente grande da contenere il numero di dispositivi HSM necessari per la distribuzione.

Gateway di ExpressRoute

Un requisito dell'architettura corrente è la configurazione di un gateway ExpressRoute nella subnet dei clienti in cui deve essere inserito un dispositivo HSM per abilitare l'integrazione del dispositivo HSM in Azure. Il gateway ExpressRoute non può essere usato per la connessione di posizioni locali ai dispositivi HSM dei clienti in Azure.

Connessione dell'IT locale ad Azure

Quando si creano risorse basate sul cloud, stabilire una connessione privata alle risorse IT locali è un requisito tipico. Per le distribuzioni HSM dedicate di Azure, tali connessioni servono principalmente il software client HSM per la configurazione del dispositivo, le operazioni di backup e il recupero dei log dai moduli di protezione hardware per l'analisi.

Quando si scelgono le opzioni di connettività, la natura della connessione rappresenta un punto decisionale chiave. La VPN da sito a sito offre la massima flessibilità, soprattutto quando più risorse locali necessitano di comunicazioni sicure con le risorse cloud di Azure, inclusi i moduli di protezione hardware. L'implementazione di una VPN da sito a sito richiede alle organizzazioni di distribuire un dispositivo VPN per facilitare la connessione. In alternativa, le connessioni VPN da punto a sito funzionano correttamente quando esiste solo un singolo endpoint locale, ad esempio una workstation di amministrazione.

Per altre informazioni sulle opzioni di connettività, vedere Opzioni di pianificazione del gateway VPN.

VPN da punto a sito

Una rete privata virtuale da punto a sito è la forma più semplice di connessione sicura a un singolo endpoint locale. Questo può essere rilevante se si dispone solo di una singola workstation di amministrazione per moduli di protezione hardware dedicati basati su Azure.

VPN da sito a sito

Una rete privata virtuale da sito a sito consente la comunicazione sicura tra moduli di protezione hardware dedicati basati su Azure e l'infrastruttura IT locale. Le organizzazioni spesso implementano tali connessioni quando si gestisce una funzionalità di backup locale per i moduli di protezione hardware, poiché il tunnel sicuro supporta i trasferimenti di dati necessari per le operazioni di backup tra entrambi gli ambienti.

Connessione di reti virtuali

Un'architettura di distribuzione tipica per HSM dedicato inizia con una singola rete virtuale e la corrispondente subnet in cui vengono creati i dispositivi HSM e ne viene eseguito il provisioning. All'interno della stessa area potrebbero essere presenti più reti virtuali e subnet per i componenti dell'applicazione che usano il modulo di protezione hardware dedicato. Per abilitare la comunicazione tra queste reti, viene utilizzato il peering di reti virtuali.

Peering di rete virtuale

Quando ci sono più reti virtuali in una regione che devono accedere alle risorse reciproche, il peering delle reti virtuali crea canali di comunicazione sicuri tra di loro. Il peering di rete virtuale offre non solo comunicazioni sicure, ma garantisce anche connessioni a bassa latenza e larghezza di banda elevata tra le risorse in Azure.

Connessione tra aree di Azure

I dispositivi HSM possono, tramite librerie software, reindirizzare il traffico a un HSM alternativo. Il reindirizzamento del traffico è utile se i dispositivi hanno esito negativo o l'accesso a un dispositivo viene perso. Gli scenari di errore a livello di area possono essere mitigati distribuendo moduli di protezione hardware in altre aree e abilitando la comunicazione tra reti virtuali tra aree.

Disponibilità elevata tra aree mediante il gateway VPN

Per le applicazioni distribuite a livello globale o per scenari di failover a livello di area a disponibilità elevata, è necessario connettere reti virtuali tra aree. Con HSM dedicato di Azure, la disponibilità elevata può essere ottenuta usando un gateway VPN che fornisce un tunnel sicuro tra le due reti virtuali. Per altre informazioni sulle connessioni da rete virtuale a rete virtuale tramite gateway VPN, vedere l'articolo Che cos'è il gateway VPN?

Restrizioni di rete

Limitazioni della sicurezza di rete

La scheda di interfaccia di rete (NIC) situata all'interno della rete virtuale dell'HSM dedicato non può utilizzare i gruppi di sicurezza di rete (NSG) o le route definite dall'utente (UDR) a causa dei requisiti di delega della subnet. Ciò crea una considerazione importante sulla sicurezza: non è possibile implementare criteri di negazione predefiniti direttamente dal punto di vista della rete virtuale HSM dedicata. È invece necessario implementare la sicurezza consentendo in modo esplicito l'accesso da segmenti di rete specifici al servizio HSM dedicato tramite metodi alternativi.

L'aggiunta della soluzione proxy NVA (Network Virtual Appliances) consente anche di posizionare logicamente un firewall NVA nell'hub di transito/DMZ davanti alla NIC HSM, fornendo così l'alternativa necessaria ai NSG e alle UDR.

Architettura della soluzione

Questa progettazione di rete richiede gli elementi seguenti:

1. Una rete virtuale dell'hub DMZ o di transito con un livello proxy nell'appliance virtuale di rete. Idealmente sono presenti due o più appliance virtuali di rete.
2. Un circuito ExpressRoute con un peering privato abilitato e una connessione alla rete virtuale dell'hub di transito.
3. Peering tra reti virtuali tra la rete virtuale dell'hub di transito e la rete virtuale dell'HSM dedicato.
4. Un firewall dell'appliance virtuale di rete o il Firewall di Azure può essere distribuito per offrire servizi DMZ nell'hub come opzione.
5. È possibile eseguire il peering di reti virtuali spoke aggiuntive del carico di lavoro alla rete virtuale dell'hub. Il client Gemalto può accedere al servizio HSM dedicato tramite la rete virtuale dell'hub.

Poiché l'aggiunta della soluzione proxy NVA consente anche di posizionare logicamente un firewall NVA nell'hub di transito/DMZ davanti alla NIC HSM, fornendo quindi le necessarie politiche di default-deny. In questo esempio viene usato Firewall di Azure per questo scopo e sono necessari gli elementi seguenti:

1. Firewall di Azure distribuito nella subnet "AzureFirewallSubnet" nella rete virtuale dell'hub DMZ
2. Tabella di routing con un UDR che indirizza il traffico destinato all'endpoint privato dell'ILB di Azure nel firewall di Azure. Questa tabella di routing viene applicata alla gatewaySubnet in cui risiede il gateway virtuale ExpressRoute del cliente.
3. Regole di sicurezza di rete all'interno di Firewall di Azure per consentire l'inoltro tra un intervallo di origine attendibile e l'endpoint privato Azure IBL in ascolto sulla porta TCP 1792. Questa logica di sicurezza aggiunge i criteri "default deny" necessari per il servizio HSM dedicato. Ciò significa che nel servizio HSM dedicato sono consentiti solo intervalli IP di origine attendibili. Tutti gli altri intervalli vengono eliminati.
4. Tabella di routing con una UDR che indirizza il traffico diretto verso l'ambiente locale nel firewall di Azure. Questa tabella di routing viene applicata alla subnet proxy della NVA (Network Virtual Appliance).
5. Un NSG applicato alla sottorete Proxy NVA considera attendibile solo l'intervallo di subnet del Firewall di Azure come origine e consente solo l'inoltro all'indirizzo IP della NIC HSM sulla porta TCP 1792.

Alternativa alle route definite dall'utente

La soluzione di livello NVA menzionata funziona come alternativa alle UDR. Ci sono alcuni punti importanti da notare.

1. La traduzione degli indirizzi di rete dovrebbe essere configurata sull'appliance virtuale di rete (NVA) per un corretto instradamento del traffico di ritorno.
2. I clienti devono disabilitare il controllo IP del client nella configurazione di Luna HSM per utilizzare VNA per NAT. I comandi seguenti fungono da esempio.

Disable:
[hsm01] lunash:>ntls ipcheck disable
NTLS client source IP validation disabled
Command Result : 0 (Success)

Show:
[hsm01] lunash:>ntls ipcheck show
NTLS client source IP validation : Disable
Command Result : 0 (Success)

1. Distribuire UDR per il traffico in ingresso nel livello NVA.
2. In base alla progettazione, le subnet HSM non avvieranno una richiesta di connessione in uscita al livello piattaforma.

Alternativa all'uso del peering reti virtuali globali

Esistono alcune architetture di rete globale che è possibile usare come un'alternativa al peering reti virtuali globali.

1. Usare la connessione gateway VPN da rete virtuale a rete virtuale
2. Collegare HSM VNET con un'altra VNET tramite un circuito ER. Ciò funziona meglio quando è necessario un percorso locale diretto o una rete virtuale VPN.

HSM con connettività ExpressRoute diretta

Passaggi successivi

• Domande frequenti
• Supporto
• Disponibilità elevata
• Sicurezza fisica
• Monitoring
• Architettura di distribuzione