Auf dieser Seite werden die Regeln für ein- und ausgehenden Traffic für VPC Service Controls erläutert. VPC Service Controls ermöglicht mithilfe von Regeln für ein- und ausgehenden Traffic den Zugriff auf die Ressourcen und Clients, die durch Dienstperimeter geschützt sind.
Die Eingangsregeln für eingehenden und ausgehenden Traffic geben die Richtung des zulässigen Zugriffs auf und von verschiedenen Identitäten und Ressourcen an. Regeln für ein- und ausgehenden Traffic können Anwendungsfälle ersetzen und vereinfachen, für die zuvor eine oder mehrere Perimeter-Bridges erforderlich waren.
Informationen zum Anwenden von Richtlinien für ein- und ausgehenden Traffic finden Sie unter Richtlinien für ein- und ausgehenden Traffic konfigurieren.
Sie können Identitätsgruppen und Drittanbieteridentitäten sowie IAM-Rollen (Vorabversion) in Ingress- und Egress-Regeln konfigurieren.
Eine Liste sicherer Anwendungsfälle und Beispiele für den Datenaustausch finden Sie unter Sicherer Datenaustausch mit Regeln für ein- und ausgehenden Traffic.
Eine Liste der Anwendungsfälle und Beispiele für den kontextsensitiven Zugriff finden Sie unter Kontextsensitiver Zugriff mit Regeln für eingehenden Traffic.
Vorteile von Regeln für ein- und ausgehenden Traffic
- Mit Regeln für ein- und ausgehenden Traffic können Sie Daten mithilfe von Google Cloud Dienst-APIs privat und effizient innerhalb von Organisationen austauschen.
- Mit Regeln für ein- und ausgehenden Traffic können Sie den Zugriff auf Google Cloud-Ressourcen in einem Perimeter basierend auf dem Kontext der API-Anfrage gewähren:
- Sie können Identitätstypen oder Identitäten beschränken, die im Rahmen eines Quellnetzwerks, einer IP-Adresse oder eines Geräts verwendet werden können.
- Sie können Google Cloud APIs und -Methoden beschränken, auf die mit dem Quellnetzwerk, der IP-Adresse, dem Gerät und dem Identitätstyp zugegriffen werden kann.
- Sie können den Dienst, die Methoden, dieGoogle Cloud -Projekte, die VPC-Netzwerke und die Identitäten beschränken, mit denen der Datenaustausch ausgeführt wird, um das Risiko der Daten-Exfiltration zu minimieren.
- Sie können schreibgeschützten Zugriff auf externe Datasets und Images gewähren, die nicht von Ihnen verwaltet werden.
- Sie können dafür sorgen, dass Clients in weniger privilegierten Segmenten keinen Zugriff aufGoogle Cloud -Ressourcen in mehr privilegierten Segmenten haben, während der Zugang in die andere Richtung ermöglicht wird.
- Sie können die Konfigurationen vereinfachen, für die zuvor eine oder mehrere Perimeter-Bridges erforderlich waren.
Definition von ein- und ausgehendem Traffic
Definitionen für ein- und ausgehenden Traffic sind unabhängig von dem Vorgang, der für die Ressource aufgerufen wird. Daher beziehen sich die Definitionen auf die Richtung der Anfrage und nicht auf die Richtung der Datenbewegung.
Eingehender Traffic: Bezieht sich auf den Zugriff von einem API-Client von außerhalb des Dienstperimeters auf Ressourcen innerhalb eines Dienstperimeters. Beispiel:
- Ein Cloud Storage-Client außerhalb eines Dienstperimeters, der Lese-, Schreib- oder Kopiervorgänge von Cloud Storage für eine Cloud Storage-Ressource innerhalb des Perimeters aufruft
Ausgehender Traffic: Bezieht sich auf alle Zugriffe, bei denen ein API-Client oder Ressourcen innerhalb des Dienstperimeters und Ressourcen außerhalb eines Dienstperimeters genutzt werden. Beispiele:
- Ein Compute Engine-Client innerhalb eines Dienstperimeters ruft einen
create
-Vorgang von Compute Engine auf, wobei sich die Image-Ressource außerhalb des Perimeters befindet. - Ein Cloud Storage-Client, innerhalb oder außerhalb des Perimeters, der einen
copy
-Befehl aufruft, wobei sich ein Bucket innerhalb des Perimeters und der andere Bucket außerhalb des Perimeters befindet.
- Ein Compute Engine-Client innerhalb eines Dienstperimeters ruft einen
Richtlinienmodell
Eine Regel für ein- und ausgehenden Traffic besteht aus from
und to
-Blöcken, in denen:
from
auf die Attribute des API-Clients verweist.to
auf die Attribute von Google Cloud Diensten und -Ressourcen verweist.
Einem Dienstperimeter können mehrere Regeln für ein- und ausgehenden Traffic zugeordnet werden. EinGoogle Cloud -Dienstaufruf wird basierend auf den folgenden semantischen Methoden zugelassen oder abgelehnt:
- Eine Anfrage von einem Client außerhalb des Perimeters an eine Google Cloud Ressource innerhalb des Perimeters ist zulässig, wenn die Bedingungen der erforderlichen Eingangsregel erfüllt sind.
- Eine Anfrage von einem Client innerhalb des Perimeters an eine Google Cloud Ressource außerhalb des Perimeters ist zulässig, wenn die Bedingungen der erforderlichen Ausgangsregel erfüllt sind.
- Ein API-Aufruf, der eine Google Cloud Ressource innerhalb des Perimeters und eine Google Cloud Ressource außerhalb des Perimeters umfasst, ist zulässig, wenn eine Regel für eingehenden Traffic vorhanden ist, die der Client erfüllt (wenn sich der Client nicht innerhalb des Perimeters befindet) und eine Regel für ausgehenden Traffic, die die externe Ressource erfüllt.
Beispiele für API-Anfragen, die durch Regeln für eingehenden Traffic zugelassen sind
- Ein Cloud Storage-Client außerhalb des Perimeters, der Objekte aus einem Cloud Storage-Bucket innerhalb des Perimeters auf die lokale Maschine herunterlädt (z. B. mit dem Befehl
gcloud storage cp
). - Ein BigQuery-Client außerhalb des Perimeters der mithilfe eines BigQuery-Jobs in einem Projekt innerhalb des Perimeters, ein BigQuery-Dataset innerhalb des Perimeters abfrägt (z. B. mit dem Befehl
bq query
). - Eine Compute Engine-VM in einem VPC-Netzwerk außerhalb des Perimeters schreibt in einen Cloud Storage-Bucket innerhalb des Perimeters.
Beispiele für API-Anfragen, die durch Regeln für ausgehenden Traffic zugelassen werden
- Ein Cloud Storage-Client innerhalb des Perimeters, der Objekte zwischen einem Cloud Storage-Bucket außerhalb des Perimeters und einem Bucket innerhalb des Perimeters kopiert (z. B. mit dem Befehl
gcloud storage cp
).
- Ein BigQuery-Client innerhalb des Perimeters der mithilfe eines BigQuery-Jobs in einem Projekt außerhalb des Perimeters, ein BigQuery-Dataset innerhalb des Perimeters abfrägt (z. B. mit dem Befehl
bq query
).
Beispiele für API-Anfragen, die durch eine Kombination aus Regeln für eingehenden und ausgehenden Traffic zugelassen werden
- Ein Cloud Storage-Client außerhalb des Perimeters, der Objekte zwischen einem Cloud Storage-Bucket außerhalb des Perimeters und einem Bucket innerhalb des Perimeters kopiert (z. B. mit dem Befehl
gcloud storage cp
). - Ein BigQuery-Client außerhalb des Perimeters der mithilfe eines BigQuery-Jobs in einem Projekt außerhalb des Perimeters, ein BigQuery-Dataset innerhalb des Perimeters abfrägt (z. B. mit dem Befehl
bq query
). - Ein Compute Engine-Client außerhalb des Perimeters erstellt ein Compute Engine-Laufwerk außerhalb des Perimeters mit einem Cloud KMS-Schlüssel innerhalb des Perimeters.
In den BigQuery- und Compute Engine-Beispielen reicht eine Regel für eingehenden Traffic nicht aus, da sich der BigQuery-Job oder die Compute Engine-Festplatte außerhalb des Perimeters befindet. Eine Regel für ausgehenden Traffic ist erforderlich, um eine API-Anfrage zuzulassen, die eine Google Cloud -Ressource innerhalb des Perimeters (das BigQuery-Dataset oder der Cloud KMS-Schlüssel) und eine Ressource außerhalb des Perimeters (der BigQuery-Job oder die Compute Engine-Festplatte) umfasst.
API-Anfragen mit mehreren Dienstperimetern
Wenn die aufgerufenen Ressourcen und/oder der API-Client zu verschiedenen Dienstperimetern gehören, müssen die Richtlinien aller betroffenen Perimeter die API-Anfrage zulassen. Beispiel: Ein Cloud Storage-Client und ein Bucket a
in einem Dienstperimeter A
und ein Bucket b
innerhalb eines Dienstperimeters B
. In diesem Beispiel kopiert der Cloud Storage-Client Objekte aus dem Bucket a
in den Bucket b
und aus dem Bucket b
in den Bucket a
. Dazu sind die folgenden Regeln für ein- und ausgehenden Traffic erforderlich:
- Eine Regel für ausgehenden Traffic im Perimeter
A
, um Zugriff auf den Cloud Storage-Bucketb
zu ermöglichen - Eine Regel für ausgehenden Traffic im Perimeter
B
, um Zugriff auf den Cloud Storage-Bucketa
zu ermöglichen - Eine Regel für eingehenden Traffic im Perimeter
B
, um Zugriff für den Cloud Storage-Client zu ermöglichen, der sich außerhalb des PerimetersB
befindet.
Referenz zu Regeln für eingehenden Traffic
Regeln für eingehenden Traffic können mit der Google Cloud Console, einer JSON-Datei oder einer YAML-Datei konfiguriert werden. Im folgenden Beispiel wird das .yaml
-Format verwendet:
- ingressFrom: identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT *OR* identities: - PRINCIPAL_IDENTIFIER sources: - resource: RESOURCE *OR* - accessLevel: ACCESS_LEVEL ingressTo: operations: - serviceName: SERVICE methodSelectors: - method: METHOD *OR* - permission: PERMISSION *OR* roles: - ROLE_NAME resources: - projects/PROJECT title: TITLE
- ingressFrom:
– (Erforderlich) Startet denfrom
-Block, in dem zulässige Quellen und Identitäten außerhalb des Perimeters aufgeführt werden.identityType:
– (Dieses oder dasidentities
-Attribut muss verwendet werden.) Dieses Attribut definiert die Arten von Identitäten, die aus den angegebenensources
verwendet werden können (Netzwerkursprung). Zulässige Werte:ANY_IDENTITY
,ANY_USER_ACCOUNT
,ANY_SERVICE_ACCOUNT
.ANY_IDENTITY
erlaubt Anfragen von allen Identitäten, einschließlich nicht authentifizierter Anfragen.ANY_USER_ACCOUNT
erlaubt alle menschlichen Nutzer undANY_SERVICE_ACCOUNT
alle Dienstkonten. Bei beiden sind jedoch keine nicht authentifizierten Anfragen zulässig.ANY_USER_ACCOUNT
ANY_SERVICE_ACCOUNT
Dieses Attribut schränkt die Identitäten nicht nach Organisation ein. Mit
ANY_SERVICE_ACCOUNT
wird beispielsweise ein Dienstkonto aus einer beliebigen Organisation zugelassen.identities:
– (Dieses oder dasidentityType
-Attribut muss verwendet werden.) Mit diesem Attribut wird eine Liste von Dienstkonten, Nutzerkonten, Google-Gruppen oder Drittanbieteridentitäten erstellt, die auf die angegebenen Ressourcen außerhalb des Perimeters zugreifen können.PRINCIPAL_IDENTIFIER
: Geben Sie ein Nutzerkonto, ein Dienstkonto, eine Google-Gruppe oder eine Drittanbieteridentität an, für die Sie Zugriff auf Ressourcen im Perimeter gewähren möchten. Verwenden Sie das Format, das in IAMv1
-API-Hauptkonto-IDs angegeben ist. Verwenden Sie beispielsweise das Formatgroup:GROUP_NAME@googlegroups.com
, um eine Google-Gruppe anzugeben.VPC Service Controls unterstützt nur die
v1
-Identitäten, die mit den Präfixenuser
,serviceAccount
,group
,principal
undprincipalSet
in den IAM-v1
-API-Hauptkonto-IDs beginnen.sources:
: (Erforderlich) Dieses Attribut bezieht sich auf eine Liste mit Netzwerkursprüngen. Jeder Wert in der Liste ist entweder eine Zugriffsebene oder ein Google Cloud -Projekt. Wenn Sie das AttributaccessLevel
auf*
setzen, erlaubt die Richtlinie für eingehenden Traffic den Zugriff von jedem Netzwerkursprung. Wenn Sie dieses Attribut auf ein Google Cloud -Projekt festlegen, erlaubt die Richtlinie für eingehenden Traffic den Zugriff von einem VPC-Netzwerk, das zum Projekt gehört.Dieser Wert wird möglicherweise entfernt, wenn das zugehörige Projekt endgültig gelöscht wird. Das Entfernen dieses Werts führt jedoch nicht zu einem Fehler. Prüfen Sie bei der Fehlerbehebung immer, ob dieser Wert vorhanden ist.
- resource:
– (Verwenden Sie dieses oder das AttributaccessLevel
.) Gibt ein Projekt oder VPC-Netzwerk außerhalb des Perimeters an, auf das Sie Zugriff gewähren möchten. Geben Sie ein Projekt im folgenden Format an:projects/PROJECT_NUMBER
. Verwenden Sie das folgende Format, um ein VPC-Netzwerk anzugeben://compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME
.- accessLevel:
- (Es muss dieses oder das Attributresource
verwendet werden.) Gibt die Zugriffsebene von außerhalb des Perimeters an, auf den der Zugriff gewährt wird. Wenn Sie das AttributaccessLevel
auf*
setzen, erlaubt die Richtlinie für eingehenden Traffic den Zugriff von jedem Netzwerkursprung.ingressTo:
: (Erforderlich) Startet dento
-Block, mit dem zugelassene Dienstvorgänge für angegebene Google Cloud -Ressourcen innerhalb des Perimeters aufgeführt werden.operations:
: (Dieses oder dasroles
-Attribut muss verwendet werden.) Markiert den Anfang der Liste der zugänglichen Dienste und Aktionen/Methoden, auf die ein Client zugreifen darf, der diefrom
-Block-Bedingungen erfüllt.- serviceName:
: (Erforderlich) Dieses Feld kann ein gültiger Dienstname sein oder auf*
gesetzt sein, um den Zugriff auf alle Dienste zu ermöglichen. Beispiel:bigquery.googleapis.com
ist ein gültigerserviceName
. Eine Liste der verfügbaren Dienste finden Sie unter Unterstützte Produkte.methodSelectors:
: (Erforderlich, wennserviceName
nicht*
ist) Der Anfang einer Liste von Methoden, auf die ein Client zugreifen kann, der diefrom
-Block-Bedingungen erfüllt. Eine Liste der Methoden und Berechtigungen für Dienste finden Sie unter Unterstützte Einschränkungen für Dienstmethoden.Eine Liste der Dienstmethoden, die nicht von VPC Service Controls gesteuert werden können, finden Sie unter Ausnahmen für Dienstmethoden.
- method:
- (Dieses oder das Attributpermission
muss verwendet werden.) Dieses Feld kann eine gültige Dienstmethode sein oder auf*
gesetzt werden, um Zugriff auf alle Methoden des angegebenen Diensts zu gewähren.- permission:
- (Dieses oder das Attributmethod
muss verwendet werden.) Dieses Feld muss eine gültige Dienstberechtigung enthalten. Der Zugriff auf die Ressourcen innerhalb des Perimeters wird für die Vorgänge zugelassen, die die Berechtigung benötigen.Wenn für eine Anfrage an eine Ressource mehrere Berechtigungen erforderlich sind, müssen Sie alle erforderlichen Berechtigungen im selben Vorgang angeben, damit die Ingress-Regel funktioniert. Wenn für eine Anfrage an eine BigQuery-Ressource beispielsweise die Berechtigungen
bigquery.jobs.create
undbigquery.tables.create
erforderlich sind, müssen Sie beide Berechtigungen für denselben Vorgang angeben. Wenn Sie die Berechtigungen für dieselbe Ressource mehrmals über dieGoogle Cloud -Konsole angeben, werden die Berechtigungen nicht im selben Vorgang erstellt. Um dieses Problem zu vermeiden, geben Sie alle Berechtigungen für die Ressource gleichzeitig an.roles:
: (Dieses oder das Attributoperations
muss verwendet werden.) Dieses Attribut verweist auf eine Liste von IAM-Rollen, die den Umfang des Zugriffs für die in der Regel angegebenen Dienste definieren.ROLE_NAME
: Geben Sie eine einzelne Rolle oder eine Kombination von Rollen an, die alle Berechtigungen enthalten, die für den Zugriff auf die Dienste erforderlich sind. Wenn Sie eine Rolle angeben möchten, verwenden Sie die in Rollenkomponenten genannten Formate für Rollennamen, mit Ausnahme des folgenden Formats:projects/PROJECT_ID/roles/IDENTIFIER
.Informationen zu den unterstützten Diensten und Rollen finden Sie unter Unterstützte Produkte.
resources:
: (Erforderlich.) Dieses Attribut gibt die Liste derGoogle Cloud -Ressourcen im Dienstperimeter an, auf die der Client außerhalb des Perimeters zugreifen kann. Dieses Feld kann auf*
gesetzt werden, um eingehenden Zugriff auf alle Google Cloud -Ressourcen innerhalb des Perimeters zu ermöglichen.title:
: (Optional) Dieses Attribut gibt den Titel der Regel für eingehenden Traffic an. Der Titel muss innerhalb des Perimeters eindeutig sein und darf 100 Zeichen nicht überschreiten. Die kombinierte Länge aller Regelüberschriften in der Zugriffsrichtlinie darf 240.000 Zeichen nicht überschreiten.
Um eine funktionsfähige Regel für eingehenden Traffic zu erstellen, müssen Sie die folgenden Attribute angeben:
- Attribut
sources
. Sie müssen einaccessLevel
oder eineresource
(Google Cloud -Projekt oder VPC-Netzwerk) angeben oder das AttributaccessLevel
auf*
setzen.
- Attribut
identityType
oderidentities
resources
AttributserviceName
Attribut
Wenn Sie die Konfiguration Ihrer Richtliniendatei für eingehenden Traffic abgeschlossen haben, finden Sie unter Richtlinien für ein- und ausgehenden Traffic aktualisieren Anweisungen zum Anwenden Ihrer Richtliniendatei für eingehenden Traffic auf Ihren Dienstbereich.
Wenn Sie mehrere Regeln für eingehenden Traffic in einem Dienstperimeter konfigurieren, lässt VPC Service Controls eine Anfrage zu, wenn sie die Bedingungen einer der Regeln für eingehenden Traffic erfüllt.
Referenz zu Regeln für ausgehenden Traffic
Regeln für ausgehenden Traffic können mit der Google Cloud Console, einer JSON-Datei oder einer YAML-Datei konfiguriert werden. Im folgenden Beispiel wird das .yaml
-Format verwendet:
- egressTo: operations: - serviceName: SERVICE_NAME methodSelectors: - method: METHOD *OR* - permission: PERMISSION *OR* roles: - ROLE_NAME resources: - projects/PROJECT *OR* externalResources: - EXTERNAL_RESOURCE_PATH egressFrom: identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT *OR* identities: - PRINCIPAL_IDENTIFIER sources: - resource: RESOURCE *OR* - accessLevel: ACCESS_LEVEL sourceRestriction: RESTRICTION_STATUS title: TITLE
- egressTo:
: (Erforderlich) Startet dento
-Block, mit dem zugelassene Dienstvorgänge für Google Cloud -Ressourcen in angegebenen Projekten außerhalb des Perimeters aufgeführt werden.operations:
: (Dieses oder dasroles
-Attribut muss verwendet werden.) Markiert den Anfang der Liste der zugänglichen Dienste und Aktionen/Methoden, auf die ein Client zugreifen darf, der diefrom
-Block-Bedingungen erfüllt.- serviceName:
: (Erforderlich) Dieses Feld kann ein gültiger Dienstname sein oder auf*
gesetzt sein, um den Zugriff auf alle Dienste zu ermöglichen. Eine Liste der verfügbaren Dienste finden Sie unter Unterstützte Produkte.methodSelectors:
: (Erforderlich, wennserviceName
nicht*
ist) Der Anfang einer Liste von Methoden, auf die ein Client zugreifen kann, der diefrom
-Block-Bedingungen erfüllt. Eine Liste der Methoden und Berechtigungen für Dienste finden Sie unter Unterstützte Einschränkungen für Dienstmethoden.Eine Liste der Dienstmethoden, die nicht von VPC Service Controls gesteuert werden können, finden Sie unter Ausnahmen für Dienstmethoden.
- method:
- (Es muss dieses oder das Attributpermission
verwendet werden.) Dieses Feld kann eine gültige Dienstmethode sein oder auf*
gesetzt werden, um den Zugriff auf alle Methoden des angegebenen Dienstes zu ermöglichen.- permission:
- (Es muss dieses oder das Attributmethod
verwendet werden.) Dieses Feld muss eine gültige Dienstberechtigung sein. Der Zugriff auf die angegebenen Ressourcen außerhalb des Perimeters wird für Vorgänge zugelassen, für die diese Berechtigung erforderlich ist.Wenn für eine Anfrage an eine Ressource mehrere Berechtigungen erforderlich sind, müssen Sie alle erforderlichen Berechtigungen für denselben Vorgang angeben, damit die Egress-Regel funktioniert. Wenn für eine Anfrage an eine BigQuery-Ressource beispielsweise die Berechtigungen
bigquery.jobs.create
undbigquery.tables.create
erforderlich sind, müssen Sie beide Berechtigungen für denselben Vorgang angeben. Wenn Sie die Berechtigungen für dieselbe Ressource mehrmals über dieGoogle Cloud -Konsole angeben, werden die Berechtigungen nicht im selben Vorgang erstellt. Um dieses Problem zu vermeiden, geben Sie alle Berechtigungen für die Ressource gleichzeitig an.roles:
: (Dieses oder das Attributoperations
muss verwendet werden.) Dieses Attribut verweist auf eine Liste von IAM-Rollen, die den Umfang des Zugriffs für die in der Regel angegebenen Dienste definieren.ROLE_NAME
: Geben Sie eine einzelne Rolle oder eine Kombination von Rollen an, die alle Berechtigungen enthalten, die für den Zugriff auf die Dienste erforderlich sind. Wenn Sie eine Rolle angeben möchten, verwenden Sie die in Rollenkomponenten genannten Formate für Rollennamen, mit Ausnahme des folgenden Formats:projects/PROJECT_ID/roles/IDENTIFIER
.Informationen zu den unterstützten Diensten und Rollen finden Sie unter Unterstützte Produkte.
resources:
: Dieses Attribut ist eine Liste von Google Cloud-Ressourcen, die von ihren Projekten angegeben werden, auf die Clients innerhalb eines Perimeters zugreifen können. Sie können dieses Feld auf*
setzen, um ausgehenden Zugriff auf jedeGoogle Cloud -Ressource zuzulassen.externalResources:
: Dieses Attribut wird nur verwendet, um BigQuery Omni-Ressourcen anzugeben. Dieses Attribut ist eine Liste externer Ressourcen, die von BigQuery Omni unterstützt werden und auf die Clients innerhalb eines Perimeters zugreifen können. Sie können nur Amazon S3- oder Azure Blob Storage-Ressourcen angeben. Für Amazon S3 ist das unterstützte Formats3://BUCKET_NAME
. Für Azure Storage ist das unterstützte Formatazure://myaccount.blob.core.windows.net/CONTAINER_NAME
.egressFrom:
: (Erforderlich) Startet denfrom
-Block, in dem zulässige Quellen und Identitäten innerhalb des Perimeters aufgeführt werden.identityType:
- (Es muss dieses oder das Attributidentities
verwendet werden.) Dieses Attribut definiert die Identitätstypen, die für den Zugriff auf die angegebenen Ressourcen außerhalb des Perimeters verwendet werden können. Zulässige Werte:ANY_IDENTITY
,ANY_USER_ACCOUNT
,ANY_SERVICE_ACCOUNT
.ANY_IDENTITY
erlaubt Anfragen von allen Identitäten, einschließlich nicht authentifizierter Anfragen.ANY_USER_ACCOUNT
erlaubt alle menschlichen Nutzer undANY_SERVICE_ACCOUNT
alle Dienstkonten. Bei beiden sind jedoch keine nicht authentifizierten Anfragen zulässig.ANY_USER_ACCOUNT
ANY_SERVICE_ACCOUNT
Dieses Attribut schränkt die Identitäten nicht nach Organisation ein. Mit
ANY_SERVICE_ACCOUNT
wird beispielsweise ein Dienstkonto aus einer beliebigen Organisation zugelassen.identities:
- (Es muss dieses oder das AttributidentityType
verwendet werden.) Dieses Attribut startet eine Liste von Dienstkonten, Nutzerkonten, Google-Gruppen oder Drittanbieteridentitäten, die auf die angegebenen Ressourcen außerhalb des Perimeters zugreifen können.PRINCIPAL_IDENTIFIER
: Geben Sie ein Nutzerkonto, ein Dienstkonto, eine Google-Gruppe oder eine Drittanbieteridentität an, die außerhalb des Perimeters auf die angegebenen Ressourcen zugreifen kann. Verwenden Sie das Format, das in IAMv1
-API-Hauptkonto-IDs angegeben ist. Verwenden Sie beispielsweise das Formatgroup:GROUP_NAME@googlegroups.com
, um eine Google-Gruppe anzugeben.VPC Service Controls unterstützt nur die
v1
-Identitäten, die mit den Präfixenuser
,serviceAccount
,group
,principal
undprincipalSet
in den IAM-v1
-API-Hauptkonto-IDs beginnen.sources:
: Dieses Attribut gibt eine Liste mit Netzwerkursprüngen an. Der Attributwert kann eine Liste von Projekten oder Zugriffsebenen sein. Wenn Sie Zugriffsbeschränkungen basierend auf dem angegebenensources
erzwingen möchten, legen Sie das AttributsourceRestriction
aufSOURCE_RESTRICTION_ENABLED
fest.VPC Service Controls wertet die Attribute
accessLevel
undresource
des Attributssources
als ODER-Bedingung aus.- resource:
: (Verwenden Sie dieses oder das AttributaccessLevel
.) Geben Sie eine oder mehrereGoogle Cloud -Ressourcen aus dem Dienstperimeter an, denen Sie den Zugriff auf Daten außerhalb des Perimeters erlauben möchten. Dieses Attribut unterstützt nur Projekte. Geben Sie ein Projekt im folgenden Format an:projects/PROJECT_NUMBER
.Sie können
*
in diesem Attribut nicht verwenden, um alle Google Cloud -Ressourcen zuzulassen.- accessLevel:
: (Verwenden Sie dieses oder das Attributresource
.) Geben Sie eine oder mehrere Zugriffsebenen an, die es Ressourcen innerhalb des Perimeters ermöglichen, auf Ressourcen außerhalb des Perimeters zuzugreifen. Achten Sie darauf, dass diese Zugriffsebenen aus derselben Zugriffsrichtlinie wie der Perimeter stammen. Wenn Sie das AttributaccessLevel
auf*
setzen, erlaubt die Richtlinie für ausgehenden Traffic den Zugriff von jedem Netzwerkursprung.sourceRestriction:
: (Erforderlich, wenn Sie das Attributsources
verwenden) Mit diesem Attribut können Sie Zugriffsbeschränkungen basierend auf dem angegebenensources
erzwingen. Um diese Zugriffsbeschränkungen zu erzwingen, setzen Sie das AttributsourceRestriction
aufSOURCE_RESTRICTION_ENABLED
.Wenn Sie diese Zugriffsbeschränkungen deaktivieren möchten, legen Sie das Attribut
sourceRestriction
aufSOURCE_RESTRICTION_DISABLED
fest.Wenn Sie keinen Wert für das Attribut
sourceRestriction
festlegen, ignoriert VPC Service Controls das Attributsources
und erzwingt keine Zugriffsbeschränkungen.title:
: (Optional) Dieses Attribut gibt den Titel der Regel für ausgehenden Traffic an. Der Titel muss innerhalb des Perimeters eindeutig sein und darf 100 Zeichen nicht überschreiten. Die kombinierte Länge aller Regelüberschriften in der Zugriffsrichtlinie darf 240.000 Zeichen nicht überschreiten.
Wenn Sie die Konfiguration Ihrer Richtliniendatei für ausgehenden Traffic abgeschlossen haben, finden Sie unter Richtlinien für ein- und ausgehenden Traffic aktualisieren Anweisungen zum Anwenden Ihrer Richtliniendatei für ausgehenden Traffic auf Ihren Dienstbereich.
Wenn Sie mehrere Regeln für ausgehenden Traffic in einem Dienstperimeter konfigurieren, lässt VPC Service Controls eine Anfrage zu, wenn sie die Bedingungen einer der Regeln für ausgehenden Traffic erfüllt.
Mit dem Probelaufmodus Richtlinien für ein-/ausgehenden Traffic testen
Wenn Sie keinen Zugriff auf alle Methoden eines Dienstes gewähren möchten, ist es manchmal schwierig, die genaue Liste der zulässigen Methoden zu bestimmen. Dies kann auftreten, wenn eine bestimmte Methode für einen Dienst dazu führen kann, dass eine andere Methode in einem separaten Google Cloud -Dienst aufgerufen wird. BigQuery lädt beispielsweise eine Tabelle aus einem Cloud Storage-Bucket, um eine Abfrage auszuführen.
Zur Bestimmung der richtigen Methoden können Sie den Probelaufmodus von VPC Service Controls verwenden. Aktivieren Sie dazu zuerst einen Perimeter im Probelaufmodus ohne Richtlinien für ein- oder ausgehenden Traffic und erfassen Sie die Liste der Methoden, die im Audit-Log aufgerufen werden. Anschließend fügen Sie diese Methoden schrittweise den Richtlinien für ein-/ausgehenden Traffic im Probelaufmodus hinzu, bis alle Verstöße behoben sind. An dieser Stelle kann die Konfiguration vom Probelaufmodus in den erzwungenen Modus verschoben werden.
Nicht unterstützte Funktionen
Die folgenden Features werden derzeit für die Regeln für ein- und ausgehenden Traffic nicht unterstützt:
- Google Cloud Ressourcen anhand von Labels anstelle von Projekten identifizieren.
- Nicht alle Dienste unterstützen Regeln für ein-/ausgehenden Traffic. Siehe Unterstützte Einschränkungen für Dienstmethoden.
- Die Identitätstypen
ANY_SERVICE_ACCOUNT
undANY_USER_ACCOUNT
können nicht für das Erlauben der folgenden Vorgänge verwendet werden:- Alle Container Registry-Vorgänge.
- Alle Dienstvorgänge für notebooks.googleapis.com.
- Cloud Storage-Vorgänge mit signierten URLs.
- Bei Cloud Run-Funktionen: die Bereitstellung einer Cloud Functions-Funktion vom lokalen Rechner aus.
- Logs aus einer Cloud Logging-Senke in eine Cloud Storage-Ressource exportieren.
- Alle Apache Airflow-Weboberflächen-Vorgänge in Cloud Composer.
Beschränkungen
Informationen zu Beschränkungen für eingehenden und ausgehenden Traffic finden Sie unter Kontingente und Beschränkungen.
Nächste Schritte
- In diesem codelab erfahren Sie, wie Sie Verstöße in Bezug auf eingehenden und ausgehenden Traffic beheben.
- Informationen zum Einrichten und Aufrufen des Dashboards für Verstöße (Vorschau)