Können wir Google Cloud Load Balancing vertrauen?

Während unserer Arbeit in diesem Bereich erhalten wir viele Fragen zu Sicherheit und Compliance. Da die Cloud in der digitalen Welt einen immer wichtigeren Platz einnimmt und damit auch die Cloud Service Provider (CSP), kam die Frage auf, wie sicher unsere Daten bei Google Cloud tatsächlich sind, wenn man sich deren Cloud Load Balancing-Angebot ansieht. Dies gilt insbesondere für die Lösungen, die SSL-Offloading durchführen. In diesem Blog finden Sie einige Informationen, die wir gesammelt haben, um diese Frage zu beantworten.

Zielpublikum

Dieser Blog richtet sich an ein Publikum, das Google Cloud Platform (GCP) verwendet. Das bedeutet, dass die Informationen in diesem Dokument Verweise auf technische Lösungen und Dokumentationen enthalten, die von GCP angeboten werden. Die Anwendbarkeit auf andere CSP's kann abgeleitet werden, ist aber nicht validiert.

Hintergrund

Für Unternehmen mit einem hohen Sicherheitsprofil ist es wichtig, alle Stellen zu identifizieren, an denen Daten übertragen werden, und darauf zu vertrauen, dass diese Daten nicht vom CSP verwendet werden können oder werden. Bei der Bedrohungsmodellierung kommen oft die SSL Load Balancing-Angebote ins Spiel. Die wichtigste Frage, die hier gestellt wird, ist:

"If the load balancer does the SSL offloading, how can we be sure that this data is not accessible by third parties?"

Arten von Lastverteilern

Bei der Beantwortung dieser Frage geht es zunächst darum, welche Arten von Load Balancern zur Verfügung stehen. Wenn Sie sich die Angebote ansehen, gibt es mehrere Arten von Load Balancern.

• Globaler/regionaler externer HTTP(S) Load Balancer
• Externer SSL-Proxy-Lastausgleicher
• Externer TCP-Proxy-Lastausgleicher
• Externer TCP/UDP-Netzwerk-Lastausgleicher
• Interner HTTP(S)-Lastausgleicher
• Interner TCP-Proxy-Lastausgleicher
• Interner TCP/UDP-Netzwerk-Load Balancer

Aus der Dokumentation zu diesen Load Balancern können wir entnehmen, dass nur die folgenden drei Load Balancer tatsächlich SSL-Offloading betreiben. Die anderen verarbeiten und leiten die Anfragen lediglich weiter.

• Globaler/regionaler externer HTTP(S) Load Balancer
• Externer SSL-Proxy-Lastausgleicher
• Interner HTTP(S)-Lastausgleicher

Risiko

Das Risiko beim SSL-Offloading besteht darin, dass sich die Daten zu diesem Zeitpunkt nicht mehr in einem verschlüsselten Zustand befinden und theoretisch für andere Zwecke als vorgesehen verwendet werden können. Wenn Sie sich eine sehr einfache Netzwerktopologie ansehen, wird deutlich, wo das Risiko liegt.

Die Load Balancer fungieren technisch gesehen als Man-in-the-Middle und verschieben die Vertrauensgrenze dieses Risikos vollständig in Richtung des gewählten Load Balancers mit SSL-Offloading.

Abhilfemaßnahmen

Angesichts des festgestellten Risikos müssen wir uns die möglichen Schutzmaßnahmen ansehen, die ergriffen wurden, um eine böswillige Nutzung der Daten zu verhindern. Unwahrscheinliche Quellen wären Einzelpersonen, die sich Zugang zu diesen Load Balancern verschaffen, aber viel wahrscheinlicher wären staatliche Akteure, die (per Gesetz) verlangen, dass diese Daten ohne Vorankündigung weitergeleitet/gespiegelt werden. Wir müssen uns durch die Dokumentation wühlen, um die Schutzmaßnahmen zu identifizieren, die für uns eingerichtet wurden.

Physisch

Google unternimmt große Anstrengungen, um die physische Verwundbarkeit zu verringern.

Zugang

Ein Aspekt ist der Zugriff auf die eigentliche Hardware, die in den Rechenzentren von Google läuft. Die physische Sicherheit besteht aus einem sechsstufigen Sicherheitsbereich, in dem jede Stufe immer strengere Berechtigungen erfordert, um Zugang zu erhalten. Das bedeutet, dass die Load Balancer nur für eine äußerst begrenzte Anzahl von Mitarbeitern physisch zugänglich sind. Aufgrund der technischen Gegebenheiten können sie nicht direkt auf die Daten auf den Rechnern zugreifen und alle Interaktionen werden sorgfältig überwacht, geprüft und aufgezeichnet.

Hardware

Ein weiterer Aspekt ist der der Hardware selbst. All diese Maßnahmen können nutzlos werden, wenn das Sicherheitsrisiko in eine der Hardwarekomponenten eingebaut ist. Um dieses Problem zu entschärfen, verwendet Google nur hochgradig vertrauenswürdige Anbieter für Hardwarekomponenten und integriert diese in die Serverplatinen und die Netzwerkausrüstung, die von Google selbst entwickelt wurde. Hinzu kommen die Google-eigenen Titan-Chips, die den korrekten und sicheren Betrieb aller Komponenten innerhalb des Hardware-Stacks überprüfen und sicherstellen.

Betrieb

Nachdem wir die Maßnahmen zum physischen Schutz der Hardware identifiziert haben, wenden wir uns der operativen Seite des Risikos zu. Innerhalb der operativen Seite identifizieren wir die folgenden Themen:

1. Standorte der Lastverteiler
2. Physikalische Konfiguration der Load Balancer
3. Software auf den Lastverteilern
4. Lokalität der Daten nach SSL-Offloading
5. Andere Verwendungszwecke für die Daten nach dem SSL-Offloading
6. Verbreitung der Daten über das Google-Netzwerk

Standort von Lastverteilern

Das Google-Netzwerk ist so aufgebaut, dass zwischen den Standorten, an denen sich die Cloud-Ressourcen befinden (sogenannte Regionen und Zonen), und den Standorten, an denen der Datenverkehr verarbeitet wird, der (meist) von außerhalb des Google-Netzwerks kommt, unterschieden wird. Letzteres geschieht am "Edge Point of Presence" (allgemeiner als Google Front End oder GFE bezeichnet). Dies kann in der folgenden Abbildung veranschaulicht werden.

Die Load Balancer befinden sich in den GFEs. Wie Sie in der Abbildung sehen können, bedeutet dies nicht unbedingt, dass sich diese Standorte physisch am selben geografischen Ort befinden.

Optionale Milderung

Wenn Sie sich Sorgen über den geografischen Ort machen, an dem der Datenverkehr in die GFEs von Google gelangt, können Sie sich dafür entscheiden, nur die Standard-Tier-Netzwerkoptionen von Google zu verwenden. Dies führt dazu, dass alle Anfragen von den Netzwerken des Internetanbieters verarbeitet werden und nur an dem GFE, das den konfigurierten Ressourcen am nächsten liegt, in das Google-Netzwerk gelangen. Dies kann erhebliche Auswirkungen auf die Erfahrung Ihres Dienstes haben, da er nicht mehr das Hochgeschwindigkeits-Glasfasernetzwerk von Google nutzt.

Physikalische Konfiguration der Load Balancer

Die Load Balancer, die auf den GFEs von Google eingesetzt werden, sind maßgeschneidert und vollständig nach den strengen Vorgaben von Google entwickelt. Dazu gehören die bereits erwähnten Hardwarekomponenten, einschließlich der Sicherheitsmaßnahmen in und für diese Komponenten. Nur die Komponenten, die die strengen Validierungen bestanden haben, dürfen verwendet werden.

Software auf den Lastverteilern

Auch die Software auf den Lastverteilern wurde speziell für die Verwendung auf den vorgesehenen Rechnern geschrieben und heißt Maglev. Auch wenn der Quellcode für dieses System nicht öffentlich zugänglich ist, wird die Gültigkeit dieser Software regelmäßig überprüft und in den SOC-Berichten sowie in anderen Audit-Berichten dokumentiert. Dadurch wird sichergestellt, dass die verwendete Software nicht direkt für tatsächliche Angriffe anfällig ist. Allerdings verschiebt sich dadurch die Vertrauensbasis in Richtung der Prüfer. Die Compliance-Beauftragten in Ihrem Unternehmen sollten die Gültigkeit der genannten Berichte überprüfen und den Grad des Vertrauens in die Prüfer bestimmen.

Die Load Balancer selbst sind ebenfalls mit Secure Boot durch die Titan-Chips und Binary Authorization ausgestattet, neben anderen Maßnahmen zur Verhinderung von Manipulationen beim Starten und/oder Ausführen von Instanzen.

Lokalität der Daten nach SSL-Offloading

Wenn der Datenverkehr auf den Load Balancer verlagert wird, liegen die Daten im Rohformat vor. Je nach Art der Daten kann dies bedeuten, dass sie sich in einem lesbaren Zustand befinden. Diese Rohdaten auf dem Load Balancer verbleiben jederzeit auf dem physischen Rechner, solange sie sich in diesem Zustand befinden. Wenn eine vorübergehende Speicherung dieser Daten erforderlich ist, werden sie im Ruhezustand immer verschlüsselt. Dies steht im Einklang mit den allgemeinen Sicherheitsanforderungen von Google und ist nicht optional.

Andere Verwendungszwecke für die Daten nach dem SSL-Offloading

Es gibt andere Dienste, die auf diese Daten zugreifen müssen. Einer dieser Dienste ist Cloud Armor. Je nach Art der Schutzregel prüft dieser Dienst die Daten der Anfrage, um das erwartete Ergebnis zu ermitteln. Ähnlich wie die Cloud Load Balancing-Angebote wird auch Cloud Armor auf spezieller Hardware ausgeführt und unterliegt den gleichen Sicherheitseinschränkungen und -prüfungen. Das bedeutet, dass dieselbe Vertrauensgrenze gilt und somit auch derselbe Prozess mit Ihren Compliance-Beauftragten erforderlich ist.

Verbreitung der Daten über das Google-Netzwerk

Bei Google gelten strenge Richtlinien, wenn es um Verschlüsselung geht. Das bedeutet, dass die Daten während der Übertragung immer verschlüsselt werden. Wenn sie von einem Dienst ausgelagert wurden, werden sie immer mit der virtuellen Netzwerkverschlüsselung von Google neu verschlüsselt. Dies gilt auch für die Daten, die von den Load Balancern kommen, sobald sie bereit sind, den Rechner in Richtung des vorgesehenen nächsten Dienstes zu verlassen.

Audits und Zertifizierungen

Wie in diesem Dokument bereits mehrfach erwähnt, unternimmt Google große Anstrengungen, um die Sicherheit der von ihm angebotenen Dienste zu gewährleisten. Dies geschieht durch die Einhaltung einer Fülle von Zertifizierungen und Audits, die von internen und externen Parteien in hoher Frequenz durchgeführt werden. Die Ergebnisse können im Compliance Resource Center eingesehen und/oder angefordert werden.

Beschränkungen, wenn vermieden

Es kann sein, dass die bereitgestellten Informationen Sie und/oder die Compliance-Beauftragten in Ihrem Unternehmen nicht überzeugen. Das kann eines von zwei Dingen bedeuten:

1. Wir haben uns entschieden, die Google Cloud Load Balancer-Angebote, die SSL-Offloading anbieten, nicht zu verwenden.
2. Wir leiten nur Daten weiter, die auf Anwendungsebene verschlüsselt wurden.

Wir entscheiden uns, den Load Balancer nicht zu verwenden

Wenn Sie sich dafür entscheiden, die Load Balancer-Angebote nicht zu nutzen, bedeutet dies, dass Sie nicht von allen Funktionen profitieren können, die diese Load Balancer zu bieten haben. Dazu gehören Funktionen wie der sofort einsatzbereite (D)DoS-Schutz, die Zugriffsverwaltung über Identity Aware Proxy, bevor Ihre Arbeitslasten und/oder Dienste erreicht werden, die fortschrittlicheren Sicherheitsmaßnahmen von Diensten wie Cloud Armor und BeyondCorp und andere. Das bedeutet auch, dass Sie, wenn Sie sich aufgrund der Sicherheitseinschränkungen dafür entscheiden, diese Funktionen intern zu verwalten, die Entwicklung, Wartung und Überprüfung selbst durchführen müssen.

Wir entscheiden uns für eine doppelte Verschlüsselung, um ein Scannen zu vermeiden.

Wenn Sie sich für diese Option entscheiden, erhöht sich zwangsläufig die Komplexität Ihrer Workloads. Es hängt von der Anwendung ab, die Sie erstellen und/oder verwenden werden, um Anfragen an Ihre Dienste zu stellen, ob sie selbst in der Lage ist, Verschlüsselung durchzuführen. Dies ist beispielsweise nicht ohne weiteres möglich, wenn Sie Ihren Dienst über einen Webbrowser einer breiten Öffentlichkeit zur Verfügung stellen, könnte aber für intern entwickelte Software wie mobile Anwendungen nützlich sein.

Beachten Sie, dass dies auch die Möglichkeit der Nutzung anderer fortschrittlicher Sicherheitsdienste wie Cloud Armor oder BeyondCorp einschränken kann.

Fazit

Bei der Nutzung von Cloud Service Providern müssen Sie zwangsläufig ein gewisses Vertrauen in den gewählten Cloud-Anbieter setzen. Google wird, wie wahrscheinlich alle anderen seriösen Anbieter, große Anstrengungen unternehmen, um seine Vertrauenswürdigkeit zu verdienen und zu beweisen. Dies geschieht durch häufige Audits, Compliance-Validierungen und Zertifizierungen.

Als wir die technischen Details von Google Cloud Load Balancing mit SSL-Offloading untersuchten, stellten wir fest, dass bei der Auslagerung Ihrer Daten ein Risiko besteht. Wir haben auch festgestellt, dass Google eine Reihe von Maßnahmen ergriffen hat, um die Sicherheit dieser Daten zu gewährleisten.

Auf der physischen Seite wird die Sicherheit durch Defense-in-Depth mit einem sechsstufigen Sicherheitsprotokoll, strengen Anforderungen an die verwendete Hardware und spezieller Hardware zur Überwachung des Verhaltens dieser Hardware gewährleistet. Selbst wenn Mitarbeiter mit einer entsprechenden Berechtigung auf die physischen Geräte zugreifen können, können sie nicht auf die Daten selbst zugreifen und alle Aktionen werden streng überwacht und geprüft.

Auf der operativen Seite geschieht dies durch den Einsatz spezieller Software, die ebenfalls geprüft wird. Diese wird ständig überwacht und durch Techniken wie Secure Boot und Binary Authorization sowie andere Techniken aufrechterhalten. Wenn Daten vorübergehend gespeichert werden müssen, werden diese im Ruhezustand und immer auf demselben physischen Rechner verschlüsselt. Wenn sie den Rechner verlassen, werden sie außerdem immer mit der virtuellen Netzwerkverschlüsselung von Google verschlüsselt.

Wenn Sie diese Maßnahmen nicht überzeugen, können Sie immer noch andere Lösungen in Betracht ziehen. Diese haben jedoch auch Nachteile und sollten sorgfältig abgewogen werden, da es viel Aufwand erfordert, mit den Sicherheitsmaßnahmen von Google gleichzuziehen. Das ist etwas, das Sie immer zusammen mit Ihrem Compliance Officer entscheiden sollten.

Bild von Johnathan Pendleton aus Unspash