Netzwerktopologien - Eine Serie: Teil 1

Bei der Arbeit mit der Cloud, insbesondere wenn Sie von einer lokalen Lösung kommen, kann es entmutigend sein zu sehen, wie Sie anfangen sollen und was am besten zu Ihrem Unternehmen passt. Es gibt eine Vielzahl möglicher Netzwerktopologien, so dass dies als Hindernis bei der Entscheidung, wie dies erreicht werden kann, angesehen werden kann. In meinem Arbeitsbereich treffe ich auf viele Unternehmen und damit auch auf mehrere Konfigurationen. Der gemeinsame Nenner ist, dass alle Unternehmen irgendwo anfangen mussten, sei es vor Ort oder ganz neu, und alle haben klein angefangen. Das brachte mich auf die Idee, eine Reihe von Netzwerktopologien zu dokumentieren, beginnend mit den einfachsten der einfachen, um uns dann zu komplexeren Konfigurationen vorzuarbeiten. Je nach Komplexität und Beziehung der Topologien wird jeder Blog 1 oder 2 Topologien enthalten.

Zielpublikum

Diese Blogserie richtet sich an Leser in Unternehmen jeder Größe. Diese Serie ist in der Regel für Cloud-Architekten und Cloud-Ingenieure nützlich, die eine Bestätigung für mögliche Topologien suchen. Der erste Beitrag könnte sogar für Privatanwender oder sehr kleine Unternehmen geeignet sein. Es wird vorausgesetzt, dass der Leser über einige Kenntnisse grundlegender Cloud-Konzepte wie VPC und Firewall-Regeln verfügt oder in der Lage ist, bei Bedarf die entsprechende Dokumentation zu finden.

Die Beispiele werden als Google Cloud Platform (GCP)-Ressourcen dargestellt, können aber in den meisten Fällen auf andere Public Cloud-Anbieter übertragen werden. Bevor Sie beginnen, sollten Sie in der entsprechenden Dokumentation nachschlagen.

In dieser Serie

Im ersten Blog dieser Serie werden wir uns auf zwei Topologien konzentrieren:

1. Die einfachste aller Einrichtungsmöglichkeiten.
   Diese Einrichtung soll kein Abbild eines tatsächlichen Unternehmens sein, sondern kann als Grundlage für eine persönliche Homepage mit begrenztem Kostenaufwand verwendet werden. Wir werden sichere Ansätze verwenden, da dies immer die Grundlage jeder Konfiguration sein muss.
2. Erweitern Sie die einfachste Einrichtung.
   Dieses Setup übernimmt die Nutzung von Cloud Load Balancing, automatischer Skalierung und verwalteten SSL-Zertifikaten. Dies kann die Grundlage für noch komplexere Konfigurationen sein.

Nummer 1: Am einfachsten

Für die erste Topologie werden wir uns die einfachste Form ansehen, die möglich ist:

In diesem Fall konzentrieren wir uns auf den Zweck des Rechners, einen einfachen Webserver zu bedienen.

Netzwerk

In diesem Beispiel sehen Sie die GCP-Ressource Virtual Private Cloud (VPC), die die typische Netzwerkressource ist, die alle Ressourcen miteinander verbindet. Für dieses Netzwerk wurde ein Subnetz sowie eine einfache Firewall-Regel für das Netzwerk-Tag "web-server" konfiguriert.

Teilnetz

Die gute Praxis sieht vor, dass Sie nicht die Standard-Netzwerkkonfiguration verwenden, sondern die erwarteten Subnetze selbst konfigurieren. In diesem Beispiel sehen Sie, dass nur ein Subnetz in einer Region konfiguriert ist, mit einem begrenzten Bereich adressierbarer IP-Adressen. Private Google Access (PGA) ist für diese Einrichtung nicht erforderlich, also deaktivieren wir es. Wir möchten Informationen über die Interaktionen erhalten (um z.B. Fehlverhalten zu erkennen). Daher erlauben wir die Erfassung von Datenflussprotokollen, allerdings mit einer niedrigen Abtastrate und nur bei 25% des Datenverkehrs.

Firewall

