Azure Veröffentlichungen

Wenn Sie Windows Server mit einem IIS in Azure hosten, dann kommt früher oder später die Frage, wie dieser Service auch aus dem Internet erreicht werden kann. Die Herausforderung gab es auch bei meinen Kunden und wie so oft gibt es nicht nur genau eine Lösung. Hier meine Gegenüberstellung und Einschätzung.

Ich habe aktuell mehrere Lösungen mit Azure Bordmitteln kennengelernt. Meine persönliche Einschätzung habe ich zu jeder Option dazu geschriebem

Option Beschreibung DoS PreAuth
Conditional Acces/MFA		 TLS/SSL HA/LB Kosten

Public-IP

Sie können einer Azure-VM direkt eine statische öffentliche IP-Adresse zuweisen und über die Azure Firewall den Zugriff auf den Port 443 beschränken. Per Default hat jede Azure-VM nach der Einrichtung eine kostenfreie IPv4-Addresse, die sich aber nach einem Neustart ändern kann. Sie können aber auch eine statische IPv4-Addresse kaufen und dauerhaft zuweisen und dann im externen DNS einen Eintrag addieren. Sie müssen sich natürlich selbst um die Sicherheit, TLS-Zertifikate, Authentifizierung, DoS-Schutz etc. kümmern und wenn sie mehrere Server unter einem Namen veröffentlichen wollten, dann ist diese Option nicht mehr passend.

Das ist sehr kritisch zu sehen, denn man verlässt sich einzig auf den Schutz der jeweiligen Applikation. Die Azure Netzwerkfilter blocken per Default natürlich alle anderen Ports aber wer einen IIS auf 443 veröffentlicht und der nicht wasserdicht ist, öffnet ein Sprungbrett für Angreifer. Diese Lösung könnte ich mir aber z.B. für VPN-Zugänge oder RDP-Gateways oder eigene Proxy-VMs vorstellen, die per Design schon für den Betrieb im Internet ausgelegt sind.

Nein

Nein

Selbst

Nein

niedrig

AzureAD App Proxy

Schon längere Zeit habe ich die Freigabe einer "On-Premises"-Applikation durch den Azure AD Application Proxy beschrieben, bei der die Clients im Internet auf einen Reverse Proxy von Microsoft in Azure zugreifen. Das Gegenstück ist ein Agent im lokalen LAN, der von innen zu Azure eine Verbindung offen hält.

Das Setup ist einfach aber natürlich sollte man für die Dienste in Azure einen eigenen AzureAD Proxy Agent in einer eigenen Gruppe auch in Azure installieren, damit die Veröffentlichung die lokalen Systeme umgeht.

Diesen Weg finde ich sehr interessant, um nicht nur On-Premises-Systeme aus dem Internet erreichbar zu machen. Er ist schnell installiert und wer PreAuth anschaltet, hat einen guten Schutz gegen DoS-Attacken anonymer Internet-Clients.

mit PreAuth

Ja

Ja

Intern

AzureADP1

Azure WAF

Die richtig "große" Lösung ist natürlich eine Security-Lösung von Microsoft. Sie können eine "Web Application Firewall" in Azure konfigurieren, die den Zugriff auf Webdienste umfangreich absichert, Lasten verteilt, URL-basiertes Routing auf verschiedene Backend-Systeme erlaubt u.a. Seltsam ist, dass es keine Pre-Authentication enthält. Ich interpretiere das derart, dass diese Funktion eher für öffentliche Webseiten vorgesehen ist, die gegen anonyme Zugriffe beschützt und skaliert werden müssen und weniger für interne Webseiten.

Die Stärke dieser Lösung ist scher die eingebaute Lastverteilung und ein Routing nach URLs, um größere Farmen von Webservern extern erreichbar zu machen. Für kleinere Umgebungen mit einem Server könnte der Aufwand und die Kosten zu hoch sein und eine PreAuth fehlt für die Veröffentlichung eigener Dienste an authentifizierte Mitarbeiter.

Ja

Nein

Ja

Ja

Extra
(15-300€/Monat)

3rd Party

Niemand hindert sie daran, eine Azure-VM mit einer statischen öffentlichen IP-Adresse zu betreiben und dort ihre eigene 3rd-Party Firewall zu betreiben. Entsprechende Angebote gibt es direkt im Azure Marketplace.

Interessant ist, dass es auch von Microsoft noch eine "Azure Firewall" gibt, die aber eher stateful Netzwerkfirewall ist und weniger mehrwerte bei Application Publishing liefert.
https://azuremarketplace.microsoft.com/de-de/marketplace/apps/microsoft.AzureFirewall-Arm?tab=Overview

Produktabhängig

OnPrem

Theoretisch ist es natürlich denkbar, dass Sie die VM zwar in Azure laufen lassen, aber die Zugriffe über einen lokalen Veröffentlichungsdienst machen wenig Sinn. Die Clients würden dann ja über das Internet durch die "On-Premises"-Welt und einen Azure VPN-Tunnel zum Service in Azure laufen.

Produktabhängig

Wenn Sie weitere Optionen kennen, dann können Sie mir gerne einen Hinweis darauf geben. (-> Kontakt)

Ich möchte auf dieser Seite nicht viel tiefer in die Konfiguration der verschiedenen Optionen einsteigen, das jede Lösung für sich eine eigene Seite wert ist. Für die ein oder andere Komponente habe ich schon eine eigene Seite veröffentlicht und die anderen Optionen habe ich entweder noch nicht umgesetzt oder zu wenig eigene Erfahrung damit gesammelt.

Weitere Links