Google PCNE: Polityki zapory sieciowej, Cloud Armor i bezpieczeństwo sieci — 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

Zasady zapory sieciowej, Cloud Armor i bezpieczeństwo sieciowe w Google Cloud razem zapewniają warstwowe mechanizmy kontroli do segmentacji, redukcji powierzchni ataku, odporności na ataki DDoS i obserwowalności. Skuteczne projekty łączą targetowanie oparte na tożsamości, hierarchiczne egzekwowanie zasad, ruch przychodzący i wychodzący z najmniejszymi uprawnieniami oraz ochronę na brzegu sieci powiązaną z globalnymi systemami równoważenia obciążenia Google. Sukces operacyjny zależy od zrozumienia procesu oceny reguł, zachowań domyślnych, zakresu logowania oraz faktycznego źródła ruchu w różnych trybach równoważenia obciążenia.

Reguły zapory sieciowej VPC i targetowanie oparte na tożsamości

Reguły zapory sieciowej VPC są stanowe i oceniane dla każdej sieci, kierunku i priorytetu.

• Kierunek i reguły domyślne:
  • Ruch przychodzący (ingress) jest oceniany dla ruchu wchodzącego do interfejsu sieciowego (NIC) maszyny wirtualnej; ruch wychodzący (egress) dla ruchu go opuszczającego.
  • W każdej sieci VPC istnieją dwie domyślne reguły: domyślna reguła blokująca cały ruch przychodzący i domyślna reguła zezwalająca na cały ruch wychodzący. Nie można ich modyfikować i nie generują one logów. Sieć domyślna (default network) tworzy również kilka reguł zezwalających; niestandardowe sieci VPC tego nie robią.
• Priorytet i ocena:
  • Priorytety mieszczą się w zakresie 0–65535, gdzie niższa wartość jest oceniana jako pierwsza. Pierwsza pasująca reguła w pełni określa działanie.
  • Jeśli pasuje wiele reguł o tym samym priorytecie, wygrywa ta z najbardziej szczegółowym zakresem IP; jeśli szczegółowość jest taka sama, a działania są sprzeczne, wygrywa reguła blokująca (deny). Należy unikać nakładania się reguł o tym samym priorytecie.
• Cele i źródła:
  • Cele (targets) określają, do których maszyn wirtualnych ma zastosowanie reguła: tagi sieciowe, konta usług (service accounts) maszyn wirtualnych lub bezpieczne tagi (secure tags). Źródła/miejsca docelowe to zakresy CIDR IP; dla ruchu przychodzącego można również określić źródłowe konta usług lub tagi dla źródeł w tej samej sieci VPC.
  • Tagi sieciowe to metadane maszyn wirtualnych, które mogą być ustawiane przez użytkowników projektu; są proste, ale oferują mniejszą kontrolę. Konta usług zapewniają targetowanie oparte na tożsamości, powiązane z tożsamością obciążenia roboczego i IAM, co utrudnia ich niewłaściwe użycie. Bezpieczne tagi (tagi menedżera zasobów na poziomie organizacji powiązane przez IAM) pozwalają zespołom ds. bezpieczeństwa kontrolować, które maszyny wirtualne mogą być celem reguły, nie pozwalając deweloperom na samodzielne przypisywanie tagów omijających zabezpieczenia; należy ich używać w celu silniejszego nadzoru.
• Logowanie:
  • Logowanie reguł zapory sieciowej można włączyć dla każdej reguły, aby rejestrować dozwolone lub odrzucone połączenia, które do niej pasują. Domyślne reguły blokujące nie są logowane; jeśli potrzebujesz logów zablokowanych połączeń, dodaj jawną regułę blokującą o wysokim priorytecie z włączonym logowaniem.
  • Logi zawierają odniesienie do reguły, działanie, 5-krotkę, liczbę bajtów i mogą być eksportowane na potrzeby analizy śledczej (forensics).

Projektowanie i operacje:

