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
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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
Compute Engine, Access Context Manager und Cloud DNS APIs aktivieren.
-
In the Google Cloud console, activate Cloud Shell.
Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator
Check for the roles
-
In the Google Cloud console, go to the IAM page.
Go to IAM - Select the organization.
-
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.
- For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
Grant the roles
-
In the Google Cloud console, go to the IAM page.
Zu IAM - Wählen Sie die Organisation aus.
- Klicken Sie auf Zugriff erlauben.
-
Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Dies ist in der Regel die E-Mail-Adresse eines Google-Kontos.
- Wählen Sie in der Liste Rolle auswählen eine Rolle aus.
- Wenn Sie weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.
- Klicken Sie auf Speichern.
-
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
-
In the Google Cloud console, go to the IAM page.
Go to IAM - Select the project.
-
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.
- For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
Grant the roles
-
In the Google Cloud console, go to the IAM page.
Zu IAM - Wählen Sie das Projekt aus.
- Klicken Sie auf Zugriff erlauben.
-
Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Dies ist in der Regel die E-Mail-Adresse eines Google-Kontos.
- Wählen Sie in der Liste Rolle auswählen eine Rolle aus.
- Wenn Sie weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.
- 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.
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
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
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
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
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
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.
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.
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.
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.
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.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.
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.
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
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.
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.
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
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
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.
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.
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.
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
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.
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.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.
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.
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 inaccessible-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.
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.
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.
Ö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 mitusername@cloudshell
beginnt.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 Methodegoogle.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
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
.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.
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:
- Wechseln Sie zum Cloud Shell-Tab, wo die Eingabeaufforderung mit
username@cloudshell
beginnt. 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
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
.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.
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.
- Wählen Sie in der Projektauswahl oben in der Google Cloud Console die Organisation aus, die Sie für diese Anleitung verwendet haben.
Rufen Sie in der Google Cloud Console die Seite VPC Service Controls auf.
Wählen Sie in der Liste der Perimeter den Perimeter aus, den Sie löschen möchten, und klicken Sie auf Löschen.
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
- Weitere 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.