Dela via


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 ditt virtuella nätverk (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 ett virtuellt nätverk 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 de funktioner som det tillhandahåller finns i Dokumentation 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 ett virtuellt nätverk i Azure eller använda ett 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 användardefinierade 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 krav är inte på hur stort eller litet undernätet för dedikerad HSM ska vara, men varje HSM-enhet använder 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 konfigurationen 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. Den här 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 Planeringsalternativ för VPN Gateway.

Kommentar

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 virtuellt privat nätverk för punkt-till-plats ä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 för 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äkerhetskopieringsfunktion för HSM:s lokala enheter 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. Inom 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 peering för virtuella nätverk.

Virtuell nätverkspeering

När det finns flera virtuella nätverk i en region som behöver komma åt varandras resurser kan peering för virtuella nätverk 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.

nätverkspeering

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. Scenarier på regional nivå kan minimeras genom att distribuera HSM:er i andra regioner och aktivera kommunikation mellan virtuella nätverk mellan regioner.

Ha för flera regioner med VPN-gateway

För globalt distribuerade program eller för regionala redundansscenarier med hög tillgänglighet måste du ansluta 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 Med titeln Vad är VPN Gateway?

Kommentar

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

Diagrammet visar två regioner som är anslutna med två V P N-gatewayer. Varje region innehåller peer-kopplade virtuella nätverk.

Nätverksbegränsningar

Kommentar

En begränsning för den dedikerade HSM-tjänsten med undernätsdelegering 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 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.

Det HSM-nätverkskort 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 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 en NVA-brandvägg i transit-/DMZ-hubben placeras logiskt framför HSM-nätverkskortet, vilket ger det alternativ som behövs till NSG:er och UDR.

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 det två eller flera NVA:er.
  2. En ExpressRoute-krets med en privat peering aktiverad och en anslutning till det virtuella överföringshubbens virtuella nätverk.
  3. En VNet-peering mellan det virtuella överföringshubbens virtuella nätverk och det dedikerade virtuella HSM-nätverket.
  4. En NVA-brandvägg eller Azure Firewall kan distribueras och erbjuda DMZ-tjänster i hubben som ett alternativ.
  5. Ytterligare virtuella arbetsbelastnings ekernätverk kan peerkopplas till det virtuella hubbnätverket. Gemalto-klienten kan komma åt den dedikerade HSM-tjänsten via det virtuella hubbnätverket.

Diagram visar ett virtuellt DMZ-hubbnätverk med en NVA-proxynivå för NSG och UDR-lösning

Eftersom du lägger till NVA-proxylösningen kan även en NVA-brandvägg i överförings-/DMZ-hubben placeras logiskt framför HSM-nätverkskortet, vilket ger nödvändiga standardnekande principer. 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 som är på förhand till 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 i Azure Firewall som källa och för att endast tillåta vidarebefordran till HSM NIC IP-adressen via TCP-port 1792.

Kommentar

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: er. Det finns några viktiga punkter att notera.

  1. Nätverksadressöversättning bör konfigureras på NVA så att returtrafiken 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 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)
  1. Distribuera UDR:er för inkommande trafik till NVA-nivån.
  2. Enligt designen initierar HSM-undernät inte en begäran om utgående anslutning till plattformsnivån.

Alternativ till att använda 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 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

Diagram visar HSM med direkt Express Route-anslutning

Nästa steg