VPC Service Controls – BigQuery Protection-Codelab I

1. Einführung

In diesem Codelab erfahren Sie, wie Sie die BigQuery API mit VPC Service Controls schützen. Im Codelab ist zu Beginn kein API-Dienst durch den Dienstperimeter geschützt. So können Abfragen für öffentliche Datasets ausgeführt und die Ergebnisse in einer Projekttabelle gespeichert werden. Die Abfrage wird in einem Projekt ausgeführt und die Tabelle, in der die Ergebnisse gespeichert werden, wird in einem anderen Projekt erstellt. So wird eine Einrichtung simuliert, in der Daten in einem Projekt gespeichert werden können, aber über ein anderes Projekt aufgerufen werden müssen.

Als Nächstes führen wir einen Dienstperimeter ein, um das Datenprojekt zu schützen. Sie erfahren, wie Sie beobachtete Verstöße mithilfe von Regeln für ein- und ausgehenden Traffic beheben und später eine Zugriffsebene hinzufügen, um den Zugriff über interne IP-Adressen einzuschränken. Die Ziele dieses Codelabs sind:

• Sie erfahren, wie Sie Verstöße gegen ein- und ausgehenden Traffic mithilfe von Regeln für ein- und ausgehenden Traffic beheben.
• Sie können nachvollziehen, warum ein bestimmter Verstoß aufgetreten ist.
• Umfang der angewendeten Behebung des Verstoßes analysieren
• Ändern Sie die Korrektur (Regel für eingehenden / ausgehenden Traffic), um ihren Umfang zu ändern. Verwenden Sie dazu die Option, Traffic von internen IP-Adressen in einem VPC-Netzwerk mithilfe von Zugriffsebenen zuzulassen.

2. Einrichtung und Anforderungen für Ressourcen

Hinweis

In diesem Codelab gehen wir davon aus, dass Sie bereits Folgendes wissen:

• BigQuery-Abfrage ausführen: In diesem Codelab erfahren Sie, wie Sie den Wikipedia-Datensatz in BigQuery abfragen.
• Ordner erstellen und verwalten
• Projekt in einem Ordner erstellen oder vorhandenes Projekt in einen Ordner verschieben
• Bereichszugriffsrichtlinie erstellen
• Dienstperimeter erstellen und konfigurieren
• Sicherheitsrichtlinienverstöße in den Logs finden

Einrichtung

Unsere Ersteinrichtung ist so konzipiert:

Wenn Sie das VPC Service Controls-Basistutorial durchlaufen haben, können Sie dieselben Projekte, denselben Ordner und denselben Dienstperimeter wiederverwenden.

• Eine Google Cloud-Organisation.
• Ein Ordner in der Organisation. In diesem Codelab nennen wir sie codelab-folder.
• Zwei Google Cloud-Projekte im selben Ordner, codelab-folder. In diesem Codelab nennen wir sie project-1 und project-2
  .
  • Wenn Sie den Ordner und die Projekte noch nicht erstellt haben, erstellen Sie in der Google Cloud Console einen Ordner unter der Organisation und zwei neue Projekte unter diesem Ordner.
• Die erforderlichen Berechtigungen:
  • IAM-Rollen für die Verwaltung von Ordnern: auf Ordnerebene zugewiesen
  • IAM-Rollen zum Verwalten von Projekten: auf Projektebene zugewiesen
  • IAM-Rollen, die für die Konfiguration von VPC Service Controls erforderlich sind: auf Organisationsebene zugewiesen
  • IAM-Rollen für die Verwaltung von BigQuery: auf Projektebene zugewiesen
  • IAM-Rollen zum Verwalten von Compute Engine-Instanzen: auf Projektebene zugewiesen
• Rechnungskonto für beide Projekte, project-2 und project-1.

Für dieses Codelab können Sie sich selbst die folgenden vordefinierten Rollen zuweisen: Ordneradministrator und Projektersteller (auf Ordnerebene), Inhaber (auf Projektebene), BigQuery-Administrator (auf Projektebene) und Access Context Manager-Administrator (auf Organisationsebene). Damit haben Sie die erforderlichen Rollen, um die für dieses Codelab benötigten Ressourcen einzurichten.

Regulären Dienstperimeter erstellen

In diesem Codelab verwenden wir einen regulären Dienstperimeter, der project-1 schützt.

• Erstellen Sie einen regulären Perimeter perimeter-1 und fügen Sie die project-1 hinzu.

Schränken Sie im Perimeter noch keinen Dienst ein. Wir machen das später.

Compute Engine-VM erstellen

In diesem Codelab verwenden wir eine Compute Engine-Instanz in project-2, die sich in us-central1 befindet und das Standard-VPC-Netzwerk mit dem Namen default verwendet.

• Sie können die Dokumentation als Richtlinie zum Erstellen einer Compute Engine-Instanz aus einem öffentlichen Image verwenden.

In diesem Codelab verwenden wir das Standard-VPC-Netzwerk mit dem Namen default. Sie können auch ein anderes Netzwerk verwenden, sofern es mindestens ein Subnetz hat.

Kosten

Sie müssen die Abrechnung in der Google Cloud Console aktivieren, um Cloud-Ressourcen oder APIs zu verwenden. Wir empfehlen, verwendete Ressourcen herunterzufahren, um zu vermeiden, dass Ihnen nach diesem Codelab Kosten in Rechnung gestellt werden. Neue Google Cloud-Nutzer können am Programm für den kostenlosen Testzeitraum mit einem Guthaben von 300 $teilnehmen.

Die Ressourcen, für die Kosten anfallen, sind BigQuery und die Compute Engine-Instanz. Sie können die Kosten mit dem BigQuery-Preisrechner und dem Compute Engine-Preisrechner schätzen.

3. Zugriff auf BigQuery ohne VPC Service Controls-Einschränkungen

Öffentliches Dataset abfragen und Ergebnisse in project-1 speichern

1. Rufen Sie project-2 und project-1 auf, um zu prüfen, ob Sie auf die BigQuery API zugreifen können. Besuchen Sie dazu die Seite BigQuery Studio. Das sollte möglich sein, da project-1 zwar in einem Dienstperimeter enthalten ist, dieser aber noch keinen Dienst schützt.
2. Führen Sie in project-2 die folgende Abfrage aus, um ein öffentliches Dataset abzufragen.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

Nachdem Sie die Abfrage für das öffentliche Dataset ausgeführt haben (während Sie in project-2 bleiben):

1. Klicken Sie auf Ergebnisse speichern und wählen Sie die BigQuery-Tabelle aus. (siehe Screenshot unten).
2. Wählen Sie project-1 als Zielprojekt aus.
3. Benennen Sie das Dataset codelab_dataset. Wählen Sie NEUES DATASET ERSTELLEN aus, sofern Sie kein vorhandenes Dataset verwenden.
4. Geben Sie der Tabelle den Namen codelab-table.
5. Klicken Sie auf Speichern.

Die Daten des öffentlichen Datasets wurden nach Ausführung der Abfrage aus project-2 erfolgreich in project-1 gespeichert.

Dataset in project-1 über project-2 abfragen

Führen Sie in project-2 BigQuery Studio die folgende Abfrage aus, um Daten aus folgenden Quellen auszuwählen:

• Projekt: project-1
• Dataset: codelab_dataset
• Tabelle: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Die Abfrage sollte erfolgreich ausgeführt werden, da weder project-2 noch project-1 die Verwendung von BigQuery einschränken. Der Zugriff auf BigQuery ist von überall aus möglich, sofern der Nutzer die entsprechenden IAM-Berechtigungen hat.

 In diesem Diagramm wird der Prozess veranschaulicht, wenn ein Prinzipal ein BigQuery-Dataset abfragt. Mit jeder BigQuery-Abfrage wird ein BigQuery-Job gestartet, der dann den eigentlichen Vorgang ausführt, in diesem Fall das Abrufen von Daten. Der Zugriff des Principals wird anhand einer Compute Engine-Instanz und über das Internet demonstriert, während Abfragen aus einem öffentlichen Dataset und aus einem separaten Google Cloud-Projekt erfolgen. Der Prozess zum Abfragen der Daten (GetData) wird erfolgreich ausgeführt, ohne von VPC Service Controls blockiert zu werden.

4. BigQuery API im Quell-Dataset-Projekt schützen

Ändern Sie die Konfiguration des Perimeters perimeter-1 und schränken Sie den Dienst BigQuery API zusammen mit der geschützten Ressource project-1 ein.

Erzwingung des Dienstperimeters prüfen

Führen Sie in project-2 die folgende Abfrage in BigQuery Studio aus, wie im vorherigen Schritt beschrieben:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Es tritt ein Verstoß gegen VPC Service Controls RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER auf.

Das Audit-Log für den Verstoß befindet sich in project-1, da dort der Verstoß gegen den Perimeter aufgetreten ist. Logs können mit der beobachteten vpcServiceControlsUniqueId gefiltert werden (ersetzen Sie VPC_SC_DENIAL_UNIQUE_ID durch die beobachtete eindeutige ID).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

Der Verstoß ist ein egressViolations mit:

• principalEmail: [Nutzerkonto, mit dem die Abfrage ausgeführt wird]
• callerIp: [Die IP-Adresse des User-Agents, der die Anfrage ausführt]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. Verstoß beheben, um BigQuery-Job zu erstellen

Der VPC Service Controls-Verstoß hat bigquery.jobs.create als Zielberechtigung, was an der Funktionsweise von BigQuery liegt. Wenn Sie die Google Cloud Console (oder das bq-Befehlszeilentool) zum Verwalten von BigQuery-Daten verwenden, erstellt BigQuery Jobs, mit denen die gewünschten Aktionen ausgeführt werden. Das erste Ereignis ist das Erstellen eines BigQuery-Jobs.

In diesem Diagramm wird veranschaulicht, wann ein Prinzipal eine Abfrage für einen Datensatz in project-1 über project-2 ausführt. Der Vorgang zum Erstellen eines BigQuery-Jobs aus dem Dataset-Projekt (project-1) in dem Projekt, in dem die Abfrage ausgeführt wird (project-2), schlägt mit einem VPC Service Controls-Ausgangsverstoß fehl, da der Dienstperimeter perimeter-1 die BigQuery API schützt. Wenn der Perimeter eingerichtet ist, kann keine BigQuery API-Anfrage von project-1 aus nach außerhalb des Perimeters oder von außerhalb des Perimeters an das geschützte Projekt gesendet werden, sofern dies nicht durch die Dienstperimeterkonfigurationen zugelassen ist.

Ein Verstoß gegen die Ausgangsregeln kann behoben werden, indem Sie eine Ausgangsregel erstellen, die auf Folgendem basiert:

• Quelle (VON): E-Mail-Adresse des Nutzers und Kontext (z. B. IP-Adresse des Anrufers, Gerätestatus, Standort usw.)
• Ziel (TO): die Zielressource, der Zieldienst und die Zielmethode oder ‑berechtigung.

Um den beobachteten Verstoß gegen die Ausgangsregel zu beheben, erstellen Sie eine Ausgangsregel, die Traffic zur targetResource (project-2) durch das Nutzerkonto, das die Abfrage ausführt ([e-mail]), für den BigQuery-Dienst und die Methode/ Berechtigung bigquery.jobs.create zulässt.

Erwartetes Verhalten der konfigurierten Regel für ausgehenden Traffic:

• FROM | Identitäten: Nur die angegebene Identität [e-mail] darf die Perimetergrenze überschreiten.
• TO | projects: Die angegebene Identität kann die Perimetergrenzen nur überschreiten, wenn das Ziel das angegebene Projekt project-2 ist.
• TO | Services: Die angegebene Identität kann Traffic außerhalb des Perimeters nur dann zum angegebenen Projekt initiieren, wenn der API-Aufruf für den angegebenen Dienst und die angegebene Methode erfolgt. Andernfalls, z. B. wenn sie einen anderen Dienst ausprobieren, der durch den Dienstperimeter geschützt ist, wird der Vorgang blockiert, da andere Dienste nicht zulässig sind.

Korrektur testen: Regel für ausgehenden Traffic

Führen Sie dieselbe Abfrage aus, nachdem die Regel für ausgehenden Traffic eingerichtet wurde.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Es kommt zu einem weiteren Verstoß, diesmal zu einem NO_MATCHING_ACCESS_LEVEL-Eingangsverstoß. Die neue Richtlinienverletzung unterscheidet sich von der ersten in Bezug auf das Zielprojekt und die Methode.

Wenn Sie einen VPC Service Controls-Verstoß beheben, bedeutet das nicht, dass keine weiteren Verstöße auftreten. Ein neuer API-Aufruf mit einem Kontext, der sich von den Kontexten unterscheidet, die durch die bereits konfigurierte Richtlinie zugelassen werden, führt zu einem anderen Verstoß.

Der neue Verstoß ist ein Verstoß bei eingehendem Traffic mit

• principalEmail: [Nutzerkonto, mit dem die Abfrage ausgeführt wird]
• callerIp: [Die IP-Adresse des User-Agents, der die Anfrage ausführt]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

Der Verstoß für die Methode bigquery.tables.getData ist auf einen API-Aufruf zurückzuführen, der vom BigQuery-Job initiiert wurde, um Daten aus der BigQuery-Tabelle abzurufen.

Es ist wichtig, die Funktionsweise eines bestimmten API-Dienstes zu verstehen, um erwartete Verstöße vorherzusehen.

6. Verstoß beheben, um BigQuery-Tabellendaten zu erhalten

Mit einer Ingress-Regel wird ein Ingress-Verstoß behoben. Gleichzeitig wird eine detaillierte Steuerung ermöglicht, wer die Dienstperimetergrenze überschreiten darf, sowie des Kontexts des zulässigen Zugriffs, z. B. des Quell- oder Zielprojekts und der API-Methode, auf die zugegriffen werden kann.

Ein Verstoß gegen die Regeln für eingehenden Traffic wird durch eine Regel für eingehenden Traffic behoben, die mit Folgendem konfiguriert ist:

• Quelle (VON): E-Mail-Adresse des Nutzers und Kontext (z. B. IP-Adresse des Anrufers, Gerätestatus, Standort usw.)
• Ziel (TO): die Zielressource, der Zieldienst und die Zielmethode oder ‑berechtigung.

Die Regel für eingehenden Traffic lässt Traffic von dem angegebenen Nutzer für den angegebenen Dienst und die angegebene Methode in Richtung project-1 zu.

Erwartetes Verhalten der konfigurierten Regel für eingehenden Traffic:

• FROM | Identitäten: Nur die angegebene Identität [e-mail] darf die Perimetergrenze überschreiten.
• TO | projects: Die angegebene Identität kann Perimetergrenzen nur überschreiten, wenn das Ziel das angegebene Projekt project-1 ist.
• AN | Dienste: Die angegebene Identität kann nur dann Traffic innerhalb des Perimeters initiieren, wenn der API-Aufruf für die BigQuery API und die angegebene Methode bigquery.tables.getData erfolgt.

Die Ausführung der identischen Abfrage sollte fortan ohne VPC Service Controls-Verstöße funktionieren.

Wir haben die BigQuery API in project-1 erfolgreich eingeschränkt, sodass sie nur von [e-mail] und nicht von [e-mail] verwendet werden kann.

 In diesem Diagramm wird veranschaulicht, wie zwei verschiedene Identitäten versuchen, dasselbe Dataset abzufragen. Der Zugriff durch [e-mail] (blaue gepunktete Linien) wird von VPC Service Controls verweigert, da sie aufgrund der Dienstperimeterkonfiguration keine BigQuery-Vorgänge von oder zu project-1 ausführen dürfen. Der Zugriff durch [e-mail] (grüne durchgezogene Linie) ist erfolgreich, da die VPC Service Controls-Konfigurationen es zulassen, dass Vorgänge von und zu project-1 ausgeführt werden.

7. Durch den Serviceperimeter zulässigen Traffic anhand der internen IP-Adresse einschränken

Mit der aktuellen Konfiguration kann der angegebene Nutzer von jedem Ort aus Abfragen für BigQuery in project-1 ausführen, sofern er die IAM-Berechtigung zum Abfragen der Daten hat und sein Konto verwendet. Aus Sicherheitssicht bedeutet dies, dass jeder, der Zugriff auf das Konto erhält, auch ohne zusätzliche Einschränkungen auf die BigQuery-Daten zugreifen kann, wenn das Konto gehackt wird.

Weitere Einschränkungen können durch die Verwendung von Zugriffsebenen in Regeln für ein- und ausgehenden Traffic implementiert werden, um den Nutzerkontext anzugeben. Sie können beispielsweise Zugriff basierend auf der Quell-IP-Adresse in Verbindung mit einer zuvor konfigurierten Regel für eingehenden Traffic zulassen, die den Zugriff anhand der Anruferidentität autorisiert. Der Zugriff über die Quell-IP ist sowohl für öffentliche IP-CIDR-Bereiche möglich, sofern dem Nutzerclient eine öffentliche IP zugewiesen ist, als auch über eine interne IP-Adresse, wenn der Nutzerclient in einem Google Cloud-Projekt ausgeführt wird.

Zugriffsebene mit einer Zugriffsbedingung für interne IP-Adressen erstellen

Öffnen Sie im selben Ordner mit der Richtlinie für eingeschränkten Zugriff die Access Context Manager-Seite, um eine Zugriffsebene zu erstellen.

1. Wählen Sie auf der Seite „Access Context Manager“ die Option ZUGRIFFSEBENE ERSTELLEN aus.
2. Im Bereich „Neue Zugriffsebene“:
   1. Geben Sie einen Titel an. Sie können codelab-al verwenden.
   2. Klicken Sie im Abschnitt „Bedingungen“ auf IP-Subnetzwerke.
   3. Wählen Sie den Tab Private IP aus und klicken Sie auf VPC-NETZWERKE AUSWÄHLEN.
   4. Im Bereich VPC-Netzwerke hinzufügen können Sie entweder nach dem Netzwerk default suchen oder den vollständigen Netzwerknamen im Format //compute.googleapis.com/projects/project-2/global/networks/default manuell eingeben.
   5. Klicken Sie auf VPC-Netzwerk hinzufügen.
   6. Klicken Sie auf IP-Subnetze auswählen.
   7. Wählen Sie die Region aus, in der sich die VM-Instanz befindet. In diesem Codelab ist es us-central1.
   8. Klicken Sie auf SPEICHERN.

Wir haben eine Zugriffsebene erstellt, die noch nicht für einen Perimeter oder eine Ein-/Ausgangsrichtlinie erzwungen wird.

Zugriffsebene der Regel für eingehenden Traffic hinzufügen

Damit der durch die Regel für eingehenden Traffic zugelassene Nutzer auch anhand der Zugriffsebene überprüft wird, muss die Zugriffsebene in der Regel für eingehenden Traffic konfiguriert werden. Die Ingress-Regel, die den Zugriff auf Abfragedaten autorisiert, befindet sich in perimeter-1. Ändern Sie die Regel für eingehenden Traffic so, dass die Quelle als Zugriffsebene codelab-al definiert wird.

Neue Konfigurationen testen

Nachdem die Zugriffsebene in der Ingress-Regel hinzugefügt wurde, schlägt dieselbe BigQuery-Abfrage fehl, sofern sie nicht vom Client im VPC-Netzwerk default für das Projekt project-2 ausgeführt wird. Um dieses Verhalten zu überprüfen, führen Sie die Abfrage über die Google Cloud Console aus, während das Endpunktgerät mit dem Internet verbunden ist. Die Abfrage wird mit einem Hinweis auf einen Ingress-Verstoß beendet.

Standard:

• Der Zugriffsbereich einer Compute Engine-Instanz ist standardmäßig auf Standardzugriff festgelegt, der keinen Zugriff auf die BigQuery API ermöglicht.
• An eine Compute Engine-Instanz ist das Compute Engine-Standarddienstkonto angehängt. Alle Befehle, die auf der VM ausgeführt werden, werden als dieses Dienstkonto ausgeführt, das das Format [e-mail] haben muss.
   Sowohl der Zugriffsbereich als auch das an die VM angehängte Dienstkonto können geändert werden.

Dieselbe Abfrage kann über das VPC-Netzwerk default in project-2 ausgeführt werden. Ebenso schlägt die Ausführung derselben BigQuery-Abfrage von einer Compute Engine-Instanz in project-2 mit dem VPC-Netzwerk default fehl. Das liegt daran, dass die Regel für eingehenden Traffic weiterhin so konfiguriert ist, dass nur das Hauptkonto [e-mail] zugelassen ist. Die VM verwendet jedoch das Compute Engine-Standarddienstkonto.

Damit Sie denselben Befehl erfolgreich über die Compute Engine-Instanz in project-2 ausführen können,müssen folgende Voraussetzungen erfüllt sein:

• Die VM hat Zugriffsbereiche für die Verwendung der BigQuery API. Dazu wählen Sie Uneingeschränkten Zugriff auf alle Cloud APIs zulassen als Zugriffsbereich für die VM aus.
• Das Dienstkonto, das an die VM angehängt ist, benötigt die IAM-Berechtigungen für Folgendes:
  • BigQuery-Jobs in project-2 erstellen
  • BigQuery-Daten aus der BigQuery-Tabelle in project-1 abrufen
• Das Compute Engine-Standarddienstkonto muss durch die Ingress- und Egress-Regel zugelassen werden.

Jetzt müssen wir das Compute Engine-Standarddienstkonto in den Regeln für eingehenden Traffic (um das Abrufen von Daten aus der BigQuery-Tabelle zu ermöglichen) und in der Regel für ausgehenden Traffic (um das Erstellen von BigQuery-Jobs zu ermöglichen) hinzufügen.

Führen Sie auf einer Compute Engine-Instanz in project-2 im VPC-Netzwerk default den folgenden bq-Abfragebefehl aus:

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

Mit der aktuellen Konfiguration ist der BigQuery-Befehl nur erfolgreich, wenn:

• auf einer VM mit dem Standard-VPC-Netzwerk in project-2 ausgeführt werden und
• in der angegebenen Region us-central1 (IP-Subnetz) und
• mit dem im Dienstperimeter konfigurierten Compute Engine-Standarddienstkonto ausgeführt werden.

Die BigQuery-Befehlsabfrage schlägt fehl, wenn sie von einem anderen Ort aus ausgeführt wird, z. B.:

• wenn sie auf einer VM mit dem Standard-VPC-Netzwerk in project-2 ausgeführt wird, sich aber in einer anderen Region als das in der Zugriffsebene hinzugefügte Subnetz befindet, oder
• wenn sie vom Nutzer [e-mail] mit einem Nutzerclient im Internet ausgeführt wird.

 In diesem Diagramm wird der Zugriff dargestellt, der vom selben Prinzipal, [e-mail], von zwei verschiedenen Standorten aus initiiert wird: dem Internet und einer Compute Engine-Instanz. Der direkte Zugriff auf BigQuery über das Internet (blaue gepunktete Linien) wird durch VPC Service Controls blockiert, während der Zugriff über eine VM (grüne durchgezogene Linien) unter Verwendung des Compute Engine-Standarddienstkontos zulässig ist. Der zulässige Zugriff ist darauf zurückzuführen, dass der Dienstperimeter so konfiguriert ist, dass der Zugriff auf geschützte Ressourcen über eine interne IP-Adresse zulässig ist.

8. Bereinigen

Für die Verwendung von VPC Service Controls fallen keine gesonderten Gebühren an, wenn der Dienst nicht verwendet wird. Es empfiehlt sich jedoch, die in diesem Lab verwendete Einrichtung zu bereinigen. Sie können auch die VM-Instanz und die BigQuery-Datasets oder Google Cloud-Projekte löschen, um Gebühren zu vermeiden. Wenn Sie das Cloud-Projekt löschen, wird die Abrechnung für alle in diesem Projekt verwendeten Ressourcen beendet.

• Führen Sie die folgenden Schritte aus, um die VM-Instanz zu löschen:
  • Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
  • Klicken Sie auf das Kästchen links neben dem Namen der VM-Instanz und wählen Sie dann Löschen aus. Klicken Sie zur Bestätigung noch einmal auf Löschen.
• So löschen Sie den Dienstperimeter:
  • Wählen Sie in der Google Cloud Console Sicherheit und dann VPC Service Controls auf der Ebene aus, auf der die Zugriffsrichtlinie festgelegt ist. In diesem Fall ist das die Ordnerebene.
  • Klicken Sie auf der Seite „VPC Service Controls“ in der Tabellenzeile für den Perimeter, den Sie löschen möchten, auf Löschen.
• So löschen Sie die Zugriffsebene:
  • Öffnen Sie in der Google Cloud Console die Seite Access Context Manager im Ordnerbereich.
  • Suchen Sie im Raster die Zeile für die Zugriffsebene, die Sie löschen möchten, wählen Sie das Dreipunkt-Menü und dann Löschen aus.
• So fahren Sie die Projekte herunter:
  • Rufen Sie in der Google Cloud Console die Seite IAM- und Verwaltungseinstellungen des Projekts auf, das Sie löschen möchten.
  • Wählen Sie auf der Seite „IAM & Admin-Einstellungen“ die Option Herunterfahren aus.
  • Geben Sie die Projekt-ID ein und wählen Sie Trotzdem beenden aus.

9. Glückwunsch!

In diesem Codelab haben Sie einen VPC Service Controls-Perimeter erstellt, ihn erzwungen und Fehler behoben.

Weitere Informationen

Sie können auch die folgenden Szenarien ausprobieren:

• Führen Sie dieselbe Abfrage für das öffentliche Dataset aus, nachdem das Projekt durch VPC Service Controls geschützt wurde.
• Fügen Sie project-2 im selben Perimeter wie project-1 hinzu.
• Fügen Sie project-2 in einem eigenen Perimeter hinzu und behalten Sie project-1 im aktuellen Perimeter bei.
• Führen Sie Abfragen aus, um Daten in der Tabelle zu aktualisieren, nicht nur um Daten abzurufen.

Lizenz

Dieser Text ist mit einer Creative Commons Attribution 2.0 Generic License lizenziert.