Google ACE: Hierarchia zasobów, IAM i administracja rozliczeniami — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Przegląd

Hierarchia zasobów, zarządzanie tożsamością i dostępem (IAM) oraz administracja rozliczeniami tworzą płaszczyznę sterowania (control plane) operacjami w Google Cloud. Odporna architektura zaczyna się od przejrzystej hierarchii (organizacja, foldery, projekty) w celu określenia zakresu polityk i odpowiedzialności; stosuje zasadę najmniejszych uprawnień (least-privilege) w IAM z administracją opartą na grupach i krótkotrwałymi poświadczeniami dla workloadów; wykorzystuje budżety, eksporty i etykiety do atrybucji kosztów; oraz wymusza ład korporacyjny (governance) za pomocą polityk organizacji i kompleksowego logowania audytowego. Doskonałość operacyjna wynika ze standaryzacji opartej na dziedziczeniu, centralizacji rozliczeń i logów oraz używania personifikacji kont serwisowych (service account impersonation) zamiast długotrwałych kluczy. Ta sekcja szczegółowo opisuje podstawowe konstrukcje, ich zamierzone zastosowanie oraz typowe błędy, których należy unikać.

Hierarchia zasobów i model tożsamości

• Hierarchia zasobów

  • Organizacja: Węzeł główny (root node), tworzony za pomocą Cloud Identity lub Google Workspace. Jest właścicielem globalnych polityk (IAM, polityki organizacji, tagi).
  • Foldery: Opcjonalne grupowanie dla działów, środowisk (np. dev, prod) lub aplikacji. Przydatne do delegowania administracji i określania zakresu polityk.
  • Projekty: Granica administracyjna dla zasobów, API, limitów (quotas), IAM i powiązań z kontem rozliczeniowym. Większość zasobów Google Cloud jest podrzędna względem projektów.
  • Dziedziczenie: Polityki IAM i polityki organizacji są dziedziczone z góry na dół. Odmowy (denies) i ograniczenia (constraints) na wyższych poziomach mają pierwszeństwo. Planuj rozmieszczenie (organizacja → foldery → projekty) tak, aby zminimalizować wyjątki i potrzeby dostępu awaryjnego (break-glass).

• Podmioty (Principals)

  • Konta Google (użytkownicy), grupy Google, konta serwisowe (service accounts) oraz tożsamości zewnętrzne poprzez Workload Identity Federation.
  • Grupy Google powinny być głównym celem powiązań (bindings) dla dostępu ludzi, aby uprościć zarządzanie cyklem życia i przeglądy uprawnień.
  • Konta serwisowe reprezentują aplikacje lub usługi; preferuj tożsamość workloadu (workload identity) zamiast kluczy.

• Tożsamości workloadów

  • W Google Cloud: GCE/GAE/Cloud Run/GKE używają serwera metadanych (metadata server) do tworzenia krótkotrwałych tokenów dla przypisanego konta serwisowego.
  • Poza Google Cloud: Workload Identity Federation mapuje tożsamości zewnętrzne (OIDC/SAML/AWS) na konta serwisowe bez użycia statycznych kluczy.

• Kompromisy projektowe i typowe błędy

  • Rozproszone projekty bez struktury folderów powodują duplikację i dryf polityk.
  • Nadawanie ról bezpośrednio użytkownikom zwiększa nakład pracy; preferuj powiązania oparte na grupach.
  • Używanie domyślnego konta serwisowego Compute Engine z szerokimi uprawnieniami zwiększa ryzyko; twórz konta serwisowe z minimalnymi wymaganymi uprawnieniami (least-privileged) dla każdego workloadu.
  • Umieszczenie projektu w niewłaściwym folderze powoduje dziedziczenie nieprawidłowych polityk; używaj tagów lub przenoś projekty ostrożnie, z zachowaniem kontroli zmian.

Role IAM i projektowanie polityk

• Typy ról

  • Role podstawowe (Viewer, Editor, Owner): Szerokie, przestarzałe (legacy). Unikaj, z wyjątkiem ściśle kontrolowanego dostępu awaryjnego (break-glass).
  • Role predefiniowane: Przygotowane dla poszczególnych usług; preferowane w większości przypadków użycia.
  • Role niestandardowe: Agregacja uprawnień w zakresie organizacji lub projektu dla specyficznych potrzeb.
  • Role warunkowe: Warunki IAM (IAM Conditions, oparte na CEL) dodają kontekst, taki jak nazwa zasobu, folder, tagi lub czas; używaj ich do ograniczania potężnych ról.

• Zasady polityk

  • Zasada najmniejszych uprawnień (Least privilege): Nadawaj tylko minimalną wymaganą rolę w jak najwęższym zakresie (zasób/projekt/folder).
  • Separacja obowiązków (Separation of duties): Rozdzielaj obowiązki (np. administrator sieci vs. administrator bezpieczeństwa vs. administrator rozliczeń). Nie łącz w jednym podmiocie (principal) uprawnień do wdrażania i zatwierdzania.
  • Świadomość dziedziczenia: Powiązanie (binding) na poziomie organizacji/folderu wpływa na wszystkie podrzędne elementy; udokumentuj zamierzony zasięg (blast radius) przed zastosowaniem.

• Polityki Deny (odmawiające)

  • Polityka IAM Deny jawnie blokuje uprawnienia, nawet jeśli zostały one przyznane w innym miejscu; używaj jej jako bariery ochronnej (guardrails) (np. deny iam.serviceAccountKeys.create).
  • Polityka Deny ma pierwszeństwo; zapewnij udokumentowane procesy awaryjne (break-glass) z ograniczonymi czasowo wyjątkami.

• Przykłady

  • Kopiowanie roli niestandardowej ze środowiska dev do prod:

undefined

• Nadawanie uprawnień administratora SSH dla grupy za pomocą OS Login:

undefined

• Typowe błędy
  • Rola Editor nadana na poziomie organizacji lub folderu niezamierzenie propaguje się na wszystkie projekty.
  • Role warunkowe ze zbyt restrykcyjnymi warunkami mogą po cichu psuć automatyzacje; przetestuj je za pomocą Policy Troubleshooter przed wdrożeniem.
  • Role niestandardowe mogą nie zawierać nowych uprawnień; przeglądaj je okresowo.

Rozliczenia i administracja kosztami

• Konta rozliczeniowe i powiązania

  • Projekt musi być połączony z dokładnie jednym kontem rozliczeniowym, aby móc korzystać z płatnych usług.
  • Role: Billing Account Administrator zarządza kontem i metodami płatności; Billing Account User łączy projekty; Project Billing Manager zarządza powiązaniem rozliczeniowym projektu.
  • Centralizuj rozliczenia na jednym korporacyjnym koncie rozliczeniowym; migruj projekty, aktualizując ich powiązanie z kontem rozliczeniowym.

• Budżety, alerty i atrybucja

  • Budżety generują alerty, a nie limity wydatków. Użyj programatycznej naprawy (programmatic remediation) za pomocą Pub/Sub i Cloud Functions/Cloud Run, jeśli wymagane jest egzekwowanie limitów.
  • Eksportuj dane rozliczeniowe do BigQuery w celu codziennej/miesięcznej analityki kosztów i prognozowania; połącz je z etykietami i tagami zasobów w celu atrybucji.
  • Etykiety i tagi: Standaryzuj klucze (np. cost_center, env, app). Brakujące etykiety zmniejszają dokładność atrybucji.

• Analiza kosztów

  • Użyj eksportu do BigQuery, aby obliczać prognozy kroczące według SKU/usługi za pomocą SQL. Połącz z metadanymi zasobów (np. etykietami GCE) w celu uzyskania szczegółowych raportów.
  • W przypadku analizy wieloprojektowej agreguj dane ze wszystkich eksportów projektów lub eksportuj je do jednego centralnego zbioru danych (dataset).

• Częste pułapki

  • Brak skonfigurowanych budżetów dla nowych projektów; stwórz politykę automatycznego tworzenia budżetów przy tworzeniu projektu.
  • Brak eksportu do BigQuery oznacza ograniczony wgląd w dane historyczne; włącz go wcześnie, aby zbudować historię.
  • Prywatne karty kredytowe podpięte do projektów rozpraszają odpowiedzialność; skonsoliduj wszystko pod korporacyjnym kontem rozliczeniowym z odpowiednimi uprawnieniami IAM i profilami płatności.
  • Anomalie kosztowe w projektach z usługami współdzielonymi wymagają tagowania i polityki obciążeń krzyżowych (cross-charging).

Zarządzanie, zasady organizacyjne, audyt i rozwiązywanie problemów

• Zasady organizacyjne i ograniczenia (constraints)

  • Wymuszaj barierki ochronne (guardrails) za pomocą ograniczeń: blokuj zewnętrzne adresy IP na maszynach wirtualnych, ograniczaj regiony, uniemożliwiaj tworzenie kluczy, ograniczaj dozwolone usługi, wymagaj jednolitego dostępu na poziomie zasobnika (uniform bucket-level access), ograniczaj udostępnianie domen.
  • Kieruj zasady na podstawie hierarchii zasobów i doprecyzowuj je za pomocą tagów w celu obsługi wyjątków specyficznych dla danego środowiska.

• Cloud Identity i cykl życia użytkownika

  • Cloud Identity dostarcza katalog użytkowników, SSO i role administracyjne. Deleguj uprawnienia w wąskim zakresie (np. Group Admin, User Management Admin) i automatyzuj procesy dołączania, zmiany i odchodzenia pracowników (joiner-mover-leaver), aby aktualizować członkostwo w grupach i dostęp.
  • Używaj Access Approvals i Access Transparency w środowiskach o podwyższonej wrażliwości.

• Logowanie audytowe

  • Logi Admin Activity i System Event są zawsze włączone; logi Data Access muszą być jawnie aktywowane i mogą generować koszty.
  • Centralizuj logi, przekierowując zagregowane ujścia (sinks) z folderów/organizacji do projektu dedykowanego bezpieczeństwu. Zabezpiecz je za pomocą CMEK i ograniczonego dostępu.
  • Monitoruj logi Policy Denied, aby wykrywać konflikty z zasadami organizacyjnymi.

• Zestaw narzędzi do rozwiązywania problemów w środowiskach wieloprojektowych

  • Policy Troubleshooter: Diagnozuj, dlaczego dostęp jest dozwolony lub zabroniony, biorąc pod uwagę obowiązujące zasady IAM i reguły deny.
  • Cloud Asset Inventory: Odpytuj o powiązania IAM (bindings) i historię zasad w całej organizacji/folderach/projektach. Przykład:

undefined

• Logs Explorer: Filtruj według tożsamości (principal), metody i zasobu, aby śledzić działania w różnych projektach.
• Konfiguracje gcloud do przełączania kontekstu przez operatora:

undefined

• Typowe przyczyny awarii: konfliktujące zasady organizacyjne blokujące wdrożenia, brak logów Data Access utrudniający dochodzenia oraz uprawnienia IAM nadane w niewłaściwym zakresie (scope). Stwórz procedury (runbooks) i podglądy przed zmianą, aby zredukować MTTR incydentów.

Praktyczny scenariusz problemowy

Firma Aurelia Retail konsoliduje wiele zespołów i projektów po przejęciu. Musi scentralizować rozliczenia, wymusić spójne zarządzanie IAM i SSH na setkach maszyn wirtualnych Compute Engine oraz ustanowić ład korporacyjny (governance) przy minimalnych zakłóceniach.

1. Utwórz firmowe konto rozliczeniowe i połącz z nim projekty

• Uzasadnienie: Pojedyncze konto rozliczeniowe centralizuje metody płatności, środki (credits) i budżety. Nadaj rolę Billing Account User grupie odpowiedzialnej za migrację projektów, a rolę Project Billing Manager liderom zespołów, aby mogli ponownie podpiąć projekty bez nadawania nadmiernych uprawnień.
• Działanie: W konsoli utwórz konto rozliczeniowe. Dla każdego projektu zaktualizuj jego powiązanie z kontem rozliczeniowym. Natychmiast włącz eksport danych rozliczeniowych do BigQuery w centralnym projekcie analitycznym.

2. Standaryzuj hierarchię zasobów za pomocą folderów i tagów

• Uzasadnienie: Umieszczenie projektów w folderach środowiskowych (prod, nonprod) wspiera dziedziczenie barierek ochronnych (guardrails) i ukierunkowane wyjątki. Tagi pozwalają na precyzyjne kierowanie zasad organizacyjnych bez powielania drzew folderów.
• Działanie: Utwórz foldery dla środowisk prod i nonprod; przenieś do nich odpowiednie projekty. Zdefiniuj tagi env=prod|nonprod oraz identyfikatory aplikacji.

3. Wdróż zarządzanie IAM oparte na grupach, z zasadą najmniejszych uprawnień i podziałem obowiązków

