Öffentliches Netzwerk mit IP Restriktion - reicht das als Sicherheitsmaßnahme?

Ich kann mich noch gut erinnern: Vor ein paar Jahren kam ein Kunde von mir - ein großer, wirklich großer Pharmakonzern - mit einer Anfrage zum Thema Azure Security. Dabei ging es nicht primär um die Umsetzung eines Konzepts, sondern um die Beantwortung eines Fragenkatalogs für ein Security Audit. Der Konzern betrieb damals eine Reporting Anwendung für seine Produkte in der Azure Cloud. Per se war die Anwendung nichts Spektakuläres - eigentlich ein simples Frontend für die dahinterliegende Azure SQL Datenbank.

Doch die Aussagen, die ich dann hörte, schockierten mich.

"Da geht's ja eh nur um unsere Azure Services, oder?"

Die Azure SQL Datenbank des Kunden hatte lediglich eine IP Restriktion - zusätzlich war aber die Checkbox "Anderen Azure-Diensten und -Ressourcen den Zugriff auf diesen Server gestatten" aktiviert. Das IT Team war überzeugt, dass dieses Setup vollkommen sicher sei. Die Aussage dazu: "Najo, da geht's ja eh nur um unsere Azure Services aus unserem Tenant, oder?"

Ich bin aus allen Wolken gefallen. Ganz klar: NEIN! Diese Option gilt nicht nur für die Azure Services aus dem eigenen Tenant, sondern für alle in Azure betriebenen Services - unabhängig davon, welchem Tenant oder Kunden sie gehören. Anders gesagt: Die Datenbank war für jeden erreichbar, der irgendeine Ressource in Azure betreibt. Die einzige Barriere zwischen diesem riesigen Personenkreis und der teils kritischen Datenbank des Pharmakonzerns waren die SQL Zugangsdaten. Ein Leak dieser Zugangsdaten und Unbefugte hätten sich über einen beliebigen Azure Service Zugriff auf die Daten verschaffen können.

Leider höre ich das immer wieder von Kunden: Viele verlassen sich auf ihre Firewall Regeln und gehen davon aus, dass der Zugriff "anderer Azure Services" automatisch auf den eigenen Tenant beschränkt ist. Das ist aber schlichtweg falsch.

Fairerweise sei gesagt: Eine IP Restriktion an sich ist nicht verkehrt. Gerade in der App Entwicklung kann sie praktisch sein, um den eigenen Entwicklern aus dem Firmennetzwerk Zugriff auf die Datenbank zu geben.

Warum gerade jetzt? KI Agenten!

Doch warum dann dieser Blogpost? Ganz einfach: Wir steuern auf eine Ära zu, in der KI Agenten selbstständig arbeiten und auf Dienste und Ressourcen zugreifen können - manchmal ganz ohne unser Wissen. Firewall Regeln und Freigaben, die ursprünglich für eine effiziente Entwicklung oder für lokale Geräte gedacht waren, sind mittlerweile gefundenes Fressen für KI Agenten. Ein lokal laufendes Claude Code hat netzwerktechnisch genau dieselben Rechte wie der Entwickler, der es verwendet (außer ihr habt extrem intelligente Appliances und Firewalls, die solche Muster erkennen und unterbinden - da muss dann aber auch die entsprechende Marie vorhanden sein ;)).

Was tun? Private Endpoint statt öffentlichem Zugriff

Im besten Fall habt ihr den öffentlichen Netzwerkzugriff an eurem Azure SQL Server komplett deaktiviert:

Stattdessen setzt ihr auf privaten Zugriff über einen dedizierten Netzwerk Endpunkt (Private Endpoint) in einem virtuellen Netzwerk:

Mit eurem privaten Endpunkt ist dann das entsprechende virtuelle Netzwerk verbunden:

In anderen Azure Ressourcen, zum Beispiel einer Web App, könnt ihr den ausgehenden Traffic dann über die VNet Integration in dieses virtuelle Netzwerk leiten:

Achtung: Dafür müsst ihr entsprechende Subnetze anlegen und das Routing korrekt definieren.

Der häufigste Stolperstein: DNS

Ganz wichtig und gern vergessen: die Private DNS Zone privatelink.database.windows.net. Sie muss mit eurem virtuellen Netzwerk verknüpft sein, damit der Servername eurer Datenbank auf die private IP des Endpunkts aufgelöst wird. Fehlt sie, löst eure Web App weiterhin die öffentliche IP auf - und die Verbindung schlägt fehl, sobald der öffentliche Zugriff deaktiviert ist. Legt ihr den Private Endpoint über das Portal an, wird die DNS Zone standardmäßig gleich mit erstellt. Prüft das aber trotzdem.

Bonus: Keine Passwörter, die leaken können

Erinnert euch an die Geschichte oben: Die einzige Barriere waren die SQL Zugangsdaten. Wenn ihr zusätzlich auf reine Microsoft Entra Authentifizierung setzt (und SQL Logins damit deaktiviert), gibt es gar keine Datenbank Passwörter mehr, die leaken können. In Kombination mit einer Managed Identity für eure Web App ist das ein richtig solides Setup.

Wie man so ein privates Netzwerk aufsetzt und mit einer bestehenden Azure Web App integriert, zeigen wir euch in einem eigenen Blogpost!

Fazit

Öffentliche Zugänge zu eurer SQL Datenbank können gravierende Nachteile mit sich bringen - vor allem die Option "Anderen Azure-Diensten den Zugriff gestatten" ist weit offener, als viele denken. Wo immer möglich, solltet ihr den öffentlichen Zugriff vermeiden und durch private Netzwerke ersetzen. Spätestens mit KI Agenten im Entwickleralltag ist das kein Nice-to-have mehr.