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 dieser Anleitung werden Netzwerkeinstellungen wie Firewalls, Private Service Connect und DNS-Konfigurationen verwendet, die für eine effektive Nutzung eines VPC Service Controls-Perimeters erforderlich sind. In dieser Anleitung wird dann gezeigt, wie Dienste zugelassen oder abgelehnt werden und wie Sie detaillierte Ausnahmen für eine Zulassungsliste bestimmter Dienste festlegen.

Lernziele

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

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

  1. Für diese Anleitung ist ein Projekt in Ihrer Organisation erforderlich. Wenn Sie noch keine Google Cloud-Organisation haben, lesen Sie Organisation erstellen und verwalten.

  2. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  4. Compute Engine, Access Context Manager und Cloud DNS APIs aktivieren.

    Aktivieren Sie die APIs

  5. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

  6. Prüfen Sie, ob Sie die folgenden Rollen für die Organisation haben: Access Context Manager Admin, Organization Policy Administrator

    Auf Rollen prüfen

    1. Öffnen Sie in der Google Cloud Console die Seite IAM.

      IAM aufrufen
    2. Wählen Sie die Organisation aus.

    3. Suchen Sie in der Spalte Hauptkonto die Zeile mit Ihrer E-Mail-Adresse.

      Ist Ihre E-Mail-Adresse nicht in dieser Spalte enthalten, haben Sie keine Rollen.

    4. Prüfen Sie in der Spalte Rolle der Zeile mit Ihrer E-Mail-Adresse, ob die Liste der Rollen die erforderlichen Rollen enthält.

    Rollen zuweisen

    1. Öffnen Sie in der Google Cloud Console die Seite IAM.

      IAM aufrufen
    2. Wählen Sie die Organisation aus.
    3. Klicken Sie auf Zugriff erlauben.
    4. Geben Sie in das Feld Neue Hauptkonten Ihre E-Mail-Adresse ein.
    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.

  7. Prüfen Sie, ob Sie die folgenden Rollen für das Projekt haben: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor

    Auf Rollen prüfen

    1. Öffnen Sie in der Google Cloud Console die Seite IAM.

      IAM aufrufen
    2. Wählen Sie das Projekt aus.

    3. Suchen Sie in der Spalte Hauptkonto die Zeile mit Ihrer E-Mail-Adresse.

      Ist Ihre E-Mail-Adresse nicht in dieser Spalte enthalten, haben Sie keine Rollen.

    4. Prüfen Sie in der Spalte Rolle der Zeile mit Ihrer E-Mail-Adresse, ob die Liste der Rollen die erforderlichen Rollen enthält.

    Rollen zuweisen

    1. Öffnen Sie in der Google Cloud Console die Seite IAM.

      IAM aufrufen
    2. Wählen Sie das Projekt aus.
    3. Klicken Sie auf Zugriff erlauben.
    4. Geben Sie in das Feld Neue Hauptkonten Ihre E-Mail-Adresse ein.
    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 Netzwerkkontrollen implementieren, die Traffic zu externen Diensten ablehnen. In den folgenden Abschnitten werden die Netzwerkkonfigurationen, die Sie in VPC-Netzwerken innerhalb Ihres Perimeters implementieren müssen, sowie ein Beispiel für eine Perimeterkonfiguration beschrieben.

VPC-Netzwerk vorbereiten

In diesem Abschnitt richten Sie eine private Verbindung zu Google APIs und Google-Diensten für Ihr VPC-Netzwerk ein, um eine Reihe von ausgehenden Netzwerkpfaden zum Internet zu entschärfen.

  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 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, 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 Bundles vpc-sc konfiguriert sind:

    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 so, dass Abfragen für Google Cloud APIs an Ihren Private Service Connect-Endpunkt weitergeleitet 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, 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 der Traffic die von Ihrem Private Service Connect-Endpunkt verwendete IP-Adresse erreichen kann:

    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 lehnen ausgehenden Traffic grob ab, bevor ausgehender Traffic zum Private Service Connect-Endpunkt selektiv zugelassen wird. Mit dieser Konfiguration wird ausgehender Traffic an die Standarddomains abgelehnt, die normalerweise standardmäßig über den privater Google-Zugriff und die 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 das Erstellen 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."

    Auf dem Organisationsknoten kann es nur einen Zugriffsrichtliniencontainer 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 von Traffic außerhalb Ihres Perimeters zugelassen werden

In den folgenden Abschnitten wird gezeigt, wie der Perimeter von VPC Service Controls den Zugriff auf Anfragen von außerhalb des Perimeters zulässt oder verweigert und wie Sie selektiv eingehenden Traffic zu Diensten zulassen können, indem Sie Zugriffsebenen und Richtlinien für eingehenden Traffic konfigurieren.

Sie können Befehle in Cloud Shell ausführen, um Traffic von außerhalb Ihres Perimeters zu simulieren. Cloud Shell ist eine Ressource außerhalb Ihres eigenen Projekts und Perimeters. Der Perimeter lässt Anfragen zu oder lehnt sie ab, obwohl sie ausreichende Berechtigungen für Identity and Access Management haben, 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 Sie, 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 zeigt, wie ein VPC Service Controls-Perimeter den Zugriff auf eingeschränkte Dienste verweigert

Das vorherige Diagramm zeigt, wie einem autorisierten Client der Zugriff auf Dienste innerhalb des von Ihnen als eingeschränkt konfigurierten Perimeters verweigert wird, dem Client jedoch Zugriff auf Dienste gewährt wird, die Sie nicht als eingeschränkt konfiguriert haben.

In den folgenden Schritten prüfen Sie dieses Konzept mithilfe von Cloud Shell, um zu 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 Perimeters befindet 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

    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 für den Zugriff auf eingeschränkte Dienste innerhalb des Perimeters eingeführt.

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 erstellen möchten, um auf alle eingeschränkten Dienste innerhalb des Perimeters zuzugreifen, und keine detaillierten Ausnahmen für jeden Dienst oder andere Attribute benötigen.

Architekturdiagramm, das zeigt, wie eine Zugriffsebene eine Ausnahme für alle Dienste innerhalb des VPC Service Controls-Perimeters gewährt

Das vorherige Diagramm zeigt, wie ein autorisierter Client mit einer Zugriffsebene auf alle eingeschränkten Dienste innerhalb des Perimeters zugreifen kann.

In den folgenden Schritten prü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 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 der Anleitung 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 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

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

Prüfen Sie, ob eine Richtlinie für eingehenden Traffic eine detaillierte Ausnahme 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 groben Zugriffsebene kann eine detaillierte Richtlinie für eingehenden Traffic zusätzliche Attribute zur Besucherquelle konfigurieren und den Zugriff auf einzelne Dienste oder Methoden ermöglichen.

Architekturdiagramm, das zeigt, wie eine Richtlinie für eingehenden Traffic es einer detaillierten Ausnahme ermöglicht, bestimmte Dienste innerhalb des Perimeters zu erreichen

Das vorherige Diagramm zeigt, wie ein autorisierter Client mit einer Richtlinie für eingehenden Traffic nur auf einen bestimmten Dienst innerhalb des Perimeters zugreifen kann, ohne den Zugriff auf andere eingeschränkte Dienste zuzulassen.

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

  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 Ihrer Nutzeridentität nur eingehenden Traffic an den Compute Engine-Dienst zulässt, und wenden Sie die Richtlinie auf Ihren Perimeter an.

    cat <<EOF > ingress_spec.yaml
- ingressFrom:
    identities:
    - user:$USERNAME
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - methodSelectors:
      - method: '*'
      serviceName: compute.googleapis.com
    resources:
    - '*'
EOF

    gcloud access-context-manager perimeters update demo_perimeter \
--set-ingress-policies=ingress_spec.yaml \
--policy=$POLICY_ID

  3. Führen Sie auf dem Cloud Shell-Tab den folgenden Befehl aus, um einen Cloud Storage-Bucket innerhalb des Perimeters zu erstellen.

    gcloud storage buckets create gs://PROJECT_ID-01

    Die Ausgabe sieht in etwa so aus:

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

    Cloud Shell ist ein Client außerhalb des Perimeters. Daher verhindert der VPC Service Controls-Perimeter, dass Cloud Shell mit eingeschränkten Diensten innerhalb des Perimeters kommuniziert.

  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 an den Compute Engine-Dienst erfüllt.

Prüfen, welche Dienste von Traffic innerhalb Ihres Perimeters zugelassen werden

In den folgenden Abschnitten wird gezeigt, wie der VPC Service Controls-Perimeter Anfragen an Dienste von innerhalb des Perimeters zulässt oder ablehnt und wie Sie ausgehenden Traffic an externe Dienste durch Richtlinien für ausgehenden Traffic gezielt zulassen können.

In den folgenden Abschnitten wird sowohl Cloud Shell außerhalb des Perimeters als auch eine Compute Engine-Instanz verwendet, die Sie innerhalb des Perimeters erstellen, um den Unterschied zwischen Traffic innerhalb und außerhalb des Perimeters zu veranschaulichen. Befehle, die Sie in der SSH-Sitzung auf der Compute Engine-Instanz innerhalb des Perimeters ausführen, verwenden die Identität des angehängten Dienstkontos. Befehle, die von Cloud Shell außerhalb des Perimeters ausgeführt werden, verwenden hingegen Ihre eigene Identität. Bei Anwendung der empfohlenen Einrichtung für diese Anleitung lässt der Perimeter Anfragen zu oder lehnt sie ab, auch wenn sie ausreichende IAM-Berechtigungen haben.

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

Architekturdiagramm, das zeigt, wie die Konfiguration von „vpc-accessible-services“ es ermöglicht, Dienste von Ihren internen Netzwerkendpunkten zu erreichen

Das vorherige Diagramm zeigt, wie ein Perimeter Traffic von Netzwerkendpunkten innerhalb des Perimeters ermöglicht, eingeschränkte Dienste zu erreichen, die Sie auch als zugängliche VPC-Dienste konfiguriert haben. Dienste, die Sie nicht als über VPC zugängliche Dienste konfiguriert haben, sind über Netzwerkendpunkte innerhalb des Perimeters nicht erreichbar.

In den folgenden Schritten prüfen Sie dieses Konzept, indem Sie eine SSH-Verbindung zur Compute Engine-Instanz innerhalb des Perimeters herstellen und dann Anfragen an die Dienste senden.

  1. Erstellen Sie in Cloud Shell eine Firewallregel, die SSH-Traffic zu Ihrem VPC-Netzwerk zulässt. Dazu lässt Sie eingehenden Traffic aus dem IP-Adressbereich 35.235.240.0/20 zu, der vom IAP-Dienst für die 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 die Verbindung zur Instanz demo-vm erfolgreich hergestellt wurde. Prüfen Sie dazu, ob die Eingabeaufforderung in der Eingabeaufforderung geändert wurde, um den Hostnamen der Instanz anzuzeigen:

    username@demo-vm:~$

    Wenn der vorherige Befehl fehlschlägt, wird möglicherweise eine Fehlermeldung wie diese angezeigt:

    "[/usr/bin/ssh] exited with return code [255]"

    In diesem Fall ist der Start der Compute Engine-Instanz möglicherweise 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 für zugängliche VPC-Dienste konfiguriert ist. Probieren Sie beispielsweise einen beliebigen Befehl aus, der den Compute Engine-Dienst verwendet.

    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. Prüfen Sie in der SSH-Sitzung innerhalb Ihres Perimeters, ob die Dienste, die nicht in der Zulassungsliste für zugängliche VPC-Dienste enthalten sind, von Ihrer VM nicht zugelassen werden. Im folgenden Befehl wird beispielsweise der Resource Manager-Dienst verwendet, der nicht in der Zulassungsliste für zugängliche VPC-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 zugängliche VPC-Dienste konfiguriert sind. Serverlose Ressourcen oder Diensttraffic von außerhalb Ihres Perimeters kann 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 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 mit Google Cloud-Diensten außerhalb des Perimeters blockiert.

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

Das vorherige Diagramm zeigt, wie 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 des Perimeters den folgenden Befehl aus, um einen Storage-Bucket innerhalb des Perimeters 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 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 des Perimeters den folgenden Befehl aus, um Daten aus einem Bucket außerhalb des Perimeters zu lesen. Für diesen öffentlichen Bucket ist die Leseberechtigung für allUsers zulässig, der Perimeter lehnt jedoch Traffic von innerhalb des Perimeters an einen eingeschränkten Dienst außerhalb des Perimeters ab.

    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 kann jedoch nicht mit eingeschränkten Diensten außerhalb des Perimeters kommunizieren.

Prüfen, ob eine Richtlinie für ausgehenden Traffic eine Ausnahme für den 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 es ermöglicht, dass bestimmte Ausnahmen einen eingeschränkten Dienst außerhalb des Perimeters erreichen

Das vorherige Diagramm zeigt, wie interner Traffic mit einer bestimmten externen Ressource kommunizieren kann, wenn Sie eine begrenzte Ausnahme von der Richtlinie für ausgehenden Traffic gewähren.

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

  1. Öffnen Sie eine neue Cloud Shell-Sitzung. Klicken Sie dazu in Cloud Shell auf Neuen Tab öffnen. 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, wo die Eingabeaufforderung mit username@cloudshell beginnt.

  2. Erstellen Sie auf dem Cloud Shell-Tab 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 an einen ö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 für die VM innerhalb Ihres Perimeters zurück. Dort beginnt die Eingabeaufforderung mit username@demo-vm.

  4. Senden Sie von 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 in etwa so aus:

    "Hello world!
This is a sample file in Cloud Storage that is viewable to allUsers."

    Diese Antwort zeigt, dass Ihre Perimeter- und Ausgangsrichtlinie internen Traffic von einer bestimmten Identität zu einem bestimmten Cloud Storage-Bucket zulassen.

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

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

    Die Ausgabe sieht in etwa so aus:

    "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."

    Diese Antwort zeigt, dass Ihr Perimeter internen Traffic ablehnt, um Objekte im externen Bucket aufzulisten, was darauf hinweist, dass die Richtlinie für ausgehenden Traffic explizit angegebene Methoden eingeschränkt zulässt.

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

Optional: Richtlinie für die Nutzung von eingeschränkten Dienstressourcen konfigurieren

Möglicherweise haben Sie auch interne Anforderungen oder Compliance-Anforderungen, um nur einzeln genehmigte APIs in Ihrer Umgebung zu verwenden. In diesem Fall können Sie auch den Organisationsrichtliniendienst Eingeschränkte Dienstressourcennutzung konfigurieren. Durch Anwenden der Organisationsrichtlinie in einem Projekt schränken Sie ein, welche Dienste in diesem Projekt erstellt werden können. Die Organisationsrichtlinie hindert Dienste in diesem Projekt jedoch nicht daran, mit Diensten in anderen Projekten zu kommunizieren. Im Gegensatz 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, um Compute Engine zuzulassen und Cloud Storage in Ihrem Projekt abzulehnen, 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 Daten-Exfiltration mit dem Cloud Storage-Dienst weiterhin möglich ist. Die folgenden Schritte zeigen, wie dieses Szenario implementiert und getestet wird:

  1. Wechseln Sie zum Cloud Shell-Tab, wo die Eingabeaufforderung 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, alle anderen Dienste ablehnt und diese dann auf Ihr Projekt anwendet.

    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 für die VM innerhalb Ihres Perimeters zurück. Dort beginnt die Eingabeaufforderung mit username@demo-vm.

  4. Führen Sie in der SSH-Sitzung innerhalb des Perimeters den folgenden Befehl aus, um denselben Storage-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 Organisationsrichtliniendienst den Cloud Storage-Dienst in Ihrem Projekt unabhängig von der Konfiguration Ihres Perimeters ablehnt.

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

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

    Bei einer erfolgreichen Antwort wird der Inhalt von helloworld.txt im externen Storage-Bucket zurückgegeben. Diese Antwort zeigt, dass Ihre Perimeter- und Ausgangsrichtlinie zulässt, dass interner Traffic unter bestimmten begrenzten Bedingungen einen externen Storage-Bucket erreicht. Der Organisationsrichtliniendienst lehnt den Cloud Storage-Dienst in Ihrem Projekt jedoch unabhängig von der Konfiguration Ihres Perimeters ab. Dienste außerhalb Ihres Projekts können unabhängig vom Organisationsrichtliniendienst für die eingeschränkte Nutzung von Dienstressourcen trotzdem zur Daten-Exfiltration verwendet werden, wenn sie von Ihrem Perimeter zugelassen sind.

    Wenn Sie die Kommunikation mit Cloud Storage oder anderen Google-Diensten außerhalb des Perimeters ablehnen möchten, reicht der Organisationsrichtliniendienst Eingeschränkte Nutzung von Dienstressourcen allein nicht aus. Sie müssen in diesem Fall einen VPC Service Controls-Perimeter konfigurieren. VPC Service Controls reduziert Daten-Exfiltrationspfade und die eingeschränkte Nutzung von Dienstressourcen ist eine Compliance-Steuerung, mit der verhindert werden soll, dass nicht genehmigte Dienste in Ihrer Umgebung erstellt werden. Kombinieren Sie diese Einstellungen, um eine Reihe von Exfiltrationspfaden zu blockieren und selektiv genehmigte Dienste für die interne Verwendung in Ihrer Umgebung zuzulassen.

Bereinigen

Google Cloud-Projekt löschen:

gcloud projects delete PROJECT_ID

Obwohl der VPC Service Controls-Perimeter keine zusätzlichen Kosten verursacht, sollte er bereinigt werden, um Unordnung und ungenutzte Ressourcen in Ihrer Organisation zu vermeiden.

  1. Wählen Sie in der Projektauswahl oben in der Google Cloud Console die Organisation aus, die Sie für diese 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 in 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