Zuverlässigkeit und Azure Virtual Network
Azure Virtual Network ist ein grundlegender Baustein für Ihr privates Netzwerk und ermöglicht es Azure-Ressourcen, sicher miteinander, mit dem Internet und lokalen Netzwerken zu kommunizieren.
Zu den wichtigsten Features von Azure Virtual Network gehören:
- Kommunikation mit Azure-Ressourcen
- Kommunikation mit dem Internet
- Kommunikation mit lokalen Ressourcen
- Filtern des Netzwerkdatenverkehrs
Weitere Informationen finden Sie unter Was ist Azure Virtual Network?
Informationen dazu, wie Azure Virtual Network eine zuverlässige Workload unterstützt, finden Sie in den folgenden Themen:
- Tutorial: Verschieben von Azure-VMs zwischen Regionen
- Schnellstart: Erstellen eines virtuellen Netzwerks im Azure-Portal
- Virtuelles Netzwerk: Geschäftskontinuität
Überlegungen zum Entwurf
Das Virtual Network (VNET) umfasst die folgenden Entwurfsüberlegungen für eine zuverlässige Azure-Workload:
- Die Überlappung von IP-Adressräumen zwischen lokalen und Azure-Regionen führt zu erheblichen Konflikten.
- Während nach der Erstellung ein Virtual Network Adressraum hinzugefügt werden kann, erfordert dieser Prozess einen Ausfall, wenn der Virtual Network bereits über Peering mit einem anderen Virtual Network verbunden ist. Ein Ausfall ist erforderlich, da das Virtual Network Peering gelöscht und neu erstellt wird.
- Die Größenänderung von virtuellen Netzwerken mit Peering befindet sich in der öffentlichen Vorschau (20. August 2021).
- Einige Azure-Dienste erfordern dedizierte Subnetze, z. B.:
- Azure Firewall
- Azure Bastion
- Gateway des virtuellen Netzwerks
- Subnetze können an bestimmte Dienste delegiert werden, um Instanzen des betreffenden Diensts im Subnetz zu erstellen.
- Azure reserviert fünf IP-Adressen in jedem Subnetz, die bei der Größenanpassung virtueller Netzwerke und eingeschlossener Subnetze berücksichtigt werden sollten.
Checkliste
Haben Sie Azure Virtual Network unter Berücksichtigung der Zuverlässigkeit konfiguriert?
- Verwenden Sie Azure DDoS Standard Protection Plans, um alle öffentlichen Endpunkte zu schützen, die in virtuellen Netzwerken des Kunden gehostet werden.
- Unternehmenskunden müssen die IP-Adressierung in Azure planen, um sicherzustellen, dass es keinen überlappenden IP-Adressraum für die betrachteten lokalen Standorte und Azure-Regionen gibt.
- Verwenden Sie IP-Adressen aus der Adresszuordnung für private Internets (Rfc) 1918).
- In Umgebungen mit eingeschränkter Verfügbarkeit von privaten IP-Adressen (RFC 1918) sollten Sie IPv6 verwenden.
- Erstellen Sie keine unnötig großen virtuellen Netzwerke (z. B.
/16
), um sicherzustellen, dass ip-Adressraum nicht unnötig verschwendet wird. - Erstellen Sie keine virtuellen Netzwerke, ohne den erforderlichen Adressraum im Voraus zu planen.
- Verwenden Sie keine öffentlichen IP-Adressen für virtuelle Netzwerke, insbesondere dann, wenn die öffentlichen IP-Adressen nicht dem Kunden gehören.
- Verwenden Sie VNET-Dienstendpunkte, um den Zugriff auf Azure-PaaS-Dienste (Platform-as-a-Service) aus einem Kunden-VNET zu schützen.
- Verwenden Sie zum Beheben von Datenexfiltrationsproblemen mit Dienstendpunkten die Filterung virtueller Netzwerkgeräte (Network Virtual Appliance, NVA) und VNet-Dienstendpunktrichtlinien für Azure Storage.
- Implementieren Sie nicht die Tunnelerzwingung, um die Kommunikation zwischen Azure und Azure-Ressourcen zu ermöglichen.
- Zugreifen auf Azure PaaS-Dienste aus der lokalen Umgebung über privates ExpressRoute-Peering.
- Verwenden Sie ExpressRoute mit Microsoft Peering, wenn keine Datenexfiltration vorliegt, um von lokalen Netzwerken aus auf Azure PaaS-Dienste zuzugreifen, wenn VNET-Einschleusung oder Private Link nicht verfügbar sind.
- Replizieren Sie keine Konzepte und Architekturen des lokalen Umkreisnetzwerks (auch bekannt als DMZ, demilitarisierte Zone und überprüftes Subnetz) in Azure.
- Stellen Sie sicher, dass die Kommunikation zwischen Azure PaaS-Diensten, die in eine Virtual Network eingefügt wurden, innerhalb der Virtual Network mithilfe von benutzerdefinierten Routen (User-Defined Routes, UDRs) und Netzwerksicherheitsgruppen (NSGs) gesperrt ist.
- Verwenden Sie keine VNET-Dienstendpunkte, wenn Probleme mit der Datenexfiltration vorliegen, es sei denn, es wird eine NVA-Filterung verwendet.
- Aktivieren Sie VNET-Dienstendpunkte nicht standardmäßig in allen Subnetzen.
Konfigurationsempfehlungen
Berücksichtigen Sie die folgenden Empfehlungen, um die Zuverlässigkeit beim Konfigurieren eines Azure-Virtual Network zu optimieren:
Empfehlung | BESCHREIBUNG |
---|---|
Erstellen Sie keine virtuellen Netzwerke, ohne den erforderlichen Adressraum im Voraus zu planen. | Das Hinzufügen des Adressraums führt zu einem Ausfall, sobald eine Virtual Network über Virtual Network Peering verbunden ist. |
Verwenden Sie VNET-Dienstendpunkte, um den Zugriff auf Azure-PaaS-Dienste (Platform-as-a-Service) aus einem Kunden-VNET zu schützen. | Nur, wenn Private Link nicht verfügbar ist und keine Datenexfiltrationsbedenken vorliegen. |
Zugreifen auf Azure PaaS-Dienste aus der lokalen Umgebung über privates ExpressRoute-Peering. | Verwenden Sie entweder die VNET-Einschleusung für dedizierte Azure-Dienste oder Azure Private Link für verfügbare freigegebene Azure-Dienste. |
Verwenden Sie ExpressRoute mit Microsoft Peering, wenn keine Datenexfiltration vorliegt, um von lokalen Netzwerken aus auf Azure PaaS-Dienste zuzugreifen, wenn VNET-Einschleusung oder Private Link nicht verfügbar sind. | Verhindert die Übertragung über das öffentliche Internet. |
Replizieren Sie keine Konzepte und Architekturen des lokalen Umkreisnetzwerks (auch bekannt als DMZ, demilitarisierte Zone und überprüftes Subnetz) in Azure. | Kunden können in Azure ähnliche Sicherheitsfunktionen wie lokal erhalten, aber die Implementierung und Architektur müssen an die Cloud angepasst werden. |
Stellen Sie sicher, dass die Kommunikation zwischen Azure PaaS-Diensten, die in eine Virtual Network eingefügt wurden, innerhalb der Virtual Network mithilfe von benutzerdefinierten Routen (User-Defined Routes, UDRs) und Netzwerksicherheitsgruppen (NSGs) gesperrt ist. | Azure PaaS-Dienste, die in eine Virtual Network injiziert wurden, führen weiterhin Vorgänge auf Verwaltungsebene mit öffentlichen IP-Adressen aus. |