Die Standard-Firewall-Einstellungen (zumindest bei GCP) sind so konfiguriert, dass der eingehende Datenverkehr blockiert und der ausgehende Datenverkehr über implizite Firewall-Regeln zugelassen wird. Wenn wir einen einfachen Webserver betreiben, möchten wir den eingehenden Datenverkehr zu den HTTP- und HTTPS-Ports zulassen. Der Datenverkehr kann von jeder IP-Adresse kommen, darf aber nur an Instanzen gehen, für die das Netzwerk-Tag Webserver konfiguriert ist.

Virtuelle Maschine

Innerhalb des Netzwerks gibt es eine virtuelle Maschine namens "Webanwendung". Auf dieser virtuellen Maschine läuft ein Webserver (Apache, NginX oder ein anderer), der auf die Ports 80 und 443 hört. Die bewährte Praxis sieht vor, dass der über Port 80 eingehende Datenverkehr eine automatische Umleitung zu Port 443 (HTTPS) auslöst. Sie sollten die Verwendung von Container Optimized OS (COS) als Boot-Image in Betracht ziehen, damit Sie ein vorkonfiguriertes Container-Image als Quelle für Ihren Webserver verwenden können. Dies kann die Skalierung in der Zukunft ebenfalls erleichtern.

Da wir von diesem Rechner aus auch keinen Zugriff auf andere Dienste benötigen, werden wir das standardmäßig angehängte Dienstkonto entfernen. Dies entspricht dem Prinzip des geringsten Privilegs. Die Art und Weise, wie Google die VMs konfiguriert, führt zu zwei verbleibenden Fähigkeiten: Lese-/Schreibzugriff auf Cloud Logging und Lesezugriff auf Cloud Storage.

Externe IP-Adresse

Da Ihr Rechner vom öffentlichen Internet aus erreichbar sein muss, muss ihm eine externe IP-Adresse zugewiesen werden. Die Standardeinstellung bei der Konfiguration einer VM ist eine ephemere externe IP-Adresse, aber Sie sollten erwägen, diese statisch zu machen. Auf diese Weise können Sie sie wiederverwenden, falls Sie die VM aus dem einen oder anderen Grund neu starten müssen. Außerdem können Sie so einen festen DNS-Eintrag bei Ihrem Domainregistrierungsdienst konfigurieren.

Kosten

Je nach Ihren Anforderungen können die Kosten relativ niedrig sein. Die meisten Public Cloud-Anbieter bieten eine Art kostenlose Stufe an, in der Sie einige Ressourcen ohne Bezahlung nutzen können. Wenn Sie dies nutzen können, dann betreffen die Kosten höchstwahrscheinlich nur den Datenverkehr von Ihrem Rechner zum Endbenutzer, die Kosten für die statische IP-Adresse und die Kosten für die Speicherung der Protokolleinträge. Wenn Sie eine größere VM verwenden, kann dies zu höheren Kosten führen. Sie könnten auch den Einsatz von Spot VMS in Erwägung ziehen, um einen größeren Rechner zu geringeren Kosten zu erhalten, allerdings mit einer geringeren Zuverlässigkeit hinsichtlich der Verfügbarkeit Ihrer Ressourcen.

Vorteile

Da dies die einfachste Einrichtung ist, ist es sehr einfach, Probleme zu finden und zu beheben. So können Sie Ihren Dienst zu sehr niedrigen Kosten betreiben.

Nachteile

Diese einfache Architektur bringt einige Nachteile mit sich. Hier sind ein paar wichtige, die Sie beachten sollten.

1. Wenn Ihre Maschine ausfällt, bedeutet dies eine Ausfallzeit für Ihren Service.
2. Ihr Dienst ist möglicherweise nicht in der Lage, kontinuierlich alle Anfragen zu bearbeiten, wenn er die maximale Verarbeitungsleistung des konfigurierten Rechners überschreitet.
3. Der Dienst kann anfällig für Angriffe sein und bei extremer Belastung (wie bei (D)DoS-Angriffen) kann es zu deutlich erhöhten Netzwerkkosten kommen.

Nummer 2: Einfache Einrichtung mit Lastausgleich

