Google PCNE: Private Konnektivität zu Google und verwalteten Diensten — Lernleitfaden

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Private Konnektivität zu Google und verwalteten Diensten umfasst Muster, die es Workloads ermöglichen, mit Google APIs, von Google verwalteten Producer-Netzwerken und Diensten von Drittanbietern ohne öffentliche IP-Adressen zu kommunizieren. Die Ziele sind die Reduzierung des Risikos der Datenexfiltration, die Vereinfachung der Compliance und die Verbesserung der Vorhersagbarkeit, indem der Traffic auf privaten Pfaden gehalten wird. Zu den Kernbausteinen gehören Private Google Access (und eingeschränkte Endpunkte), Private Services Access (für private IPs zu von Google verwalteten Diensten), Private Service Connect (für die Veröffentlichung und Nutzung privater Dienste zwischen Producer und Consumer, einschließlich Google APIs), VPC Service Controls (für Daten-Perimeter), Cloud NAT (für privaten ausgehenden Traffic ins öffentliche Internet) und DNS-Mapping für eine deterministische Endpunktauswahl.

Der Erfolg des Designs hängt von drei Entscheidungen ab:

Welcher private Zugriffsmechanismus zum Service- und Sicherheitsmodell passt (PGA vs. PSC für Google APIs, PSA vs. PSC für verwaltete oder Partnerdienste).
Wie DNS Dienstnamen zu privaten Zielen auflösen sollte, ohne nicht unterstützte Dienste zu beeinträchtigen.
Wie Routing und Perimeter-Richtlinien interagieren, damit der Traffic auch bei Ausfällen oder Änderungen durchgängig privat bleibt.

Fehlermodi entstehen häufig durch die Routenauswahl, die DNS-Reihenfolge, den regionalen Geltungsbereich von Endpunkten oder Perimeter-Regeln, die Aufrufe unbemerkt ablehnen. Validieren Sie jede Schicht: Namensauflösung, Route, Firewall, Endpunkt-Zustand und Service-Richtlinie.

Private Google Access, eingeschränkte Endpunkte und Endpunktauswahl

Private Google Access (PGA) ermöglicht es VMs und GKE-Knoten ohne externe IP-Adressen, Google APIs und Dienste über die Anycast-VIPs von Google zu erreichen. Der Zugriff erfolgt über das Standard-Internetgateway der VPC, nicht über Cloud NAT. Er wird pro Subnetz aktiviert.

Endpunkte:
- private.googleapis.com (199.36.153.8/30): vollständige Oberfläche der Google APIs.
- restricted.googleapis.com (199.36.153.4/30): Teilmenge der APIs, die mit VPC Service Controls kompatibel sind. Verwenden Sie diesen, wenn Sie Service-Perimeter erzwingen.
Ansätze für das DNS-Mapping:
- Behalten Sie die standardmäßigen öffentlichen Namen bei und lassen Sie Clients auf öffentliches DNS zugreifen. Dies funktioniert, wenn Sie ausgehenden Traffic über Cloud NAT zulassen, schwächt aber die Kontrollen zur Datenexfiltration.
- Überschreiben Sie spezifische API-Hostnamen in einer privaten Cloud DNS-Zone für googleapis.com mit CNAMEs, die auf restricted.googleapis.com (oder private.googleapis.com) verweisen, um eine private Auflösung pro Dienst zu erzwingen. Beispiel: Erstellen Sie eine private Zone googleapis.com und fügen Sie einen CNAME-Eintrag für storage.googleapis.com hinzu, der auf restricted.googleapis.com verweist.
Überlegungen zum Routing:
- PGA erfordert eine Route zum Standard-Internetgateway. Wenn Sie 0.0.0.0/0 an eine NGFW eines Drittanbieters senden, fügen Sie explizite Host-Routen hinzu, damit die Google API VIPs das Standard-Internetgateway verwenden:

undefined

Fehlermodus: Wenn diese Host-Routen fehlen, können Instanzen ohne externe IP-Adressen die APIs nicht erreichen, wenn der Next-Hop für 0.0.0.0/0 eine Firewall-Instanz ist.
Subnetz-Konfiguration:

