Auf welche Weise wechseln wir zu einem expliziten Ansatz der öffentlichen Vernetzung.
Heute werde ich die Gründe und Hintergründe für die Außerbetriebnahme der standardmäßigen ausgehenden Zugriffskonnektivität sowie die notwendigen Vorbereitungen dafür erläutern.
Erstens: Lassen wir uns nicht davon abhalten, jetzt zu handeln, nur weil es beim Schreiben 12 Monate und 11 Tage zurückliegt. Die öffentlichen IP-Adressen der Basis-SKU sowie die Azure-Load Balancer der Basis-SKU werden derzeit ebenfalls außer Betrieb genommen. Daher ist der Außerdienststellungstermin am 30. September 2025 ein wichtiger Termin im Azure-Netzwerk.
Dies ist eine bedeutende Änderung, die in einigen Fällen eine Neugestaltung der Architektur erfordert. Es ist empfehlenswert, diese Änderungen jetzt zu planen, bevor wir möglicherweise in 12 Monaten eine komplexere Umgebung haben.
Was geschieht und warum?
Die Antwort auf diese Frage lautet Sicherheit. Bisher konnten wir bei der Erstellung einer neuen virtuellen Azure-Maschine auf das Internet und alle Azure-Dienste zugreifen, die einen öffentlichen Endpunkt verwenden. Dies erfolgt über einen standardmäßigen ausgehenden Zugriff. Wenn wir also keine explizite Methode für ausgehende Verbindungen einrichten, verwenden wir stattdessen eine implizite dynamische öffentliche IP-Adresse auf die virtuelle Maschine. Dies diente vor allem der Benutzerfreundlichkeit, um die Nutzung von Azure-Diensten schnell und ohne großen Aufwand zu ermöglichen und eine Verbindung zu über das Internet zugänglichen Diensten herzustellen.
Moderne Bedrohungen haben jedoch zu einem Umdenken in dieser Herangehensweise geführt. Microsoft und andere führende Cloud-Anbieter verfolgen einen Ansatz, bei dem die Sicherheit standardmäßig gewährleistet ist. Dies bedeutet, dass wir bald eine ausgehende Verbindungsroute für alle neuen virtuellen Maschinen konfigurieren müssen, falls unsere virtuellen Maschinen dies erfordert.
Zunächst einmal wird es sicherer sein, aber es kann durchaus vorkommen, dass wir virtuellen Maschinenressourcen aus irgendeinem Grund neu erstellt werden müssen.
Einige Beispiele dafür sind:
- Wiederherstellen einer virtuellen Maschine aus einem Backup-System.
- Verschieben die virtuelle Maschine in eine Verfügbarkeitszone.
- Eine Replikation der virtuellen Maschinen in eine andere Azure-Region.
- Eine vertikale Skalierung von virtuellen Computern in einem VM-Skalierungssatz.
Irgendwann müssen wir vermutlich auch eine explizite ausgehende Konnektivität für bestehende virtuelle Maschinen einführen. Es wird empfohlen, dies sofort zu planen und noch vor Ablauf der Frist durchzuführen. Eine zusätzliche Modifikation betrifft nur virtuelle Azure-Computer. PaaS-Dienste arbeiten weiterhin mit expliziten Verfahren für ausgehende Verbindungen.
Welche Optionen habe ich für einen gezielten ausgehenden Zugriff?
In der Dokumentation von Microsoft finden wir verschiedene Optionen für die Bereitstellung einer gezielten ausgehenden Verbindung. Das grundlegende Konzept besteht darin, Source Network Address Translation (SNAT) zu verwenden, um den Internetverkehr über eine öffentliche IP-Adresse zu leiten, die wir besitzen, verwalten und über eine der folgenden Optionen zuweisen:
„Fügen wir einer Netzwerkkarte direkt eine öffentliche IP-Adresse hinzu!“
Was habe ich gerade empfohlen ???
Bitte nicht auf diesen Punkt achten. Klar, wir werden immer Situationen haben, in denen wir eine Public-IP benötigen, aber aus Sicherheitsgründen ist es überhaupt nicht empfohlen.
Aber falls wir eine wirklich brauchen, bitte beachten, dass die öffentlichen IP-Adressen der Basis-SKU am 30. September 2025 außer Betrieb genommen wird. Wir müssen die Standard-SKU vorher aktualisieren.
Den ausgehenden Datenverkehr über einen öffentlichen Azure Load Balancer Routen.
Eine gute Option ist die Erschöpfung des SNAT-Ports, wenn wir viele gleichzeitige ausgehende Verbindungen haben und es einige spezifische Konfigurationsanforderungen gibt, wie in den Hinweisen unten beschrieben.
Hinweis:
- Virtuelle Computer müssen im Back-End-Pool des Azure Load Balancers als NIC-Konfiguration angeschlossen werden.
- Darüber hinaus müssen wir bei Verwendung der Basis-SKU eine Lastenausgleichsregel oder bei Verwendung des Standard-SKU Azure Load Balancers eine Ausgangsregel zuweisen.
- Der Betrieb der Basis-SKU Azure Load Balancer wird am 30. September 2025 eingestellt.
Ausgehenden Daten über ein NAT-Gateway
Die von Microsoft empfohlene Methode ist einfach zu konfigurieren, aber derzeit kann der Dienst bei Bedarf nicht über Verfügbarkeitszonen hinweg skaliert werden.
Ausgehenden Datenverkehr über eine Azure Firewall oder ein virtuelle Appliance
Dies ist die sicherste Option, da der gesamte ausgehende Datenverkehr von der Firewall gefiltert wird. Die Konfiguration ist etwas komplizierter, da wir benutzerdefinierte Routen für die virtuelle Maschine erstellen und den nächsten Hop des Internetverkehrs zur virtuellen Maschine bestimmen müssen. Dies ist jedoch im Allgemeinen die sicherste (und teuerste) Option.
Es ist wichtig, die richtigen Optionen für die eigene Umgebung zu wählen. Ich empfehle, die Architektur vorher zu planen und zu ändern, da je länger wir warten, desto komplexer wird die Umgebung mit der Zeit.
Analyse der Ressourcen die derzeit standardmäßig den ausgehenden Zugriff verwenden.
Ich gehe davon aus, dass Microsoft ein Verfahren entwickeln wird, um die betroffenen virtuellen Azure-Maschinen zu identifizieren. Tatsächlich habe ich bei meinen Recherchen ein Parameter namens „defaultOutboundAccess“ in der Netzwerkschnittstellenressource des „Resource Graph Explorers“ entdeckt. Es scheint, als hätte Microsoft noch nicht mit der Ausfüllung dieses Werts begonnen, aber man sollte ihn im Auge behalten.
Zunächst habe ich eine KQL-Abfrage verfasst, die hilft die Ressourcen zu identifizieren, bei denen derzeit der standardmäßige ausgehende Zugriff verwendet wird.
Die KQL-Abfrage ruft erstmal alle Netzwerkschnittstellenressourcen (NIC) virtueller Maschinen im ausgewählten Bereich ab. Anschließend wird überprüft, ob dieser NIC eine öffentliche IP-Adresse hat, ob sie Teil eines öffentlichen Azure Load Balancer-Back-End-Pools ist, der sich in einem Subnetz befindet, das einem NAT-Gateway zugewiesen ist, oder ob es sich in einem Subnetz befindet, das über eine Default Route über eine virtuelle Appliance vom Typ „Next Hop“ verfügt.
Einige zusätzliche Info zur Verwendung:
- Wenn auf eine virtuelle Maschine mehrere Netzwerkkarten vorhanden sind, werden diese durch die Abfrage individuell beurteilt.
- Die Azure Load Balancer-Prüfung erkennt nur NIC-zugewiesene Back-End-Pool-Konfigurationen. IP-Adressbasierte Konfigurationen verwenden jedoch aufgrund eines bekannten Problems mit diesem Konfigurationstyp weiterhin den standardmäßigen ausgehenden Zugriff.
- Für die NVA-Prüfung prüfe ich, ob im NIC-Subnetz eine Standardroute von 0.0.0.0/0 vorhanden ist und ob sie den Next Hop Typ „Virtual Appliance“ hat. Wenn wir spezifischere Internetrouten verwenden oder Ihr Internet-Routing falsch konfiguriert ist, wird diese Abfrage nicht geprüft.
Haftungsausschluss: Für die Richtigkeit der Ergebnisse, die mit dieser Abfrage erzielt werden, nehme ich nicht in Verantwortung. Ausschließlich dient diese Abfrage dazu, Fälle zu identifizieren, in denen der Standard-Ausgangszugriff genutzt wird. Bitte nutzen Sie die Informationen, die Sie durch diese Abfrage erhalten haben, auf Ihr eigenes Risiko und nach Ihrem eigenen Ermessen.
resources
| where type == "microsoft.network/networkinterfaces"
| mv-expand ipconfig = properties.ipConfigurations
| mv-expand backendPool = ipconfig.properties.loadBalancerBackendAddressPools
| extend backendPoolId = tostring(backendPool.id)
| where isnotempty(properties.virtualMachine)
| extend vmIdArray = split(properties.virtualMachine, "/")
| extend vmName = tostring(vmIdArray[-1])
| extend virtualMachine = vmName
| extend subnetArray = split(tostring(ipconfig.properties.subnet), "/")
| extend virtualNetwork = tostring(subnetArray[8])
| extend subnetName = tostring(ipconfig.properties.subnet)
| extend subnet = tostring(subnetArray[10])
| extend pipArray = split(tostring(ipconfig.properties.publicIPAddress.id), "/")
| extend publicIp = tostring(pipArray[8])
| extend publicIp = iff(isnotempty(publicIp), "Yes", "No")
| project id, resourceGroup, nicName = name, virtualMachine, virtualNetwork, subnetName, subnet, publicIp, backendPoolId
| join kind=leftouter (
resources
| where type == "microsoft.network/loadbalancers"
| mv-expand backendPools = properties.backendAddressPools
| extend hasPublicIpConfig = iff(isnotempty(properties.frontendIPConfigurations), "Yes", "No")
| where hasPublicIpConfig == "Yes"
| project lbName = name, backendPoolId = tostring(backendPools.id)
) on backendPoolId
| extend loadBalancer = iff(isnotempty(lbName), "Yes", "No")
| join kind=leftouter (
resources
| where type == "microsoft.network/natgateways"
| where array_length(properties['subnets']) > 0
| mv-expand subnetName = properties.subnets
| extend subnetName = tostring(subnetName)
| project subnetName, natGwName = name
) on subnetName
| extend natGateway = iff(isnotempty(natGwName), "Yes", "No")
| join kind=leftouter (
resources
| where type == "microsoft.network/routetables"
| mv-expand rules = properties.routes
| extend addressPrefix = tostring(rules.properties.addressPrefix)
| extend nextHopType = tostring(rules.properties.nextHopType)
| extend nextHopIpAddress = tostring(rules.properties.nextHopIpAddress)
| mv-expand subnetName = properties.subnets
| extend subnetName = tostring(subnetName)
| where addressPrefix == "0.0.0.0/0"
| where nextHopType == "VirtualAppliance"
| project subnetName, nextHopIpAddress
) on subnetName
| extend defaultRouteisNVA = iff(isnotempty(nextHopIpAddress), "Yes", "No")
| extend defaultOutboundAccess = iff(publicIp == "No" and loadBalancer == "No" and natGateway == "No" and defaultRouteisNVA == "No", "Yes", "No")
| project id, resourceGroup, nicName, virtualMachine, virtualNetwork, subnet, publicIp, loadBalancer, natGateway, defaultRouteisNVA, defaultOutboundAccess
| order by defaultOutboundAccessIm Azure Resource Graph Explorer des Azure-Portals können wir diese Abfrage direkt ausführen und sollten eine Tabellenausgabe erhalten, die dem nachfolgenden Beispiel ähnelt.
Jede Zeile in der Tabelle beschreibt eine Netzwerkschnittstelle (NIC) und ihre Eigenschaften, einschließlich des NIC-Namens, der zugehörigen virtuellen Maschine, des virtuellen Netzwerks, des Subnetzes sowie des Vorhandenseins einer öffentlichen IP-Adresse, eines Lastenausgleichs, eines NAT-Gateways und einer Standardroute zu einer virtuellen Appliance (NVA). Für jede Eigenschaft gibt ein Wert „Ja“ oder „Nein“ an. Die Spalte „defaultOutboundAccess“ bietet eine Gesamtauswertung des standardmäßigen Status des ausgehenden Zugriffs.
Wie wird es Zukünftig aussehen
Wie können wir uns für die Zukunft absichern und sicherstellen, dass wir nicht in die Falle tappen, neue virtuelle Maschinen einzusetzen, die in Zukunft den standardmäßigen ausgehenden Zugriff nutzen, nachdem wir nun hoffentlich die Umgebung identifiziert und für die defaultOutboundAccess vorbereitet haben?
Microsoft hat hierfür eine neue Funktion veröffentlicht „Private Subnets“
Das Konzept ist recht einfach: Virtuelle Maschinen in einem privaten Subnetz können kein standardmäßiger ausgehender Zugriff verwenden, um eine Verbindung zum Internet herzustellen. wir müssen eine der zuvor erwähnten expliziten Methoden verwenden, wenn ein Internetzugang erforderlich ist.
Hinweis: Bei Windows-Maschinen ist zu beachten, dass wir für die Funktion von Windows-Aktivierung und Windows-Updates einen Internetzugang bereitstellen müssen.
Es gibt derzeit keine Möglichkeit, ein bestehendes Subnetz in ein privates Subnetz umzuwandeln. Wir können jedoch ein neues privates Subnetz in einem bestehenden virtuellen Netzwerk erstellen und dann die Netzwerkkarte der virtuellen Maschine in dieses private Subnetz verlegen. Das kann mit PowerShell oder CLI ganz einfach erreicht werden.
Im folgenden PowerShell Code-Abschnitt wird ein neues privates Subnetz mit einem Adressraum von 10.0.0.0/24 als Beispiel, in einem vorhandenen virtuellen Netzwerk. Bitte beachten, dass das Flag „DefaultOutboundAccess“ auf „$false“ gesetzt ist.
$vnet = Get-AzVirtualNetwork -ResourceGroupName privatesubnettest -Name vnet-privatesubnettest
Add-AzVirtualNetworkSubnetConfig -Name "privateSubnet" -VirtualNetwork $vnet
-AddressPrefix "10.7.1.0/24" -DefaultOutboundAccess $false
$vnet | Set-AzVirtualNetworkFazit
Um sicherzustellen, dass wir die volle Kontrolle über die Verwaltung sicherer ausgehender Verbindungen für die virtuellen Maschinen haben, wird dies alles eingeführt, obwohl es umständlich erscheint. Die Frist gibt uns genügend Zeit, um sich darauf vorzubereiten. Ich möchte jedoch noch einmal betonen, dass es nichts ist, womit man bis zur letzten Minute warten sollte.
Beginnen wir also mit der Planung noch heute.