Azure Private Link, darauf habe ich lange gewartet! 🙂 Es ist bekannt, dass SQL-Datenbanken aus dem PaaS-Bereich immer über eine öffentliche IP-Adresse angesprochen werden. D. h. eine Anwendung muss immer über den öffentlichen IP-Adressraum des Internets mit der Datenbank kommunizieren. Es gibt bereits einige Sicherheitsfeatures, die den Zugriff auf eine SQL-Datenbank aus einem VNET heraus einschränken, aber wenn man von onprem auf diese SQL-Datenbank zugreifen möchte benötigte man eine Regel, die eine öffenliche NAT-IP-Adresse zuließ. Und das bereitet so manchen Sicherheits-Admin Bauchschmerzen.
Wie es besser geht? Hier geht es weiter.
Problemstellung
In diesem Beispiel erläutere ich das anhand einer Topologie mit ExpressRoute.
Es stellt kein Problem dar, den Zugriff aus einem VNET heraus auf die SQL-Datenbank einzuschränken. Dafür gibt es Service Endpoints, die ein VNET direkt auf den gewünschten PaaS-Service „mappen“. Die VM in diesem Beispiel kann somit direkt auf die SQL-Datenbank zugreifen. Auch dann, wenn Sie vollkommen von der Außenwelt abgeschottet ist. Zudem wird auf der SQL-Datenbank das VNET freigeschaltet und gleichzeitig der gesamte öffentliche IP-Adressraum ausgesperrt. „Allow Azure services and resources to access this server“ = OFF und keine „Client IP address“ eintragen. Damit ist auf OSI-Layer 3/4 (TCP/IP) alles „safe“.
Wenn man einen Zugriff von onprem zu einer Azure Datenbank benötigt, dann kann dies über VPN oder ein ExpressRoute-Circuit ermöglicht werden.
Das Problem dabei ist aber, dass immer ein natting zwischen den Client und der SQL-Datenbank stattfinden muss. Hat das TCP/IP-Quellpaket eine private IP-Adresse und möchte eine öffentliche IP-Adresse erreichen, so muss genattet werden.
In dieser Zeichnung möchte eine VM, die onprem gehostet wird, eine SQL-Datenbank erreichen. Die Quell-IP-Adresse des IP-Paketes kommt aus dem privaten Adressraum (RFC1918). Die Ziel-IP-Adresse ist die öffentliche IP-Adresse der SQL-Datenbank. Daher wird der ExpressRoute-Router, der onprem steht, das Paket auf dem Microsoft-Peering routen und nicht auf dem Private-Peering.
Die Lösung: Private Link
Das geht besser! Mit Private Link bekommt die SQL-Datenbank (PaaS) eine IP-Adresse aus einem Subnetz in Azure.
Es müssen dafür zwei Konfigurationsobjekte angelegt werden. Den Private Link selbst: Dieser verbindet eine unterstütze Ressource (Unsere SQL-Datenbank) mit den Subnetz. Und dann eine Netzwerkkarte, die eine IP aus dem Adressbereich des Subnetzes erhält. Somit kann ich die SQL-Datenbank über eine private IP-Adresse ansprechen. Es lassen sich auch alle anderen Konfigurationen einer Netzwerkkarte, wie z. B.: eine Network Security Group darauf anwenden. Somit kann ich übliche Firewall-Regeln auf die SQL-Datenbank anwenden.
Aber Vorsicht, Private Link ist derzeit (Oktober 2019) im Preview. Das bedeutet es gibt bei Problemen kein Support von Microsoft.
Viel Spaß beim nachbauen! Bei Fragen einfach fragen.