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 erstellen.

Lernziele

• Konfigurieren Sie einen VPC Service Controls-Perimeter mit zusätzlichen Netzwerksteuerungen, um Exfiltrationspfade zu minimieren.
• Zugriff auf Dienste innerhalb des Perimeters durch Anfragen, die innerhalb oder außerhalb des Perimeters stammen, zulassen oder ablehnen.
• Zugriff auf Dienste außerhalb des Perimeters über Anfragen, die innerhalb des Perimeters stammen, zulassen oder verweigern.
• Verwenden Sie die Organisationsrichtlinie „Ressourcendienstnutzung einschränken“ und VPC Service Controls zusammen.

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloudverwendet:

• Compute Engine
• Cloud Storage
• Private Service Connect

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

1. Für dieses Tutorial ist ein Projekt in Ihrer Organisation erforderlich. Wenn Sie noch keine Google Cloud Organisation haben, finden Sie weitere Informationen unter Organisation erstellen und verwalten.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.

   Enable the APIs

5. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

6. 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 column 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.

      Zu IAM

   2. Wählen Sie die Organisation aus.
   3. Klicken Sie auf person_add 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 add Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.
   7. Klicken Sie auf Speichern.

7. 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 column 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.

      Zu IAM

   2. Wählen Sie das Projekt aus.
   3. Klicken Sie auf person_add 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 add 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 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 einen Perimeter.

   VPC-Netzwerk vorbereiten

   In diesem Abschnitt richten Sie private Verbindungen zu Google APIs und Google-Diensten für Ihr VPC-Netzwerk ein, um eine Reihe von Netzwerk-Egress-Pfaden 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 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. Bei dieser Konfiguration wird der ausgehende Traffic zu den Standarddomains verweigert, 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.

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

   Prüfen, welche Dienste für Traffic außerhalb Ihres Perimeters zulässig 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 Ingress zu Diensten 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 außerhalb Ihres eigenen Projekts und Perimeters. Der Perimeter lässt Anfragen zu oder lehnt sie ab, obwohl die Anfragen über ausreichende Identity and Access Management-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. Die gleichen 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 zu eingeschränkten Diensten 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. Der Client darf jedoch auf Dienste zugreifen, die Sie nicht als eingeschränkt konfiguriert haben.

   In den folgenden Schritten wird dieses Konzept überprüft, 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 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 Cloud Shell außerhalb Ihres Perimeters liegt und 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 im Flag --restricted-services konfiguriert ist.

      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 nachgewiesen, 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 Sie auf eingeschränkte Dienste innerhalb des Perimeters zugreifen 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 vom Perimeter zulässt. Eine Zugriffsebene ist nützlich, wenn Sie eine Ausnahme für externen Traffic erstellen möchten, damit auf alle eingeschränkten Dienste innerhalb des Perimeters zugegriffen werden kann, und Sie keine detaillierten Ausnahmen für jeden Dienst oder andere Attribute benötigen.

   

   Das vorherige Diagramm veranschaulicht, 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 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. In diesem Beispiel wird eine Zugriffsebene für die Nutzeridentität erstellt, die Sie derzeit zum Ausführen des Tutorials verwenden.

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

      Dieses Mal funktioniert die Anfrage. Ihr Perimeter verhindert, dass externer Traffic die eingeschränkten Dienste verwendet. Die von Ihnen konfigurierte Zugriffsebene lässt jedoch eine Ausnahme zu.

   Prüfen, ob eine Ingress-Richtlinie eine detaillierte Ausnahme vom Perimeter zulässt

   In diesem Abschnitt prüfen Sie, ob eine Richtlinie für eingehenden Traffic 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 Traffic-Quelle konfiguriert und der Zugriff auf einzelne Dienste oder Methoden erlaubt werden.

   

   Das vorherige Diagramm zeigt, wie eine Ingress-Richtlinie einem autorisierten Client den Zugriff auf einen bestimmten Dienst innerhalb des Perimeters ermöglicht, ohne den Zugriff auf andere eingeschränkte Dienste zu erlauben.

   In den folgenden Schritten wird dieses Konzept überprüft, indem die Zugriffsebene durch eine Ingress-Richtlinie ersetzt wird, die einem autorisierten Client nur den Zugriff auf den Compute Engine-Dienst, aber nicht auf andere eingeschränkte Dienste ermöglicht.

   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 Richtlinie für eingehenden Traffic, die es Ihrer Nutzeridentität erlaubt, nur auf den Compute Engine-Dienst zuzugreifen, 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 Perimeters zu erstellen.

      gcloud storage buckets create gs://PROJECT_ID-01

      Die Ausgabe sieht 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 wird die Kommunikation von Cloud Shell mit eingeschränkten Diensten innerhalb des Perimeters durch den VPC Service Controls-Perimeter blockiert.

   4. Führen Sie auf dem Tab „Cloud Shell“ den folgenden Befehl aus, um eine Anfrage an den Compute Engine-Dienst innerhalb des Perimeters zu senden.

      gcloud compute instances describe demo-vm --zone=ZONE

      Eine erfolgreiche Antwort gibt die Details von 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 Sie, welche Dienste für Traffic innerhalb Ihres 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 ausgehenden Traffic zu externen Diensten selektiv über Richtlinien für ausgehenden Traffic zulassen können.

   Um den Unterschied zwischen Traffic innerhalb und außerhalb des Perimeters zu veranschaulichen, werden 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. Bei der empfohlenen Einrichtung für das Tutorial werden Anfragen vom Perimeter zugelassen oder abgelehnt, obwohl die Anfragen über ausreichende IAM-Berechtigungen verfügen.

   In dieser Anleitung werden die Compute Engine API, die Cloud Storage API und die Cloud Resource Manager API verwendet. Die gleichen Konzepte gelten jedoch auch für andere Dienste.

   Prüfen Sie, 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 Ihres Perimeters zulässt, wenn der Dienst auch in Über VPC zugängliche Dienste konfiguriert ist.

   

   Das vorherige Diagramm veranschaulicht, wie ein Perimeter es ermöglicht, dass Traffic von Netzwerkendpunkten innerhalb des Perimeters eingeschränkte Dienste erreicht, 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 nicht über Netzwerkendpunkte innerhalb des Perimeters erreicht werden.

   In den folgenden Schritten überprüfen Sie dieses Konzept, indem Sie eine SSH-Verbindung zur Compute Engine-Instanz innerhalb des Perimeters 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

      Vergewissern Sie sich, dass Sie erfolgreich eine Verbindung zur demo-vm-Instanz hergestellt haben, indem Sie bestätigen, dass 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 über VPC zugänglichen Dienste konfiguriert ist. Probieren Sie beispielsweise einen beliebigen Befehl mit dem Compute Engine-Dienst aus.

      gcloud compute instances describe demo-vm --zone=ZONE

      Eine erfolgreiche Antwort gibt die Details von 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 nicht zugelassen werden. Im folgenden Beispiel wird der Resource Manager-Dienst verwendet, der nicht in der Liste der über VPC zugänglichen Dienste konfiguriert ist.

      gcloud projects describe PROJECT_ID

      Die Ausgabe sieht 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 Diensttraffic, die ihren Ursprung außerhalb Ihres Perimeters haben, 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 Sie, 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 veranschaulicht, wie interner Traffic nicht mit eingeschränkten Diensten außerhalb des Perimeters kommunizieren kann.

   In den folgenden Schritten überprü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 innerhalb Ihres Perimeters zu erstellen. Dieser Befehl funktioniert, weil 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 Storage-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, um Daten aus einem Bucket außerhalb Ihres Perimeters zu lesen. Dieser öffentliche Bucket erlaubt die schreibgeschützte Berechtigung für allUsers, der Perimeter lehnt jedoch Traffic von innerhalb Ihres Perimeters zu einem eingeschränkten Dienst außerhalb des Perimeters ab.

      gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

      Die Ausgabe sieht 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 vom 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 obige Diagramm zeigt, wie interner Traffic mit einer bestimmten externen Ressource kommunizieren kann, wenn Sie mit der Egress-Richtlinie eine enge Ausnahme gewähren.

   In den folgenden Schritten wird dieses Konzept überprüft, indem Sie eine Richtlinie für ausgehenden Traffic erstellen und dann auf einen öffentlichen Cloud Storage-Bucket außerhalb des Perimeters zugreifen, der durch die Richtlinie für ausgehenden Traffic zugelassen wird.

   1. Öffnen Sie eine neue Cloud Shell-Sitzung, indem Sie in Cloud Shell auf add Neuen Tab öffnen klicken. In den folgenden Schritten wechseln Sie zwischen dem ersten Tab mit der SSH-Sitzung innerhalb Ihres Perimeters und dem zweiten Tab in Cloud Shell außerhalb Ihres Perimeters, auf dem die Eingabeaufforderung mit username@cloudshell beginnt.

   2. Erstellen Sie auf dem Tab „Cloud Shell“ eine Richtlinie für ausgehenden Traffic, die ausgehenden Traffic von der angehängten Dienstkontoidentität von 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 Perimeters zurück, auf dem die Eingabeaufforderung mit username@demo-vm beginnt.

   4. Stellen Sie in der SSH-Sitzung innerhalb Ihres Perimeters eine weitere 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 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 Egress-Richtlinie internen Traffic von einer bestimmten Identität zu einem bestimmten Cloud Storage-Bucket zulässt.

   5. In der SSH-Sitzung in Ihrem Perimeter können Sie auch andere Methoden testen, die nicht explizit durch die Ausnahme für die Richtlinie für ausgehenden Traffic zugelassen wurden. Für den folgenden Befehl ist beispielsweise die Berechtigung google.storage.buckets.list erforderlich, die von Ihrem Perimeter abgelehnt wird.

      gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*

      Die Ausgabe sieht 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 deutet darauf hin, dass die Egress-Richtlinie nur explizit angegebene Methoden zulässt.

   Weitere Informationen zu gängigen Mustern für die Freigabe von Daten außerhalb des Serviceperimeters finden Sie unter Sicherer Datenaustausch mit Regeln für ein- und ausgehenden Traffic.

   Optional: Richtlinie zur eingeschränkten Nutzung von Dienstressourcen konfigurieren

   Möglicherweise haben Sie auch interne oder Compliance-Anforderungen, die die Verwendung von APIs in Ihrer Umgebung auf einzeln genehmigte APIs beschränken. In diesem Fall können Sie auch den Organisationsrichtliniendienst für die Nutzung eingeschränkter Serviceressourcen konfigurieren. Wenn Sie die Organisationsrichtlinie in einem Projekt anwenden, schränken Sie ein, 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. Im Vergleich dazu können Sie mit VPC Service Controls einen Perimeter definieren, um die Kommunikation mit Diensten außerhalb des Perimeters zu verhindern.

   Wenn Sie beispielsweise eine Organisationsrichtlinie definieren, die Compute Engine in Ihrem Projekt zulässt und Cloud Storage ablehnt, kann eine VM in diesem Projekt kein 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. Im Folgenden wird beschrieben, 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 Organizationsrichtliniendienst beschrieben wird, der nur die Verwendung des Compute Engine-Dienstes zulässt und alle anderen Dienste ablehnt. Wenden Sie die Datei 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 Perimeters zurück, auf dem die Eingabeaufforderung mit username@demo-vm beginnt.

   4. Führen Sie in der SSH-Sitzung innerhalb Ihres Perimeters den folgenden Befehl aus, um den Speicher-Bucket aufzurufen, den Sie zuvor in diesem Projekt erstellt haben.

      gcloud storage buckets describe gs://PROJECT_ID

      Die Ausgabe sieht 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 Organization Policy Service den Cloud Storage-Dienst in Ihrem Projekt unabhängig von der Konfiguration Ihres Perimeters verweigert.

   5. Führen Sie in der SSH-Sitzung innerhalb Ihres Perimeters den folgenden Befehl aus, um einen Speicher-Bucket außerhalb des Perimeters aufzurufen, der durch Ihre Richtlinie für ausgehenden Traffic zugelassen ist.

      gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

      Die Ausgabe sieht 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 internen Traffic zu einem externen Speicher-Bucket zulassen, der Organization Policy Service den Cloud Storage-Dienst in Ihrem Projekt jedoch unabhängig von der Konfiguration Ihres Perimeters ablehnt. Dienste außerhalb Ihres Projekts können weiterhin für die Exfiltration verwendet werden, wenn sie von Ihrem Perimeter zugelassen werden, 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 unterbinden möchten, reicht die Organisationsrichtlinie Einschränkung der Ressourcendienstnutzung allein nicht aus. Sie müssen einen VPC Service Controls-Perimeter konfigurieren. VPC Service Controls minimiert Daten-Exfiltrationspfade und Restricted Service Resource Usage ist eine Compliance-Kontrolle, um die Erstellung nicht genehmigter Dienste in Ihrer Umgebung zu verhindern. 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

   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 -Konsole 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 Architecture Center.