undefined

Abwägungen:

restricted.googleapis.com reduziert das Exfiltrationsrisiko, aber einige APIs sind nicht verfügbar.
PGA-Traffic umgeht Cloud NAT, daher wird er nicht im NAT-Logging angezeigt. Verwenden Sie VPC Flow Logs für das Subnetz.

Für On-Premises-Clients können Sie privaten Zugriff auf Google APIs bereitstellen, indem Sie entweder 199.36.153.4/30 und/oder 199.36.153.8/30 über Cloud VPN/Interconnect an die On-Premises-Umgebung ankündigen (mit dem Standard-Internetgateway in der VPC als Next-Hop) oder indem Sie PSC-Endpunkte (siehe unten) bereitstellen und das On-Premises-DNS auf diese Endpunkte verweisen.

Private Services Access und Private Service Connect

Private Services Access (PSA) bietet private IP-Konnektivität zu von Google verwalteten Producer-Netzwerken, die Dienste wie Cloud SQL (private IP) und Memorystore hosten. Sie weisen in Ihrer VPC einen RFC1918-Bereich zu, den Google verwenden kann, und stellen eine Peering-Verbindung zum Service-Producer-Netzwerk her.

Einrichtungsmuster:
- Einen Adressbereich für VPC-Peering reservieren:

undefined

Die private Verbindung herstellen:

undefined

Den verwalteten Dienst mit privater IP bereitstellen.
Betriebliche Hinweise:
- Der Bereich muss für alle Instanzen groß genug sein und darf sich nicht mit bestehenden Bereichen überschneiden.
- Das Peering ist nicht transitiv; der Datenverkehr muss aus der gepeerten VPC stammen (On-Premises-Systeme können über die VPC zugreifen, wenn das Routing dies zulässt).
- Eine spätere Änderung oder Verkleinerung des Bereichs ist störend; planen Sie die Kapazität.

Private Service Connect (PSC) erweitert die private Konnektivität auf:

Google APIs (der Consumer erstellt Endpunkte mit privaten IPs in einem Subnetz, und DNS leitet API-Namen auf diese IPs um).
Partner- und SaaS-Dienste, die über Service Attachments veröffentlicht werden.
Ihre eigenen Dienste, die privat für andere Projekte oder Organisationen über Service Attachments veröffentlicht werden.

Producer-Consumer-Modell:

Der Producer veröffentlicht ein Service Attachment in einer Region, das von einem internen Load Balancer unterstützt wird. Der Producer kann Allow-Listen für Consumer-Projekte/-Organisationen verlangen und Verbindungskontingente festlegen.
Der Consumer erstellt einen PSC-Endpunkt (Weiterleitungsregel) in derselben Region, der auf das Service Attachment des Producers abzielt. Der Endpunkt erhält eine IP aus dem gewählten Subnetz.

Design-Einschränkungen und Kompromisse:

PSC ist regional; stellen Sie es pro Region in der Nähe der Consumer bereit. Verwenden Sie DNS-Richtlinien oder gewichtete Einträge (Weighted Records), um nahegelegene Clients zu steuern und Failover bereitzustellen.
Es gibt keine Transitivität durch PSC; Consumer können Dienste nicht über einen Endpunkt verketten.
Die Quell-IP wird nicht durchgängig über PSC beibehalten; entwerfen Sie producerseitige Kontrollen unter Berücksichtigung dieses Aspekts (z. B. durch Verlassen auf Identitäts- oder anwendungsebene Autorisierung).

Häufige Fehlermodi:

Fehlschlagende Health Checks des Producer-ILB führen zur Ablehnung von PSC-Verbindungen.
Der Consumer-Endpunkt wird in einer anderen Region als das Service Attachment erstellt.
Eine Deny-Richtlinie des Producers oder eine fehlende Allow-Liste für das Projekt blockiert Verbindungen.
DNS verweist nicht auf die IP des Endpunkts, oder überlappende private Zonen lösen zum falschen Ziel auf.

VPC Service Controls, Perimeter, Ingress/Egress und DNS-Mapping

VPC Service Controls (VPC-SC) definieren Service-Perimeter um von Google verwaltete Ressourcen, um Datenexfiltration zu verhindern. Innerhalb eines Perimeters müssen Anfragen an geschützte Dienste von Projekten innerhalb des Geltungsbereichs stammen und alle konfigurierten Zugriffsebenen (Access Levels) erfüllen.

Perimeter:
- Standard-Perimeter schützen Projekte, die Daten hosten (z. B. BigQuery, Cloud Storage).
- Perimeter-Brücken (Perimeter Bridges) ermöglichen eine begrenzte Interaktion zwischen ansonsten isolierten Perimetern.
- Ingress-Regeln gewähren spezifischen Zugriff von außerhalb des Perimeters (z. B. von CI/CD- oder Monitoring-Projekten).
- Egress-Regeln beschränken, welche externen Dienste oder Projekte innerhalb von Google Cloud aufgerufen werden können.
Endpunktauswahl:
- Verwenden Sie restricted.googleapis.com, um API-Aufrufe auf VPC-SC-kompatible Dienste zu beschränken und versehentliche Aufrufe an öffentliche Endpunkte zu vermeiden, die nicht perimeterfähig sind.
- PSC für Google APIs bietet eine stärkere Kontrolle, indem der Datenverkehr auf privaten IPs gehalten und regionale Affinität ermöglicht wird, erfordert aber dennoch eine Perimeter-Konfiguration für die Autorisierung.
DNS und Namensgebung:
- Implementieren Sie Split-Horizon-DNS mit privaten Zonen von Cloud DNS, damit interne Clients API-Namen zu privaten Zielen auflösen.
- Bevorzugen Sie pro-Dienst-Einträge oder CNAMEs zu restricted.googleapis.com anstelle eines Wildcards für ganz googleapis.com, da dies Dienste beeinträchtigen kann, die öffentlich bleiben müssen.
- Veröffentlichen Sie für PSC A-Records, die auf die IP jedes Endpunkts verweisen. Verwenden Sie separate Zonen pro Umgebung, um eine versehentliche umgebungsübergreifende Nutzung zu verhindern.

Fallstricke:

Die Verwendung von Cloud NAT zum Erreichen des öffentlichen googleapis.com kann die Absicht von VPC-SC umgehen, es sei denn, Perimeter-Regeln schränken den Egress explizit ein; kombinieren Sie NAT mit eingeschränktem DNS oder PSC.
Einige APIs haben mehrere Hostnamen (z. B. JSON- vs. XML-Endpunkte); stellen Sie sicher, dass Ihr DNS-Mapping alle Namen abdeckt, die Ihre Clients verwenden.
Eine Fehlkonfiguration des Perimeters führt zu einem Fail-Closed-Verhalten; überwachen Sie Access Transparency- und VPC-SC-Logs, um Ablehnungen zu erkennen.

Muster für ausgehenden Traffic, hybrider Zugriff und Fehlerbehebung

Muster für ausgehenden Traffic für private Workloads:

Nur Google APIs: Aktivieren Sie PGA und mappen Sie DNS auf restricted.googleapis.com, oder stellen Sie PSC für Google APIs bereit und mappen Sie DNS auf die Endpunkt-IPs.
Internet und SaaS: Verwenden Sie Cloud NAT für Instanzen ohne externe IPs. Dimensionieren Sie NAT für die maximale Anzahl gleichzeitiger Verbindungen und Ports; überwachen Sie auf Port-Erschöpfung.
Mischung mit einer Drittanbieter-NGFW: Behalten Sie die NGFW als Standard bei, aber fügen Sie spezifische Host-Routen zu den Google API Anycast-VIPs hinzu, um sicherzustellen, dass PGA die Firewall umgeht. Senden Sie Traffic für Nicht-Google-Ziele je nach Richtlinie an die NGFW oder Cloud NAT.

Hybride Clients (On-Premises oder andere Clouds):

Um Google APIs privat zu nutzen:
- Option A: Privater Google-Zugriff für On-Premises, indem 199.36.153.4/30 und/oder 199.36.153.8/30 von Cloud Router an On-Premises angekündigt wird, mit dem standardmäßigen Internet-Gateway in der VPC als Next Hop; mappen Sie das On-Premises-DNS bei Bedarf auf restricted/private.googleapis.com.
- Option B: PSC-Endpunkte für Google APIs in Ihrer VPC; stellen Sie diese über Cloud VPN/Interconnect bereit, indem Sie den Traffic zu den Endpunkt-IPs routen und das On-Premises-DNS entsprechend mappen.
Um von Google verwaltete Dienste mit privaten IPs (über PSA) zu erreichen, stellen Sie Konnektivität zur VPC her (Cloud VPN/Interconnect), stellen Sie sicher, dass sich die RFC1918-Bereiche nicht überschneiden, propagieren Sie Routen und lassen Sie Firewall-Regeln zu.

Fehlerbehebung und Überprüfung:

DNS: Führen Sie von einem Client aus dig oder nslookup für den API-Hostnamen aus und überprüfen Sie, ob er zur beabsichtigten privaten Adresse (PSC-Endpunkt-IP) oder zu den Anycast-VIPs von restricted/private aufgelöst wird. Überprüfen Sie die Reihenfolge der Cloud DNS-Richtlinien und die privaten Zonen in der VPC.
Routing: Führen Sie gcloud compute routes list aus und bestätigen Sie, dass die spezifischste Route mit dem beabsichtigten Next Hop übereinstimmt (standardmäßiges Internet-Gateway für PGA-VIPs, intern für PSC).
Firewall: Überprüfen Sie, ob Egress-Regeln TCP 443 zu den Ziel-IPs zulassen. Überprüfen Sie bei Producern mit Lastausgleich hinter PSC, ob die Quellbereiche der Systemdiagnosen (Health Checks) zulässig sind.
PGA: Bestätigen Sie, dass die Subnetzeinstellung aktiviert ist und dass Host-Routen für 199.36.153.4/30 und/oder 199.36.153.8/30 existieren, falls eine benutzerdefinierte Standardroute vorhanden ist.
PSA: Führen Sie gcloud services vpc-peerings list aus, um zu bestätigen, dass das servicenetworking-Peering AKTIV ist und der zugewiesene Bereich korrekt ist und nirgendwo anders verwendet wird.
PSC: Beschreiben Sie auf der Consumer-Seite den Endpunkt, um den Verbindungsstatus zu sehen; überprüfen Sie auf der Producer-Seite ausstehende oder abgelehnte Verbindungen und den Zustand des ILB. Überprüfen Sie die Consumer-Zulassungsliste des Service Attachments.
Cloud NAT: Verwenden Sie NAT-Logging und -Metriken, um Übersetzungen zu bestätigen und auf Port-Zuweisung oder -Erschöpfung zu prüfen. Wenn eine Instanz eine externe IP hat, umgeht sie NAT absichtlich (by design).

Praktisches Problemszenario

Contoso Research führt Analysen in zwei Regionen durch (us‑east1, europe‑west1). Sicherheitsvorgaben schreiben vor, dass keine VM eine öffentliche IP-Adresse haben darf, Google APIs privat und unter der Kontrolle von VPC Service Controls erreichbar sein müssen, On-Premises-Benutzer privaten Zugriff auf eine Cloud SQL-Instanz (mit privater IP) benötigen und ein SaaS eines Partners privat genutzt werden muss. Eine Drittanbieter-NGFW ist der standardmäßige Next Hop für ausgehenden Traffic.

Privaten Google-Zugriff und eingeschränkte Endpunkte aktivieren

Aktion: Aktivieren Sie den Privaten Google-Zugriff in allen Analyse-Subnetzen. Erstellen Sie private Cloud DNS-Zonen für googleapis.com und fügen Sie CNAMEs für die erforderlichen APIs (BigQuery, Pub/Sub, Cloud Storage) hinzu, die auf restricted.googleapis.com verweisen. Fügen Sie in beiden Regionen Host-Routen für 199.36.153.4/30 zum standardmäßigen Internet-Gateway hinzu.
Begründung: Stellt sicher, dass der Traffic von VM zu API privat bleibt, mit VPC-SC kompatibel ist und die NGFW umgeht, ohne einen breiten Internet-Egress zu schaffen.

VPC Service Controls Perimeter erstellen

Aktion: Platzieren Sie Analyse- und Datenprojekte innerhalb eines Service Perimeters. Fügen Sie bei Bedarf Zugriffsebenen für die Unternehmensnetzwerke von Contoso hinzu und erlauben Sie explizit erforderliche projektübergreifende Flüsse über Ingress-Regeln. Vermeiden Sie Perimeter-Bridges, außer wenn sie streng begründet sind.
Begründung: Reduziert das Risiko der Datenexfiltration aus von Google verwalteten Diensten und steht im Einklang mit der Verwendung eingeschränkter Endpunkte.

Cloud SQL mit Private Services Access bereitstellen

Aktion: Weisen Sie einen /24-Bereich für PSA zu, verbinden Sie servicenetworking und erstellen Sie eine Cloud SQL-Instanz mit privater IP in us-east1. Propagieren Sie VPC-Routen über Interconnect an On-Premises und lassen Sie Firewall-Regeln zu.
Begründung: Bietet private RFC1918-Erreichbarkeit sowohl von VPC-Workloads als auch von On-Premises-Clients ohne öffentliche Exposition.

Privaten On-Premises-Zugriff auf Google APIs bereitstellen

Aktion: Kündigen Sie 199.36.153.4/30 von Cloud Router an On-Premises an, mit dem standardmäßigen Internet-Gateway in der VPC als Next Hop. Mappen Sie im On-Premises-DNS dieselben API-Hostnamen auf restricted.googleapis.com.
Begründung: Ermöglicht On-Premises-Clients, denselben eingeschränkten privaten Pfad zu verwenden, was eine konsistente Durchsetzung von Richtlinien gewährleistet und die betriebliche Varianz minimiert.

Das Partner-SaaS über Private Service Connect nutzen

Aktion: Der Partner teilt ein regionales Service Attachment. Erstellen Sie PSC-Endpunkte in den Subnetzen von us-east1 und europe-west1, die auf das Attachment abzielen. Veröffentlichen Sie private A-Records (saas.partner.contoso), die auf den jeweiligen regionalen Endpunkt verweisen; verwenden Sie gewichtetes DNS, um den regionalen Zugriff zu bevorzugen.
Begründung: Hält den SaaS-Traffic auf privaten IPs mit vom Producer durchgesetzten Projekt-Zulassungslisten, verbessert die Latenz durch regionale Affinität und vermeidet öffentlichen Egress.

Cloud NAT für Nicht-Google-Internet-Egress beibehalten

Aktion: Stellen Sie pro Region Cloud NAT-Gateways bereit, die für Spitzenlasten dimensioniert sind. Stellen Sie sicher, dass die Standardroute weiterhin auf die NGFW zeigt, mit Ausnahme der spezifischen Host-Routen für die eingeschränkten VIPs.
Begründung: Ermöglicht kontrollierten ausgehenden Traffic zu Nicht-Google-Zielen, während sichergestellt wird, dass der Google-API-Traffic privat bleibt und die NGFW die zentrale Sichtbarkeit beibehält.

Validieren und überwachen

Aktion: Überprüfen Sie für jeden Client-Typ die DNS-Auflösung, die Routenauswahl und die TLS-Konnektivität. Überprüfen Sie die VPC-SC-Logs auf Ablehnungen, die NAT-Logs auf Nicht-Google-Egress und die PSC-Verbindungsstatus. Fügen Sie Zustands- und Verfügbarkeitswarnungen für die ILBs hinter dem Service Attachment des Partners und für Cloud SQL hinzu.
Begründung: Bestätigt, dass der Datenpfad der Entwurfsabsicht entspricht, und deckt Regressionen frühzeitig auf, insbesondere bei Änderungen an DNS, Routen oder Perimetern.

← Cloud DNS · Alle Domänen · Routing →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →