Grundlegende Anleitung II zu VPC Service Controls – Fehlerbehebung bei Verstößen gegen ausgehenden Traffic

1. Einführung

VPC Service Controls (VPC-SC) ist eine Sicherheitskontrolle auf Organisationsebene in Google Cloud, mit der Unternehmenskunden das Risiko der Daten-Exfiltration minimieren können. VPC Service Controls bietet Zero-Trust-Zugriff auf mehrmandantenfähige Dienste. Clients können den Zugriff auf autorisierte IP-Adressen, den Clientkontext und die Geräteparameter einschränken, während sie über das Internet und andere Dienste eine Verbindung zu mehrmandantenfähigen Diensten herstellen. So lassen sich absichtliche und unbeabsichtigte Verluste reduzieren. Wie in VPC Service Controls – Basisanleitung I gesehen, können Sie mit VPC Service Controls Perimeter erstellen, die die Ressourcen und Daten von Diensten schützen, die Sie explizit angeben.

Wenn Sie VPC Service Controls Basic Tutorial I noch nicht durchgearbeitet haben, sollten Sie dort beginnen, um die erforderlichen Vorbereitungen für diese Anleitung zu haben.

In dieser Anleitung werden folgende Ziele verfolgt:

• Grundlagen von VPC Service Controls
• Dienstperimeter aktualisieren und im Probelaufmodus testen
• Zwei Dienste mit VPC Service Controls schützen
• VPC Service Controls-Verstoß gegen ausgehenden Traffic beim Auflisten eines Objekts aus Cloud Storage beheben

2. Einrichtung und Anforderungen

Für diese Anleitung sind die folgenden Voraussetzungen erforderlich:

• Google Cloud-Organisation.
• Ein Ordner unter der Organisation.
• 2 GCP-Projekte in derselben Organisation werden im Ordner abgelegt.
• Die erforderlichen Berechtigungen auf Organisationsebene.
• Rechnungskonto für beide Projekte.
• Grundlegende Anleitung zu VPC Service Controls I Einrichtung von VPC Service Controls und Access Context Manager

Ressourcen einrichten

1. Richten Sie die Ressourcen wie unter „Resources-setup“ beschrieben ein Abschnitt von VPC Service Controls – grundlegende Anleitung I
2. Prüfen Sie, ob Sie die erforderlichen Berechtigungen zum Verwalten von Cloud Storage haben.
3. In dieser Anleitung verwenden wir die Befehlszeile anstelle der Cloud Console. Richten Sie in einer der Entwicklungsumgebungen die gcloud CLI ein:

• Cloud Shell: Aktivieren Sie Cloud Shell, um ein Onlineterminal mit eingerichteter gcloud CLI zu verwenden.

Aktivieren Sie Cloud Shell, indem Sie rechts oben in der Cloud Console auf das Symbol klicken. Das Initialisieren der Sitzung kann einige Sekunden dauern. Weitere Informationen finden Sie im Cloud Shell-Leitfaden.

• Lokale Shell: Um eine lokale Entwicklungsumgebung zu verwenden, installieren und initialisieren Sie die gcloud CLI.

Kosten

Sie müssen die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/APIs verwenden zu können. Dieses Codelab ist kostengünstig. Sie können die von Ihnen erstellten Ressourcen oder das Projekt löschen, um Ressourcen herunterzufahren, um zu vermeiden, dass über diese Anleitung hinaus Kosten anfallen. Neue Google Cloud-Nutzer haben Anspruch auf das kostenlose Testprogramm mit einem Guthaben von 300 $.

Die einzigen Ressourcen, die Kosten verursachen, sind die VM-Instanz und das Cloud Storage-Objekt. Die geschätzten Kosten der VM-Instanz finden Sie im Preisrechner. Die geschätzten Kosten für Cloud Storage finden Sie in dieser Preisliste.

3. Storage-Bucket und -Objekt erstellen

Wie bereits erwähnt, werden wir die in der vorherigen Anleitung erstellten Ressourcen wiederverwenden. Fahren wir also mit der Erstellung des Cloud Storage-Buckets fort. In dieser Anleitung verwenden wir die gcloud CLI anstelle der Console.

1. Wählen Sie in der Google Console ProjectX aus. In diesem Projekt werden den Storage-Bucket und das Objekt erstellt.
2. Achten Sie darauf, dass Cloud Shell für die Verwendung von ProjectX konfiguriert ist. Führen Sie dazu den folgenden Befehl aus:

