Blog
Cloud Network Segmentation
Welche Option passt am besten zu Ihren Anforderungen?
Mit der Möglichkeit, Platform as a Service (PaaS) Dienste in ein virtuelles Netzwerk zu integrieren, steigert sich auch die Wichtigkeit eines sicheren, skalierbaren und effizient betreibbaren Netzwerkdesigns. Mit diesem Blog zeigen wir Varianten auf, wie Cloud Network Segmentation im Enterprise-Umfeld aussehen kann.
Grundsätze zur Cloud Network Segmentation
Eine Hub&Spoke-Netzwerk-Architektur hat sich in der Cloud als Best Practice etabliert und wird mittlerweile in den meisten Unternehmen im Enterprise-Bereich eingesetzt. Dabei werden übergreifende Netzwerkservices wie Firewall, Connectivity oder Routing zentral in einem Hub-Netzwerk gesteuert. Mittels Peerings werden Workload-Netzwerke (Spokes) mit dem Hub verbunden, wodurch sämtlicher Verkehr zwischen verschiedenen Spokes im Hub kontrolliert wird.
Während sich OnPremise der Weg zur Micro Segmentation als sehr aufwändig gestaltet, kommt dieses Konzept in der Cloud bereits standardmässig zur Anwendung. Dabei wird vermehrt ein Zero Trust Ansatz verfolgt, der eine deutlich striktere Abschottung von einzelnen Applikationen ermöglicht. Dies widerspiegelt sich auch in Controls von diversen Best Practice Security Frameworks wie dem Microsoft Cloud Security Benchmark (NS-1/NS-2), CIS Controls (3.12, 13.4, 4.4), NIST SP 800-53 (AC-4, SC-2, SC-7) oder PCI-DSS (1.1, 1.2, 1.3).
Blog
Ergänzende Informationen zu Zero Trust finden Sie in unserem dedizierten Blog-Beitrag:
Implementierung einer Zero Trust Architektur
In der Cloud existieren dabei fünf grundlegende Werkzeuge, die zu einer funktionierenden Network Segmentation beitragen:
- Virtuelle Netzwerke
Mit Hilfe von VNets (Azure) oder VPCs (AWS und Google) lassen sich Ressourcen isolieren, da eine freie Kommunikation standardmässig nur innerhalb eines virtuellen Netzwerks möglich ist. Mittels Peerings zum Hub können diese jedoch miteinander verbunden werden.
- Subnetze
Innerhalb eines virtuellen Netzwerks ist eine zusätzliche Segmentierung durch Subnetze möglich. Dadurch können einzelne Applikationskomponenten (z.B. Frontends, Key Vaults oder Datenbanken) voneinander isoliert und von der Firewall über die spezifischen Subnetz-Ranges angesteuert werden.
- Firewalls
Mit Firewalls lässt sich Traffic steuern und inspizieren, der über Peerings zum Hub geschleust wird. Dies erfolgt auf definierten IP-Adressen oder -Adressbereichen (L3), kann aber auch mittels FQDN-Regeln auf einem erhöhten Layer (L7) implementiert werden.
- Network Security Groups / Network Access Control Lists / VPC Firewall Rules
Network Security Groups (NSGs, Azure), Network Access Control Lists (ACLs, AWS) oder VPC Firewall Rules (GCP) sind vereinfachte Firewalls, die den Verkehr innerhalb eines virtuellen Netzwerks regeln. Diese NSGs bzw. ACLs werden dabei an einzelne Subnetze angehängt und definieren dort den eingehenden und ausgehenden Verkehr auf Basis Source / Destination, Protokoll und Port.
- Route Tables
Standardmässig wird ausgehender Internetverkehr direkt aus dem jeweiligen Subnetz ins Internet geroutet. Um dies zu ändern und den Verkehr zunächst in einer Firewall zu inspizieren bzw. zu steuern, können Route Tables und User Defined Routes (UDRs) eingesetzt und mit Subnetzen verknüpft werden.
Nun stellt sich allerdings die Frage, wie die zuvor genannten Werkzeuge bestmöglich miteinander kombiniert werden können, um das Ziel einer effizienten, sicheren und skalierbaren Segmentierung zu erreichen.
Für eine bessere Leserlichkeit werden in den nachfolgenden Abschnitten die Terminologien von Microsoft Azure verwendet, das Prinzip gilt allerdings jeweils genauso für AWS und GCP.
Variante 1 – Segmentierung virtueller Netzwerke
Diese Variante verfolgt den Grundsatz, dass jede Applikation bzw. jeder Service in einem dedizierten virtuellen Netzwerk gehostet wird. Dabei wird erreicht, dass standardmässig eine virtuelle Hülle um die Applikation entsteht und die Kommunikation innerhalb über Subnetze und Network Security Groups gehandhabt wird.
Der Vorteil dieser Variante liegt vor allem in der niedrigen Komplexität und der durchgehenden Isolation von Applikationen, da die Applikationsgrenzen direkt mittels virtueller Netzwerke erzwungen werden. Allerdings gilt es zu beachten, dass aufgrund der limitierten Anzahl Peerings (bei Azure sind es derzeit 500 pro Hub) die maximale Anzahl an Applikationen entsprechend begrenzt ist. Diese Limitation fällt noch mehr ins Gewicht, wenn pro Applikation getrennte Umgebungen (Dev, Test, Prod) erforderlich sind.
Ein weiterer Faktor, den es bei dieser Variante zu berücksichtigen gilt, sind die Kosten. Die Anzahl an VNets ist zwar kein direkter Kostenfaktor, allerdings wird sämtlicher VNet-übergreifender Verkehr verrechnet. Eine Überlegung kann daher sein, dass Applikationen, die häufig und viel Daten austauschen, im selben VNet geclustert werden.
Variante 2 – Segmentierung mittels Subnetze
Anstelle von applikationsspezifischen virtuellen Netzwerken werden bei dieser Variante grössere, geteilte Netzwerke (z.B. pro Umgebung) eingesetzt. Die Abgrenzung von Applikationen innerhalb dieser virtuellen Netzwerke erfolgt dabei (wenn überhaupt erwünscht) über Subnetze und Network Security Groups. Dies bedeutet somit, dass hier standardmässig eine offene Kommunikation innerhalb einer Umgebung respektive Zone möglich ist.
Diese Variante bringt wiederum den Vorteil der einfachen Handhabung mit, sofern ein offener, applikationsübergreifender Verkehr erwünscht ist. Ist dies nicht der Fall, führt dies mit einer steigenden Anzahl Applikationen zu einer unübersichtlichen Landschaft an Subnetzen und Network Security Groups. Vor allem die Tatsache, dass aktuell keine übergreifende Ansicht zum Management von Subnetzen oder NSGs existiert, erschwert das Verwalten von Regeln bei zusätzlichen Applikationen.
Variante 3 – Segmentierung mittels Route Tables und Firewall
Bei dieser Variante wird ein Mix zwischen den ersten beiden Varianten erzielt, indem Applikationen zwar in einem grossen, geteilten Netzwerk platziert werden, der Verkehr aber stets zur zentralen Firewall im Hub geroutet und dort gesteuert wird. Dies wird mit mehreren User-defined-Routes (UDRs) ermöglicht, die die standardmässig vorhandenen Routen innerhalb des virtuellen Netzwerks übersteuern.
Zwar könnte bei dieser Variante der Eindruck entstehen, dass die Vorteile der zuvor erwähnten Varianten kombiniert werden können, allerdings wird bei steigender Applikationsmenge auch hier die Handhabung komplex. Der Grund dafür liegt darin, dass die Standardrouten nur durch UDRs übersteuert werden können, wenn diese gleich spezifisch oder spezifischer sind. Eine Default-Route (0.0.0.0/0) bringt in diesem Fall für internen Verkehr nicht den gewünschten Effekt, vielmehr müsste für jedes Subnetz auch eine zusätzliche Route erstellt werden (max. 400 pro Route Table).
Fazit / Empfehlung
Um dem Zero Trust Ansatz gerecht zu werden, empfehlen wir Variante 1 und somit eine strikte netzwerktechnische Trennung von Applikationen mit Hilfe von dedizierten virtuellen Netzwerken. Microsoft hat diesen Ansatz indirekt auch in ihrem Cloud Adoption Framework verankert und sieht vor, dass Applikationen prinzipiell in dedizierten Subscriptions platziert werden (Subscription Democratization), was folglich auch zu dedizierten virtuellen Netzwerken führt.
Der Grund für diese Empfehlung liegt hauptsächlich in der mittelfristig notwendigen Skalierbarkeit. Zwar mag zu Beginn mit einem überschaubaren Cloud-Portfolio ein geteiltes virtuelles Netzwerk sinnvoll erscheinen, mit der zunehmenden Anzahl Applikationen steigen der Betriebsaufwand und die Komplexität allerdings exponentiell. Ein Architekturwechsel ist zwar auch im Nachhinein möglich, bedeutet aber ein Neu-Deployment sämtlicher Komponenten innerhalb des virtuellen Netzwerks.
Grundsätzlich empfehlen wir das Netzwerkdesign in einem Cloud-Vorhaben nicht zu unterschätzen und sich bereits zu Beginn damit auseinanderzusetzen. Schliesslich gilt das Netzwerk, zusammen mit Identity Management und Governance-Mechanismen (Policies, RBAC, etc.), als einer der Grundpfeiler, auf dem die Applikationen aufsetzen.
