Regeln für ein- und ausgehenden Traffic

Auf dieser Seite werden die in VPC Service Controls geltenden Regeln für ein- und ausgehenden Traffic erläutert. VPC Service Controls regelt damit den Zugriff von den und auf die Ressourcen und Clients, die durch Dienstperimeter geschützt sind.

Die Regelblöcke für eingehenden und ausgehenden Traffic legen die Richtung des zulässigen Zugriffs auf und von Identitäten und Ressourcen fest. Regeln für eingehenden oder ausgehenden Traffic ersetzen oder vereinfachen Anwendungsfälle, für die zuvor eine oder mehrere Perimeter-Bridges benötigt wurden.

Informationen zum Anwenden der Regeln für ein- und ausgehenden Traffic auf Ihren Dienstperimeter finden Sie unter Richtlinien für ein- und ausgehenden Traffic konfigurieren.

In den Regeln für ein- und ausgehenden Traffic können Sie Identitätsgruppen und Identitäten von Drittanbietern sowie IAM-Rollen (Vorschau) konfigurieren.

Eine Liste mit Anwendungsfällen und Beispielen für sicheren Datenaustausch finden Sie unter Sicherer Datenaustausch mit Regeln für ein- und ausgehenden Traffic.

Eine Liste mit Anwendungsfällen und Beispielen für kontextsensitiven Zugriff finden Sie unter Kontextsensitiver Zugriff mit Regeln für eingehenden Traffic.

Vorteile von Regeln für ein- und ausgehenden Traffic

Mithilfe von Regeln für ein- und ausgehenden Traffic ist es möglich, Daten mit APIs von Google Cloud -Diensten privat und effizient intern und organisationsübergreifend austauschen.
Mit Regeln für ein- und ausgehenden Traffic können Sie den Zugriff auf in einem Perimeter geschützte Google Cloud-Ressourcen abhängig vom Kontext der API-Anfrage zulassen:
1. Sie können Identitätstypen oder Identitäten einschränken, die für ein bestimmtes Quellnetzwerk, eine bestimmte IP-Adresse oder ein bestimmtes Gerät verwendet werden können.
2. Sie können APIs und Methoden von Google Cloud einschränken, auf die je nach Quellnetzwerk, IP-Adresse, Gerät und Identitätstyp zugegriffen werden kann.
Mit den Regeln reduzieren Sie Risiko von Exfiltration, indem Sie die zum Datenaustausch verwendeten Dienste, Methoden,Google Cloud -Projekte, VPC-Netzwerke und Identitäten exakt eingrenzen.
Sie können Lesezugriff auf externe, nicht von Ihnen verwaltete Datensätze und Bilder zulassen.
Sie können damit steuern, dass Clients in Segmenten mit geringeren Berechtigungen keinen Zugriff aufGoogle Cloud -Ressourcen in Segmenten mit höheren Berechtigungen haben, und gleichzeitig den Zugriff in die andere Richtung zulassen.
Sie können Konfigurationen vereinfachen, für die zuvor eine oder mehrere Perimeter-Bridges erforderlich waren.

Definition von eingehendem und ausgehendem Traffic

Die Konzepte eingehender und ausgehender Traffic lassen sich unabhängig vom Vorgang definieren, der für die Ressource aufgerufen wird. Die Definitionen beziehen sich daher auf die Richtung der Anfrage und nicht auf die Richtung der Datenbewegung.

Eingehender Traffic: Jeder Zugriff eines API-Clients von außerhalb des Dienstperimeters auf Ressourcen innerhalb eines Dienstperimeters. Beispiel:
- Ein Cloud Storage-Client außerhalb eines Dienstperimeters ruft Lese-, Schreib- oder Kopiervorgänge für eine Cloud Storage-Ressource innerhalb des Dienstperimeters auf.
Ausgehender Traffic: Jeder Zugriff, an dem ein API-Client oder Ressourcen innerhalb eines Dienstperimeters und Ressourcen außerhalb eines Dienstperimeters beteiligt sind. Beispiele:
- Ein Compute Engine-Client innerhalb eines Dienstperimeters ruft einen create-Vorgang in Compute Engine auf, wobei sich die Image-Ressource außerhalb des Perimeters befindet.
- Ein Cloud Storage-Client, innerhalb oder außerhalb des Perimeters ruft einen copy-Befehl auf, wobei sich ein Bucket innerhalb des Perimeters und der andere Bucket außerhalb des Perimeters befindet.

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 der Dienste und Ressourcen von Google Cloud verweist

Einem Dienstperimeter können mehrere Regeln für ein- und ausgehenden Traffic zugeordnet werden. Aufrufe von Diensten inGoogle Cloud werden anhand der folgenden Semantik zugelassen oder abgelehnt:

Anfragen von Clients außerhalb des Perimeters an Ressourcen von Google Cloud innerhalb des Perimeters sind zulässig, wenn die Bedingungen der entsprechenden Regel für eingehenden Traffic erfüllt sind.
Anfragen von Clients innerhalb des Perimeters an Ressourcen von Google Cloud außerhalb des Perimeters sind zulässig, wenn die Bedingungen der entsprechenden Regel für ausgehenden Traffic erfüllt sind.
API-Aufrufe, an denen eine Google Cloud -Ressource innerhalb des Perimeters und eine Google Cloud -Ressource außerhalb des Perimeters beteiligt sind, sind zulässig, wenn der Client die vorhandene Regel für eingehenden Traffic erfüllt (sofern er sich nicht innerhalb des Perimeters befindet), und die externe Ressource die Regel für ausgehenden Traffic erfüllt.

Beispiele für API-Anfragen, die von Regeln für eingehenden Traffic zugelassen werden

Ein Cloud Storage-Client außerhalb des Perimeters lädt Objekte aus einem Cloud Storage-Bucket innerhalb des Perimeters auf den lokalen Computer herunter (z. B. mit dem Befehl gcloud storage cp).
Ein BigQuery-Client außerhalb des Perimeters fragt mit einem BigQuery-Job aus einem Projekt innerhalb des Perimeters ein BigQuery-Dataset innerhalb des Perimeters ab (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 von Regeln für ausgehenden Traffic zugelassen werden

Ein Cloud Storage-Client innerhalb des Perimeters kopiert Objekte zwischen einem Cloud Storage-Bucket außerhalb des Perimeters und einem Bucket innerhalb des Perimeters (z. B. mit dem Befehl gcloud storage cp).

Ein BigQuery-Client innerhalb des Perimeters fragt mit einem BigQuery-Job in einem Projekt außerhalb des Perimeters ein BigQuery-Dataset innerhalb des Perimeters ab (z. B. mit dem Befehl bq query).

Beispiele für API-Anfragen, die von kombinierten Regeln für ein- und ausgehenden Traffic zugelassen werden

Ein Cloud Storage-Client außerhalb des Perimeters kopiert Objekte zwischen einem Cloud Storage-Bucket außerhalb und einem Bucket innerhalb des Perimeters (z. B. mit dem Befehl gcloud storage cp).
Ein BigQuery-Client außerhalb des Perimeters fragt mit einem BigQuery-Job in einem Projekt außerhalb des Perimeters ein BigQuery-Dataset innerhalb des Perimeters ab (z. B. mit dem Befehl bq query).
Ein Compute Engine-Client außerhalb des Perimeters erstellt mit einem Cloud KMS-Schlüssel innerhalb des Perimeters ein Compute Engine-Laufwerk außerhalb des Perimeters.

In den Beispielen für BigQuery und Compute Engine reicht eine Regel für eingehenden Traffic nicht aus, da sich der BigQuery-Job oder das Compute Engine-Laufwerk außerhalb des Perimeters befinden. Regeln für ausgehenden Traffic werden benötigt, um API-Anfragen zuzulassen, die sich an eine Google Cloud -Ressource innerhalb des Perimeters (das BigQuery-Dataset oder den Cloud KMS-Schlüssel) und eine Ressource außerhalb des Perimeters (den BigQuery-Job oder das Compute Engine-Laufwerk) richten.

API-Anfragen mit mehreren Dienstperimetern

Wenn die aufgerufenen Ressourcen und/oder der API-Client zu unterschiedlichen Dienstperimetern gehören, muss die API-Anfrage von den Richtlinien aller beteiligten Perimeter zugelassen werden. Beispiel: Ein Cloud Storage-Client und ein Bucket a befinden sich in einem Dienstperimeter A, ein Bucket b in einem Dienstperimeter B. In diesem Fall sind die folgenden Regeln erforderlich, damit der Cloud Storage-Client Objekte aus dem Bucket a in den Bucket b und aus dem Bucket b in den Bucket a kopieren kann:

Eine Regel für ausgehenden Traffic im Perimeter A für den Zugriff auf den Cloud Storage-Bucket b
Eine Regel für ausgehenden Traffic im Perimeter B für den Zugriff auf den Cloud Storage-Bucket a
Eine Regel für eingehenden Traffic im Perimeter B für den Zugriff des Cloud Storage-Clients, der sich außerhalb des Perimeters B 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 Format .yaml 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 den Block from, in dem die außerhalb des Perimeters zulässigen Quellen und Identitäten aufgeführt sind.
identityType: (dieses Attribut oder das Attribut identities verwenden) Damit wird definiert, welche Identitätstypen aus den angegebenen sources (Netzwerkursprung) verwendet werden können. Zulässige Werte: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. Der Wert ANY_IDENTITY lässt Anfragen von allen Identitäten zu, einschließlich nicht authentifizierter Anfragen. ANY_USER_ACCOUNT lässt alle menschlichen Nutzer und ANY_SERVICE_ACCOUNT alle Dienstkonten zu. Nicht authentifizierte Anfragen sind jedoch bei beiden Werten (ANY_USER_ACCOUNT und ANY_SERVICE_ACCOUNT) nicht zulässig.

Dieses Attribut schränkt die Identitäten nicht nach der Organisation ein. Mit ANY_SERVICE_ACCOUNT sind beispielsweise Dienstkonten aus beliebigen Organisationen zugelassen.
identities: (dieses Attribut oder das Attribut identityType verwenden) Damit 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, denen Sie Zugriff auf Ressourcen im Perimeter gewähren möchten. VPC Service Controls unterstützt nur die folgenden Identitäten aus den IAM v1 API-Hauptkontokennungen:
- Nutzerkonten und Dienstkonten haben die Formate user:USER_EMAIL_ADDRESS bzw. serviceAccount:SA_EMAIL_ADDRESS.
- Andere Identitäten haben die unter Unterstützte Identitätsgruppen angegebenen Formate.
Weitere Informationen zu diesen Identitäten finden Sie unter Hauptkontokennungen für Zulassungsrichtlinien.
sources: (erforderlich) Dieses Attribut bezieht sich auf eine Liste von Netzwerkursprüngen. Jeder Wert in der Liste ist entweder eine Zugriffsebene oder ein Projekt in Google Cloud . Wenn Sie für das Attribut accessLevel den Wert "*" angeben, lässt die Richtlinie für eingehenden Traffic den Zugriff von jedem Netzwerkursprung zu. Wenn Sie für das Attribut ein Projekt von Google Cloud angeben, lässt die Richtlinie den Zugriff von einem VPC-Netzwerk zu, das zu diesem Projekt gehört.

Dieser Wert wird möglicherweise entfernt, sobald das zugehörige Projekt endgültig gelöscht wird. Das Entfernen dieses Wertes löst jedoch keinen Fehler aus. Prüfen Sie bei der Fehlerbehebung immer, ob der Wert vorhanden ist.
- resource: (dieses Attribut oder das Attribut accessLevel verwenden) Gibt ein Projekt oder VPC-Netzwerk außerhalb des Perimeters an, auf das Sie Zugriff gewähren möchten. Geben Sie Projekte im folgenden Format an: projects/PROJECT_NUMBER. Geben Sie das VPC-Netzwerk im folgenden Format an: //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.
- accessLevel: (dieses Attribut oder das Attribut resource verwenden) Gibt die Zugriffsebene außerhalb des Perimeters an, auf die Zugriff gewährt wird. Wenn Sie für das Attribut accessLevel den Wert "*" angeben, lässt die Richtlinie für eingehenden Traffic den Zugriff von jedem Netzwerkursprung zu.
ingressTo: (erforderlich) Startet den Block to, in dem die zulässigen Dienstvorgänge für angegebene Ressourcen von Google Cloud innerhalb des Perimeters aufgeführt sind.
operations: (dieses Attribut oder das Attribut roles verwenden) Markiert den Anfang der Liste der zugänglichen Dienste und Aktionen/Methoden, auf die ein Client, der die Bedingungen des Blocks from erfüllt, zugreifen darf.
- serviceName: (erforderlich) Das Feld kann ein gültiger Dienstname sein oder auf "*" gesetzt werden, um Zugriff auf alle Dienste zu ermöglichen. Beispielsweise ist bigquery.googleapis.com ein gültiger serviceName. Eine Liste der verfügbaren Dienste finden Sie unter Unterstützte Produkte.
methodSelectors: (erforderlich, wenn serviceName nicht "*" ist) Der Anfang einer Liste von Methoden, auf die ein Client, der die Bedingungen des Blocks from erfüllt, zugreifen darf. Eine Liste der einschränkbaren Methoden und Berechtigungen für Dienste finden Sie unter Unterstützte Einschränkungen für Dienstmethoden.

Eine Liste der Dienstmethoden, die VPC Service Controls nicht steuern kann, finden Sie unter Ausnahmen für Dienstmethoden.
- method: (dieses Attribut oder das Attribut permission verwenden) Dieses Feld kann eine gültige Dienstmethode sein oder auf "*" gesetzt werden, um Zugriff auf alle Methoden des angegebenen Dienstes zu ermöglichen.
- permission: (dieses Attribut oder das Attribut method verwenden.) Dieses Feld muss eine gültige Dienstberechtigung enthalten. Der Zugriff auf die Ressourcen innerhalb des Perimeters ist für die Vorgänge zulässig, die die Berechtigung benötigen.

Wenn für eine Anfrage an eine Ressource mehrere Berechtigungen benötigt werden, müssen Sie alle erforderlichen Berechtigungen unter demselben Vorgang angeben, damit die Regel für eingehenden Traffic funktioniert. Beispiel: Für Ihre Anfrage an eine BigQuery-Ressource benötigen Sie die Berechtigungen bigquery.jobs.create und bigquery.tables.create. Beide Berechtigungen müssen Sie unter demselben Vorgang angeben. Genauso gilt: Berechtigungen, die Sie für dieselbe Ressource über dieGoogle Cloud Console mehrmals angeben, werden nicht unter demselben Vorgang erstellt. Um dieses Problem zu vermeiden, geben Sie alle Berechtigungen für die Ressource gleichzeitig an.
roles: (dieses Attribut oder das Attribut operations verwenden) Dieses Attribut bezieht sich auf eine Liste von IAM-Rollen, die den Zugriffsbereich für die in der Regel angegebenen Dienste definieren.
ROLE_NAME: Geben Sie eine einzelne Rolle oder mehrere Rollen kombiniert an, die alle Berechtigungen abdecken, die für den Zugriff auf die Dienste erforderlich sind. Geben Sie die Rollen mit den unter Rollenkomponenten genannten Formaten für Rollennamen an, 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 im Dienstperimeter die Liste der Ressourcen inGoogle Cloud an, auf die der Client außerhalb des Perimeters zugreifen kann. Dieses Feld kann auf "*" gesetzt werden, um eingehenden Zugriff auf alle Ressourcen von Google Cloud 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. Innerhalb der Zugriffsrichtlinie darf die Gesamtlänge aller Titel 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: Geben Sie accessLevel oder resource (Projekt inGoogle Cloud oder VPC-Netzwerk) an oder setzen Sie das Attribut accessLevel auf "*".

Attribut identityType oder identities
Attribut resources
Attribut serviceName

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

Wenn Sie mehrere Regeln für eingehenden Traffic in einem Dienstperimeter konfigurieren, lässt VPC Service Controls Anfragen zu, die die Bedingungen einer der Regeln für eingehenden Traffic erfüllen.

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 Format .yaml 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 den Block to, mit dem zugelassene Dienstvorgänge für Ressourcen von Google Cloud in angegebenen Projekten außerhalb des Perimeters aufgeführt werden.
operations: (dieses Attribut oder das Attribut roles verwenden) Markiert den Anfang der Liste der zugänglichen Dienste und Aktionen/Methoden, auf die ein Client, der die Bedingungen des Blocks from erfüllt, zugreifen darf.
- serviceName: (erforderlich) Das Feld kann ein gültiger Dienstname sein oder auf "*" gesetzt werden, um Zugriff auf alle Dienste zu ermöglichen. Eine Liste der verfügbaren Dienste finden Sie unter Unterstützte Produkte.
methodSelectors: (erforderlich, wenn serviceName nicht "*" ist) Der Anfang einer Liste von Methoden, auf die ein Client, der die Bedingungen des Blocks from erfüllt, zugreifen darf. Eine Liste der einschränkbaren Methoden und Berechtigungen für Dienste finden Sie unter Unterstützte Einschränkungen für Dienstmethoden.

Eine Liste der Dienstmethoden, die VPC Service Controls nicht steuern kann, finden Sie unter Ausnahmen für Dienstmethoden.
- method: (dieses Attribut oder das Attribut permission verwenden) 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: (dieses Attribut oder das Attribut method verwenden) Dieses Feld muss eine gültige Dienstberechtigung enthalten. Der Zugriff auf die angegebenen Ressourcen außerhalb des Perimeters ist für die Vorgänge zulässig, für die die Berechtigung erforderlich ist.

Wenn für eine Anfrage an eine Ressource mehrere Berechtigungen benötigt werden, müssen Sie alle erforderlichen Berechtigungen unter demselben Vorgang angeben, damit die Regel für ausgehenden Traffic funktioniert. Beispiel: Für Ihre Anfrage an eine BigQuery-Ressource benötigen Sie die Berechtigungen bigquery.jobs.create und bigquery.tables.create. Beide Berechtigungen müssen Sie unter demselben Vorgang angeben. Genauso gilt: Berechtigungen, die Sie für dieselbe Ressource über dieGoogle Cloud Console mehrmals angeben, werden nicht unter demselben Vorgang erstellt. Um dieses Problem zu vermeiden, geben Sie alle Berechtigungen für die Ressource gleichzeitig an.
roles: (dieses Attribut oder das Attribut operations verwenden) Dieses Attribut bezieht sich auf eine Liste von IAM-Rollen, die den Zugriffsbereich für die in der Regel angegebenen Dienste definieren.
ROLE_NAME: Geben Sie eine einzelne Rolle oder mehrere Rollen kombiniert an, die alle Berechtigungen abdecken, die für den Zugriff auf die Dienste erforderlich sind. Geben Sie die Rollen mit den unter Rollenkomponenten genannten Formaten für Rollennamen an, 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 gibt eine Liste von nach Projekten aufgeschlüsselten Ressourcen von Google Cloudan, auf die Clients innerhalb eines Perimeters zugreifen können. Sie können dieses Feld auf "*" setzen, um den Zugriff von ausgehendem Traffic auf alle Ressourcen vonGoogle Cloud zuzulassen.
externalResources: Dieses Attribut wird nur zur Angabe von BigQuery Omni-Ressourcen verwendet. Es gibt eine Liste externer Ressourcen an, 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 wird das Format s3://BUCKET_NAME unterstützt. Für Azure Storage wird das Format azure://myaccount.blob.core.windows.net/CONTAINER_NAME unterstützt.
egressFrom: (erforderlich) Startet den Block from, in dem zulässige Quellen und Identitäten innerhalb des Perimeters aufgeführt werden.
identityType: (dieses oder das Attribut identities verwenden.) 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. Der Wert ANY_IDENTITY lässt Anfragen von allen Identitäten zu, einschließlich nicht authentifizierter Anfragen. ANY_USER_ACCOUNT lässt alle menschlichen Nutzer und ANY_SERVICE_ACCOUNT alle Dienstkonten zu. Nicht authentifizierte Anfragen sind jedoch bei beiden Werten (ANY_USER_ACCOUNT und ANY_SERVICE_ACCOUNT) nicht zulässig.

Dieses Attribut schränkt die Identitäten nicht nach der Organisation ein. Mit ANY_SERVICE_ACCOUNT sind beispielsweise Dienstkonten aus beliebigen Organisationen zugelassen.
identities: (dieses Attribut oder das Attribut identityType verwenden) Damit wird eine Liste von Dienstkonten, Nutzerkonten, Google-Gruppen oder Drittanbieteridentitäten gestartet, 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 auf die angegebenen Ressourcen außerhalb des Perimeters zugreifen kann. VPC Service Controls unterstützt nur die folgenden Identitäten aus den IAM v1 API-Hauptkontokennungen:
- Nutzerkonten und Dienstkonten haben die Formate user:USER_EMAIL_ADDRESS bzw. serviceAccount:SA_EMAIL_ADDRESS.
- Andere Identitäten haben die unter Unterstützte Identitätsgruppen angegebenen Formate.
Weitere Informationen zu diesen Identitäten finden Sie unter Hauptkontokennungen für Zulassungsrichtlinien.
sources: Dieses Attribut gibt eine Liste der Netzwerkursprünge an. Der Attributwert kann eine Liste von Projekten oder Zugriffsebenen sein. Um Zugriffsbeschränkungen basierend auf den angegebenen sources durchzusetzen, setzen Sie das Attribut sourceRestriction auf SOURCE_RESTRICTION_ENABLED.

VPC Service Controls wertet die Attribute accessLevel und resource des Attributs sources als ODER-Bedingung aus.
- resource: (dieses Attribut oder das Attribut accessLevel verwenden) Geben Sie eine oder mehrere Ressourcen vonGoogle Cloud 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 Projekte im folgenden Format an: projects/PROJECT_NUMBER.

Bei diesem Attribut ist es nicht möglich, durch Angabe von "*" alle Ressourcen von Google Cloud zuzulassen.
- accessLevel: (dieses Attribut oder das Attribut resource verwenden) Geben Sie eine oder mehrere Zugriffsebenen an, die Ressourcen innerhalb des Perimeters den Zugriff auf Ressourcen außerhalb des Perimeters erlauben. Achten Sie darauf, dass diese Zugriffsebenen aus derselben Zugriffsrichtlinie wie der Perimeter stammen. Wenn Sie das Attribut accessLevel auf "*" setzen, ermöglicht die Richtlinie ausgehendem Traffic den Zugriff von jedem Netzwerkursprung.
sourceRestriction: (erforderlich, wenn Sie das Attribut sources verwenden) Mit diesem Attribut können Sie Zugriffsbeschränkungen basierend auf den angegebenen sources erzwingen. Um diese Zugriffsbeschränkungen zu erzwingen, legen Sie das Attribut sourceRestriction auf SOURCE_RESTRICTION_ENABLED fest.

Wenn Sie die Zugriffsbeschränkungen deaktivieren möchten, legen Sie das Attribut sourceRestriction auf SOURCE_RESTRICTION_DISABLED fest.

Wenn Sie keinen Wert für das Attribut sourceRestriction festlegen, ignoriert VPC Service Controls das Attribut sources 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. Innerhalb der Zugriffsrichtlinie darf die Gesamtlänge aller Titel 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 der Richtliniendatei für ausgehenden Traffic auf Ihren Dienstperimeter.

Wenn Sie mehrere Regeln für ausgehenden Traffic in einem Dienstperimeter konfigurieren, lässt VPC Service Controls Anfragen zu, die die Bedingungen einer der Regeln für ausgehenden Traffic erfüllen.

Mit dem Probelaufmodus Richtlinien für ein-/ausgehenden Traffic testen

Sie möchten nicht allen Methoden eines Dienstes Zugriff gewähren. Manchmal ist es aber schwierig, alle Methoden, die Sie zulassen möchten, präzise zu bestimmen. Dies kann daran liegen, dass bestimmte Methoden für einen Dienst bewirken können, dass andere Methoden in einem separaten Dienst von Google Cloud aufgerufen werden. So lädt beispielsweise BigQuery eine Tabelle aus einem Cloud Storage-Bucket, um eine Abfrage auszuführen.

Um die richtigen Methoden zu bestimmen, die zugelassen werden sollen, können Sie den Probelaufmodus von VPC Service Controls verwenden. Aktivieren Sie dazu zuerst einen Perimeter im Probelaufmodus ohne Richtlinien für ein-/ausgehenden Traffic und erfassen Sie die Liste der aufgerufenen Methoden aus dem Audit-Log. Fügen Sie diese Methoden dann schrittweise zu den Richtlinien für ein-/ausgehenden Traffic im Probelaufmodus hinzu, bis alle Verstöße behoben sind. An diesem Punkt kann die Konfiguration vom Probelaufmodus in den erzwungenen Modus überführt werden.

Nicht unterstützte Funktionen

Die folgenden Features werden derzeit bei den Regeln für ein-/ausgehenden Traffic nicht unterstützt:

Ressourcen von Google Cloud anhand von Labels anstelle von Projekten identifizieren
Nicht alle Dienste unterstützen Regeln für ein-/ausgehenden Traffic pro Methode. Siehe Unterstützte Einschränkungen für Dienstmethoden.
Die folgenden Vorgänge können mit den Identitätstypen ANY_SERVICE_ACCOUNT und ANY_USER_ACCOUNT nicht zugelassen werden:
- Alle Container Registry-Vorgänge
- Alle Vorgänge des Dienstes notebooks.googleapis.com
- Cloud Storage-Vorgänge mit signierten URLs
- Bei Cloud Run Functions: die Bereitstellung einer Cloud Function-Funktion vom lokalen Rechner
- Logs aus einer Cloud Logging-Senke in eine Cloud Storage-Ressource exportieren
- Alle Vorgänge auf Apache Airflow-Web-Benutzeroberflächen-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 gegen ein- und ausgehenden Traffic beheben.
Erfahren Sie, wie Sie das Dashboard für Verstöße einrichten und anzeigen können.