Google PCNE: Connettività privata a Google e ai servizi gestiti — Guida allo studio

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

Fa parte della Google Professional Cloud Network Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La connettività privata a Google e ai servizi gestiti comprende pattern che consentono ai workload di comunicare con le API di Google, le reti producer gestite da Google e i servizi di terze parti senza utilizzare IP pubblici. Gli obiettivi sono ridurre il rischio di esfiltrazione dei dati, semplificare la compliance e migliorare la prevedibilità mantenendo il traffico su percorsi privati. I componenti fondamentali includono Private Google Access (e gli endpoint ristretti), Private Services Access (per IP privati verso servizi gestiti da Google), Private Service Connect (per la pubblicazione e l’utilizzo di servizi privati in modalità producer-consumer, incluse le API di Google), VPC Service Controls (per la creazione di perimetri di dati), Cloud NAT (per il traffico in uscita privato verso l’internet pubblico) e la mappatura DNS per una selezione deterministica degli endpoint.

Il successo della progettazione dipende da tre decisioni:

Quale meccanismo di accesso privato si adatta al servizio e al modello di sicurezza (PGA vs PSC per le API di Google, PSA vs PSC per i servizi gestiti o dei partner).
Come il DNS dovrebbe risolvere i nomi dei servizi verso target privati senza interrompere il funzionamento dei servizi non supportati.
Come interagiscono le policy di routing e di perimetro affinché il traffico rimanga privato end-to-end in caso di guasto o modifica.

Le modalità di guasto derivano comunemente dalla selezione della rotta, dall’ordine

Private Services Access e Private Service Connect

Private Services Access (PSA) fornisce connettività IP privata a reti producer gestite da Google che ospitano servizi come Cloud SQL (con IP privato) e Memorystore. Si alloca un intervallo di indirizzi RFC1918 nel proprio VPC affinché Google possa utilizzarlo e si stabilisce una connessione di peering con la rete del service producer.

Schema di configurazione:
- Riserva un intervallo di indirizzi per il VPC peering: gcloud compute addresses create google-managed-services-range
  –global –purpose=VPC_PEERING –prefix-length=24 –network=VPC
- Stabilisci la connessione privata: gcloud services vpc-peerings connect
  –service=servicenetworking.googleapis.com –network=VPC
  –ranges=google-managed-services-range
- Esegui il provisioning del servizio gestito con IP privato.
Note operative:
- L’intervallo deve essere sufficientemente ampio per tutte le istanze e non deve sovrapporsi a intervalli esistenti.
- Il peering non è transitivo; il traffico deve originare dal VPC in peering (le risorse on-premise possono raggiungerlo attraverso il VPC se il routing lo consente).
- Modificare o ridurre l’intervallo in un secondo momento causa interruzioni; pianificare la capacità.

Private Service Connect (PSC) estende la connettività privata a:

API di Google (il consumer crea endpoint con IP privati in una subnet e il DNS mappa i nomi delle API a tali IP).
Servizi di partner e SaaS pubblicati tramite service attachment.
I propri servizi pubblicati privatamente per altri progetti o organizzazioni tramite service attachment.

Modello producer-consumer:

Il producer pubblica un service attachment in una region, supportato da un internal load balancer. Il producer può richiedere allowlist di progetti/organizzazioni consumer e specificare quote di connessione.
Il consumer crea un endpoint PSC (regola di forwarding) nella stessa region, che punta al service attachment del producer. L’endpoint ottiene un IP dalla subnet scelta.

Vincoli di progettazione e compromessi:

PSC è regionale; effettuare il deploy per region vicino ai consumer. Utilizzare policy DNS o record ponderati per indirizzare i client vicini e fornire failover.
Non c’è transitività attraverso PSC; i consumer non possono concatenare servizi tramite un endpoint.
L’IP di origine non viene preservato end-to-end attraverso PSC; progettare i controlli lato producer tenendo conto di questo (ad esempio, basandosi sull’identità o sull’autorizzazione a livello di applicazione).

Modalità di fallimento comuni:

Il fallimento degli health check dell’ILB del producer causa il rifiuto delle connessioni PSC.
Endpoint del consumer creato in una region diversa da quella del service attachment.
Una deny policy del producer o una allowlist di progetto mancante bloccano le connessioni.
Il DNS non punta all’IP dell’endpoint, o zone private sovrapposte risolvono verso la destinazione sbagliata.

VPC Service Controls, perimetri, regole di ingresso/uscita e mappatura DNS

VPC Service Controls (VPC-SC) definisce perimetri di servizio attorno alle risorse gestite da Google per mitigare l’esfiltrazione di dati. All’interno di un perimetro, le richieste ai servizi protetti devono provenire da progetti inclusi nell’ambito (in-scope) e soddisfare eventuali livelli di accesso configurati.

Perimetri:
- I perimetri standard proteggono i progetti che ospitano dati (ad esempio, BigQuery, Cloud Storage).
- I perimeter bridge consentono un’interazione limitata tra perimetri altrimenti isolati.
- Le regole di ingresso (ingress) concedono un accesso specifico dall’esterno del perimetro (ad esempio, da progetti di CI/CD o monitoraggio).
- Le regole di uscita (egress) limitano quali servizi esterni o progetti all’interno di Google Cloud possono essere chiamati.
Selezione dell’endpoint:
- Utilizzare restricted.googleapis.com per limitare le chiamate API ai servizi compatibili con VPC-SC ed evitare chiamate accidentali a endpoint pubblici che non sono consapevoli del perimetro (perimeter-aware).
- PSC per le API di Google offre un controllo più forte mantenendo il traffico su IP privati e abilitando l’affinità regionale, ma richiede comunque la configurazione del perimetro per l’autorizzazione.
DNS e naming:
- Implementare uno split-horizon DNS con le zone private di Cloud DNS in modo che i client interni risolvano i nomi delle API in destinazioni private.
- Preferire record per servizio o CNAME a restricted.googleapis.com piuttosto che usare un wildcard per tutto googleapis.com, il che può interrompere servizi che devono rimanere pubblici.
- Per PSC, pubblicare record A che puntano all’IP di ciascun endpoint. Utilizzare zone separate per ogni ambiente per prevenire un consumo accidentale tra ambienti diversi (cross-env).

Potenziali problemi:

L’uso di Cloud NAT per raggiungere il googleapis.com pubblico può eludere l’intento di VPC-SC a meno che le regole del perimetro non limitino esplicitamente l’uscita (egress); abbinare NAT con DNS ristretto o PSC.
Alcune API hanno più hostname (ad esempio, endpoint JSON vs XML); assicurarsi che la mappatura DNS copra tutti i nomi utilizzati dai client.
Una configurazione errata del perimetro causa un blocco (fail-closed); monitorare i log di Access Transparency e VPC-SC per rilevare i rifiuti di accesso.

Pattern di outbound, accesso ibrido e risoluzione dei problemi

Pattern di outbound per workload privati:

Solo API di Google: abilitare PGA e mappare il DNS a restricted.googleapis.com, oppure distribuire PSC per le API di Google e mappare il DNS agli IP degli endpoint.
Internet e SaaS: utilizzare Cloud NAT per le istanze senza IP esterni. Dimensionare il NAT per il picco di connessioni e porte simultanee; monitorare l’esaurimento delle porte.
Combinazione con un NGFW di terze parti: mantenere l’NGFW come predefinito, ma aggiungere route host specifiche ai VIP anycast delle API di Google per garantire che PGA bypassi il firewall. Per le destinazioni non-Google, inviare il traffico all’NGFW o a Cloud NAT in base alla policy.

Client ibridi (on-premise o altri cloud):

Per utilizzare le API di Google in modo privato:
- Opzione A: Private Google Access per l’on-premise annunciando 199.36.153.4/30 e/o 199.36.153.8/30 da Cloud Router verso l’on-premise con next hop il gateway internet predefinito nel VPC; mappare il DNS on-premise a restricted/private.googleapis.com secondo necessità.
- Opzione B: endpoint PSC per le API di Google nel proprio VPC; esporli tramite Cloud VPN/Interconnect instradando il traffico verso gli IP degli endpoint e mappando il DNS on-premise di conseguenza.
Per raggiungere i servizi gestiti da Google con IP privati (tramite PSA), stabilire la connettività al VPC (Cloud VPN/Interconnect), assicurarsi che gli intervalli RFC1918 non si sovrappongano, propagare le route e consentire le regole del firewall.

Risoluzione dei problemi e verifica:

DNS: eseguire dig o nslookup sull’hostname dell’API da un client e verificare che si risolva nell’indirizzo privato previsto (IP dell’endpoint PSC) o nei VIP anycast restricted/private. Controllare l’ordine delle policy di Cloud DNS e le zone private sul VPC.
Routing: eseguire

undefined

e confermare che la route più specifica corrisponda al next hop previsto (gateway internet predefinito per i VIP di PGA, interno per PSC).

Firewall: verificare che le regole di egress consentano TCP 443 verso gli IP di destinazione. Per i producer con bilanciamento del carico dietro a PSC, verificare che gli intervalli di origine degli health check siano consentiti.
PGA: confermare che l’impostazione della subnet sia abilitata e che esistano route host per 199.36.153.4/30 e/o 199.36.153.8/30 se è presente una route predefinita personalizzata.
PSA: eseguire

undefined

