Netzwerksicherheit in der Google Cloud Platform (1)

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.

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.

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 das VPC an, auf das 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.

ln/jp/Dr. Guido Söldner

Im zweiten Teil der Workshopserie geht es um den Unterschied zwischen den Firewalls Essentials und Standard. Außerdem zeigen wir, wie virtuelle Maschinen mit Cloud NAT sicher ins Internet kommen. Im dritten und letzten Teil beschreiben wir, wie Sie Serverless Workloads schützen, Private Service Connect einsetzen und ein effizientes Monitoring und Logging betreiben.