Google PCNE: Prywatna łączność do Google i usług zarządzanych — Przewodnik do nauki

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

Część Google Professional Cloud Network Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Prywatna łączność z Google i usługami zarządzanymi obejmuje wzorce, które pozwalają obciążeniom roboczym (workloads) komunikować się z interfejsami API Google, sieciami producentów zarządzanymi przez Google oraz usługami firm trzecich bez użycia publicznych adresów IP. Celem jest zmniejszenie ryzyka eksfiltracji danych, uproszczenie zgodności z przepisami (compliance) i poprawa przewidywalności poprzez utrzymywanie ruchu na prywatnych ścieżkach. Główne elementy składowe to Private Google Access (i punkty końcowe z ograniczeniami), Private Services Access (dla prywatnych adresów IP do usług zarządzanych przez Google), Private Service Connect (do publikowania i konsumowania prywatnych usług na linii producent-konsument, w tym interfejsów API Google), VPC Service Controls (do tworzenia perymetrów danych), Cloud NAT (dla prywatnego ruchu wychodzącego do publicznego internetu) oraz mapowanie DNS w celu deterministycznego wyboru punktu końcowego.

Powodzenie projektu zależy od trzech decyzji:

Który mechanizm dostępu prywatnego pasuje do modelu usługi i bezpieczeństwa (PGA vs PSC dla interfejsów API Google, PSA vs PSC dla usług zarządzanych lub partnerskich).
Jak system DNS powinien rozwiązywać nazwy usług na prywatne cele, nie zakłócając działania nieobsługiwanych usług.
Jak routing i polityki perymetru (perimeter policy) współdziałają, aby ruch pozostał prywatny od początku do końca (end-to-end) w przypadku awarii lub zmiany.

Tryby awarii często wynikają z wyboru trasy, kolejności zapytań DNS, regionalnego zasięgu punktów końcowych lub reguł perymetru, które po cichu odrzucają wywołania. Należy zweryfikować każdą warstwę: rozwiązywanie nazw, trasę, zaporę sieciową (firewall), stan punktu końcowego i politykę usługi.

Private Google Access, punkty końcowe z ograniczeniami i wybór punktu końcowego

Private Google Access (PGA) umożliwia maszynom wirtualnym i węzłom GKE bez zewnętrznych adresów IP dostęp do interfejsów API i usług Google przy użyciu adresów VIP anycast Google przez domyślną bramę internetową sieci VPC, a nie przez Cloud NAT. Jest on włączany dla każdej podsieci.

Punkty końcowe:
- private.googleapis.com (199.36.153.8/30): pełen zakres interfejsów API Google.
- restricted.googleapis.com (199.36.153.4/30): podzbiór interfejsów API zgodnych z VPC Service Controls. Używaj go, gdy wymuszasz perymetry usług.
Podejścia do mapowania DNS:
- Zachowaj domyślne nazwy publiczne i pozwól klientom na dostęp do publicznego DNS. Działa to, jeśli zezwalasz na ruch wychodzący (egress) przez Cloud NAT, ale osłabia to mechanizmy kontroli eksfiltracji danych.
- Nadpisz określone nazwy hostów API w prywatnej strefie Cloud DNS dla googleapis.com za pomocą rekordów CNAME wskazujących na restricted.googleapis.com (lub private.googleapis.com), aby wymusić prywatne rozwiązywanie nazw dla poszczególnych usług. Przykład: utwórz prywatną strefę googleapis.com i dodaj rekord storage.googleapis.com CNAME restricted.googleapis.com.
Kwestie związane z routingiem:
- PGA wymaga trasy do domyślnej bramy internetowej. Jeśli wysyłasz ruch 0.0.0.0/0 do zapory NGFW innej firmy, dodaj jawne trasy hosta, aby adresy VIP interfejsów API Google korzystały z domyślnej bramy internetowej:

undefined

