Azure Dedicated HSM nätverk

Azure Dedicated HSM kräver en mycket säker nätverksmiljö. Detta gäller oavsett om det är från Azure-molnet tillbaka till kundens IT-miljö (lokalt), med distribuerade program eller för scenarier med hög tillgänglighet. Azure-nätverkstjänster detta och det finns fyra olika områden som måste åtgärdas.

• Skapa HSM-enheter i Virtual Network (VNet) i Azure
• Ansluta lokalt till molnbaserade resurser för konfiguration och hantering av HSM-enheter
• Skapa och ansluta virtuella nätverk för sammankopplade programresurser och HSM-enheter
• Ansluta virtuella nätverk mellan regioner för kommunikation och även för att möjliggöra scenarier med hög tillgänglighet

Virtuellt nätverk för dina dedikerade HSM:er

Dedikerade HSM:er är integrerade i Virtual Network och placeras i kundernas egna privata nätverk i Azure. Detta ger åtkomst till enheter från virtuella datorer eller beräkningsresurser i det virtuella nätverket.
Mer information om hur du integrerar Azure-tjänster i det virtuella nätverket och dess funktioner finns i dokumentationen om virtuella nätverk för Azure-tjänster.

Virtuella nätverk

Innan du etablerar Dedicated HSM-enhet måste kunderna först skapa en Virtual Network i Azure eller använda en som redan finns i kundprenumerationen. Det virtuella nätverket definierar säkerhets perimetern för Dedicated HSM enhet. Mer information om hur du skapar virtuella nätverk finns i dokumentationen om virtuella nätverk.

Undernät

Undernät segmenterar det virtuella nätverket i separata adressutrymmen som kan användas av de Azure-resurser som du placerar i dem. Dedikerade HSM:er distribueras i ett undernät i det virtuella nätverket. Varje Dedicated HSM enhet som distribueras i kundens undernät får en privat IP-adress från det här undernätet. Undernätet där HSM-enheten distribueras måste uttryckligen delegeras till tjänsten: Microsoft.HardwareSecurityModules/dedicatedHSM. Detta beviljar vissa behörigheter till HSM-tjänsten för distribution till undernätet. Delegering till dedikerade HSM:er inför vissa principbegränsningar för undernätet. Nätverkssäkerhetsgrupper (NSG:er) och User-Defined vägar (UDR) stöds för närvarande inte i delegerade undernät. När ett undernät har delegerats till dedikerade HSM:er kan det därför bara användas för att distribuera HSM-resurser. Distributionen av andra kundresurser till undernätet misslyckas. De är inget krav på hur stort eller litet undernätet för Dedicated HSM ska vara, men varje HSM-enhet kommer att använda en privat IP-adress, så det bör säkerställas att undernätet är tillräckligt stort för att hantera så många HSM-enheter som krävs för distribution.

ExpressRoute-gateway

Ett krav för den aktuella arkitekturen är konfiguration av en ExpressRoute-gateway i kundens undernät där en HSM-enhet måste placeras för att aktivera integrering av HSM-enheten i Azure. ExpressRoute-gatewayen kan inte användas för att ansluta lokala platser till kundernas HSM-enheter i Azure.

Ansluta din lokala IT till Azure

När du skapar molnbaserade resurser är det ett vanligt krav för en privat anslutning tillbaka till lokala IT-resurser. När det gäller Dedicated HSM kommer detta främst att vara att HSM-klientprogramvaran konfigurerar HSM-enheterna och även för aktiviteter som säkerhetskopiering och att hämta loggar från HSM:er för analys. En viktig beslutspunkt här är anslutningens natur eftersom det finns alternativ. Det mest flexibla alternativet är plats-till-plats-VPN eftersom det troligen finns flera lokala resurser som kräver säker kommunikation med resurser (inklusive HSM:er) i Azure-molnet. Detta kräver att en kundorganisation har en VPN-enhet för att underlätta anslutningen. En punkt-till-plats-VPN-anslutning kan användas om det bara finns en enda plats lokalt, till exempel en enskild administrationsarbetsplats. Mer information om anslutningsalternativ finns i VPN Gateway planeringsalternativ.

Punkt-till-plats-VPN

Ett virtuellt privat punkt-till-plats-nätverk är den enklaste formen av säker anslutning till en enskild slutpunkt lokalt. Detta kan vara relevant om du endast planerar att ha en enda administrationsarbetsstationen för Azure-baserade dedikerade HSM:er.

Plats-till-plats-VPN

Ett virtuellt privat nätverk för plats-till-plats möjliggör säker kommunikation mellan Azure-baserade dedikerade HSM:er och din lokala IT. En anledning att göra detta är att ha en säkerhetskopieringsfunktion för HSM:en lokalt och att du behöver en anslutning mellan de två för att köra säkerhetskopieringen.

Ansluta virtuella nätverk

En typisk distributionsarkitektur för Dedicated HSM startar med ett enda virtuellt nätverk och motsvarande undernät där HSM-enheterna skapas och etableras. Inom samma region kan det mycket väl finnas ytterligare virtuella nätverk och undernät för programkomponenter som använder Dedicated HSM. För att möjliggöra kommunikation mellan dessa nätverk använder vi Virtual Network peering.

Virtuell nätverkspeering

När det finns flera virtuella nätverk i en region som behöver åtkomst till varandras resurser kan Virtual Network Peering användas för att skapa säkra kommunikationskanaler mellan dem. Peering för virtuella nätverk ger inte bara säker kommunikation, utan garanterar även anslutningar med låg latens och hög bandbredd mellan resurserna i Azure.

Ansluta mellan Azure-regioner

HSM-enheterna kan, via programvarubibliotek, omdirigera trafik till en alternativ HSM. Omdirigering av trafik är användbart om enheter misslyckas eller om åtkomsten till en enhet går förlorad. Du kan minimera felscenarier på regional nivå genom att distribuera HSM:er i andra regioner och möjliggöra kommunikation mellan virtuella nätverk mellan regioner.

Ha mellan regioner med VPN-gateway

För globalt distribuerade program eller för regionala redundansscenarier med hög tillgänglighet krävs anslutning av virtuella nätverk mellan regioner. Med Azure Dedicated HSM kan hög tillgänglighet uppnås med hjälp av en VPN Gateway som tillhandahåller en säker tunnel mellan de två virtuella nätverken. Mer information om Vnet-till-Vnet-anslutningar med VPN Gateway finns i artikeln Vad heter VPN Gateway?

Nätverksbegränsningar

HSM-nätverkskortet som finns i Dedicated HSM virtuella nätverket kan inte använda nätverkssäkerhetsgrupper eller användardefinierade vägar. Det innebär att det inte går att ange standardprinciper för att neka från det virtuella Dedicated HSM-nätverket och att andra nätverkssegment måste tillåtas för att få åtkomst till Dedicated HSM-tjänsten.

Genom att lägga till NVA-proxylösningen (Network Virtual Appliances) kan en NVA-brandvägg i överförings-/DMZ-hubben placeras logiskt framför HSM-nätverkskortet, vilket ger det nödvändiga alternativet till NSG:er och UDR:er.

Lösningsarkitektur

Den här nätverksdesignen kräver följande element:

1. Ett överförings- eller DMZ-hubbnätverk med en NVA-proxynivå. Vi rekommenderar att det finns två eller flera NVA:er.
2. En ExpressRoute-krets med en privat peering aktiverad och en anslutning till det virtuella nätverket för överföringshubben.
3. En VNet-peering mellan det virtuella nätverket för överföringshubben och Dedicated HSM virtuella nätverket.
4. En NVA-brandvägg eller Azure Firewall kan distribueras med DMZ-tjänster i hubben som ett alternativ.
5. Ytterligare virtuella arbetsbelastnings-ekernätverk kan peer-peeras till det virtuella hubbnätverket. Gemalto-klienten kan komma åt den dedikerade HSM-tjänsten via det virtuella hubbnätverket.

Eftersom tillägg av NVA-proxylösningen också gör att en NVA-brandvägg i överförings-/DMZ-hubben kan placeras logiskt framför HSM-nätverkskortet, vilket ger de nödvändiga standardprinciperna för att neka. I vårt exempel använder vi Azure Firewall för detta ändamål och behöver följande element på plats:

1. En Azure Firewall distribueras i undernätet "AzureFirewallSubnet" i det virtuella DMZ-hubbnätverket
2. En routningstabell med en UDR som dirigerar trafik till den privata Azure ILB-slutpunkten till Azure Firewall. Den här routningstabellen tillämpas på det GatewaySubnet där kundens virtuella ExpressRoute-gateway finns
3. Nätverkssäkerhetsregler i AzureFirewall för att tillåta vidarebefordran mellan ett betrott källintervall och den privata Azure IBL-slutpunkten som lyssnar på TCP-port 1792. Den här säkerhetslogiken lägger till den nödvändiga "standardprincipen för att neka" Dedicated HSM tjänsten. Det innebär att endast tillförlitliga käll-IP-intervall tillåts i Dedicated HSM tjänsten. Alla andra intervall tas bort.
4. En routningstabell med en UDR som dirigerar trafik till den Azure Firewall. Den här routningstabellen tillämpas på NVA-proxyundernätet.
5. En NSG som tillämpas på proxy-NVA-undernätet för att endast lita på undernätsintervallet för Azure Firewall som källa och för att endast tillåta vidarebefordran till HSM NIC IP-adressen via TCP-port 1792.

Alternativ till UDR:er

Lösningen på NVA-nivån som nämns ovan fungerar som ett alternativ till UDR:er. Det finns några viktiga punkter att notera.

1. Network Address Translation ska konfigureras på NVA så att returtrafik kan dirigeras korrekt.
2. Kunder bör inaktivera klientens IP-kontroll i Configuration for HSM för att använda VNA för NAT. Följande kommandon är ett exempel.

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)

3. Distribuera UDR:er för ingresstrafik till NVA-nivån.
4. Enligt design initierar HSM-undernät inte en utgående anslutningsbegäran till plattformsnivån.

Alternativ till global VNET-peering

Det finns ett par arkitekturer som du kan använda som ett alternativ till Global VNet-peering.

1. Använda Vnet-till-Vnet VPN Gateway anslutning
2. Anslut HSM VNET med ett annat VNET med en ER-krets. Detta fungerar bäst när en direkt lokal sökväg krävs eller ett vpn-VNET.

HSM med direkt Express Route-anslutning

Nästa steg

• Vanliga frågor och svar
• Support
• Hög tillgänglighet
• Fysisk säkerhet
• Övervakning
• Distributionsarkitektur