Diese Seite wurde von der Cloud Translation API übersetzt.

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

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 haben Sie folgende Möglichkeiten:

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.
Bei Workflows, bei denen API-Aufrufe mehrere Dienstperimeter durchlaufen müssen, kann der Zugriff auf nur wenige Subnetze beschränkt werden, anstatt das gesamte VPC-Netzwerk oder Projekt zuzulassen.
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, 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 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 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 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. 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 den VPC-Netzwerknamen 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 in VpcSubNetwork angegebene IP-Adressbereich Feld von VpcNetworkSource muss der CIDR-Block-IP-Subnetzwerkspezifikation entsprechen. Sie können jeden IP-Adressbereich verwenden, der ein gültiger IPv4-Bereich ist.
Verwenden Sie diese Zugriffsebene mit Zulassungsbedingungen in 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, um Traffic weiterzuleiten.
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. Gehen Sie dazu so vor:

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 dem Subnetz von VM1 Zugriff auf den Cloud Storage-Bucket zu gewähren.

Das folgende Diagramm zeigt die in diesem Beispiel beschriebene Konfiguration.

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 Nutzer 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 zum Schutz des Netzwerk-Hostprojekts und des Cloud Storage-Projekts

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
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 Perimeter erstellt haben, ist der Cloud Storage-Bucket nicht mehr von den beiden VMs aus zugänglich.

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 sind nur die Attribute zu sehen, die zum Aktivieren einer internen IP-Adresse erforderlich sind:
```
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 oben beschriebenen Formate für IP-Adressbereiche.

Weitere Informationen zur YAML-Datei finden Sie unter basic-level-spec YAML-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 Zugriffsebene erstellen.

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

Wenn Sie den Zugriff nur von VM1 zulassen möchten, konfigurieren Sie eine Ingress-Richtlinie im Perimeter sp2, damit Cloud Storage API-Traffic den Perimeter betreten 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 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 das Cloud Storage-Projekt schützt. Beispiel: sp2.
- FILE_NAME: Die YAML-Datei, die Ihre Ingress-Richtlinie 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 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: Befehl:
```
gcloud access-context-manager perimeters update PERIMETER --set-egress-policies=FILE_NAME
```
Ersetzen Sie Folgendes:
- PERIMETER: Der Name des Dienstperimeters, der das Netzwerk-Hostprojekt schützt. Beispiel: sp1.
- FILE_NAME: Die YAML-Datei, die Ihre Ausstiegsrichtlinie definiert. Beispiel: egress.yaml
Weitere Informationen finden Sie unter Richtlinien für eingehenden und ausgehenden Traffic für einen Dienstperimeter.

Nachdem Sie die Ingress- und Egress-Richtlinien konfiguriert haben, ist der Cloud Storage-Bucket von der VM1 aus zugänglich, während der Zugriff von der VM2 aus nicht möglich ist.

Empfehlungen

Wenn Sie eine interne IP-Adresse aktivieren, empfehlen wir, das IP‑Weiterleiten für Ihre VMs zu deaktivieren. Bei der IP‑Weiterleitung kann eine VM im selben VPC-Netzwerk Anfragen mit einer anderen IP‑Adresse senden. Das birgt das Risiko von IP‑Adress-Spoofing.
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 die Organisationsrichtlinie (constraints/compute.vmCanIpForward), damit nur autorisierte VMs die IP-Weiterleitung aktivieren können.
- 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.
  - Richten Sie Firewallregeln für ausgehenden Traffic ein, um ausgehenden Traffic nur von den VMs zu einem bestimmten IP-Adressbereich zuzulassen, bei denen die IP-Weiterleitung aktiviert ist.