Kolumne: Stropek as a Service

Zero Trust: Netzwerksicherheit durch virtuelle Netzwerke in der Azure Cloud
Keine Kommentare

PaaS-Dienste in VNets isolieren oder keine VNets verwenden? Die Frage ist nicht so einfach zu beantworten, wie es auf den ersten Blick scheint. Zwar können VNets richtig gemacht die Sicherheit eines Gesamtsystems auf jeden Fall erhöhen, sie erhöhen aber auch die Kosten – und das zum Teil beträchtlich. Woher kommt eigentlich die Tendenz, alles in der Cloud in virtuelle Netzwerke einzusperren?

In den vielen Azure-Cloud-Architekturworkshops, die ich in den letzten Monaten begleiten durfte, kam eine Frage so sicher wie das Amen in der Kirche: PaaS-Dienste in VNets isolieren oder keine VNets verwenden? Die Frage ist nicht so einfach zu beantworten, wie es auf den ersten Blick scheint. Zwar können VNets richtig gemacht die Sicherheit eines Gesamtsystems auf jeden Fall erhöhen, sie erhöhen aber auch die Kosten – und das zum Teil beträchtlich. Kunden sagen mir zwar oft, dass Sicherheit höchste Priorität hat und hier nicht gespart werden darf. Wenn die Zahlen aber auf dem Tisch liegen, kommen sie ins Grübeln. Aber beginnen wir von vorne: Woher kommt eigentlich die Tendenz, alles in der Cloud in virtuelle Netzwerke einzusperren?

Perimeter Security

Lokale Firmennetze haben von Natur aus nur wenig Berührungspunkte mit dem Internet. Meist gibt es eine zentrale Verbindung, der in Bezug auf Sicherheit durch Firewalls und Proxies viel Aufmerksamkeit geschenkt wird. Angreifer sollen so draußen gehalten werden. Der Großteil an Servern muss von außen nicht erreichbar sein, und daher werden Verbindungen aus dem Internet größtenteils verhindert. Im LAN spielt Netzwerksicherheit kaum eine Rolle, schließlich vertraut man seinen Mitarbeiterinnen und Mitarbeitern.

Diese Form der Netzwerksicherheit ist heutzutage obsolet. Die Annahme, dass ein lokales Netzwerk sicher ist, entbehrt oft jeder Grundlage. Die Belegschaft bringt eigene Computer mit (Bring Your Own Device, BYOD), viele möchten von unterwegs auf die Unternehmensserver zugreifen, externe Dienstleister gehen ein und aus und brauchen eine Verbindung zum Unternehmensnetz etc.

Zero Trust Networks

Es läuft darauf hinaus, dass Software grundsätzlich so geschrieben werden muss, dass man nie von einem vertrauenswürdigen Netzwerk ausgeht (Zero Trust Networks). Nur weil jemand eine Verbindung zu einem Netzwerk hat, heißt das nicht, dass man ihr mehr vertrauen kann als jemandem, der von außen kommt. Das Netzwerk, von dem aus ein Systemzugriff erfolgt, kann nur ein Aspekt bei der Bewertung sein, ob Zugriff auf eine Anwendung oder ein API gewährt wird oder nicht.

C# 8.0 Spickzettel

Kostenlos: C# 8.0 – neue Sprachfeatures auf einen Blick

Der C#-8.0-Spickzettel fasst die neuen Features der Sprache zusammen mit Blick auf das aktuelle .NET Core 3.0 bzw. .NET Standard 2.1. Jetzt herunterladen und schneller & effektiver programmieren!

Die wenigsten der Kunden, mit denen ich zu tun habe, arbeiten nach diesem Prinzip, wenn es um das lokale Netzwerk geht. Gültige Zertifikate für interne Webseiten? Fehlanzeige. IP Whitelisting für interne Datenbankserver? Das wäre viel zu kompliziert.

In der Cloud

