Azure Dedicated HSM netwerken

  • Artikel
  • 8 minuten om te lezen

Azure Dedicated HSM is een uiterst veilige netwerkomgeving vereist. Dit geldt voor zowel de Azure-cloud als de IT-omgeving (on-premises) van de klant, met gedistribueerde toepassingen of voor scenario's met hoge beschikbaarheid. Azure-netwerken biedt dit en er zijn vier afzonderlijke gebieden die moeten worden aangepakt.

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

Virtueel netwerk voor uw toegewezen HMS's

Toegewezen HMS's worden geïntegreerd in een Virtual Network geplaatst in het eigen particuliere netwerk van de klant in Azure. Hierdoor is toegang tot de apparaten mogelijk vanaf virtuele machines of rekenbronnen 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 ze een Dedicated HSM inrichten, moeten klanten 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 Dedicated HSM apparaat. Zie 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 in deze subnetten wilt plaatsen. Toegewezen HMS's worden geïmplementeerd in een subnet in het virtuele netwerk. Elk Dedicated HSM dat is geïmplementeerd in het subnet van de klant, 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/dedicatedHSMs. Hiermee worden bepaalde machtigingen verleend aan de HSM-service voor implementatie in het subnet. Delegering naar toegewezen HMS's legt bepaalde beleidsbeperkingen op aan het subnet. Netwerkbeveiligingsgroepen (NSG's) en User-Defined Routes (UDR's) worden momenteel niet ondersteund op gedelegeerde subnetten. Als gevolg hiervan kan een subnet, zodra dit is gedelegeerd aan toegewezen HSM's, 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 Dedicated HSM moet zijn, maar elk HSM-apparaat gebruikt één privé-IP- en moet er dus voor zorgen dat het subnet groot genoeg is om ruimte te bieden voor zoveel HSM-apparaten als nodig is voor implementatie.

ExpressRoute-gateway

Een vereiste van de huidige architectuur is de configuratie van een ExpressRoute-gateway in het klantensubnet 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 om on-premises locaties te verbinden met de HSM-apparaten van klanten in Azure.

Uw on-premises IT verbinden met Azure

Bij het maken van cloudbronnen is het 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 binnenhalen 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 HMS'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 meer informatie over connectiviteitsopties.

Notitie

Op dit moment is ExpressRoute geen optie voor verbinding met on-premises resources. Ook moet worden opgemerkt dat de ExpressRoute-gateway die wordt gebruikt zoals hierboven wordt beschreven, niet is voor verbindingen met een 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 van plan bent slechts één beheerwerkstation te hebben voor toegewezen HMS's in Azure.

Site-naar-site-VPN

Een site-naar-site virtueel particulier netwerk maakt beveiligde communicatie mogelijk tussen toegewezen HMS's in Azure en uw on-premises IT. Een reden hiervoor is een back-upfaciliteit voor de on-premises HSM en een verbinding tussen de twee nodig hebben voor het uitvoeren van de back-up.

Virtuele netwerken verbinden

Een typische implementatiearchitectuur voor Dedicated HSM begint met één virtueel netwerk en het bijbehorende subnet waarin de HSM-apparaten worden gemaakt en ingericht. Binnen dezelfde regio kunnen er mogelijk extra virtuele netwerken en subnetten zijn voor toepassingsonderdelen die gebruikmaken van de Dedicated HSM. Om communicatie tussen 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 voor virtuele netwerken biedt niet alleen beveiligde communicatie, maar zorgt ook voor verbindingen met lage latentie en hoge bandbreedte tussen de resources in Azure.

netwerk-peering

Verbinding maken tussen Azure-regio's

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

Ha in verschillende 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 te verbinden tussen regio's. Met Azure Dedicated HSM kunt u hoge beschikbaarheid bereiken met behulp van een VPN Gateway die een beveiligde tunnel tussen de twee virtuele netwerken biedt. Zie het artikel What is VPN Gateway? (Wat is VPN Gateway? voor meer informatie over Vnet-naar-Vnet-verbindingen met VPN Gateway.

Notitie

Wereldwijde VNet-peering is op dit moment niet beschikbaar in scenario's voor connectiviteit tussen regio's met toegewezen HMS's en vpn-gateway moet in plaats daarvan worden gebruikt.

Diagram met twee regio's die zijn verbonden door twee V P N-gateways. Elke regio bevat virtuele peernetwerken.

Netwerkbeperkingen

Notitie

Een beperking van de Dedicated HSM service die gebruik maakt van subnetdelegering, worden beperkingen opgelegd die in aanmerking moeten worden genomen 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 Dedicated 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 de Dedicated HSM VNet 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 Dedicated HSM-VNet en dat andere netwerksegmenten moeten worden toegestaan om toegang te krijgen tot de Dedicated HSM-service.

Door de NVA-proxyoplossing (Network Virtual Appliances) toe te voegen, kan 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 gebruikt.

Architectuur van de oplossing

Dit netwerkontwerp vereist de volgende elementen:

  1. Een transit- of DMZ-hub-VNet met een NVA-proxylaag. Idealiter zijn er twee of meer N NVA's aanwezig.
  2. Een ExpressRoute-circuit met ingeschakelde privé-peering en een verbinding met het VNet van de transithub.
  3. Een VNet-peering tussen het doorvoerhub-VNet en Dedicated 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 ge peerd met 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 een NSG- en UDR-tijdelijke oplossing

Omdat u de NVA-proxyoplossing ook kunt toevoegen, kan een NVA-firewall in de transit/DMZ-hub logisch worden geplaatst voor de HSM-NIC, waardoor het benodigde beleid voor standaard weigeren wordt weergegeven. 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 het subnet 'AzureFirewallSubnet' in het VNet van de DMZ-hub
  2. Een routeringstabel met een UDR die verkeer dat naar het privé-eindpunt van de Azure ILB gaat, naar de Azure Firewall. Deze routeringstabel wordt toegepast op het GatewaySubnet waar de ExpressRoute Virtual Gateway van de klant zich bevindt
  3. Netwerkbeveiligingsregels binnen 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 vereiste standaardbeleid voor weigeren aan de Dedicated HSM service. Dit betekent dat alleen IP-adresbereiken van vertrouwde bronnen worden toegestaan in de Dedicated HSM service. Alle andere bereik worden weggevallen.
  4. Een routeringstabel met een UDR die verkeer naar on-prem naar de Azure Firewall. Deze routeringstabel wordt toegepast op het NVA-proxysubnet.
  5. Een NSG die wordt 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 via SNAT doorsturen naar de HSM-NIC, zijn er geen UPR's vereist tussen het HSM-VNet en het DMZ-hub-VNet.

Alternatief voor UDR's

De hierboven genoemde oplossing voor de NVA-laag werkt als alternatief voor UVA's. Er zijn enkele belangrijke punten om op te merken.

  1. Network Address Translation moet worden geconfigureerd op NVA zodat retourverkeer correct kan worden gerouteerd.
  2. Klanten moeten de client-IP-controle in Luna HSM-configuratie uitschakelen om VNA voor NAT te gebruiken. De volgende opdrachten worden als voorbeeld gebruikt.
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 ingressverkeer naar de NVA-laag.
  2. Daarom starten HSM-subnetten geen uitgaande verbindingsaanvraag naar de platformlaag.

Alternatief voor het gebruik van Global VNET-peering

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

  1. Vnet-naar-Vnet-verbinding VPN Gateway gebruiken
  2. Verbinding maken 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 met HSM met directe Express Route-connectiviteit

Volgende stappen