Google PCNE: Private Connectiviteit naar Google en Beheerde Services — Studiegids

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

Onderdeel van de Google Professional Cloud Network Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Privéconnectiviteit met Google en beheerde services omvat patronen waarmee workloads kunnen communiceren met Google API’s, door Google beheerde producer-netwerken en services van derden zonder openbare IP’s te gebruiken. De doelen zijn het risico op data-exfiltratie te verminderen, compliance te vereenvoudigen en de voorspelbaarheid te verbeteren door verkeer via privépaden te leiden. De kernbouwstenen zijn onder andere Private Google Access (en restricted endpoints), Private Services Access (voor privé-IP’s naar door Google beheerde services), Private Service Connect (voor het publiceren en gebruiken van private services door producers en consumers, inclusief Google API’s), VPC Service Controls (data-perimeters), Cloud NAT (privé uitgaand verkeer naar het openbare internet) en DNS-mapping voor deterministische endpoint-selectie.

Het succes van het ontwerp hangt af van drie beslissingen:

Welk privétoegangsmechanisme past bij het service- en beveiligingsmodel (PGA vs. PSC voor Google API’s, PSA vs. PSC voor beheerde of partnerdiensten).
Hoe DNS servicenamen moet omzetten naar privé-targets zonder niet-ondersteunde services te verstoren.
Hoe routering en perimeterbeleid op elkaar inwerken zodat verkeer end-to-end privé blijft bij storingen of wijzigingen.

Foutscenario’s komen vaak voort uit routekeuze, DNS-volgorde, de regionale scope van endpoints of perimeterregels die ongemerkt aanroepen weigeren. Valideer elke laag: naamresolutie, route, firewall, endpoint-status en servicebeleid.

Private Google Access, restricted endpoints en endpoint-selectie

Private Google Access (PGA) stelt VM’s en GKE-nodes zonder externe IP’s in staat om Google API’s en services te bereiken via de Google anycast VIP’s over de standaard internetgateway van de VPC, niet via Cloud NAT. Dit wordt per subnet ingeschakeld.

Endpoints:
- private.googleapis.com (199.36.153.8/30): het volledige oppervlak van Google API’s.
- restricted.googleapis.com (199.36.153.4/30): een subset van API’s die compatibel zijn met VPC Service Controls. Gebruik dit wanneer u serviceperimeters afdwingt.
Benaderingen voor DNS-mapping:
- Behoud de standaard openbare namen en laat clients openbare DNS gebruiken. Dit werkt als u uitgaand verkeer via Cloud NAT toestaat, maar het verzwakt de controles op data-exfiltratie.
- Overschrijf specifieke API-hostnamen in een private zone van Cloud DNS voor googleapis.com met CNAME’s naar restricted.googleapis.com (of private.googleapis.com) om privéresolutie per service af te dwingen. Voorbeeld: maak een private zone googleapis.com aan en voeg storage.googleapis.com CNAME restricted.googleapis.com toe.
Overwegingen voor routering:
- PGA vereist een route naar de standaard internetgateway. Als u 0.0.0.0/0 naar een NGFW van een derde partij stuurt, voeg dan expliciete hostroutes toe zodat de Google API VIP’s de standaard internetgateway gebruiken:

undefined

Foutscenario: als deze hostroutes ontbreken, kunnen instances zonder externe IP’s de API’s niet bereiken wanneer een 0.0.0.0/0 next-hop een firewall-instance is.
Subnetconfiguratie:

undefined

Afwegingen:

restricted.googleapis.com vermindert het risico op exfiltratie, maar sommige API’s zijn niet beschikbaar.
PGA-verkeer omzeilt Cloud NAT, dus het zal niet in NAT-logging verschijnen. Gebruik VPC Flow Logs op het subnet.

Voor on-premise clients kunt u privétoegang tot Google API’s bieden door 199.36.153.4/30 en/of 199.36.153.8/30 te adverteren naar on-premise via Cloud VPN/Interconnect met de standaard internetgateway in de VPC als next hop, of door PSC-endpoints (zie hieronder) beschikbaar te stellen en on-premise DNS naar die endpoints te mappen.

Private Services Access en Private Service Connect

