Netzwerksicherheit in der Google Cloud Platform (3)

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 ein 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. In dieser Konstellation 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
Zum Thema 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 Firewallregeln 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
Netzwerksicherheit wird in der Google Cloud großgeschrieben. 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. So greifen beispielweise VMs sorgenfrei auf das Internet zu, während der Administrator parallel Zugriff auf wichtige Monitoringdaten hat, die nicht nur in Sachen Security wertvoll sind.

ln/jp/Dr. Guido Söldner

Im ersten Teil des Workshops haben wir das Konzept der Shared VPCs erklärt und wie Sie Virtual Private Clouds mit Firewalls absichern. Im zweiten Teil ging es um den Unterschied zwischen den Firewalls Essentials und Standard. Außerdem haben wir gezeigt, wie virtuelle Maschinen mit Cloud NAT sicher ins Internet kommen.