Netzwerksicherheit in der Google Cloud Platform
Engmaschig
Veröffentlicht in Ausgabe 03/2023 - PRAXIS
Mit Virtual Private Clouds (VPCs) haben Google und die anderen Hyperscaler das Netzwerkmanagement (in der Cloud) revolutioniert. Während es in der lokalen IT trotz Neuentwicklungen wie dem Software-defined Networking (SDN) immer noch einigermaßen umständlich ist, Netzwerke dynamisch anzulegen und zu verwalten, bieten die Cloudprovider eine API an, mit der sich Netzwerkkonstrukte wie VPCs im Handumdrehen erzeugen lassen.
Doch nicht selten liegt die Verwaltung von Cloudnetzwerken in der Hand von DevOps-Teams. Und nicht immer ist der Kenntnisstand dort so, dass alle Sicherheitsbelange gebührlich beachtet werden. Zudem ist das Feld der Netzwerksicherheit relativ groß und verlangt Know-how in Sachen Anlegen von VPCs und ihren Subnetzen, Routing, Firewalls und Flow-Log-Analyse oder Threat-Detection. Wir stellen daher im Folgenden diese zentralen Sicherheitstechniken in der Google Cloud Platform (GCP) dar.
Mehr Sicherheit mit Shared VPCs
Shared VPCs sind eine Weiterentwicklung der VPCs. Letztere können Admins auf einfache Art und Weise erstellen – mit allen denkbaren Fehlkonfigurationen. Der Ansatz von Shared VPCs ist, das Erstellen und Verwalten von VPCs an ein dediziertes Team zu delegieren. Dies entbindet Applikationsteams von der Bürde "Netzwerk-sicherheit" und erlaubt ihnen, sich dediziert um ihre Anwendung zu kümmern.
Mit Virtual Private Clouds (VPCs) haben Google und die anderen Hyperscaler das Netzwerkmanagement (in der Cloud) revolutioniert. Während es in der lokalen IT trotz Neuentwicklungen wie dem Software-defined Networking (SDN) immer noch einigermaßen umständlich ist, Netzwerke dynamisch anzulegen und zu verwalten, bieten die Cloudprovider eine API an, mit der sich Netzwerkkonstrukte wie VPCs im Handumdrehen erzeugen lassen.
Doch nicht selten liegt die Verwaltung von Cloudnetzwerken in der Hand von DevOps-Teams. Und nicht immer ist der Kenntnisstand dort so, dass alle Sicherheitsbelange gebührlich beachtet werden. Zudem ist das Feld der Netzwerksicherheit relativ groß und verlangt Know-how in Sachen Anlegen von VPCs und ihren Subnetzen, Routing, Firewalls und Flow-Log-Analyse oder Threat-Detection. Wir stellen daher im Folgenden diese zentralen Sicherheitstechniken in der Google Cloud Platform (GCP) dar.
Mehr Sicherheit mit Shared VPCs
Shared VPCs sind eine Weiterentwicklung der VPCs. Letztere können Admins auf einfache Art und Weise erstellen – mit allen denkbaren Fehlkonfigurationen. Der Ansatz von Shared VPCs ist, das Erstellen und Verwalten von VPCs an ein dediziertes Team zu delegieren. Dies entbindet Applikationsteams von der Bürde "Netzwerk-sicherheit" und erlaubt ihnen, sich dediziert um ihre Anwendung zu kümmern.
Bild 1 illustriert die Verwendung von Shared VPCs beziehungsweise einfachen VPCs. Im unteren Teil des Bildes ist eine VPC zu erkennen, die sich über zwei Regionen erstreckt. Pro Region existiert ein Subnet. Die VPC und die virtuellen Maschinen gehören zu einem Projekt und oben im Bild erkennen Sie ein dediziertes Host-Projekt. In diesem wird das Shared VPC konfiguriert und freigegeben. Den Serviceprojekten A und B ist dabei die Nutzung des Shared VPC gestattet. Das bedeutet, dass die Projekte die virtuellen Maschinen selbst betreiben und die Schnittstellen der VMs an das Shared VPC angedockt sind.
Dieser Ansatz bietet mehr Sicherheit, erhöht aber auch den Konfigurationsaufwand. Dies beginnt bei der initialen Einrichtung, bei der eine Reihe von Schritten zu erledigen sind. Zuerst sind auf Organisationsebene die Rechte "Administrator für freigegebene VPC" (compute.xpnAdmin) und "Projekt-IAM-Administrator" (resourcemanager.projectIamAdmin) erforderlich. Diese Berechtigungen vergibt ein Organisationsadministrator.
Sobald diese Berechtigungen stehen, können Sie das entsprechende Projekt mit dem Aufsetzen eines Shared VPC zu einem HubHost-Projekt aufwerten. Dazu klicken Sie in der GCP-Konsole im Menü "VPC Network / Shared VPC" auf "Set up Shared VPC". Anschließend startet ein Assistent, in dem Sie im ersten Schritt das Projekt zu einem Host-Projekt heraufstufen. Anschließend wählen Sie aus, ob Sie alle Subnets der VPCs oder nur dediziert einzelne Subnets freigeben möchten. Im dritten Schritt selektieren Sie die User, die Sie für die Subnets berechtigen wollen. Konkret bedeutet dies, die Rolle "Netzwerknutzer" (compute.network.User) zu vergeben. Die Projekte, in denen diese Nutzer beziehungsweise Service-Accounts beheimatet sind, werden durch den Freigabeprozess anschließend zu Service-Projekten.
VPCs mit Firewalls absichern
Sobald Sie Ihre VPCs erstellt haben, kümmern Sie sich um deren Absicherung. Ein wichtiger Baustein sind dabei Firewallregeln. Gerade hier hat Google in den letzten Jahren massiv aufgerüstet, sodass es unterschiedliche Firewalltypen gibt:
- VPC-Firewallregeln gelten für ein bestimmtes Projekt und Netzwerk.
- Firewallrichtlinien gruppieren mehrere Firewallregeln, um sie gleichzeitig zu aktualisieren. Diese Regeln landen so auf einem Richtlinienobjekt, das Sie auf unterschiedliche Art und Weise anwenden können: Global, regional oder auf Organisationelemente wie Ordner oder Projekte.
- Relativ neu sind die Cloud-Firewalls, die zusätzliche Features wie Stateful Inspection, Adressgruppen oder Regeln auf Ebene von FQDNs anbieten.
Die Firewallregeln lassen sich auch in Kombination nutzen. Wichtig ist dabei der Ablauf der Auflösung dieser Regeln: Zuerst wird für die Netzwerkkommunikation überprüft, ob es eine Regel auf Organisationsebene gibt. Ist dies der Fall, wird der Netzwerkverkehr entweder erlaubt oder verweigert. Anschließend erfolgt ein Check auf Ordnerebene. Liegen dort keine Regeln vor, kommen die VPC-Firewallregeln zum Tragen. Als Nächstes kommen die globalen Regeln zur Geltung. Existieren diese ebenfalls nicht, geht es mit den regionalen Regeln weiter. Zu guter Letzt zählen die impliziten Regeln, die besagen, dass ausgehender Verkehr standardmäßig erlaubt und jeglicher eingehender Verkehr untersagt ist.
Beim Erstellen einer VPC-Firewallregel müssen Sie einige Attribute setzen. Dies erledigen Sie entweder in der Google-Cloud-Konsole in der entsprechenden VPC auf der Karteikarte "Firewalls" im Menü "VPC Networks / VPC Networks" oder alternativ unter "VPC Networks / Firewall". Für das Anlegen einer Regel ist Input notwendig:
- Zuerst benötigen Sie einen Namen. Firewallregeln sollten dabei möglichst sprechend sein und es lohnt sich, die Policies nach Use Case zu erstellen und nicht zu feingranular hinsichtlich einzelner Ports oder IP-Adressen vorzugehen.
- Im "Description"-Feld beschreiben Sie die Regel genauer.
- Bei Bedarf schalten Sie die Firewall-Logs ein. Diese helfen bei der Auswertung des Netzwerkverkehrs und beim Troubleshooting. Allerdings können hier zusätzliche Kosten durch das Logging entstehen.
- In der Dropdown-Liste "Network" geben Sie die VPC an, auf die die Firewallregel wirken soll.
- Unter "Priorität" geben Sie eine Nummer ein. Standardmäßig ist 1000 eingetragen. Kleinere Nummern werden als Erstes abgearbeitet.
- Mit "Actions on Match" bestimmen Sie, ob der Netzwerkverkehr gestattet (Allow) oder verweigert (Deny) wird.
Nun legen Sie das Target fest, auf das die Firewallregel wirken soll. Dies können entweder alle Instanzen in einem Netzwerk oder nur bestimmte Maschinen mit Tag oder gewissen Service Accounts sein. Bei der Verwendung von Tags gilt es zu beachten, dass Sie sie nicht erzwingen können. Jeder Benutzer, der eine Maschine administrieren kann, darf beliebige Tags auf der VM vergeben. Bei Service Accounts ist es dagegen nur möglich, diejenigen mit einer VM zu verwenden, die über die entsprechenden Rechte verfügen. Service Accounts bei VMs lassen sich dabei nur ändern, wenn die Maschine gestoppt ist. Dementsprechend ist der zweite Ansatz restriktiver in Sachen Sicherheit.
Haben Sie eine Regel für eingehenden Netzwerkverkehr gesetzt, konfigurieren Sie nun den Source-Filter. Dies können IPv4- beziehungsweise IPv6-Ranges, Tags oder Service Accounts sein. Bei ausgehendem Verkehr ist der Destination-Filter zu setzen. In diesem Fall können Sie nur CIDR Ranges konfigurieren. Zum Schluss konfigurieren Sie die gewünschten Protokolle und Ports. Diese können Sie feingranular setzen oder einfach komplett alle freischalten. Nach dem Speichern der Regel gelangen Sie zurück in das Firewall-Übersichtsmenü. Dort finden Sie nun alle Regeln aufgelistet und sind in der Lage, diese nach Regel und Art zu filtern.
Neu: Firewall Essentials und Firewall Standard
Google hat im Herbst 2022 auf seiner Hausmesse Google Next eine Reihe von Ankündigungen in Sachen Netzwerksicherheit gemacht – dazu gehören auch die neuen Produkte "Cloud Firewall Essentials" und "Cloud Firewall Standard". Diese umfassen die bisherigen VPC-Firewallregeln und ergänzen diese.
Ein interessantes zusätzliches Feature ist die Tag-Integration. Bei diesen Tags handelt es sich aber nicht um die zuvor beschriebenen Netzwerk-Tags, die bei VPC-Firewallregeln zum Einsatz kommen, sondern um Resource-Manager-Tags. Diese haben den Vorteil, dass Sie diese über IAM berechtigen. So ist es beispielsweise möglich, ein Tag mit dem Schlüssel "vm-function" zu erstellen und dazu eine Liste möglicher Werte wie "database", "app-client" oder "app-server" anzulegen. Anschließend vergeben Sie Berechtigungen auf diese Tags. So ließe sich etwa Datenbank-Administratoren die Rolle "Tag User" für den Tag mit dem Wert "database" vergeben. Damit ist es dem entsprechenden Admin möglich, eine VM mit dem Tag zu starten und den Datenbankverkehr zu gestatten.
Standardmäßig sind Firewall-Regeln "stateful", das heißt, wenn die Verbindung in eine Richtung geöffnet ist, ist automatisch der Rück-Netzwerkverkehr erlaubt. Für das Troubleshooting ist an dieser Stelle interessant, ob dieser rückläufige Netzwerktraffic ankommt und ob er auch analysierbar ist. Dies ist generell mit den Firewall Logs möglich.
Neu sind Adressengruppen, die helfen, wenn Sie eine Reihe von Hosts, IP-Adressen oder ganze Netzwerk-Ranges vielfach in Benutzung haben. In diesem Fall sollten Sie möglichst vermeiden, diese Elemente in jeder Regel aktuell halten zu müssen, falls es zu einer Änderung kommt. Mit Adressengruppen ist es möglich, die Gruppen einmalig zu pflegen und in Firewallregeln zu referenzieren.
Einige der genannten Features sind Cloud Firewall Standard vorenthalten, sodass hier zusätzliche Kosten anfallen können. So etwa bei der Nutzung des Threat-Intelligence-Modules, mit dem Sie Traffic basierend auf verschiedenen Kategorien blockieren. Dies sind zum Beispiel bekannte schädliche IP-Adressen und Domains. Des Weiteren gibt es nunmehr einen erweiterten Schutz mit FQDN-Objekten. Diese ermöglichen das dynamische Updaten von Firewallregeln, auch wenn sich die zugrunde liegenden IP-Adressen ändern. Auch das Einbinden von Standortbestimmung für Firewallregeln ist nun möglich. Damit verwalten Sie den Netzwerkverkehr basierend auf dessen Ursprungsland. Ein derartiges Feature war bisher nur in einer Web Application Firewall integriert.
IT-Administrator Sonderheft "Cloud Security"
Der Gang in die Cloud bringt für Unternehmen ganz neue Anforderungen an die IT-Sicherheit mit sich. In unserem neuen Sonderheft "Cloud Security" zeigt das Autorenteam daher Wege auf, AWS, Azure, GCP und lokale Clouds vor unbefugten Zugriffen und Datenverlust zu schützen. Auf 180 Seiten stellt das Sonderheft praxisnahe Vorgehensweisen zur Absicherung von Infrastruktur, Applikationen und Identitäten auf.
Im Detail betrachten wir die Sicherheitsfeatures der drei großen Plattformen von Amazon, Google und Microsoft und wie Administratoren diese einsetzen, um etwa Zugriffe von Anwendern und Externen zu steuern. Gleichzeitig zeigen wir, welche Werkzeuge zur Verfügung stehen, um die eigene Cloud zu härten, zu überwachen und sicher mit anderen public Clouds zu verbinden. Nicht zu kurz kommt aber auch die Absicherung der lokalen Cloud. Dabei schildern die Autoren, welche Maßnahmen vSphere, Hyper-V und Open-Source-Virtualisierung nachhaltig schützen.Das Sonderheft ist ab Ende April 2023 verfügbar und kostet für Abonnenten des IT-Administrator 24,90 Euro, für Nicht-Abonnenten werden 29,90 Euro fällig.
Sicher ins Internet mit Cloud NAT
Benötigt eine virtuelle Maschine Zugriff auf das Internet, müssen Sie (in der einfachsten Form) eine Reihe von Elementen einrichten. Zunächst konfigurieren Sie eine Route auf das Internet-Gateway. Dies erledigen Sie, indem Sie eine Route auf die CIDR-Range "0.0.0.0/0" mit "Next Hop Internet Gateway" festlegen. Dann müssen Sie die virtuelle Maschine mit einer externen IP-Adresse ausstatten.
Diese Konfiguration führt dazu, dass virtuelle Maschinen direkt im Internet erreichbar sind und dies ist aus Sicherheitsgründen nicht immer erwünscht. Gestatten Sie ausgehende Internetzugriffe, bringen Sie NAT an den Start. Dies konfigurieren Sie entweder selbst oder greifen auf den Dienst "Cloud NAT" zurück. Dabei stellt Cloud NAT Internetkonnektivität für die folgenden Services bereit:
- Compute Engine
- Private Google Kubernetes Engine (GKE) Cluster
- Cloud Run über Serverless VPC Access
- Cloud Function über Serverless VPC Access
- App Engine über Serverless VPC Access
Cloud NAT ist dabei ein Managed Service und bietet als solcher eine Hochverfügbarkeit von mindestens 99,9 Prozent. Er ist zudem regional gegen den Ausfall einer Zone resilient. Bild 3 zeigt den Einsatz von Cloud NAT in einem weltweiten Set-up mit den zwei Regionen "us-east1" und "europe-west1". Pro Region und VPC ist eine Cloud-NAT-Instanz eingerichtet. Dabei kann eine solche Instanz für die ganze VPC Internetkonnektivität bereitstellen (wie im Bild auf der rechten Seite dargestellt) oder nur für einzelne Subnetze (Subnet1 in der Region us-east1).
Um Cloud NAT einzurichten, müssen Sie die folgenden Schritte durchführen: Zuerst wechseln Sie links im Menü im Bereich "Networking" auf die Seite "Network services / Cloud NAT". Legen Sie zum ersten Mal im Projekt eine Cloud-NAT-Instanz an, klicken Sie auf den Link "Get Started". Sobald der Assistent gestartet ist, vergeben Sie einen Namen für Ihre Instanz.
Anschließend wählen Sie die VPC aus, zu der sich Cloud NAT verbinden soll. Nun konfigurieren Sie eine Region und legen dann den zu nutzenden Cloudrouter fest. Dabei integriert sich Cloud NAT in den Cloudrouter, um darüber Routen zu veröffentlichen. Schließlich definieren Sie, welche Subnets in den Genuss des NAT-Routers kommen. Es können einzelne Subnetze oder die ganze VPC sein. Zusätzlich können Sie festlegen, welche Secondary Ranges Cloud NAT nutzen dürfen. Secondary Ranges kommen beispielsweise zum Einsatz, wenn eine VM mehrere IP-Adressen in Beschlag nimmt – Beispiele sind hier VMs mit Docker oder Kubernetes-Cluster, bei denen jeder Pod eine IP-Adresse aus der VPC erhält.
Mit VMs auf das Internet zugreifen
Mit dem Einsatz von Cloud NAT können Sie auf öffentliche IP-Adressen für den Internetzugriff verzichten. Sollen ausschließlich Google-Services erreicht werden, lässt sich auch auf Cloud NAT verzichten. Zwar haben viele Google-Dienste öffentliche IP-Adressen, es ist aber so, dass Google eine Technik mit dem Namen "Private Google Access" bereitstellt, um auf diese direkt aus einer VPC zuzugreifen. Dafür sind nur entsprechende DNS-Einträge und Routing notwendig.
Konkret gibt es DNS-Domänen, für die Sie private Zonen einrichten müssen. So enden die meisten Google-APIs mit der Domäne "googleapis.com". Entsprechend können Sie im "Cloud DNS" eine Zone für "googleapis.com" anlegen. In der Zone richten Sie anschließend einen A-Eintrag für die IP-Adressen "199.36.153.8", "199.36.153.9", "199.36.153.10" und "199.36.153.11" ein.
Zusätzlich benötigen Sie einen CNAME-Eintrag für "*.googleapis.com", der auf den erstellten A-Eintrag deutet. Nun fehlt nur noch das Routing. Dazu gehen Sie auf die Administrationsseite der VPC, wechseln auf die Karteikarte "Routing" und fügen eine Route mit dem Ziel "0.0. 0.0/0" ein, dessen nächster Hop das Standard-Internetgateway ist.
Serverless Workloads schützen
Neben virtuellen Maschinen benötigt von Zeit zu Zeit auch Serverless Workloads (Cloud Functions, Cloud Run oder App Engine) Zugriff auf eine VPC. Oft geht dies auch mit dem Wunsch einher, sämtlichen Netzwerkverkehr vom Internet zu isolieren. Ersteres erledigen Sie mit "VPC Serverless Access" und die zweite Anforderung ist zumindest für Cloud Functions und Cloud Run umsetzbar. Dabei müssen Sie zuerst ein /28-Subnet in der entsprechenden VPC reservieren.
Anschließend stellen Sie darauf basierend den "Serverless VPC Access Connector" bereit. Mit dessen Hilfe greifen Sie schlussendlich auf VPC-Ressourcen, Managed Google Ressourcen wie Cloud SQL oder Memory mit privaten IP-Adressen oder auf lokale Netze zu, wenn eine hybride Konnektivität vorhanden ist. Sobald der Serverless VPC Access Connector steht, schärfen Sie in Sachen Security nach. Denn nun ist es möglich, dass sämtlicher eingehender und ausgehender Netzwerkverkehr nur noch über den Connector laufen darf und somit der Zugriff über öffentliche IP-Adressen unterbunden ist.
Private Service Connect einsetzen
Eine weitere spannende Weiterentwicklung ist Private Service Connect (PSC). Kurz gesagt wird dabei in einer VPC ein Endpunkt erstellt, der einen Dienst außerhalb der VPC abstrahiert. Dabei erfolgt der Zugriff über interne IP-Adressen und ist somit gut kontrollierbar. Dafür gibt es eine Reihe von Anwendungsfällen.
Als Erstes der Private Service Connect für den Zugriff auf Google APIs: Dieser Ansatz ähnelt dem Private Google Access, aber mit dem Unterschied, dass sämtlicher Netzwerkverkehr in der VPC privat ist und keine Route auf das Internet-Gateway konfiguriert werden muss, um auf Google-APIs zuzugreifen. Entsprechend erstellen Sie einen "Private Service Connect Endpoint" für die zuvor beschriebenen Google-API-Bundles. Zusätzlich hinterlegen Sie im DNS noch sprechende Namen für die einzelnen Dienste, wie zum Beispiel "storage-vialink1.p.googleapis.com".
Einen Schritt weiter gehen PSC-Endpunkte mit HTTP(S)-Nutzerdienstkontrollen. Dabei wird zusätzlich ein HTTP(S)-Loadbalancer erstellt. Für diesen können Sie granular steuern, welche URLs gemappt werden sollen und wie diese veröffentlicht sein sollen. Darüber hinaus sind Sie in der Lage, eigene Zertifikate zum Zugriff auf Google Services einzuspielen und lokale Services über den Loadbalancer verfügbar zu machen.
Die dritte Möglichkeit besteht darin, mittels PSC-Endpunkten eigene Dienste bereitzustellen oder für andere konsumierbar zu machen. Dies ist auch über VPCs, Projekte, Regionen und Organisationen hinweg möglich. Technisch läuft dies wie bei den anderen Varianten mit einer Netzwerkadressübersetzung (NAT), die dabei im Hintergrund entsteht. Auf Seiten des Bereitstellers (Producer VPC) erzeugen Sie dabei einen HTTPS(S)-Loadbalancer samt Backend und veröffentlichen diesen mittels eines Service-Attachments. Nun kann der Konsument diesen Dienst nutzen.
Monitoring und Logging
Zur Netzwerksicherheit gehört auch das Monitoring, für das Google eine Reihe von Bordmitteln bereitstellt. Wir werfen an dieser Stelle insbesondere einen Blick auf "VPC Flow Logs" und "Firewall Logs". VPC Flow Logs zeichnen eine Stichprobe von Netzwerkdaten auf, die virtuelle Maschinen verursachen. Diese Informationen sind hilfreich beim Netzwerkmonitoring, der Forensik, bei Echtzeit-Sicherheitsanalysen und der Kostenoptimierung.
VPC Flow Logs müssen Sie aktivieren, und zwar für jedes Subnet in einer VPC. VPC Flow Logs Datensätze umfassen immer eine Reihe von Attributen:
- Informationen zur IP-Verbindung, wie das verwendete Protokoll, die Quell-IP-Adresse, die Ziel-IP-Adresse sowie Quell- beziehungsweise Zielport.
- Informationen zu der Virtuellen Maschine (Instance Details).
- Daten zum VPC (VpcDetails)
Je nach verwendetem Dienst gibt es zusätzliche Felder – im Fall von GKE für den Cluster, den Service und den Pod. Da VPC Flow Logs von Fall zu Fall viele Daten erzeugt, gibt es die Möglichkeit einer Filterung – dabei können Sie sogar Expressions nutzen. Das folgende Beispiel beschränkt die Logerfassung auf eine VM mit dem Namen "my-vm", bei dem entweder das Ziel oder die Quelle "my-vm" ist:
gcloud compute networks subnets update my-subnet \
--logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance. vm_name == 'my-vm' && reporter== 'DEST')"
Die Analyse erfolgt anschließend in Cloud Logging.
Für das Troubleshooting interessant sind die Firewall-Logs. So stellen Sie zum Beispiel fest, ob eine Firewallregel, die Traffic abweisen soll, wie vorgesehen funktioniert oder welche Verbindungen von einer Firewallregel betroffen sind. Ähnlich wie die VPC Flow Logs müssen Sie die Firewall Logs erst aktivieren. Dies kann für alle Firewalls in einer VPC oder für einzelne Firewall-Regeln geschehen.
Ist dies geschehen, haben Sie in Cloud Logging Zugriff auf die erzeugten Logdaten. Beispielsweise holen Sie sich mit folgender Abfrage die Firewall-Logs zu einer VM auf den Bildschirm:
resource.type="gce_subnetwork"
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall"
jsonPayload.instance.vm_name="INSTANCE_ID"
Fazit
Die Netzwerksicherheit sollte auch in der Google Cloud Plattform groß geschrieben werden. Wir haben einen ausführlichen Blick auf den Einsatz von VPCs geworfen und gezeigt, wie Sie mit den entsprechenden Bordmitteln Sicherheit in Ihrer Cloudumgebung schaffen.
(jp)