• Ruch przychodzący z najmniejszymi uprawnieniami: Preferuj domyślne blokowanie (deny-by-default) za pomocą jawnych reguł blokujących o wysokim priorytecie, a następnie dodawaj ograniczone reguły zezwalające według konta usługi lub bezpiecznego taga. Dla grup instancji za systemem równoważenia obciążenia, zezwalaj na ruch tylko z zakresów IP systemu równoważenia obciążenia lub kontroli stanu (health check), które są faktycznym źródłem ruchu.
• Ruch wychodzący z najmniejszymi uprawnieniami: Zastąp domyślną regułę zezwalającą jawną regułą blokującą cały ruch wychodzący o wysokim priorytecie, a następnie dodaj ukierunkowane reguły zezwalające (dla zakresów NAT, adresów IP partnerów lub interfejsów API Google przez Private Google Access). Uważaj, aby nie zablokować przepływów zwrotnych; stanowość zapory pozwala na odpowiedzi na dozwolone połączenia bez dodatkowych reguł.
• Targetowanie oparte na tożsamości:
  • Używaj kont usług do tworzenia zasad typu „kto z kim może rozmawiać”, niezależnie od zmieniających się adresów IP.
  • Używaj bezpiecznych tagów, aby uniemożliwić deweloperom samodzielne stosowanie tagów sieciowych o zbyt szerokich uprawnieniach.
• Częste pułapki i tryby awarii:
  • Tożsamość źródła w systemie równoważenia obciążenia: W przypadku zewnętrznych systemów równoważenia obciążenia HTTP(S), backendy widzą połączenia pochodzące z serwerów proxy Google Front End, a nie z adresów IP klientów. Użyj Cloud Armor do zezwalania/blokowania adresów IP klientów; użyj zapory sieciowej VPC, aby zezwolić na ruch z zakresów GFE i kontroli stanu. W przypadku systemów równoważenia obciążenia sieciowego TCP/UDP, backendy widzą adres IP klienta; listy dozwolonych adresów IP klientów w zaporze sieciowej mają bezpośrednie zastosowanie.
  • Brakujące logi zablokowanych połączeń: Zablokowane połączenia przez reguły domyślne nie są logowane. Dodaj jawną regułę blokującą z włączonym logowaniem, aby obserwować blokowany ruch.
  • Ominięcie NAT: Jeśli maszyna wirtualna ma zewnętrzny adres IP, użyje go do ruchu wychodzącego, omijając Cloud NAT. Usuń zewnętrzny adres IP, aby wymusić korzystanie z NAT.
  • Diagnozowanie niedopasowania reguł: Potwierdź kierunek, tożsamość celu (tag/konto usługi/bezpieczny tag), priorytet i filtry źródłowe. Jeśli logi nie wykazują dopasowania, ruch nie trafia na oczekiwaną regułę.

Krótki przykład, reguła zezwalająca na ruch przychodzący oparta na tożsamości z logowaniem:

• Cel: konto usługi sa: web-backend@project.iam.gserviceaccount.com
• Zakresy źródłowe: zakresy proxy GFE + kontrole stanu Google
• Priorytet: 100
• Działanie: zezwól na tcp:80,443
• Logowanie: włączone

Hierarchiczne zasady zapory sieciowej, segmentacja i perymetry usług

Hierarchiczne zasady zapory sieciowej egzekwują zasady na poziomie organizacji lub folderu przed wszelkimi zasadami na poziomie VPC. Używaj ich, aby zagwarantować zabezpieczenia (tzw. guardrails), na przykład „odmów całemu ruchowi przychodzącemu z internetu do maszyn wirtualnych bez load balancera” lub „odmów RDP/SSH z 0.0.0.0/0”. Zasady VPC niższego poziomu nie mogą nadpisać reguły deny na poziomie organizacji/folderu, która już została dopasowana.

Strategia segmentacji:

• Segmentacja ruchu przychodzącego (ingress):
  • Zasady na poziomie organizacji/folderu: reguły deny o wysokim priorytecie dla ryzykownych portów i domyślna odmowa z wyjątkiem zatwierdzonych punktów wejścia. Zezwalaj na zakresy sprawdzania stanu (health check) Google tam, gdzie jest to wymagane.
  • Zasady VPC: reguły allow specyficzne dla obciążenia, kierowane według konta usługi (service account) lub bezpiecznego tagu (secure tag). W przypadku usług wewnętrznych użyj Private Service Connect lub wewnętrznego load balancingu dla dostępu wschód-zachód (east-west) z ograniczonymi zasadami.
• Segmentacja ruchu wychodzącego (egress):
  • Zastąp domyślną regułę zezwalającą na cały ruch wychodzący regułą deny-all o wysokim priorytecie na poziomie organizacji/folderu lub VPC, a następnie otwórz tylko to, co jest niezbędne:
    • Ruch wychodzący do internetu przez Cloud NAT lub zatwierdzone zapory sieciowe dla ruchu wychodzącego.
    • Interfejsy API Google przez Private Google Access i punkty końcowe private.googleapis.com lub restricted.googleapis.com. Punkt końcowy restricted współpracuje z VPC Service Controls, aby zapobiegać eksfiltracji danych do nieautoryzowanych tożsamości lub projektów.
    • W przypadku architektur, które kierują ruch 0.0.0.0/0 przez zaporę sieciową innej firmy, ale nadal wymagają bezpośredniego dostępu do interfejsów API Google bez tzw. hairpinningu, dodaj trasy statyczne dla bloków VIP interfejsów API Google do domyślnej bramy internetowej i włącz Private Google Access w podsieciach. Pozwala to zachować mechanizmy kontroli bezpieczeństwa, jednocześnie zmniejszając opóźnienia i zależność od urządzenia innej firmy w przypadku usług własnych (first-party).

Interakcje z perymetrami usług:

• VPC Service Controls definiują perymetry wokół projektów i obsługiwanych interfejsów API Google w celu ograniczenia eksfiltracji danych. Gdy perymetry są włączone:
  • Preferuj restricted.googleapis.com, aby wywołania API musiały pozostać w kontekście perymetru.
  • Upewnij się, że DNS wskazuje odpowiednie domeny na punkty końcowe restricted lub private oraz że trasy nie kierują ruchu z powrotem do niezaufanych urządzeń wyjściowych.
  • Połącz zasady perymetru z listami dozwolonych (allowlists) zapory sieciowej dla ruchu wychodzącego, aby uniknąć przypadkowych wycieków do punktów końcowych spoza perymetru.

Kompromisy:

• Reguły deny na poziomie organizacji upraszczają zarządzanie ryzykiem, ale mogą blokować uzasadnione eksperymenty, jeśli kontrola zmian jest powolna; deleguj wyjątki za pomocą bezpiecznych tagów (secure tags) i udokumentowanych procesów składania wniosków.
• Agresywne reguły deny dla ruchu wychodzącego zmniejszają promień rażenia (blast radius), ale wymagają solidnego mechanizmu odnajdywania usług (service discovery) i kontroli zmian, aby zapobiegać awariom.

Cloud Armor, WAF i globalne zabezpieczenia brzegowe

Cloud Armor wiąże polityki bezpieczeństwa z zewnętrznymi load balancerami HTTP(S) oraz zewnętrznymi load balancerami TCP/SSL Proxy, aby zapewnić ochronę na brzegu sieci (at the edge).

• Reguły WAF:
  • Używaj prekonfigurowanych reguł dla OWASP Top 10 i popularnych CVE oraz niestandardowych reguł wykorzystujących język wyrażeń do dopasowywania nagłówków, adresów IP, krajów, identyfikatorów URI i innych.
  • Dołączaj do każdej usługi backendowej (backend service) i porządkuj reguły według priorytetu. Działania obejmują zezwolenie (allow), odmowę (deny) z określoną odpowiedzią lub przekierowanie (redirect) dla HTTP(S).
• Ograniczanie częstotliwości (rate limiting):
  • Wymuszaj limity na klucz (np. według adresu IP klienta, nagłówka lub pliku cookie) z wykorzystaniem okien przesuwnych (sliding windows) i kontroli nagłych wzrostów (burst controls). Blokady oparte na częstotliwości (rate-based bans) automatycznie dodają tymczasowe reguły deny dla źródeł generujących nadużycia.
• Adaptive Protection:
  • Wykrywanie anomalii oparte na ML uczy się normalnych wzorców żądań i ujawnia ataki DDoS warstwy 7 lub nadużycia. Może sugerować lub automatycznie generować proponowane reguły; wdrażaj je najpierw w trybie podglądu (preview).
• Tryb podglądu (preview mode):
  • Oceniaj nowe reguły bez wpływu na ruch. Wyniki podglądu są logowane, co umożliwia niskokoryzykowne dostrajanie. Po weryfikacji przejdź do trybu egzekwowania (enforced mode).

Obrona przed DDoS i mechanizmy kontroli globalnego load balancera:

• Globalna sieć brzegowa anycast Google absorbuje wolumetryczne ataki L3/L4; walidacja SYN/ACK, obsługa zniekształconych pakietów i automatyczne skalowanie pojemności brzegowej są wbudowane w platformę dla zewnętrznych load balancerów HTTP(S) i TCP/SSL Proxy.
• Połącz z Cloud Armor, aby łagodzić ataki typu L7 flood, credential stuffing i nadużycia aplikacji.
• Wymuszaj polityki TLS, nowoczesne szyfry i, w razie potrzeby, mTLS klienta na poziomie load balancera. W przypadku wymagań dotyczących IPv6 użyj globalnego zewnętrznego load balancera HTTP(S) lub TCP/SSL Proxy z adresami VIP IPv6.
• Aby dodać określone adresy IP klientów do listy dozwolonych (allowlisting) dla aplikacji za load balancerem:
  • Jeśli używasz HTTP(S), preferuj listy dozwolonych Cloud Armor oparte na adresie IP klienta i ogranicz zasady zapory sieciowej dla backendu do źródeł GFE i sprawdzania stanu (health check).
  • Jeśli używasz TCP/UDP Network Load Balancer, backendy widzą rzeczywisty adres IP klienta; zastosuj listy dozwolonych zapory sieciowej VPC bezpośrednio do docelowych instancji (według bezpiecznego tagu lub konta usługi) i uwzględnij adresy IP sprawdzania stanu Google.

Uwagi operacyjne:

• Reguły są oceniane na brzegu sieci; nieprawidłowe listy dozwolonych mogą natychmiast spowodować globalne awarie. Używaj trybu podglądu i wdrożeń etapowych (staged rollouts) oraz monitoruj logi Cloud Armor i metryki load balancera.
• Wymagania dotyczące powinowactwa sesji (session affinity) są różne: w przypadku mieszanych protokołów (np. HTTP i TFTP od tego samego klienta do tej samej puli backendów), powinowactwo oparte na adresie IP klienta na load balancerze utrzymuje lepkość sesji (stickiness) między portami.

Widoczność, inspekcja i reagowanie na incydenty

Obserwowalność:

• VPC Flow Logs dostarczają próbkowane rekordy przepływu (5-krotki) dla każdej podsieci z konfigurowalnym próbkowaniem, wzbogacaniem metadanych i interwałami agregacji. Używaj ich do tworzenia bazowych profili wydajności i wykrywania anomalii.
• Logowanie reguł zapory sieciowej przechwytuje zezwolenia i odrzucenia dla każdego połączenia dla konkretnych reguł z włączonym logowaniem; twórz jawne reguły odrzucające, aby logować zablokowane połączenia, które w przeciwnym razie trafiłyby na domyślne odrzucenia.
• Logi żądań i wyniki podglądu Cloud Armor pokazują dopasowania reguł, podjęte decyzje oraz wyniki ograniczania szybkości (rate-limiting) na brzegu sieci.

Inspekcja i wykrywanie:

• Packet Mirroring kopiuje ruch do kolektora w tym samym regionie w celu głębokiej inspekcji pakietów (DPI) lub użycia z systemem IDS. Ogranicz zakres mirroringu według podsieci, tagu lub konta serwisowego, aby zminimalizować narzut. Packet Mirroring działa poza pasmem (out-of-band) i nie blokuje ruchu; używaj go z Cloud IDS lub sensorami firm trzecich.
• Inspekcja L7 w trybie inline wymaga wzorca urządzenia z dwiema kartami sieciowymi (2-NIC) i odpowiedniego routingu przez to urządzenie. Zaprojektuj system pod kątem routingu symetrycznego i wysokiej dostępności (HA); uwzględnij regionalne domeny awarii i potencjalne wąskie gardła przepustowości. Urządzenia inline zwiększają promień rażenia w przypadku awarii; wdrażaj zarządzane grupy instancji i wzorce przełączania awaryjnego tras oparte na kontroli stanu (health-checked), tam gdzie to możliwe.

Praktyki reagowania na incydenty:

• Centralizuj logi w dedykowanym projekcie bezpieczeństwa, buduj systemy wykrywania nagłych skoków liczby odrzuceń, tworzenia nowych reguł o wysokim priorytecie lub aktywacji ograniczania szybkości przez Cloud Armor. Używaj BigQuery lub integracji z SIEM do prowadzenia dochodzeń.
• Zapewnij minimalne uprawnienia IAM (least-privilege): Rola Network Admin jest niewystarczająca do modyfikacji polityk zapory w Shared VPC, gdzie wymagana jest rola Security Admin; rozdziel obowiązki między zespoły sieciowe i bezpieczeństwa.
• Gdy potrzebujesz awaryjnego dostępu SSH (break-glass), a klucze nie zostały wcześniej udostępnione, użyj polecenia

undefined

z Cloud Shell, aby wgrać klucz efemeryczny poprzez metadane instancji, jeśli pozwalają na to uprawnienia IAM i ustawienia metadanych instancji.

• W celu rozwiązywania problemów typu „brak logów”: zweryfikuj regułę i kierunek ruchu, pamiętaj, że domyślne odrzucenia nie są logowane, i sprawdź polityki hierarchiczne, które mogły zostać dopasowane wcześniej.

Praktyczny scenariusz problemowy

Firma Contoso Retail prowadzi wielowarstwową platformę internetową w Google Cloud. Ruch front-endowy jest obsługiwany przez globalny zewnętrzny load balancer HTTP(S); maszyny wirtualne aplikacji działają w wielu regionach bez zewnętrznych adresów IP. Ruch wychodzący (egress) musi przechodzić w trybie hairpin przez urządzenie NGFW firmy trzeciej, z wyjątkiem ruchu do Google APIs (BigQuery i Pub/Sub). Zespół bezpieczeństwa chce wdrożyć ogólnoorganizacyjne bariery ochronne, listy dozwolonych adresów IP klientów dla pilotażowego programu partnerskiego oraz zminimalizować ryzyko podczas testowania podejrzanego, złośliwego klienta.

Podejście:

1. Ustanów hierarchiczne bariery ochronne (guardrails)
   • Utwórz hierarchiczną politykę zapory na poziomie organizacji, która odrzuca cały ruch przychodzący z

undefined

do maszyn wirtualnych nieposiadających bezpiecznego tagu

undefined

oraz blokuje porty administracyjne (SSH, RDP) z internetu.

• Uzasadnienie: Globalnie zatrzymuje niebezpieczną ekspozycję; deweloperzy nie mogą samodzielnie przypisać bezpiecznego tagu z powodu ograniczeń IAM na tagach.

2. Targetowanie obciążeń roboczych z uwzględnieniem tożsamości
   • Przypisz odrębne konta serwisowe do warstw front-endu, aplikacji i bazy danych. Odwołuj się do tych kont serwisowych w regułach zapory na poziomie VPC, aby zezwolić tylko na wymagane przepływy wschód-zachód (np.

undefined

,

undefined

).

• Uzasadnienie: Wiąże politykę z tożsamością obciążenia roboczego i jest odporne na przypadkowe, błędne użycie tagów.

3. Zezwolenia na ruch przychodzący dla backendów za load balancerem

   • Na maszynach wirtualnych aplikacji utwórz regułę zezwalającą na ruch przychodzący o wysokim priorytecie, targetowaną przez konto serwisowe aplikacji, z zakresami źródłowymi równymi adresom proxy Google Front End oraz zakresom kontroli stanu Google; włącz logowanie.
   • Uzasadnienie: W przypadku HTTP(S) L7, backendy powinny akceptować połączenia tylko z adresów IP GFE i kontroli stanu; listy dozwolonych adresów IP klientów są egzekwowane na brzegu sieci.

4. Polityka brzegowa Cloud Armor

   • Dołącz politykę Cloud Armor do usługi backendowej zewnętrznego load balancera HTTP(S):
     • Dodaj regułę z listą dozwolonych adresów IP partnera.
     • Włącz prekonfigurowane reguły WAF dla OWASP Top 10.
     • Skonfiguruj ograniczanie szybkości (rate limit) z kluczem opartym na adresie IP klienta i konserwatywnymi progami.
   • Uzasadnienie: Wymusza ograniczenia dotyczące źródła klienta i ochronę na warstwie aplikacji tam, gdzie adres IP klienta jest widoczny i zanim ruch dotrze do VPC.

5. Ochrona adaptacyjna i bezpieczne testowanie

   • Włącz Adaptive Protection i utwórz regułę odrzucającą dla podejrzanego adresu IP klienta w trybie podglądu (preview mode).
   • Uzasadnienie: Tryb podglądu pozwala na weryfikację zachowania bez wpływu na rzeczywistych użytkowników; logi potwierdzą, czy klient jest złośliwy, przed wdrożeniem reguły.

6. Segmentacja ruchu wychodzącego z użyciem Private Google Access

   • Zachowaj trasę

undefined

do NGFW firmy trzeciej. Dodaj niestandardowe trasy statyczne dla VIP-ów Google APIs do domyślnej bramy internetowej i włącz Private Google Access na podsieciach. Dodaj jawną regułę odrzucającą cały ruch wychodzący o wysokim priorytecie, a następnie konkretne reguły zezwalające dla next-hopa NGFW i Google APIs; włącz logowanie.

• Uzasadnienie: Wymusza przepływ ogólnego ruchu internetowego przez NGFW, jednocześnie umożliwiając prywatny dostęp do BigQuery i Pub/Sub bez niepotrzebnego hairpinningu.

7. Kontrola NAT i zewnętrznych adresów IP

   • Użyj Cloud NAT dla instancji, które potrzebują dostępu do internetu, ale nie mają zewnętrznych adresów IP. Przeprowadź audyt i usuń wszelkie zewnętrzne adresy IP z instancji obliczeniowych, które muszą korzystać z NAT.
   • Uzasadnienie: Zapobiega omijaniu NAT i utrzymuje jednolitą politykę ruchu wychodzącego.

8. Inspekcja i monitorowanie

   • Włącz Packet Mirroring w każdym regionie dla warstwy aplikacji, targetując konto serwisowe aplikacji, i wysyłaj zdublowany ruch do regionalnego kolektora IDS. Włącz VPC Flow Logs i logowanie kluczowych reguł zapory; eksportuj logi Cloud Armor i VPC do centralnego projektu bezpieczeństwa i BigQuery.
   • Uzasadnienie: Zapewnia głęboką widoczność na potrzeby polowania na zagrożenia (threat hunting) i tworzenia bazowych profili wydajności bez wprowadzania opóźnień w ścieżce ruchu.

9. Operacje gotowe na incydenty

   • Zbuduj system alertów reagujący na skoki liczby odrzuceń w Cloud Armor, logi odrzuceń zapory sieciowej lub zmiany w politykach hierarchicznych. Udokumentuj procedurę awaryjnego dostępu SSH (break-glass) przy użyciu polecenia

undefined

w Cloud Shell w celu zapewnienia kontrolowanego dostępu w sytuacjach kryzysowych.

• Uzasadnienie: Pozwala na szybkie wykrywanie aktywnego nadużycia i zachowuje bezpieczną ścieżkę operacyjną do usuwania skutków incydentów.

10. Bezpieczeństwo zmian i możliwość wycofania (rollback)
    • Wdrażaj zmiany w Cloud Armor najpierw w trybie podglądu, a następnie egzekwuj. W przypadku zmian w zaporze sieciowej używaj reguł o niższym priorytecie i testuj w projektach kanarkowych (canary projects) przed propagacją na poziom polityki organizacyjnej.
    • Uzasadnienie: Minimalizuje ryzyko globalnych awarii spowodowanych błędami w polityce, jednocześnie utrzymując silną postawę bezpieczeństwa.

← Architektura VPC · Wszystkie domeny · Łączność hybrydowa →

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

Przeglądaj Google →