Eine subtile Designbeschränkung bei der Implementierung privater Endpunkte in Microsoft Azure schafft ein unerwartetes Denial-of-Service-Risiko (DoS-Risiko) für Cloud-Umgebungen, die für sichere Konnektivität stark auf Private Link setzen.
Das DNS-Verhalten von Azure bei privaten Endpunkten und privaten DNS-Zonen über mehrere virtuelle Netzwerke (VNETs) hinweg kann die Namensauflösung unterbrechen und Ausfälle verursachen, selbst wenn der Dienst und sein öffentlicher Endpunkt weiterhin funktionieren.
Der Fehler „… könnte Azure-Ressourcen Denial-of-Service-Angriffen (DoS-Angriffen) aussetzen“, erklärten Forscher von Palo Alto Networks’ Unit 42.
Das DNS-Problem privater Azure-Endpunkte
Im Kern geht es bei diesem Problem darum, wie Azure die DNS-Auflösung priorisiert, sobald eine private DNS-Zone mit einem virtuellen Netzwerk verknüpft ist.
Private Endpoints sollen den Datenverkehr aus dem öffentlichen Internet heraushalten, indem sie einem Azure-Dienst eine private IP-Adresse zuweisen und den Zugriff über das Azure-Backbone leiten.
Damit dies nahtlos funktioniert, setzt Azure auf private DNS-Zonen – etwa privatelink[.]blob[.]core[.]windows[.]net –, um den Hostnamen eines Dienstes in die richtige private Adresse aufzulösen.
In einer Standardbereitstellung enthält diese DNS-Zone die erforderlichen Einträge (typischerweise A-Einträge), sodass Workloads innerhalb des verbundenen Netzwerks den Dienstnamen in die IP-Adresse des privaten Endpunkts statt in den öffentlichen Endpunkt auflösen.
Die Probleme beginnen, wenn dieselbe private DNS-Zone über mehrere VNETs erweitert wird – insbesondere in Hub-and-Spoke- oder segmentierten Umgebungen, in denen nicht jedes Netzwerk über eine identische Abdeckung durch private Endpunkte verfügt.
Das Fehlermuster sieht im Allgemeinen so aus:
- In VNET2 wird ein privater Endpunkt erstellt, und Azure generiert eine mit diesem Endpunkt verknüpfte private DNS-Zone oder verwendet eine vorhandene.
- Anschließend wird die private DNS-Zone mit VNET1 verknüpft, um die Namensauflösung über Netzwerkgrenzen hinweg zu ermöglichen.
- VNET1 verfügt jedoch nicht über einen entsprechenden DNS-A-Eintrag für das betreffende Speicherkonto (oder den betreffenden Dienst).
Sobald diese Verknüpfung besteht, bevorzugt Azure DNS in VNET1 die private DNS-Zone bei der Auflösung dieses Hostnamens.
Fehlt der Eintrag, kann die Abfrage mit einer NXDOMAIN-ähnlichen Antwort fehlschlagen – der Name lässt sich dann überhaupt nicht auflösen.
Das Ergebnis ist ein Denial-of-Service-Zustand (DoS-Zustand), in dem Workloads in VNET1 plötzlich den Zugriff verlieren – obwohl die zugrunde liegende Azure-Ressource weiterhin fehlerfrei ist, der öffentliche Endpunkt unverändert geblieben ist und keine Firewallregeln angepasst wurden.
Das macht dieses Problem besonders folgenschwer: Der Ausfall wird vollständig durch das Verhalten von DNS verursacht, nicht dadurch, dass ein Angreifer die Ressource lahmlegt oder Produktionseinstellungen des Dienstes selbst verändert.
Eine einfache Änderung an VNET-Verknüpfungen oder Zonenbeziehungen kann die Konnektivität zwischen Umgebungen innerhalb von Sekunden unterbrechen.
Die Forscher stellten fest, dass diese Schwachstelle typischerweise in drei realen Szenarien auftritt:
- Versehentliche interne Fehlkonfiguration: Teams erweitern die Abdeckung durch private Endpunkte im Laufe der Zeit und führen unbeabsichtigt DNS-Konflikte ein, wenn sie Zonen über mehrere Netzwerke hinweg verknüpfen.
- Bereitstellungen durch Dritte: Sicherheitsanbieter oder Managed Services können private Endpunkte für Scans, Überwachung oder Integrationszwecke bereitstellen und dadurch unbeabsichtigt das DNS-Verhalten ändern sowie Produktionsdatenverkehr stören.
- Böswillige Aktivitäten durch Insider oder kompromittierte Administratoren: Ein Angreifer mit ausreichenden Azure-Berechtigungen könnte die Verknüpfung privater Endpunkte und DNS-Zonen gezielt missbrauchen, um den Zugriff zu blockieren – und so ein DoS-Ereignis auszulösen, ohne den Datenverkehr überfluten oder die Zielressource direkt ausnutzen zu müssen.
Die Auswirkungen können über einen einzelnen Ausfall hinausgehen, da Azure Storage die Grundlage für zahlreiche Dienste bildet, darunter Azure Functions, CI/CD-Pipelines und Anwendungen, die für Konfiguration und Zustand auf Blobs angewiesen sind.
Wenn DNS-Fehler den Zugriff auf den Speicher blockieren, können sich die Ausfälle ausweiten: Functions schlagen fehl, Bereitstellungen kommen zum Stillstand, und Systeme, die auf Key-Vault-Geheimnisse oder Container-Artefakte angewiesen sind, können ausfallen.
Abmilderung von DNS-Fehlern bei privaten Azure-Endpunkten
Organisationen müssen dieses DNS-Risiko von Private Link nicht als unvermeidbar hinnehmen.
Mit der richtigen Kombination aus DNS-Governance, Zugriffskontrollen und Überwachung können Teams die Wahrscheinlichkeit verringern, dass Auflösungsfehler zu Ausfällen werden.
- „Fallback auf das Internet“ (NxDomainRedirect) für VNET-Verknüpfungen privater DNS-Zonen aktivieren , um zu verhindern, dass NXDOMAIN-Fehler die Auflösung unterbrechen, und dabei den Sicherheitskompromiss abwägen, der durch die Zulassung eines Fallbacks auf öffentliche Endpunkte entsteht.
- Vollständige und korrekte private DNS-A-Einträge pflegen für alle Private-Link-fähigen Ressourcen in verknüpften Netzwerken, um Auflösungslücken zu vermeiden, die Ausfälle verursachen können.
- Die Namensauflösung privater Endpunkte zentralisieren und standardisieren – mithilfe von Azure Private Resolver oder benutzerdefinierten DNS-Servern mit bedingter Weiterleitung für privatelink.*-Zonen in Umgebungen mit mehreren VNETs und hybriden Umgebungen.
- Beschränken, wer private Endpunkte erstellen oder private DNS-Zonen ändern darf, indem RBAC nach dem Prinzip der geringsten Berechtigung verwendet wird; außerdem sollte eine Änderungskontrolle für Aktualisierungen der DNS- und Private-Link-Konfiguration eingerichtet werden.
- Den Wirkungsradius begrenzen, indem die Verknüpfung privater DNS-Zonen auf die VNETs beschränkt wird, die sie benötigen, und DNS-Zonen, wo angemessen, nach Umgebung oder Workload getrennt werden.
- Kontinuierlich prüfen und überwachen , welche Änderungen an privaten Endpunkten und privaten DNS vorgenommen werden – mithilfe von Azure Policy, Resource-Graph-Abfragen und Alarmen für riskante Änderungen an Verknüpfungen oder Spitzen bei NXDOMAIN-Antworten.
Zusammengenommen helfen diese Kontrollen Organisationen dabei, Private-Link-Bereitstellungen sicher zu halten und zugleich das Risiko DNS-bedingter Ausfälle zu verringern.
Private Link kann DoS-ähnliche Ausfälle auslösen
Dieses Problem erinnert daran, dass Cloud-Sicherheitskontrollen Verfügbarkeitsrisiken mit sich bringen können, wenn sie nicht mit einem konsequenten DNS-Design und entsprechender Governance einhergehen.
Azure Private Link reduziert die öffentliche Angriffsfläche, doch sein „Alles-oder-nichts“-DNS-Verhalten bedeutet, dass ein fehlender Eintrag oder eine weitreichende Zonenverknüpfung DoS-ähnliche Ausfälle auslösen kann.
Deshalb setzen Organisationen zunehmend auf Zero-Trust-Lösungen , die den Zugriff schützen, ohne sich ausschließlich auf Annahmen auf Netzwerkebene zu verlassen.