Bei der nächsten Topologie handelt es sich um eine Erweiterung der vorherigen einfachen Einrichtung, bei der ein Load Balancer konfiguriert wird, der von einer Managed Instance Group (MIG) unterstützt wird.

Der Load Balancer bietet eine Reihe von Funktionen, von denen wir jetzt nur die Fähigkeit nutzen werden, die Anzahl der Backend-Instanzen zu skalieren, während er der einzige Einstiegspunkt ist. Der Anwendungsfall ist immer noch die Bedienung eines einfachen Webservers.

Netzwerk

In diesem Beispiel wird dasselbe Netzwerk wie im vorherigen Beispiel verwendet.

Teilnetz

Das Teilnetz ist das gleiche wie im vorherigen Beispiel.

Firewall

Wie Sie in dieser Topologie sehen können, sind die Firewall-Regeln unterschiedlich. Der Load Balancer fungiert als Endpunkt für den aus dem öffentlichen Internet kommenden Datenverkehr und muss so konfiguriert werden, dass er die richtigen Ports freigibt. Von dort aus wird der Datenverkehr weitergeleitet und kommt immer aus einem festen Bereich von IP-Adressen. Das bedeutet, dass die Firewall-Regel so konfiguriert werden kann, dass nur Datenverkehr aus diesen IP-Bereichen in Ihr Netzwerk gelangen darf.

Da die VMs nicht mehr über eine externe IP-Adresse verfügen, ist es außerdem nicht mehr möglich, bei Bedarf direkt auf diese Rechner zuzugreifen. Um einen sicheren Zugriff durch Identitäten mit ausreichenden Privilegien zu ermöglichen, konfigurieren wir eine Firewall-Regel, die den Zugriff über den Identity Aware Proxy (IAP) erlaubt.

Virtuelle Maschine

Da wir einen Load Balancer verwenden, können wir eine Managed Instance Group für die Verarbeitung unseres Datenverkehrs konfigurieren. Diese MIG wird als Backend-Dienst für unseren Load Balancer fungieren. Wir können den Load Balancer jetzt auch so konfigurieren, dass er unsere MIG auf der Grundlage einiger ausgewählter Metriken, die Ihren Bedürfnissen am besten entsprechen, nach oben oder unten skaliert. Die Konfiguration der Maschine(n) bleibt ähnlich wie bei der einfachsten Einrichtung.

Keine externe IP-Adresse für Recheninstanz

Da wir nun einen Load Balancer als öffentlich zugängliche Ressource verwenden, benötigen wir für unseren Backend-Dienst keine externe IP-Adresse mehr. Dies kann den Angriffsdienst unserer VM erheblich reduzieren, da sie nicht mehr direkt aus dem öffentlichen Internet erreichbar ist. Beachten Sie, dass Sie die externe IP-Adresse explizit deaktivieren müssen, da die Standardeinstellungen diese verwenden.

Benutzerdefinierte externe IP-Adresse

Nachdem Sie den Load Balancer eingerichtet haben, müssen Sie nun die externe IP-Adresse mit diesem Dienst verknüpfen, anstatt direkt mit der/den VM(s). Aus Gründen, die im nächsten Kapitel beschrieben werden, werden wir dies separat tun , bevor wir den Load Balancer konfigurieren. Auf diese Weise können wir unseren DNS-Server bereits so konfigurieren, dass er auf diese Adresse zeigt, bevor wir den Load Balancer selbst konfigurieren.

Lastausgleicher

Wenn Sie Ihren Dienst mit einem MIG konfiguriert haben, können Sie nun einen Load Balancer erstellen und verbinden. Da diese Topologie einen Webserver beschreibt, werden wir einen HTTPS Global External Load Balancer verwenden. Der Load Balancer wird der Eingangspunkt Ihres Dienstes sein und es müssen SSL-Zertifikate bereitgestellt werden.

