Delen via

Toegewezen HSM-netwerken van Azure

  • Artikel

Azure Dedicated HSM vereist een zeer veilige netwerkomgeving. Dit is waar of het vanuit 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 virtuele netwerk (VNet) in Azure
  • On-premises verbinden met cloudresources voor de configuratie en het beheer van HSM-apparaten
  • Virtuele netwerken maken en verbinden voor interverbinding tussen toepassingsbronnen en HSM-apparaten
  • Virtuele netwerken verbinden tussen regio's voor communicatie en om scenario's met hoge beschikbaarheid mogelijk te maken

Virtueel netwerk voor uw toegewezen HSM's

Toegewezen HSM's worden geïntegreerd in een virtueel netwerk en geplaatst in het eigen privénetwerk van klanten in Azure. Hiermee hebt u toegang tot de apparaten vanaf virtuele machines of rekenresources in het virtuele netwerk.
Zie de documentatie over het virtuele netwerk 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 een toegewezen HSM-apparaat wordt ingericht, moeten klanten eerst een virtueel netwerk maken in Azure of een virtueel netwerk gebruiken dat al bestaat in het abonnement van de klant. Het virtuele netwerk definieert de beveiligingsperimeter voor het toegewezen HSM-apparaat. Zie de documentatie voor 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 wordt geïmplementeerd, moet expliciet worden gedelegeerd aan de service: Microsoft.HardwareSecurityModules/dedicatedHSM's. Hiermee worden bepaalde machtigingen verleend 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 door de gebruiker gedefinieerde routes (UDR's) worden momenteel niet ondersteund voor gedelegeerde subnetten. Als een subnet is gedelegeerd aan toegewezen HSM's, kan het dus alleen worden gebruikt om HSM-resources te implementeren. De implementatie van andere klantbronnen in het subnet mislukt. Het is niet vereist hoe groot of klein het subnet voor toegewezen HSM moet zijn, maar elk HSM-apparaat verbruikt één privé-IP, dus moet worden gegarandeerd dat het subnet groot genoeg is om zoveel HSM-apparaten te kunnen gebruiken als vereist is voor de 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 het een typische vereiste voor een privéverbinding met on-premises IT-resources. In het geval van toegewezen HSM is dit voornamelijk bedoeld 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, omdat 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 eindpunt on-premises is, zoals één beheerwerkstation. Zie planningsopties voor VPN Gateway 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 is beschreven, niet bedoeld is voor verbindingen met on-premises infrastructuur.

Punt-naar-site-VPN

Een punt-naar-site virtueel particulier netwerk 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-to-site-VPN

Een site-naar-site virtueel particulier netwerk maakt beveiligde communicatie mogelijk tussen toegewezen HSM's op basis van Azure en uw on-premises IT. Een reden hiervoor is dat er een back-upfaciliteit is voor de on-premises HSM en dat er een verbinding tussen de twee nodig is 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 dezelfde regio kunnen er wel extra virtuele netwerken en subnetten zijn voor toepassingsonderdelen die gebruikmaken van de toegewezen HSM. Om communicatie tussen deze netwerken mogelijk te maken, gebruiken we Peering voor virtuele netwerken.

Peering op virtueel netwerk

Wanneer er meerdere virtuele netwerken binnen een regio zijn die toegang nodig hebben tot elkaars resources, kan Peering van virtuele netwerken 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 lage latentie en hoge bandbreedte tussen de resources in Azure.

netwerkpeering

Verbinding maken tussen Azure-regio's

De HSM-apparaten hebben de mogelijkheid om verkeer via softwarebibliotheken om te leiden naar een alternatieve HSM. Het omleiden van verkeer is handig als apparaten mislukken of als de toegang tot een apparaat verloren gaat. Scenario's voor storingen op regionaal niveau kunnen worden beperkt door HSM's in andere regio's te implementeren en communicatie tussen virtuele netwerken in verschillende regio's mogelijk te maken.

Hoge beschikbaarheid tussen regio's met BEHULP van VPN-gateway

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

Notitie

Globale Vnet-peering is momenteel niet beschikbaar in connectiviteitsscenario's tussen regio's met toegewezen HSM's en in plaats daarvan moet de VPN-gateway worden gebruikt.

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

Netwerkbeperkingen

Notitie

Een beperking van de toegewezen HSM-service die gebruikmaakt van subnetdelegering, worden beperkingen opgelegd die moeten worden overwogen bij het ontwerpen van de doelnetwerkarchitectuur voor een HSM-implementatie. Het gebruik van subnetdelegering 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 te bereiken voor deze mogelijkheden.

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 beleid voor standaard weigeren in te stellen vanuit 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 een NVA-firewall in de transit/DMZ-hub logisch worden geplaatst vóór de HSM-NIC, 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 doorvoer- of DMZ-hub-VNet met een NVA-proxylaag. In het ideale voorbeeld zijn er twee of meer NVA's aanwezig.
  2. Een ExpressRoute-circuit waarvoor een persoonlijke peering is 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 worden geïmplementeerd.
  5. Extra workload spoke-VNets kunnen worden gekoppeld aan het hub-VNet. De Gemalto-client heeft toegang tot de toegewezen HSM-service via het hub-VNet.

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

Omdat het toevoegen van de NVA-proxyoplossing ook toestaat dat een NVA-firewall in de transit/DMZ-hub logisch wordt geplaatst vóór de HSM-NIC, waardoor het benodigde standaardbeleid voor weigeren wordt geboden. In ons voorbeeld gebruiken we de Azure Firewall voor dit doel 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 waarmee verkeer naar het privé-eindpunt van Azure ILB naar de Azure Firewall wordt geleid. Deze routeringstabel wordt toegepast op het GatewaySubnet waar de expressRoute-gateway van de klant zich bevindt
  3. Netwerkbeveiligingsregels binnen de AzureFirewall om doorsturen tussen een vertrouwd bronbereik en het privé-eindpunt van Azure IBL toe te staan dat luistert op TCP-poort 1792. Met deze beveiligingslogica wordt het benodigde 'standaard weigeren'-beleid 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 omleidt naar on-premises naar de Azure Firewall. Deze routeringstabel wordt toegepast op het NVA-proxysubnet.
  5. Een NSG die is toegepast op het NVA-subnet proxy om alleen het subnetbereik van de Azure Firewall als bron te vertrouwen en 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 naar de HSM-NIC stuurt, 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 die u moet noteren.

  1. Netwerkadresomzetting moet worden geconfigureerd op NVA, zodat retourverkeer correct kan worden gerouteerd.
  2. Klanten moeten de ip-check 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. UDR's implementeren voor inkomend verkeer in de NVA-laag.
  2. Volgens het ontwerp starten HSM-subnetten geen uitgaande verbindingsaanvraag naar de platformlaag.

Alternatief voor het gebruik van globale VNET-peering

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

  1. Verbinding tussen Vnet-naar-Vnet-VPN-gateways gebruiken
  2. Verbind HSM VNET met een ander VNET met een ER-circuit. Dit werkt het beste wanneer een direct on-premises pad is vereist of VPN-VNET.

HSM met directe Express Route-connectiviteit

Diagram toont HSM met directe Express Route-connectiviteit

Volgende stappen