VPC Service Controls - Eine Schritt-für-Schritt-Anleitung

Einführung

Einer der größten Vorteile eines Cloud Service Providers (CSP) ist die Möglichkeit, Ressourcen nach Bedarf zu nutzen und eine Hochgeschwindigkeitsverbindung über den ganzen Globus zu erhalten, ohne alle physischen Ressourcen kaufen und warten zu müssen. Aber wie können wir unsere Datenbestände kontrollieren, wenn es plötzlich so viele mögliche Ausstiegspunkte zu berücksichtigen gibt? Nehmen Sie zum Beispiel die Möglichkeit, mit verschiedenen Cloud-Diensten wie Cloud Storage, BigQuery, Cloud SQL usw. zu interagieren. Und haben Sie auch bedacht, dass andere Dienste wie YouTube, Drive und AdSense die gleichen APIs verwenden?

Bei der Definition einer Cloud-Umgebung werden Sie höchstwahrscheinlich ein Netzwerk (Virtual Private Cloud: VPC) konfigurieren. Eine der besten Praktiken bei der Gestaltung Ihrer Cloud-Plattform besteht darin, nur private IP-Adressen für die Rechen- und Datenressourcen (aufgeführt unter RFC-1918) zu verwenden, die nicht aus dem öffentlichen Internet aufgelöst werden können. Für den Ingress-Zugang zu Ihrer Anwendung sollten Sie Dienste wie Cloud Load Balancer bevorzugen und für den Egress zum öffentlichen Internet einen Dienst wie Cloud NAT. Dieser Ansatz wird Ihre Plattform in vielerlei Hinsicht vor externen Bedrohungen schützen, aber durch den offenen Zugang zum öffentlichen Internet sind Sie nicht vor internen Bedrohungen geschützt.

Wie Sie aus dem obigen Diagramm ersehen können, gibt es keinen Schutz davor, dass Daten über das Internet an irgendeinen Ort gesendet werden. Aus diesem Grund entscheiden sich viele Unternehmen dafür, die Nutzung von Cloud NAT zu verbieten oder einzuschränken. Dies kann zu verschiedenen Problemen für Anwendungen führen, die in gewisser Weise auf einen Internetzugang oder sogar auf den Zugriff auf Google-Dienste angewiesen sind. Für diese Szenarien können verschiedene Lösungen implementiert werden. Für den Google API-Zugang gibt es jedoch eine einfache Methode, indem Sie das Kästchen Private Google Access in dem Teilnetz aktivieren, in dem die Ressourcen bereitgestellt werden. Dadurch wird der Zugriff auf die Google-APIs für Ihre Ressourcen in diesem Teilnetz konfiguriert. Der Haken an der Sache ist, dass dadurch der Zugriff auf alle Google-APIs. Dies ist für eine Reihe von Unternehmen ein echtes Problem, wenn sie Richtlinien und Vorschriften wie GDPR, HIPAA und NIS2(/NIST) einhalten müssen.

Ziel dieses Blogs ist es, einen Einblick zu geben, wie das Risiko der Datenexfiltration durch die Kontrolle des Zugriffs auf die Google APIs weiter reduziert werden kann.

Ein Schritt in die Richtung, den Zugriff auf bestimmte Google-APIs einzuschränken, besteht darin, die Aktivierung bestimmter Dienste durch Organisationsrichtlinien von vornherein zu unterbinden. Und dann vor allem die Richtlinie namens Restrict allowed Google Cloud APIs and services. Aber das funktioniert nicht, wenn es eine Nachfrage nach einem bestimmten Dienst gibt und Sie sicherstellen müssen, dass der Zugriff nur innerhalb eines bestimmten Kontexts möglich ist. Dies ist häufig bei Unternehmen der Fall, die Daten in einem Cloud-Speicher speichern oder diese mit BigQuery analysieren, während gleichzeitig die gesetzliche Verpflichtung besteht, diese Daten zu schützen.

VPC-Dienst-Kontrollen

