Google PCD: Tożsamość, uwierzytelnianie i bezpieczeństwo aplikacji — Przewodnik do nauki

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Przegląd

Tożsamość to nowy obwód zabezpieczeń w Google Cloud. Aplikacje muszą uwierzytelniać podmioty (użytkowników, usługi) i autoryzować je w celu uzyskania dostępu do danych i interfejsów API na zasadzie najmniejszych uprawnień, jednocześnie chroniąc sekrety, klucze i łańcuch dostaw oprogramowania. Ta sekcja przedstawia kompleksowe praktyki projektowe i operacyjne, które łączą Google Cloud IAM, nowoczesne protokoły uwierzytelniania, zabezpieczenia sieci i API, szyfrowanie, logowanie oraz procesy reagowania. Nacisk kładziony jest na krótkotrwałe poświadczenia, scentralizowane zasady i warstwowe mechanizmy kontroli, które zapewniają bezpieczne działanie w razie awarii.

Tożsamości, uwierzytelnianie i kontrola dostępu

Role IAM i konta usług
- Używaj hierarchii zasobów (organizacja > folder > projekt) i predefiniowanych ról zamiast ról podstawowych (primitive roles). Preferuj role niestandardowe tylko wtedy, gdy role predefiniowane są zbyt szerokie.
- Przypisuj konta usług (SA) do obciążeń (workloads). Nie używaj ponownie domyślnych kont usług Compute Engine ani App Engine. Jedno konto usługi na granicę obciążenia upraszcza zasadę najmniejszych uprawnień i rotację zaufania.
- Wymuszaj zasadę najmniejszych uprawnień, przyznając minimalny zestaw uprawnień w jak najwęższym zakresie zasobów.
- Impersonifikacja: Preferuj krótkotrwałe poświadczenia za pośrednictwem roli Service Account Token Creator, aby umożliwić ludziom, systemom CI/CD lub innym usługom uzyskanie efemerycznego dostępu bez przechowywania kluczy:
  - Nadaj rolę roles/iam.serviceAccountTokenCreator na docelowym koncie usługi tożsamości wywołującej.
  - Przykład:

undefined

Workload Identity
- GKE: Użyj Workload Identity, aby powiązać konta usług Kubernetes z kontami usług Google; tokeny są automatycznie wstrzykiwane i wymieniane — bez kluczy JSON.
- Obciążenia zewnętrzne: Użyj Workload Identity Federation do wymiany poświadczeń OIDC/SAML (na przykład z GitHub Actions lub środowisk on-premise) na tokeny dostępu Google bez przechowywania długotrwałych kluczy.
Tryby awarii i kompromisy
- Zbyt szerokie role lub uprawnienia o szerokim zakresie prowadzą do możliwości ruchu bocznego (lateral movement). Brak uprawnień Token Creator blokuje przepływy impersonifikacji. Pliki kluczy JSON zwiększają promień rażenia naruszenia bezpieczeństwa.
Uwierzytelnianie użytkowników za pomocą OAuth 2.0, OpenID Connect i Google Identity
- Do uwierzytelniania użytkowników końcowych używaj OIDC z Google jako IdP lub korporacyjnym IdP; waliduj tokeny ID po stronie serwera. Do dostępu do API używaj tokenów dostępu OAuth 2.0 z odpowiednimi zakresami (scopes).
- Waliduj tokeny: weryfikuj iss, aud, exp, iat i podpis, używając JWKS dostawcy tożsamości (IdP); buforuj JWKS i wymuszaj rotację kluczy.
- Dla backendów aplikacji mobilnych/SPA preferuj przepływ Authorization Code z PKCE. Unikaj przepływów typu implicit.
- Dla komunikacji między usługami używaj przepływu OAuth 2.0 Service Account JWT lub mTLS; unikaj statycznych kluczy API.
- Przykład (impersonifikacja tokenu za pomocą gcloud):

undefined

Tryby awarii
- Brak walidacji aud/iss pozwala na ataki typu token confusion. Akceptowanie wygasłych tokenów lub brak rotacji JWKS zwiększa ryzyko. Używanie tokenów odświeżania (refresh tokens) w aplikacjach mobilnych naraża długotrwałe poświadczenia.
Identity-Aware Proxy (IAP) dla dostępu przez przeglądarkę
- Używaj IAP jako frontu dla aplikacji HTTP w Cloud Run, GKE lub Compute Engine bez osadzania logiki uwierzytelniania. Wymuszaj rolę „IAP-secured Web App User” w celu uzyskania dostępu.
- Aplikacje otrzymują podpisany nagłówek (x-goog-iap-jwt-assertion). Zweryfikuj token JWT, aby ufać tożsamości i adresowi e-mail użytkownika; nie polegaj na nagłówkach X-Forwarded-* do uwierzytelniania.
- Częste pułapki: ścieżki omijające IAP, błędnie skonfigurowany firewall backendu lub ufanie nagłówkom IP klienta bez zapewnienia integralności przez Cloud Load Balancing.

Sekrety, klucze i szyfrowanie

Secret Manager
- Przechowuj klucze API, hasła do baz danych i sekrety webhooków w Secret Manager. Polegaj na wersjonowaniu, kontroli dostępu IAM i dziennikach audytu.
- Wzorce dostępu
  - Pobieraj przy uruchomieniu i buforuj w pamięci; odświeżaj w odpowiedzi na sygnały o zmianie sekretu (powiadomienia Pub/Sub).
  - Unikaj wbudowywania sekretów w obrazy lub zmienne środowiskowe. Jeśli używasz zmiennych środowiskowych, upewnij się, że nigdy nie są logowane ani zapisywane w raportach o awariach.
- Rotacja
  - Automatyzuj za pomocą Cloud Scheduler + Cloud Functions/Run, aby tworzyć nowe wersje, aktualizować zależne komponenty i wycofywać stare wersje.
  - Przykład:

undefined

Tryby awarii
- Nadmierne wywołania Secret Manager na żądanie zwiększają opóźnienia i ryzyko wyczerpania limitów (quota). Brak roli roles/secretAccessor powoduje błędy 403 w czasie działania.
Cloud KMS i szyfrowanie na poziomie aplikacji
- Używaj szyfrowania kopertowego (envelope encryption): lokalnie generowany klucz szyfrowania danych (DEK) szyfruje dane; zarządzany przez klienta klucz Cloud KMS (CMEK) szyfruje klucz DEK (jako KEK).
- Regularnie rotuj klucze; zaplanuj ponowne szyfrowanie. Preferuj podejście „odszyfruj starym, zaszyfruj nowym” przy zapisie; masowe zadania ponownego szyfrowania danych w spoczynku (at-rest) są bardziej kosztowne.
- Włącz CMEK dla usług (BigQuery, GCS, Pub/Sub, Cloud SQL itp.), gdy jest to wymagane przez przepisy. Przechowuj klucze KMS w tym samym regionie co dane.
- Przykład CLI:
  - Szyfrowanie:

undefined

- Odszyfrowywanie:

undefined

Używaj dobrze sprawdzonych bibliotek kryptograficznych (na przykład Tink), aby uniknąć błędów implementacyjnych.
Tryby awarii
- Niezgodność lokalizacji uniemożliwia użycie CMEK. Odszyfrowywanie w Cloud KMS dla każdego żądania zwiększa opóźnienia; buforuj klucze DEK w pamięci z uwzględnieniem ich rotacji. Brak roli roles/cloudkms.cryptoKeyEncrypterDecrypter skutkuje błędami 403.

Bezpieczeństwo łańcucha dostaw, logowanie i reagowanie

Bezpieczeństwo łańcucha dostaw oprogramowania
- Przechowuj artefakty w Artifact Registry; wymuszaj skanowanie podatności. Przerywaj buildy w przypadku wykrycia CVE o wysokiej/krytycznej wadze, z wyjąciami od polityki, które są śledzone.
- Przypinaj wersje zależności i obrazów bazowych; unikaj tagu „latest”. Generuj i weryfikuj SBOM-y. Używaj Binary Authorization, aby wymagać podpisanych obrazów przed wdrożeniem.
- Podpisuj obrazy za pomocą Cosign i rejestruj ich pochodzenie (provenance); wdrażaj praktyki budowania zgodne z SLSA. Używaj Workload Identity Federation dla CI, aby wyeliminować klucze JSON.
- Scenariusze awarii
  - Nieprzypięte zależności pobierają podatne na ataki wersje. Pomijanie weryfikacji pochodzenia (provenance) pozwala na modyfikację obrazów. Przechowywanie danych uwierzytelniających do rejestru lub kluczy kont serwisowych w logach CI prowadzi do wycieku sekretów.
Logowanie i monitorowanie bezpieczeństwa
- Włącz Admin Activity i Data Access Audit Logs dla krytycznych projektów i usług. Przekieruj logi do dedykowanego projektu z ograniczonym dostępem.
- Twórz metryki w Cloud Logging dla nieudanych uwierzytelnień, odmów dostępu i błędów ewaluacji polityk; skonfiguruj alerty przez Cloud Monitoring.
- Przykład (pomysł na niestandardową metrykę typu licznik): Zliczaj wskaźnik błędów 401/403 na ścieżce /api/* i alertuj o odchyleniach od normy.
- Analiza i usuwanie zagrożeń (triage i remediacja)
  - Używaj Security Command Center do agregacji wyników; twórz playbooki dla kluczowych scenariuszy (wyciek klucza, atak brute force, anomalne zmiany w IAM).
  - Automatyzuj typowe działania naprawcze (unieważnianie tokenów, wyłączanie kluczy, rotacja sekretów, poddawanie kont serwisowych kwarantannie).
- Projektowanie z uwzględnieniem prywatności
  - Minimalizuj dane osobowe (PII); tokenizuj tam, gdzie to możliwe. Redaguj wrażliwe wartości z logów; używaj Cloud DLP do klasyfikacji. Stosuj polityki minimalnego okresu przechowywania i regionalnego składowania danych.
- Scenariusze awarii
  - Wyłączenie logów Data Access uniemożliwia wykrycie eksfiltracji danych. Etykiety o wysokiej kardynalności gwałtownie zwiększają koszty. Logowanie sekretów tworzy trwałe zagrożenie ich ujawnienia.

Praktyczny scenariusz problemowy

Firma Acme Retail buduje wielodostępny (multi-tenant) portal analityczny na Cloud Run z frontendem w React, API w Pythonie i zestawami danych BigQuery dla każdego klienta (tenanta). Wymagania obejmują SSO dla pracowników i klientów, izolację tenantów, zarządzanie sekretami i kluczami, prywatny dostęp do bazy danych, WAF i ograniczanie liczby zapytań (rate limiting) oraz solidne CI/CD bez długożyjących kluczy.

Podejście:

Ustanowienie tożsamości i zasady najmniejszych uprawnień

Utwórz dedykowane konto serwisowe Google dla każdego mikroserwisu (api-sa, ingest-sa). Nadaj role z najmniejszymi wymaganymi uprawnieniami na poziomie projektu lub zestawu danych (na przykład roles/bigquery.dataEditor dla zestawów danych tenanta).
Uzasadnienie: Konta serwisowe per usługa ograniczają promień rażenia (blast radius) i upraszczają rotację; role o wąskim zakresie redukują możliwość ruchu bocznego (lateral movement).

Użycie Workload Identity Federation dla CI/CD

Skonfiguruj GitHub Actions OIDC do podszywania się pod deployer-sa za pomocą ról roles/iam.workloadIdentityUser i roles/iam.serviceAccountTokenCreator. Wdrażaj na Cloud Run przy użyciu tokenów uzyskanych przez impersonację.
Uzasadnienie: Eliminuje klucze JSON z CI; krótkotrwałe dane uwierzytelniające zmniejszają ryzyko kradzieży.

Frontend i uwierzytelnianie użytkowników

Skonfiguruj IAP na HTTPS Load Balancerze przed usługami Cloud Run. Zintegruj Google jako IdP dla pracowników oraz IdP klienta poprzez federację. Ogranicz dostęp za pomocą roli „IAP-secured Web App User” do autoryzowanych grup.
Uzasadnienie: Scentralizowane uwierzytelnianie dla aplikacji przeglądarkowych; brak logiki uwierzytelniania w usługach; wsparcie dla SSO.

Walidacja tożsamości IAP w API

Weryfikuj nagłówek x-goog-iap-jwt-assertion w API; wymuszaj obecność claima tenant_id (mapowanego z grupy lub niestandardowego claima).
Uzasadnienie: Silna gwarancja tożsamości od IAP; osadzenie kontekstu tenanta w każdym żądaniu zapewnia spójną autoryzację w dalszych systemach.

Implementacja autoryzacji świadomej istnienia tenantów

Przechowuj polityki dla każdego tenanta i mapuj użytkowników do ról (viewer, analyst, admin). Przy każdym żądaniu sprawdzaj rolę i warunki ABAC (zgodność tenant_id, flagi funkcji).
Uzasadnienie: Łączy prostotę RBAC z elastycznością ABAC; eliminuje podatność IDOR poprzez wymuszanie zakresu ograniczonego do tenanta.

Sekrety i dostęp do bazy danych

Przechowuj hasła do bazy danych i tokeny API firm trzecich w Secret Manager; nadaj rolę roles/secretmanager.secretAccessor tylko kontu serwisowemu API. Uzyskuj dostęp do sekretów przy uruchomieniu i odświeżaj je po otrzymaniu powiadomień o rotacji z Pub/Sub.
Uzasadnienie: Brak zaszytych na stałe danych uwierzytelniających; audytowalny dostęp; terminowa rotacja bez konieczności restartów.

Szyfrowanie danych i CMEK

Utwórz pęk kluczy (keyring) i klucze Cloud KMS dla każdego środowiska. Włącz CMEK dla zestawów danych BigQuery i bucketów Cloud Storage. Używaj szyfrowania kopertowego (envelope encryption) dla wszelkich wrażliwych blobów przechowywanych przez aplikację.
Uzasadnienie: Klucze zarządzane przez klienta (CMEK) spełniają wymagania zgodności i zapewniają rozdzielenie obowiązków.

Prywatna łączność i perymetr usług

Użyj private service access dla prywatnego IP Cloud SQL. Utwórz perymetr VPC Service Controls dla projektu hostującego BigQuery i GCS; dodaj polityki Access Context dla dostępu administratorów korporacyjnych.
Uzasadnienie: Eliminuje publiczne ścieżki wyjściowe (egress); zmniejsza ryzyko eksfiltracji danych.

Bezpieczeństwo API, rate limiting, CORS i CSRF

Zastosuj politykę bezpieczeństwa Cloud Armor z zarządzanymi regułami WAF i ograniczaniem liczby zapytań (rate limiting) do zewnętrznego HTTP(S) LB; dostosuj białe listy (allowlists) dla adresów IP partnerów. Skonfiguruj restrykcyjny CORS (jawne źródła) dla API i używaj tokenów okaziciela (bearer tokens) w nagłówku Authorization; ciasteczka nie są używane.
Uzasadnienie: Łagodzi zagrożenia z listy OWASP Top 10 i nadużycia; zapobiega wyciekowi danych uwierzytelniających między domenami; unika CSRF dzięki niestosowaniu ciasteczek.

Wzmacnianie łańcucha dostaw

Przechowuj obrazy w Artifact Registry. Włącz skanowanie podatności i przerywaj buildy w przypadku krytycznych CVE. Podpisuj obrazy za pomocą Cosign i wymuszaj przez Binary Authorization wymaganie podpisów Acme w środowisku produkcyjnym.
Uzasadnienie: Zapobiega uruchamianiu niesprawdzonych artefaktów; utrzymuje weryfikowalne pochodzenie (provenance).

Logowanie, monitorowanie i alerty

Włącz Audit Logs i przekieruj je do scentralizowanego projektu. Utwórz metryki oparte na logach dla skoków błędów 401/403, permissionDenied z BigQuery i dostępu do Secret Manager. Alertuj o anomaliach i skonfiguruj testy dostępności (uptime checks) w Cloud Monitoring dla publicznych endpointów.
Uzasadnienie: Wczesne wykrywanie nieudanych uwierzytelnień i nadużyć; monitorowanie dostępności.

Playbooki incydentów i ćwiczenia z rotacji

Udokumentuj kroki w celu unieważnienia skompromitowanych kont serwisowych (wyłączenie, rotacja kluczy, unieważnienie tokenów), rotacji sekretów i ponownego szyfrowania nowymi wersjami kluczy KMS. Testuj kwartalnie.
Uzasadnienie: Przygotowana, powtarzalna reakcja minimalizuje przestoje i ryzyko ujawnienia danych.

Taki projekt zapewnia krótkotrwałe, weryfikowalne tożsamości na każdym etapie, spójną autoryzację świadomą istnienia tenantów, chronione sekrety i klucze, prywatne ścieżki danych oraz wzmocniony łańcuch dostaw, wraz z obserwowalnością i przepływami reakcji, które utrzymują odporność systemu na ataki i podczas rutynowych operacji.

← Dane aplikacji · Wszystkie domeny · Ciągłe dostarczanie →

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