Dediziertes Azure HSM-Netzwerk

Azure Dedicated HSM erfordert eine robuste, sichere Netzwerkinfrastruktur in allen Bereitstellungsszenarien. Ganz gleich, ob Sie eine Verbindung von der Azure-Cloud zu Ihrer lokalen Umgebung herstellen, verteilte Anwendungen implementieren oder Konfigurationen mit hoher Verfügbarkeit einrichten: Umfassende Sicherheit ist unerlässlich. Azure Networking bietet Sicherheit über vier kritische Netzwerkbereiche, die eine sorgfältige Planung und Implementierung erfordern.

• Erstellen von HSM-Geräten in Ihrem virtuellen Netzwerk (VNet) in Azure
• Herstellen einer lokalen Verbindung mit cloudbasierten Ressourcen für die Konfiguration und Verwaltung von HSM-Geräten
• Erstellen und Verbinden virtueller Netzwerke für die Verbindung von Anwendungsressourcen und HSM-Geräten
• Verbinden virtueller Netzwerke über Regionen hinweg für die Kommunikation und auch zur Aktivierung von Szenarien mit hoher Verfügbarkeit

Virtuelles Netzwerk für Ihre dedizierten HSMs

Dedizierte HSMs sind in ein virtuelles Netzwerk integriert und in das eigene private Netzwerk der Kunden in Azure platziert. Dies ermöglicht den Zugriff auf die Geräte von virtuellen Computern oder Computeressourcen im virtuellen Netzwerk.
Weitere Informationen zum Integrieren von Azure-Diensten in das virtuelle Netzwerk und die darin bereitgestellten Funktionen finden Sie in der Dokumentation zum virtuellen Netzwerk für Azure-Dienste .

Virtuelle Netzwerke

Kunden müssen vor der Bereitstellung ein virtuelles Netzwerk in Azure erstellen oder ein Netzwerk verwenden, das bereits im Abonnement des Kunden vorhanden ist. Das virtuelle Netzwerk definiert den Sicherheitsperimeter für das dedizierte HSM-Gerät. Weitere Informationen zum Erstellen virtueller Netzwerke finden Sie in der Dokumentation zum virtuellen Netzwerk.

Subnetze

Subnetze unterteilen das virtuelle Netzwerk in getrennte Adressräume, die von den Azure-Ressourcen, die Sie darin platzieren, verwendet werden können. Dedizierte HSMs werden in einem Subnetz im virtuellen Netzwerk bereitgestellt. Jedes dedizierte HSM-Gerät, das im Subnetz des Kunden bereitgestellt wird, empfängt eine private IP-Adresse von diesem Subnetz.

Das Subnetz, in dem das HSM-Gerät bereitgestellt wird, muss explizit an den Dienst delegiert werden: Microsoft.HardwareSecurityModules/dedicatedHSMs. Dadurch werden bestimmte Berechtigungen für den HSM-Dienst für die Bereitstellung im Subnetz gewährt. Die Delegierung an dedizierte HSMs führt zu bestimmten Einschränkungen der Richtlinien für das Subnetz. Netzwerksicherheitsgruppen (Network Security Groups, NSGs) und User-Defined Routen (UDRs) werden derzeit für delegierte Subnetze nicht unterstützt. Daher kann ein Subnetz, sobald es an dedizierte HSMs delegiert wurde, nur noch zur Bereitstellung von HSM-Ressourcen verwendet werden. Die Bereitstellung anderer Kundenressourcen in das Subnetz schlägt fehl. Es gibt keine Anforderung, wie groß oder klein das Subnetz für dedizierte HSM sein sollte, aber jedes HSM-Gerät verbraucht eine private IP, daher sollte sichergestellt werden, dass das Subnetz groß genug ist, um so viele HSM-Geräte wie erforderlich für die Bereitstellung aufzunehmen.

ExpressRoute-Gateway

Eine Anforderung der aktuellen Architektur ist die Konfiguration eines ExpressRoute-Gateways im Subnetz des Kunden, in dem ein HSM-Gerät platziert werden muss, um die Integration des HSM-Geräts in Azure zu ermöglichen. Das ExpressRoute-Gateway kann nicht für die Verbindung von lokalen Standorten mit den HSM-Geräten der Kunden in Azure verwendet werden.

Verbinden Ihrer lokalen IT mit Azure

Wenn Sie cloudbasierte Ressourcen erstellen, ist das Herstellen einer privaten Verbindung mit lokalen IT-Ressourcen eine typische Anforderung. Bei Azure Dedicated HSM-Bereitstellungen dienen solche Verbindungen in erster Linie den HSM-Clientsoftwareanforderungen für die Gerätekonfiguration, Sicherungsvorgänge und das Abrufen von Protokollen von HSMs zur Analyse.

Wenn Sie Konnektivitätsoptionen auswählen, stellt die Art der Verbindung einen wichtigen Entscheidungspunkt dar. Standort-zu-Standort-VPN bietet die größte Flexibilität, insbesondere wenn mehrere lokale Ressourcen eine sichere Kommunikation mit Azure-Cloudressourcen einschließlich HSMs benötigen. Die Implementierung eines Standort-zu-Standort-VPN erfordert, dass Organisationen ein VPN-Gerät bereitstellen, um die Verbindung zu erleichtern. Alternativ funktionieren Point-to-Site-VPN-Verbindungen gut, wenn nur ein einzelner lokaler Endpunkt vorhanden ist, z. B. eine Verwaltungsarbeitsstation.

Weitere Informationen zu Konnektivitätsoptionen finden Sie unter VPN-Gatewayplanungsoptionen.

Point-to-Site-VPN

Ein virtuelles privates Point-to-Site-Netzwerk ist die einfachste Form der sicheren Verbindung zu einem einzelnen lokalen Endpunkt. Dies kann relevant sein, wenn Sie nur über eine einzige Verwaltungsarbeitsstation für azure-basierte dedizierte HSMs verfügen.

Standort-zu-Standort-VPN-Verbindung

Ein standortbasiertes virtuelles privates Netzwerk ermöglicht eine sichere Kommunikation zwischen azure-basierten dedizierten HSMs und Ihrer lokalen IT-Infrastruktur. Organisationen implementieren solche Verbindungen häufig bei der Wartung einer lokalen Sicherungseinrichtung für HSMs, da der sichere Tunnel erforderliche Datenübertragungen für Sicherungsvorgänge zwischen beiden Umgebungen unterstützt.

Verbinden virtueller Netzwerke

Eine typische Bereitstellungsarchitektur für dedicated HSM beginnt mit einem einzelnen virtuellen Netzwerk und einem entsprechenden Subnetz, in dem die HSM-Geräte erstellt und bereitgestellt werden. Innerhalb derselben Region gibt es möglicherweise mehr virtuelle Netzwerke und Subnetze für Anwendungskomponenten, die das dedizierte HSM nutzen. Um die Kommunikation über diese Netzwerke zu ermöglichen, verwenden wir Virtual Network Peering.

Peering in virtuellen Netzwerken

Wenn mehrere virtuelle Netzwerke in einer Region vorhanden sind, die auf die Ressourcen der anderen zugreifen müssen, erstellt Virtual Network Peering sichere Kommunikationskanäle zwischen ihnen. Virtuelle Netzwerk-Peering bietet nicht nur sichere Kommunikation, sondern stellt auch Verbindungen mit geringer Latenz und hoher Bandbreite zwischen den Ressourcen in Azure sicher.

Herstellen einer Verbindung zwischen Azure-Regionen

Die HSM-Geräte haben die Möglichkeit, über Softwarebibliotheken Datenverkehr zu einem alternativen HSM umzuleiten. Die Umleitung des Datenverkehrs ist hilfreich, wenn Geräte ausfallen oder der Zugriff auf ein Gerät verloren geht. Fehlerszenarien auf regionaler Ebene können verringert werden, indem HSMs in anderen Regionen bereitgestellt und die Kommunikation zwischen virtuellen Netzwerken in allen Regionen ermöglicht wird.

Regionsübergreifende HA mit VPN-Gateway

Für global verteilte Anwendungen oder für regionale Failoverszenarien mit hoher Verfügbarkeit ist es erforderlich, virtuelle Netzwerke über Regionen hinweg zu verbinden. Mit Azure Dedicated HSM können Hohe Verfügbarkeit mithilfe eines VPN-Gateways erreicht werden, das einen sicheren Tunnel zwischen den beiden virtuellen Netzwerken bereitstellt. Weitere Informationen zu Vnet-zu-Vnet-Verbindungen mit VPN-Gateway finden Sie im Artikel " Was ist VPN-Gateway?

Netzwerkeinschränkungen

Netzwerksicherheitseinschränkungen

Die HSM-Netzwerkschnittstellenkarte (NIC), die sich innerhalb des dedizierten HSM-VNet befindet, kann aufgrund von Subnetzdelegierungsanforderungen keine Netzwerksicherheitsgruppen (Network Security Groups, NSGs) oder benutzerdefinierte Routen (USER Defined Routes, UDRs) verwenden. Dies führt zu einer wichtigen Sicherheitsüberlegung: Sie können keine Standard-Ablehnungsrichtlinien direkt aus der Perspektive des dedizierten HSM VNet implementieren. Stattdessen muss die Sicherheit implementiert werden, indem der Zugriff von bestimmten Netzwerksegmenten auf den dedizierten HSM-Dienst über alternative Methoden explizit zugelassen wird.

