Share via

Azure Dedicated HSM-netwerken

  • Artikel

Azure Dedicated HSM vereist een zeer veilige netwerkomgeving. Dit geldt voor scenario's met een hoge beschikbaarheid, ongeacht of de azure-cloud teruggaat naar de IT-omgeving van de klant (on-premises), met behulp van gedistribueerde toepassingen of voor scenario's met hoge beschikbaarheid. Azure Networking biedt dit en er zijn vier verschillende gebieden die moeten worden aangepakt.

  • HSM-apparaten maken in uw Virtual Network (VNet) in Azure
  • On-premises verbinding maken met cloudresources voor de configuratie en het beheer van HSM-apparaten
  • Virtuele netwerken maken en verbinden voor onderling verbinden van toepassingsresources en HSM-apparaten
  • Virtuele netwerken verbinden tussen regio's voor inter-communicatie en ook om scenario's met hoge beschikbaarheid mogelijk te maken

Virtueel netwerk voor uw toegewezen HSM's

Toegewezen HSM's worden geïntegreerd in een Virtual Network en geplaatst in het eigen particuliere netwerk van de klant in Azure. Hiermee hebt u toegang tot de apparaten vanaf virtuele machines of rekenresources in het virtuele netwerk.
Zie Documentatie over Virtuele netwerken voor Azure-services voor meer informatie over het integreren van Azure-services in het virtuele netwerk en de mogelijkheden die het biedt.

Virtuele netwerken

Voordat klanten een toegewezen HSM-apparaat inrichten, moeten ze eerst een Virtual Network maken in Azure of een apparaat gebruiken dat al bestaat in het abonnement van de klant. Het virtuele netwerk definieert de beveiligingsperimeter voor het toegewezen HSM-apparaat. Zie documentatie over virtuele netwerken voor meer informatie over het maken van virtuele netwerken.

Subnetten

Subnetten segmenteren het virtuele netwerk in afzonderlijke adresruimten die kunnen worden gebruikt door de Azure-resources die u erin plaatst. Toegewezen HSM's worden geïmplementeerd in een subnet in het virtuele netwerk. Elk toegewezen HSM-apparaat dat in het subnet van de klant wordt geïmplementeerd, ontvangt een privé-IP-adres van dit subnet. Het subnet waarin het HSM-apparaat is geïmplementeerd, moet expliciet worden gedelegeerd aan de service: Microsoft.HardwareSecurityModules/dedicatedHSMs. Hiermee verleent u bepaalde machtigingen aan de HSM-service voor implementatie in het subnet. Delegatie naar toegewezen HSM's legt bepaalde beleidsbeperkingen op voor het subnet. Netwerkbeveiligingsgroepen (NSG's) en User-Defined routes (UDR's) worden momenteel niet ondersteund op gedelegeerde subnetten. Als gevolg hiervan kan een subnet dat is gedelegeerd aan toegewezen HSM's, alleen worden gebruikt om HSM-resources te implementeren. Implementatie van andere klantresources in het subnet mislukt. Hun is niet vereist voor hoe groot of klein het subnet voor toegewezen HSM moet zijn, maar elk HSM-apparaat verbruikt één privé-IP-adres. Daarom moet ervoor worden gezorgd dat het subnet groot genoeg is om zoveel HSM-apparaten te kunnen gebruiken als nodig is voor implementatie.

ExpressRoute-gateway

Een vereiste van de huidige architectuur is de configuratie van een ExpressRoute-gateway in het subnet van de klant waar een HSM-apparaat moet worden geplaatst om integratie van het HSM-apparaat in Azure mogelijk te maken. Deze ExpressRoute-gateway kan niet worden gebruikt voor het verbinden van on-premises locaties met de HSM-apparaten van klanten in Azure.

Uw on-premises IT verbinden met Azure

Bij het maken van cloudresources is dit een typische vereiste voor een privéverbinding met on-premises IT-resources. In het geval van dedicated HSM is dit voornamelijk voor de HSM-clientsoftware om de HSM-apparaten te configureren en ook voor activiteiten zoals back-ups en het ophalen van logboeken van HSM's voor analyse. Een belangrijk beslissingspunt hier is de aard van de verbinding, aangezien er opties zijn. De meest flexibele optie is site-naar-site-VPN, omdat er waarschijnlijk meerdere on-premises resources zijn waarvoor beveiligde communicatie met resources (inclusief HSM's) in de Azure-cloud is vereist. Hiervoor moet een klantorganisatie een VPN-apparaat hebben om de verbinding te vergemakkelijken. Een punt-naar-site-VPN-verbinding kan worden gebruikt als er slechts één on-premises eindpunt is, zoals één beheerwerkstation. Zie VPN Gateway planningsopties voor meer informatie over connectiviteitsopties.

Notitie

Op dit moment is ExpressRoute geen optie voor verbinding met on-premises resources. Er moet ook worden opgemerkt dat de ExpressRoute-gateway die wordt gebruikt zoals hierboven beschreven, niet bedoeld is voor verbindingen met de on-premises infrastructuur.

Punt-naar-site-VPN

Een punt-naar-site Virtual Private Network is de eenvoudigste vorm van beveiligde verbinding met één on-premises eindpunt. Dit kan relevant zijn als u slechts één beheerwerkstation wilt hebben voor toegewezen HSM's op basis van Azure.

Site-naar-site-VPN

Een site-naar-site Virtual Private Network maakt beveiligde communicatie mogelijk tussen op Azure gebaseerde toegewezen HSM's en uw on-premises IT. Een reden om dit te doen, is het hebben van een back-upfaciliteit voor de on-premises HSM's en het nodig hebben van een verbinding tussen de twee voor het uitvoeren van de back-up.

Virtuele netwerken verbinden

Een typische implementatiearchitectuur voor toegewezen HSM begint met één virtueel netwerk en het bijbehorende subnet waarin de HSM-apparaten worden gemaakt en ingericht. Binnen diezelfde regio zijn er mogelijk extra virtuele netwerken en subnetten voor toepassingsonderdelen die gebruikmaken van de toegewezen HSM. Om communicatie via deze netwerken mogelijk te maken, gebruiken we Virtual Network Peering.

Peering op virtueel netwerk

Wanneer er meerdere virtuele netwerken binnen een regio zijn die toegang nodig hebben tot elkaars resources, kan Virtual Network Peering worden gebruikt om beveiligde communicatiekanalen tussen deze netwerken te maken. Peering van virtuele netwerken biedt niet alleen beveiligde communicatie, maar zorgt ook voor verbindingen met een lage latentie en hoge bandbreedte tussen de resources in Azure.

netwerkpeering

Verbinding maken tussen Azure-regio's

De HSM-apparaten kunnen via softwarebibliotheken verkeer omleiden naar een alternatieve HSM. Verkeersomleiding is handig als apparaten mislukken of als de toegang tot een apparaat verloren gaat. Foutscenario's op regionaal niveau kunnen worden beperkt door HSM's in andere regio's te implementeren en communicatie tussen virtuele netwerken tussen regio's mogelijk te maken.

Hoge beschikbaarheid in meerdere regio's met vpn-gateway

Voor wereldwijd gedistribueerde toepassingen of voor scenario's met regionale failover met hoge beschikbaarheid is het vereist om virtuele netwerken tussen regio's te verbinden. Met Azure Dedicated HSM kan hoge beschikbaarheid worden bereikt met behulp van een VPN Gateway die een beveiligde tunnel tussen de twee virtuele netwerken biedt. Zie het artikel Wat is VPN Gateway? voor meer informatie over Vnet-naar-Vnet-verbindingen met VPN Gateway.

Notitie

Globale VNet-peering is momenteel niet beschikbaar in scenario's voor connectiviteit tussen regio's met toegewezen HSM's en in plaats daarvan moet een VPN-gateway worden gebruikt.

Diagram toont twee regio's die zijn verbonden door twee V P N-gateways. Elke regio bevat gekoppelde virtuele netwerken.

Netwerkbeperkingen

Notitie

Een beperking van de toegewezen HSM-service die gebruikmaakt van subnetdelegatie, worden beperkingen opgelegd waarmee rekening moet worden gehouden bij het ontwerpen van de doelnetwerkarchitectuur voor een HSM-implementatie. Het gebruik van subnetdelegatie betekent dat NSG's, UDR's en globale VNet-peering niet worden ondersteund voor toegewezen HSM. De onderstaande secties bieden hulp bij alternatieve technieken om hetzelfde of een vergelijkbaar resultaat voor deze mogelijkheden te bereiken.

De HSM-NIC die zich in het toegewezen HSM-VNet bevindt, kan geen netwerkbeveiligingsgroepen of door de gebruiker gedefinieerde routes gebruiken. Dit betekent dat het niet mogelijk is om standaardbeleid voor weigeren in te stellen vanuit het oogpunt van het toegewezen HSM-VNet en dat andere netwerksegmenten moeten worden toegestaan om toegang te krijgen tot de toegewezen HSM-service.

