Google PCA: Bezpieczeństwo, zgodność z przepisami i architektura ochrony danych — Przewodnik do nauki

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Przegląd

Bezpieczeństwo, zgodność i ochrona danych w Google Cloud opierają się na współdzielonej odpowiedzialności i obronie w głąb (defense in depth). Google zabezpiecza infrastrukturę bazową, podczas gdy Ty projektujesz bezpieczne tożsamości, sieci, aplikacje i procesy przetwarzania danych. Przyjmij Zero Trust jako model wiodący: nigdy nie ufaj sieci w sposób domniemany, ciągle weryfikuj tożsamość i kontekst oraz rygorystycznie egzekwuj zasadę najmniejszych uprawnień. Projektuj z założeniem kompromitacji: zakładaj, że poświadczenia mogą wyciec, punkty końcowe mogą być skanowane, a usługi wewnętrzne mogą być nadużywane. Kompensuj to za pomocą wielu mechanizmów kontrolnych (prewencyjnych, wykrywających, reagujących), silnej kryptografii i zarządzania kluczami, solidnego monitoringu oraz przećwiczonych procedur reagowania na incydenty.

Kompromisy są nieuniknione. Silniejsze mechanizmy kontrolne mogą zwiększać opóźnienia, złożoność operacyjną i koszty. Twoja architektura powinna jawnie równoważyć ryzyka z użytecznością i wydajnością, zachowując jednocześnie udowadnialną zgodność i gotowość do analizy powłamaniowej (forensics).

Architektura Tożsamości i Dostępu

• Zasady i model

  • Zasada najmniejszych uprawnień (least privilege) domyślnie: przyznawaj najmniejszy zestaw uprawnień wymagany do wykonania zadania i preferuj predefiniowane role lub role niestandardowe zamiast ról podstawowych (Owner, Editor, Viewer).
  • Rozdzielenie obowiązków (separation of duties): rozdziel role pomiędzy twórców (CI/CD), osoby wdrażające, operatorów i zespoły bezpieczeństwa. Używaj kont awaryjnych (break-glass) z silnymi mechanizmami kontrolnymi i logowaniem w sytuacjach nadzwyczajnych.
  • Egzekwowanie Zero Trust: używaj dostępu opartego na kontekście (context-aware access) do weryfikacji użytkownika, urządzenia, lokalizacji i ryzyka; wymagaj silnego MFA; i ciągle oceniaj kontekst sesji.
  • Zasady Organizacji (Organization Policy) i IAM Deny: skodyfikuj zasady ochronne (guardrails) (na przykład, zakaz tworzenia kluczy kont serwisowych, ograniczanie udostępniania domen) i używaj polityk deny do egzekwowania nienegocjowalnych granic.

• Implementacja IAM i strategia kont serwisowych

  • Ustanów model dostępu oparty na hierarchii: foldery odzwierciedlają linie biznesowe lub środowiska (prod, non-prod); projekty izolują promień rażenia (blast radius) i rozliczenia; konta serwisowe (SA) reprezentują obciążenia robocze.
  • Jedno obciążenie, jedno konto serwisowe: unikaj współdzielenia kont serwisowych między niepowiązanymi usługami. Przypisuj uprawnienia do zakresu wdrożenia (projekt) i zakresu zasobu.
  • Preferuj krótkożyciowe poświadczenia poprzez personifikację konta serwisowego (Service Account Impersonation) i Workload Identity Federation. Wyłączaj klucze kont serwisowych zarządzane przez użytkownika; jeśli jest to nieuniknione, izoluj ich użycie, często rotuj i monitoruj za pomocą logów audytowych.
  • Używaj Access Boundaries, aby ograniczyć, do czego spersonifikowane konto serwisowe ma dostęp w czasie żądania (na przykład, ograniczając ścieżki do obiektów GCS), co ogranicza promień rażenia nawet w przypadku nadużycia uprzywilejowanego konta serwisowego.
  • Warunkowy IAM (Conditional IAM): stosuj warunki na poziomie zasobów (czas, IP, atrybuty podmiotu), aby ograniczyć dostęp. Przykład: zablokuj dostęp do środowiska produkcyjnego z wyjątkiem firmowych zakresów IP i podczas okien serwisowych.

• Tryby awarii i kompromisy

  • Role z nadmiernymi uprawnieniami (np. Editor na poziomie projektu) zwiększają ryzyko; preferuj bardziej granularne role i weryfikuj je za pomocą analizatorów polityk.
  • Rozprzestrzenianie się kluczy kont serwisowych w CI/CD i lokalnych skryptach jest częstym wektorem ataku; przy użyciu personifikacji niektóre starsze narzędzia mogą wymagać adaptacji.
  • Polityki IAM Deny są potężne, ale mogą być trudne do debugowania; wdrażaj i testuj zmiany na środowiskach nieprodukcyjnych z jawnymi uruchomieniami na sucho (dry runs).