Durch das Hinzufügen der NVA-Proxylösung (Network Virtual Appliances) kann auch eine NVA-Firewall im Transit-/DMZ-Hub logisch vor der HSM-NIC platziert werden, wodurch die erforderliche Alternative zu NSGs und UDRs bereitgestellt wird.

Lösungsarchitektur

Für dieses Netzwerkdesign sind die folgenden Elemente erforderlich:

1. Ein Transit- oder DMZ-Hub-VNet mit einer NVA-Proxy-Ebene. Idealerweise sind zwei oder mehr NVAs vorhanden.
2. Ein ExpressRoute-Schaltkreis mit aktiviertem privatem Peering und einer Verbindung mit dem Transithub-VNet.
3. VNet-Peering zwischen dem Transit-Hub-VNet und dem Dedicated HSM-VNet.
4. Eine NVA-Firewall oder Eine Azure-Firewall kann bereitgestellt werden, um DMZ-Dienste im Hub als Option anzubieten.
5. Zusätzliche Workload-Spoke-VNets können mit dem Hub-VNet gepeert werden. Der Gemalto-Client kann über das Hub-VNet auf den dedizierten HSM-Dienst zugreifen.

Da durch das Hinzufügen der NVA-Proxylösung auch eine NVA-Firewall im Transit-/DMZ-Hub logisch vor der HSM-NIC platziert werden kann und somit die erforderlichen Standardverweigerungsrichtlinien bereitgestellt werden. In unserem Beispiel verwenden wir die Azure-Firewall für diesen Zweck und benötigen die folgenden Elemente:

1. Eine Azure-Firewall, die im Subnetz "AzureFirewallSubnet" im DMZ-Hub-VNet bereitgestellt wird
2. Eine Routingtabelle mit einem UDR, der den Datenverkehr, der zum privaten Azure ILB-Endpunkt führt, zur Azure-Firewall leitet. Diese Routingtabelle wird auf das GatewaySubnet angewendet, in dem sich das virtuelle ExpressRoute-Gateway des Kunden befindet.
3. Netzwerksicherheitsregeln in der Azure Firewall, um die Weiterleitung zwischen einem vertrauenswürdigen Quellbereich und dem privaten Endpunkt des Azure ILB, der an TCP-Port 1792 lauscht, zuzulassen. Diese Sicherheitslogik fügt die notwendige "Default Deny"-Richtlinie für den Dedicated HSM-Dienst hinzu. Dies bedeutet, dass nur vertrauenswürdige QUELL-IP-Bereiche im dedizierten HSM-Dienst zulässig sind. Alle anderen Bereiche werden verworfen.
4. Eine Routing-Tabelle mit einer UDR, die den Datenverkehr in Richtung on-premises in die Azure Firewall leitet. Diese Routingtabelle wird auf das NVA-Proxysubnetz angewendet.
5. Ein NSG, das auf das Proxy-NVA-Subnetz angewendet wird, um nur dem Subnetzbereich der Azure Firewall als Quelle zu vertrauen und nur die Weiterleitung an die HSM NIC-IP-Adresse über TCP-Port 1792 zuzulassen.

Alternative zu UDRs

Die erwähnte NVA-Tier-Lösung funktioniert als Alternative zu UDRs. Es gibt einige wichtige Punkte zu beachten.

1. Network Address Translation sollte auf NVA konfiguriert werden, damit der Rückverkehr ordnungsgemäß weitergeleitet werden kann.
2. Kunden sollten die Client-IP-Check in Luna HSM-Konfiguration deaktivieren, um VNA für NAT zu verwenden. Die folgenden Befehle dienen als Beispiel.

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. Stellen Sie UDRs für eingehenden Datenverkehr in der NVA-Ebene bereit.
2. Je nach Entwurf initiiert HSM-Subnetze keine ausgehende Verbindungsanforderung auf der Plattformebene.

Alternative zur Verwendung des globalen VNET-Peerings

Es gibt eine Reihe von Architekturen, die Sie als Alternative zu globalen VNet-Peering verwenden können.

1. Verwenden Sie die Vnet-zu-Vnet-VPN-Gateway-Verbindung
2. Verbinden Sie das HSM-VNET mit einem anderen VNET über eine ER-Verbindung. Dies funktioniert am besten, wenn ein direkter On-Premises-Pfad erforderlich ist oder eine VPN- oder VNET-Verbindung.

HSM mit direkter ExpressRoute-Konnektivität

Nächste Schritte

• Häufig gestellte Fragen
• Unterstützungsmöglichkeiten
• Hohe Verfügbarkeit
• Physische Sicherheit
• Überwachung
• Bereitstellungsarchitektur