per confermare che il peering servicenetworking sia ACTIVE e che l’intervallo allocato sia corretto e non utilizzato altrove.

PSC: sul consumer, descrivere l’endpoint per vedere lo stato della connessione; sul producer, controllare le connessioni in sospeso o rifiutate e lo stato di salute dell’ILB. Verificare la allowlist dei consumer dell’allegato di servizio (service attachment).
Cloud NAT: utilizzare i log e le metriche di NAT per confermare le traduzioni e verificare l’allocazione o l’esaurimento delle porte. Se un’istanza ha un IP esterno, per design bypassa il NAT.

Scenario pratico

Contoso Research esegue analisi in due region (us-east1, europe-west1). Le policy di sicurezza impongono che nessuna VM abbia un IP pubblico, che le API di Google siano raggiungibili privatamente e soggette a VPC Service Controls, che gli utenti on-premise necessitino di accesso privato a un’istanza Cloud SQL (con IP privato) e che un SaaS di un partner debba essere utilizzato privatamente. Un NGFW di terze parti è il next hop di egress predefinito.

Abilitare Private Google Access e gli endpoint restricted

Azione: abilitare Private Google Access su tutte le subnet di analisi. Creare zone private di Cloud DNS per googleapis.com e aggiungere record CNAME per le API richieste (BigQuery, Pub/Sub, Cloud Storage) che puntano a restricted.googleapis.com. Aggiungere route host per 199.36.153.4/30 verso il gateway internet predefinito in entrambe le region.
Motivazione: garantisce che il traffico da VM ad API rimanga privato, sia compatibile con VPC-SC e bypassi l’NGFW senza creare un’ampia via di egress verso internet.

Creare un perimetro VPC Service Controls

Azione: inserire i progetti di analisi e i progetti dati all’interno di un perimetro di servizio. Aggiungere livelli di accesso per le reti aziendali di Contoso secondo necessità e consentire esplicitamente i flussi tra progetti richiesti tramite regole di ingress. Evitare i bridge di perimetro tranne dove strettamente giustificato.
Motivazione: riduce il rischio di esfiltrazione di dati dai servizi gestiti da Google e si allinea con l’uso degli endpoint restricted.

Provisioning di Cloud SQL con Private Services Access

Azione: allocare un /24 per PSA, connettere servicenetworking e creare un’istanza Cloud SQL con IP privato in us-east1. Propagare le route del VPC verso l’on-premise tramite Interconnect e consentire le regole del firewall.
Motivazione: fornisce raggiungibilità privata RFC1918 sia dai workload nel VPC sia dai client on-premise senza esposizione pubblica.

Fornire accesso privato on-premise alle API di Google

Azione: annunciare 199.36.153.4/30 da Cloud Router verso l’on-premise, con next hop il gateway internet predefinito nel VPC. Sul DNS on-premise, mappare gli stessi hostname delle API a restricted.googleapis.com.
Motivazione: consente ai client on-premise di utilizzare lo stesso percorso privato restricted, garantendo un’applicazione coerente delle policy e minimizzando le variazioni operative.

Utilizzare il SaaS del partner tramite Private Service Connect

Azione: il partner condivide un allegato di servizio (service attachment) regionale. Creare endpoint PSC nelle subnet di us-east1 e europe-west1 che puntano all’allegato. Pubblicare record A privati (saas.partner.contoso) che puntano a ciascun endpoint regionale; utilizzare il DNS ponderato (weighted) per preferire l’accesso regionale.
Motivazione: mantiene il traffico SaaS su IP privati con allowlist di progetti applicate dal producer, migliora la latenza tramite l’affinità regionale ed evita l’egress pubblico.

Mantenere Cloud NAT per l’egress internet non-Google

Azione: distribuire gateway Cloud NAT per ogni region, dimensionati per i flussi di picco. Assicurarsi che la route predefinita punti ancora all’NGFW, ad eccezione delle specifiche route host per i VIP restricted.
Motivazione: consente l’outbound controllato verso destinazioni non-Google, garantendo al contempo che il traffico delle API di Google rimanga privato e che l’NGFW mantenga una visibilità centralizzata.

Convalidare e monitorare

Azione: per ogni tipo di client, verificare la risoluzione DNS, la selezione della route e la connettività TLS. Controllare i log di VPC-SC per eventuali rifiuti (denial), i log di NAT per l’egress non-Google e gli stati delle connessioni PSC. Aggiungere alert di stato e disponibilità per gli ILB dietro il service attachment del partner e per Cloud SQL.
Motivazione: conferma che il percorso dei dati corrisponda all’intento progettuale e fa emergere tempestivamente le regressioni, specialmente quando cambiano DNS, route o perimetri.

← Cloud DNS · Tutti i domini · Instradamento →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →