[English]Microsoft will ab 30. September die Standardkonnektivität von ausgehenden Verbindungen bei VMs in Azure einstellen und auf neue Methoden umstellen.
Anzeige
Virtuellen Maschinen, die in einem virtuellen Netzwerk ohne eine definierte explizite Outbound-Methode erstellt wurden, erhalten in Microsoft Azure bisher eine öffentliche Standard-IP-Adresse zugewiesen. Dadurch kann die VM auf das öffentliche Netzwerk und auf andere Endpunkte (das Internet) zugreifen. Microsoft hat dies im Beitrag Default outbound access in Azure näher beschrieben.
Aber am 30. September 2025 ist damit Schluss, da Microsoft diese Fallback-Option aus Sicherheitsgründen beendet. Im Supportbeitrag Default outbound access in Azure hat Microsoft weitere Details verraten.
Nach dem 30. September 2025 werden neue virtuelle Netzwerke in Azure standardmäßig explizite Methoden für den ausgehenden Zugang benötigen, anstatt einen Fallback auf die Standardkonnektivität für den ausgehenden Zugang zu haben. Alle virtuellen Maschinen, die einen öffentlichen Endpunktzugang benötigen, müssen explizite ausgehende Konnektivitätsmethoden wie Azure NAT Gateway, ausgehende Azure Load Balancer-Regeln oder eine direkt verbundene öffentliche Azure-IP-Adresse verwenden.
Alle virtuellen Maschinen (bestehende oder neu erstellte) in bestehenden VNETs, die den standardmäßigen ausgehenden Zugriff verwenden, werden nach dieser Änderung weiterhin funktionieren. Es wird jedoch dringend empfohlen, auf eine explizite ausgehende Methode umzustellen, damit:
Anzeige
- Microsofts Workloads nicht durch Änderungen der öffentlichen IP-Adresse beeinträchtigt werden.
- Administratoren mehr Kontrolle darüber haben, wie sich Ihre VMs mit öffentlichen Endpunkten verbinden.
- VMs rückverfolgbare IP-Ressourcen verwenden, die dem Benutzer bzw. dem Unternehmen gehören.
Um kontrollierbarere und nachverfolgbare Internetverbindungen zu gewährleisten, stellen Sie alle vorhandenen VMs, die auf den standardmäßigen ausgehenden Zugriff angewiesen sind, auf eine explizite Methode der Konnektivität um.
Sofern die VMs auf Azure Cloud Services (erweiterter Support) bereitgestellt werden, sind diese davon nicht betroffen und Administratoren müssen keine Maßnahmen ergreifen. The Register hat hier ein Interview mit Aviatrix CPO Chris McHenry zu diesem Themenkomplex geführt.
Kommentar eines Lesers auf Facebook: "Das ist irgendwie totaler Mist. Sobald ein NAT Gateway eingebunden wird geht keine inbound Kommunikation per public IP mehr, die einer VM zugeordnet wurde."
Anzeige
;-) siehe auch hier:
https://www.borncity.com/blog/diskussion-allgemeines/#comment-221126
Naja die Zahl der böse Überraschten dürfte hoch sein, da viele WebDev sich bislang kaum Gedanken über Ihre outbound APIs gemacht haben. Die dürfen jetzt mitten in der Urlaubszeit hektisch schnell alles umstellen und prüfen. Nicht jede Web-App funktioniert durch einen Proxy auf Anhieb.
FunFact am Rande: Einige scheinen den Azure Bastion Host jetzt zu entdecken. Ich wette, den gibt es nicht umsonst ;-)
https://azure.microsoft.com/en-us/products/azure-bastion
Dabei ist der Azure Bastion Host nichts anderes als ein umgebrandeter und weg abstrahierter (für den User funktionsreduzierter) Apache Guacamole:
https://guacamole.apache.org/
Dann doch lieber bei dem Original bleiben (ohne Azure Cloud natürlich)
Dieser "freie Blick ins Mündungsfeuer" hat mich bei Azure schon immer gewundert, die anderen großen Cloud-Anbieter machen es nicht so. Dort muß man Außenanbindung zumindest einschalten, oft auch kostenpflichtig dazubuchen.
"Öffentliche" IP-Adressen gibt es nur endlich und ein paar Aussagen oben "NAT-Gateway" lassen mich vermuten, daß auch Microsofts Vorrat inzwischen aufgebraucht ist. Wer seine Applikation so konstruiert hat, daß sie eine öffentlich erreichbare IP-Adresse braucht, wird die vermutlich in Zukunft kostenpflichtig dazu buchen müssen.
Andererseits, wenn ich mir in letzter Zeit komplexere Phishing-Mails angeschaut habe, die uns erreichen, stand da recht häufig etwas in Azure gehostetes dahinter, z.B. Websites, die mit nachgebauten Login-Seiten Credentials abgreifen wollten. Vermutlich wurde das inzwischen auch Microsoft zuviel Abuse-Handling.