Kolumne: Stropek as a Service

Privatsphäre in der Cloud – neue Spielregeln für Azure VNets durch Private Endpoints
Keine Kommentare

In dieser Kolumne habe ich schon mehrmals über Zero Trust Networking geschrieben. Man verabschiedet sich bei diesem Ansatz von der Annahme, dass irgendein Netzwerk sicher ist. Traditionell unterschieden Firmen früher zwischen dem bösen unsicheren Internet und dem sicheren lokalen Netzwerk. Die Grenze zwischen den beiden wurde von Firewalls bewacht. Diese Denkweise kann in der heutigen Zeit nicht mehr aufrechterhalten werden. Erstens haben unzählige Vorfälle gezeigt, dass lokale Netze speziell in großen Organisationen nicht pauschal sicher sind. Zweitens öffnen sich in der heutigen Zeit viele Firmen und bieten APIs bewusst im öffentlichen Internet an.

Zero Trust Networking

Zero Trust Networking bedeutet, dass jede Maschine so behandelt wird, als ob sie mit einer öffentlichen IP-Adresse im Internet erreichbar wäre. An die Stelle von klassischen Firewalls und Perimetersecurity treten Authentifizierung von Benutzern und Geräten, Verschlüsselung und Logging. Das sind die „neuen Firewalls“ im Zero Trust Network. Wer mehr über die Grundlagen von Zero Trust Networking lernen möchte, dem empfehle ich einen Blick auf die BeyondCorp-Initiative von Google [1].

Nicht alles muss ins Internet

Bedeutet Zero Trust Networking auch, dass jeder Service ins öffentliche Internet muss? Nein, keineswegs! Netzwerke zu segmentieren und nur jene gegenseitigen Zugriffe zu erlauben, die notwendig sind, ergibt Sinn und sorgt für zusätzliche Sicherheit. Kombiniert man eine gute Netzwerksegmentierung mit minimalen Containern, die nur die Services enthalten, die tatsächlich notwendig sind, macht man Angreifern das Leben schwer.

Wollte man eine solche Architektur in Microsoft Azure umsetzen, musste man bis vor einigen Monaten auf viele Dienste verzichten beziehungsweise besonders tief in die Tasche greifen, da nicht alle in virtuellen Netzwerken (VNets) verfügbar waren und Preise zum Betrieb von PaaS-Diensten in VNets empfindlich hoch sind. Für Azure App Service brauchte man zum Beispiel den Isolated Service Plan, für den wiederum ein App Service Environment Voraussetzung war, das Basiskosten von fast 1 000 Euro monatlich verursacht. Man hat damit zwar den Vorteil, dass man sich die zugrundeliegenden, virtuellen Server mit keinem anderen Azure-Kunden teilen muss, viele Anwendungen brauchen das aber nicht, sondern wollen einfach nur eine Web-API vom Internet abschotten und den Zugriff auf sie auf ein VNet beschränken.

Azure Private Endpoints

Die neuen Azure Private Endpoints ändern die Situation grundlegend. Über Private Endpoints kann man sich fertige PaaS-Dienste wie Azure SQL Database, Azure Storage oder Azure CosmosDB (komplette Liste siehe [2]) mit einer privaten IP-Adresse in sein VNet holen und den Zugriff aus dem öffentlichen Internet verhindern. Das allein ist schon hilfreich, bis vor Kurzem fehlte aber ein entscheidender Schritt: Azure App Service, der beliebteste PaaS/Serverless-Service für den Betrieb von Webanwendungen und Web-APIs in Azure, beherrschte diesen Trick noch nicht. Das ändert sich jedoch gerade. Private Endpoints for Azure Web Apps sind seit Kurzem als Preview-Version verfügbar. Zum Zeitpunkt des Schreibens dieser Kolumne war die Preview nur für US-Regionen von Azure verfügbar. Es ist aber zu hoffen, dass diese Einschränkung in naher Zukunft aufgehoben wird.

Wenn Private Endpoints durchgängig verfügbar sein werden, kann man ohne großen Aufwand und vor allem ohne nennenswerte Zusatzkosten Backend-Web-APIs auf PaaS-Basis ohne Anbindung an das öffentliche Internet betreiben. Die von ihnen genutzten PaaS Dienste (z. B. Datenbanken, Storage) wären ebenfalls nur innerhalb ihres VNets erreichbar. Das macht mikrosegmentierte Netzwerke möglich, in denen jeder Service nur genau die Ressourcen im Netzwerk erreichen kann, die er braucht. Abbildung 1 zeigt einen Docker-Container mit einem nginx-Webserver in einer Azure-Web-App, der über einen Private Endpoint in einem VNet hängt. Rechts sieht man, dass der Zugriff über das öffentliche Internet nicht funktioniert (403 – Forbidden), während der Zugriff aus dem VNet funktioniert.

Abb. 1: Azure-Web-App im VNet

Abb. 1: Azure-Web-App im VNet

Azure Private Link

Azure Private Link ist eine spannende Ergänzung speziell für Serviceprovider, die SaaS-Lösungen für Firmen anbieten. Anstatt die SaaS-Lösung im VNet des Kunden installieren zu müssen, erstellt man einen Private Link und gibt dessen ID an die Kunden weiter. Sie können damit Private Endpoints einrichten, über die auf die SaaS-Lösung zugegriffen werden kann [4]. Dadurch wird eine Multi-Tenant-SaaS-Lösung möglich, für die ein Netzwerkzugriff aus dem öffentlichen Internet nicht zwingend notwendig ist. Für B2B-SaaS-Angebote, die für die interne Nutzung durch Firmenkunden konzipiert sind, kann das interessant sein.