Wenn Firmen ihre ersten Anwendungen in die Cloud bringen, möchten sie den gewohnten Ansatz des Außenschutzes (Perimeter-based Network Security) mitnehmen. Sie wollen keinesfalls, dass ihre Cloudserver netzwerktechnisch über das Internet erreichbar sind. Ein virtuelles Netzwerk in der Cloud muss her, und das braucht einen klar definierten Ein- und Ausgang, der über entsprechende Firewalls geschützt wird.

Es spricht (außer den höheren Kosten) nichts gegen diesen Ansatz, im Gegenteil. VNets können zusätzliche Sicherheit bieten. Wenn aber das VNet über ein VPN mit dem Firmennetz verbunden und dem ohne Weiteres vertraut wird, ist die erhöhte Sicherheit schon wieder in Frage zu stellen.

Anders sieht die Sache aus, wenn man den erwähnten Zero-Trust-Network-Ansatz gewöhnt ist. Das Internet ist dann nur ein weiteres, unsicheres Netzwerk. Jedes System muss den Zugriff über entsprechende Policies und Verschlüsselungsmaßnahmen schützen, unabhängig davon, woher der Traffic kommt.

Doppelt hält besser, ist aber teuer

Man könnte argumentieren, dass VNets zusätzlich zu Zero Trust doch nichts schaden können. Leider ist das in Azure nicht ganz richtig. Viele Azure-PaaS-Dienste kosten, wenn man sie in ein VNet einbindet, deutlich mehr als sonst. Hier einige Beispiele:

  • Will man Azure App Service in ein VNet einbinden, braucht man den Isolated Service Plan. Erstens ist die Rechenleistung in diesem Plan teurer als die in den anderen Preisplänen und zweitens zahlt man pro sogenanntem App Service Environment eine Flat Fee von knapp 1 000 Euro pro Monat.
  • Möchte man den Azure Service Bus in einem VNet nutzen, funktionieren erstens die Integrationen in einige andere Azure-Dienste nicht mehr. Zweitens ist der Premium-Preisplan Voraussetzung. Wenn man die Leistungsfähigkeit dieses Preisplans eigentlich nicht braucht, bezahlt man die VNet-Integration ziemlich teuer (Mindestpreis Standard-Preisplan 0,0114 €/Stunde vs. 0,783 €/Stunde im Premium-Plan).
  • Azure API Management ist ein nützlicher Dienst, wenn man öffentliche Web-APIs anbieten möchte. Für VNet-Unterstützung braucht man in Produktion den Premium-Preisplan, der zwar eine Menge Rechenleistung mitbringt, mit über 2 300 €/Monat aber nicht billig ist. Kleinere Anwendungen kämen vielleicht mit dem Standard-Plan aus, der schon um unter 580 €/Monat zu haben ist.

In großen Unternehmen mit entsprechend hohen Anforderungen an die Leistungsfähigkeit ihrer Cloudlösungen spielen solche Mehrkosten meist keine Rolle. Das Hinterfragen festgeschriebener Sicherheitsregeln würde viel höheren Abstimmungsaufwand bedeuten. In diesen Fällen würde ich – wo technisch möglich – ohne zu zögern VNets einsetzen. In kleineren Projekten muss man aber aufpassen, dass die Zusatzkosten für Cloudressourcen in VNets nicht zum Killerargument gegen den Schritt in die Cloud werden.

DevSecOps

In einer meiner letzten Kolumnen habe ich über DevSecOps geschrieben. Dieser Ansatz, der dem Thema Sicherheit bei der DevOps-Arbeit im Projekt von Anfang an hohen Stellenwert zuschreibt, erlaubt es in vielen Fällen, auf VNets zu verzichten. PaaS-Dienste wie Azure SQL Database sind von Haus aus für den Betrieb im öffentlichen Internet vorgesehen. Eine Schwachstelle könnten schwache Passwörter für Datenbankbenutzer sein. Ein DevSecOps-Team ist sich dieses Risikos im Rahmen der Systementwicklung bewusst und würde entsprechende Gegenmaßnahmen ergreifen. Hier einige Beispiele:

  • Automatisches Generieren von starken Passwörtern, die automatisch regelmäßig geändert werden
  • Sicheres Ablegen von Connection Strings in Azure Key Vault
  • Nutzung von Azure Managed Identity statt manueller Pflege von Passwörtern
  • Verwendung von Azure Active Directory Authentication und dadurch Vermeidung von zusätzlichen Datenbankbenutzern

