Ich möchte an die „Einstellung“ – hiermit ist kein „Configuration-Setting“, sondern der „EOL“ eines Azure-Services gemeint – des so genannten „standardmäßigen ausgehenden Zugriff für VMs in Azure“ erinnern. Ich meinen Kursen gehe ich regelmäßig auf die Thematik ein. Auch wenn Microsoft seit gefühlt mehreren Jahren auf kritische Termine wie diesen hinweist, irgendwann ist es dann doch soweit und ruckzuck ist aus März 2025 dann doch September geworden.
Der Termin 30.09 trifft übrigens auch noch für weitere thematisch verwandte Themen wie die Einstellung der Basic-SKU für öffentliche IP-Adressen und Azure-Loadbalancer zu. Während Letzteres den eingehenden Internet-Zugriff betrifft – ein leidiges Sicherheitsproblem für Azure-VMs, die aus dem Internet erreichbar sein sollen, auf das ich seit Jahren aufmerksam mache -, betrifft das Thema heute den ausgehenden Internetzugriff.
Bekanntlich kann – genau wie jeder private Server oder Client-Computer via NAT/Masquerading hinter der heimischen Fritzbox diese als Vehicel für Source-NAT nutzt – jede Azure-VM ausgehend mit dem Internet kommunizieren, auch wenn sie über keine öffentliche IP-Adresse verfügt. Microsoft nennt das Feature „Standardzugriff in ausgehender Richtung in Azure“. Microsoft klassifiziert diese Default-Eigenschaft als „implizite“ ausgehende Konnektivität und rät von deren Verwendung in produktiven Umgebungen selbst ab, denn die zugrundliegende virtuelle IP-Adresse (VIP) gehört Microsoft und kann sich ändern.
Es gibt aber auch andere Gründe, die gegen dieses implizite Verfahren sprechen:
- Nutzt Ihre VM mehrere virtuelle Netzwerkkarten, sind nämlich die Standard-IP-Adressen für ausgehenden Datenverkehr nicht für alle NICs identisch.
- Auch beim Hoch- oder Herunterskalieren von VM-Scalesets können sich die den einzelnen Instanzen zugewiesenen Standard-IP-Adressen für ausgehenden Datenverkehr ändern.
In produktiven Umgebungen sollten Kunden daher schon immer für „explizite“ ausgehende Internet-Konnektivität sorgen. Diese kann erfolgen mittels …
- Öffentlicher IP-Adresse
- Source-NAT-Regel in Verbindung mit einer Azure Firewall
- Source-NAT-Regel in Verbindung mit einem Azure Loadbalancer
- Azure NAT-Gateway
Spätestens ab September 2025 müssen Sie daher Ihre VM-basierten Workloads mit einer impliziten Methode ausstatten, wobei von der Variante „öffentliche IP-Adresse“ aus Sicherheitsgründen trotzdem abzuraten ist.
Sie können z. B. den Azure Advisor verwenden, um zu ermitteln, welche virtuellen Computer für Ihr Abonnement betroffen sind. Suchen Sie dazu im Abschnitt „Operational Excellence“ nach der Empfehlung „Hinzufügen einer expliziten ausgehenden Methode zum Deaktivieren des standardmäßigen ausgehenden Datenverkehrs“. Der Azure Advisor zeigt dann die spezifischen Netzwerkkarten aller VMs an, die den standardmäßigen ausgehenden Datenverkehr noch verwenden.
Weitere Azure-Dienste oder SKUs mit EOL identifizieren
Das war jetzt nur ein Beispiel für eine SKU (es betrifft in diesem Fall ja nicht den kompletten Dienst „Öffentliche IP-Adresse“), die in diesem Jahr ihr EOL erreicht. Zwar warnt Microsoft immer schon recht frühzeitig und regelmäßig (oft schon mehrere Jahre vorher), doch die uns Menschen innewohnende Aufschieberitis für irgendwann doch dazu, dass eine Nichtrektion oder Nichtbeachtung zu erheblichen Problemen führen kann. Daher ist es abgesehen von den proaktiven Warnungen von Microsoft immer eine gute Idee, sich aktiv über ablaufenden Dienste, SKUs oder Features auf dem Laufenden zu halten.
Ein Anlaufpunkt dazu ist das Service-Health-Dashboard im Azure Monitor der Abschnitt „Integritätsempfehlungen“.
In unserem Fall betrifft das Problem ja nur eine „Einstellungsänderung“, also der EOL eine spezifischen SKU. Möchten sich nach kompletten Diensten suchen, die in Zukunft „eingestellt“ werden, nutzen Sie die Filterfunktion. So können Sie in der deutschen Übersetzung nach „Problemuntertyp“ filtern und dort den Eintrag „Einstellung“ wählen. Hiermit ist wiederum nicht Einstellung im Sinne von „Setting“ gemeint sondern Einstellung im sinne von „Aufgabe“ oder „EOL“.
