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 Netzwerksteuerungen, um Exfiltrationspfade einzuschränken.
Sie können den Zugriff auf Dienste innerhalb des Perimeters für Anfragen zulassen oder verweigern, die innerhalb oder außerhalb des Perimeters 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.

Hinweise

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
  
  Wenn Sie einen VPC Service Controls-Perimeter für ein VPC-Netzwerk implementieren möchten, müssen Sie Netzwerksteuerungen implementieren, die Traffic zu externen Diensten verweigern. 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 eine private Verbindung zu Google APIs und Diensten für Ihr VPC-Netzwerk ein, um eine Reihe von Netzwerk-Ausgangspfaden zum Internet zu minimieren.
  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, die sich in der Nähe Ihres Standorts befindet, 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 eine Weiterleitungsregel, die für die Verwendung des vpc-sc-Bundles konfiguriert ist:
    
    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 zu verhindern:
    
    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. Mit dieser Konfiguration wird ausgehender Traffic zu Standarddomains abgelehnt, die normalerweise standardmäßig mit dem privater Google-Zugriff und den impliziten Firewallregeln erreichbar sind.
  VPC Service Controls-Perimeter erstellen
  
  In diesem Abschnitt erstellen Sie einen VPC Service Controls-Perimeter.
  
  Hinweis: In dieser Anleitung wird ein erzwungener Perimeter implementiert, da sich innerhalb des Perimeters keine Produktionsressourcen befinden. Wenn Sie vorhandenen Produktionsprojekten einen Perimeter hinzufügen, empfehlen wir, vor der Erzwingung einen Testlauf durchzuführen.
  1. Erstellen Sie in Cloud Shell eine Zugriffsrichtlinie als Voraussetzung für die Erstellung eines VPC Service Controls-Perimeters:
    
    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 in Ihrer Organisation bereits eine Richtlinie 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 einschränkt.
    
    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. Für einen Produktionsperimeter empfehlen wir, alle unterstützten Dienste einzuschränken, um eine Reihe von Exfiltrationspfaden zu minimieren.
    Im Beispielperimeter wird das Flag --vpc-allowed-services mit dem Aliaswert RESTRICTED-SERVICES konfiguriert, um Traffic von dieser VPC zu denselben Diensten zuzulassen, die Sie mit dem Flag --restricted-services definieren.
  Prüfen, welche Dienste von Traffic außerhalb Ihres 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.
  
  Wenn Sie Traffic von außerhalb Ihres Perimeters simulieren möchten, können Sie Befehle in Cloud Shell ausführen. Cloud Shell ist eine Ressource, die sich außerhalb Ihres eigenen Projekts und Perimeters befindet. 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 zu eingeschränkten Diensten ablehnt
  
  In diesem Abschnitt prüfen Sie, ob der Perimeter externen Traffic für eingeschränkte Dienste ablehnt.
  
  Das vorherige Diagramm zeigt, wie einem autorisierten Client der Zugriff auf Dienste innerhalb des Perimeters verweigert wird, die Sie als eingeschränkt konfiguriert haben, dem Client aber der Zugriff auf Dienste erlaubt ist, die Sie nicht als eingeschränkt konfiguriert haben.
  
  In den folgenden Schritten überprüfen Sie dieses Konzept, indem Sie mit Cloud Shell versuchen, eine VM in Ihrem VPC-Netzwerk zu erstellen. Dies schlägt aufgrund der Konfiguration des VPC Service Controls-Perimeters fehl.
  1. Führen Sie in Cloud Shell den folgenden Befehl aus, um eine VM in Ihrem VPC-Netzwerk zu erstellen.
    
    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 den Resource Manager-Dienst zuzugreifen, der nicht mit dem Flag --restricted-services konfiguriert ist.
    
    gcloud projects describe PROJECT_ID
    
    Bei einer erfolgreichen Antwort werden die Details Ihres Projekts zurückgegeben. 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 für den Perimeter zulässt
  
  In diesem Abschnitt prüfen Sie, ob eine Zugriffsebene eine Ausnahme für den Perimeter zulässt. Eine Zugriffsebene ist nützlich, wenn Sie eine Ausnahme für externen Traffic zum Zugriff auf alle eingeschränkten Dienste innerhalb des Perimeters erstellen möchten und keine detaillierten Ausnahmen für jeden Dienst oder andere Attribute benötigen.
  
  Das vorherige Diagramm zeigt, wie eine Zugriffsebene einem autorisierten Client den Zugriff auf alle eingeschränkten Dienste innerhalb des Perimeters ermöglicht.
  
  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. Diese Anfrage ist auch zulässig, wenn Sie die 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. In diesem Beispiel wird eine Zugriffsebene für die Nutzeridentität erstellt, mit der Sie die Anleitung gerade ausfü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 noch einmal den folgenden Befehl aus, um eine VM zu erstellen:
    
    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 die eingeschränkten Dienste nutzt, die von Ihnen konfigurierte Zugriffsebene erlaubt jedoch eine Ausnahme.
    
    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 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 für die Trafficquelle konfiguriert und der Zugriff auf einzelne Dienste oder Methoden zugelassen werden.
  
  Das vorherige Diagramm zeigt, wie eine Ingress-Richtlinie einem autorisierten Client den Zugriff nur auf einen bestimmten Dienst innerhalb des Perimeters erlaubt, ohne Zugriff auf andere eingeschränkte Dienste zu gewähren.
  
  In den folgenden Schritten überprüfen Sie dieses Konzept, indem Sie die Zugriffsebene durch eine Ingress-Richtlinie ersetzen, die einem autorisierten Client nur den Zugriff auf den Compute Engine-Dienst, aber keinen Zugriff auf andere eingeschränkte Dienste erlaubt.
  1. Führen Sie auf dem Tab „Cloud Shell“ den folgenden Befehl aus, um die Zugriffsebene zu entfernen.
    
    gcloud access-context-manager perimeters update demo_perimeter \ --policy=$POLICY_ID \ --clear-access-levels
  2. Erstellen Sie auf dem Tab „Cloud Shell“ eine Ingress-Richtlinie, die Ihrer Nutzeridentität nur den Zugriff auf den Compute Engine-Dienst erlaubt, 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 Tab „Cloud Shell“ den folgenden Befehl aus, um einen Cloud Storage-Bucket innerhalb des Perimeter 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. Daher verhindert der VPC Service Controls-Perimeter die Kommunikation von Cloud Shell mit eingeschränkten Diensten innerhalb des Perimeters.
  4. Führen Sie auf dem Tab „Cloud Shell“ den folgenden Befehl aus, um eine Anfrage an den Compute Engine-Dienst innerhalb des Perimeter zu senden.
    
    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 Ingress-Richtlinie für den Compute Engine-Dienst erfüllt.
  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 für den Erfolg verfügen.
  
  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 den Traffic von Netzwerkendpunkten innerhalb des Perimeters zu eingeschränkten Diensten ermöglicht, die Sie auch als über VPC zugängliche Dienste konfiguriert haben. Dienste, die Sie nicht als über VPC zugängliche Dienste konfiguriert haben, können von Netzwerkendpunkten innerhalb des Perimeters nicht erreicht werden.
  
  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-Traffic zu Ihrem VPC-Netzwerk zulässt. Dazu müssen Sie eingehenden Traffic aus dem IP-Adressbereich 35.235.240.0/20 zulassen, der vom Dienst IAP für TCP-Weiterleitung verwendet wird:
    
    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 demo-vm-Instanz hergestellt haben, indem Sie prüfen, ob in der Befehlszeilen-Eingabeaufforderung nun der Hostname Ihrer Instanz angezeigt wird:
    
    username@demo-vm:~$
    
    Wenn der vorherige Befehl fehlschlägt, erhalten Sie möglicherweise eine Fehlermeldung wie diese:
    
    "[/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 Befehl mit der Compute Engine auszufü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 zur Compute Engine API zulässt.
  4. Prüfen Sie in der SSH-Sitzung innerhalb Ihres Perimeters, ob die Dienste, die nicht in der Zulassungsliste der über VPC zugänglichen Dienste enthalten sind, von Ihrer VM aus nicht zulässig sind. 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 nur Dienste anfordern, die in der Zulassungsliste für über VPC zugängliche Dienste konfiguriert sind. Serverlose Ressourcen oder Dienstverkehr, der außerhalb Ihres Perimeters seinen Ursprung hat, können diesen Dienst jedoch anfordern. Wenn Sie verhindern möchten, dass ein Dienst in Ihrem Projekt verwendet wird, lesen Sie die Richtlinie zur eingeschränkten Ressourcennutzung von Diensten.
  Prüfen, ob der Perimeter den 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 Perimeter-Bereichs den folgenden Befehl aus, um einen Storage-Bucket innerhalb Ihres Perimeter-Bereichs 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 Perimeter den folgenden Befehl aus, um Daten aus einem Bucket zu lesen, der sich außerhalb Ihres Perimeter befindet. Dieser öffentliche Bucket erlaubt Lesezugriff auf allUsers, der Perimeter verhindert jedoch den Traffic von innerhalb des Perimeters zu einem eingeschränkten Dienst außerhalb 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 innerhalb des Perimeters verwenden können, eine Ressource innerhalb des Perimeters jedoch nicht mit eingeschränkten Diensten außerhalb des Perimeters kommunizieren kann.
  Prüfen, ob eine Egress-Richtlinie eine Ausnahme für den Perimeter zulässt
  
  In diesem Abschnitt prüfen Sie, ob eine Richtlinie für ausgehenden Traffic eine Ausnahme für den 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 prüfen Sie dieses Konzept, indem Sie eine Richtlinie für ausgehenden Traffic erstellen und dann auf einen öffentlichen Cloud Storage-Bucket außerhalb des durch die Richtlinie für ausgehenden Traffic zulässigen Perimeter zugreifen.
  1. Öffnen Sie eine neue Cloud Shell-Sitzung, indem Sie in Cloud Shell auf Neuen Tab öffnen klicken. In den folgenden Schritten wechseln Sie zwischen dem ersten Tab mit der SSH-Sitzung innerhalb Ihres Perimeter und dem zweiten Tab in Cloud Shell außerhalb Ihres Perimeter, bei dem die Befehlszeile mit username@cloudshell beginnt.
  2. Erstellen Sie auf dem Tab „Cloud Shell“ eine Ausstiegsrichtlinie, die den ausgehenden Traffic von der verknüpften Dienstkontoidentität demo-vm über die Methode google.storage.objects.get zu einem öffentlichen Bucket in einem externen Projekt zulässt. Aktualisieren Sie den Perimeter mit der ausgehenden Richtlinie.
    
    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 Befehlszeilen-Aufforderung 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 Ausstiegsrichtlinien internen Traffic von einer bestimmten Identität zu einem bestimmten Cloud Storage-Bucket zulassen.
    
    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 und versuchen Sie es noch einmal, nachdem der Perimeter vollständig aktualisiert wurde.
  5. Über die SSH-Sitzung in Ihrem Perimeter können Sie auch andere Methoden testen, die durch die Ausnahme der Richtlinie für ausgehenden Traffic nicht ausdrücklich zugelassen wurden. Für den folgenden Befehl ist beispielsweise die Berechtigung google.storage.buckets.list erforderlich, die durch Ihren Perimeter abgelehnt 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 nur explizit angegebene Methoden 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 zur Nutzung eingeschränkter 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 den Organisationsrichtliniendienst Nutzung von Ressourcen eingeschränkter Dienste konfigurieren. 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 Zulassungsrichtlinie definieren, die Compute Engine in Ihrem Projekt zulässt und Cloud Storage ablehnt, kann eine VM in diesem Projekt keinen Cloud Storage-Bucket in Ihrem Projekt erstellen. Die VM kann jedoch Anfragen an einen Cloud Storage-Bucket in einem anderen Projekt senden, sodass eine Exfiltration über den Cloud Storage-Dienst weiterhin möglich ist. In den folgenden Schritten wird gezeigt, wie Sie dieses Szenario implementieren und testen:
  1. Wechseln Sie zum Cloud Shell-Tab, auf dem die Befehlszeile mit username@cloudshell beginnt.
  2. Erstellen Sie auf dem Tab „Cloud Shell“ eine YAML-Datei, in der der Dienst für die Organisationsrichtlinie beschrieben wird, der nur die Nutzung des Compute Engine-Dienstes zulässt und alle anderen Dienste ablehnt. Wenden Sie sie dann auf Ihr Projekt an.
    
    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 Befehlszeilen-Aufforderung mit username@demo-vm beginnt.
  4. Führen Sie in der SSH-Sitzung innerhalb Ihres Perimeter den folgenden Befehl aus, um denselben Speicher-Bucket aufzurufen, 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 Dienst „Organization Policy Service“ den Cloud Storage-Dienst in Ihrem Projekt unabhängig von der Konfiguration des Perimeters ablehnt.
    
    Hinweis: Nach dem Aktualisieren eines Dienstes für Organisationsrichtlinien kann es einige Zeit dauern, bis die Änderungen übernommen und wirksam werden. Wenn Sie ein unerwartetes Ergebnis erhalten, warten Sie eine Minute und versuchen Sie es noch einmal, nachdem der Perimeter vollständig aktualisiert wurde.
  5. Führen Sie in der SSH-Sitzung innerhalb des Perimeters den folgenden Befehl aus, um einen Speicher-Bucket außerhalb des Perimeters aufzurufen, der gemäß Ihrer Richtlinie für ausgehenden Traffic zulässig ist.
    
    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 Exfiltration verwendet werden, wenn sie von Ihrem Perimeter zugelassen sind, unabhängig von der Organisationsrichtlinie zur eingeschränkten Nutzung von Ressourcendiensten.
    
    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. Mit VPC Service Controls werden Daten-Exfiltrationspfade minimiert. Die eingeschränkte Nutzung von Dienstressourcen ist eine Compliance-Kontrolle, die das Erstellen nicht genehmigter Dienste in Ihrer Umgebung verhindert. Verwenden Sie diese Steuerelemente zusammen, um eine Reihe von Exfiltrationspfaden zu genehmigten Diensten zu blockieren und diese 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
  Obwohl für den VPC Service Controls-Perimeter keine zusätzlichen Kosten anfallen, sollten Sie ihn bereinigen, um unnötige und nicht verwendete Ressourcen in Ihrer Organisation zu vermeiden.
  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
  - 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

Hinweise

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 Ihres Perimeters zugelassen sind

Prüfen, ob der Perimeter externen Traffic zu eingeschränkten Diensten ablehnt

Prüfen, ob eine Zugriffsebene eine Ausnahme für den 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 den internen Traffic zu eingeschränkten Diensten außerhalb des Perimeters ablehnt

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

Optional: Richtlinie zur Nutzung eingeschränkter Dienstressourcen konfigurieren

Bereinigen

Nächste Schritte