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 Unternehmen das Risiko einer Daten-Exfiltration minimieren können. VPC Service Controls bietet Zero-Trust-Zugriff auf mehrmandantenfähige Dienste, indem Clients den Zugriff auf autorisierte IP-Adressen, einen bestimmten Clientkontext und bestimmte Geräteparameter beschränken können, wenn sie eine Verbindung zu mehrmandantenfähigen Diensten aus dem Internet und von anderen Diensten herstellen. So können sowohl beabsichtigte als auch unbeabsichtigte Verluste reduziert werden. Wie im grundlegenden Tutorial I zu VPC Service Controls gezeigt, können Sie mit VPC Service Controls Perimeter zum Schutz von Ressourcen und Daten von Diensten erstellen, die Sie explizit angeben.

Wenn Sie das grundlegende Tutorial I zu VPC Service Controls noch nicht durchgearbeitet haben, sollten Sie damit beginnen, um die erforderliche Vorbereitung für dieses Tutorial zu treffen.

Die Ziele dieses Tutorials sind:

• Grundlagen von VPC Service Controls
• Dienstperimeter aktualisieren und im Probelaufmodus testen
• Zwei Dienste mit VPC Service Controls schützen
• Fehler bei Verstößen für ausgehenden Traffic in VPC Service Controls beheben, während ein Objekt aus Cloud Storage aufgelistet wird

2. Einrichtung und Anforderungen

Für dieses Tutorial gelten die folgenden Voraussetzungen:

• Google Cloud-Organisation
• Ein Ordner in der Organisation
• Zwei Google Cloud-Projekte in derselben Organisation, die sich im Ordner befinden
• Die erforderlichen Berechtigungen auf Organisationsebene
• Rechnungskonto für beide Projekte
• Grundlegendes Tutorial I zu VPC Service Controls: Einrichtung von VPC Service Controls und Access Context Manager

Ressourcen einrichten

1. Richten Sie die Ressourcen wie im Abschnitt „Ressourcen einrichten“ des grundlegenden Tutorials I zu VPC Service Controls beschrieben ein.
2. Prüfen Sie, ob Sie die erforderlichen Berechtigungen zum Verwalten von Cloud Storage haben.
3. In diesem Tutorial verwenden wir die Befehlszeile anstelle der Cloud Console. Richten Sie in einer der Entwicklungsumgebungen die gcloud CLI ein:

• Cloud Shell: Aktivieren Sie die Cloud Shell, um ein Onlineterminal mit der bereits eingerichteten gcloud CLI zu verwenden.

Klicken Sie rechts oben in der Cloud Console auf das Symbol, um die Cloud Shell zu aktivieren. Das Initialisieren der Sitzung kann einige Sekunden dauern. Weitere Informationen finden Sie in der Anleitung zur Cloud Shell.

• Lokale Shell: Zur Verwendung einer lokalen Entwicklungsumgebung müssen Sie die gcloud CLI installieren und initialisieren.

Kosten

Sie müssen die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/APIs zu verwenden. Die Kosten für dieses Codelab sind gering oder fallen gar nicht an. Wenn Sie die Ressourcen herunterfahren möchten, um zu vermeiden, dass nach diesem Tutorial Kosten anfallen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am kostenlosen Testprogramm im Wert von 300 $teilnehmen.

Die einzigen Ressourcen, für die Kosten anfallen, sind die VM-Instanz und das Cloud Storage-Objekt. Die geschätzten Kosten für die 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, verwenden wir die in dem vorherigen Tutorial erstellten Ressourcen wieder. Wir fahren also mit der Erstellung des Cloud Storage-Buckets fort. In diesem Tutorial verwenden wir die gcloud CLI anstelle der Console.

1. Wählen Sie in der Google Console „ProjectX“ aus. In diesem Projekt erstellen wir den Storage-Bucket und das Objekt.
2. Achten Sie darauf, dass die Cloud Shell für die Verwendung von „ProjectX“ eingerichtet 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 erfahren Sie mehr darüber, wie Sie Ihren Bucket benennen.

4. Erstellen Sie ein Storage-Objekt, damit wir es von der VM-Instanz in „ProjectZ“ lesen können. Wir erstellen eine TXT-Datei.

nano hello.txt 

Fügen Sie der Textdatei 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

Die Datei „hello.txt“ muss in der Console aufgeführt sein.

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 wir unseren Perimeter im Probelaufmodus und fügen Cloud Storage hinzu. So können wir die Auswirkungen des Perimeterschutzes ermitteln, indem wir die VPC Service Controls-Verstöße in den Audit-Logs sehen. Die Ressourcen bleiben jedoch zugänglich, bis wir den Perimeter erzwingen.

Wenn Sie einen regulären Perimeter erstellen, wird auch automatisch ein Perimeter im Probelaufmodus erstellt. Diesen bearbeiten wir in diesem Lab.

1. Wählen Sie in der Google Console Ihre Organisation aus und rufen Sie VPC Service Controls auf. Prüfen Sie, ob Sie sich im Bereich der Organisation befinden.
2. Öffnen Sie die Cloud Shell und aktualisieren Sie den Perimeter im Probelaufmodus „SuperProtection“, der im vorherigen Lab erstellt wurde:

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 "-vpcAccessibleServices: {}" Label:

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

Prüfen Sie im Probelaufmodus, ob der Perimeter „SuperProtection“ die Ablehnung anzeigt, indem Sie das Objekt von der VM-Instanz in „ProjectZ“ zu „ProjectX“ auflisten, in dem sich der Storage-Bucket befindet.

1. Wählen Sie in der Cloud Console die Projektauswahl aus und wählen Sie „ProjectZ“ aus. Rufen Sie dann „Compute Engine“ > VM-Instanzen auf.
2. Klicken Sie auf die Schaltfläche „SSH“, um eine Verbindung zur VM-Instanz herzustellen und auf die 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. In den Audit-Logs von „ProjectZ“ muss jedoch eine Fehlermeldung vorhanden sein.

4. Rufen Sie die Logs Explorer API in „ProjectZ“ auf und suchen Sie nach der letzten Fehlermeldung von VPC Service Controls. Mit diesem Filter können Sie das gesuchte Log abrufen:

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

Dieser Filter zeigt den letzten Verstoß im Probelaufmodus an, der zu Cloud Storage gehört. Hier sehen Sie ein Beispiel dafür, wie das Log aussieht. Wir können prüfen, ob es sich um einen Verstoß für ausgehenden Traffic handelt, wenn wir versuchen, den Inhalt des Buckets in „ProjectX“ aufzulisten.

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ß verursacht, erzwingen wir den Perimeter mit der neuen Konfiguration. Öffnen Sie die Cloud Shell und erzwingen Sie den Perimeter im Probelaufmodus:

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 Perimeter im Probelaufmodus korrekt erzwungen wurde.

gcloud storage ls gs://BUCKET_NAME

Statt einer Liste der Storage-Objekte erhalten wir einen VPC Service Controls-Verstoß in der VM-Befehlszeile:

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 das Lesen von Daten aus einer Ressource außerhalb des Perimeters oder das Kopieren von Daten in eine solche Ressource verhindert haben.

6. Fehlerbehebung bei der Ablehnung der Auflistung

Wir beheben den Fehler bei der Ablehnung, den wir von der VM-Instanz-Befehlszeile erhalten haben. Sehen wir uns die Audit-Logs an und suchen wir nach der eindeutigen ID von VPC Service Controls.

1. Wählen Sie die Projektauswahl aus und wählen Sie „ProjectZ“ aus.
2. Suchen Sie in den Audit-Logs nach der eindeutigen ID von VPC Service Controls. 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 von VPC Service Controls angezeigt. Wir suchen nach dem letzten Fehlerlog. Da der API-Aufruf von der VM-Instanz aus erfolgt ist, muss das Prinzipal das Compute Engine-Dienstkonto sein: "[e-mail]"

Da wir bereits die eindeutige ID von VPC Service Controls haben, können wir sie verwenden, um das gewünschte Log direkt abzurufen. Verwenden Sie dazu diesen Filter:

protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_ID"

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

Diese API zeigt in einer benutzerfreundlichen UI den Grund für den Verstoß und ob es sich um einen Verstoß für eingehenden oder ausgehenden Traffic handelt.

In dieser Übung suchen wir nach Folgendem:

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 von „ProjectZ“ aus auf den Storage-Bucket in „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 Dienstperimeter hinweg freigeben.

4. Aktivieren Sie die 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, von der VM-Instanz aus auf den Bucket zuzugreifen.

1. Wählen Sie in der Cloud Console die Projektauswahl aus und wählen Sie „ProjectZ“ aus. Rufen Sie dann „Compute Engine“ > VM-Instanzen auf.
2. Klicken Sie auf die Schaltfläche „SSH“, um eine Verbindung zur VM-Instanz herzustellen und auf die 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 die Berechtigung zum Lesen von Objekten gewähren, damit die Objekte im Storage-Bucket aufgelistet werden 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 einen VPC Service Controls-Berechtigungsverstoß auflisten. Aber wie sieht es mit dem Herunterladen der Datei aus? Probieren wir das aus.

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

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 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 Ihre VM-Instanz und/oder Cloud-Projekte löschen, um Kosten zu vermeiden. Durch das Löschen des Cloudprojekts wird die Abrechnung für alle in diesem Projekt verwendeten Ressourcen beendet.

1. Klicken Sie zum Löschen Ihrer VM-Instanz das Kästchen links neben dem Namen der VM-Instanz an und klicken Sie dann auf Löschen.

2. So löschen Sie den Perimeter:

• Klicken Sie in der Google Cloud Console auf Sicherheit und dann auf VPC Service Controls im Bereich der Organisation.
• 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 die Access Context Manager Seite im Bereich des Ordners.
• Klicken Sie im Raster in der Zeile der Zugriffsebene, die Sie löschen möchten, auf das Symbol „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 „Cloud Storage-Buckets“ .
• Klicken Sie das Kästchen neben dem von Ihnen erstellten Bucket an.
• Klicken Sie auf Löschen.
• Bestätigen Sie im daraufhin geöffneten Fenster, dass Sie den Bucket löschen möchten.
• Klicken Sie auf Löschen.

5. So beenden Sie Ihr Projekt:

• Rufen Sie in der Google Cloud Console die Seite „Einstellungen“ unter „IAM und Verwaltung“ des Projekts auf, das Sie löschen möchten.
• Klicken Sie auf der Seite „Einstellungen“ unter „IAM und Verwaltung“ auf Beenden.
• Geben Sie die Projekt-ID ein und klicken Sie auf Trotzdem beenden.

8. Glückwunsch!

In diesem Codelab haben Sie einen VPC Service Controls-Perimeter im Probelaufmodus aktualisiert, erzwungen und Fehler behoben.

Weitere Informationen

• Dokumentation zu VPC Service Controls
• Dokumentation zu Access Context Manager
• Dokumentation zur Fehlerbehebung für VPC Service Controls
• Dokumentation zu Regeln für eingehenden und ausgehenden Traffic
• Dokumentation zum Probelaufmodus.
• Dokumentation zu Cloud Storage

Lizenz

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