Anleitung zum Einrichten eines Dienstperimeters mit VPC Service Controls. In dieser Anleitung werden Netzwerkeinstellungen wie Firewalls, Private Service Connect und DNS-Konfigurationen verwendet, die für die 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 erstellen.
Lernziele
- Konfigurieren Sie einen VPC Service Controls-Perimeter mit zusätzlichen Netzwerkkontrollen, um Exfiltrationspfade zu minimieren.
- Zugriff auf Dienste innerhalb des Perimeters zulassen oder ablehnen, indem Anfragen aus dem Perimeter stammen.
- Zugriff auf Dienste außerhalb des Perimeters über Anfragen aus dem Perimeter zulassen oder ablehnen.
- Verwenden Sie gleichzeitig die Organisationsrichtlinie „Resource Service Usage einschränken“ und 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.
Hinweis
Für diese Anleitung ist ein Projekt in Ihrer Organisation erforderlich. Wenn Sie noch keine Google Cloud-Organisation haben, lesen Sie die Informationen unter Organisation erstellen und verwalten.
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
Compute Engine, Access Context Manager und Cloud DNS APIs aktivieren.
-
Aktivieren Sie Cloud Shell in der Google Cloud Console.
Prüfen Sie, ob Sie die folgenden Rollen für die Organisation haben: Access Context Manager Admin, Organization Policy Administrator
Auf Rollen prüfen
-
Öffnen Sie in der Google Cloud Console die Seite IAM.
IAM aufrufen - Wählen Sie die Organisation aus.
-
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.
- 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
-
Öffnen Sie in der Google Cloud Console die Seite IAM.
IAM aufrufen - Wählen Sie die Organisation aus.
- Klicken Sie auf Zugriff erlauben.
- Geben Sie in das Feld Neue Hauptkonten Ihre E-Mail-Adresse ein.
- 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.
-
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
-
Öffnen Sie in der Google Cloud Console die Seite IAM.
IAM aufrufen - Wählen Sie das Projekt aus.
-
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.
- 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
-
Öffnen Sie in der Google Cloud Console die Seite IAM.
IAM aufrufen - Wählen Sie das Projekt aus.
- Klicken Sie auf Zugriff erlauben.
- Geben Sie in das Feld Neue Hauptkonten Ihre E-Mail-Adresse ein.
- 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
Zum Implementieren eines VPC Service Controls-Perimeters für ein VPC-Netzwerk müssen Sie Netzwerkkontrollen implementieren, die den Traffic zu externen Diensten ablehnen. In den folgenden Abschnitten werden die Netzwerkkonfigurationen beschrieben, die Sie in VPC-Netzwerken innerhalb Ihres Perimeters implementieren müssen, sowie eine Beispielkonfiguration für Perimeter.
VPC-Netzwerk vorbereiten
In diesem Abschnitt haben Sie eine private Verbindung zu Google APIs und Diensten für Ihr VPC-Netzwerk eingerichtet, um eine Reihe von Pfaden für ausgehenden Traffic zum Internet zu minimieren.
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
Dabei gilt:
- 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 vpc-sc-Bundles 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, um Abfragen für Google Cloud APIs an Ihren Private Service Connect-Endpunkt weiterzuleiten:
gcloud dns managed-zones create restricted-dns-zone \ --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \ --dns-name="googleapis.com." \ --networks=restricted-vpc \ --visibility=private gcloud dns record-sets create googleapis.com \ --rrdatas=10.0.1.1 \ --type=A \ --ttl=300 \ --zone=restricted-dns-zone gcloud dns record-sets create *.googleapis.com \ --rrdatas="googleapis.com." \ --type=CNAME \ --ttl=300 \ --zone=restricted-dns-zone
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 einer höheren 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 weitgehend ab, bevor der ausgehende Traffic zum Endpunkt von Private Service Connect selektiv zugelassen wird. Durch diese Konfiguration wird ausgehender Traffic an die Standarddomains verweigert, die normalerweise mit dem privater Google-Zugriff und den impliziten Firewallregeln standardmäßig 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 darf 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.
einen VPC Service Controls-Perimeter erstellen, 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"
Zulässige Dienste außerhalb des Perimeters prüfen
In den folgenden Abschnitten wird gezeigt, wie der VPC Service Controls-Perimeter den Zugriff auf Anfragen außerhalb des Perimeters zulässt oder ablehnt und wie Sie den eingehenden Traffic für Dienste selektiv zulassen können, indem Sie Zugriffsebenen und Richtlinien für eingehenden Traffic konfigurieren.
Wenn Sie Traffic von außerhalb des Perimeters simulieren möchten, können Sie Befehle in Cloud Shell ausführen. Cloud Shell ist eine Ressource außerhalb Ihres eigenen Projekts und Perimeters. Perimeter können Anfragen zulassen oder ablehnen, obwohl sie ausreichend Berechtigungen für Identity and Access Management haben.
In dieser Anleitung werden die Compute Engine API, die Cloud Storage API und die Resource Manager API verwendet. Dieselben Konzepte gelten jedoch auch für andere Dienste.
Prüfen, ob der Perimeter externen Traffic an eingeschränkte Dienste ablehnt
In diesem Abschnitt prüfen Sie, ob der Perimeter externen Traffic an eingeschränkte Dienste ablehnt.
Das obige Diagramm zeigt, wie einem autorisierten Client der Zugriff auf Dienste in dem von Ihnen konfigurierten Perimeter verweigert wird. Der Client hat jedoch Zugriff auf Dienste, die Sie nicht als eingeschränkt konfiguriert haben.
In den folgenden Schritten prüfen Sie dieses Konzept mit Cloud Shell. Dadurch wird versucht, eine VM in Ihrem VPC-Netzwerk zu erstellen, das aufgrund der Konfiguration des VPC Service Controls-Perimeters fehlschlägt.
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-addressDie 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, weil sich Cloud Shell außerhalb des Perimeters befindet und Compute Engine mit dem Flag
--restricted-serviceskonfiguriert ist.Führen Sie in Cloud Shell den folgenden Befehl aus, um auf den Resource Manager-Dienst zuzugreifen, der nicht im Flag
--restricted-serviceskonfiguriert 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 Resource Manager API zulässt.
Sie haben gezeigt, dass der Perimeter externen Traffic an Dienste verweigert, die in
--restricted-serviceskonfiguriert sind, und externen Traffic an Dienste zulässt, die nicht explizit in--restricted-serviceskonfiguriert sind.
In den folgenden Abschnitten werden Ausnahmemuster eingeführt, um eingeschränkte Dienste innerhalb des Perimeters zu erreichen.
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. Eine Zugriffsebene ist nützlich, wenn Sie eine Ausnahme für externen Traffic erstellen möchten, um innerhalb eines Perimeters auf alle eingeschränkten Dienste zuzugreifen und keine detaillierten Ausnahmen für jeden Dienst oder andere Attribute zu benötigen.
Im vorherigen Diagramm wird gezeigt, wie ein 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 dann zulässig, wenn Sie Compute Engine als eingeschränkt konfiguriert haben.
Erstellen Sie in Cloud Shell eine YAML-Datei, in der die Konfiguration einer Zugriffsebene beschrieben und auf Ihren Perimeter angewendet wird. 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 EOFgcloud 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 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 wird die Anfrage erfolgreich ausgeführt. Ihr Perimeter verhindert, dass externer Traffic die eingeschränkten Dienste nutzt, 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 können Sie mithilfe einer detaillierten Richtlinie für eingehenden Traffic zusätzliche Attribute zur Besucherquelle konfigurieren und den Zugriff auf einzelne Dienste oder Methoden zulassen.
Das obige Diagramm zeigt, wie ein eingehender Client mit einer Richtlinie für eingehenden Traffic nur auf einen bestimmten Dienst innerhalb des Perimeters zugreifen kann, ohne Zugriff auf andere eingeschränkte Dienste zu gewähren.
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 erlaubt.
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, damit Ihre Nutzeridentität nur an den Compute Engine-Dienst eingeht und die Richtlinie auf Ihren Perimeter anwendet.
cat <<EOF > ingress_spec.yaml - ingressFrom: identities: - user:$USERNAME sources: - accessLevel: '*' ingressTo: operations: - methodSelectors: - method: '*' serviceName: compute.googleapis.com resources: - '*' EOFgcloud 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 im Perimeter zu erstellen.
gcloud storage buckets create gs://PROJECT_ID-01
Die Ausgabe sieht in etwa so aus:
"ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."Cloud Shell ist ein Client außerhalb des Perimeters. Der VPC Service Controls-Perimeter verhindert also, 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 im Perimeter zu senden.
gcloud compute instances describe demo-vm --zone=ZONE
Eine erfolgreiche Antwort gibt Details zu
demo-vmzurück. 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 Sie die Dienste, die im Traffic innerhalb Ihres Perimeters zugelassen sind
In den folgenden Abschnitten wird gezeigt, wie der VPC Service Controls-Perimeter Anfragen an Dienste innerhalb des Perimeters zulässt oder ablehnt und wie Sie ausgehenden Traffic über externe Richtlinien extern an externe Dienste zulassen können.
In den folgenden Abschnitten wird sowohl der Cloud Shell-Bereich als auch der außerhalb des Perimeters verwendet, um den Unterschied zwischen dem Traffic innerhalb und außerhalb des Perimeters zu demonstrieren, und eine Compute Engine-Instanz, die Sie im Perimeter erstellen. Befehle, die Sie über die SSH-Sitzung auf der Compute Engine-Instanz innerhalb des Perimeters ausführen, nutzen die Identität des angehängten Dienstkontos, während Befehle aus Cloud Shell außerhalb des Perimeters Ihre eigene Identität nutzen. Wenn Sie die empfohlene Einrichtung für die Anleitung ausführen, erlaubt oder lehnt der Perimeter Anfragen ab, obwohl die Anfragen ausreichend IAM-Berechtigungen haben.
In dieser Anleitung werden die Compute Engine API, die Cloud Storage API und die Resource Manager API verwendet. Dieselben Konzepte gelten jedoch auch für andere Dienste.
Prüfen, ob der Perimeter internen Traffic zu eingeschränkten Diensten innerhalb des Perimeters zulässt
In diesem Abschnitt prüfen Sie, ob der Perimeter Traffic von Netzwerkendpunkten in Ihrem Perimeter zulässt, wenn der Dienst auch in über VPC zugänglichen Diensten konfiguriert ist.
Das obige Diagramm zeigt, wie Traffic von Netzwerkendpunkten innerhalb des Perimeters eingeschränkte Dienste erreichen kann, die Sie auch als über VPC zugängliche Dienste konfiguriert haben. Dienste, die Sie nicht als zugängliche VPC-Dienste konfiguriert haben, können nicht über Netzwerkendpunkte innerhalb des Perimeters erreicht werden.
In den folgenden Schritten prüfen Sie dieses Konzept. Stellen Sie dazu eine SSH-Verbindung zur Compute Engine-Instanz innerhalb des Perimeters her und senden Sie dann Anfragen an Dienste.
Erstellen Sie in Cloud Shell eine Firewallregel, die SSH-Traffic zu Ihrem VPC-Netzwerk zulässt. Lassen Sie dazu eingehenden Traffic aus dem IP-Adressbereich 35.235.240.0/20 zu, 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
Starten Sie eine SSH-Sitzung für diese Instanz:
gcloud compute ssh demo-vm --zone=ZONE
Prüfen Sie, ob Sie eine Verbindung zur Instanz
demo-vmhergestellt haben. Prüfen Sie dazu, ob sich die Befehlszeile geändert hat, um den Hostnamen Ihrer 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 wurde die Compute Engine-Instanz möglicherweise nicht gestartet. 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. Führen Sie beispielsweise einen beliebigen Befehl mit dem Compute Engine-Dienst aus.
gcloud compute instances describe demo-vm --zone=ZONE
Eine erfolgreiche Antwort gibt Details zu
demo-vmzurück. 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 sind. Im folgenden Befehl wird beispielsweise der Resource Manager-Dienst verwendet, der nicht in der Zulassungsliste der zugänglichen 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. Dieser serverlose Dienst fordert jedoch möglicherweise serverlose Ressourcen oder Dienst-Traffic an, die von außerhalb Ihres Perimeters stammen. Wenn Sie einen Dienst in Ihrem Projekt verhindern möchten, lesen Sie die Richtlinie zur eingeschränkten Nutzung von Dienstressourcen.
Prüfen, ob der Perimeter internen Traffic an eingeschränkte Dienste außerhalb des Perimeters ablehnt
In diesem Abschnitt prüfen Sie, ob der Perimeter die Kommunikation von Diensten innerhalb des Perimeters zu Google Cloud-Diensten außerhalb des Perimeters blockiert.
Das obige Diagramm zeigt, wie der interne 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 im Perimeter 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 in Ihrem Perimeter zu erstellen. Dieser Befehl funktioniert, da der Cloud Storage-Dienst sowohl in
restricted-servicesals auch inaccessible-serviceskonfiguriert 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 Ihres Perimeters den folgenden Befehl aus, um aus einem Bucket zu lesen, der sich außerhalb des Perimeters befindet. Dieser öffentliche Bucket gewährt Lesezugriff auf
allUsers, der Perimeter verweigert jedoch den Traffic aus Ihrem Perimeter zu einem eingeschränkten Dienst außerhalb des Perimeters.gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
Die Ausgabe sieht in etwa so aus:
"ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited by organization's policy."Diese Antwort zeigt, dass Sie eingeschränkte Dienste im Perimeter verwenden können, aber eine Ressource im Perimeter kann nicht mit eingeschränkten Diensten außerhalb des Perimeters kommunizieren.
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.
Das obige Diagramm zeigt, wie der interne Traffic mit einer bestimmten externen Ressource kommunizieren kann, wenn Sie mit der Richtlinie für ausgehenden Traffic eine enge Ausnahme gewähren.
In den folgenden Schritten prüfen Sie dieses Konzept, indem Sie eine Richtlinie für ausgehenden Traffic erstellen und dann auf einen öffentlichen Cloud Storage-Bucket außerhalb des Perimeters zugreifen, der von der Richtlinie für ausgehenden Traffic zugelassen ist.
Öffnen Sie eine neue Cloud Shell-Sitzung. Klicken Sie dazu auf Neuen Tab öffnen in Cloud Shell. 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, in dem die Befehlszeile mit
username@cloudshellbeginnt.Erstellen Sie auf dem Cloud Shell-Tab eine ausgehende Richtlinie, die ausgehenden Traffic von der angehängten Dienstkontoidentität von
demo-vmmit der Methodegoogle.storage.objects.getan 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 EOFgcloud 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 in Ihrem Perimeter zurück, wobei die Befehlszeile mit
username@demo-vmbeginnt.Senden Sie über die SSH-Sitzung innerhalb Ihres Perimeters eine weitere Anfrage an den Cloud Storage-Bucket und prüfen Sie, ob er 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 ausgehenden Richtlinien internen Traffic von einer bestimmten Identität zu einem bestimmten Cloud Storage-Bucket zulassen.
Über die SSH-Sitzung innerhalb Ihres Perimeters können Sie 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.listerforderlich, die von Ihrem Perimeter abgelehnt wird.gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*
Die Ausgabe sieht in etwa so aus:
"ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."Diese Antwort zeigt, dass Ihr Perimeter internen Traffic von der Auflistung von Objekten im externen Bucket ablehnt, was darauf hinweist, dass die Richtlinie für ausgehenden Traffic explizit festgelegte Methoden zulässt.
Weitere Informationen zu gängigen Mustern für die Freigabe von Daten außerhalb des Dienstperimeters finden Sie unter Sicherer Datenaustausch mit eingehenden und ausgehenden Regeln.
Optional: Richtlinie für die Nutzung von eingeschränkten Dienstressourcen konfigurieren
Unter Umständen müssen auch interne Anforderungen oder Complianceanforderungen vorhanden sein, damit nur einzelne APIs in Ihrer Umgebung verwendet werden können. In diesem Fall könnten Sie auch den Organisationsrichtliniendienst Ressourcen mit eingeschränktem Dienst konfigurieren. Durch Anwenden der Organisationsrichtlinie in einem Projekt beschränken Sie, welche Dienste in diesem Projekt erstellt werden können. Die Organisationsrichtlinie verhindert jedoch nicht, dass Dienste in diesem Projekt mit Diensten in anderen Projekten kommunizieren. Im Vergleich dazu können Sie mit VPC Service Controls einen Perimeter definieren, um die Kommunikation mit Diensten außerhalb des Perimeters zu verhindern.
Wenn Sie beispielsweise eine Organisationsrichtlinie definieren, 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 Exfiltration mit dem Cloud Storage-Dienst möglich ist. Die folgenden Schritte zeigen, wie Sie dieses Szenario implementieren und testen:
- Wechseln Sie zum Tab „Cloud Shell“, in dem die Eingabeaufforderung mit
username@cloudshellbeginnt. Erstellen Sie auf dem Cloud Shell-Tab eine YAML-Datei, in der der Organisationsrichtliniendienst beschrieben wird, die nur die Nutzung des Compute Engine-Dienstes zulässt und alle anderen Dienste ablehnt. Wenden Sie ihn dann auf Ihr Projekt an.
cat <<EOF > allowed_services_policy.yaml constraint: constraints/gcp.restrictServiceUsage listPolicy: allowedValues: - compute.googleapis.com inheritFromParent: true EOFgcloud 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 in Ihrem Perimeter zurück, wobei die Befehlszeile mit
username@demo-vmbeginnt.Führen Sie in der SSH-Sitzung innerhalb Ihres 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 ablehnt, unabhängig von der Konfiguration des Perimeters.
Führen Sie in der SSH-Sitzung innerhalb des Perimeters den folgenden Befehl aus, um sich einen Storage-Bucket außerhalb des Perimeters anzusehen, der von Ihrer ausgehenden Richtlinie zulässig ist.
gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
Die Ausgabe sieht in etwa so aus:
"Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."Eine erfolgreiche Antwort gibt den Inhalt von
helloworld.txtim externen Storage-Bucket zurück. Diese Antwort zeigt, dass die Richtlinie für ausgehenden und ausgehenden Traffic den internen Traffic unter bestimmten begrenzten Bedingungen zulässt, aber der Organisationsrichtliniendienst den Cloud Storage-Dienst in Ihrem Projekt ablehnt, unabhängig von der Konfiguration des Perimeters. Dienste außerhalb Ihres Projekts können weiterhin für die Exfiltration verwendet werden, wenn sie vom Perimeter zugelassen sind – unabhängig vom Ressourcendienst für Ressourcennutzung für Dienste mit eingeschränktem Dienst.Wenn Sie die Kommunikation mit Cloud Storage oder anderen Google-Diensten außerhalb des Perimeters verweigern möchten, ist der Organisationsrichtliniendienst der eingeschränkten Dienstnutzung nicht ausreichend. Sie müssen einen VPC Service Controls-Perimeter konfigurieren. VPC Service Controls reduziert die Daten-Exfiltration. Außerdem können Sie mit der eingeschränkten Nutzung von Dienstressourcen festlegen, dass in Ihrer Umgebung nicht genehmigte Dienste erstellt werden. Verwenden Sie diese Kontrollen zusammen, um eine Reihe von Exfiltrationspfaden zu blockieren und genehmigte Dienste für den internen Gebrauch in Ihrer Umgebung selektiv zuzulassen.
Bereinigen
Google Cloud-Projekt löschen:
gcloud projects delete PROJECT_ID
Obwohl für den VPC Service Controls-Perimeter keine zusätzlichen Kosten anfallen, sollte er bereinigt werden, um unübersichtliche und nicht verwendete Ressourcen in Ihrer Organisation zu vermeiden.
- Wählen Sie in der Projektauswahl oben in der Google Cloud Console die Organisation aus, die Sie in dieser 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, finden Sie hier.
- Über VPC zugängliche Dienste aktivieren.
- Weitere Informationen zur Konfiguration von Private Service Connect für den Zugriff auf Google APIs.
Weitere Architekturen, Diagramme, Anleitungen und Best Practices finden Sie im Cloud-Architekturzentrum.