Door de NVA-proxyoplossing (Network Virtual Appliances) toe te voegen, kan ook een NVA-firewall in de transit-/DMZ-hub logisch vóór de HSM-NIC worden geplaatst, waardoor het benodigde alternatief voor NSG's en UDR's wordt geboden.

Architectuur van de oplossing

Voor dit netwerkontwerp zijn de volgende elementen vereist:

  1. Een transit- of DMZ-hub-VNet met een NVA-proxylaag. Idealiter zijn er twee of meer NVA's aanwezig.
  2. Een ExpressRoute-circuit met een persoonlijke peering ingeschakeld en een verbinding met het VNet van de transithub.
  3. Een VNet-peering tussen het VNet van de transithub en het toegewezen HSM-VNet.
  4. Een NVA-firewall of Azure Firewall kan als optie DMZ-services in de hub aanbieden.
  5. Aanvullende spoke-VNets voor workloads kunnen worden gekoppeld aan het hub-VNet. De Gemalto-client heeft toegang tot de toegewezen HSM-service via het hub-VNet.

Diagram met een DMZ-hub-VNet met een NVA-proxylaag voor tijdelijke oplossing voor NSG en UDR

Omdat u de NVA-proxyoplossing toevoegt, kan er ook een NVA-firewall in de transit-/DMZ-hub logisch vóór de HSM-NIC worden geplaatst, waardoor het vereiste standaardbeleid voor weigeren wordt geleverd. In ons voorbeeld gebruiken we hiervoor de Azure Firewall en hebben we de volgende elementen nodig:

  1. Een Azure Firewall geïmplementeerd in subnet 'AzureFirewallSubnet' in het VNet van de DMZ-hub
  2. Een routeringstabel met een UDR die verkeer naar het privé-eindpunt van Azure ILB naar de Azure Firewall leidt. Deze routeringstabel wordt toegepast op het GatewaySubnet waar de virtuele ExpressRoute-gateway van de klant zich bevindt
  3. Netwerkbeveiligingsregels binnen de AzureFirewall om doorsturen toe te staan tussen een vertrouwd bronbereik en het privé-eindpunt van Azure IBL dat luistert op TCP-poort 1792. Met deze beveiligingslogica wordt het noodzakelijke beleid voor standaard weigeren toegevoegd aan de toegewezen HSM-service. Dit betekent dat alleen vertrouwde bron-IP-bereiken worden toegestaan in de toegewezen HSM-service. Alle andere bereiken worden verwijderd.
  4. Een routeringstabel met een UDR die verkeer naar on-premises naar de Azure Firewall leidt. Deze routeringstabel wordt toegepast op het NVA-proxysubnet.
  5. Een NSG die is toegepast op het PROXY NVA-subnet om alleen het subnetbereik van de Azure Firewall als bron te vertrouwen en om alleen doorsturen naar het IP-adres van de HSM-NIC via TCP-poort 1792 toe te staan.

Notitie

Omdat de NVA-proxylaag het IP-adres van de client doorstuurt naar de HSM-NIC, zijn er geen UDR's vereist tussen het HSM-VNet en het VNet van de DMZ-hub.

Alternatief voor UDR's

De hierboven genoemde NVA-laagoplossing werkt als alternatief voor UDR's. Er zijn enkele belangrijke punten om op te merken.

  1. Netwerkadresomzetting moet worden geconfigureerd op NVA zodat retourverkeer correct kan worden gerouteerd.
  2. Klanten moeten de IP-controle van de client uitschakelen in de Luna HSM-configuratie om VNA voor NAT te gebruiken. De volgende opdrachten dienen als voorbeeld.
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. Implementeer UDR's voor inkomend verkeer in de NVA-laag.
  2. Volgens het ontwerp starten HSM-subnetten geen aanvraag voor een uitgaande verbinding met de platformlaag.

Alternatief voor het gebruik van globale VNET-peering

Er zijn een aantal architecturen die u kunt gebruiken als alternatief voor globale VNet-peering.

  1. VNet-naar-VNet-VPN Gateway-verbinding gebruiken
  2. HSM VNET verbinden met een ander VNET met een ER-circuit. Dit werkt het beste wanneer een direct on-premises pad of VPN-VNET vereist is.

HSM met directe Express Route-connectiviteit

Diagram met HSM met directe Express Route-connectiviteit

Volgende stappen