Zugriff auf geschützte Ressourcen über eine interne IP-Adresse zulassen

Auf dieser Seite wird beschrieben, wie Sie Traffic von internen IP-Adressen in einem VPC-Netzwerk zu Dienstperimetern mithilfe von Regeln für ein- und ausgehenden Traffic zulassen.

Übersicht

Mit VPC Service Controls können Sie Bedingungen festlegen, damit bestimmte IP-Adressbereiche des VPC-Netzwerks auf die geschützten Projekte und VPC-Netzwerke zugreifen können. Mit dieser Funktion können Sie folgende Aufgaben ausführen:

Unterstützung von Bedingungen auf einfacher Zugriffsebene, um interne IP-Adressbereiche von VPC-Netzwerken zuzulassen.
Die Verwendung dieser Zugriffsebenenbedingungen für API-Aufrufe für eingehenden oder ausgehenden Traffic in bzw. aus der Dienstperimetergrenze zulassen.

Diese Funktion bietet folgende Vorteile:

Sie können Bedingungen in VPC Service Controls-Konfigurationen angeben, um den Zugriff über eine interne IP-Adresse in einem VPC-Netzwerk zuzulassen.
Bei Workflows, bei denen API-Aufrufe mehrere Dienstperimeter durchlaufen müssen, kann der Zugriff so eingeschränkt werden, dass nur wenige Subnetze zugelassen werden, anstatt das gesamte VPC-Netzwerk oder Projekt zuzulassen.
Sie können verschiedene Ressourcen aus Ihrem lokalen Netzwerk so konfigurieren, dass nur auf bestimmte Ressourcen von Google Cloud zugegriffen werden kann. Sie müssen den IP-Adressbereich des Subnetzes verwenden, der diesen lokalen Ressourcen und dem VPC-Netzwerk der Landing Zone zugeordnet ist, um die Zugriffsebene zu definieren.

Abbildung 1 zeigt ein Beispiel für eine Einrichtung, die den Zugriff auf einen bestimmten geschützten Dienst über eine autorisierte interne IP-Adresse ermöglicht.

Einschränkungen bei der Verwendung interner IP-Adressen

Wenn Sie eine interne IP-Adresse in VPC Service Controls verwenden, gelten die folgenden Einschränkungen:

Sie können eine interne IP-Adresse nur mit grundlegenden Zugriffsebenen und nicht mit benutzerdefinierten Zugriffsebenen aktivieren.
Wir empfehlen, Zugriffsebenen nicht mit Bedingungen zu negieren, die auf internen IP-Adressen basieren, da dies zu unerwartetem Verhalten führen kann.
Es gelten auch die Einschränkungen beim Hinzufügen von VPC-Netzwerken zu Dienstperimetern.
Wenn VPC Service Controls ein Audit-Log zu einem Richtlinienverstoß protokolliert, wird der Name des VPC-Netzwerks im Audit-Log als __UNKNOWN__ unkenntlich gemacht.
VPC-Netzwerke, für die SUBNET_MODE auf custom festgelegt ist, aber keine Subnetze haben, werden nicht unterstützt. Wenn Sie eine interne IP-Adresse aktivieren, muss ein VPC-Netzwerk mindestens ein Subnetz enthalten.
Sie können in Ihrer Zugriffsrichtlinie nur 500 VPC-Netzwerke für alle Zugriffsebenen angeben.
Wenn Sie ein VPC-Netzwerk löschen, auf das von einer Zugriffsebene oder einem Dienstperimeter verwiesen wird, und dann ein anderes VPC-Netzwerk mit demselben Namen neu erstellen, werden interne IP-Adressen in VPC Service Controls nicht automatisch für das neu erstellte VPC-Netzwerk aktiviert. Um diese Einschränkung zu umgehen, erstellen Sie ein VPC-Netzwerk mit einem anderen Namen und fügen Sie es dem Perimeter hinzu.
Sie können keine interne IP-Adresse verwenden, um den Zugriff von von Google verwalteten Diensten zuzulassen. Zum Beispiel Cloud SQL.
Wenn Sie eine Zugriffsebene mit auf internen IP-Adressen basierenden Bedingungen mit einer Regel für ausgehenden Traffic verwenden, empfehlen wir, der Zugriffsebene keine anderen Bedingungen wie Gerätetyp oder Nutzeridentität hinzuzufügen.
Die interne IP-Adresse stimmt nicht mit Zugriffsebenen überein, die sich auf geografische Regionen beziehen.

Interne IP-Adresse in Zugriffsebenen verwenden

Geben Sie den Namen des VPC-Netzwerks und den IP-Adressbereich im Feld vpcNetworkSources der Bedingung für die grundlegende Zugriffsebene an.
- VPC-Netzwerkname. Sie müssen den Namen des VPC-Netzwerks im folgenden Format definieren:
```
//compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME
```
  Beispiel: //compute.googleapis.com/projects/my-project/global/networks/my-vpc
- IP-Adressbereich. Der im Feld VpcSubNetwork von VpcNetworkSource angegebene IP-Adressbereich muss der Spezifikation für IP-Subnetze von CIDR-Blöcken entsprechen. Sie können jeden IP-Adressbereich verwenden, der ein gültiger IPv4-Bereich für Subnetze ist.
Verwenden Sie diese Zugriffsebene mit Zulassungsbedingungen in IngressSource oder EgressSource.

Anhand eines Beispielszenarios wird in den folgenden Abschnitten erläutert, wie Sie diese Schritte ausführen, um eine interne IP-Adresse zu aktivieren.

Beispiel für die Verwendung einer internen IP-Adresse zum Einrichten des Subnetzzugriffs

Im folgenden Beispiel haben Sie zwei Projekte:

Netzwerk-Hostprojekt:Project1 hostet ein VPC-Netzwerk:default. Die beiden VMs in Project1, VM1 und VM2 verwenden dieses Netzwerk als Netzwerkschnittstelle, um Traffic zu senden.
Cloud Storage-Projekt: Project2 enthält einen Cloud Storage-Bucket.

Mit VPC Service Controls können Sie festlegen, dass nur VM1 aus Project1 über eine interne IP-Adresse auf den Cloud Storage-Bucket in Project2 zugreifen darf. Für diese Einrichtung sind die folgenden Schritte erforderlich:

Sie erstellen einen Dienstperimeter sp1 um Project1 und einen weiteren Dienstperimeter sp2 um Project2.
Anschließend können Sie den Dienstperimetern Regeln für ein- und ausgehenden Traffic hinzufügen, um nur den Subnetzwerkzugriff von VM1 auf den Cloud Storage-Bucket zuzulassen.

Das folgende Diagramm zeigt die in diesem Beispiel beschriebene Einrichtung.

Zugriffsrichtlinie auf Organisationsebene konfigurieren

Prüfen Sie, ob Sie eine Zugriffsrichtlinie auf Organisationsebene haben. Wenn Sie auf dieser Ebene keine Zugriffsrichtlinie haben, führen Sie den folgenden gcloud CLI-Befehl aus:
```
gcloud access-context-manager policies create \
    --organization=ORGANIZATION_ID --title=POLICY_TITLE
```
Ersetzen Sie Folgendes:
- ORGANIZATION_ID: Die numerische ID Ihrer Organisation.
- POLICY_TITLE: Ein für Nutzer lesbarer Titel für Ihre Zugriffsrichtlinie.
Weitere Informationen finden Sie unter Zugriffsrichtlinie auf Organisationsebene erstellen.
Name Ihrer Zugriffsrichtlinie abrufen
Führen Sie den folgenden gcloud CLI-Befehl aus, um diese Richtlinie als Standardzugriffsrichtlinie festzulegen:
```
gcloud config set access_context_manager/policy POLICY_NAME
```
Ersetzen Sie POLICY_NAME durch den numerischen Namen Ihrer Zugriffsrichtlinie.

Weitere Informationen finden Sie unter Standardzugriffsrichtlinie für das gcloud-Befehlszeilentool festlegen.

Perimeter zum Schutz des Netzwerk-Hostprojekts und des Cloud Storage-Projekts erstellen

Führen Sie den folgenden gcloud CLI-Befehl aus, um einen Perimeter sp1 um Project1 zu erstellen:
```
gcloud access-context-manager perimeters create sp1 --title="sp1" --resources=PROJECT_NUMBER \
    --restricted-services=storage.googleapis.com --policy=POLICY_NAME
```
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: Die Projektnummer des Netzwerk-Hostprojekts. Beispiel: projects/111.
- POLICY_NAME: Der numerische Name Ihrer Zugriffsrichtlinie. Beispiel: 1234567890
Führen Sie den folgenden gcloud CLI-Befehl aus, um einen Perimeter sp2 um Project2 zu erstellen, der den Cloud Storage-Dienst einschränkt:
```
gcloud access-context-manager perimeters create sp2 --title="sp2" --resources=PROJECT_NUMBER \
    --restricted-services=storage.googleapis.com --policy=POLICY_NAME
```
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: Die Projektnummer des Cloud Storage-Projekts. Beispiel: projects/222.
- POLICY_NAME: Der numerische Name Ihrer Zugriffsrichtlinie. Beispiel: 1234567890

Weitere Informationen zum Erstellen eines Dienstperimeters finden Sie unter Dienstperimeter erstellen.

Nachdem Sie diese beiden Perimeters erstellt haben, ist der Cloud Storage-Bucket nicht mehr über die beiden VMs zugänglich.

Zugriffsebene mit einer auf einer internen IP-Adresse basierenden Zugriffsbedingung erstellen

Erstellen Sie eine Zugriffsebene, die nur Traffic aus dem Subnetz von VM1 zulässt.

Erstellen Sie eine YAML-Datei, in der Sie Ihre Zugriffsbedingungen definieren. Im folgenden Beispiel sind nur die Attribute enthalten, die Sie zum Aktivieren einer internen IP-Adresse benötigen:
```
echo """
- vpcNetworkSources:
  - vpcSubnetwork:
      network: VPC_NETWORK_NAME
      vpcIpSubnetworks:
      - IP_RANGE

""" > level.yaml
```
Ersetzen Sie Folgendes:
- VPC_NETWORK_NAME: Der Name des VPC-Netzwerks, in dem sich die VM1 befindet. Beispiel: //compute.googleapis.com/projects/Project1/global/networks/default.
- IP_RANGE: Der IP-Adressbereich des Subnetzes. Beispiel: 10.10.0.0/24
Verwenden Sie den Namen des VPC-Netzwerks und die zuvor beschriebenen Formate für IP-Adressbereiche.

Weitere Informationen zur YAML-Datei finden Sie unter basic-level-spec-YAML-Datei.
Führen Sie den folgenden gcloud CLI-Befehl aus, um eine Zugriffsebene mit der YAML-Datei zu erstellen:
```
gcloud access-context-manager levels create LEVEL_NAME \
    --title="TITLE" --basic-level-spec=FILE_NAME
```
Ersetzen Sie Folgendes:
- LEVEL_NAME: Ein eindeutiger Name für die Zugriffsebene. Beispiel: allowvm1
- TITLE: Ein kurzer, für Nutzer lesbarer Titel der Zugriffsebene. Beispiel: allowvm1.
- FILE_NAME: Die YAML-Datei, die Ihre Zugriffsbedingungen für die Zugriffsebene definiert. Beispiel: level.yaml.
Weitere Informationen finden Sie unter Einfache Zugriffsebene erstellen.

Richtlinie für eingehenden Traffic konfigurieren, um eingehenden API-Traffic zum Cloud Storage-Bucket zuzulassen

Wenn Sie nur Zugriff von VM1 zulassen möchten, konfigurieren Sie eine Ingress-Richtlinie im Perimeter sp2, damit Cloud Storage API-Traffic in den Perimeter gelangen kann.

Erstellen Sie eine YAML-Datei, die Ihre Ingress-Richtlinie definiert.

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME
  ingressTo:
    operations:
    - methodSelectors:
      - method: '*'
      serviceName: storage.googleapis.com
    resources:
    - '*'

""" > ingress.yaml

Ersetzen Sie Folgendes:

POLICY_NAME: Der numerische Name Ihrer Zugriffsrichtlinie. Beispiel: 1234567890
ACCESS_LEVEL_NAME: Der Name Ihrer Zugriffsebene. Beispiel: allowvm1

Weitere Informationen zur YAML-Datei finden Sie in der Referenz zu Regeln für eingehenden Traffic.

Führen Sie den folgenden gcloud CLI-Befehl aus, um die Richtlinie für eingehenden Traffic für einen Dienstperimeter zu aktualisieren:
```
gcloud access-context-manager perimeters update PERIMETER --set-ingress-policies=FILE_NAME
```
Ersetzen Sie Folgendes:
- PERIMETER: Der Name Ihres Dienstperimeters, der das Cloud Storage-Projekt schützt. Beispiel: sp2.
- FILE_NAME: Die YAML-Datei, in der Ihre Richtlinie für eingehenden Traffic definiert ist. Beispiel: ingress.yaml
Weitere Informationen finden Sie unter Richtlinien für ein- und ausgehenden Traffic für einen Dienstperimeter aktualisieren.

Richtlinie für ausgehenden Traffic konfigurieren, um ausgehenden API-Traffic zum Cloud Storage-Bucket zuzulassen

Konfigurieren Sie außerdem eine Richtlinie für ausgehenden Traffic im Perimeter sp1, damit Cloud Storage API-Traffic den Perimeter verlassen kann.

Erstellen Sie eine YAML-Datei, die Ihre Richtlinie für ausgehenden Traffic definiert. Achten Sie darauf, dass Sie das Feld sourceRestriction in der YAML-Datei auf SOURCE_RESTRICTION_ENABLED setzen.
```
echo """
- egressFrom:
    identityType: ANY_IDENTITY
    sourceRestriction: SOURCE_RESTRICTION_ENABLED
    sources:
    - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME
  egressTo:
    operations:
    - methodSelectors:
      - method: '*'
      serviceName: storage.googleapis.com
    resources:
    - '*'

""" > egress.yaml
```
Ersetzen Sie Folgendes:
- POLICY_NAME: Der numerische Name Ihrer Zugriffsrichtlinie. Beispiel: 1234567890
- ACCESS_LEVEL_NAME: Der Name Ihrer Zugriffsebene. Beispiel: allowvm1
Weitere Informationen zur YAML-Datei finden Sie in der Referenz zu Regeln für ausgehenden Traffic.
Führen Sie den folgenden Befehl aus, um die Richtlinie für ausgehenden Traffic für einen Dienstperimeter zu aktualisieren:
```
gcloud access-context-manager perimeters update PERIMETER --set-egress-policies=FILE_NAME
```
Ersetzen Sie Folgendes:
- PERIMETER: Der Name Ihres Dienstperimeters, der das Netzwerk-Hostprojekt schützt. Beispiel: sp1.
- FILE_NAME: Die YAML-Datei, in der Ihre Egress-Richtlinie definiert ist. Beispiel: egress.yaml
Weitere Informationen finden Sie unter Richtlinien für ein- und ausgehenden Traffic für einen Dienstperimeter aktualisieren.

Nachdem Sie die Ingress- und Egress-Richtlinien konfiguriert haben, ist der Cloud Storage-Bucket über VM1 zugänglich, nicht aber über VM2.

Empfehlungen

Wenn Sie eine interne IP-Adresse aktivieren, empfehlen wir, IP-Weiterleitung für Ihre VMs zu deaktivieren. Mit IP-Weiterleitung kann eine VM im selben VPC-Netzwerk Anfragen mit einer anderen IP-Adresse senden, was das Risiko von IP-Adress-Spoofing birgt.
Wenn Sie die IP-Weiterleitung aktivieren möchten, empfehlen wir die folgenden Konfigurationen, um das Risiko von IP-Adress-Spoofing zu verringern:
- Verwenden Sie die Restrict VM IP Forwarding-Einschränkung für Unternehmensrichtlinien (constraints/compute.vmCanIpForward), um dafür zu sorgen, dass nur autorisierte VMs die IP-Weiterleitung aktivieren können.
- Verwenden Sie Quellen für Firewallregeln, um die IP-Adressen einzuschränken, die mit den VMs kommunizieren können, für die die IP-Weiterleitung aktiviert ist. Führen Sie die folgenden Schritte aus:
  - Richten Sie Firewallregeln für eingehenden Traffic ein, um eingehenden Traffic nur von einem bestimmten IP-Adressbereich zu den VMs zuzulassen, für die die IP-Weiterleitung aktiviert ist.
  - Richten Sie Firewallregeln für ausgehenden Traffic ein, um ausgehenden Traffic nur zu einem bestimmten IP-Adressbereich von den VMs zuzulassen, für die die IP-Weiterleitung aktiviert ist.

Zugriff auf geschützte Ressourcen über eine interne IP-Adresse zulassen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.