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 Networking tillhandahåller detta och det finns fyra olika områden som måste åtgärdas.

• Skapa HSM-enheter i din 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 att ansluta programresurser och HSM-enheter
• Ansluta virtuella nätverk mellan regioner för interkommunikation 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 en Virtual Network och placeras i kundernas egna privata nätverk i Azure. Detta ger åtkomst till enheterna 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 vilka funktioner det tillhandahåller finns i dokumentationen om virtuella nätverk för Azure-tjänster .

Virtuella nätverk

Innan du etablerar en dedikerad 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äkerhetsperimetern för den dedikerade HSM-enheten. 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 till ett undernät i det virtuella nätverket. Varje dedikerad HSM-enhet som distribueras i kundens undernät får en privat IP-adress från det här undernätet. Det undernät där HSM-enheten distribueras måste uttryckligen delegeras till tjänsten: Microsoft.HardwareSecurityModules/dedicatedHSMs. Detta ger vissa behörigheter till HSM-tjänsten för distribution till undernätet. Delegering till dedikerade HSM:er medfö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. Deras är inget krav på hur stort eller litet undernätet för dedikerad 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 rymma 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 möjliggöra 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 dedikerad HSM är detta främst för HSM-klientprogramvaran för att konfigurera HSM-enheterna och även för aktiviteter som säkerhetskopieringar och hämtar 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 sannolikt kommer att finnas 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 slutpunkt lokalt, till exempel en enda administrationsarbetsstation. Mer information om anslutningsalternativ finns i VPN Gateway planeringsalternativ.

Anteckning

För närvarande är ExpressRoute inte ett alternativ för anslutning till lokala resurser. Det bör också noteras att ExpressRoute-gatewayen som används enligt beskrivningen ovan inte är avsedd för anslutningar till lokal infrastruktur.

Punkt-till-plats-VPN

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

Plats-till-plats-VPN

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

Ansluta virtuella nätverk

En typisk distributionsarkitektur för dedikerad HSM börjar med ett enda virtuellt nätverk och motsvarande undernät där HSM-enheterna skapas och etableras. I samma region kan det mycket väl finnas ytterligare virtuella nätverk och undernät för programkomponenter som använder dedikerad HSM. För att aktivera 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 svarstid och hög bandbredd mellan resurserna i Azure.

Ansluta mellan Azure-regioner

HSM-enheterna kan via programvarubibliotek omdirigera trafik till en alternativ HSM. Trafikomdirigering är användbart om enheter misslyckas eller om åtkomsten till en enhet går förlorad. Felscenarier på regional nivå kan minimeras genom att distribuera HSM:er i andra regioner och aktivera 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 det att du ansluter 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 är VPN Gateway?

Anteckning

Global Vnet-peering är inte tillgängligt i anslutningsscenarier mellan regioner med dedikerade HSM:er för tillfället och VPN-gateway bör användas i stället.

Nätverksbegränsningar

Anteckning

En begränsning för den dedikerade HSM-tjänsten med delegering av undernät införs begränsningar som bör beaktas när målnätverksarkitekturen utformas för en HSM-distribution. Användning av delegering av undernät innebär att NSG:er, UDR:er och global VNet-peering inte stöds för dedikerad HSM. Avsnitten nedan ger hjälp med alternativa tekniker för att uppnå samma eller liknande resultat för dessa funktioner.

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

Genom att lägga till nva-proxylösningen (Network Virtual Appliances) kan du också placera en NVA-brandvägg i transit/DMZ-hubben logiskt framför HSM-nätverkskortet, vilket ger det alternativ som behövs till NSG:er och UDR:er.

Lösningsarkitektur

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

1. Ett virtuellt nätverk för överföring eller DMZ-hubb med en NVA-proxynivå. Helst 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 transithubbens virtuella nätverk och det dedikerade virtuella HSM-nätverket.
4. En NVA-brandvägg eller Azure Firewall kan distribueras erbjuder DMZ-tjänster i hubben som ett alternativ.
5. Ytterligare virtuella arbetsbelastningsnätverk för ekrar kan peerkopplas till det virtuella hubbnätverket. Gemalto-klienten kan komma åt den dedikerade HSM-tjänsten via det virtuella hubbnätverket.

Eftersom du lägger till NVA-proxylösningen kan även en NVA-brandvägg i transit/DMZ-hubben placeras logiskt framför HSM-nätverkskortet, vilket ger de nödvändiga standardnekande principerna. I vårt exempel använder vi Azure Firewall för detta ändamål och behöver följande element:

1. En Azure Firewall distribuerad till 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å 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äkerhetslogik lägger till den nödvändiga principen "standard neka" mot den dedikerade HSM-tjänsten. Det innebär att endast betrodda käll-IP-intervall tillåts i den dedikerade HSM-tjänsten. Alla andra intervall tas bort.
4. En routningstabell med en UDR som dirigerar trafik till den lokala 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 vidarekoppling till HSM NIC IP-adressen över TCP-port 1792.

Anteckning

Eftersom NVA-proxynivån SNAT-klientens IP-adress när den vidarebefordras till HSM-nätverkskortet krävs inga UDR mellan det virtuella HSM-nätverket och det virtuella DMZ-hubbnätverket.

Alternativ till UDR

Den NVA-nivålösning som nämns ovan fungerar som ett alternativ till UDR:erna. Det finns några viktiga punkter att notera.

1. Översättning av nätverksadresser ska konfigureras på NVA så att returtrafiken kan dirigeras korrekt.
2. Kunder bör inaktivera klientens IP-kontroll i Luna HSM-konfigurationen för att använda VNA för NAT. Följande kommandon fungerar som 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:erna för inkommande trafik till NVA-nivån.
4. Enligt designen initierar HSM-undernät inte en utgående anslutningsbegäran till plattformsnivån.

Alternativ till att använda global VNET-peering

Det finns några 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 till ett annat VNET med en ER-krets. Detta fungerar bäst när en direkt lokal sökväg krävs eller 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