Netzwerksicherheit in der Google Cloud Platform (1)

Table of Contents:

Tags:

Virtual Private Clouds erlauben in der Google Cloud Platform das schnelle und einfache Anlegen selbst komplexer Netzwerkinfrastrukturen. Doch wie jeder IT-Verantwortliche bestätigen wird, bedeutet schnell nicht immer auch richtig – und das ist in der Cloud insbesondere in Sachen Security ein Problem. In diesem Workshop zeigen wir daher, welche Bordmittel für Sicherheit sorgen. Im ersten Teil erklären wir das Konzept der Shared VPCs und wie Sie Virtual Private Clouds mit Firewalls absichern.

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 „Netzwerksicherheit“ 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 ein VPC zu erkennen, das sich über zwei Regionen erstreckt. Pro Region existiert ein Subnet. Das 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.

Bild 1: Die Architektur einer Shared VPC (oben) im Vergleich zu einer klassischen VPC (unten).
Bild 1: Die Architektur einer Shared VPC (oben) im Vergleich zu einer klassischen VPC (unten).
 

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 „Setup 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 etwa Ordner.
  • 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.

Autor

Dr. Guido Söldner

Geschäftsführer

Guido Söldner ist Geschäftsführer und Principal Consultant bei Söldner Consult. Sein Themenfeld umfasst Cloud Infrastruktur, Automatisierung und DevOps, Kubernetes, Machine Learning und Enterprise Programmierung mit Spring.