Diese Seite wurde von der Cloud Translation API übersetzt.

VPC Service Controls-Perimeter für ein Virtual Private Cloud-Netzwerk einrichten

Hier erfahren Sie, wie Sie mit VPC Service Controls einen Dienstperimeter einrichten. In diesem Tutorial werden Netzwerkeinstellungen wie Firewalls, Private Service Connect und DNS-Konfigurationen verwendet, die für die effektive Verwendung eines VPC Service Controls-Perimeters erforderlich sind. In dieser Anleitung wird dann gezeigt, wie Dienste zugelassen oder abgelehnt werden und wie Sie detaillierte Ausnahmen für eine Zulassungsliste bestimmter Dienste festlegen.

Lernziele

Konfigurieren Sie einen VPC Service Controls-Perimeter mit zusätzlichen Netzwerkkontrollen, um Exfiltrationspfade zu minimieren.
Gewähren oder verweigern Sie den Zugriff auf Dienste innerhalb des Perimeters von Anfragen, die aus dem Perimeter selbst oder von außerhalb stammen.
Sie können den Zugriff auf Dienste außerhalb des Perimeters für Anfragen zulassen oder verweigern, die innerhalb des Perimeters stammen.
Verwenden Sie die Organisationsrichtlinie „Ressourcendienstnutzung einschränken“ und VPC Service Controls zusammen.

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie unter Bereinigen.

Hinweis

Für diese Anleitung ist ein Projekt in Ihrer Organisation erforderlich. Wenn Sie noch keine Google Cloud-Organisation haben, finden Sie weitere Informationen unter Organisation erstellen und verwalten.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.
Enable the APIs
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the organization.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  IAM aufrufen
2. Wählen Sie die Organisation aus.
3. Klicken Sie auf Zugriff erlauben.
4. Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Dies ist in der Regel die E-Mail-Adresse eines Google-Kontos.
5. Wählen Sie in der Liste Rolle auswählen eine Rolle aus.
6. Wenn Sie weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.
7. Klicken Sie auf Speichern.
8. Make sure that you have the following role or roles on the project: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor
  Check for the roles
  1. In the Google Cloud console, go to the IAM page.
    Go to IAM
  2. Select the project.
  3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
  4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
  Grant the roles
  1. In the Google Cloud console, go to the IAM page.
    IAM aufrufen
  2. Wählen Sie das Projekt aus.
  3. Klicken Sie auf Zugriff erlauben.
  4. Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Dies ist in der Regel die E-Mail-Adresse eines Google-Kontos.
  5. Wählen Sie in der Liste Rolle auswählen eine Rolle aus.
  6. Wenn Sie weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.
  7. Klicken Sie auf Speichern.
  VPC Service Controls-Perimeter einrichten
  
  Um einen VPC Service Controls-Perimeter für ein VPC-Netzwerk zu implementieren, müssen Sie Netzwerksteuerungen implementieren, die Traffic zu externen Diensten ablehnen. In den folgenden Abschnitten werden die Netzwerkkonfigurationen beschrieben, die Sie in VPC-Netzwerken innerhalb Ihres Perimeters implementieren müssen, sowie eine Beispielkonfiguration für den Perimeter.
  
  VPC-Netzwerk vorbereiten
  
  In diesem Abschnitt richten Sie für Ihr VPC-Netzwerk eine private Verbindung zu Google APIs und Google-Diensten ein, um eine von Pfaden für ausgehenden Netzwerktraffic zum Internet.
  1. Legen Sie in Cloud Shell Variablen fest:
    
    gcloud config set project PROJECT_ID gcloud config set compute/region REGION gcloud config set compute/zone ZONE
    
    Ersetzen Sie Folgendes:
    
    PROJECT_ID: die Projekt-ID des Projekts, in dem Sie Ressourcen erstellen
    
    REGION: eine Region, die sich in der Nähe Ihres Standorts befindet, z. B. us-central1
    
    ZONE: eine Zone in der Nähe Ihres Standorts, z. B. us-central1-a
  2. Erstellen Sie ein VPC-Netzwerk und ein Subnetz, in denen der private Google-Zugriff aktiviert ist:
    
    gcloud compute networks create restricted-vpc --subnet-mode=custom gcloud compute networks subnets create restricted-subnet \ --range=10.0.0.0/24 \ --network=restricted-vpc \ --enable-private-ip-google-access
  3. Erstellen Sie einen Private Service Connect-Endpunkt und einen Weiterleitungsregel, die für die Verwendung der vpc-sc-Bundle:
    
    gcloud compute addresses create restricted-psc-endpoint \ --global \ --purpose=PRIVATE_SERVICE_CONNECT \ --addresses=10.0.1.1 \ --network=restricted-vpc gcloud compute forwarding-rules create restrictedpsc \ --global \ --network=restricted-vpc \ --address=restricted-psc-endpoint \ --target-google-apis-bundle=vpc-sc
  4. Konfigurieren Sie die Cloud DNS-Serverrichtlinie, um Abfragen für Google Cloud APIs an Ihren Private Service Connect-Endpunkt weiterzuleiten:
    
    gcloud dns managed-zones create restricted-dns-zone \ --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \ --dns-name="googleapis.com." \ --networks=restricted-vpc \ --visibility=private gcloud dns record-sets create googleapis.com \ --rrdatas=10.0.1.1 \ --type=A \ --ttl=300 \ --zone=restricted-dns-zone gcloud dns record-sets create *.googleapis.com \ --rrdatas="googleapis.com." \ --type=CNAME \ --ttl=300 \ --zone=restricted-dns-zone
  5. Konfigurieren Sie eine Firewallregel mit niedriger Priorität, um den gesamten ausgehenden Traffic abzulehnen:
    
    gcloud compute firewall-rules create deny-all-egress \ --priority=65534 \ --direction=egress \ --network=restricted-vpc \ --action=DENY \ --rules=all \ --destination-ranges=0.0.0.0/0
  6. Konfigurieren Sie eine Firewallregel mit höherer Priorität, damit Traffic die IP-Adresse erreichen kann, die von Ihrem Private Service Connect-Endpunkt verwendet wird:
    
    gcloud compute firewall-rules create allow-psc-for-google-apis \ --priority=1000 \ --direction=egress \ --network=restricted-vpc \ --action=ALLOW \ --rules=tcp:443 \ --destination-ranges=10.0.1.1
    
    Diese Firewallregeln verweigern ausgehenden Traffic, bevor er selektiv zum Private Service Connect-Endpunkt zugelassen wird. Diese Konfiguration wird abgelehnt ausgehender Traffic an Standarddomains die normalerweise über privater Google-Zugriff erreichbar sind. die Implizierte Firewallregeln.
  VPC Service Controls-Perimeter erstellen
  
  In diesem Abschnitt erstellen Sie einen VPC Service Controls-Perimeter.
  
  Hinweis: Dieses In dieser Anleitung wird ein erzwungener Perimeter implementiert, da es keine Produktion gibt Ressourcen innerhalb des Perimeters. Wenn Sie vorhandenen Produktionsprojekten einen Perimeter hinzufügen, empfehlen wir, sie vor der Erzwingung im Modus „Trockenlauf“ zu testen.
  1. Erstellen Sie in Cloud Shell eine Zugriffsrichtlinie als Voraussetzung für Erstellen Sie einen VPC Service Controls-Perimeter:
    
    gcloud access-context-manager policies create \ --organization=ORGANIZATION_ID --title "Access policy at organization node"
    
    Die Ausgabe sieht in etwa so aus:
    
    "Create request issued Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."
    
    Am Organisationsknoten kann es nur einen Zugriffsrichtlinien-Container geben. Wenn ein in Ihrer Organisation bereits erstellt wurde, sieht die Ausgabe in etwa so aus:
    
    "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"
    
    Wenn diese Meldung angezeigt wird, fahren Sie mit dem nächsten Schritt fort.
  2. Erstellen Sie einen VPC Service Controls-Perimeter, der die Cloud Storage- und Compute Engine-Dienste.
    
    export POLICY_ID=$(gcloud access-context-manager policies list \ --organization=ORGANIZATION_ID \ --format="value(name)") gcloud access-context-manager perimeters create demo_perimeter \ --title="demo_perimeter" \ --resources=projects/$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") \ --restricted-services="storage.googleapis.com,compute.googleapis.com" \ --enable-vpc-accessible-services \ --policy=$POLICY_ID \ --vpc-allowed-services="RESTRICTED-SERVICES"
    
    Achtung: In dieser Anleitung beschränken Sie nur die Compute Engine- und Cloud Storage-Dienste. In einem Produktionsperimeter empfehlen wir, Sie alle unterstützten Dienste einschränken um eine Reihe von Exfiltrationspfaden abzuschwächen.
    Im Beispielperimeter wird das Flag --vpc-allowed-services mit dem Parameter Alias-Wert RESTRICTED-SERVICES um Traffic von dieser VPC zu den Diensten zuzulassen, die Sie mit der --restricted-services.
  Prüfen, welche Dienste von Traffic außerhalb des Perimeters zugelassen sind
  
  In den folgenden Abschnitten wird gezeigt, wie der VPC Service Controls-Perimeter den Zugriff auf Anfragen von außerhalb des Perimeters zulässt oder verweigert und wie Sie den Zugriff auf Dienste selektiv zulassen können, indem Sie Zugriffsebenen und Ingress-Richtlinien konfigurieren.
  
  Um Traffic von außerhalb des Perimeters zu simulieren, können Sie Befehle in Cloud Shell Cloud Shell ist eine Ressource außerhalb Ihrer eigenen Projekt und Perimeter. Der Perimeter erlaubt oder lehnt Anfragen ab, obwohl die Anfragen ausreichende IAM-Berechtigungen (Identity and Access Management) für den Erfolg haben.
  
  In dieser Anleitung werden die Compute Engine API, die Cloud Storage API und die Cloud Resource Manager API verwendet. Dieselben Konzepte gelten jedoch auch für andere Dienste.
  
  Prüfen, ob der Perimeter externen Traffic an eingeschränkte Dienste ablehnt
  
  In diesem Abschnitt prüfen Sie, ob der Perimeter externen Traffic für eingeschränkte Dienste ablehnt.
  
  Das Diagramm oben zeigt, wie einem autorisierten Client der Zugriff Dienste innerhalb des Perimeters, die Sie als eingeschränkt konfiguriert haben, aber der Client hat Zugriff auf Dienste, die Sie nicht als eingeschränkt konfiguriert haben.
  
  In den folgenden Schritten überprüfen Sie dieses Konzept mithilfe von Cloud Shell, versuchen, eine VM in Ihrem VPC-Netzwerk zu erstellen, die aufgrund mit der Konfiguration des VPC Service Controls-Perimeters.
  1. Führen Sie in Cloud Shell den folgenden Befehl aus, um eine VM zu erstellen. in Ihrem VPC-Netzwerk.
    
    gcloud compute instances create demo-vm \ --machine-type=e2-micro \ --subnet=restricted-subnet \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --no-address
    
    Die Ausgabe sieht in etwa so aus:
    
    "ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Request is prohibited by organization's policy."
    
    Die Anfrage schlägt fehl, da sich Cloud Shell außerhalb Ihres Perimeter befindet und die Compute Engine mit dem Flag --restricted-services konfiguriert ist.
  2. Führen Sie in Cloud Shell den folgenden Befehl aus, um auf die Resource Manager-Dienst, der nicht im Flag --restricted-services.
    
    gcloud projects describe PROJECT_ID
    
    Eine erfolgreiche Antwort gibt die Details Ihres Projekts zurück. Diese Antwort zeigt, dass Ihr Perimeter externen Traffic zur Cloud Resource Manager API zulässt.
    
    Sie haben gezeigt, dass der Perimeter externen Traffic zu Diensten, die in --restricted-services konfiguriert sind, ablehnt und externen Traffic zu Diensten zulässt, die nicht explizit in --restricted-services konfiguriert sind.
  In den folgenden Abschnitten werden Ausnahmemuster vorgestellt, mit denen eingeschränkte Dienste innerhalb des Perimeters erreicht werden können.
  
  Prüfen, ob eine Zugriffsebene eine Ausnahme vom Perimeter zulässt
  
  In diesem Abschnitt bestätigen Sie, dass eine Zugriffsebene lässt eine Ausnahme vom Perimeter zu. Eine Zugriffsebene ist nützlich, Zum Erstellen einer Ausnahme für externen Traffic, um auf alle eingeschränkten Dienste zuzugreifen innerhalb des Perimeters und Sie benötigen keine detaillierten Ausnahmen für jeden Dienst oder anderen Attributen.
  
  Das Diagramm oben zeigt, wie ein autorisierter Client mit einer Zugriffsebene um auf alle eingeschränkten Dienste innerhalb des Perimeters zuzugreifen.
  
  In den folgenden Schritten überprüfen Sie dieses Konzept, indem Sie eine Zugriffsebene erstellen und dann eine erfolgreiche Anfrage an den Compute Engine-Dienst senden. Dieses ist auch dann zulässig, wenn Sie Compute Engine als eingeschränkt konfiguriert haben.
  1. Erstellen Sie in Cloud Shell eine YAML-Datei, die die Konfiguration einer Zugriffsebene beschreibt, und wenden Sie sie auf Ihren Perimeter an. Dieses Beispiel: Sie erstellen eine Zugriffsebene für die Nutzeridentität, die Sie gerade verwenden. mit, um die Anleitung auszuführen.
    
    export USERNAME=$(gcloud config list account --format "value(core.account)") cat <<EOF > user_spec.yaml - members: - user:$USERNAME EOF
    
    gcloud access-context-manager levels create single_user_level \ --title="single-user access level" \ --basic-level-spec=user_spec.yaml \ --policy=$POLICY_ID gcloud access-context-manager perimeters update demo_perimeter \ --add-access-levels=single_user_level \ --policy=$POLICY_ID
  2. Führen Sie in Cloud Shell den folgenden Befehl noch einmal aus, zum Erstellen einer VM:
    
    gcloud compute instances create demo-vm \ --machine-type=e2-micro \ --subnet=restricted-subnet \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --no-address
    
    Diesmal funktioniert die Anfrage. Ihr Perimeter verhindert, dass externer Traffic eingeschränkten Diensten verwenden, aber die von Ihnen konfigurierte Zugriffsebene ermöglicht Ausnahmeregelung.
    
    Hinweis: Nach dem Aktualisieren eines Dienstperimeters kann es einige Zeit dauern, bis die Änderungen übernommen und wirksam werden. Wenn Sie ein unerwartetes Ergebnis erhalten, warten Sie eine Minute lang und versuchen Sie es noch einmal, nachdem der Perimeter vollständig aktualisiert wurde.
  Prüfen, ob eine Ingress-Richtlinie eine detaillierte Ausnahme für den Perimeter zulässt
  
  In diesem Abschnitt prüfen Sie, ob eine Ingress-Richtlinie eine detaillierte Ausnahme für den Perimeter zulässt. Im Vergleich zur grobkörnigen Zugriffsebene können mit einer detaillierten Ingress-Richtlinie zusätzliche Attribute zur Trafficquelle konfiguriert und der Zugriff auf einzelne Dienste oder Methoden zugelassen werden.
  
  Das obige Diagramm zeigt, wie eine Ingress-Richtlinie eine autorisierte Client nur auf einen bestimmten Dienst innerhalb des Perimeters zuzugreifen, ohne auf andere eingeschränkte Dienste zugreifen können.
  
  In den folgenden Schritten prüfen Sie dieses Konzept, indem Sie die Zugriffsebene ersetzen mit einer Richtlinie für eingehenden Traffic, die es einem autorisierten Client erlaubt, nur auf den Compute Engine-Dienst, gewährt jedoch keinen Zugriff auf andere eingeschränkte Dienstleistungen.
  1. Führen Sie auf dem Cloud Shell-Tab den folgenden Befehl aus, um die Zugriffsebene zu ändern.
    
    gcloud access-context-manager perimeters update demo_perimeter \ --policy=$POLICY_ID \ --clear-access-levels
  2. Erstellen Sie auf dem Cloud Shell-Tab eine Richtlinie für eingehenden Traffic, die Ihrer Nutzeridentität für eingehenden Traffic Nur Compute Engine-Dienst und wenden Sie die Richtlinie auf Ihren Perimeter an.
    
    cat <<EOF > ingress_spec.yaml - ingressFrom: identities: - user:$USERNAME sources: - accessLevel: '*' ingressTo: operations: - methodSelectors: - method: '*' serviceName: compute.googleapis.com resources: - '*' EOF
    
    gcloud access-context-manager perimeters update demo_perimeter \ --set-ingress-policies=ingress_spec.yaml \ --policy=$POLICY_ID
  3. Führen Sie auf dem Cloud Shell-Tab den folgenden Befehl aus, um einen Cloud Storage-Bucket innerhalb des Perimeters zu erstellen.
    
    gcloud storage buckets create gs://PROJECT_ID-01
    
    Die Ausgabe sieht in etwa so aus:
    
    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."
    
    Cloud Shell ist ein Client außerhalb des Perimeters. Der VPC Service Controls-Perimeter blockiert Cloud Shell Kommunikation mit eingeschränkten Diensten innerhalb des Perimeters
  4. Führen Sie auf dem Cloud Shell-Tab den folgenden Befehl aus, um eine -Anfrage an den Compute Engine-Dienst innerhalb des Perimeters.
    
    gcloud compute instances describe demo-vm --zone=ZONE
    
    Eine erfolgreiche Antwort gibt die Details zu demo-vm zurück. Diese Antwort zeigt, dass Ihr Perimeter externen Traffic zulässt, der die Bedingungen Ihrer Richtlinie für eingehenden Traffic an den Compute Engine-Dienst an.
  Prüfen, welche Dienste für Traffic innerhalb des Perimeters zulässig sind
  
  In den folgenden Abschnitten wird gezeigt, wie der VPC Service Controls-Perimeter Anfragen an Dienste innerhalb des Perimeters zulässt oder ablehnt und wie Sie mithilfe von Richtlinien für ausgehenden Traffic den ausgehenden Traffic zu externen Diensten selektiv zulassen können.
  
  Um den Unterschied zwischen Traffic innerhalb und außerhalb des Perimeters zu veranschaulichen, wird in den folgenden Abschnitten sowohl Cloud Shell außerhalb des Perimeters als auch eine Compute Engine-Instanz verwendet, die Sie innerhalb des Perimeters erstellen. Für Befehle, die Sie über die SSH-Sitzung auf der Compute Engine-Instanz innerhalb des Perimeters ausführen, wird die Identität des angehängten Dienstkontos verwendet. Für Befehle, die Sie über Cloud Shell außerhalb des Perimeters ausführen, wird Ihre eigene Identität verwendet. Wenn Sie der empfohlenen Einrichtung für die Anleitung folgen, werden Anfragen vom Perimeter zugelassen oder abgelehnt, obwohl sie über ausreichende IAM-Berechtigungen verfügen, um erfolgreich zu sein.
  
  In dieser Anleitung werden die Compute Engine API, die Cloud Storage API und die Cloud Resource Manager API verwendet. Dieselben Konzepte gelten jedoch auch für andere Dienste.
  
  Prüfen, ob der Perimeter internen Traffic zu eingeschränkten Diensten innerhalb des Perimeters zulässt
  
  In diesem Abschnitt prüfen Sie, ob der Perimeter Traffic von Netzwerkendpunkten innerhalb des Perimeters zulässt, wenn der Dienst auch in Über VPC zugängliche Dienste konfiguriert ist.
  
  Das vorherige Diagramm zeigt, wie ein Perimeter Traffic aus einem Netzwerk zulässt Endpunkte innerhalb des Perimeters, um eingeschränkte Dienste zu erreichen, die als über VPC zugängliche Dienste konfiguriert sind. Dienste, die Sie nicht konfiguriert haben Über VPC zugängliche Dienste sind von Netzwerkendpunkten innerhalb der des Perimeters.
  
  In den folgenden Schritten überprüfen Sie dieses Konzept, indem Sie eine SSH-Verbindung zur Compute Engine-Instanz innerhalb des Perimeter herstellen und dann Anfragen an Dienste senden.
  1. Erstellen Sie in Cloud Shell eine Firewallregel, die SSH zulässt. Traffic zu Ihrem VPC-Netzwerk, indem Sie eingehenden Traffic von der IP-Adresse 35.235.240.0/20 zulassen Adressbereich, der von der IAP für TCP-Weiterleitung Dienst:
    
    gcloud compute firewall-rules create demo-allow-ssh \ --direction=INGRESS \ --priority=1000 \ --network=restricted-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
  2. Starten Sie eine SSH-Sitzung für diese Instanz:
    
    gcloud compute ssh demo-vm --zone=ZONE
    
    Prüfen Sie, ob Sie eine Verbindung zur Instanz demo-vm hergestellt haben. um zu bestätigen, dass die Eingabeaufforderung geändert wurde, um den Hostnamen Ihres Instanz:
    
    username@demo-vm:~$
    
    Wenn der vorherige Befehl fehlschlägt, wird möglicherweise eine Fehlermeldung wie die Folgendes:
    
    "[/usr/bin/ssh] exited with return code [255]"
    
    In diesem Fall ist der Startvorgang der Compute Engine-Instanz möglicherweise noch nicht abgeschlossen. Warten Sie eine Minute und versuchen Sie es dann noch einmal.
  3. Prüfen Sie in der SSH-Sitzung innerhalb Ihres Perimeters die Dienste, die Ihr Perimeter intern zulässt. Verwenden Sie dazu einen Google Cloud-Dienst, der in der Zulassungsliste der zugänglichen VPC-Dienste konfiguriert ist. Versuchen Sie beispielsweise, einen beliebigen Befehl mit dem Compute Engine-Dienst ausführen.
    
    gcloud compute instances describe demo-vm --zone=ZONE
    
    Eine erfolgreiche Antwort gibt die Details zu demo-vm zurück. Diese Antwort zeigt, dass Ihr Perimeter internen Traffic zum Compute Engine API
  4. Prüfen Sie in der SSH-Sitzung innerhalb Ihres Perimeters, ob die Dienste nicht auf der Zulassungsliste für zugängliche VPC-Dienste enthalten sind, sind nicht zulässig von Ihre virtuelle Maschine. Im folgenden Befehl wird beispielsweise der Resource Manager-Dienst verwendet, der nicht in der Zulassungsliste der über VPC zugänglichen Dienste konfiguriert ist.
    
    gcloud projects describe PROJECT_ID
    
    Die Ausgabe sieht in etwa so aus:
    
    "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."
    
    Ihre Compute Engine-Instanz und andere Netzwerkendpunkte können fordert Dienste an, die in der Zulassungsliste für zugängliche VPC-Dienste konfiguriert sind. Serverlose Ressourcen oder Diensttraffic, der von außerhalb Ihres Perimeter kann diesen Dienst anfordern. Wenn Sie verhindern möchten, dass ein Dienst die in Ihrem Projekt verwendet werden, Richtlinie zur eingeschränkten Nutzung von Dienstressourcen.
  Prüfen, ob der Perimeter internen Traffic zu eingeschränkten Diensten außerhalb des Perimeters ablehnt
  
  In diesem Abschnitt prüfen Sie, ob der Perimeter die Kommunikation von Diensten innerhalb des Perimeters zu Google Cloud-Diensten außerhalb des Perimeters blockiert.
  
  Das vorherige Diagramm zeigt, dass interner Traffic nicht mit eingeschränkten Diensten außerhalb des Perimeters kommunizieren kann.
  
  In den folgenden Schritten prüfen Sie dieses Konzept, indem Sie versuchen, internen Traffic an einen eingeschränkten Dienst innerhalb des Perimeters und an einen eingeschränkten Dienst außerhalb des Perimeters zu senden.
  1. Führen Sie in der SSH-Sitzung innerhalb Ihres Perimeters den folgenden Befehl aus: um einen Storage-Bucket in Ihrem Perimeter zu erstellen. Dieser Befehl funktioniert, da der Cloud Storage-Dienst sowohl in restricted-services als auch in accessible-services konfiguriert ist.
    
    gcloud storage buckets create gs://PROJECT_ID-02
    
    Bei einer erfolgreichen Antwort wird der Speicher-Bucket erstellt. Diese Antwort zeigt, dass Ihr Perimeter internen Traffic zum Cloud Storage-Dienst zulässt.
  2. Führen Sie in der SSH-Sitzung innerhalb Ihres Perimeters den folgenden Befehl aus: aus einem Bucket zu lesen, der sich außerhalb Ihres Perimeters befindet. Dieses öffentlicher Bucket erlaubt nur Lesezugriff auf allUsers, aber für den Perimeter Lehnt Traffic von innerhalb des Perimeters zu einem eingeschränkten Dienst außerhalb des Perimeters ab des Perimeters.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    Die Ausgabe sieht in etwa so aus:
    
    "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited by organization's policy."
    
    Diese Antwort zeigt, dass Sie eingeschränkte Dienste im Perimeter definieren, aber eine Ressource innerhalb des Perimeters kann nicht mit eingeschränkter Dienste außerhalb des Perimeters.
  Prüfen, ob eine Richtlinie für ausgehenden Traffic eine Ausnahme vom Perimeter zulässt
  
  In diesem Abschnitt prüfen Sie, ob eine Richtlinie für ausgehenden Traffic eine Ausnahme vom Perimeter zulässt.
  
  Das vorherige Diagramm zeigt, wie interner Traffic mit einer bestimmten externen Ressource kommunizieren kann, wenn Sie mit der Richtlinie für ausgehenden Traffic eine eng gefasste Ausnahme gewähren.
  
  In den folgenden Schritten verifizieren Sie dieses Konzept, indem Sie eine Richtlinie für ausgehenden Traffic erstellen Anschließend greifen Sie auf einen öffentlichen Cloud Storage-Bucket außerhalb des Perimeters zu. die gemäß der Richtlinie für ausgehenden Traffic zulässig sind.
  1. Öffnen Sie eine neue Cloud Shell-Sitzung, indem Sie in Cloud Shell auf Neuen Tab öffnen klicken. In den nachfolgenden Schritten wechseln Sie zwischen dem ersten Tab und der SSH-Sitzung innerhalb des Perimeters und der zweite Tab in Cloud Shell außerhalb Ihrem Perimeter, in dem die Befehlszeilen-Eingabeaufforderung beginnt username@cloudshell
  2. Erstellen Sie auf dem Tab „Cloud Shell“ eine Ausstiegsrichtlinie, die den ausgehenden Traffic von der verknüpften Dienstkontoidentität demo-vm mit der Methode google.storage.objects.get zu einem öffentlichen Bucket in einem externen Projekt zulässt. Aktualisieren Sie den Perimeter mit der Richtlinie für ausgehenden Traffic.
    
    export POLICY_ID=$(gcloud access-context-manager policies list \ --organization=ORGANIZATION_ID \ --format="value(name)") export SERVICE_ACCOUNT_EMAIL=$(gcloud compute instances describe demo-vm \ --zone=ZONE) \ --format="value(serviceAccounts.email)"
    
    cat <<EOF > egress_spec.yaml - egressFrom: identities: - serviceAccount:$SERVICE_ACCOUNT_EMAIL egressTo: operations: - methodSelectors: - method: 'google.storage.objects.get' serviceName: storage.googleapis.com resources: - projects/950403849117 EOF
    
    gcloud access-context-manager perimeters update demo_perimeter \ --set-egress-policies=egress_spec.yaml \ --policy=$POLICY_ID
  3. Kehren Sie zum Tab mit der SSH-Sitzung zur VM innerhalb Ihres Perimeter zurück, bei der die Eingabeaufforderung der Befehlszeile mit username@demo-vm beginnt.
  4. Stellen Sie über die SSH-Sitzung in Ihrem Perimeter noch einmal eine Anfrage an den Cloud Storage-Bucket und prüfen Sie, ob sie funktioniert.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    Die Ausgabe sieht in etwa so aus:
    
    "Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."
    
    Diese Antwort zeigt, dass Ihre Perimeter- und Ausgangsrichtlinie interne Traffic von einer bestimmten Identität zu einem bestimmten Cloud Storage-Bucket
    
    Hinweis: Nach dem Aktualisieren eines Dienstperimeters kann es einige Zeit dauern, bis die Änderungen übernommen und wirksam werden. Wenn Sie ein unerwartetes Ergebnis erhalten, warten Sie eine Minute lang und versuchen Sie es noch einmal, nachdem der Perimeter vollständig aktualisiert wurde.
  5. Über die SSH-Sitzung innerhalb Ihres Perimeters können Sie auch andere Methoden, die von der Richtlinienausnahme für ausgehenden Traffic nicht ausdrücklich zugelassen wurden. Für Für den folgenden Befehl ist z. B. der Parameter google.storage.buckets.list erforderlich. Berechtigung, die von Ihrem Perimeter verweigert wird.
    
    gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*
    
    Die Ausgabe sieht in etwa so aus:
    
    "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."
    
    Diese Antwort zeigt, dass Ihr Perimeter internen Traffic daran hindert, Objekte im externen Bucket aufzulisten. Das bedeutet, dass die ausgehende Richtlinie explizit angegebene Methoden nur eingeschränkt zulässt.
  Weitere Informationen zu gängigen Mustern für die Freigabe von Daten außerhalb Ihres Dienstperimeters finden Sie unter Sicherer Datenaustausch mit Regeln für ein- und ausgehenden Traffic.
  
  (Optional) Richtlinie für die eingeschränkte Nutzung von Dienstressourcen konfigurieren
  
  Möglicherweise haben Sie auch interne oder Compliance-Anforderungen, die nur die Verwendung individuell genehmigter APIs in Ihrer Umgebung zulassen. In diesem Fall können Sie auch die Eingeschränkte Nutzung von Dienstressourcen Organisationsrichtliniendienst. Wenn Sie die Organisationsrichtlinie auf ein Projekt anwenden, können Sie einschränken, welche Dienste in diesem Projekt erstellt werden können. Die Organisationsrichtlinie verhindert jedoch nicht, dass Dienste in diesem Projekt mit Diensten in anderen Projekten kommunizieren. Mit VPC Service Controls können Sie dagegen einen Perimeter definieren, um die Kommunikation mit Diensten außerhalb des Perimeters zu verhindern.
  
  Wenn Sie beispielsweise eine Organisationsrichtlinie definieren, Compute Engine und verweigern Cloud Storage in Ihrem Projekt. Eine VM in diesem Projekt konnte keinen Cloud Storage-Bucket in Ihrem Projekt arbeiten. Die VM kann jedoch Anfragen an einen Cloud Storage-Bucket in die Daten-Exfiltration mit dem Cloud Storage-Dienst möglich. Die folgenden Schritte zeigen, wie dieses Szenario implementiert und getestet wird:
  1. Wechseln Sie zum Cloud Shell-Tab, wo die Eingabeaufforderung beginnt mit username@cloudshell.
  2. Erstellen Sie im Cloud Shell-Tab eine YAML-Datei, in der die Organisationsrichtliniendienst, der nur die Nutzung von Compute Engine zulässt und alle anderen Dienste ablehnen und ihn dann auf Ihr Projekt anwenden.
    
    cat <<EOF > allowed_services_policy.yaml constraint: constraints/gcp.restrictServiceUsage listPolicy: allowedValues: - compute.googleapis.com inheritFromParent: true EOF
    
    gcloud resource-manager org-policies set-policy allowed_services_policy.yaml \ --project=PROJECT_ID
  3. Kehren Sie zum Tab mit der SSH-Sitzung zur VM innerhalb Ihres Perimeter zurück, bei der die Eingabeaufforderung der Befehlszeile mit username@demo-vm beginnt.
  4. Führen Sie in der SSH-Sitzung innerhalb Ihres Perimeters den folgenden Befehl aus, denselben Storage-Bucket anzeigen, den Sie zuvor in diesem Projekt erstellt haben.
    
    gcloud storage buckets describe gs://PROJECT_ID
    
    Die Ausgabe sieht in etwa so aus:
    
    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."
    
    Diese Antwort zeigt, dass der Organisationsrichtliniendienst den Cloud Storage-Dienst ablehnt innerhalb Ihres Projekts, unabhängig von der Konfiguration des Perimeters.
    
    Hinweis: Nachdem Sie einen Organisationsrichtliniendienst aktualisiert haben, kann es einige Zeit dauern, bis der übernommen werden und wirksam werden. Wenn Sie ein unerwartetes Ergebnis erhalten, warten Sie eine Minute lang und versuchen Sie es noch einmal, nachdem der Perimeter vollständig aktualisiert wurde.
  5. Führen Sie in der SSH-Sitzung innerhalb Ihres Perimeters den folgenden Befehl aus: um einen Storage-Bucket außerhalb des Perimeters anzuzeigen, der von Ihrem Richtlinie für ausgehenden Traffic.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    Die Ausgabe sieht in etwa so aus:
    
    "Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."
    
    Eine erfolgreiche Antwort gibt den Inhalt von helloworld.txt im externen Speicher-Bucket zurück. Diese Antwort zeigt, dass Ihr Perimeter und Ihre Richtlinie für ausgehenden Traffic unter bestimmten eingeschränkten Bedingungen den internen Traffic zu einem externen Speicher-Bucket zulassen, der Cloud Storage-Dienst in Ihrem Projekt wird jedoch vom Organisationsrichtliniendienst unabhängig von der Konfiguration Ihres Perimeters abgelehnt. Dienste außerhalb Ihres Projekts können weiterhin für die Daten-Exfiltration verwendet werden, wenn Sie werden von Ihrem Perimeter zugelassen, unabhängig vom eingeschränkten Dienst Organisationsrichtliniendienst für Ressourcennutzung.
    
    Wenn Sie die Kommunikation mit Cloud Storage oder anderen Google-Diensten außerhalb des Perimeters verweigern möchten, reicht die Organisationsrichtlinie Einschränkung der Ressourcendienstnutzung allein nicht aus. Sie müssen einen VPC Service Controls-Perimeter konfigurieren. Datenminimierung durch VPC Service Controls Exfiltrationspfade Eingeschränkte Nutzung von Dienstressourcen ist eine Compliance-Kontrolle, mit der Sie verhindern können, dass nicht genehmigte Dienste in Ihrem zu verbessern. Verwenden Sie diese Steuerelemente zusammen, um eine Reihe von Exfiltrationspfaden zu blockieren und genehmigte Dienste für die interne Nutzung in Ihrer Umgebung selektiv zuzulassen.
  Bereinigen
  Achtung: Das Löschen von Projekten hat folgende Auswirkungen:
  
  Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
  
  Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.
  
  Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.
  Delete a Google Cloud project:
  gcloud projects delete PROJECT_ID
  Auch wenn der VPC Service Controls-Perimeter keine zusätzliche Kosten verursachen, sollten sie bereinigt werden, um Unordnung und ungenutzte Ressourcen zu vermeiden. in Ihrer Organisation.
  1. Wählen Sie in der Projektauswahl oben in der Google Cloud Console die Organisation aus, die Sie in dieser Anleitung verwendet haben.
  2. Rufen Sie in der Google Cloud Console die Seite VPC Service Controls auf.
    
    Zu „VPC Service Controls“
  3. Wählen Sie unter der Liste der Perimeter den Perimeter aus, den Sie löschen möchten, und klicken Sie auf Löschen.
  4. Klicken Sie im Dialogfeld noch einmal auf Löschen, um den Löschvorgang zu bestätigen.
  Nächste Schritte
  - Weitere Informationen Best Practices zum Aktivieren von VPC Service Controls
  - Informationen dazu, welche Dienste in VPC Service Controls unterstützt werden
  - Über VPC zugängliche Dienste aktivieren.
  - Weitere Informationen zur Konfiguration von Private Service Connect für den Zugriff auf Google APIs.
  - Weitere Referenzarchitekturen, Diagramme, Anleitungen und Best Practices finden Sie im Cloud-Architekturcenter.

VPC Service Controls-Perimeter für ein Virtual Private Cloud-Netzwerk einrichten

Lernziele

Kosten

Hinweis

Check for the roles

Grant the roles

Check for the roles

Grant the roles

VPC Service Controls-Perimeter einrichten

VPC-Netzwerk vorbereiten

VPC Service Controls-Perimeter erstellen

Prüfen, welche Dienste von Traffic außerhalb des Perimeters zugelassen sind

Prüfen, ob der Perimeter externen Traffic an eingeschränkte Dienste ablehnt

Prüfen, ob eine Zugriffsebene eine Ausnahme vom Perimeter zulässt

Prüfen, ob eine Ingress-Richtlinie eine detaillierte Ausnahme für den Perimeter zulässt

Prüfen, welche Dienste für Traffic innerhalb des Perimeters zulässig sind

Prüfen, ob der Perimeter internen Traffic zu eingeschränkten Diensten innerhalb des Perimeters zulässt

Prüfen, ob der Perimeter internen Traffic zu eingeschränkten Diensten außerhalb des Perimeters ablehnt

Prüfen, ob eine Richtlinie für ausgehenden Traffic eine Ausnahme vom Perimeter zulässt

(Optional) Richtlinie für die eingeschränkte Nutzung von Dienstressourcen konfigurieren

Bereinigen

Nächste Schritte