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 mithilfe von Regeln für ein- und ausgehenden Traffic Traffic von internen IP-Adressen in einem VPC-Netzwerk zu Dienstperimetern zulassen.

Übersicht

Mit VPC Service Controls können Sie Bedingungen festlegen, um bestimmten IP-Adressbereichen des VPC-Netzwerk den Zugriff auf die geschützten Projekte und VPC-Netzwerke zu erlauben. Mit dieser Funktion haben Sie folgende Möglichkeiten:

Unterstützung von Bedingungen für die Grundlegende Zugriffsebene, um interne IP-Adressbereiche von VPC-Netzwerken zuzulassen.
Die Verwendung dieser Zugriffsebenenbedingungen für eingehende oder ausgehende API-Aufrufe innerhalb oder außerhalb des Dienstperimeters zulassen

Diese Funktion bietet folgende Vorteile:

Sie können in VPC Service Controls-Konfigurationen Bedingungen angeben, um den Zugriff von einer internen IP-Adresse in einem VPC-Netzwerk zuzulassen.
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 Ressourcen auf Ihrem On-Premises-Gerät konfigurieren, um nur auf bestimmte Google Cloud-Ressourcen zugreifen zu können. Sie müssen den IP-Adressbereich des Subnetzes verwenden, der mit diesen lokalen Ressourcen und dem VPC-Netzwerk der Landing Zone verknüpft ist, als Teil der Zugriffsebene.

Abbildung 1 zeigt eine Beispielkonfiguration, bei der der Zugriff auf einen bestimmten geschützten Dienst von einer autorisierten internen IP-Adresse aus zulässig ist.

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.
Außerdem gelten 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-Netzwerk im Audit-Log als __UNKNOWN__ ausgeblendet.
VPC-Netzwerke, für die SUBNET_MODE auf custom festgelegt ist, aber keine Subnetze haben, werden nicht unterstützt. Wenn Sie interne IP-Adressen aktivieren möchten, 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 eine Zugriffsebene oder ein Dienstperimeter verweist, und dann ein anderes VPC-Netzwerk mit demselben Namen neu erstellen, werden interne IP-Adressen im neu erstellten VPC-Netzwerk nicht automatisch von VPC Service Controls 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. Beispiel: Cloud SQL.
Wenn Sie eine Zugriffsebene mit internen IP-adressbasierten Bedingungen mit einer ausgehenden Regel verwenden, sollten Sie der Zugriffsebene keine weiteren Bedingungen wie Gerätetyp oder Nutzeridentität hinzufügen.
Die interne IP-Adresse stimmt nicht mit den Zugriffsebenen überein, die sich auf geografische Regionen beziehen.

Interne IP-Adresse in Zugriffsebenen verwenden

Geben Sie den Namen des VPC-Netzwerk und den IP-Adressbereich im Feld vpcNetworkSources der Bedingung für die grundlegende Zugriffsebene an.
- 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 im Feld VpcSubNetwork von VpcNetworkSource angegebene IP-Adressbereich muss der Spezifikation für das IP-Subnetz des CIDR-Blocks 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 Beispiels 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 gibt es 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.

Mit VPC Service Controls können Sie VM1 von Project1 aus nur über eine interne IP-Adresse auf den Cloud Storage-Bucket in Project2 zugreifen lassen. 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

Sie benötigen eine Zugriffsrichtlinie auf Organisationsebene. 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.
Rufen Sie den Namen Ihrer Zugriffsrichtlinie ab.
Führen Sie 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 Perimeter erstellt haben, ist der Cloud Storage-Bucket nicht mehr von den beiden VMs aus zugänglich.

Zugriffsebene mit einer internen IP-Adressenbasierten 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 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-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 oben beschriebenen Formate für IP-Adressbereiche.

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

Ingress-Richtlinie konfigurieren, um eingehenden API-Traffic zum 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 gcloud CLI-Befehl aus, um die Ingress-Richtlinie für einen Dienstperimeter zu aktualisieren:
```
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 ein- und ausgehenden Traffic für einen Dienstperimeter aktualisieren.

Ausgehende API-Traffic-Richtlinie für den Cloud Storage-Bucket konfigurieren

Konfigurieren Sie außerdem eine ausgehende Richtlinie 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 festlegen.
```
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 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 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 ein- und ausgehenden Traffic für einen Dienstperimeter aktualisieren.

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:
- Mit der Restrict VM IP Forwarding Einschränkung für die Organisationsrichtlinie (constraints/compute.vmCanIpForward) können Sie dafür 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 Eingangs-Firewallregeln 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 von den VMs zu einem bestimmten IP-Adressbereich zuzulassen, für die die IP-Weiterleitung aktiviert ist.