Tryb awarii: Jeśli brakuje tych tras hosta, instancje bez zewnętrznych adresów IP nie mogą dotrzeć do interfejsów API, gdy następnym skokiem (next-hop) dla trasy 0.0.0.0/0 jest instancja zapory sieciowej.
Konfiguracja podsieci:

undefined

Kompromisy:

restricted.googleapis.com zmniejsza ryzyko eksfiltracji, ale niektóre interfejsy API są niedostępne.
Ruch PGA omija Cloud NAT, więc logi NAT go nie pokażą. Użyj VPC Flow Logs na poziomie podsieci.

Dla klientów on-premise można zapewnić prywatny dostęp do interfejsów API Google poprzez rozgłaszanie prefiksów 199.36.153.4/30 i/lub 199.36.153.8/30 do środowiska on-premise przez Cloud VPN/Interconnect z następnym skokiem (next hop) ustawionym na domyślną bramę internetową w VPC, albo przez udostępnienie punktów końcowych PSC (zobacz poniżej) i zmapowanie DNS on-premise na te punkty końcowe.

Private Services Access i Private Service Connect

Private Services Access (PSA) zapewnia prywatną łączność IP z sieciami producenta zarządzanymi przez Google, w których hostowane są usługi takie jak Cloud SQL (z prywatnym IP) i Memorystore. Alokujesz zakres RFC1918 w swojej sieci VPC do użytku przez Google i ustanawiasz połączenie peeringowe z siecią producenta usługi.

Schemat konfiguracji:
- Zarezerwuj zakres adresów dla VPC peering:

undefined

Ustanów prywatne połączenie:

undefined

Udostępnij zarządzaną usługę z prywatnym adresem IP.
Uwagi operacyjne:
- Zakres musi być wystarczająco duży dla wszystkich instancji i nie może nakładać się na istniejące zakresy.
- Peering nie jest przechodni; ruch musi pochodzić z połączonej sieci VPC (środowisko on-premise może uzyskać dostęp przez VPC, jeśli pozwala na to routing).
- Późniejsza zmiana lub zmniejszenie zakresu jest operacją zakłócającą; zaplanuj pojemność.

Private Service Connect (PSC) rozszerza prywatną łączność na:

Interfejsy API Google (konsument tworzy punkty końcowe z prywatnymi adresami IP w podsieci, a DNS mapuje nazwy API na te adresy IP).
Usługi partnerskie i SaaS publikowane za pomocą załączników usług (service attachments).
Twoje własne usługi publikowane prywatnie dla innych projektów lub organizacji za pomocą załączników usług (service attachments).

Model producent-konsument:

Producent publikuje załącznik usługi (service attachment) w regionie, obsługiwany przez wewnętrzny load balancer. Producent może wymagać list dozwolonych (allowlists) dla projektów/organizacji konsumenta i określać limity połączeń.
Konsument tworzy punkt końcowy PSC (regułę przekierowania) w tym samym regionie, wskazując na załącznik usługi producenta. Punkt końcowy otrzymuje adres IP z wybranej podsieci.

Ograniczenia projektowe i kompromisy:

PSC jest usługą regionalną; wdrażaj ją w każdym regionie blisko konsumentów. Użyj polityk DNS lub rekordów ważonych (weighted records), aby kierować pobliskich klientów i zapewnić przełączanie awaryjne (failover).
PSC nie zapewnia przechodniości; konsumenci nie mogą łączyć usług w łańcuchy przez punkt końcowy.
Źródłowy adres IP nie jest zachowywany na całej ścieżce przez PSC; projektuj mechanizmy kontroli po stronie producenta, mając to na uwadze (np. opierając się na tożsamości lub autoryzacji na poziomie aplikacji).

Typowe tryby awarii:

Błędy kontroli stanu (health checks) wewnętrznego load balancera (ILB) producenta powodują odrzucanie połączeń PSC.
Punkt końcowy konsumenta utworzony w innym regionie niż załącznik usługi.
Polityka deny producenta lub brak projektu na liście dozwolonych (allowlist) blokuje połączenia.
DNS nie wskazuje na adres IP punktu końcowego lub nakładające się strefy prywatne rozpoznają nazwę na zły cel.

VPC Service Controls, perymetry, ruch przychodzący/wychodzący i mapowanie DNS

VPC Service Controls (VPC-SC) definiują perymetry usług wokół zasobów zarządzanych przez Google w celu ograniczenia eksfiltracji danych. Wewnątrz perymetru żądania do chronionych usług muszą pochodzić z projektów objętych zakresem i spełniać wszelkie skonfigurowane poziomy dostępu.

Perymetry:
- Standardowe perymetry chronią projekty przechowujące dane (np. BigQuery, Cloud Storage).
- Mosty perymetrów (perimeter bridges) pozwalają na ograniczoną interakcję między perymetrami, które w innym przypadku byłyby odizolowane.
- Reguły wejściowe (ingress rules) przyznają określony dostęp spoza perymetru (np. z projektów CI/CD lub monitoringu).
- Reguły wyjściowe (egress rules) ograniczają, które zewnętrzne usługi lub projekty w Google Cloud mogą być wywoływane.
Wybór punktu końcowego:
- Użyj restricted.googleapis.com, aby ograniczyć wywołania API do usług kompatybilnych z VPC-SC i uniknąć przypadkowych wywołań publicznych punktów końcowych, które nie są świadome istnienia perymetru.
- PSC dla interfejsów API Google oferuje silniejszą kontrolę, utrzymując ruch na prywatnych adresach IP i umożliwiając powinowactwo regionalne, ale wciąż wymaga konfiguracji perymetru do autoryzacji.
DNS i nazewnictwo:
- Zaimplementuj DNS typu split-horizon za pomocą prywatnych stref Cloud DNS, aby wewnętrzni klienci rozpoznawali nazwy API na prywatne cele.
- Preferuj rekordy dla poszczególnych usług lub CNAME do restricted.googleapis.com zamiast używać wildcard dla całej domeny googleapis.com, co może zakłócić działanie usług, które muszą pozostać publiczne.
- Dla PSC publikuj rekordy A wskazujące na adres IP każdego punktu końcowego. Używaj oddzielnych stref dla każdego środowiska, aby zapobiec przypadkowemu korzystaniu z zasobów między środowiskami.

Pułapki:

Używanie Cloud NAT do komunikacji z publicznym googleapis.com może ominąć intencję VPC-SC, chyba że reguły perymetru jawnie ograniczają ruch wychodzący; połącz NAT z restricted DNS lub PSC.
Niektóre interfejsy API mają wiele nazw hostów (np. punkty końcowe JSON vs XML); upewnij się, że Twoje mapowanie DNS obejmuje wszystkie nazwy używane przez klientów.
Błędna konfiguracja perymetru domyślnie blokuje dostęp (fail-closed); monitoruj logi Access Transparency i VPC-SC, aby wykrywać odmowy dostępu.

Wzorce ruchu wychodzącego, dostęp hybrydowy i rozwiązywanie problemów

Wzorce ruchu wychodzącego dla prywatnych obciążeń roboczych:

Tylko interfejsy API Google: Włącz PGA i zmapuj DNS na restricted.googleapis.com lub wdróż PSC dla interfejsów API Google i zmapuj DNS na adresy IP punktów końcowych.
Internet i SaaS: Użyj Cloud NAT dla instancji bez zewnętrznych adresów IP. Dostosuj rozmiar NAT do szczytowej liczby jednoczesnych połączeń i portów; monitoruj pod kątem wyczerpania portów.
Połączenie z NGFW innej firmy: Zachowaj NGFW jako domyślną trasę, ale dodaj konkretne trasy hosta do anycastowych VIP-ów Google API, aby zapewnić, że PGA omija zaporę. W przypadku miejsc docelowych innych niż Google, wysyłaj ruch do NGFW lub Cloud NAT zgodnie z polityką.

Klienci hybrydowi (on-premise lub w innych chmurach):

Aby korzystać z interfejsów API Google prywatnie:
- Opcja A: Private Google Access dla środowisk on-premise poprzez rozgłaszanie 199.36.153.4/30 i/lub 199.36.153.8/30 z Cloud Router do on-prem z następnym skokiem (next hop) do domyślnej bramy internetowej w VPC; zmapuj DNS on-prem na restricted/private.googleapis.com w zależności od potrzeb.
- Opcja B: Punkty końcowe PSC dla interfejsów API Google w Twojej sieci VPC; udostępnij je przez Cloud VPN/Interconnect, kierując ruch do adresów IP punktów końcowych i odpowiednio mapując DNS on-prem.
Aby uzyskać dostęp do usług zarządzanych przez Google z prywatnymi adresami IP (przez PSA), ustanów łączność z VPC (Cloud VPN/Interconnect), upewnij się, że zakresy RFC1918 nie nakładają się na siebie, propaguj trasy i zezwól na odpowiednie reguły zapory sieciowej.

Rozwiązywanie problemów i weryfikacja:

DNS: użyj dig lub nslookup dla nazwy hosta API z klienta i sprawdź, czy jest ona rozwiązywana na zamierzony adres prywatny (IP punktu końcowego PSC) lub na anycastowe VIP-y restricted/private. Sprawdź kolejność polityk Cloud DNS i strefy prywatne w VPC.
Routing: użyj

undefined

i potwierdź, że najbardziej szczegółowa trasa odpowiada zamierzonemu następnemu skokowi (domyślna brama internetowa dla VIP-ów PGA, wewnętrzna dla PSC).

Firewall: Sprawdź, czy reguły ruchu wychodzącego (egress) zezwalają na TCP 443 do docelowych adresów IP. W przypadku producentów z równoważeniem obciążenia za PSC, sprawdź, czy zakresy źródłowe kontroli stanu (health check) są dozwolone.
PGA: Potwierdź, że ustawienie dla podsieci jest włączone i że istnieją trasy hosta dla 199.36.153.4/30 i/lub 199.36.153.8/30, jeśli istnieje niestandardowa trasa domyślna.
PSA: Użyj

undefined

, aby potwierdzić, że peering servicenetworking jest AKTYWNY (ACTIVE) i że przydzielony zakres jest poprawny i nie jest używany gdzie indziej.

PSC: Po stronie konsumenta opisz punkt końcowy, aby zobaczyć status połączenia; po stronie producenta sprawdź oczekujące lub odrzucone połączenia i stan ILB. Zweryfikuj listę dozwolonych konsumentów (consumer allowlist) w załączniku usługi (service attachment).
Cloud NAT: Użyj logowania i metryk NAT, aby potwierdzić translacje adresów i sprawdzić alokację lub wyczerpanie portów. Jeśli instancja ma zewnętrzny adres IP, z założenia omija NAT.

Praktyczny scenariusz problemowy

Firma Contoso Research prowadzi analitykę w dwóch regionach (us‑east1, europe‑west1). Wymogi bezpieczeństwa nakazują, aby żadna maszyna wirtualna nie miała publicznego adresu IP, interfejsy API Google muszą być dostępne prywatnie i objęte kontrolą VPC Service Controls, użytkownicy on-premise potrzebują prywatnego dostępu do instancji Cloud SQL (z prywatnym IP), a usługa SaaS partnera musi być konsumowana prywatnie. NGFW innej firmy jest domyślnym następnym skokiem dla ruchu wychodzącego.

Włącz Private Google Access i restricted endpoints

Działanie: Włącz Private Google Access we wszystkich podsieciach analitycznych. Utwórz prywatne strefy Cloud DNS dla googleapis.com i dodaj rekordy CNAME dla wymaganych interfejsów API (BigQuery, Pub/Sub, Cloud Storage) wskazujące na restricted.googleapis.com. Dodaj trasy hosta dla 199.36.153.4/30 do domyślnej bramy internetowej w obu regionach.
Uzasadnienie: Zapewnia, że ruch z maszyn wirtualnych do API pozostaje prywatny, jest zgodny z VPC‑SC i omija NGFW bez tworzenia szerokiego dostępu do internetu.