• Uzasadnienie: Grupy upraszczają zarządzanie cyklem życia użytkowników i audytowanie. Podział ról między osoby wdrażające, administratorów bezpieczeństwa i sieci zmniejsza promień rażenia (blast radius).
• Działanie: Utwórz grupy Google dla app-operators, net-admins, sec-admins i billing-managers. Przypisuj predefiniowane role w zakresie folderu/projektu w zależności od potrzeb; unikaj ról podstawowych (basic roles).

4. Wymuś administrację SSH opartą na OS Login

• Uzasadnienie: Indywidualne klucze SSH przypisane do kont użytkowników zapewniają przypisywalny i odwoływalny dostęp. Role OS Login zarządzają kontami Linux poprzez IAM, eliminując potrzebę używania współdzielonych kluczy.
• Działanie: W każdym projekcie włącz metadane OS Login. Nadaj rolę compute.osAdminLogin grupie ops-admins. Przykład:

undefined

5. Zastąp klucze kont serwisowych impersonacją

• Uzasadnienie: Krótkożyciowe poświadczenia ograniczają ryzyko wycieku kluczy i upraszczają ich rotację. Logi audytowe rejestrują, kto podszywał się pod kogo, co poprawia identyfikowalność (traceability).
• Działanie: Nadaj rolę roles/iam.serviceAccountTokenCreator tożsamościom runnerów CI/CD na kontach serwisowych obciążeń roboczych (workload). Usuń klucze zarządzane przez użytkowników i zastosuj zasadę organizacyjną, aby zablokować tworzenie nowych.

6. Zastosuj zasady organizacyjne jako barierki ochronne (guardrails)

• Uzasadnienie: Ograniczenia (constraints) zapobiegają ryzykownym konfiguracjom we wszystkich projektach, jednocześnie pozwalając na wyjątki oparte na tagach tam, gdzie jest to uzasadnione.
• Działanie: Wymuś ograniczenia, aby zablokować zewnętrzne adresy IP w środowisku produkcyjnym, ograniczyć regiony do zatwierdzonych lokalizacji i wyłączyć tworzenie kluczy kont serwisowych. Użyj tagów, aby zezwolić na wyjątki dla określonych projektów z udokumentowanymi zgodami.

7. Ustanów zarządzanie kosztami

• Uzasadnienie: Budżety ostrzegają właścicieli przed przekroczeniem wydatków; eksport do BigQuery umożliwia atrybucję kosztów i prognozowanie. Etykiety i tagi mapują wydatki na zasoby do centrów kosztowych (cost centers).
• Działanie: Utwórz budżety dla każdego folderu i głównej aplikacji z powiadomieniami Pub/Sub. Wymuszaj zasady dotyczące etykiet za pomocą szablonów wdrożeniowych i walidacji zasad w CI.

8. Scentralizuj audyt i przyspiesz rozwiązywanie problemów

• Uzasadnienie: Zagregowane logowanie i inwentaryzacja zasobów (asset inventory) w całej organizacji przyspieszają dochodzenia i raportowanie zgodności.
• Działanie: Utwórz zagregowane ujścia (sinks) do projektu bezpieczeństwa z zasobnikami chronionymi przez CMEK. Włącz logi Data Access dla krytycznych usług (Cloud Storage, BigQuery). Używaj Cloud Asset Inventory do rutynowego skanowania powiązań IAM. Przeszkól operatorów z używania Policy Troubleshooter w przypadku problemów z dostępem oraz Logs Explorer do śledzenia logów Admin Activity/Data Access.

9. Operacjonalizuj zmiany za pomocą podglądów i wdrożeń etapowych

• Uzasadnienie: Walidacja efektów działania IAM i zasad przed ich wdrożeniem zmniejsza liczbę awarii.
• Działanie: Najpierw przetestuj zasady IAM i organizacyjne w środowisku nieprodukcyjnym. Używaj uruchomień na sucho (dry-runs) i symulacji zasad, jeśli są dostępne. W przypadku automatyzacji wdrożeń, wdrażaj wdrożenia kanarkowe (canaries) i plany wycofywania zmian (backout plans).

Takie podejście zapewnia scentralizowane rozliczenia i wgląd w koszty, przypisywalne zarządzanie SSH przez OS Login, IAM oparte na zasadzie najmniejszych uprawnień z wykorzystaniem impersonacji, silne kontrole prewencyjne dzięki zasadom organizacyjnym oraz solidne mechanizmy audytu i rozwiązywania problemów w nowym, wieloprojektowym środowisku.

Wszystkie domeny · Compute Engine i operacje na maszynach wirtualnych →

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

Przeglądaj Google →