Wenn Sie Zertifikate hinzufügen, haben Sie zwei Möglichkeiten. Entweder Sie stellen Ihre selbst verwalteten Zertifikate bereit oder Sie lassen diese von Google verwalten. Die letztere Option ist kostenlos und verwendet entweder die Google Root CA oder Let's Encrypt. Diese Zertifikate werden nur dann bereitgestellt, wenn Sie Ihren DNS-Dienst so konfiguriert haben, dass er auf die mit dem Load Balancer verknüpfte IP-Adresse zeigt. Deshalb ist es wichtig, dass Sie die IP-Adresse vorher reserviert haben. Wenn Sie keine strengen Sicherheitsanforderungen durch Unternehmensrichtlinien haben, wenn es um geheime Werte und Zertifikate geht, ist dies wahrscheinlich die beste Wahl für Sie.

Wenn Sie sich für die Sicherheit rund um Google Cloud Load Balancing interessieren, sollten Sie auch meinen früheren Blog mit dem Titel "Können wir Google Cloud Load Balancing vertrauen?" lesen.

Kosten

Mit dieser zusätzlichen Komplexität gewinnen Sie eine Reihe von Vorteilen. Die Details werden in den folgenden Blogs deutlicher werden, wenn wir uns mit komplexeren Topologien beschäftigen. Die Inanspruchnahme von Managed Services ist jedoch mit höheren Kosten verbunden.

Auch wenn ein MIG als Backend für den Load Balancer nicht erforderlich ist (Sie können auch mit nur einer Instanz auskommen), haben Sie mit einer Instanzgruppe den Vorteil der automatischen Skalierung bei steigendem Datenverkehr. Dies macht Ihren Dienst robuster.

Die Nutzung eines Load Balancers ist mit einigen Kosten verbunden. Beachten Sie, dass die 5 in der Preistabelle genannten Weiterleitungsregeln von einem oder mehreren Load Balancern gemeinsam genutzt werden und Sie eine http-zu-https-Weiterleitungsregel in Betracht ziehen sollten.

Vorteile

Wie bereits in dieser zweiten Topologie erwähnt, bietet die Verwendung eines Load Balancers eine Reihe von Vorteilen.

1. Die Möglichkeit, Ihren Dienst automatisch zu skalieren, wenn der Datenverkehr zunimmt
2. Backend-Dienste (die VMs der MIG in diesem Szenario) müssen nicht mehr direkt vom öffentlichen Internet aus zugänglich sein, was Ihre Angriffsfläche reduziert.
3. Die Load Balancing-Angebote werden sofort mit einem grundlegenden (D)DoS-Schutz geliefert.
4. SSL-Zertifikate können für Sie verwaltet werden, so dass Sie sich nicht mehr selbst darum kümmern müssen.
5. Eröffnung der Möglichkeit, in Zukunft erweiterte (Sicherheits-)Funktionen zu übernehmen. Dies wird in zukünftigen Blog-Beiträgen dieser Serie beschrieben werden.

Nachteile

Die Einführung dieser Topologie wird einige Nachteile mit sich bringen

1. Die Kosten werden steigen. Das liegt daran, dass der verwaltete Service kostenpflichtig ist, aber den Preis wert ist
2. Die Konfiguration dieser Topologie kann etwas komplexer werden. Es empfiehlt sich, dies immer mit dem Ansatz Infrastructure as Code zu tun. Dies hat den Vorteil der Konsistenz und der Validierung, bevor Änderungen verarbeitet werden.
3. Ein direkter Zugriff ist nicht mehr möglich und erfordert einen Tunnel über IAP, wobei Sie die richtigen Berechtigungen haben müssen

Fazit

Dieser Blog ist der erste einer kommenden Serie. Er wird sich mit immer komplexeren Netzwerktopologien befassen. In dieser ersten Ausgabe haben wir die einfachste Form der Topologie behandelt, bei der die grundlegenden Sicherheitsprinzipien beachtet werden, sowie eine etwas komplexere Variante mit einem Load Balancer.

Die erste Topologie kostet am wenigsten von den angebotenen Optionen, hat aber einige Nachteile in Form von mangelnder Zuverlässigkeit. Die zweite Option ist bereits robuster, kann mit zusätzlichen (Sicherheits-)Funktionen ausgestattet werden und bietet mehr Zuverlässigkeit. Dies ist jedoch mit einem Anstieg der Kosten verbunden.

Foto von Shubham Dhage auf Unsplash