Google Cloud Platform (GCP)

Ataki i Obrona

Google Cloud to złożony system, w którym bezpieczeństwo zaczyna się od tożsamości i przemyślanej organizacji zasobów. Nawet drobna luka konfiguracyjna — jak nieprawidłowo ustawiony klucz lub uprawnienie — może doprowadzić do przejęcia danych w skali całej organizacji. Przykłady takie jak wyciek danych z GCS, nadużycia kont serwisowych czy błędne polityki IAM pokazują, że nadmiarowe uprawnienia i brak segmentacji projektów to najczęstsze wektory ataku.



Struktura tożsamości i bezpieczeństwa w GCP

  • Projekty – podstawowa jednostka organizacyjna i granica bezpieczeństwa. Zasoby są domyślnie izolowane.
  • Organizacja (Organization) – najwyższy poziom hierarchii. Tu ustala się globalne zasady i centralne uprawnienia.
  • Użytkownicy i Grupy – długowieczne tożsamości ludzi. Dostęp przez Google Workspace lub Cloud Identity.
  • Konta serwisowe (Service Accounts) – tożsamości dla aplikacji. W GCP ich tokeny są dodatkowo ograniczane zakresem (Access Scope).
  • Polityki IAM – reguły przydzielające role i uprawnienia do zasobów. Wymagają regularnych przeglądów i ograniczenia do minimum.

Typowe zagrożenia

  • Nadmiarowe uprawnienia (np. roles/editor, roles/owner)
  • Klucze serwisowe pozostawione w publicznych repozytoriach
  • Publiczne zasoby (np. GCS z dostępem dla allUsers)
  • Błędy w trustach między projektami
  • Możliwość eskalacji uprawnień (np. setIamPolicy, actAs, create push subscription)
  • Nieusuwane HMAC Keys umożliwiające trwały dostęp

Dobre praktyki

  1. Zasada najmniejszych uprawnień – korzystaj z predefiniowanych lub własnych ról, przypisuj uprawnienia tylko do grup.
  2. Separacja środowisk – osobne projekty dla dev/stage/prod/log/security.
  3. Monitorowanie i alertowanie – Cloud Logging, Cloud Monitoring, Security Command Center.
  4. Audyt polityk IAM – regularne przeglądy, ograniczenie allUsers, rotacja kluczy.
  5. Zabezpieczenie kont serwisowych – Workload Identity Federation zamiast długowiecznych JSON key.


References