Przykład (personifikacja bez tworzenia kluczy):

undefined

Ochrona danych i kryptografia

• Cloud KMS i modele zarządzania kluczami
  • Natywne szyfrowanie danych w spoczynku (at rest) jest domyślne. Aby uzyskać dodatkową kontrolę, używaj kluczy szyfrujących zarządzanych przez klienta (CMEK) z usługami takimi jak BigQuery, Cloud Storage, dyski Compute Engine, Pub/Sub i wolumeny trwałe GKE.
  • Zaprojektuj hierarchię kluczy według środowiska i domeny danych. Używaj oddzielnych pęków kluczy (keyrings) dla każdej lokalizacji i oddzielnych kluczy dla każdej aplikacji lub zbioru danych, aby ograniczyć promień rażenia (blast radius).
  • Rotacja: włącz zaplanowaną rotację i wycofuj starsze wersje kluczy w sposób kontrolowany, używając szyfrowania kopertowego (envelope encryption) dla aplikacji. Sprawdź kompatybilność konsumentów przed zwiększeniem częstotliwości rotacji.
  • External Key Manager (EKM) i External Key Access (EKA) umieszczają klucze poza Google Cloud w celu zapewnienia kontroli regulacyjnej. Wady obejmują dodatkowe opóźnienia i zależność od dostępności zewnętrznego HSM; zaplanuj działanie w trybie awaryjnym (degraded-mode).
  • Wymuszaj zasadę najmniejszych uprawnień (least privilege) IAM na CryptoKeys. Używaj logów audytowych na poziomie klucza jako dowodu dostępu.

Przykład (CMEK z rotacją):

undefined

undefined

• Szyfrowanie na poziomie aplikacji

  • Używaj szyfrowania kopertowego (np. za pomocą Tink) do szyfrowania wrażliwych pól na poziomie aplikacji, co umożliwia selektywny dostęp i izolację danych tenantów. Wyprowadzaj klucze per-tenant, aby zminimalizować wpływ między tenantami.
  • Weryfikuj integralność (AEAD), aby zapobiegać manipulacji (tampering) i atakom typu replay.

• Secret Manager i cykl życia sekretów

  • Przechowuj dane uwierzytelniające, tokeny i klucze API jako wersjonowane sekrety; nigdy w obrazach, repozytoriach Git ani w metadanych instancji. Nadawaj uprawnienia IAM na poziomie sekretu lub projektu do konta serwisowego (service account) środowiska uruchomieniowego.
  • Rotacja: zautomatyzuj za pomocą Cloud Functions/Cloud Run wyzwalanych przez Pub/Sub, aby tworzyć nową wersję, aktualizować zależności i unieważniać stare wersje. Preferuj zastępowanie długożyjących haseł do baz danych uwierzytelnianiem bazodanowym opartym na IAM lub tokenami krótkoterminowymi.
  • Bezpieczeństwo konfiguracji: oddzielaj konfigurację niezawierającą sekretów (ConfigMap, zmienne środowiskowe) od sekretów. Zapobiegaj ujawnianiu sekretów w logach i komunikatach o błędach.

Przykład (dodanie nowej wersji sekretu):

undefined

• Wzmacnianie bezpieczeństwa zasobów obliczeniowych (hardening) i confidential computing
  • Shielded VMs: włącz bezpieczny rozruch (secure boot), vTPM i monitorowanie integralności, aby chronić przed bootkitami i rootkitami. Wymuszaj za pomocą polityk organizacji (organization policy) i weryfikuj w potokach CI/CD.
  • Confidential VMs: domyślne szyfrowanie pamięci chroni dane w użyciu (data-in-use) przy minimalnych zmianach konfiguracyjnych; oceń wpływ na wydajność dla obciążeń o dużej przepustowości i intensywnie wykorzystujących kryptografię.
  • Obrazy wzmocnione (hardened images): zaczynaj od obrazów bazowych zoptymalizowanych przez Google lub wzmocnionych zgodnie ze standardem CIS; zarządzaj łataniem za pomocą OS Config i wyłączaj niepotrzebne pakiety oraz porty.

Bezpieczeństwo sieci i brzegu sieci (Edge)

• Segmentacja sieci i kontrola ruchu wychodzącego (egress)

  • Segmentuj według warstw (tier) i wrażliwości, używając oddzielnych sieci VPC, podsieci i hierarchicznych reguł zapory sieciowej. Łącz tagi zapory sieciowej oparte na tożsamości z ograniczeniami między usługami (np. GKE NetworkPolicy), aby wymusić kontrolę ruchu wschód-zachód (east-west).
  • Kontroluj ruch wychodzący za pomocą Cloud NAT, polityk DNS i ograniczonego Private Google Access, aby zminimalizować eksfiltrację danych. Używaj jawnych list dozwolonych dla ruchu wychodzącego (egress allowlists) i inspekcji przez proxy, gdy jest to uzasadnione.

• VPC Service Controls (VPC SC)

  • Buduj perymetry usług (service perimeters) wokół projektów przechowujących dane objęte zakresem, aby ograniczyć eksfiltrację z zarządzanych przez Google API (GCS, BigQuery, Secret Manager, Pub/Sub itp.).
  • Poziomy dostępu (access levels): zdefiniuj warunki kontekstowe (tożsamość użytkownika, zakresy IP, stan urządzenia), które muszą być spełnione, aby uzyskać dostęp do usług wewnątrz perymetru.
  • Używaj mostów perymetru (perimeter bridges) do kontrolowanych przepływów pracy obejmujących wiele perymetrów oraz reguł ruchu wychodzącego (egress rules) do ograniczania miejsc docelowych. Testuj w trybie dry-run, aby uniknąć awarii potoków.
  • Ograniczenia: nie chroni bezpośrednio ruchu do adresów IP Compute Engine; uzupełnij o reguły zapory sieciowej i kontrolę ruchu wychodzącego. Niektóre narzędzia i wzorce hybrydowe mogą wymagać kont serwisowych świadomych perymetru (perimeter-aware) oraz Private Service Connect do ograniczonych adresów VIP.

• Ochrona brzegu sieci i aplikacji

  • Cloud Armor: chroń aplikacje HTTP(S) za globalnym zewnętrznym load balancerem za pomocą mitygacji DDoS na warstwach L3/L4/L7, list dozwolonych/zablokowanych adresów IP, kontroli opartych na geolokalizacji i ograniczania liczby zapytań (rate limiting).
  • Reguły WAF: stosuj prekonfigurowane, zarządzane reguły i niestandardowe sygnatury dla OWASP Top 10; dostrajaj, aby zredukować fałszywe alarmy (false positives). Dołączaj do poszczególnych usług backendowych (backend service), aby dostosować polityki do wersji API lub komponentu aplikacji.
  • Ochrona API: zabezpieczaj API za pomocą API Gateway lub Apigee w celu uwierzytelniania, przydzielania limitów (quota), walidacji schematu i wykrywania zagrożeń; zintegruj z Cloud Armor w celu egzekwowania polityk na brzegu sieci; rozważ użycie reCAPTCHA Enterprise i kontroli botów w odpowiednich przypadkach.
  • Wady: głębsza inspekcja może zwiększyć opóźnienia i szum operacyjny. Wdrażaj reguły w trybie podglądu (preview mode), monitoruj logi i stopniowo je egzekwuj.

Operacje bezpieczeństwa, monitorowanie i zgodność

• Security Command Center (SCC) i wykrywanie zagrożeń

  • SCC agreguje inwentarz zasobów i wyniki z różnych projektów i organizacji. Używaj go do ustalania bazowego stanu bezpieczeństwa (publiczne buckety, otwarte reguły zapory), śledzenia zmian i inicjowania procesów naprawczych.
  • Wykrywanie zagrożeń w wersji Premium obejmuje Event Threat Detection, VM Threat Detection i Container Threat Detection w celu identyfikacji złośliwego oprogramowania, cryptominingu i anomalnych zachowań.
  • Integruj wyniki z systemami ticketowymi i potokami SOAR; definiuj polityki wyciszania/wyjątków z datą wygaśnięcia, aby uniknąć zmęczenia alertami.

• Bezpieczeństwo podatności i artefaktów

  • Używaj Artifact Analysis do skanowania obrazów kontenerów pod kątem CVE; egzekwuj polityki w czasie wdrażania za pomocą Binary Authorization i podpisanych atestacji z CI.
  • Zarządzanie poprawkami za pomocą OS Config; monitoruj okna ekspozycji i automatyzuj wdrożenia z użyciem canary.

• Dzienniki audytu, prywatność i dowody

  • Cloud Audit Logs domyślnie dostarczają logi Admin Activity i System Event; logi Data Access można włączyć dla poszczególnych usług i są one płatne. Przekierowuj logi do BigQuery w celu analizy i do Cloud Storage w celu niezmiennego przechowywania i blokady na potrzeby postępowań prawnych (legal hold).
  • Klasyfikacja danych: używaj Cloud DLP do odkrywania i klasyfikowania danych osobowych (PII), stosowania etykiet i tagów oraz mapowania na poziomy ochrony (CMEK, VPC SC, Confidential VMs).
  • Prywatność i rezydencja danych: ograniczaj lokalizacje za pomocą polityki organizacji; dostosuj lokalizacje CMEK i przechowywania danych do wymogów regulacyjnych.
  • Blokady na potrzeby postępowań prawnych i przechowywanie: włącz polityki przechowywania i blokady dla bucketów; w razie potrzeby używaj wersjonowania obiektów (Object Versioning). Dokumentuj łańcuch dowodowy (chain of custody) dla obrazów i logów kryminalistycznych, aby przedstawić wiarygodne dowody.

• Reagowanie na incydenty i gotowość do analizy śledczej

  • Przygotuj runbooki, ścieżki dostępu i automatyzację. Upewnij się, że osoby reagujące mają dostęp na zasadzie najniższych uprawnień, a audyt jest włączony w całej organizacji, folderach i projektach.
  • Powstrzymywanie: izoluj instancje, usuwając je z systemów równoważenia obciążenia, stosując reguły zapory blokujące ruch wychodzący lub przenosząc projekty do bardziej restrykcyjnych polityk organizacji; wyłączaj naruszone konta usług oraz rotuj sekrety i klucze.
  • Analiza śledcza: wykonuj migawki dysków i eksportuj obrazy do analizy offline; zachowuj logi poprzez ich eksport. W stosownych przypadkach używaj mirroringu pakietów. Unikaj modyfikowania dowodów; pracuj na kopiach.
  • Odzyskiwanie: odbudowuj systemy z zaufanych obrazów, ponownie udostępniaj sekrety i weryfikuj za pomocą testów typu smoke test oraz testów bezpieczeństwa. Przeprowadzaj przeglądy poincydentalne i wykorzystuj wnioski do ulepszania zabezpieczeń (guardrails) i mechanizmów wykrywania.

Praktyczny scenariusz problemowy

NimbusPay, firma SaaS z branży fintech, musi przetwarzać dane oznaczone jako PCI w mikrousługach w architekturze multi-tenant na Google Cloud, egzekwować rezydencję danych w UE, chronić przed atakami na warstwę API i dostarczać audytowalne dowody na istnienie kontroli. Firma wdroży nowe API v2, utrzymując jednocześnie działanie v1 pod tą samą nazwą hosta.

Podejście:

1. Podział projektów i tożsamości

• Utwórz oddzielne projekty dla każdego środowiska i warstwy mikrousług (ingest, processing, reporting). Przypisz unikalne konto usługi (workload service account) do każdej usługi. Uzasadnienie: izoluje promień rażenia (blast radius) i mapuje zasadę najniższych uprawnień na konkretne obciążenia.

2. Wdrożenie Zero Trust i zasady najniższych uprawnień

• Przypisz predefiniowane/niestandardowe role do kont usług i grup devops; zastosuj warunkowe IAM, aby ograniczyć dostęp do środowiska produkcyjnego do firmowych adresów IP i godzin pracy. Uzasadnienie: ogranicza ruch boczny (lateral movement) i przypadkowe zmiany.

3. Usunięcie statycznych kluczy kont usług

• Wyłącz zarządzane przez użytkownika klucze SA za pomocą polityki organizacji. Używaj personifikacji konta usługi (Service Account Impersonation) dla CI/CD i operacji; zastosuj Access Boundaries, ograniczając ścieżki GCS dla poszczególnych najemców. Uzasadnienie: eliminuje częsty wektor wycieku poświadczeń i ogranicza dostęp do danych nawet w przypadku kradzieży tokenów.

4. Ochrona danych za pomocą CMEK i kontroli regionalnych

• Utwórz pęki kluczy (keyrings) i klucze Cloud KMS w regionach europe-west; włącz CMEK dla zbiorów danych BigQuery, bucketów GCS i dysków trwałych (Persistent Disks). Skonfiguruj zaplanowaną rotację i monitorowanie wersji. Uzasadnienie: udowadnialna kontrola kryptograficzna zgodna z rezydencją danych w UE i standardem PCI.

5. Zastosowanie szyfrowania na poziomie aplikacji dla danych kart

• Użyj szyfrowania kopertowego (envelope encryption, np. Tink AEAD) z kluczami danych dla każdego najemcy, opakowanymi przez CMEK; przechowuj w bazach danych tylko zaszyfrowany tekst (ciphertext). Uzasadnienie: ochrona na poziomie pola i zminimalizowany zakres podczas analizy incydentu (triage).

6. Centralizacja sekretów i automatyczna rotacja

• Przechowuj poświadczenia do baz danych i tokeny API w Secret Manager z uprawnieniami IAM dla każdej usługi. Zaimplementuj zadania rotacji wyzwalane przez Pub/Sub, które tworzą nowe wersje i aktualizują wdrożenia. Tam, gdzie to możliwe, przełącz się na uwierzytelnianie IAM DB dla Cloud SQL. Uzasadnienie: audytowalny cykl życia sekretów z minimalnym czasem przestoju.

7. Segmentacja sieci i kontrola ruchu wychodzącego

• Użyj hierarchicznych polityk zapory sieciowej, aby wymusić przepływy web→API→DB; zablokuj bezpośredni ruch web→DB. Włącz Cloud NAT z listami dozwolonych adresów dla ruchu wychodzącego i Private Google Access (restricted) dla interfejsów API Google. Uzasadnienie: ogranicza ruch wschód-zachód (east-west) i blokuje nieautoryzowaną eksfiltrację.

8. Objecie usług danych za pomocą VPC Service Controls

• Umieść projekty BigQuery, GCS i Secret Manager wewnątrz perymetru usług (service perimeter); zdefiniuj poziomy dostępu wymagające firmowego adresu IP i zarządzanych urządzeń. Przetestuj w trybie dry-run, a następnie wdróż. Uzasadnienie: ogranicza eksfiltrację danych poprzez skradzione tokeny lub błędnie skonfigurowanych klientów.

9. Zabezpieczenie brzegu sieci i API

• Umieść globalny load balancer HTTPS za Cloud Armor z zarządzanymi regułami i ograniczaniem liczby zapytań (rate limiting). Użyj routingu opartego na ścieżkach, aby rozdzielić /v1 i /v2 do odrębnych usług backendowych i zastosuj dostosowane polityki WAF dla każdej wersji. Zintegruj Apigee do uwierzytelniania, limitów (quotas) i walidacji schematów. Uzasadnienie: warstwowa ochrona API, płynne przejście z v1 na v2 i zminimalizowana liczba fałszywych alarmów (false positives).

10. Wzmocnienie zabezpieczeń zasobów obliczeniowych i atestacja artefaktów

• Włącz Shielded VMs i Confidential VMs dla węzłów przetwarzających; zastosuj obrazy bazowe wzmocnione zgodnie z wytycznymi CIS. Skanuj obrazy w Artifact Registry, wymagaj podpisanych atestacji za pomocą Binary Authorization dla GKE. Uzasadnienie: chroni łańcuch rozruchowy i dane w użyciu oraz egzekwuje zaufanie w łańcuchu dostaw.

11. Monitorowanie stanu bezpieczeństwa i zagrożeń za pomocą SCC

• Włącz SCC Premium, aby wykrywać ryzykowne konfiguracje i zagrożenia w czasie rzeczywistym; zintegruj z systemem ticketowym w celu obsługi SLA. Wyciszaj zaakceptowane ryzyka, podając daty wygaśnięcia. Uzasadnienie: ciągłe zapewnienie bezpieczeństwa i sygnały umożliwiające podjęcie działań.

12. Logowanie, przechowywanie i dostarczanie dowodów

• Przekierowuj logi Admin Activity, Data Access i VPC Flow Logs do BigQuery i Cloud Storage z politykami przechowywania i blokadami na potrzeby postępowań prawnych. Oznaczaj zbiory danych etykietami rezydencji i wrażliwości. Uzasadnienie: wspiera dochodzenia i audyty zewnętrzne dzięki ograniczonemu zakresowi dostępu.

13. Przygotowanie do reagowania na incydenty i analizy śledczej

• Utwórz runbooki do izolowania naruszonych usług poprzez przenoszenie projektów do folderu kwarantanny z bardziej rygorystycznymi politykami, wyłączanie powiązanych kont SA i tworzenie migawek dysków do analizy offline. Uzasadnienie: szybkie powstrzymanie zagrożenia z zachowaniem dowodów.

Krótkie polecenia wspierające wdrożenie:

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

Dzięki tym krokom NimbusPay osiąga warstwową ochronę (tożsamość, kryptografia, sieć i brzeg sieci), weryfikowalną zgodność, kontrolowaną ewolucję API pod jedną nazwą hosta oraz gotowość do wykrywania, powstrzymywania i odzyskiwania sprawności po incydentach.

← Sieci · Wszystkie domeny · Niezawodność →

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

Przeglądaj Google →