Reti con HSM dedicato di Azure
HSM dedicato di Azure richiede un ambiente di rete altamente sicuro. Questo vale sia dal cloud di Azure all'ambiente IT del cliente (locale), che con l'uso delle applicazioni distribuite e per scenari a disponibilità elevata. Rete di Azure fornisce tutto questo e vi sono quattro aree distinte a cui prestare attenzione.
- Creazione di dispositivi HSM all'interno della rete virtuale in Azure
- Connessione locale a risorse basate su cloud per la configurazione e gestione di dispositivi HSM
- Creazione e connessione di reti virtuali per l'interconnessione di risorse applicative e dispositivi HSM
- Connessione di reti virtuali tra aree per l'intercomunicazione e per abilitare la disponibilità elevata
Rete virtuale per HSM dedicati
Gli HSM dedicati sono integrati in una rete virtuale e inseriti nella rete privata del cliente in Azure. Ciò consente l'accesso ai dispositivi da macchine virtuali o risorse di calcolo nella rete virtuale.
Per altre informazioni sull'integrazione dei servizi di Azure nella rete virtuale e le funzionalità che ciò offre, vedere la documentazione Rete virtuale per servizi di Azure.
Reti virtuali
Prima di eseguire il provisioning di un dispositivo HSM dedicato i clienti devono creare una rete virtuale in Azure o devono usarne una esistente nella loro sottoscrizione. La rete virtuale definisce il perimetro di sicurezza per il dispositivo HSM dedicato. Per altre informazioni sulla creazione di reti virtuali, vedere la documentazione sulle reti virtuali.
Subnet
Le subnet segmentano la rete virtuale in spazi di indirizzi separati usabili dalle risorse di Azure contenute. Gli HSM dedicati sono distribuiti in una subnet all'interno di una rete virtuale. Ogni dispositivo HSM dedicato che viene distribuito nella subnet del cliente riceverà un indirizzo IP privato dalla subnet. La subnet in cui il dispositivo HSM viene distribuito 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. Nelle subnet delegate non sono supportati i gruppi di sicurezza di rete e le route definite dall'utente. Di conseguenza, dopo che una subnet è stata delegata a HSM dedicati, può essere usata solo per distribuire risorse HSM. Non sarà possibile distribuire nessun'altra risorsa del cliente nella subnet. Non è necessario specificare quanto grande o piccola sia la subnet per HSM dedicato, tuttavia ogni dispositivo HSM utilizzerà un indirizzo IP privato, quindi dovrebbe essere garantito che la subnet sia abbastanza grande per supportare il numero di dispositivi HSM necessari per la distribuzione.
Gateway 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. Non è possibile usare questo gateway ExpressRoute per connettere le posizioni locali ai dispositivi HSM dei clienti in Azure.
Connessione dell'IT locale ad Azure
Quando si creano risorse basate su cloud, un'esigenza tipica è mantenere una connessione privata a risorse IT locali. Nel caso di HSM dedicato, ciò sarà necessario soprattutto per consentire al software client HSM di configurare i dispositivi HSM e anche per attività quali il backup e il recupero dei log dai moduli di protezione hardware a scopo di analisi. Una decisione fondamentale da prendere a questo proposito riguarda la natura della connessione, per la quale esistono varie opzioni. L'opzione più flessibile è VPN da sito a sito dato che probabilmente ci saranno più risorse locali che richiedono la comunicazione sicura con le risorse, inclusi i moduli di protezione hardware, nel cloud di Azure. Questo richiederà che l'organizzazione del cliente abbia un dispositivo VPN per facilitare la connessione. È possibile usare una connessione VPN da punto a sito se è presente un solo endpoint locale, ad esempio una sola workstation amministrativa. Per altre informazioni sulle opzioni di connettività, vedere le opzioni di pianificazione di Gateway VPN.
Nota
Al momento ExpressRoute non può essere usato per la connessione a risorse locali. Si noti anche che il gateway ExpressRoute non può essere usato come descritto in precedenza per le connessioni all'infrastruttura locale.
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. Può risultare utile se si prevede di avere una sola workstation amministrativa per HSM dedicati basati su Azure.
VPN da sito a sito
Una rete privata virtuale da sito a sito consente la comunicazione sicura tra HSM dedicati basati su Azure e l'IT locale. Un motivo per eseguire questa operazione è avere una struttura di backup per il modulo di protezione hardware locale e la necessità di una connessione tra i due per l'esecuzione del backup.
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 possono essere presenti anche altre reti virtuali e subnet per i componenti dell'applicazione che usano l'HSM dedicato. Per abilitare la comunicazione tra queste reti si usa il peering di rete virtuale.
Peering di rete virtuale
Quando in un'area sono presenti più reti virtuali che devono accedere l'una alle risorse delle altre, si può usare il peering di rete virtuale per creare canali di comunicazione sicura tra esse. Il peering di rete virtuale non solo consente la comunicazione sicura ma garantisce anche una connessione a bassa latenza e larghezza di banda elevata tra le risorse in Azure.
Connessione tra aree di Azure
I dispositivi HSM hanno la capacità, tramite le librerie di software, di reindirizzare il traffico a un modulo di protezione hardware alternativo. Il reindirizzamento del traffico è utile in caso di errore dei dispositivi o di perdita dell'accesso a essi. È possibile ridurre gli scenari di errore a livello di area distribuendo moduli di protezione hardware in altre aree e abilitando la comunicazione tra reti virtuali in aree diverse.
Disponibilità elevata tra aree mediante il gateway VPN
Per le applicazioni distribuite a livello globale o per gli scenari di failover a livello di area con disponibilità elevata è necessario connettere reti virtuali di aree diverse. Con HSM dedicato di Azure è possibile ottenere la disponibilità elevata 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 mediante un Gateway VPN, vedere l'articolo intitolato Che cos'è un Gateway VPN?
Nota
Al momento il peering di rete virtuale globale in scenari di connettività fra aree non è disponibile con HSM dedicato e al suo posto si deve usare un gateway VPN.
Restrizioni di rete
Nota
Un vincolo del servizio HSM dedicato tramite la delega della subnet viene imposto restrizioni che devono essere considerate durante la progettazione dell'architettura di rete di destinazione per una distribuzione HSM. L'uso della delega di subnet significa che i gruppi di sicurezza di rete, i gruppi di sicurezza di rete virtuale e il peering di rete virtuale globale non sono supportati per HSM dedicato. Le sezioni seguenti forniscono assistenza con tecniche alternative per ottenere lo stesso risultato o un risultato simile per queste funzionalità.
La scheda di interfaccia di rete HSM che risiede nella rete virtuale HSM dedicata non può usare gruppi di sicurezza di rete o route definite dall'utente. Ciò significa che non è possibile impostare criteri di negazione predefiniti dal punto di vista della rete virtuale HSM dedicata e che altri segmenti di rete devono essere elencati per ottenere l'accesso al servizio HSM dedicato.
L'aggiunta della soluzione proxy NVA (Network Virtual Appliances) consente anche a un firewall NVA nell'hub transit/DMZ di essere posizionato logicamente davanti alla scheda di interfaccia di rete HSM, fornendo così l'alternativa necessaria ai gruppi di sicurezza di rete e alle reti di sicurezza di rete.
Architettura della soluzione
Questa progettazione di rete richiede gli elementi seguenti:
- Una rete virtuale dell'hub dmZ o di transito con un livello proxy di rete virtuale. Idealmente sono presenti due o più NVA.
- Un circuito ExpressRoute con peering privato abilitato e una connessione alla rete virtuale dell'hub di transito.
- Peering reti virtuali tra la rete virtuale dell'hub di transito e la rete virtuale HSM dedicata.
- Un firewall di rete virtuale o un Firewall di Azure può essere distribuito offre servizi DMZ nell'hub come opzione.
- È possibile eseguire il peering di reti virtuali spoke aggiuntive per il carico di lavoro nella 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 a un firewall NVA nell'hub transit/DMZ di essere posizionato logicamente davanti alla scheda di interfaccia di rete HSM, fornendo così i criteri di negazione predefiniti necessari. Nell'esempio verrà usato il Firewall di Azure per questo scopo e saranno necessari gli elementi seguenti:
- Un Firewall di Azure distribuito nella subnet "AzureFirewallSubnet" nella rete virtuale dell'hub DMZ
- Tabella di routing con un'interfaccia utente che indirizza il traffico diretto all'endpoint privato di Azure ILB nell'Firewall di Azure. Questa tabella di routing verrà applicata al gatewaySubnet in cui risiede il gateway virtuale ExpressRoute del cliente
- Regole di sicurezza di rete all'interno di AzureFirewall per consentire l'inoltro tra un intervallo di origine attendibile e l'endpoint privato IBL di Azure in ascolto sulla porta TCP 1792. Questa logica di sicurezza aggiungerà i criteri di "negazione predefiniti" necessari per il servizio HSM dedicato. Ciò significa che solo gli intervalli IP di origine attendibili saranno consentiti nel servizio HSM dedicato. Tutti gli altri intervalli verranno eliminati.
- Tabella di routing con un'interfaccia utente che indirizza il traffico diretto verso il prem nell'Firewall di Azure. Questa tabella di routing verrà applicata alla subnet proxy NVA.
- Un gruppo di sicurezza di rete applicato alla subnet NVA proxy considera attendibile solo l'intervallo di subnet dell'Firewall di Azure come origine e consente l'inoltro solo all'indirizzo IP della scheda di interfaccia di rete HSM sulla porta TCP 1792.
Nota
Poiché il livello proxy della rete virtuale di rete eseguirà SNAT l'indirizzo IP client mentre inoltra alla scheda di interfaccia di rete HSM, non sono necessarie UDR tra la rete virtuale HSM e la rete virtuale dell'hub DMZ.
Alternativa alle route definite dall'utente
La soluzione di livello appliance virtuale di rete menzionata in precedenza funziona come alternativa alle route definite dall'utente. Ci sono alcuni punti importanti da notare.
- Network Address Translation deve essere configurato nell'appliance virtuale di rete per consentire il routing corretto del traffico di ritorno.
- I clienti devono disabilitare l'archiviazione ip client nella configurazione luna HSM per usare VNA per NAT. I comandi seguenti servce come 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)
- Distribuire le route definite dall'utente per il traffico in ingresso nel livello appliance virtuale di rete.
- In base alla progettazione, le subnet del modulo di protezione hardware non avvieranno una richiesta di connessione in uscita al livello della piattaforma.
Alternativa all'uso del peering reti virtuali globale
Esistono un paio di architetture che è possibile usare come alternativa al peering reti virtuali globali.
- Usare la connessione da rete virtuale a rete virtuale Gateway VPN
- Connettere la rete virtuale HSM a un'altra rete virtuale con un circuito ER. Questo funziona meglio quando è necessario un percorso locale diretto o una rete virtuale VPN.
HSM con connettività ExpressRoute diretta
