Google PCA: Projektowanie organizacji, IAM i zarządzanie chmurą — 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

Projekt organizacji, IAM i ład organizacyjny (governance) tworzą fundament, na którym działają wszystkie architektury Google Cloud. Dobre projekty tworzą jasne granice administracyjne, minimalizują promień rażenia, umożliwiają stosowanie zasady najmniejszych uprawnień, kontrolują koszty i skalują się operacyjnie na wiele zespołów i środowisk. Ład organizacyjny powinien kłaść nacisk na bariery ochronne (guardrails) zamiast na bramki (gates): automatyzuj domyślne ustawienia, które są bezpieczne, mierzalne i odwracalne, jednocześnie delegując codzienną kontrolę zespołom najbliższym obciążeniu roboczemu.

Hierarchia zasobów i podstawy tożsamości

Zasoby Google Cloud tworzą ścisłą strukturę drzewiastą: Organizacja → Foldery → Projekty → Zasoby (na przykład instancje Compute Engine, buckety). Polityki IAM i ograniczenia Polityki Organizacji są dziedziczone w dół drzewa.

Kluczowe zasady projektowania:

• Używaj jednej Organizacji, aby scentralizować zarządzanie. Twórz Foldery najwyższego poziomu dla głównych granic administracyjnych (na przykład jednostki biznesowe, regiony lub środowiska regulowane vs. nieregulowane).
• W ramach każdej granicy twórz Foldery środowiskowe (prod, nonprod), aby stosować zróżnicowane polityki. W miarę możliwości utrzymuj projekty o zakresie ograniczonym do obciążenia roboczego (workload-scoped) i efemeryczne, aby zmniejszyć promień rażenia i ułatwić rozliczanie kosztów.
• Dziedziczenie: nadania uprawnień kumulują się (suma powiązań zezwalających od przodków i danego węzła). Polityki IAM Deny, jeśli są używane, mają pierwszeństwo i mogą blokować dostęp, nawet jeśli istnieje zezwolenie. Unikaj umieszczania szerokich ról wysoko w drzewie; promień rażenia jest duży, a cofnięcie zmian trudne.

Źródła tożsamości:

• Cloud Identity to płaszczyzna tożsamości dla pracowników. Zintegruj ze swoim korporacyjnym dostawcą tożsamości (IdP, SAML/OIDC), aby scentralizować uwierzytelnianie i cykl życia tożsamości (nowi pracownicy, zmiany stanowisk, odejścia). W razie potrzeby użyj Google Cloud Directory Sync do synchronizacji atrybutów i grup.
• Grupy są podstawowymi podmiotami (subjects) w IAM. Dostęp oparty na grupach umożliwia skalowalne zmiany i audytowalną własność. Stosuj wzorzec grupy-grup (np. net-admins, sec-admins, app-team-A) i ogranicz, kto może zarządzać członkostwem w grupach.
• Konta usług (service accounts) reprezentują obciążenia robocze. Preferuj podszywanie się pod konta usług (impersonation) z użyciem krótkożyciowych poświadczeń zamiast przechowywanych kluczy. Unikaj kluczy kont usług zarządzanych przez użytkownika; traktuj je jako wyjątki wymagające ścisłych zatwierdzeń i rotacji.
• Wzorce tożsamości dla obciążeń roboczych:
  • GKE Workload Identity wiąże konta usług Kubernetes z kontami usług Google, eliminując poświadczenia o zakresie całego węzła.
  • Workload Identity Federation umożliwia tożsamościom zewnętrznym (on-prem, inne chmury, GitHub Actions) uzyskanie krótkożyciowego dostępu do Google bez użycia kluczy. Używaj ograniczania do puli/dostawcy (pool/provider scoping) i warunków opartych na atrybutach, aby zawęzić dostęp.

Typowe błędy i sposoby ich łagodzenia:

• Nadawanie ról podstawowych (Owner/Editor/Viewer) na poziomie Folderu lub Organizacji prowadzi do wszechobecnego nadmiaru uprawnień. Używaj ich tylko w projektach awaryjnych (break-glass) o wąskim zakresie.
• Niekontrolowany rozrost grup z niejasną własnością podważa zasadę najmniejszych uprawnień. Wymuszaj stosowanie konwencji nazewnictwa, tagów celu i metadanych właściciela dla grup.
• Osierocone konta usług i nieaktualne powiązania kumulują ryzyko. Planuj cykliczne przeglądy dostępu i używaj IAM Recommender do redukcji niewykorzystywanych uprawnień.

Modele IAM, role i operacje dostępu

Role i powiązania:

• Role predefiniowane są przygotowane dla konkretnych usług i powinny być domyślnym wyborem.
• Role niestandardowe wypełniają luki, gdy role predefiniowane są zbyt ogólne. Twórz je z minimalnego zestawu uprawnień, które okazały się niezbędne; wersjonuj je i testuj.
• Role podstawowe (Viewer/Editor/Owner) są przestarzałe i zbyt szerokie. Unikaj ich na poziomie Organizacji i Folderów. Nie używaj roli Owner do codziennych operacji; zarezerwuj ją dla scenariuszy awaryjnych (break-glass) na platformie z silnymi kontrolami kompensacyjnymi.
• Warunkowe powiązania ról (IAM Conditions) ograniczają, kiedy i gdzie obowiązuje powiązanie, używając atrybutów takich jak

undefined

,

undefined

,

undefined

lub

undefined

. Używaj warunków do dostępu ograniczonego czasowo, dostępu do środowiska produkcyjnego ograniczonego tagami lub akcji ograniczonych do lokalizacji.

Zasada najmniejszych uprawnień i podnoszenie uprawnień:

• Oddziel obowiązki typu „odczyt”, „operacje” i „administracja”. Na przykład zespoły sieciowe, bezpieczeństwa i aplikacyjne otrzymują odrębne role w odrębnych zakresach.
• Używaj podnoszenia uprawnień just-in-time za pomocą przepływów pracy Access Approval lub automatyzacji opartej na systemie ticketowym, aby powiązać role ograniczone czasowo za pomocą warunków.

Polityki Deny i zagrożenia:

• Polityki IAM Deny mogą centralnie blokować ryzykowne uprawnienia (np.

undefined

). Polityka Deny ma pierwszeństwo przed zezwoleniem (allow) i obowiązuje dla całego poddrzewa. Weryfikuj je dokładnie; błędnie skonfigurowane polityki Deny mogą zablokować automatyzację lub zepsuć wdrożenia.

Audytowalność i przeglądy:

• Włącz logi Admin Activity na poziomie Organizacji; domyślnie są one przechowywane przez 400 dni. Dla wrażliwych usług włącz logi Data Access i przesyłaj je do BigQuery w celu długoterminowego przechowywania i audytu.
• Wdróż okresowe przeglądy dostępu: wylicz powiązania za pomocą Cloud Asset Inventory, porównaj je z rejestrami własności, usuń niewykorzystywane role sugerowane przez IAM Recommender i weryfikuj wygasanie wyjątków.

Przydatny przykład (powiązanie ograniczone czasowo i tagami):

undefined

Zarządzanie finansowe i bariery ochronne zasad organizacji

Architektura rozliczeń:

• Scentralizuj jedno lub więcej kont rozliczeniowych pod zarządem działu finansowego. Używaj wielu kont rozliczeniowych tylko wtedy, gdy jest to wymagane prawnie lub operacyjnie (na przykład dla oddzielnych podmiotów prawnych lub w modelach resellerskich).
• Łącz projekty z kontami rozliczeniowymi za pomocą automatyzacji; nie zezwalaj na ręczne łączenie poza zatwierdzonymi procesami (workflows).

Obciążenia zwrotne (chargeback) i wgląd w koszty:

• Używaj spójnie etykiet (labels) i tagów alokacji kosztów (cost allocation tags). Etykiety to metadane o dowolnym formacie służące do filtrowania i raportowania; tagi są hierarchiczne i mogą być używane w warunkach (Conditions) i politykach IAM. Włącz alokację kosztów dla wybranych tagów, aby pojawiały się w eksportach danych rozliczeniowych.
• Eksportuj dane rozliczeniowe do BigQuery w celu analizy; twórz pulpity nawigacyjne (dashboards) dla poszczególnych właścicieli, centrów kosztów i środowisk. Wymagaj, aby każdy projekt miał odpowiedzialnego właściciela i przypisany budżet.

Budżety i wykrywanie anomalii:

• Twórz budżety z alertami na poziomach folderów i projektów. Dodaj programistyczne reakcje (np. powiadamianie dyżurnego on-call, otwieranie zgłoszeń lub blokowanie zwiększania limitów), aby ograniczyć niekontrolowany wzrost wydatków.
• Używaj limitów (Quotas) i zobowiązań (CUDs) dostosowanych do przewidywanego użycia; monitoruj ich wykorzystanie.

Ograniczenia zasad organizacji (domyślnie bezpieczne):

• Wymuszaj bariery ochronne na poziomie organizacji lub folderu i zwalniaj je tylko w uzasadnionych przypadkach. Typowe ograniczenia:
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects ograniczające obrazy VM
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• Używaj VPC Service Controls, aby zmniejszyć ryzyko eksfiltracji danych dla wspieranych usług w obrębie wrażliwych perymetrów (perimeters).

Obsługa wyjątków od zasad:

• Wyjątki muszą być możliwe do wnioskowania, zatwierdzone, ograniczone czasowo i audytowalne. Preferuj użycie warunków IAM (IAM Conditions) do ograniczania zakresu wyjątków według tagu/czasu. Okresowo weryfikuj wyjątki i automatycznie je wygaszaj za pomocą potoków typu policy-as-code.

Przykładowa zasada organizacji (YAML) wyłączająca klucze konta usługi:

• name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
  • enforce: true Następnie zastosuj: gcloud org-policies set-policy policy.yaml

Strefy docelowe, usługi współdzielone, automatyzacja i modele operacyjne

Strefa docelowa (landing zone):

• Zapewnia wstępnie zabezpieczoną konfigurację bazową: Organization Policies, ujścia logów, strategia CMEK, Shared VPC, prywatny DNS, Cloud NAT, Private Service Connect, projekty audytowe i bezpieczeństwa oraz ograniczone katalogi obrazów.
• Oddzielne projekty hosta dla każdego środowiska w ramach Shared VPC. Administratorzy sieci kontrolują projekty hosta; zespoły aplikacyjne wdrażają zasoby w projektach usługowych podłączonych do właściwego hosta.

Fabryka projektów:

• Automatyzacja tworzenia projektów za pomocą infrastruktury jako kodu (IaC). Masowe tworzenie projektów z:
  • Prawidłowym umiejscowieniem w Folderze i powiązaniem z kontem bilingowym
  • Wstępnie przypisanymi grupami i rolami
  • Domyślnymi kontami usługowymi wyłączonymi lub z ograniczonymi uprawnieniami
  • Ujściami logów do centralnych projektów i bucketów z retencją
  • Predefiniowanymi budżetami, etykietami i tagami
• Użyj modułów Terraform lub Cloud Config Controller do skodyfikowania fabryki. Wymuszaj walidację polityk w CI przed zastosowaniem zmian.

Usługi współdzielone i izolacja:

• Centralizuj tożsamość, sieć, CI/CD, rejestry artefaktów i narzędzia bezpieczeństwa w dedykowanych projektach. Izoluj środowiska za pomocą Folderów i VPC; blokuj ruch boczny za pomocą reguł zapory sieciowej, oddzielnych perymetrów usług i odrębnych pęków kluczy Cloud KMS dla każdego środowiska.
• Używaj Private Service Connect i projektów producenta do publikowania usług współdzielonych dla konsumentów bez wystawiania publicznych punktów końcowych.

Logowanie audytowe i automatyzacja ładu korporacyjnego:

• Przekierowuj logi Admin Activity i Data Access do projektu audytowego. Skonfiguruj buckety na logi z CMEK i politykami retencji zgodnymi z wymaganiami.
• Używaj strumieni Cloud Asset Inventory do Pub/Sub oraz Cloud Functions/Cloud Run do wykrywania dryfu (np. publicznych bucketów) i automatycznego naprawiania lub otwierania zgłoszeń.
• Stos polityki jako kod:
  • Polityki Organizacji (Org Policies) i IAM jako kod przechowywane w repozytorium
  • Config Validator/Policy Controller dla zasobów KRM
  • Sprawdzanie polityk przed wdrożeniem w CI/CD
  • Zaplanowane zadania uzgadniające w celu ponownego zastosowania pożądanego stanu

Nazewnictwo zasobów i tagi:

• Wymuszaj krótkie, czytelne wzorce nazewnictwa, które kodują środowisko, aplikację, region i numer sekwencyjny (np. appA-prd-usw2-web-01). Zarezerwuj tagi do celów zarządczych (env=prod, pii=true, owner=team-x). Waliduj obecność wymaganych etykiet/tagów podczas tworzenia projektu.

Operacje wielozespołowe i delegowana administracja:

• Ustanów zespoły platformowe, bezpieczeństwa i sieciowe z jasno zdefiniowanymi zakresami odpowiedzialności i rolami. Deleguj administrację na poziomie projektu zespołom aplikacyjnym w granicach ich Folderu. Zapewnij samoobsługę w ramach barier ochronnych poprzez katalogi i szablony.
• Równoważ autonomię z ryzykiem, przekazując zespołom decyzje o małym promieniu rażenia i centralizując decyzje, które wpływają na wiele projektów lub infrastrukturę współdzieloną.

Praktyczny scenariusz problemowy

Firma Contoso Retail planuje wdrożyć osiem zespołów produktowych do Google Cloud w ciągu trzech miesięcy. Każdy zespół potrzebuje środowisk produkcyjnych i nieprodukcyjnych, izolowanej sieci, scentralizowanego logowania zdarzeń bezpieczeństwa i rozliczalności kosztów. Zespół platformowy musi zapobiegać niekontrolowanemu przyrostowi kluczy kont usługowych, ograniczać obrazy maszyn wirtualnych i umożliwiać ograniczony czasowo podwyższony dostęp na potrzeby reagowania na incydenty.

Podejście:

1. Ustanowienie hierarchii i folderów

• Utwórz Foldery najwyższego poziomu dla działów oraz zagnieżdżone Foldery dla środowisk produkcyjnych i nieprodukcyjnych. Uzasadnienie: jasne granice administracyjne pozwalają na stosowanie ukierunkowanych barier ochronnych i budżetów, jednocześnie umożliwiając delegowanie administracji zespołom produktowym bez przyznawania im uprawnień na poziomie całej organizacji.

2. Wdrożenie strefy docelowej z Shared VPC

• Utwórz projekty hosta dla sieci produkcyjnych i nieprodukcyjnych, zarządzane przez zespół sieciowy. Podłącz projekty usługowe zespołów za pośrednictwem Shared VPC. Uzasadnienie: centralizuje routing, NAT i polityki zapory sieciowej, jednocześnie izolując obciążenia robocze według projektów; zapobiega tworzeniu sieci ad hoc, co prowadzi do niekontrolowanego rozrostu i niespójnego bezpieczeństwa.

3. Wdrożenie barier ochronnych w postaci polityk organizacji

• Wymuś ograniczenia: wyłącz tworzenie kluczy kont usługowych, wymagaj OS Login, ogranicz publiczne adresy IP dla Cloud SQL, ogranicz obrazy VM do zaufanych projektów i włącz jednolity dostęp na poziomie bucketu. Uzasadnienie: podejście „domyślnie bezpieczne” redukuje często występujące błędy konfiguracyjne; wyjątki mogą być w razie potrzeby ograniczone czasowo.

4. Uruchomienie tożsamości i grup

• Zintegruj Cloud Identity z korporacyjnym dostawcą tożsamości (IdP); utwórz grupy dla każdej z ról (dev, ops, admin) w zespołach oraz grupy na poziomie platformy dla administratorów sieci i bezpieczeństwa. Uzasadnienie: IAM oparty na grupach skaluje się i jest zgodny z zasadą separacji obowiązków; cykl życia użytkowników podąża za zdarzeniami w dziale HR.

5. Zdefiniowanie IAM z zasadą najmniejszych uprawnień i warunkowym podnoszeniem uprawnień

• Przypisz predefiniowane role do grup na poziomie Folderu lub projektu; włącz podnoszenie uprawnień na czas reakcji na incydenty za pomocą warunkowych przypisań ograniczonych do zasobów z tagiem prod i wygasających po 24 godzinach. Uzasadnienie: zasada najmniejszych uprawnień na co dzień, z bezpieczną, audytowalną eskalacją w razie potrzeby.

6. Zbudowanie potoku fabryki projektów

• Użyj modułów Terraform do tworzenia projektów z wymaganymi etykietami/tagami (env, owner, cost-center), powiązania z kontem bilingowym, podłączenia do właściwego Shared VPC, utworzenia ujść logów do centralnego projektu audytowego i ustawienia budżetów. Uzasadnienie: spójne, zgodne z politykami provisionowanie na dużą skalę eliminuje ręczne odstępstwa od konfiguracji i przyspiesza wdrażanie nowych zespołów.

7. Scentralizowanie logowania audytowego i przeglądów dostępu

• Przekieruj logi Admin Activity i Data Access do BigQuery z CMEK; zaplanuj comiesięczne zapytania w celu wyliczenia przypisań IAM i porównania ich z przynależnością do grup oraz danymi o ostatnim dostępie z IAM Recommender. Uzasadnienie: trwały ślad audytowy i ciągłe dopasowywanie dostępu redukują ryzyko i koszty.

8. Zarządzanie kosztami i alerty

• Włącz tagi i etykiety do alokacji kosztów, eksportuj dane bilingowe do BigQuery i ustawiaj budżety na poziomie Folderu i projektu z powiadomieniami dla działu finansów i liderów zespołów. Uzasadnienie: przejrzyste rozliczanie kosztów zwiększa odpowiedzialność; wczesne alerty ograniczają niekontrolowane wydatki.

9. Tożsamość obciążeń roboczych i automatyzacja bezkluczowa

• Dla GKE włącz Workload Identity; dla zewnętrznego CI (np. GitHub) skonfiguruj Workload Identity Federation z zakresem ograniczonym do określonych repozytoriów i z warunkami. Uzasadnienie: eliminuje długożyjące klucze i ogranicza użycie do zamierzonych obciążeń roboczych.

10. Proces obsługi wyjątków i automatyzacja

• Wdróż przepływ pracy dla wniosków, który tworzy warunkowe przypisania IAM lub tymczasowe złagodzenia polityk z automatycznym wygasaniem za pośrednictwem CI. Uzasadnienie: daje zespołom większe możliwości bez utraty kontroli; każdy wyjątek jest ograniczony czasowo i audytowalny.

Wyniki techniczne:

• Zespoły samoobsługowo tworzą nowe projekty w mniej niż 15 minut z domyślnymi ustawieniami zgodnymi z politykami.
• Klucze kont usługowych zarządzane przez użytkownika nie są dozwolone; podniesienie uprawnień na czas reakcji na incydent jest ograniczone czasowo i zakresem tagów.
• Koszty są agregowane według zespołu i środowiska, z automatycznymi budżetami i alertami o anomaliach.
• Logi audytowe i przeglądy dostępu stale weryfikują, czy uprawnienia i polityki są zgodne z zamierzeniami.

Wszystkie domeny · Moc obliczeniowa →

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

Przeglądaj Google →