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 einer Daten-Exfiltration verringern können. VPC Service Controls bietet Zero-Trust-Zugriff auf mehrmandantenfähige Dienste, indem Clients den Zugriff auf autorisierte IP-Adressen, den Clientkontext und Geräteparameter beschränken können, wenn sie eine Verbindung zu mehrmandantenfähigen Diensten aus dem Internet und anderen Diensten herstellen. So lassen sich sowohl vorsätzliche als auch unbeabsichtigte Verluste reduzieren. Wie im VPC Service Controls-Tutorial I beschrieben, können Sie mit VPC Service Controls Perimeter zum Schutz von Ressourcen und Daten von Diensten erstellen, die Sie explizit angeben.

Wenn Sie das VPC Service Controls-Basistutorial I noch nicht durchgearbeitet haben, sollten Sie damit beginnen, um die erforderlichen Vorbereitungen für dieses Tutorial zu treffen.

Die Ziele dieser Anleitung sind:

• Grundlagen von VPC Service Controls
• Dienstperimeter aktualisieren und im Probelaufmodus testen
• Zwei Dienste mit VPC Service Controls schützen
• Fehler bei Egress-Verstößen in VPC Service Controls beheben, wenn ein Objekt aus Cloud Storage aufgelistet wird

2. Einrichtung und Anforderungen

Für diese Anleitung gelten die folgenden Voraussetzungen:

• GCP-Organisation
• Ein Ordner unter der Organisation.
• 2 GCP-Projekte innerhalb derselben Organisation, die sich im Ordner befinden.
• Die erforderlichen Berechtigungen auf Organisationsebene.
• Rechnungskonto für beide Projekte.
• VPC Service Controls – Basic Tutorial I: Einrichtung von VPC Service Controls und Access Context Manager.

Ressourceneinrichtung

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

• Cloud Shell: Aktivieren Sie Cloud Shell, um ein Onlineterminal mit der bereits eingerichteten 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 in der Cloud Shell-Anleitung.

• 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 oder APIs zu verwenden. Die Durchführung dieses Codelabs kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um Kosten zu vermeiden, die über diese Anleitung hinausgehen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können das kostenlose Testprogramm mit einem Guthaben von 300 $nutzen.

Die einzigen Ressourcen, die Kosten verursachen, 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, werden wir die Ressourcen aus dem vorherigen Tutorial wiederverwenden. Wir fahren 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 erstellen wir den Speicher-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. Weitere Informationen zum Benennen von Buckets

4. Erstellen Sie ein Speicherobjekt, 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 beliebige Inhalte 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 Konsole 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 den Perimeter unseres Probebetriebs 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 automatisch auch ein Probelaufperimeter erstellt. Diese Datei werden wir in diesem Lab bearbeiten.

1. Wählen Sie in der Google Console Ihre Organisation aus und greifen Sie auf VPC Service Controls zu. Prüfen Sie, ob Sie sich im Organisationsbereich befinden.
2. Öffnen Sie Cloud Shell und aktualisieren Sie den im vorherigen Lab erstellten Dry Run-Perimeter „SuperProtection“:

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

3. Prüfen, 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 wurde

Prüfen Sie im Testlaufmodus, ob der „SuperProtection“-Perimeter die Ablehnung anzeigt, indem Sie das Objekt von der VM-Instanz, die in ProjectZ erstellt wurde, in ProjectX auflisten. ProjectX hostet den Storage-Bucket.

1. Rufen Sie in der Cloud Console die Projektauswahl auf und wählen Sie „ProjectZ“ aus. 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 die Befehlszeile zuzugreifen.

3. Lassen Sie sich die zuvor hochgeladene Datei „hello.txt“ auflisten.

gcloud storage ls gs://BUCKET_NAME

Da die Cloud Storage API im Probebetrieb geschützt ist, sollten Sie die Ressourcen auflisten können. In den Audit-Logs von ProjectZ muss jedoch eine Fehlermeldung angezeigt werden.

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 uns den letzten Verstoß im Probebetrieb an, der zu Cloud Storage gehört. Hier ist ein Beispiel dafür, wie das Log aussieht. Wir können bestätigen, dass es sich um eine Verletzung der Regeln für ausgehenden Traffic handelt, wenn wir versuchen, die Inhalte 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 bestätigt haben, dass der API-Aufruf an Cloud Storage einen VPC Service Controls-Verstoß generiert, erzwingen wir den Perimeter mit der neuen Konfiguration. Öffnen Sie Cloud Shell und erzwingen Sie den Dry-Run-Perimeter:

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

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

gcloud storage ls gs://BUCKET_NAME

Wir erhalten in der VM-Befehlszeile einen VPC Service Control-Verstoß anstelle einer Liste der Storage-Objekte:

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 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 Liste

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

1. Rufen Sie die Projektauswahl auf 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 Fehlerprotokoll. Da der API-Aufruf von der VM-Instanz aus erfolgt ist, muss das Prinzipal das Compute Engine-Dienstkonto [e-mail]" sein.

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

protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_ID"

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

Über diese API können wir in einer benutzerfreundlichen Benutzeroberfläche den Grund für den Verstoß und andere nützliche Informationen sehen, z. B. ob es sich um einen Verstoß gegen die Regeln für ein- oder für 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 vom Projekt Z aus auf den Speicher-Bucket im Projekt X 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 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. Richtlinie für eingehenden Traffic aktualisieren, 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. Rufen Sie in der Cloud Console die Projektauswahl auf und wählen Sie „ProjectZ“ aus. 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 die Befehlszeile zuzugreifen.
3. Sobald Sie sich in der VM-Befehlszeile befinden, versuchen Sie, 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 Berechtigung zum Lesen von Objekten erteilen, 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 CLI der VM-Instanz aufzulisten .

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

Jetzt können wir das Objekt ohne Verstoß gegen die VPC Service Controls-Berechtigung auflisten. Was ist aber mit dem Herunterladen der Datei? Probieren wir das mal 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 Cloud-Projekts wird die Abrechnung für alle in diesem Projekt verwendeten Ressourcen beendet.

1. Klicken Sie das Kästchen links neben dem Namen der VM-Instanz an 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 im Organisationsbereich 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 zum Löschen.

3. So löschen Sie die Zugriffsebene:

• Öffnen Sie in der Google Cloud Console die Seite Access Context Manager im Ordnerbereich.
• 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 angezeigten 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 IAM- und Verwaltungseinstellungen des Projekts auf, das Sie löschen möchten.
• Klicken Sie auf der Seite „IAM- und Admin-Einstellungen“ auf Herunterfahren.
• Geben Sie die Projekt-ID ein und klicken Sie auf Trotzdem beenden.

8. Glückwunsch!

In diesem Codelab haben Sie einen VPC Service Controls-Probeperimeter 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.
• Dokumentation zum Probebetrieb
• Weitere Informationen finden Sie in der Cloud Storage-Dokumentation.

Lizenz

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