Im Rahmen eines aktuellen Projektes helfen wir einer Bank dabei, ihre Applikationen in die Google Cloud zu migrieren. Eines unserer Teams war damit betraut, zusammen mit den Netzwerk-Experten der Bank das Netzwerk innerhalb der Cloud zu entwickeln sowie die Anbindung an die Kernbanksysteme zu designen. Diese sollten vorerst in den bankeigenen Rechenzentren verbleiben, weshalb sich für das Zielbild ein sogenanntes Hybrid Cloud Setup als beste Wahl herausgestellt hat.

Aufbau des Hybridnetzwerkes

Die Designgrundlagen der Hybrid Cloud Architektur waren die jeweiligen Anforderungen der bankeigenen Applikationen in der Cloud mit Bezug auf genutzte Google Services, benötigte Anbindungen an on-premise Services insbesondere bezüglich Bandbreite und Latenz sowie übergreifende Anforderungen im Bezug auf High Availability, Disaster Recovery und die Fähigkeit in Zukunft weiter Skalieren zu können. Hinzu kommen hier die bankenaufsichtlichen Anforderungen an die IT der BaFin, welche sich zu Teilen aus den Empfehlungen des BSI speisen. Gesondert ist hier auf die geforderte Georedunzanz von Rechenzentren zu verweisen, welche auch in einem Cloud Set-Up beachtet werden muss. Es erfolgt dementsprechend eine Nutzung von mindestens zwei Rechenzentren mit einem Mindestabstand von über 10 Kilometern.

Weitere Designparameter für das Netzwerk in der Cloud wurden wie folgt festgelegt:

• • Die genutzten Netzwerke (VPCs, Virtual Private Cloud) in der Cloud sollen zentral verwaltet und hochgradig standardisiert werden.
  • Das VPC Design muss einzelne Umgebungen (Development, Test, Produktion) abbilden können sowie langfristig skalierbar sein
  • Jegliche Kommunikation zwischen VPCs in der Cloud und on-premise Routing (VRF) muss explizit freigegeben werden. Traffic zwischen Netzwerkzonen wird über die on-premise Firewall (FW) geroutet
  • Egress Internet-Verbindungen werden über die bestehende on-premise Proxy Infrastruktur geroutet. Ein Routing über die Cloud direkt soll in einer weiteren Ausbaustufe erfolgen
  • Ingress Internet Verbindungen werden über Apigee als zentrales API Gateway geroutet

Anbindung bestehender Rechenzentren mittels Dedicated Interconnect

Auf Basis der Anforderungen einer Verfügbarkeit von mindestens 99,99% wurde schnell die Entscheidung der Anbindung mittels Dedicated Interconnect  ins Auge gefasst. Die Nutzung eines Dedicated Interconnects ermöglicht eine direkte Verbindung der zwei vorhandenen Rechenzentren der Bank mit dem GCP Netzwerk an von Google bereitgestellten Peering Locations. Im Zielbild ergaben sich entsprechend der Google Best Practices die folgenden Ressourcen:

• • 4 Dedicated Interconnect Verbindungen, in zwei unterschiedlichen Regionen. Innerhalb einer Region wurden beide Interconnects in jeweils eine eigene Availability Zone gelegt.
  • Insgesamt 4 Cloud Router, jeweils zwei pro Region und dementsprechende VLAN Attachments
  • Jeweils zwei Router je eigenem Rechenzentrum zur Abbildung des Produktionsnetzes und anderer Nicht-Produktionsnetze

Somit konnten wir mittels Dedicated Interconnect nicht nur die direkten Anforderungen der Applikationen bezüglich latenzarmer Anbindung der Kernsysteme erfüllen, sondern auch die allgemeineren Anforderungen der Bank und des Regulators.

Nutzung eines zentralen Shared VPC innerhalb der GCP

Um den Anforderungen zu entsprechen, die Netzwerkverwaltung zu zentralisieren und gewisse Standards zu erzwingen, wurde für jede Umgebung ein zentrales Projekt angelegt, welches gleichzeitig auch als Host Projekt fungiert und den Dedicated Interconnect Service beinhaltet. In diesem Host Projekt wird ein globales Shared VPC sowie je Umgebung für die einzelnen Applikationen Subnetze definiert. Diese Subnetze können die Applikationen für ihre Infrastruktur in ihren eigenen Service Projekten nutzen. Gleichfalls können die Systeme innerhalb des VPC alle Services on-premise sowie innerhalb der Cloud erreichen. Die Absicherung erfolgt hierbei über Firewallregeln entweder mittels TAG oder basierend auf Service Accounts. Dieser Ansatz folgt Google’s Best Practice für große Unternehmen.

Dies ermöglicht einerseits die zentrale Steuerung von Subnetzen, Routen, Firewalls und weiteren Netzwerkressourcen innerhalb eines dedizierten Netzwerkteams und andererseits Aufgaben bezüglich Applikationsinstanzen wie Compute Engine und Kubernetes Cluster bei den jeweiligen Applikationsteams zu belassen. Taktische VPC Peerings erlauben Zugriff auf spezielle Services wie Kubernetes Cluster Master, welche noch nicht in Shared VPCs integriert sind. Zukünftig soll hierfür Private Service Connect zum Einsatz kommen.

Verhinderung von Data Exfiltration mittels eines VPC Service Perimeter je Umgebung

Zur Verhinderung von Data Exfiltration wird um jede Umgebung ein VPC Service Perimeter gezogen. Dieser verhindert Verbindungen zwischen Projekten unterschiedlicher Umgebungen sowie mit Projekten außerhalb der Organisation. Problematisch zeigt sich hier, dass noch nicht alle Services die Nutzung des VPC Service Perimeter unterstützen (z.B. Cloud Shell). Diese werden nur nach detaillierter Risikobetrachtung und explizit durch ein zentrales Team freigeschaltet.

Beispielhaftes Netzwerksetup für eine Applikation

Unsere Beispiel-Applikation wird als Service innerhalb eines Kubernetes Clusters gehostet. Client Anfragen werden am globalen LB terminiert, welcher mittels Cloud Armor WAF zusätzlich abgesichert ist und weiterleitet zu Apigee. Apigee wird als zentrales API Gateway genutzt, welches sämtliche externen Schnittstellen der Bank exponiert. Innerhalb Apigee erfolgt eine JWT Prüfung, bevor der Request zum jeweiligen Workload Cluster weitergeleitet wird.

Die GKE Cluster nutzen Anthos Service Mesh (Google’s gemanagte Version von Istio) zum Routing der jeweiligen Anfragen, welches zusätzlich am Ingress Gateway eine erneute JWT Prüfung durchführt. Bei Bedarf erfolgt der Aufruf von on-premise Applikationen über den Dedicated Interconnect.

Die BaFin Anforderungen einer zweifachen DMZ werden über die logische Aufrufreihenfolge erfüllt. Die „obere“ DMZ bildet Apigee und die vorgeschalteten Loadbalancern, die „untere“ DMZ die Cluster mit jeweiligem Service Mesh.

Fazit

Das oben abgebildete Hybrid Cloud Setup hat uns grundlegend in die Lage versetzt, Applikationen in der Cloud zu betreiben, welche auf die Anwendungen zugreifen, die weiterhin in bank-eigenen Rechenzentren liegen. Die jeweiligen Anforderungen an Ausfallsicherheit und Georedundanz bei gleichzeitig akzeptabler Latenz konnten aufgrund des sehr gut ausgebauten Google Netzwerkes sichergestellt werden. Nichtsdestotrotz bleibt zu sagen, dass ein zentrales SharedVPC verwaltet von einem dedizierten Netzwerkteam zwar Vorteile bezüglich Standardisierung bringt, dieses allerdings auch schnell zu einem Bottleneck werden kann. Einerseits bezüglich zu geringer Kapazität im Netzwerkteam, andererseits bezüglich festgesetzter Quotas innerhalb der GCP, welche nur mittels spezieller Anfragen erhöht werden konnten.