Wenn du eine SQL-Datenbank in der Azure Cloud ablegst, ist diese über eine öffentliche IP-Adresse erreichbar – nur legitimierten Usern innerhalb und außerhalb des vNet Zugriff zu gewähren, stellt daher eine gewisse Herausforderung dar. Ich zeige dir, wie du diese meisterst. .

Der Artikel basiert auf der Frage eines Kursteilnehmers, der wissen wollte, wie man den Zugriff auf eine SQL-Datenbank in der Azure Cloud so steuern kann, dass trotz FQDN nicht nur legitimierte User innerhalb des vNet, sondern auch On-Premise-User darauf zugreifen können.

Die Ausganglage: Zugriffsteuerung einer SQL-Datenbank in der Azure Cloud

In der Azure Cloud oder einem anderen PaaS-Dienst werden SQL-Installationen standardmäßig mit einem Public FQDN Hostnamen versehen und sind damit über eine öffentliche IP-Adresse erreichbar.

Ein von mir durchgeführter Test ergab, dass die öffentlichen IP-Adressen durch Sicherheitsfilter innerhalb des vNet in private IPs umgewandelt werden. Das erlaubt uns, die Zugriffe innerhalb des vNet mit ein paar Klimmzügen zu steuern.

Das löst aber nicht das Problem, legitimierten On-Premise-Usern Zugriff zu gewähren. Im Folgenden möchte ich Schritt für Schritt aufzeigen, welche Maßnahmen für die korrekte Zugriffssteuerung auf eine SQL-Datenbank in der Azure Cloud notwendig sind.

Bevor wir ins Detail gehen, hier einige hilfreiche Links dazu:

https://docs.microsoft.com/de-de/azure/sql-database/sql-database-vnet-service-endpoint-rule-overview

https://docs.microsoft.com/de-de/azure/sql-database/sql-database-managed-instance-vnet-configuration

https://docs.microsoft.com/de-de/azure/sql-database/sql-database-managed-instance

Schritt 1: Die Zugriffe innerhalb des vNet steuern

Um nur legitimierte User innerhalb des vNet auf die Datenbank zugreifen zu lassen, erstellen wir Dienstendpunkte und konfigurieren einige Einstellungen an der SQL-DB-Server Firewall. Öffne also die verwaltete PaaS SQL Instanz in der Übersicht und rufe dann oben rechts „Firewall Settings“ auf:

a) Der „Hauptschalter“

Über einen Schalter können wir den Zugriff durch alle Azure vNet-Adressen erlauben. Leider ist diese Einstellung allein aber doch etwas zu viel des Guten, denn damit werden alle Azure vNet-Adressen, alle Subnetze und alle öffentlichen Azure-Adressen angesprochen.

b) Die Filterregeln

Um dies weiter einzuschränken, müssen weitere Filter mit Hilfe der NSG (Netzwerk-Sicherheitsregeln) eingerichtet werden. Da diese aber über die IP-Header gesteuert werden, kannst du so lediglich die Zugriffssteuerung innerhalb des vNet verfeinern, die Steuerung der On-Premise-Zugriffe ist damit nicht möglich.

c) Die Dienstendpunkte

Um das in einem späteren Schritt zu ermöglichen, tragen wir deshalb zunächst vNet-Endpunkte ein, um auf die Datenbank nur noch über ein bestimmtes vNet/Subnet zugreifen zu können. Dies betrifft dann aber nur das vNet/Subnet einer bestimmten Region, ein Peering greift hier nicht.

Zu beachten ist auch, dass die Eintragung dieser Endpunkte den ganzen SQL-Server betrifft und nicht nur eine einzelne Datenbank. Bedenke, dass auch in einer PaaS-Umgebung jede SQL-Datenbank auf einer Server-VM liegt und jede Datenbank selbst auch noch eine eigene Firewall und Zugriffs-RBACS-Listen in ihrer Administration vorhält.

Mit den Maßnahmen a) bis c) hast du nun zwar die Zugriffe innerhalb des vNet geregelt, aber immer noch keine Lösung für die On-Premise-User geschaffen. Dieses Problem lösen wir in Schritt 2.

Schritt 2: Zugriff für On-Premise-User

a) Die ExpressRoute

Eine elegante Möglichkeit, On-Premise-Usern Zugriff auf eine bestimmte Datenbank zu gewähren, ist die ExpressRoute. Der Einfachheit halber bediene ich mich hier der Dokumentation von Microsoft:

„Wenn Ihr Netzwerk über ExpressRoute mit Ihrem Azure-Netzwerk verbunden ist, wird jede Verbindung mit zwei öffentlichen IP-Adressen im Microsoft-Edgebereich konfiguriert. Die beiden IP-Adressen werden zum Herstellen der Verbindung mit Microsoft-Diensten, z.B. Azure Storage, mithilfe von öffentlichem Azure-Peering verwendet.

Um die Kommunikation von Ihrer Verbindung mit Azure SQL-Datenbank zu ermöglichen, müssen Sie IP-Adressregeln für die öffentlichen IP-Adressen Ihrer Verbindungen erstellen. Öffnen Sie über das Azure-Portal ein Supportticket für ExpressRoute, um die öffentlichen IP-Adressen Ihrer ExpressRoute-Verbindung zu ermitteln.“

b) Das Microsoft VPN Gateway

Hier ergibt sich das Problem, dass die Tunnel Client IPs nicht zum Subnet gehören und die Regeln im SQL-Sicherheitsfilter bei diesen IP-Adressen somit nicht greifen (siehe Schritt 1, Punkt a) und b)).

On-Premise-Umgebungen wären auf diese Weise nicht filterbar und es müsste über die öffentliche Umgebung „normal“ zugegriffen werden. Als Workaround könnte ein NAT Server im vNet dienen, über den nach dem VPN-Tunnel geroutet wird – das ist aber teuer und – wie wir im nächsten Schritt sehen werden – auch nicht nötig.

c) Zugriff über eine alternative Firewall und VPN-Lösung

Mit einem VPN-Server, z.B. von WatchGuard oder SonicWall, der gleichzeitig auch NAT unterstützt, sind wir mit dem On-Premise-Client im vNet. Nun greifen alle Regeln aus Schritt 1. Weiterer Vorteil: So kann ich auch lokale Anwendungen mit der Datenbank verbinden.

d) Weitere Möglichkeit für die Anbindung einer lokalen Anwendung

Neben Punkt c) gibt es eine weitere durch Microsoft vorgeschlagene Möglichkeit eine lokale Anwendung mit der Datenbank zu verbinden. Auch hier möchte ich mich der Einfachheit halber der Texte aus der Microsoft-Dokumentation bedienen:

„Auf eine verwaltete Instanz kann nur über eine private IP-Adresse zugegriffen werden. Für den Zugriff auf die verwaltete Instanz über die lokale Umgebung müssen Sie eine Standort-zu-Standort-Verbindung zwischen der Anwendung und dem VNET der verwalteten Instanz herstellen.

Es gibt zwei Optionen für die lokale Verbindung mit dem Azure-VNET:

1. Site-to-Site-VPN-Verbindung (Azure-Portal, PowerShell, Azure CLI)
2. ExpressRoute-Verbindung

Wenn Sie eine lokale Verbindung mit Azure hergestellt haben und keine Verbindung mit der verwalteten Instanz herstellen können, sollten Sie überprüfen, ob für die Firewall eine geöffnete ausgehende Verbindung am SQL-Port 1433 und ein geöffneter Portbereich 11000-12000 für die Umleitung festgelegt sind.“

 

Fazit und Vorschlag

Wie du siehst ist es zwar nicht ganz einfach, aber auch kein Hexenwerk, die Zugriffe auf eine SQL-Datenbank innerhalb des vNet oder On-Premise zu steuern. In den meisten Fällen werden die drei Punkte aus Schritt 1, kombiniert mit einer alternativen Firewall und VPN-Lösung aus Schitt 2 Punkt c), zu einer sinnvollen Lösung führen.

Wenn du weitere Fragen zum Thema hast, kontaktiere uns, wir helfen dir gerne!