Eine Azure-SQL-Database, die durch solche Maßnahmen geschützt ist, kann auch netzwerktechnisch über das Internet erreichbar sein, ohne dass man das als fahrlässig bezeichnen könnte. Ähnliches gilt bei der Absicherung von Web-APIs. Wer sich dabei an die gängigen Standards (z. B. OpenID Connect) hält und im Rahmen der Entwicklung etablierte Bibliotheken (z. B. Standardbibliotheken für das Validieren von JWT Tokens, Entity Framework zur Vermeidung von SQL Injections etc.) nutzt, kann trotz direkter Internetanbindung ruhig schlafen. Speziell Azure Active Directory bietet eine Menge Standardfunktionen, die helfen können, den Zugriff auf APIs solide abzusichern. Interessierte Personen finden mehr dazu, unter anderem unter dem Betriff Azure Active Directory Conditional Access.

VNets also sinnlos?

Sind VNets als Mittel zu Abschottung von Backend Services gegenüber dem Internet also sinnlos? Nein, keinesfalls. Ein wesentlicher Vorteil von VNets ist, dass die eingeschlossenen Services überhaupt nicht aus dem Internet erreichbar sind. Man kann dadurch an einer zentralen Stelle beispielsweise DDoS-Schutz oder eine Web Application Firewall (z. B. Azure Application Gateway Web Application Firewall) vorsehen, und niemand hat netzwerktechnisch eine Möglichkeit, sie zu umgehen. Ohne VNet könnten die Services im Hintergrund direkt angegriffen werden.

Dazu kommt, dass man bei Nutzung von Sicherheitsdiensten wie Azure Application Gateway oder Azure API Management ohne VNet in den dahinterliegenden APIs selbst validieren muss, dass eingehender Traffic tatsächlich durch die vorgelagerten Systeme gegangen ist. Dafür gibt es zwar entsprechende Mechanismen und Anleitungen, das Risiko eines Konfigurations- oder Programmierfehlers bleibt aber trotzdem bestehen.

Fazit

Wer sich in der Cloud wie in der Vergangenheit ganz auf Perimeter Security verlässt, wird über kurz oder lang ein böses Erwachen erleben. DevSecOps-Teams sollten Software so schreiben, dass jedes Netzwerk als unsicher betrachtet wird und ein sicherer Betrieb ihrer Dienste über das Internet gewährleistet werden könnte, selbst wenn man sich doch für VNet-Isolierung entscheidet.

In größeren Projekten, bei denen Netzwerksicherheit einen hohen Stellenwert hat, sind VNets und zentrale Sicherheitsmaßnahmen am Ein- und Ausgang zum Internet empfehlenswert. Aber Achtung: Wenn man mit dem Zugriff zu diesen VNets zu locker umgeht (z. B. VPN-Zugänge aus unsicheren Netzwerken), sinkt der sicherheitstechnische Wert. An dieser Stelle möchte ich auf einen neuen Dienst in Azure hinweisen: Azure Bastion. Bastion ist ein PaaS-Dienst, der den Zugriff auf VMs in VNets über RDP und SSH über das Azure Portal, also den Webbrowser, erlaubt. Dafür ist kein VPN-Zugriff in das VNet oder eine öffentliche IP-Adresse mehr notwendig.

Vorsichtig sollte man hinsichtlich VNets in Projekten sein, bei denen niedrige Betriebskosten ein entscheidender Erfolgsfaktor sind. In solchen Fällen muss man die eventuell zu erwartenden Mehrkosten durch VNets transparent kommunizieren und projektspezifisch abwägen, ob zumindest manche der benutzten Azure-PaaS-Dienste außerhalb des VNets akzeptabel sind, auch wenn sie streng genommen nur im Backend notwendig wären.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. Außerdem ist der Windows Developer weiterhin als Print-Magazin im Abonnement erhältlich.

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 -