An dieser Stelle kommt VPC Service Controls um die Ecke. VPC Service Controls ist ein Dienst auf Organisationsebene zur Kontrolle des Zugriffs auf die verfügbaren Google APIs. Er bietet feinkörnige Kontrollen darüber, wer auf welchen Dienst zugreifen kann und in welchem Kontext. Die Implementierung von VPC Service Controls erfolgt durch die Konfiguration der Ressource auf Organisationsebene, die als Service Perimeter bezeichnet wird. Dieses Perimeter zieht eine Zugriffsgrenze um die Google APIs, für die der Zugriff kontrolliert werden muss. Wenn Sie die VPC Service Controls im Allgemeinen betrachten, können Sie sie als zusätzliche Zugriffskontrollen für die Google APIs neben den regulären Cloud IAM-Zugriffskontrollen betrachten. Das bedeutet, dass die Anwendung von VPC Service Controls über einen Perimeter eine zusätzliche Verteidigungslinie für den Zugriff auf Google APIs darstellt, die durch den Perimeter geschützt sind.

Das mag im Moment noch etwas vage erscheinen, aber im weiteren Verlauf dieses Blogs wird es klarer werden.

VPC Service Controls Bausteine

Zunächst einmal. Die Konfiguration des VPC Service Control Perimeters finden Sie in der Google Cloud Console unter dem Menüpunkt Security -> VPC Service Controls. Dies ist eine Organizational level Ressource und kann weder auf Folder noch auf Project Ebene konfiguriert werden.

Gehen wir nun die Optionen durch, die Sie beim Öffnen dieses Menüpunkts sehen können.

VPC Service Kontrolliert Ressourcen

Beginnen wir ganz oben. Sie können sofort drei Menüpunkte erkennen:

1. Ein Element namens default policy mit einem Dropdown-Pfeil
2. Ein Artikel namens Manage policies
3. Ein Artikel namens View Quota

Hierarchie

Beginnen Sie auf der rechten Seite, weil das ein wenig Licht in die Hierarchie bringt, und sehen Sie die Quoten, die für die aktuelle Richtlinie gelten. Im folgenden Diagramm versuchen wir, die Werte zu verdeutlichen, die Sie sehen, wenn Sie auf dieses Element klicken. Sie können diese Werte auch in der Dokumentation VPC Service Controls Quota nachlesen.

Richtlinien verwalten

Dies bringt uns zu Menüpunkt Nummer 2: Manage policies. Wie Sie an der Quote sehen können, gibt es einen Unterschied zwischen der Zugriffsrichtlinie der Organisation, von der es nur 1 geben kann (die Standardrichtlinie), und den Richtlinien mit einem bestimmten Geltungsbereich. Dies sind die Richtlinien, die Sie in diesem Menüpunkt verwalten können.

Eine Richtlinie erstellen oder aktualisieren

In einem typischen Unternehmen werden Sie wahrscheinlich eine Hierarchie haben, die zumindest in eine Produktions- und eine Nicht-Produktionsumgebung unterteilt ist. Dies lässt sich mit einer Hierarchieressource namens Folder bewerkstelligen. Damit haben Sie die Möglichkeit, zwei Richtlinien mit unterschiedlichen Gültigkeitsbereichen zu erstellen, eine für jeden Ordner. Bei der Erstellung einer Richtlinie kann nur entweder ein Ordner oder ein Projekt festgelegt werden. Das bedeutet automatisch, dass jeder unter dieser Richtlinie erstellte Perimeter nur Projekte enthalten kann, die sich im Geltungsbereich der Richtlinie befinden.

Erzwungener und trockener Lauf

Im vorherigen Screenshot ist default policy ausgewählt, wie oben in blau markiert. Dies wirkt sich darauf aus, wie die Perimeter-Konfiguration angewendet wird, wenn Sie auf die Schaltfläche + NEW PERIMETER klicken und unter welcher Richtlinie.

1. Erzwungener Modus
2. Trockenlauf-Modus

Die Menüpunkte tun das, was Sie von ihnen erwarten: entweder die von Ihnen konfigurierten Regeln durchsetzen oder Regeln testen, bevor sie durchgesetzt werden. Im Testmodus werden die Zugriffsprotokolle in Cloud Audit Logging angezeigt, so dass Sie sehen können, wie sich die Eingrenzung auf den Zugriff auf die Google-Dienste auswirkt, ohne diese jedoch tatsächlich zu blockieren. Dies hilft Ihnen bei der Konfiguration der entsprechenden Regeln, die Sie für die Durchsetzung der Zugriffsbeschränkungen anwenden möchten. Die Konfiguration der beiden Optionen ist ansonsten identisch.

Perimeter-Typen

Wenn Sie mit der Konfiguration Ihres Perimeters beginnen, wird der folgende Bildschirm angezeigt.

Der Name ist offensichtlich, aber was auffällt, ist die Unterscheidung zwischen einer Regular perimeter und einer Perimeter bridge. Die Auswahl Config Type ist deaktiviert, da diese festgelegt wurde, als Sie auf die Schaltfläche im Modus Enforced oder Dry run geklickt haben.

Lassen Sie mich den Unterschied zwischen diesen beiden Begrenzungsarten anhand einiger Diagramme erklären.

Regulärer Umfang

Ein regulärer Perimeter zieht eine Grenze um die GCP-Projekte oder VPC-Netzwerke, die Sie auswählen werden. Alle Ressourcen innerhalb dieses regulären Perimeters unterliegen weiterhin Cloud IAM, aber der Zugriff auf und von außerhalb des Perimeters unterliegt zusätzlichen Kontrollen. Ein wichtiger Faktor ist, dass ein GCP-Projekt oder VPC-Netzwerk nur in genau 1 regulären Service-Perimeter aufgenommen werden kann!

Das obige Diagramm zeigt eine grundlegende Einrichtung, bei der es zwei Perimeter gibt: Production Service Perimeter und DTA Service Perimeter. In diesen beiden Perimetern ist Cloud Storage erlaubt, während die regulären Cloud IAM-Berechtigungen weiterhin überprüft werden. Der Zugriff auf die Cloud Storage API, die mit Production project verknüpft ist, ist von DTA project aus nicht erlaubt.

Begrenzte Brücke

Eine Perimeter Bridge bietet die Möglichkeit, die Kommunikation zwischen den Google-Diensten über den Perimeter hinweg für die enthaltenen Ressourcen zu ermöglichen. Der Unterschied besteht darin, dass die GCP-Projekte und VPC-Netzwerke Teil von null oder mehr Perimeter-Brücken sein können. Beachten Sie, dass Sie bei der Erstellung einer Perimeter Bridge den Zweck eines Service-Perimeters zwischen diesen Projekten oder Netzwerken aufheben und sich nur auf den Schutz von Cloud IAM verlassen.

Das obige Diagramm führt zwei neue Projekte namens Production DMZ project und DTA DMZ project sowie eine Perimeter Bridge namens DMZ Service Perimeter Bridge ein. Ein typischer Anwendungsfall für die Perimeter Bridge ist, dass die Daten in der DTA-Umgebung den Produktionsdaten so weit wie möglich ähneln sollen, aber vor ihrer Verwendung anonisiert werden müssen.

Zu schützende Ressource

Nachdem Sie Ihren Perimeter-Typ ausgewählt haben, müssen Sie im nächsten Schritt die zu schützenden Ressourcen definieren.

Hier fällt auf, dass Sie Projects und VPC networks auswählen können. Die am häufigsten verwendete Ressource bei der Konfiguration eines Perimeters ist projects, seltener VPC networks. Wenn Sie Netzwerke als die zu schützende(n) Ressource(n) im Perimeter auswählen (z.B. wenn Sie eine Shared VPC einbeziehen möchten), kann dies nur für Dienste auf Netzwerkebene gelten, wie z.B. Cloud SQL. Dienste auf Projektebene, wie z.B. Cloud Storage, können zu unerwartetem Verhalten führen, da diese keine Beziehung zu den im Perimeter definierten Netzwerken haben und es keinen Diskriminator gibt, um die Zugriffsregeln von außerhalb Ihres Perimeters festzulegen.

Eingeschränkte Dienstleistungen

Die Auswahl der eingeschränkten Dienste ist der Punkt, an dem die Verwirrung für viele bereits beginnt.

In diesem Punkt können Sie entweder all services oder specific services auswählen. Die Dienste, die Sie hier auswählen, sind die Google-Dienste, deren Nutzung Sie von inside und outside aus einschränken möchten. Wenn Sie Cloud Storage als einzuschränkenden Dienst auswählen, bedeutet dies, dass dieser Dienst nicht mehr zugänglich ist, ohne dass Sie dies explizit konfigurieren: Sie haben eine Grenze für die Nutzung von Cloud Storage im Verhältnis zu dem/den Projekt(en) im Perimeter gezogen.

In der untenstehenden Abbildung sehen Sie das etwas deutlicher. Sowohl die Production project als auch die DTA project befinden sich jeweils in ihrem eigenen Service-Perimeter. Daneben befindet sich Other project, das sich entweder in der gleichen GCP-Organisation oder in einer anderen Organisation befinden kann. Wenn Sie Cloud Storage zu den eingeschränkten Diensten hinzufügen, haben Sie effektiv jeden Zugriff auf diesen Dienst blockiert. Sowohl von innerhalb als auch von außerhalb des Perimeters. Alle anderen Dienste, die nicht zu dieser Liste hinzugefügt wurden, sind weiterhin frei zugänglich und unterliegen lediglich den regulären Cloud IAM-Berechtigungen.

VPC Zugängliche Dienste

Die Verwirrung wird für die meisten noch größer, wenn sie die VPC Accessible Services auswählen. Was hat das mit den eingeschränkten Diensten zu tun?

Er wird oft ausgelöst, weil Sie hier vier Optionen wählen können.

1. Alle Dienstleistungen
2. Keine Dienstleistungen
3. Alle eingeschränkten Dienste
4. Ausgewählte Dienstleistungen

Um es deutlicher zu machen, füge ich BigQuery zu den von unserer Anwendung verwendeten Diensten aus den früheren Diagrammen hinzu. Für diese Diagramme betrachten wir das Szenario, in dem wir Cloud Storage für unsere eingeschränkten Dienste ausgewählt haben, aber nicht BigQuery. Wenn Sie sich die Diagramme genau ansehen, werden Sie feststellen, dass der Service Perimeter das Projekt teilweise überlappt, aber nicht vollständig. Dies soll verdeutlichen, welcher Dienst im Zusammenhang mit dem Projekt in die Eingrenzung einbezogen ist.

Alle Dienstleistungen

Aus dem Diagramm können Sie ersehen, dass, wenn Sie All services auswählen, dies bedeutet, dass von innerhalb des Perimeters alle Dienste zugänglich sind. Dazu gehören alle Google APIs, nicht nur BigQuery aus dem Diagramm. Der einzige Unterschied besteht darin, dass Cloud Storage nicht mehr von außerhalb des Service-Perimeters zugänglich ist.

Keine Dienstleistungen

Dieses Diagramm zeigt, dass die Auswahl von No services mehr Auswirkungen auf den Zugriff auf die Dienste von innerhalb des Service-Perimeters hat als von außerhalb des Perimeters. Das bedeutet, dass Cloud Storage in diesem Szenario überhaupt nicht zugänglich ist. BigQuery ist nur über Cloud IAM von außerhalb des Perimeters geschützt, kann aber von innerhalb des Perimeters nicht erreicht werden. Ein typischer Anwendungsfall hierfür ist der Schutz vor Datenexfiltration von innerhalb des Perimeters zu nicht zugelassenen Diensten.

Alle eingeschränkten Dienste

Dieses Diagramm zeigt, dass die Auswahl von All restricted services sicherstellt, dass Cloud Storage von innerhalb des Perimeters, aber nicht von außerhalb erreicht werden kann. BigQuery hingegen ist von außerhalb des Perimeters, aber nicht von innerhalb des Perimeters erreichbar.

Ausgewählte Dienstleistungen

Um die letzte Option etwas deutlicher zu machen, müssen wir eine Änderung in unserem Szenario vornehmen. Nehmen wir an, dass wir jetzt auch BigQuery zu unserem Restricted services hinzugefügt haben.

Für dieses Diagramm haben wir Selected services verwendet und nur Cloud Storage als den Dienst ausgewählt, der zugänglich sein sollte. Da BigQuery nun jedoch zum Serviceumfang gehört, ist er weder von innerhalb noch von außerhalb des Serviceumfangs zugänglich.

Zugangsebenen

Wir haben nun einen der verwirrendsten Teile abgedeckt, sind aber noch nicht am Ziel. Als nächstes haben Sie die Möglichkeit, eine Zugriffsebene hinzuzufügen. Beachten Sie, dass es sich hierbei um einen Singular handelt, da Sie nur eine Zugriffsebene auf der Begrenzungsebene auswählen können. Denken Sie daran, dass eine Zugriffsebene weitere Zugriffsebenen enthalten kann. Diese Zugriffsebenen werden in einem anderen Menüpunkt konfiguriert. Security -> Access Context Manager. Möglicherweise kennen Sie den Zugriffskontext-Manager bereits von anderen Sicherheitsfunktionen wie Identity Aware Proxy und diese sind in der Tat identisch.

Zugriff auf Context Manager

Der Access Context Manager bietet die Möglichkeit, Regelsätze zu konfigurieren, die für die Autorisierung angewendet werden. Dies kann als Teil der umfassenderen Zero Trust-Prinzipien betrachtet werden, die auf Netzwerk- (Zero Trust Network Access, ZTNA) und Anwendungsebene (Zero Trust Application Access, ZTAA) angewendet werden können.

Das Erstellen und Konfigurieren einer Zugriffsstufe kann eine Vielzahl von Optionen umfassen, z. B. die Angabe der IP-Bereiche, die erlaubt oder verweigert werden, und für den geografischen Kontext (anwendbar für External Application Load Balancers und Service Perimeter). Sie können auch mit anderen Access Levels kombiniert werden. Es gibt Premium-Optionen, die verfügbar sind, wenn Sie auch Lizenzen für Chrome Enterprise Premium erwerben. Damit lassen sich die Sicherheitsfunktionen noch weiter verbessern, was den Rahmen dieses Blogs bei weitem sprengen würde.

Wichtig für diesen Abschnitt ist, dass er auch die Möglichkeit bietet, den Kontext zu validieren, in dem die Anfrage an den/die durch den Service-Perimeter geschützten Dienst(e) gestellt wird.

Ingress-Politik

Die Ingress-Richtlinie wird verwendet, um granulare Regeln für den Zugriff auf Ressourcen außerhalb des Perimeters innerhalb des Perimeters anzuwenden. Das nachfolgende Diagramm veranschaulicht diesen Prozess.

Hier sehen Sie, dass die Ingress Policy auf jede Anfrage angewendet wird, die auf einen Dienst zugreifen möchte, der durch den Service Perimeter geschützt ist. Der Vorteil dieses Ansatzes gegenüber der Verwendung eines Service-Perimeters ist ein zweifacher: 1. Sie können Regeln für Projekte konfigurieren, die nicht Teil eines Service-Perimeters oder sogar außerhalb des Unternehmens sind. 2. Dies bietet die Möglichkeit eines granularen Autorisierungsprozesses, um zu bestimmen, auf welchen Dienst von außerhalb des Perimeters zugegriffen werden darf

Die Abhängigkeit von Ingress-Richtlinien bringt jedoch auch einige Nachteile mit sich. Sie müssen alle Regeln für den Zugriff von außerhalb des Service-Perimeters explizit konfigurieren. Dies betrifft nicht nur den Zugriff von anderen Projekten, sondern auch die Möglichkeit des Zugriffs auf Ressourcen über die Cloud Console und von verwalteten Diensten, die in von Google verwalteten Single-Tenant-Projekten implementiert sind. Dies kann zu einer ganzen Reihe von Tests und Versuchen führen, während Sie die Cloud Audit-Protokolle durchgehen und mithilfe des Leitfadens zur Fehlerbehebung prüfen, wie Sie das Problem lösen können.

Nach meiner persönlichen Erfahrung kann insbesondere der Fehler NETWORK_NOT_IN_SAME_PERIMETER für viel Kopfzerbrechen sorgen. Ein besonderer Fall ist, wenn die Anfragen von einer Ressource in einem Projekt kommen, das in einer Shared VPC enthalten ist, während der aktuelle Perimeter außerhalb dieser VPC liegt. Dann müssen Sie diesem Netzwerk explizit Zugriff gewähren. Ein anderer Fall ist die Nutzung eines verwalteten Dienstes wie Cloud SQL, bei dem das Netzwerk des Single Tenant-Projekts mit dem Projekt im Service-Perimeter gepaart ist. Der Trick besteht darin, herauszufinden, um welches Netzwerk es sich tatsächlich handelt, denn in den Protokollen wird der Netzwerkname als __unknown__ angezeigt.

Die Ingress-Richtlinie selbst ist ziemlich selbsterklärend.

Sie können auswählen, woher die Anfragen kommen sollen und an welchen Dienst.

Sie können die Identitäten definieren, die Sie erwarten

Sie können die Quellorte angeben, einschließlich anderer Zugriffsebenen

Sie können das/die Zielprojekt(e) angeben

Und der/die Zieldienst(e)

Für einige Dienste können Sie sogar noch spezifischer sein, indem Sie die erlaubten Methoden definieren. Dies sind Dienste wie Cloud Storage und BigQuery

Ausstiegspolitik

Zu guter Letzt ist da noch die Egress Policy. Insbesondere zum Schutz vor Datenexfiltration hilft diese Funktion bei der Einhaltung der erforderlichen Sicherheitskontrollen.

Dieses Diagramm zeigt, dass diese Egress-Richtlinie auf Anrufe von innerhalb des Perimeters nach außerhalb des Perimeters angewendet wird. Beachten Sie, dass, wenn sich die Zielressource selbst innerhalb eines Service-Perimeters befindet, in diesem Perimeter auch zusätzliche Ingress-Regeln gelten sollten, damit die Anfrage erfolgreich sein kann.

Die Konfiguration der Egress-Richtlinie selbst ist etwas weniger komplex und die Felder, die konfiguriert werden können, sind denen einer Ingress-Richtlinie sehr ähnlich.

Eine besondere Abweichung bei der Ingress-Policy ist, dass Sie bei einer Egress-Policy auch eine Ressource mit einem externen CSP, wie AWS oder Azure, angeben können.

Fazit

VPC Service Controls ist eine Technik, mit der Sie den Zugriff auf Google-APIs kontrollieren können, die andernfalls selbst im Kontext eines privaten Netzwerks mit aktiviertem Private Google Access allgemein zugänglich wären. Der Umfang geht noch ein wenig weiter, um sicherzustellen, dass diese Dienste nun vor Zugriffen von außerhalb des Perimeters geschützt werden können, so dass Sie den Datenschutz auf mehreren Ebenen durchsetzen können. Es ist jedoch oft eine wichtige Funktion, um nachweisen zu können, dass Sie Richtlinien und Vorschriften wie die GDPR und HIPAA einhalten.

Die Konfiguration von VPC Service Controls kann ziemlich komplex werden, vor allem wenn Sie mit dem Thema nicht vertraut sind und den Wald vor lauter Bäumen nicht mehr sehen. Dieser Blog soll Klarheit darüber schaffen, wie ein VPC Service Perimeter richtig konfiguriert wird, welche Teile zu konfigurieren sind und welche Überlegungen bei der Implementierung angestellt werden müssen (z.B. wann Perimeter Bridges gegenüber Ingress- und Egress-Richtlinien vorzuziehen sind). Wenn Sie weitere Fragen haben, können Sie sich gerne an uns wenden.