© vs148/shutterstock.com
APIs durch Azure-Dienste absichern - Teil 1

Private Endpoints für Azure App Service


Der Siegeszug von Software as a Service (SaaS) hat dazu geführt, dass wir daran gewöhnt sind, alle unsere Web-APIs und Webanwendungen über das öffentliche Internet zu erreichen. Aus Benutzersicht ist das eine praktische Sache, einer DevSecOps-Expertin bereitet dieser Gedanke allerdings schlaflose Nächte. Jeder Service, der über das Internet verfügbar ist, ist Ziel von Angriffen. Inwiefern private Endpoints für Azure-Web-Apps hier Abhilfe schaffen können, betrachten wir in diesem Artikel.

Natürlich wissen wir, dass wir jede Netzwerkanwendung so schreiben sollen, dass sie Angriffen standhält. Wir dürfen uns schon längst nicht mehr auf Perimeter Security, also den Schutz durch Firewalls, die an den Grenzen unseres Firmennetzwerks zum Internet installiert sind, verlassen. Authentifizierung und Verschlüsselung sind die neuen Firewalls.

Soweit die Theorie. In der Praxis müssen wir aber mit Unzulänglichkeiten umgehen. Software altert, und nicht immer sind die Ressourcen vorhanden, um alle Anwendungen auf dem neuesten Stand zu halten. Manchmal verändern sich auch Teams, und plötzlich fühlt sich niemand mehr so richtig für die Wartung eines Service verantwortlich. In solchen Situationen wünscht man sich die gute, alte Zeit von lokalen, abgeschotteten Netzwerken zurück, in denen nur „Freunde“ unterwegs waren, deren oberstes Ziel nicht das Finden und Ausnutzen von Softwareschwachstellen war. Im Folgenden wollen wir beleuchten, inwieweit Private Service Endpoints uns einen Teil dieser Zeit wieder zurückbringen können.

App Service: Status quo

Ideal wäre es, wenn wir die Vorteile der Public Cloud mit der zusätzlichen Sicherheit kombinieren könnten, die uns Netzwerkzugriffsmöglichkeiten bieten, die auf das Notwendigste beschränkt wurden. Mit Azure App Service war das bisher schwierig. Azure App Service ist ein Multi-Tenant-Dienst, also ein Dienst, bei dem sich viele Azure-Kunden eine gemeinsame Basisinfrastruktur teilen, die von Microsoft als Cloud-Anbieter verwaltet wird. Als Kunde hat man keinen Zugriff auf die zugrunde liegenden virtuellen Maschinen und kann sie daher auch nicht so einfach in ein virtuelles Netzwerk (VNet) in Azure hängen.

Eine Option, die man bereits seit Längerem hatte, sind App Service Environments (ASEs). Mit einem ASE bekommt man eine kleine, private Variante des großen App-Service-Diensts und kann diese in sein VNet integrieren. Dadurch kann man den Zugriff darauf netzwerktechnisch so weit einschränken, wie man möchte: Firmeninterne Anwendungen brauchen vielleicht keine Internetverbindung. Backend-Services können möglicherweise nur von den Frontend-Services aufgerufen werden, die davorstehen und für den Zugriff aus dem öffentlichen Internet konzipiert sind. Der Haken an der Sache ist der Preis. Man benötigt für ASEs den Isolated-Serviceplan [1], der mit Grundkosten von knapp 1 000 Euro pro Monat zusätzlich zu den Kosten für die benötigten Server zu Buche schlägt. Im Vergleich zu den normalen App Services, die im Basic-Plan bei unter 50 Euro im Monat beginnen, ist das empfindlich teuer.

Service Endpoints

Azure Service Endpoints sind ein Kompromiss aus Preis und Funktionalität. Azure App Service unterstützt Service Endpoints für alle Ausprägungen (Windows und Linux, mit und ohne Container sowie Azure Functions) schon seit relativ langer Zeit. Die Grundidee ist, dass die Webanwendungen nicht im eigenen VNet betrieben werden, sondern man die ganz normale, kostengünstige Multi-Tenant-App-Service-Umgebung von Azure nutzt. Der Zugriff wird aber durch Firewallregeln limitiert, die man über das Azure Portal, ARM-Templates, PowerShell oder das Azure CLI konfigurieren kann. Die Regeln können den Zugriff auf gewisse IP-Adressen (z. B. die IP-Adressen der Firmenniederlassungen) und/oder VNets beschränken. Damit können die DevSecOps-Verantwortlichen den netzwerktechnischen Zugriff genauso einschränken, wie es inhaltlich notwendig ist. Ebenso kann der Zugriff aus dem öffentlichen Internet unterbunden werden, wenn er nicht benötigt wird.

Service Endpoints gibt es nicht nur für App Service. Sie stehen für alle gängigen Dienste aus dem Bereich Platform as a Service (PaaS) von Azure zur Verfügung [2]. Die beste Nachricht schließlich ist, dass Service Endpoints kostenlos sind; ein großer Nachteil hingegen, dass der Zugriff auf sie von Computern im lokalen Firmennetzwerk nicht funktioniert, wenn es über VPN Gateway oder ExpressRoute Gateway mit Azure verbunden ist. Solche Computer würden die öffentlichen Endpunkte des jeweiligen PaaS-Diensts nutzen und die Zugriffseinschränkungen müssten über die öffentlichen IP-Adressen des Firmennetzwerks geregelt werden.

Private Endpoints

Die neuen Azure Private Endpoints lösen viele der Probleme, die es bisher mit Service Endpoints gab. Sie erlauben es, auf PaaS-Dienste von Azure mit einer IP-Adresse aus dem Adressraum seines Azure VNets zuzugreifen. Der jeweilige PaaS-Dienst läuft deshalb nicht innerhalb des VNets, sondern weiterhin in der Multi-Tenant-Infrastruktur, die Microsoft bereitstellt. Es wird nur ein Netzwerkendpunkt in das eigene VNet eingeblendet, über den der Zugriff möglich gemacht wird. Werden die so erreichbaren Services (z. B. Backend-Microservices, Datenbanken, Storage etc.) nur intern verwendet, kann man den Zugriff aus dem öffentlichen Internet einschränken und erreicht so das Ziel einer Abschottung gegenüber potenziellen Angreifern. Auch der Zugriff über VPN Gateway oder ExpressRoute Gateway auf Private Endpoints ist – im Gegensatz zu Service Endpoints – möglich.

Funktional sind die Private Endpoints den Service Endpoints also vorzuziehen, doch wie sieht es mit den Kosten aus? Private Endpoints sind zwar nicht gratis, aber kostengünstig. Für einen Private Endpoint muss man mit Kosten in der Höhe von ca. 6,50 Euro pro Monat rechnen. Dazu kommen noch geringe Gebühren für den Netzwerkverkehr (knapp 1 Cent pro GB) [3].

Ein Beispiel

Am besten versteht man, wie Private Endpoints funktionieren, wenn man sie ausprobiert. Daher widme ich den Großteil des restlichen Artikels einem durchgängigen Beispiel. Ziel ist es, das API-Backend für eine fiktive Single Page Application (SPA) aufzubauen. Dafür haben wir uns Folgendes zum Ziel gesetzt:

  • Die SPA greift auf ein Frontend-API zu (Backend-for-Frontend-Ansatz). Dieses muss daher aus dem öffentlichen Internet erreichbar sein.

  • Das Frontend-API nutzt im Hintergrund ein Backend-API, das nicht aus dem Internet erreichbar sein darf. In der Praxis wäre dort die eigentliche Geschäftslogik implementiert.

  • Das Backend-API verwendet eine Azure SQL Database als Datenspeicher. Aus Sicherheitsgründen wollen wir auch sie vom öffentlichen Internet abschotten.

Um den Fokus auf Private Endpoints nicht zu verlieren, ist der C#-Code für die APIs so einfach wie möglich ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang