Diese Seite wurde von der Cloud Translation API übersetzt.

Zugriff auf geschützte Ressourcen von einer internen IP-Adresse aus erlauben

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

Übersicht

Sie können mit VPC Service Controls Bedingungen angeben, um bestimmte IP-Adressen zuzulassen des VPC-Netzwerk für den Zugriff auf die geschützten Projekten und VPC-Netzwerken. Mit dieser Funktion können Sie Aufgaben:

Basiszugriff unterstützen interne IP-Adressbereiche von VPC-Netzwerken zulassen.
Verwendung dieser Bedingungen für Zugriffsebenen für die API für eingehenden oder ausgehenden Traffic zulassen Aufrufe innerhalb oder außerhalb des Dienstperimeters.

Diese Funktion bietet folgende Vorteile:

Sie können Bedingungen in VPC Service Controls-Konfigurationen angeben, um Zugriff von einer internen IP-Adresse in einem VPC-Netzwerk.
Workflows, bei denen API-Aufrufe mehrere Dienstperimeter erfordern kann den Zugriff so einschränken, dass nur wenige Subnetze zulässig sind, statt den Zugriff oder Projekt VPC-Netzwerk.
Sie können verschiedene lokale Ressourcen konfigurieren, um auf bestimmte Google Cloud-Ressourcen zugreifen. Sie müssen die IP-Adresse des Subnetzes Adressbereich, der diesen lokalen Ressourcen und der Landing Zone zugeordnet ist VPC-Netzwerk als Teil der Zugriffsebene.

Abbildung 1 zeigt eine Beispielkonfiguration, die den Zugriff auf einen bestimmten geschützten über eine autorisierte interne IP-Adresse.

Einschränkungen bei der Verwendung interner IP-Adressen

Wenn Sie eine interne IP-Adresse in VPC Service Controls verwenden, gilt Folgendes: gelten folgende Einschränkungen:

Sie können eine interne IP-Adresse nur mit grundlegenden Zugriffsebenen aktivieren. mit benutzerdefinierten Zugriffsebenen.
Wir empfehlen, Zugriffsebenen nicht mit einer internen IP-Adresse zu negieren. da dies zu unerwartetem Verhalten führen kann.
Die Einschränkungen auch VPC-Netzwerke zu Dienstperimetern hinzufügen.
Wenn VPC Service Controls ein Audit-Log zu einer Richtlinie über abgelehnte Richtlinien protokolliert, wird der Name entfernt. des VPC-Netzwerk als __UNKNOWN__ im Audit-Log angegeben.
VPC-Netzwerke, für die SUBNET_MODE auf custom festgelegt ist aber keine Subnetze haben, werden jedoch nicht unterstützt. Interne IP-Adresse wird aktiviert erfordert, dass ein VPC-Netzwerk mindestens ein Subnetz enthalten muss.
Sie können nur 500 VPC angeben Netzwerke in allen Zugriffsebenen in Ihrer Zugriffsrichtlinie festzulegen.
Wenn Sie ein VPC-Netzwerk löschen, auf das ein Zugriff verweist oder einen Dienstperimeter haben, und erstellen Sie dann eine weitere VPC denselben Namen erhalten, aktiviert VPC Service Controls interne IP-Adressen im neu erstellten VPC-Netzwerk Bis diese Einschränkung zu umgehen, erstellen Sie ein VPC-Netzwerk mit einer einen anderen Namen und fügen ihn dem Perimeter hinzu.
Sie können keine interne IP-Adresse verwenden, um den Zugriff über von Google verwaltete . Beispiel: Cloud SQL.
Wenn Sie eine Zugriffsebene mit Bedingungen verwenden, die auf internen IP-Adressen basieren mit einer Regel für ausgehenden Traffic haben, empfehlen wir, keine weiteren Bedingungen etwa Gerätetyp, Nutzeridentität und Zugriffsebene.
Die interne IP-Adresse stimmt nicht mit den Zugriffsebenen überein, die sich auf den geografischen Regionen.

Interne IP-Adresse in Zugriffsebenen verwenden

Geben Sie den VPC-Netzwerknamen und den IP-Adressbereich in der Feld vpcNetworkSources der Basiszugriffsebene Bedingung aus.
- VPC-Netzwerkname: Sie müssen die VPC definieren Netzwerknamens im folgenden Format:
```
//compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME
```
  Beispiel: //compute.googleapis.com/projects/my-project/global/networks/my-vpc
- IP-Adressbereich. Der in VpcSubNetwork angegebene IP-Adressbereich Feld von VpcNetworkSource muss der CIDR-Block-IP-Subnetzwerkspezifikation entsprechen. Sie können eine beliebige IP-Adresse verwenden. Bereich, der ein gültiger IPv4-Bereich für Subnetze ist.
Diese Zugriffsebene mit Zulassungsbedingungen in der IngressSource oder EgressSource.

In den folgenden Abschnitten wird anhand eines Beispielszenarios erläutert, wie diese Schritte ausgeführt werden. Schritte zum Aktivieren einer internen IP-Adresse.

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, über die Traffic gesendet wird.
Cloud Storage-Projekt: Project2 enthält einen Cloud Storage-Bucket.

Sie können VPC Service Controls verwenden, um nur VM1 aus Project1 den Zugriff auf den Cloud Storage-Bucket in Project2 mit einer internen IP-Adresse. Dazu müssen Sie die folgenden Schritte ausführen:

Sie erstellen einen Dienstperimeter sp1 um Project1 und einen anderen Dienst Umfang sp2 um Project2.
Dann können Sie Regeln für eingehenden und ausgehenden Traffic zu den Dienstperimetern hinzufügen, nur dem Subnetz von VM1 Zugriff auf den Cloud Storage-Bucket gewähren.

Das folgende Diagramm zeigt die in diesem Beispiel beschriebene Einrichtung.

Zugriffsrichtlinie auf Organisationsebene konfigurieren

Achten Sie darauf, dass Sie eine Zugriffsrichtlinie auf Organisationsebene haben. Wenn Sie keine Zugriffsrichtlinie auf dieser Ebene haben, führen Sie folgenden Befehl aus: gcloud CLI-Befehlszeile:
```
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 Menschen lesbarer Titel für Ihre Zugriffsrichtlinie.
Weitere Informationen finden Sie unter Zugriff auf Organisationsebene erstellen .
Name Ihres Zugriffs abrufen .
Führen Sie folgenden Befehl aus, um diese Richtlinie als Standardzugriffsrichtlinie festzulegen: gcloud CLI-Befehlszeile:
```
gcloud config set access_context_manager/policy POLICY_NAME
```
Ersetzen Sie POLICY_NAME durch den numerischen Namen der Zugriffsrichtlinie.

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

Erstellen Sie Perimeter, um das Netzwerk-Hostprojekt und das Cloud Storage-Projekt zu schützen

Führen Sie folgenden Befehl aus, um einen Perimeter sp1 um Project1 zu erstellen. gcloud CLI-Befehlszeile:
```
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
Um einen Perimeter sp2 um Project2 zu erstellen, der Cloud Storage-Dienst führen Sie den folgenden gcloud CLI-Befehl aus:
```
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 von Cloud Storage Projekt arbeiten. Beispiel: projects/222.
- POLICY_NAME: Der numerische Name Ihrer Zugriffsrichtlinie. Beispiel: 1234567890

Weitere Informationen zum Erstellen eines Dienstperimeters finden Sie unter Dienst erstellen Perimeter

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

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

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

Erstellen Sie eine YAML-Datei, in der die Zugriffsbedingungen definiert sind. Im folgenden Beispiel zeigt nur die Attribute an, 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-Netzwerk 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-Netzwerk und die Formate des IP-Adressbereichs wie zuvor erläutert wurde.

Weitere Informationen zur YAML-Datei finden Sie unter YAML-Datei basic-level-spec. Datei.
Führen Sie folgenden Befehl aus, um mithilfe der YAML-Datei eine Zugriffsebene zu erstellen: gcloud CLI-Befehlszeile:
```
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, visuell lesbarer Titel für die Zugriffsebene. Beispiel: allowvm1.
- FILE_NAME: Die YAML-Datei, die Ihre Zugriffsbedingungen definiert für die Zugriffsebene. Beispiel: level.yaml.
Weitere Informationen finden Sie unter Grundlegende Zugriffsrechte erstellen Level

Konfigurieren Sie eine Richtlinie für eingehenden Traffic, um eingehenden API-Traffic in den Cloud Storage-Bucket zuzulassen

Wenn Sie nur Zugriff aus VM1 zulassen möchten, konfigurieren Sie eine Richtlinie für eingehenden Traffic in der sp2 Perimeter festlegen, damit der Cloud Storage API-Traffic in den Perimeter gelangen kann.

Erstellen Sie eine YAML-Datei, die Ihre Richtlinie für eingehenden Traffic 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 unter Regeln für eingehenden Traffic Referenz.
Führen Sie den folgenden Befehl aus, um die Richtlinie für eingehenden Traffic für einen Dienstperimeter zu aktualisieren: gcloud CLI-Befehlszeile:
```
gcloud access-context-manager perimeters update PERIMETER --set-ingress-policies=FILE_NAME
```
Ersetzen Sie Folgendes:
- PERIMETER: Der Name des Dienstperimeters, der die Cloud Storage-Projekt Beispiel: sp2.
- FILE_NAME: Die YAML-Datei, die Ihre Richtlinie für eingehenden Traffic definiert. Beispiel: ingress.yaml
Weitere Informationen finden Sie unter Richtlinien für eingehenden und ausgehenden Traffic für einen Dienstperimeter.

Konfigurieren Sie eine Richtlinie für ausgehenden Traffic, um ausgehenden API-Traffic zum Cloud Storage-Bucket zuzulassen

Konfigurieren Sie außerdem eine Richtlinie für ausgehenden Traffic im Perimeter sp1, um Cloud Storage API-Traffic zum Verlassen des Perimeters.

Erstellen Sie eine YAML-Datei, die Ihre Richtlinie für ausgehenden Traffic definiert. Achten Sie darauf, das Feld sourceRestriction als SOURCE_RESTRICTION_ENABLED in der YAML-Datei -Datei.
```
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 unter Regeln für ausgehenden Traffic Referenz.
Führen Sie den folgenden Befehl aus, um die Richtlinie für ausgehenden Traffic für einen Dienstperimeter zu aktualisieren: Befehl:
```
gcloud access-context-manager perimeters update PERIMETER --set-egress-policies=FILE_NAME
```
Ersetzen Sie Folgendes:
- PERIMETER: Der Name des Dienstperimeters, der die Netzwerk-Hostprojekt. Beispiel: sp1.
- FILE_NAME: Die YAML-Datei, die Ihre Richtlinie für ausgehenden Traffic definiert. Beispiel: egress.yaml
Weitere Informationen finden Sie unter Richtlinien für eingehenden und ausgehenden Traffic für einen Dienstperimeter.

Nachdem Sie die Richtlinien für eingehenden und ausgehenden Traffic konfiguriert haben, ist über die VM1 zugänglich, während auf den Cloud Storage-Bucket nicht zugänglich über VM2.

Empfehlungen

Wenn Sie eine interne IP-Adresse aktivieren, sollten Sie die Option IP-Adresse -Weiterleitung für Ihre VMs. IP-Weiterleitung Ermöglicht einer VM im selben VPC-Netzwerk, Anfragen zu senden verwenden, wodurch das Risiko von IP-Adressen-Spoofing besteht.
Wenn Sie die IP-Weiterleitung aktivieren möchten, empfehlen wir die Verwendung des folgenden Konfigurationen, um das Risiko von IP-Adressen-Spoofing zu verringern:
- Organisationsrichtlinie Restrict VM IP Forwarding verwenden Einschränkung (constraints/compute.vmCanIpForward), damit nur autorisierte VMs aktivieren Sie die IP-Weiterleitung.
- Quellen für Firewallregeln verwenden , um die IP-Adressen einzuschränken, die mit den VMs kommunizieren können, die IP-Adressen haben 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, für die die IP-Weiterleitung aktiviert ist.
  - Firewallregeln für ausgehenden Traffic einrichten, um ausgehenden Traffic nur an eine bestimmte IP-Adressbereich der VMs, für die die IP-Weiterleitung aktiviert ist.