Zugriff von außerhalb

Die neuen Azure-Dienste machen die Absicherung von Diensten in Azure viel leichter und kostengünstiger. Was aber tun, wenn man auf Dienste im VNet zugreifen will, sich aber außerhalb von Azure befindet? Vor diesem Problem könnte eine Entwicklerin stehen, die zum Zweck der Fehleranalyse auf ein Backend-Web-API zugreifen muss. Eine Multi-Cloud-Lösung, bei der Dienste in verschiedenen Cloud-Umgebungen laufen, steht vor einem ähnlichen Problem. Azure bietet dafür das Azure VPN Gateway [5] an, mit dem man VNets untereinander (Site-to-Site-VPN) oder sich von einem einzelnen Computer aus ins VNet (Point-to-Site-VPN) verbinden kann.

An seine Grenzen stößt dieser Ansatz, wenn man über Azure-Grenzen hinweg sein Netzwerk feiner strukturieren will. Gewisse Entwicklerinnen dürfen vielleicht nur auf gewisse VNets zugreifen. Vielleicht möchte man in einer Multi-Cloud-Lösung Verbindungen von gewissen Servern in AWS nur auf gewisse Dienste in Azure erlauben. Für dieses Problem gibt es verschiedene kommerzielle und Open-Source-Lösungen. Zwei relativ neue, plattformunabhängige Open-Source-Produkte möchte ich zum Abschluss dieser Ausgabe der Kolumne erwähnen. Beide haben etwas unterschiedliche Schwerpunkte.

Tailscale

Tailscale [6] ist das Produkt des gleichnamigen Start-ups, das angetreten ist, das Erstellen von Overlay VPNs auf Basis der populären VPN-Software WireGuard [7] stark zu vereinfachen. Statt eine eigene komplexe Verwaltung von Zertifikaten für die VPN-Verbindungen aufzubauen, verwendet man bei Tailscale vorhandene Single-Sign-on-(SSO-)Systeme wie Google GSuite, Microsoft AAD etc., um seinen Computer mit einem VNet zu verbinden. Man ist dabei nicht an einen Cloud-Anbieter gebunden, sondern kann auf einfache Weise lokale Computer und Server sowie Server in irgendeiner Cloud netzwerktechnisch miteinander verbinden. Die Zugriffssteuerung erfolgt mit Hilfe der Benutzer aus dem SSO-System oder mit den IP-Adressen der Server, die diese im VNet zugewiesen bekommen haben.

Abbildung 2 zeigt beispielhaft den Zugriff auf eine VM in Azure über Tailscale. Am Windows-Entwicklungsrechner und auf der Linux VM in Azure ist Tailscale installiert. Auf beiden Maschinen habe ich mich über Azure AD authentifiziert. Auf die Azure VM ist über die öffentliche IP-Adresse (52.191.119.31) kein Zugriff möglich, über die Tailscale-Adresse 100.112.236.98, wie man rechts im Bild sieht, jedoch schon. Die Azure VM ist mit einem Azure VNet verbunden (IP-Adresse 10.10.2.4).

Abb. 2: Zugriff auf Azure VM über Tailscale

Abb. 2: Zugriff auf Azure VM über Tailscale

Tailscale ist aus meiner Sicht ein vielversprechendes Projekt, speziell wenn es um den Zugang zu virtuellen Netzwerken durch Benutzer von individuellen Computern aus geht. Das Produkt ist noch nicht für den produktiven Einsatz freigegeben. Es steht momentan als Preview zur Verfügung. Große Teile des Quellcodes sind auf GitHub als Open-Source-Software einsehbar.

Slack Nebula

Slack, der bekannte Hersteller des gleichnamigen Teamworking-Produkts, hat seine Lösung zur Verbindung von Servern in verschiedenen Cloud-Umgebungen als Open-Source-Software zur Verfügung gestellt. Das entsprechende Projekt trägt den Namen Nebula [8]. Nebula erlaubt es, ein Overlay-Netzwerk plattformunabhängig über verschiedene Netzwerkumgebungen hinweg aufzubauen und den Netzwerkverkehr darin entsprechend zu filtern. Man kann sich Nebula vorstellen wie Azure Network Security Groups [9], nur eben Cloud-übergreifend. Nebula hat im Gegensatz zu Tailscale keine SSO-Integration. Der Schwerpunkt liegt beim Verbinden von Servern in Multi-Cloud-Lösungen, weniger bei der einfachen Einbindung von Benutzern und ihren individuellen Rechnern.

Fazit

In der Vergangenheit haben viele Azure-Projekte mit PaaS-Fokus auf VNets verzichtet, da sie zu hohen Kosten geführt oder den Einsatz gewisser Dienste unmöglich gemacht hätten. Durch Private Endpoints werden die Karten neu gemischt und neue, sicherere Architekturen werden möglich. Wer keine reine Azure-Lösung hat, dem helfen neue Open-Source-Projekte wie Tailscale oder Nebula, die Overlay-Netzwerke über Cloud-Anbieter hinweg mit überschaubarem Aufwand möglich machen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -