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. Das Codelab beginnt ohne einen durch den Dienstperimeter geschützten API-Dienst. Dadurch können Abfragen in öffentlichen 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. Dabei wird eine Konfiguration nachgeahmt, bei der Daten in einem Projekt gespeichert werden können, aber über ein anderes Projekt aufgerufen werden muss.

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 eingehenden und ausgehenden Traffic beheben und später eine Zugriffsebene hinzufügen, um den Zugriff über interne IP-Adressen einzuschränken. Mit diesem Codelab werden folgende Ziele erreicht:

• Informationen zum Beheben von Verstößen gegen ein- und ausgehenden Traffic mithilfe von Regeln für eingehenden und ausgehenden Traffic
• Nachvollziehen, warum ein bestimmter Verstoß aufgetreten ist
• Analysieren Sie den Umfang der angewendeten Korrektur von Verstößen.
• Ändern Sie die Korrektur (Regel für eingehenden / ausgehenden Traffic), um den Bereich zu ändern. Nutzen Sie dazu die Option, Traffic von internen IP-Adressen in einem VPC-Netzwerk mithilfe von Zugriffsebenen zuzulassen.

2. Einrichtung und Anforderungen von Ressourcen

Hinweis

In diesem Codelab gehen wir davon aus, dass Sie bereits mit Folgendem vertraut sind:

• Grundlagen zum Ausführen einer BigQuery-Abfrage: In diesem Codelab erfahren Sie, wie Sie ein Wikipedia-Dataset in BigQuery abfragen.
• Ordner erstellen und verwalten
• Projekt in einem Ordner erstellen oder vorhandenes Projekt in einen Ordner verschieben
• Richtlinien für den eingeschränkten Zugriff erstellen
• Dienstperimeter erstellen und konfigurieren
• Sicherheitsrichtlinienverstöße in den Logs finden

Einrichtung

Die Ersteinrichtung sieht so aus:

Wenn Sie die grundlegende Anleitung zu VPC Service Controls durchgearbeitet haben, können Sie dieselben Projekte, Ordner und Dienstperimeter wiederverwenden.

• Eine Google Cloud-Organisation.
• Ein Ordner in der Organisation. In diesem Codelab nennen wir sie codelab-folder.
• Zwei Google Cloud-Projekte werden im selben Ordner (codelab-folder) abgelegt. 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 erstellen Sie zwei neue Projekte unter diesem Ordner.
• Erforderliche Berechtigungen:
  • IAM-Rollen zum Verwalten von Ordnern: auf Ordnerebene zugewiesen
  • IAM-Rollen zum Verwalten von Projekten: werden auf Projektebene zugewiesen
  • Zum Konfigurieren von VPC Service Controls erforderliche IAM-Rollen: auf Organisationsebene zugewiesen
  • IAM-Rollen für die Verwaltung von BigQuery: auf Projektebene zugewiesen
  • IAM-Rollen zum Verwalten der Compute Engine-Instanz: auf Projektebene zugewiesen
• Rechnungskonto für beide Projekte, project-2 und project-1.

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

Regulären Dienstperimeter erstellen

In diesem Codelab verwenden wir einen regulären Dienstperimeter zum Schutz von project-1.

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

Schränken Sie im Perimeter noch keine Dienste ein. Das tun wir 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 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 default. Sie können auch ein beliebiges anderes Netzwerk verwenden, solange das Netzwerk mindestens ein Subnetzwerk hat.

Kosten

Sie müssen die Abrechnung in der Google Cloud Console aktivieren, um Cloud-Ressourcen/APIs verwenden zu können. Wir empfehlen, verwendete Ressourcen zu deaktivieren, damit über dieses Codelab hinaus keine Kosten anfallen. Neue Google Cloud-Nutzer haben Anspruch auf das kostenlose Testprogramm mit 300 $Guthaben.

Die Kosten für die Ressourcen 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 Einschränkungen für VPC Service Controls

Öffentliches Dataset abfragen und Ergebnisse in project-1 speichern

1. Rufen Sie project-2 und project-1 auf und prüfen Sie auf der Seite BigQuery Studio, ob Sie auf die BigQuery API zugreifen können. Das sollte möglich sein, denn selbst wenn sich project-1 in einem Dienstperimeter befindet, schützt der Perimeter noch keinen Dienst.
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. Nennen Sie das Dataset codelab_dataset. (Wählen Sie NEUES DATASET ERSTELLEN aus, sofern Sie kein vorhandenes Dataset verwenden.)
4. Benennen Sie die Tabelle so: codelab-table.
5. Klicken Sie auf Speichern.

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

Abfrage-Dataset in project-1 aus project-2 gespeichert

Führen Sie in BigQuery Studio project-2 die folgende Abfrage aus, um Daten 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 auf die Verwendung von BigQuery beschränkt ist. Der Zugriff auf BigQuery ist von überall aus erlaubt, solange der Nutzer die entsprechenden IAM-Berechtigungen hat.

Dieses Diagramm veranschaulicht den Vorgang, wenn ein Hauptkonto ein BigQuery-Dataset abfragt. Mit jeder BigQuery-Abfrage wird ein BigQuery-Job initiiert, der dann den tatsächlichen Vorgang ausführt, in diesem Szenario und das Abrufen von Daten. Der Hauptzugriff wird über eine Compute Engine-Instanz und das Internet während der Abfrage aus einem öffentlichen Dataset und einem separaten Google Cloud-Projekt demonstriert. Der Prozess zum Abfragen der Daten (GetData) ist erfolgreich, wird aber nicht von VPC Service Controls blockiert.

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

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

Erzwingung von Dienstperimetern prüfen

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

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

Ein RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER-Verstoß gegen VPC Service Controls tritt auf

Das Audit-Log zu Verstößen befindet sich in project-1, da der Verstoß dort aufgetreten ist, der den Perimeter überschreitet. 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, das die Abfrage ausführt]
• callerIp: [Die IP-Adresse des User-Agents, der die Abfrage 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 einen BigQuery-Job zu erstellen

Aufgrund der Funktionsweise von BigQuery ist für den VPC Service Controls-Verstoß die Zielberechtigung bigquery.jobs.create. Wenn Sie BigQuery-Daten mit der Google Cloud Console (oder dem bq-Befehlszeilentool) verwalten, erstellt BigQuery Jobs, die dann verwendet werden, um die gewünschten Aktionen auszuführen. Das erste Ereignis besteht darin, einen BigQuery-Job zu erstellen.

Dieses Diagramm zeigt, wann ein Hauptkonto eine Abfrage aus project-2 für ein Dataset in project-1 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-Verstoß gegen ausgehenden Traffic fehl, da die BigQuery API im Dienstperimeter geschützt wird perimeter-1. Wenn der Perimeter eingerichtet ist, kann keine BigQuery API-Anfrage von project-1, die sich außerhalb des Perimeters befindet, oder von außerhalb zum geschützten Projekt initiiert werden. es sei denn, dies ist in den Dienstperimeterkonfigurationen erlaubt.

Ein Verstoß gegen ausgehenden Traffic kann behoben werden, indem eine Regel für ausgehenden Traffic erstellt wird, die auf Folgendem basiert:

• Quelle (FROM): E-Mail-Adresse und Kontext des Nutzers (z. B. IP-Adresse des Anrufers, Gerätestatus, Standort usw.)
• Ziel (TO): Zielressource, -dienst und -methode oder -berechtigung.

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

Erwartetes Verhalten der konfigurierten Ausgangsregel:

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

Lösung testen: Regel für ausgehenden Traffic

Führen Sie die gleiche Abfrage aus, sobald die Ausgangsregel eingerichtet ist.

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

Ein weiterer Verstoß tritt auf, diesmal ein NO_MATCHING_ACCESS_LEVEL-Verstoß gegen eingehenden Traffic. Der neue Verstoß unterscheidet sich vom ersten, was das Zielprojekt und die Methode angeht.

Das Beheben eines VPC Service Controls-Verstoßes bedeutet nicht, dass keine weiteren Verstöße auftreten. Ein neuer API-Aufruf mit einem anderen Kontext als dem von der bereits konfigurierten Richtlinie zulässigen Kontext führt zu einem anderen Verstoß.

Der neue Verstoß ist ein Verstoß gegen

• principalEmail: [Nutzerkonto, das die Abfrage ausführt]
• callerIp: [Die IP-Adresse des User-Agents, der die Abfrage 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, der versucht, Daten aus der BigQuery-Tabelle abzurufen.

Es ist wichtig zu verstehen, wie ein bestimmter API-Dienst funktioniert, um erwartete Verstöße vorhersehen zu können.

6. Verstoß beheben, um BigQuery-Tabellendaten abzurufen

Eine Regel für eingehenden Traffic behebt einen Verstoß gegen eingehenden Traffic und bietet eine detaillierte Kontrolle darüber, wer die Perimetergrenze überschreiten darf. Dies gilt auch im Kontext des zulässigen Zugriffs, z. B. das Quell-/Zielprojekt und die API-Methode, auf die sie zugreifen können.

Ein Verstoß gegen eingehenden Traffic wird durch eine Regel für eingehenden Traffic behoben, die wie folgt konfiguriert ist:

• Quelle (FROM): E-Mail-Adresse und Kontext des Nutzers (z. B. IP-Adresse des Anrufers, Gerätestatus, Standort usw.)
• Ziel (TO): Zielressource, -dienst und -methode oder -berechtigung.

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

Erwartetes Verhalten der konfigurierten Regel für eingehenden Traffic:

• VON | Identitäten: Nur die angegebene Identität [e-mail] darf die Perimetergrenze überschreiten.
• AN | Projekte: Die angegebene Identität kann nur dann Perimetergrenzen ü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 daher ohne VPC Service Controls-Verstöße ordnungsgemäß funktionieren.

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

Dieses Diagramm zeigt, wie zwei verschiedene Hauptkonten versuchen, dasselbe Dataset abzufragen. Der Zugriff über [e-mail] (blaue Linien) wird von VPC Service Controls verweigert, da sie gemäß der Dienstperimeterkonfiguration keine BigQuery-Vorgänge von oder in Richtung project-1 ausführen dürfen. Der Zugriff über [e-mail] (grüne durchgezogene Linie) ist erfolgreich, da VPC Service Controls-Konfigurationen erlauben, Vorgänge von und in Richtung project-1 auszuführen.

7. Vom Dienstperimeter zugelassenen Traffic basierend auf der internen IP-Adresse einschränken

Die aktuelle Konfiguration ermöglicht dem angegebenen Nutzer, Abfragen in BigQuery in project-1 von einem beliebigen Standort aus auszuführen. überall im Internet, wenn ihnen die IAM-Berechtigung zum Abfragen der Daten gewährt wurde und sie ihr Konto nutzen. Aus Sicherheitsgründen bedeutet dies, dass jede Person, die sich Zugriff auf das Konto verschafft, ohne zusätzliche Einschränkungen auf die BigQuery-Daten zugreifen kann, wenn das Konto gehackt wird.

Weitere Einschränkungen können mithilfe der Zugriffsebene in den Regeln für ein- und ausgehenden Traffic implementiert werden, um den Nutzerkontext anzugeben. Sie können beispielsweise den Zugriff basierend auf der Quell-IP-Adresse in Verbindung mit einer bereits konfigurierten Regel für eingehenden Traffic zulassen, die den Zugriff anhand der Identität des Anrufers autorisiert. Der Zugriff über Quell-IP-Adressen ist für beide öffentlichen IP-CIDR-Bereiche möglich, vorausgesetzt, dem Nutzerclient ist eine öffentliche IP-Adresse zugewiesen, oder durch Verwendung einer internen IP-Adresse, wenn der Nutzerclient in einem Google Cloud-Projekt ausgeführt wird.

Zugriffsebene mit einer Zugriffsbedingungen für interne IP-Adresse erstellen

Öffnen Sie im selben Ordner für Zugriffsrichtlinien die Seite „Access Context Manager“, 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. Titel angeben: Sie können codelab-al verwenden.
   2. Klicken Sie im Bereich „Bedingungen“ auf IP-Subnetzwerke.
   3. Wählen Sie den Tab Private IP-Adresse aus und klicken Sie auf VPC-NETZWERKE AUSWÄHLEN.
   4. Im Bereich VPC-Netzwerke hinzufügen können Sie entweder nach dem default-Netzwerk 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-SUBNETs 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 immer noch nicht für Perimeter oder Richtlinien für ein- und ausgehenden Traffic erzwungen wird.

Zugriffsebene zur Regel für eingehenden Traffic hinzufügen

Wenn Sie erzwingen möchten, dass der von der Regel für eingehenden Traffic zugelassene Nutzer auch anhand der Zugriffsebene verifiziert wird, müssen Sie die Zugriffsebene in der Regel für eingehenden Traffic konfigurieren. Die Regel für eingehenden Traffic, die den Zugriff auf Abfragedaten autorisiert, befindet sich in perimeter-1. Ändern Sie die Regel für eingehenden Traffic, um die Quelle als Zugriffsebene codelab-al zu definieren.

Neue Konfigurationen testen

Nachdem die Zugriffsebene in die Regel für eingehenden Traffic aufgenommen wurde, schlägt dieselbe BigQuery-Abfrage fehl, es sei denn, sie wird vom Client im VPC-Netzwerk default für das Projekt project-2 ausgeführt. 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 nicht erfolgreich beendet, zusammen mit dem Hinweis auf einen Richtlinienverstoß.

Standard:

• Der Zugriffsbereich einer Compute Engine-Instanz wird standardmäßig auf Standardzugriff eingestellt, wodurch kein Zugriff auf die BigQuery API möglich ist.
• Mit einer Compute Engine-Instanz ist das Compute Engine-Standarddienstkonto verknüpft. In der Zwischenzeit werden alle von der VM ausgeführten Befehle über dieses Dienstkonto ausgeführt, das das Format [e-mail] haben muss.
  Sowohl der Zugriffsbereich als auch das mit der VM verknüpfte Dienstkonto können geändert werden.

Dieselbe Abfrage kann über das VPC-Netzwerk default ausgeführt werden, das sich in project-2 befindet. Ebenso schlägt die Ausführung derselben BigQuery-Abfrage von einer Compute Engine-Instanz in project-2 über das 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 wird. Die VM verwendet jedoch das Compute Engine-Standarddienstkonto.

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

• Die VM hat Zugriffsbereich, um die BigQuery API zu verwenden. Wählen Sie dazu Uneingeschränkten Zugriff auf alle Cloud APIs zulassen als VM-Zugriffsbereich aus.
• Das an die VM angehängte Dienstkonto 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 von der Regel für eingehenden und ausgehenden Traffic zugelassen werden.

Jetzt müssen Sie das Compute Engine-Standarddienstkonto in den Eingangsregeln, um das Abrufen von Daten aus der BigQuery-Tabelle zu ermöglichen, und zur Ausgangsregel hinzufügen, damit BigQuery-Jobs erstellt werden können.

Führen Sie von 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;'

Bei der aktuellen Konfiguration ist der BigQuery-Befehl nur in folgenden Fällen erfolgreich:

• Ausführung auf einer VM mit dem Standard-VPC-Netzwerk in project-2 und
• sich in der angegebenen us-central1-Region (IP-Subnetzwerk) befindet und
• Sie werden mit dem Compute Engine-Standarddienstkonto ausgeführt, das im Dienstperimeter konfiguriert ist.

Die BigQuery-Befehlsabfrage schlägt fehl, wenn sie an einer anderen Stelle ausgeführt wird, einschließlich:

• Bei Ausführung auf einer VM unter Verwendung des Standard-VPC-Netzwerks in project-2, die sich jedoch in einer anderen Region als das in der Zugriffsebene hinzugefügte Subnetz befindet, oder
• Bei Ausführung durch den Nutzer [e-mail] mit einem Nutzerclient im Internet.

Dieses Diagramm zeigt den Zugriff, der vom selben Hauptkonto [e-mail] von zwei verschiedenen Standorten aus initiiert wurde: über das Internet und eine Compute Engine-Instanz. Der direkte Zugriff auf BigQuery aus dem Internet (blaue gepunktete Linien) wird durch VPC Service Controls blockiert. Der Zugriff von einer VM (grüne durchgezogene Linien) ist zulässig, während gleichzeitig die Identität des Compute Engine-Standarddienstkontos übernommen wird. Der Zugriff ist darauf zurückzuführen, dass der Dienstperimeter so konfiguriert wurde, dass der Zugriff auf geschützte Ressourcen von einer internen IP-Adresse aus möglich ist.

8. Bereinigen

Für die Nutzung von VPC Service Controls fallen keine gesonderten Kosten an, wenn der Dienst nicht genutzt wird. Es empfiehlt sich jedoch, die in diesem Labor verwendete Konfiguration zu bereinigen. Sie können auch die VM-Instanz und 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 das Kästchen links neben dem Namen der VM-Instanz an. Wählen Sie dann Löschen aus und klicken Sie zur Bestätigung noch einmal auf Löschen.
• Führen Sie die folgenden Schritte aus, um den Dienstperimeter zu löschen:
  • Wählen Sie in der Google Cloud Console Sicherheit und dann VPC Service Controls auf der Ebene aus, auf der die Zugriffsrichtlinie definiert ist, in diesem Fall auf Ordnerebene.
  • Klicken Sie auf der Seite „VPC Service Controls“ in der Tabellenzeile des Perimeters, den Sie löschen möchten, auf Löschen.
• Führen Sie die folgenden Schritte aus, um die Zugriffsebene zu löschen:
  • Öffnen Sie in der Google Cloud Console im Ordnerbereich die Seite Access Context Manager.
  • Wählen Sie im Raster die Zeile mit der Zugriffsebene aus, die Sie löschen möchten. Klicken Sie auf das Dreipunkt-Menü und dann auf Löschen.
• Führen Sie die folgenden Schritte aus, um die Projekte herunterzufahren:
  • Wechseln Sie in der Google Cloud Console zur Seite IAM & Administratoreinstellungen des Projekts, das Sie löschen möchten.
  • Auf der IAM- und Administratoreinstellungen die Option Herunterfahren aus.
  • Geben Sie die Projekt-ID ein und wählen Sie Trotzdem herunterfahren 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 sich auch die folgenden Szenarien ansehen:

• Führen Sie dieselbe Abfrage für ein öffentliches Dataset aus, nachdem das Projekt durch VPC Service Controls geschützt ist.
• Fügen Sie project-2 im selben Perimeter wie project-1 hinzu.
• Fügen Sie project-2 in einen eigenen Perimeter ein und belassen Sie project-1 im aktuellen Perimeter.
• 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.