gcloud config set project PROJECT_ID

3. Führen Sie in Ihrer Entwicklungsumgebung den folgenden Befehl aus:

gcloud storage buckets create gs://BUCKET_NAME --location=us-central1

Bucket-Namen sind global eindeutig. In diesem Dokument finden Sie weitere Informationen zum Benennen Ihres Buckets.

4. Erstellen Sie ein Speicherobjekt, damit es von der VM-Instanz in ProjectZ gelesen werden kann. Wir erstellen eine TXT-Datei.

nano hello.txt 

Fügen Sie der Textdatei einen beliebigen Text hinzu.

5. Laden Sie das Objekt in den Bucket hoch.

gcloud storage cp /home/${USER}/hello.txt gs://BUCKET_NAME

6. Prüfen Sie, ob das Objekt in den Bucket hochgeladen wurde, indem Sie es auflisten.

gcloud storage ls gs://BUCKET_NAME

Sie müssen die Datei hello.txt in der Konsole sehen.

4. Cloud Storage API schützen

Im vorherigen Codelab haben wir einen Perimeter erstellt und die Compute Engine API geschützt. In diesem Codelab bearbeiten Sie den Perimeter des Probelaufmodus und fügen Cloud Storage hinzu. So können wir die Auswirkungen des Perimeterschutzes besser bestimmen, indem wir die VPC Service Controls-Verstöße in den Audit-Logs anzeigen. Die Ressourcen bleiben jedoch zugänglich, bis wir den Perimeter erzwingen.

Beim Erstellen eines regulären Perimeters wird automatisch auch ein Probelaufperimeter erstellt. Diese Datei werden wir in diesem Lab bearbeiten.

1. Wählen Sie in der Google Console Ihre Organisation aus. Auf VPC Service Controls zugreifen Achten Sie darauf, dass Sie sich im Bereich der Organisation befinden.
2. Cloud Shell öffnen und Probelaufperimeter „SuperProtection“ aktualisieren die im vorherigen Lab erstellt wurden:

gcloud access-context-manager perimeters dry-run update SuperProtection --policy=POLICY --add-restricted-services=storage.googleapis.com

3. Prüfen Sie, ob die Cloud Storage API aktualisiert wurde, indem Sie den Perimeter beschreiben

gcloud access-context-manager perimeters dry-run describe SuperProtection --policy=POLICY 

In der Ausgabe sehen Sie, dass die Cloud Storage API unter den eingeschränkten Diensten aufgeführt ist.

zusammen mit der Compute Engine API, aber mit dem Label „-vpcAccessibleServices: {}"“:

5. Prüfen, ob die Cloud Storage API geschützt ist

Prüfen Sie im Probelaufmodus, ob die Option „SuperProtection“ Der Perimeter zeigt die Ablehnung an, indem das Objekt aus der in ProjectZ erstellten VM-Instanz in ProjectX aufgelistet wird, in dem der Storage-Bucket gehostet wird.

1. Gehen Sie in der Cloud Console zur Projektauswahl, wählen Sie „ProjectZ“ aus und gehen Sie dann zu „Compute Engine“. > VM-Instanzen
2. Klicken Sie auf die Schaltfläche SSH, um eine Verbindung zur VM-Instanz herzustellen und auf ihre Befehlszeile zuzugreifen.

3. Listen Sie die Datei hello.txt auf, die wir zuvor hochgeladen haben.

gcloud storage ls gs://BUCKET_NAME

Da die Cloud Storage API im Probelaufmodus geschützt ist, sollten Sie die Ressourcen auflisten können. Allerdings müssen die Audit-Logs von ProjectZ eine Fehlermeldung enthalten.

4. Rufen Sie in ProjectZ die Logs Explorer API auf und suchen Sie nach der letzten Fehlermeldung zu VPC Service Controls. Mit diesem Filter können Sie das Protokoll abrufen, nach dem wir suchen:

protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
"(Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:UNIQUE_ID"

Mit diesem Filter wird der letzte Verstoß im Probelaufmodus angezeigt, der zu Cloud Storage gehört. Das folgende Beispiel zeigt, wie das Protokoll aussieht. Wenn wir versuchen, den Inhalt des Buckets in ProjectX aufzulisten, können wir überprüfen, ob es sich um einen ausgehenden Verstoß handelt.

egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTX_ID"
sourceType: "Network"
targetResource: "projects/PROJECTZ_ID"
}
]
resourceNames: [
0: "projects//buckets/BUCKET_NAME"
]
securityPolicyInfo: {
organizationId: "ORGANIZATION_ID"
servicePerimeterName: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
vpcServiceControlsUniqueId: "UNIQUE_ID"
}
methodName: "google.storage.objects.list"

5. Da wir geprüft haben, dass der API-Aufruf an Cloud Storage einen VPC Service Controls-Verstoß erzeugt, wird der Perimeter mit der neuen Konfiguration erzwungen. Öffnen Sie Cloud Shell und erzwingen Sie den Probelaufperimeter:

gcloud access-context-manager perimeters dry-run enforce SuperProtection --policy=POLICY --async

6. Stellen Sie über SSH eine Verbindung zur VM-Instanz her und listen Sie den Storage-Bucket noch einmal auf, um zu prüfen, ob der Probelaufperimeter korrekt erzwungen wurde.

gcloud storage ls gs://BUCKET_NAME

In der VM-Befehlszeile wird ein VPC Service Control-Verstoß anstelle einer Liste der Storage-Objekte angezeigt:

ERROR: (gcloud.storage.ls) User [[e-mail]] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:"UNIQUE_ID"

Wir haben die Daten-Exfiltration erfolgreich verhindert, indem wir mit VPC Service Controls verhindern, dass Daten aus einer Ressource außerhalb des Perimeters gelesen oder in eine Ressource kopiert werden.

6. Fehlerbehebung bei der Ablehnung der Liste

Wir beheben die Ablehnung der VM-Instanz-Befehlszeile. Sehen Sie sich die Audit-Logs an und suchen Sie nach der eindeutigen VPC Service Controls-ID.

1. Gehen Sie zur Projektauswahl und wählen Sie ProjektZ aus.
2. Suchen Sie die eindeutige VPC Service Controls-ID in den Audit-Logs. Verwenden Sie dazu die folgende Abfrage im Log-Explorer:

resource.type="audited_resource"
protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

Dadurch werden alle Audit-Logs zu VPC Service Controls angezeigt. Wir suchen nach dem letzten Fehlerprotokoll. Da der API-Aufruf über die VM-Instanz ausgeführt wurde, muss das Hauptkonto das Compute Engine-Dienstkonto „[e-mail]"“ sein

Da wir bereits die eindeutige VPC Service Controls-ID haben, können wir das gewünschte Log direkt mit diesem Filter abrufen:

protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_ID"

3. Klicken Sie auf den Header VPC Service Controls und wählen Sie „Fehlerbehebung bei Ablehnung“ aus. Dadurch wird die Fehlerbehebung für VPC Service Controls geöffnet.

Diese API zeigt uns in einer nutzerfreundlichen Benutzeroberfläche unter anderem den Grund des Verstoßes an und ob es sich um einen Verstoß gegen ein- oder ausgehenden Traffic handelt.

In dieser Übung suchen wir auf Folgendes:

authenticationInfo: {
principalEmail: "[e-mail]"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTZ_ID"
sourceType: "Network"
targetResource: "projects/PROJECTX_ID"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"

Diese Informationen reichen aus, um zu wissen, dass wir eine Regel für ausgehenden Traffic erstellen müssen, damit das Compute Engine-Dienstkonto auf den Storage-Bucket von ProjectZ zu ProjectX zugreifen kann. Außerdem sehen wir, dass sich das Netzwerk nicht im selben Perimeter befindet. Daher müssen wir die VPC-Kommunikation mit Diensten zulassen und Daten über mehrere Dienstperimeter hinweg austauschen.

4. Aktivieren Sie Cloud Shell und erstellen Sie mit einem Texteditor eine YAML-Datei mit der Regel für ausgehenden Traffic.

nano egresstorage.yaml 

- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: \"*\"
    resources:
    - projects/PROJECTX_ID
 egressFrom:
    identities:
    - serviceAccount:[e-mail]

5. Aktualisieren Sie die Richtlinie für eingehenden Traffic, die ProjectZ schützt.

gcloud access-context-manager perimeters update SuperProtection --set-egress-policies=egresstorage.yaml --policy=POLICY 

Jetzt können wir noch einmal versuchen, über die VM-Instanz auf den Bucket zuzugreifen.

1. Gehen Sie in der Cloud Console zur Projektauswahl, wählen Sie „ProjectZ“ aus und gehen Sie dann zu „Compute Engine“. > VM-Instanzen
2. Klicken Sie auf die Schaltfläche SSH, um eine Verbindung zur VM-Instanz herzustellen und auf ihre Befehlszeile zuzugreifen.
3. Versuchen Sie in der VM-Befehlszeile, die Objekte im Storage-Bucket aufzulisten.

gcloud storage ls gs://BUCKET_NAME/

Sie erhalten die folgende Fehlermeldung:

ERROR: (gcloud.storage.ls) User [[e-mail]] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): [e-mail] does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist).

4. Wir müssen dem Compute Engine-Dienstkonto eine Objektleseberechtigung erteilen, um die Objekte im Storage-Bucket auflisten zu können.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=serviceAccount:[e-mail] --role=roles/storage.objectViewer

5. Versuchen wir noch einmal, die Datei hello.txt über die Befehlszeile der VM-Instanz aufzulisten .

gcloud storage ls gs://BUCKET_NAME/
.
.
gs://BUCKET_NAME/hello.txt

Jetzt können wir das Objekt ohne VPC Service Controls-Berechtigungsverstoß auflisten. Aber wie sieht es mit dem Herunterladen der Datei aus? Versuchen wir das.

gcloud storage cp gs://BUCKET_NAME/hello.txt /home/${USER}

Und wir erhalten die folgende Ausgabe

Copying gs://BUCKET_NAME/hello.txt to file:///home/${USER}
 Completed files 1/1 | 54.0B/54.0B  

7. 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 Ihre VM-Instanz und/oder Cloud-Projekte löschen, um Gebühren zu vermeiden. Wenn Sie Ihr Cloud-Projekt löschen, wird die Abrechnung für alle in diesem Projekt verwendeten Ressourcen beendet.

1. Klicken Sie auf das Kästchen links neben dem Namen der VM-Instanz und dann auf Löschen, um die VM-Instanz zu löschen.

2. So löschen Sie den Perimeter:

• Klicken Sie in der Google Cloud Console auf Sicherheit und dann unter „Organisation“ auf VPC Service Controls.
• Klicken Sie auf der Seite „VPC Service Controls“ in der Tabellenzeile für den Perimeter, den Sie löschen möchten, auf das Symbol „Löschen“

3. So löschen Sie die Zugriffsebene:

• Öffnen Sie in der Google Cloud Console im Ordnerbereich die Seite Access Context Manager.
• Klicken Sie im Raster in der Zeile der Zugriffsebene, die Sie löschen möchten, auf „Symbol zum Löschen“ und dann auf Löschen.

4. So löschen Sie das Storage-Objekt und den Bucket:

• Öffnen Sie in der Google Cloud Console die Seite mit den Cloud Storage-Buckets .
• Klicken Sie das Kästchen neben dem von Ihnen erstellten Bucket an.
• Klicken Sie auf Löschen.
• Bestätigen Sie im angezeigten Fenster, dass Sie den Bucket löschen möchten.
• Klicken Sie auf Löschen.

5. Führen Sie die folgenden Schritte aus, um Ihr Projekt herunterzufahren:

• Wechseln Sie in der Google Cloud Console zur Seite IAM & Administratoreinstellungen des Projekts, das Sie löschen möchten.
• Auf der IAM- und Klicken Sie auf der Seite "Administratoreinstellungen" auf Herunterfahren.
• Geben Sie die Projekt-ID ein und klicken Sie auf Trotzdem herunterfahren.

8. Glückwunsch!

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

Weitere Informationen

• Weitere Informationen finden Sie in der Dokumentation zu VPC Service Controls.
• Weitere Informationen finden Sie in der Dokumentation zu Access Context Manager.
• Weitere Informationen finden Sie in der Dokumentation zur VPC-SC-Fehlerbehebung.
• Weitere Informationen finden Sie in der Dokumentation zu Regeln für ein- und ausgehenden Traffic.
• Weitere Informationen finden Sie in der Dokumentation zum Probelauf.
• Weitere Informationen finden Sie in der Cloud Storage-Dokumentation.

Lizenz

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