Utwórz perymetr VPC Service Controls

Działanie: Umieść projekty analityczne i projekty danych wewnątrz perymetru usług. W razie potrzeby dodaj poziomy dostępu (access levels) dla sieci korporacyjnych Contoso i jawnie zezwól na wymagane przepływy między projektami za pomocą reguł wejściowych (ingress rules). Unikaj mostów perymetru (perimeter bridges), chyba że jest to ściśle uzasadnione.
Uzasadnienie: Zmniejsza ryzyko eksfiltracji danych z usług zarządzanych przez Google i jest zgodne z użyciem restricted endpoints.

Udostępnij Cloud SQL z Private Services Access

Działanie: Przydziel zakres /24 dla PSA, połącz servicenetworking i utwórz instancję Cloud SQL z prywatnym adresem IP w us-east1. Propaguj trasy VPC do środowiska on-premise przez Interconnect i zezwól na odpowiednie reguły zapory sieciowej.
Uzasadnienie: Zapewnia prywatną osiągalność w ramach RFC1918 zarówno dla obciążeń roboczych w VPC, jak i dla klientów on-premise, bez publicznej ekspozycji.

Zapewnij prywatny dostęp on‑premise do interfejsów API Google

Działanie: Rozgłaszaj 199.36.153.4/30 z Cloud Router do środowiska on-premise, z następnym skokiem (next hop) do domyślnej bramy internetowej w VPC. W DNS on-premise zmapuj te same nazwy hostów API na restricted.googleapis.com.
Uzasadnienie: Pozwala klientom on-premise korzystać z tej samej ograniczonej ścieżki prywatnej, zapewniając spójne egzekwowanie polityk i minimalizując różnice operacyjne.

Konsumuj usługę SaaS partnera przez Private Service Connect

Działanie: Partner udostępnia regionalny załącznik usługi (service attachment). Utwórz punkty końcowe PSC w podsieciach us-east1 i europe-west1, wskazując na ten załącznik. Opublikuj prywatne rekordy A (saas.partner.contoso) wskazujące na każdy regionalny punkt końcowy; użyj ważonego DNS (weighted DNS), aby preferować dostęp regionalny.
Uzasadnienie: Utrzymuje ruch SaaS na prywatnych adresach IP z listami dozwolonych projektów (project allowlists) egzekwowanymi przez producenta, poprawia opóźnienia dzięki kolokacji regionalnej (regional affinity) i unika publicznego ruchu wychodzącego.

Zachowaj Cloud NAT dla ruchu wychodzącego do internetu poza Google

Działanie: Wdróż bramy Cloud NAT w każdym regionie, dostosowując ich rozmiar do szczytowych przepływów. Upewnij się, że trasa domyślna nadal wskazuje na NGFW, z wyjątkiem specyficznych tras hosta dla restricted VIP.
Uzasadnienie: Umożliwia kontrolowany ruch wychodzący do miejsc docelowych innych niż Google, jednocześnie zapewniając, że ruch do Google API pozostaje prywatny, a NGFW zachowuje centralną widoczność.

Waliduj i monitoruj

Działanie: Dla każdego typu klienta zweryfikuj rozwiązywanie nazw DNS, wybór trasy i łączność TLS. Sprawdzaj logi VPC‑SC pod kątem odmów dostępu, logi NAT pod kątem ruchu wychodzącego poza Google oraz stany połączeń PSC. Dodaj alerty dotyczące stanu i dostępności dla wewnętrznych load balancerów (ILB) za załącznikiem usługi partnera oraz dla Cloud SQL.
Uzasadnienie: Potwierdza, że ścieżka danych jest zgodna z zamierzeniami projektowymi i wcześnie wykrywa regresje, zwłaszcza gdy zmieniają się DNS, trasy lub perymetry.

← Cloud DNS · Wszystkie domeny · Trasowanie →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →