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

In dieser Anleitung lernen Sie, wie Sie mit VPC Service Controls einen Dienstperimeter einrichten. Dabei werden Netzwerkeinstellungen verwendet, die für die effektive Nutzung eines VPC Service Controls-Perimeters erforderlich sind, z. B. Firewalls, Private Service Connect und DNS-Konfigurationen. Anschließend wird gezeigt, wie Sie Dienste zulassen und ablehnen können und wie Sie für bestimmten Dienste in eine Zulassungsliste detaillierte Ausnahmen festlegen können.

Ziele

  • Einen VPC Service Controls-Perimeter mit zusätzlichen Netzwerkeinstellungen konfigurieren, um Exfiltrationspfade zu reduzieren
  • Zugriff von Anfragen von innerhalb oder außerhalb des Perimeters auf Dienste innerhalb des Perimeters zulassen oder ablehnen
  • Zugriff von Anfragen von innerhalb des Perimeters auf Dienste außerhalb des Perimeters zulassen oder ablehnen
  • Organisationsrichtlinie „Eingeschränkte Nutzung von Dienstressourcen“ und VPC Service Controls gemeinsam verwenden

Kosten

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

Mit dem Preisrechner können Sie eine Kostenschätzung Ihrer voraussichtlichen Nutzung vornehmen.

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie erstellte Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Vorbereitung

  1. Für diese Anleitung benötigen Sie ein Projekt in Ihrer Organisation. Wenn Sie noch keine Organisation in Google Cloud haben, lesen Sie den Abschnitt unter Organisation erstellen und verwalten.

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

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

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    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.

      IAM aufrufen

    2. Wählen Sie die Organisation aus.
    3. Klicken Sie auf Zugriffsrechte erteilen.

    4. Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Das 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. Klicken Sie auf Weitere Rolle hinzufügen, wenn Sie weitere Rollen zuweisen möchten.
    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 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.

        IAM aufrufen

      2. Wählen Sie das Projekt aus.
      3. Klicken Sie auf Zugriffsrechte erteilen.

      4. Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Das 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. Klicken Sie auf Weitere Rolle hinzufügen, wenn Sie weitere Rollen zuweisen möchten.
      7. Klicken Sie auf Speichern.

        8. VPC Service Controls-Perimeter einrichten

        Bevor Sie einen VPC Service Controls-Perimeter für ein VPC-Netzwerk einrichten, müssen Sie mithilfe von Netzwerkeinstellungen den Traffic zu externen Diensten verweigern. In den folgenden Abschnitten werden die Netzwerkkonfigurationen für VPC-Netzwerke innerhalb Ihres Perimeters detailliert beschrieben. Außerdem wird eine Beispielkonfiguration des Perimeters vorgestellt.

        VPC-Netzwerk vorbereiten

        In diesem Abschnitt richten Sie eine private Verbindung zu Google APIs und Google-Diensten für Ihr VPC-Netzwerk ein. Damit möchten Sie verhindern, dass Daten über verschiedene Netzwerkpfade ins Internet gelangen.

        1. Legen Sie in der Cloud Shell die Variablen fest:

          gcloud config set project PROJECT_ID
gcloud config set compute/region REGION
gcloud config set compute/zone ZONE

          Ersetzen Sie die folgenden Variablen:

          • PROJECT_ID: die Projekt-ID des Projekts, in dem Sie Ressourcen erstellen
          • REGION: eine Region in der Nähe Ihres Standorts, 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. Der private Google-Zugriff ist aktiviert:

          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, in der das Bundle „vpc-sc“ 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 Serverrichtlinie in Cloud DNS so, dass Anfragen für Google Cloud-APIs an Ihren Private Service Connect-Endpunkt umgeleitet werden:

          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, die den gesamten ausgehenden Traffic ablehnt:

          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, die den Traffic zur IP-Adresse Ihres Private Service Connect-Endpunkts zulässt:

          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

          Mit diesen Firewallregeln wird der ausgehende Traffic zuerst generell verweigert, und dann selektiv zum Private Service Connect-Endpunkt zugelassen. Diese Konfiguration verweigert ausgehenden Traffic zu den Standarddomains, die mit privatem Google-Zugriff und den implizierten Firewallregeln normalerweise per Standard erreichbar sind.

        VPC Service Controls-Perimeter erstellen

        In diesem Abschnitt erstellen Sie einen VPC Service Controls-Perimeter.

        1. Erstellen Sie als Voraussetzung für die Einrichtung eines VPC Service Controls-Perimeters in der Cloud Shell eine Zugriffsrichtlinie:

          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 von außerhalb des Perimeters zulässig sind

        In den folgenden Abschnitten wird gezeigt, wie Sie mit dem VPC Service Controls-Perimeter den Zugriff auf Anfragen von außerhalb des Perimeters zulassen bzw. verweigern und wie Sie den Zugriff auf Dienste mithilfe von Zugriffsebenen und Zugriffsrichtlinien selektiv zulassen.

        Um Traffic von außerhalb Ihres Perimeters zu simulieren, führen Sie Befehle in der Cloud Shell aus. Die Cloud Shell ist eine Ressource außerhalb Ihres eigenen Projekts und Perimeters. Mit dem Perimeter können Sie auch Anfragen zulassen bzw. ablehnen, deren IAM-Berechtigungen (Identity and Access Management) eigentlich ausreichen, um erfolgreich zu sein.

        In dieser Anleitung werden die Compute Engine API, die Cloud Storage API und die Cloud Resource Manager API verwendet. Die vorgestellten Konzepte gelten aber 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.

        Architekturdiagramm, das einen VPC Service Controls-Perimeter zeigt, mit dem der Zugriff auf eingeschränkte Dienste verweigert wird

        Der im Diagramm oben dargestellte autorisierte Client kann nicht auf Dienste innerhalb des Perimeters zugreifen, die Sie als eingeschränkt konfiguriert haben. Auf Dienste, die Sie nicht als eingeschränkt konfiguriert haben, kann er jedoch zugreifen.

        In den folgenden Schritten prüfen Sie dieses Konzept. Dafür versuchen Sie mit der Cloud Shell, eine VM innerhalb Ihres VPC-Netzwerks zu erstellen, was aufgrund der Konfiguration des VPC Service Controls-Perimeters fehlschlägt.

        1. Führen Sie in der Cloud Shell den folgenden Befehl aus, um in Ihrem VPC-Netzwerk 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

          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 sich die Cloud Shell außerhalb Ihres Perimeters befindet und Compute Engine mit dem Flag --restricted-services konfiguriert ist.

        2. Führen Sie in der 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

          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 ablehnt, die in --restricted-services konfiguriert sind, 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 vom Perimeter zulässt

        In diesem Abschnitt prüfen Sie, ob eine Zugriffsebene eine Ausnahme vom Perimeter zulässt. Die Zugriffsebene ist nützlich, um Ausnahmen für externen Traffic zu erstellen, mit denen Sie auf alle eingeschränkten Dienste innerhalb des Perimeters zugreifen können. Dabei benötigen Sie nicht für jeden Dienst detaillierte Ausnahmen oder andere Attribute.

        Architekturdiagramm, das eine Zugriffsebene zeigt, die für alle Dienste innerhalb des VPC Service Controls-Perimeters eine Ausnahme zulässt

        Die im Diagramm oben dargestellte Zugriffsebene ermöglicht einem autorisierten Client den Zugriff auf alle eingeschränkten Dienste innerhalb des Perimeters.

        In den folgenden Schritten prüfen Sie dieses Konzept. Sie erstellen eine Zugriffsebene und stellen dann eine erfolgreiche Anfrage an den Compute Engine-Dienst. Die Anfrage wird zugelassen, obwohl Compute Engine als eingeschränkt konfiguriert ist.

        1. Erstellen Sie in der Cloud Shell eine YAML-Datei, in der die Konfiguration einer Zugriffsebene beschrieben wird. Wenden Sie die Datei auf Ihren Perimeter an. In diesem Beispiel wird für die Nutzeridentität eine Zugriffsebene erstellt, mit der Sie derzeit die Anleitung 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 der Cloud Shell noch einmal den folgenden Befehl aus, um zu versuchen, 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

          Jetzt funktioniert die Anfrage. Der Perimeter verhindert, dass die eingeschränkten Dienste vom externen Traffic genutzt werden. Die von Ihnen konfigurierte Zugriffsebene ermöglicht jedoch eine Ausnahme.

        Prüfen, ob eine Richtlinie für eingehenden Traffic detaillierte Ausnahmen vom Perimeter zulässt

        In diesem Abschnitt prüfen Sie, ob eine Richtlinie für eingehenden Traffic eine detaillierte Ausnahme vom Perimeter zulässt. Im Vergleich zur gröberen Zugriffsebene können Sie mit einer detaillierten Richtlinie für eingehenden Traffic zusätzliche Attribute zur Traffic-Quelle konfigurieren und den Zugriff auf einzelne Dienste oder Methoden zulassen.

        Architekturdiagramm, das eine Richtlinie für eingehenden Traffic zeigt, die für bestimmte Dienste eine detaillierte Ausnahme innerhalb des Perimeters ermöglicht

        Die im Diagramm oben gezeigte Richtlinie für eingehenden Traffic ermöglicht einem autorisierten Client den Zugriff auf einen bestimmten Dienst innerhalb des Perimeters, verweigert jedoch den Zugriff auf andere eingeschränkte Dienste.

        In den folgenden Schritten überprüfen Sie dieses Konzept. Sie ersetzen die Zugriffsebene durch eine Richtlinie für eingehenden Traffic, die einem autorisierten Client nur den Zugriff auf den Compute Engine-Dienst erlaubt, aber keinen Zugriff auf andere eingeschränkte Dienste.

        1. Führen Sie auf dem Cloud Shell-Tab 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 Cloud Shell-Tab eine Richtlinie für eingehenden Traffic, die es Ihrer Nutzeridentität erlaubt, nur auf den Compute Engine-Dienst zuzugreifen. 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 etwa so aus:

          "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."

          Die Cloud Shell ist ein Client außerhalb des Perimeters. Daher blockiert der VPC Service Controls-Perimeter die Kommunikation der Cloud Shell 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 zu senden.

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

          Bei einer erfolgreichen Antwort werden die Details von demo-vm zurückgegeben. Diese Antwort zeigt, dass Ihr Perimeter externen Traffic zulässt, der die Bedingungen Ihrer Richtlinie für eingehenden Traffic für den Compute Engine-Dienst erfüllt.

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

        In den folgenden Abschnitten wird gezeigt, wie Sie mit dem VPC Service Controls-Perimeter Anfragen an Dienste innerhalb des Perimeters zulassen bzw. ablehnen und wie Sie ausgehenden Traffic zu externen Diensten mithilfe von Richtlinien für externe Dienste selektiv zulassen.

        Um den Unterschied zwischen Traffic innerhalb und außerhalb des Perimeters zu veranschaulichen, werden in den folgenden Abschnitten die Cloud Shell außerhalb des Perimeters und eine Compute Engine-Instanz verwendet, die Sie innerhalb des Perimeters erstellen. In Befehlen, die Sie über die SSH-Sitzung auf der Compute Engine-Instanz innerhalb des Perimeters ausführen, verwenden Sie die Identität des zugehörigen Dienstkontos. In Befehlen, die Sie über die Cloud Shell außerhalb des Perimeters ausführen, verwenden Sie hingegen Ihre eigene Identität. Wenn Sie die für die Anleitung empfohlene Einrichtung befolgen, erlaubt oder verweigert der Perimeter auch Anfragen, die aufgrund ausreichender IAM-Berechtigungen eigentlich erfolgreich sein müssten.

        In dieser Anleitung werden die Compute Engine API, die Cloud Storage API und die Cloud Resource Manager API verwendet. Die vorgestellten Konzepte gelten aber 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 Ihres Perimeters zulässt, wenn der Dienst auch in zugänglichen VPC-Diensten konfiguriert ist.

        Architekturdiagramm, das eine Konfiguration von „vpc-accessible-services“ zeigt, mit der der Zugriff auf Dienste über interne Netzwerkendpunkte möglich ist.

        Der Perimeter im Diagramm oben lässt Traffic von Netzwerkendpunkten innerhalb des Perimeters zu eingeschränkten Diensten zu, die Sie auch als zugängliche VPC-Dienste konfiguriert haben. Dienste, die nicht als zugängliche VPC-Dienste konfiguriert sind, sind über Netzwerkendpunkte innerhalb des Perimeters nicht erreichbar.

        In den folgenden Schritten überprüfen Sie dieses Konzept. Sie stellen eine SSH-Verbindung zur Compute Engine-Instanz innerhalb des Perimeters her und stellen dann Anfragen an Dienste.

        1. Erstellen Sie in der Cloud Shell eine Firewallregel, die SSH-Traffic zu Ihrem VPC-Netzwerk zulässt. Der zugelassene eingehende Traffic kommt aus dem IP-Adressbereich 35.235.240.0/20, 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 die Verbindung zur Instanz demo-vm funktioniert. Überprüfen Sie dazu, ob sich der Prompt in der Befehlszeile geändert hat und nun den Hostnamen Ihrer Instanz anzeigt:

          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 wurde die Compute Engine-Instanz möglicherweise nicht vollständig gestartet. Warten Sie eine Minute und versuchen Sie es dann noch einmal.

        3. Prüfen Sie in der SSH-Sitzung innerhalb Ihres Perimeters, die von Ihrem Perimeter intern zugelassenen Dienste. Verwenden Sie dazu einen Dienst von Google Cloud , der in der Zulassungsliste für zugängliche VPC-Dienste konfiguriert ist. Probieren Sie beispielsweise einen beliebigen Befehl mit dem Compute Engine-Dienst aus.

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

          Bei einer erfolgreichen Antwort werden die Details von demo-vm zurückgegeben. Diese Antwort zeigt, dass Ihr Perimeter internen Traffic zur Compute Engine-API zulässt.

        4. Vergewissern Sie sich in der SSH-Sitzung innerhalb Ihres Perimeters, dass Dienste, die nicht in der Zulassungsliste für zugängliche VPC-Dienste enthalten sind, von Ihrer VM nicht zugelassen werden. Beispielsweise verwendet der folgende Befehl den Dienst „Resource Manager“, der nicht in der Zulassungsliste für zugängliche VPC-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 zugängliche VPC-Dienste konfiguriert sind. Serverlose Ressourcen oder Traffic, der von außerhalb Ihres Perimeters stammt, 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 Nutzung von Dienstressourcen.

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

        In diesem Abschnitt prüfen Sie, ob der Perimeter die Kommunikation von Diensten innerhalb des Perimeters zu Diensten von Google Cloud außerhalb des Perimeters blockiert.

        Architekturdiagramm, das einen VPC Service Controls-Perimeter zeigt, der den Zugriff von Traffic innerhalb des Perimeters auf eingeschränkte Dienste außerhalb des Perimeters verweigert

        Der im Diagramm oben dargestellte Perimeter verhindert, dass interner Traffic mit eingeschränkten Diensten außerhalb des Perimeters kommunizieren kann.

        In den folgenden Schritten überprüfen Sie dieses Konzept. Dazu versuchen Sie, 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 Speicher-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 aus einem Bucket außerhalb Ihres Perimeters zu lesen. Dieser öffentliche Bucket gewährt allUsers Leserechte, aber der Perimeter verweigert Traffic von innerhalb Ihres Perimeters zu eingeschränkten Diensten außerhalb des Perimeters.

          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, aber Ressourcen innerhalb des Perimeters nicht mit eingeschränkten Diensten außerhalb des Perimeters kommunizieren können.

        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.

        Architekturdiagramm, das zeigt, wie eine Richtlinie für ausgehenden Traffic bestimmte Ausnahmen zulässt, damit ein eingeschränkter Dienst außerhalb des Perimeters erreicht werden kann

        Der interne Traffic im Diagramm oben kann mit einer bestimmten externen Ressource kommunizieren, wenn Sie mit der Richtlinie für ausgehenden Traffic eine enge Ausnahme zulassen.

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

        1. Öffnen Sie eine neue Cloud Shell-Sitzung, indem Sie in der Cloud Shell auf 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 der Cloud Shell außerhalb Ihres Perimeters, auf dem die Befehlszeile mit username@cloudshell beginnt.

        2. Erstellen Sie auf dem Cloud Shell-Tab eine Richtlinie für ausgehenden Traffic. Diese ermöglicht mit der Methode google.storage.objects.get ausgehenden Traffic von der angehängten Dienstkontoidentität von demo-vm zu einem öffentlichen Bucket in einem externen Projekt. 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. Wechseln Sie zurück zum Tab mit der SSH-Sitzung zur VM innerhalb Ihres Perimeters, in dem die Befehlszeile 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 Ihr Perimeter- und Ihre Richtlinie für ausgehenden Traffic den internen Traffic von einer bestimmten Identität zu einem bestimmten Cloud Storage-Bucket zulassen.

        5. In der SSH-Sitzung in Ihrem Perimeter können Sie auch andere Methoden testen, die nicht explizit über 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 den internen Traffic den internen Traffic zum Auflisten von Objekten im externen Bucket verweigert. Dies deutet darauf hin, dass die Richtlinie für ausgehenden Traffic 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 eingeschränkten Nutzung von Dienstressourcen konfigurieren

        Möglicherweise gelten in Ihrem Unternehmen interne oder Compliance-Anforderungen, nach denen nur individuell genehmigte APIs in Ihrer Umgebung verwendet werden dürfen. In diesem Fall können Sie auch die Organisationsrichtlinie zur eingeschränkten Nutzung von Dienstressourcen konfigurieren. Durch die Anwendung der Organisationsrichtlinie in einem Projekt schränken Sie ein, welche Dienste in diesem Projekt erstellt werden können. Die Organisationsrichtlinie verhindert jedoch nicht, dass Dienste aus 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 zulässt und Cloud Storage in Ihrem Projekt ablehnt, kann eine VM in diesem Projekt keinen Cloud Storage-Bucket in Ihrem Projekt erstellen. Sie kann jedoch Anfragen an einen Cloud Storage-Bucket in einem anderen Projekt stellen, sodass eine Exfiltration mit dem Cloud Storage-Dienst weiterhin möglich ist. Die folgenden Schritte zeigen, wie Sie dieses Szenario implementieren und testen können:

        1. Wechseln Sie zum Cloud Shell-Tab, auf dem die Befehlszeile mit username@cloudshell beginnt.

        2. Erstellen Sie auf dem Cloud Shell-Tab eine YAML-Datei, die den Organisationsrichtliniendienst beschreibt, der nur die Nutzung 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. Wechseln Sie zurück zum Tab mit der SSH-Sitzung zur VM innerhalb Ihres Perimeters, in dem die Befehlszeile 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 Organisationsrichtliniendienst den Cloud Storage-Dienst innerhalb Ihres Projekts 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 gemäß Ihrer Richtlinie für ausgehenden Traffic zulässig 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 den internen Traffic unter bestimmten eingeschränkten Bedingungen zu einem externen Speicher-Bucket zulassen. Der Organisationsrichtliniendienst aber lehnt den Cloud Storage-Dienst in Ihrem Projekt unabhängig von der Konfiguration Ihres Perimeters ab. Dienste außerhalb Ihres Projekts können unabhängig von der Organisationsrichtlinie „Eingeschränkte Nutzung von Dienstressourcen“ weiterhin für die Exfiltration verwendet werden, wenn sie von Ihrem Perimeter zugelassen werden.

          Um Kommunikation mit Cloud Storage oder anderen Google-Diensten außerhalb des Perimeters zu unterbinden, reicht der Organisationsrichtlinie zur eingeschränkten Nutzung von Dienstressourcen allein nicht aus. Sie müssen einen VPC Service Controls-Perimeter konfigurieren. VPC Service Controls reduziert Datenexfiltrationspfade. Die Richtlinie zur eingeschränkten Nutzung von Dienstressourcen ist eine Compliance-Kontrolle, um die Erstellung nicht genehmigter Dienste in Ihrer Umgebung zu verhindern. Verwenden Sie diese Einstellungen zusammen, um eine Reihe von Exfiltrationspfaden zu blockieren und genehmigte Dienste für die interne Nutzung in Ihrer Umgebung selektiv zuzulassen.

        Bereinigen

      8. In the Google Cloud console, go to the Manage resources page.

        Go to Manage resources

      9. In the project list, select the project that you want to delete, and then click Delete.
      10. In the dialog, type the project ID, and then click Shut down to delete the project.

        11. Obwohl der VPC Service Controls-Perimeter keine zusätzlichen Kosten verursacht, sollten er bereinigt werden, 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. Wechseln Sie in der Google Cloud Console zur Seite VPC Service Controls.

          Zu VPC Service Controls

        3. Wählen Sie den Perimeter, den Sie löschen möchten, aus der Liste der Perimeter aus, 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