Private Services Access (PSA) biedt private IP-connectiviteit aan door Google beheerde producer-netwerken die services hosten zoals Cloud SQL (privaat IP) en Memorystore. U wijst een RFC1918-reeks in uw VPC toe die Google kan gebruiken en brengt een peering-verbinding tot stand met het service-producer-netwerk.

Installatiepatroon:
- Reserveer een adresbereik voor VPC-peering:

undefined

Breng de private verbinding tot stand:

undefined

Provisioneer de beheerde service met een privaat IP-adres.
Operationele opmerkingen:
- Het bereik moet groot genoeg zijn voor alle instances en mag niet overlappen met bestaande bereiken.
- De peering is niet transitief; verkeer moet afkomstig zijn van de gepeerde VPC (on-prem kan via de VPC bereiken als de routering dit toestaat).
- Het later wijzigen of verkleinen van het bereik is storend; plan de capaciteit.

Private Service Connect (PSC) breidt private connectiviteit uit naar:

Google API’s (de consument maakt endpoints met private IP’s in een subnet, en DNS koppelt API-namen aan die IP’s).
Partner- en SaaS-services die via service attachments worden gepubliceerd.
Uw eigen services die privaat worden gepubliceerd naar andere projecten of organisaties via service attachments.

Producer-consumer-model:

De producer publiceert een service attachment in een regio, ondersteund door een interne load balancer. De producer kan allowlists voor consumentenprojecten/-organisaties vereisen en verbindingsquota’s specificeren.
De consument maakt een PSC-endpoint (forwarding rule) in dezelfde regio, gericht op de service attachment van de producer. Het endpoint krijgt een IP-adres uit het gekozen subnet.

Ontwerpbeperkingen en afwegingen:

PSC is regionaal; implementeer per regio dicht bij de consumenten. Gebruik DNS-beleid of gewogen records om nabije clients te sturen en failover te bieden.
Er is geen transitiviteit via PSC; consumenten kunnen geen services aan elkaar koppelen via een endpoint.
Het bron-IP-adres wordt niet end-to-end behouden over PSC; ontwerp controles aan de producer-zijde met dit in gedachten (bijvoorbeeld, vertrouw op identiteit of autorisatie op applicatieniveau).

Veelvoorkomende faalscenario’s:

Falende health checks van de producer ILB zorgen ervoor dat PSC-verbindingen worden geweigerd.
Consumenten-endpoint aangemaakt in een andere regio dan de service attachment.
Een deny-beleid van de producer of een ontbrekende project-allowlist blokkeert verbindingen.
DNS wijst niet naar het IP-adres van het endpoint, of overlappende private zones lossen op naar de verkeerde bestemming.

VPC Service Controls, perimeters, ingress/egress en DNS-mapping

VPC Service Controls (VPC-SC) definiëren serviceperimeters rond door Google beheerde resources om data-exfiltratie te beperken. Binnen een perimeter moeten verzoeken naar beschermde services afkomstig zijn van projecten die binnen de scope vallen en voldoen aan eventueel geconfigureerde toegangsniveaus.

Perimeters:
- Standaard perimeters beschermen projecten die data hosten (bijvoorbeeld BigQuery, Cloud Storage).
- Perimeter bridges maken beperkte interactie mogelijk tussen anders geïsoleerde perimeters.
- Ingress-regels verlenen specifieke toegang van buiten de perimeter (bijvoorbeeld vanuit CI/CD- of monitoringprojecten).
- Egress-regels beperken welke externe services of projecten binnen Google Cloud kunnen worden aangeroepen.
Endpointselectie:
- Gebruik restricted.googleapis.com om API-aanroepen te beperken tot VPC-SC-compatibele services en om onbedoelde aanroepen naar publieke endpoints die niet perimeter-bewust zijn te vermijden.
- PSC voor Google API’s biedt sterkere controle door verkeer op private IP’s te houden en regionale affiniteit mogelijk te maken, maar vereist nog steeds perimeterconfiguratie voor autorisatie.
DNS en naamgeving:
- Implementeer split-horizon DNS met Cloud DNS private zones zodat interne clients API-namen omzetten naar private doelen.
- Geef de voorkeur aan per-service records of CNAMEs naar restricted.googleapis.com in plaats van een wildcard voor heel googleapis.com, wat services die publiek moeten blijven kan verstoren.
- Publiceer voor PSC A-records die naar het IP-adres van elk endpoint wijzen. Gebruik afzonderlijke zones per omgeving om onbedoeld cross-environment verbruik te voorkomen.

Valkuilen:

Het gebruik van Cloud NAT om het publieke googleapis.com te bereiken kan de intentie van VPC-SC omzeilen, tenzij perimeterregels de egress expliciet beperken; koppel NAT aan restricted DNS of PSC.
Sommige API’s hebben meerdere hostnamen (bijvoorbeeld JSON- versus XML-endpoints); zorg ervoor dat uw DNS-mapping alle namen dekt die uw clients gebruiken.
Een onjuiste perimeterconfiguratie faalt gesloten (fail-closed); monitor Access Transparency en VPC-SC-logs om weigeringen te detecteren.

Uitgaande patronen, hybride toegang en probleemoplossing

Uitgaande patronen voor private workloads:

Alleen Google API’s: Schakel PGA in en map DNS naar restricted.googleapis.com, of implementeer PSC voor Google API’s en map DNS naar de IP-adressen van de endpoints.
Internet en SaaS: Gebruik Cloud NAT voor instances zonder externe IP-adressen. Dimensioner NAT voor piekbelasting van gelijktijdige verbindingen en poorten; monitor op poortuitputting.
Mix met een NGFW van derden: Behoud de NGFW als standaard, maar voeg specifieke host routes toe naar de Google API anycast VIP’s om te zorgen dat PGA de firewall omzeilt. Stuur verkeer voor niet-Google bestemmingen naar de NGFW of Cloud NAT volgens het beleid.

Hybride clients (on-premise of andere clouds):

Om Google API’s privé te gebruiken:
- Optie A: Private Google Access voor on-premise door 199.36.153.4/30 en/of 199.36.153.8/30 te adverteren vanaf Cloud Router naar on-premise met de standaard internetgateway in de VPC als next hop; map de on-premise DNS naar restricted/private.googleapis.com indien nodig.
- Optie B: PSC-endpoints voor Google API’s in uw VPC; stel ze beschikbaar via Cloud VPN/Interconnect door te routeren naar de IP-adressen van de endpoints en de on-premise DNS dienovereenkomstig te mappen.
Om Google-beheerde services met privé IP-adressen (via PSA) te bereiken, breng connectiviteit met de VPC tot stand (Cloud VPN/Interconnect), zorg ervoor dat RFC1918-reeksen niet overlappen, propageer routes en sta firewallregels toe.

Probleemoplossing en verificatie:

DNS: Gebruik dig of nslookup op de API-hostnaam vanaf een client en verifieer dat deze wordt omgezet naar het beoogde privéadres (PSC-endpoint IP) of naar de restricted/private anycast VIP’s. Controleer de volgorde van het Cloud DNS-beleid en de private zones op de VPC.
Routing: Gebruik gcloud compute routes list en bevestig dat de meest specifieke route overeenkomt met de beoogde next hop (standaard internetgateway voor PGA VIP’s, intern voor PSC).
Firewall: Verifieer dat uitgaande regels TCP 443 naar de doel-IP’s toestaan. Voor load-balanced producers achter PSC, verifieer dat de bronbereiken voor health checks zijn toegestaan.
PGA: Bevestig dat de subnet-instelling is ingeschakeld en dat er host routes voor 199.36.153.4/30 en/of 199.36.153.8/30 bestaan als er een aangepaste standaardroute is ingesteld.
PSA: Gebruik gcloud services vpc-peerings list om te bevestigen dat de servicenetworking-peering ACTIVE is en dat het toegewezen bereik correct is en nergens anders wordt gebruikt.
PSC: Beschrijf aan de consumer-kant het endpoint om de verbindingsstatus te zien; controleer aan de producer-kant op wachtende of geweigerde verbindingen en de gezondheid van de ILB. Verifieer de consumer-allowlist van de service attachment.
Cloud NAT: Gebruik NAT-logging en -metrics om vertalingen te bevestigen en controleer op poorttoewijzing of -uitputting. Als een instance een extern IP-adres heeft, omzeilt deze per ontwerp de NAT.

Praktisch Probleemscenario

Contoso Research voert analyses uit in twee regio’s (us-east1, europe-west1). Beveiligingseisen schrijven voor dat geen enkele VM een publiek IP-adres mag hebben, Google API’s privé bereikbaar moeten zijn en onder VPC Service Controls vallen, on-premise gebruikers privétoegang nodig hebben tot een Cloud SQL-instance (privé IP), en de SaaS van een partner privé moet worden gebruikt. Een NGFW van derden is de standaard next hop voor uitgaand verkeer.

Schakel Private Google Access en restricted endpoints in

Actie: Schakel Private Google Access in op alle analytics-subnetten. Maak Cloud DNS private zones voor googleapis.com en voeg CNAME’s toe voor de vereiste API’s (BigQuery, Pub/Sub, Cloud Storage) naar restricted.googleapis.com. Voeg host routes voor 199.36.153.4/30 toe naar de standaard internetgateway in beide regio’s.
Reden: Zorgt ervoor dat VM-naar-API-verkeer privé blijft, compatibel is met VPC-SC en de NGFW omzeilt zonder brede internet-egress te creëren.

Maak een VPC Service Controls-perimeter

Actie: Plaats analytics-projecten en dataprojecten binnen een serviceperimeter. Voeg indien nodig access levels toe voor de bedrijfsnetwerken van Contoso en sta expliciet de vereiste inter-projectstromen toe via ingress-regels. Vermijd perimeter-bridges, tenzij strikt gerechtvaardigd.
Reden: Vermindert het risico op data-exfiltratie vanuit Google-beheerde services en sluit aan bij het gebruik van restricted endpoints.

Provisioneer Cloud SQL met Private Services Access

Actie: Wijs een /24 toe voor PSA, verbind servicenetworking en maak een Cloud SQL-instance met een privé IP-adres in us-east1. Propageer VPC-routes naar on-premise via Interconnect en sta firewallregels toe.
Reden: Biedt privé RFC1918-bereikbaarheid vanaf zowel VPC-workloads als on-premise clients zonder publieke blootstelling.

Bied on-premise privétoegang tot Google API’s

Actie: Adverteer 199.36.153.4/30 vanaf Cloud Router naar on-premise, met de standaard internetgateway in de VPC als next hop. Map op de on-premise DNS dezelfde API-hostnamen naar restricted.googleapis.com.
Reden: Laat on-premise clients hetzelfde beperkte privépad gebruiken, wat zorgt voor consistente beleidshandhaving en minimale operationele variatie.

Gebruik de partner-SaaS via Private Service Connect

Actie: De partner deelt een regionale service attachment. Maak PSC-endpoints in de subnetten van us-east1 en europe-west1 die gericht zijn op de attachment. Publiceer privé A-records (saas.partner.contoso) die naar elk regionaal endpoint verwijzen; gebruik gewogen DNS om de voorkeur te geven aan regionale toegang.
Reden: Houdt SaaS-verkeer op privé IP-adressen met door de producer afgedwongen project-allowlists, verbetert de latentie via regionale affiniteit en vermijdt publieke egress.

Behoud Cloud NAT voor niet-Google internet-egress

Actie: Implementeer per regio Cloud NAT-gateways die zijn gedimensioneerd voor piekstromen. Zorg ervoor dat de standaardroute nog steeds naar de NGFW wijst, met uitzondering van de specifieke host routes voor de restricted VIP’s.
Reden: Maakt gecontroleerd uitgaand verkeer naar niet-Google bestemmingen mogelijk, terwijl het Google API-verkeer privé blijft en de NGFW centraal inzicht behoudt.

Valideer en monitor

Actie: Verifieer voor elk clienttype de DNS-resolutie, de route-selectie en de TLS-connectiviteit. Controleer VPC-SC-logs op weigeringen, NAT-logs op niet-Google egress en de PSC-verbindingsstatussen. Voeg health- en beschikbaarheidsalerts toe voor de ILB’s achter de service attachment van de partner en voor Cloud SQL.
Reden: Bevestigt dat het datapad overeenkomt met het ontwerp en brengt regressies vroegtijdig aan het licht, vooral wanneer DNS, routes of perimeters veranderen.

← Cloud DNS · Alle domeinen · Routing →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →