---
title: "Lista kontrolna wzmacniania zabezpieczeń GCP | Snow Tree"
url: "https://www.snow-tree.com/pl/gcp-security-hardening/"
---

Bezpieczna infrastruktura GCP

# Lista kontrolna wzmacniania zabezpieczeń GCP dla małych i średnich zespołów

Praktyczny poziom bazowy zabezpieczeń dla zespołów, które uruchamiają obciążenia produkcyjne w Google Cloud bez osobnego działu bezpieczeństwa. Zacznij tam, gdzie najbardziej prawdopodobne ścieżki do poważnego incydentu najłatwiej ograniczyć.

## Na tej stronie

1. [Typowe ścieżki zagrożeń w GCP](https://www.snow-tree.com/pl/#threat-paths)
2. [Tożsamość i dostęp](https://www.snow-tree.com/pl/#identity)
3. [Sieć i brzeg sieci](https://www.snow-tree.com/pl/#network)
4. [Dane i sekrety](https://www.snow-tree.com/pl/#data)
5. [Wzmacnianie zabezpieczeń GKE](https://www.snow-tree.com/pl/#gke)
6. [Wykrywanie i odzyskiwanie](https://www.snow-tree.com/pl/#detection)
7. [Lista kontrolna z priorytetami na 30, 60 i 90 dni](https://www.snow-tree.com/pl/#checklist)
8. [Oficjalne źródła](https://www.snow-tree.com/pl/#references)

## Typowe ścieżki zagrożeń w GCP

Większość incydentów w chmurze zaczyna się od niewielkiej luki w odpowiedzialności lub konfiguracji. Szukaj tych ścieżek, zanim zrobi to atakujący.

- Użytkownik, konto usługi lub tożsamość obciążenia z nadmiernymi uprawnieniami może sprawić, że jedne skradzione dane logowania dadzą szeroki dostęp do wielu projektów.
- Wystawiony na zewnątrz punkt końcowy zarządzania, port debugowania lub zbyt liberalna reguła zapory sieciowej mogą ominąć wszystkie mechanizmy kontroli zaprojektowane dla zwykłego ruchu aplikacji.
- Publiczny zasobnik pamięci masowej lub podpisany URL o zbyt szerokim zakresie mogą ujawnić dane klientów bez widocznego włamania do aplikacji.
- Porzucone obciążenia tworzą trwałe ryzyko, gdy stare obrazy, zapomniane przestrzenie nazw, nieużywane konta usługi i zasoby bez właściciela nadal można wdrożyć.
- Brakujące lub zbyt krótko przechowywane dowody audytowe utrudniają ustalenie, kto zmienił zasadę, kiedy zaczął się dostęp i do jakich danych dotarto.
- Nieprzetestowana kopia zapasowa to tylko nadzieja. Nieudane przywracanie, niepełna retencja i niedostępne klucze szyfrowania mogą zamienić zdarzenie związane z bezpieczeństwem w trwałą utratę danych.

## Tożsamość i dostęp

Traktuj tożsamość jako podstawową płaszczyznę kontroli. Każda osoba, proces automatyzacji i obciążenie powinny mieć odrębną tożsamość o ściśle określonym przeznaczeniu.

### Wyraźnie zaznacz granicę zasobów

Używaj organizacji i folderów do wyznaczania mechanizmów ochronnych, a środowiska deweloperskie, przedprodukcyjne i produkcyjne rozdziel na osobne projekty lub silniejsze granice zaufania. Stosuj zasady organizacji na najwyższym praktycznym poziomie, ograniczaj dozwolone usługi i nie współdziel projektów produkcyjnych między niepowiązanymi produktami.

### Przyznaj minimalną rolę w najwęższym zakresie

Wybieraj role predefiniowane lub niestandardowe zamiast szerokich ról podstawowych, przyznawaj je grupom i tożsamościom obciążeń oraz używaj warunków IAM tam, gdzie nazwa zasobu lub tag mogą zawęzić dostęp. Przeglądaj nieużywane uprawnienia i usuń stały dostęp do produkcji, który powinien przysługiwać wyłącznie w ramach procedury dostępu awaryjnego (break-glass).

### Usuń długoterminowe dane logowania

Używaj Workload Identity Federation for GKE, aby pody otrzymywały krótkotrwałe dane logowania bez eksportowanych kluczy kont usługi. Tam, gdzie to możliwe, blokuj tworzenie i przesyłanie kluczy za pomocą zasady organizacji, zinwentaryzuj pozostałe klucze i konfiguruj alerty dla ryzykownych zmian IAM w Cloud Audit Logs.

## Sieć i brzeg sieci

Załóż, że jakiś błąd aplikacji prędzej czy później będzie osiągalny z sieci. Ogranicz to, do czego ten błąd może uzyskać dostęp.

### Zacznij od domyślnej odmowy i dodawaj nazwane ścieżki

Używaj reguł zapory sieciowej VPC opartych na zasadzie minimalnych uprawnień oraz Kubernetes NetworkPolicies dla ruchu podów. Rozdziel środowiska na osobne sieci, udokumentuj każdą ścieżkę ruchu przychodzącego i usuń szerokie reguły debugowania, które zezwalają na porty zarządzania lub wszystkie protokoły z dużych zakresów adresów.

### Utrzymuj węzły i platformy sterowania jako prywatne

Wyłącz zewnętrzne adresy IP w węzłach GKE. Preferuj prywatny punkt końcowy platformy sterowania oparty na DNS, a gdy punktu końcowego IP nie da się uniknąć, ogranicz go za pomocą autoryzowanych sieci. Zapewnij obciążeniom świadomie zaprojektowaną ścieżkę ruchu wychodzącego zamiast szerokiego dostępu do internetu.

### Publikuj tylko świadomie udostępniane usługi publiczne

Udostępniaj aplikacje przez sprawdzoną bramę lub system równoważenia obciążenia, a nie przez przypadkowe adresy podów czy węzłów. Kończ połączenia TLS na certyfikatach zarządzanych, ograniczaj hosty i ścieżki ruchu przychodzącego, stosuj limity żądań i częstotliwości, a interfejsy administracyjne udostępniaj wyłącznie przez dostęp uwzględniający tożsamość.

## Dane i sekrety

Chroń dane w spoczynku, w transmisji i podczas użycia, a następnie udowodnij, że potrafisz je odzyskać. Wykrywanie danych jest częścią kontroli.

### Zapobiegaj przypadkowemu dostępowi publicznemu

Wymuszaj zapobieganie dostępowi publicznemu i jednolity dostęp na poziomie zasobnika w Cloud Storage. Klasyfikuj zasobniki według wrażliwości danych, ograniczaj dostęp do obiektów i kluczy, włącz logowanie dla danych o wysokiej wartości i używaj kluczy szyfrowania zarządzanych przez klienta tam, gdzie wymaga tego Twój model ryzyka lub zgodności.

### Nie trzymaj sekretów w obrazach ani w kodzie źródłowym

Przechowuj dane logowania w Secret Manager i przyznawaj dostęp konkretnej tożsamości obciążenia do konkretnej wersji sekretu. Rotuj sekrety świadomie i planowo, nie kopiuj ich do Git ani do obrazów kontenerów i nie traktuj zwykłych Kubernetes Secrets jako pełnej granicy ochrony.

### Testuj odzyskiwanie, a nie tylko tworzenie kopii zapasowych

Określ docelowy punkt odzyskiwania (RPO) i docelowy czas odzyskiwania (RTO), przechowuj kopie poza domeną awarii środowiska produkcyjnego i chroń dostęp do kopii zapasowych oraz kluczy szyfrowania przed tożsamością obciążenia. Zgodnie z harmonogramem przywracaj dane do izolowanego środowiska, weryfikuj je i zapisuj czas trwania oraz wszystkie kroki wykonywane ręcznie.

## Wzmacnianie zabezpieczeń GKE

GKE zabezpiecza zarządzaną platformę sterowania, ale za konfigurację klastra, przestrzenie nazw, zasady dopuszczania i obciążenia nadal odpowiadasz Ty.

### Niech przestrzenie nazw będą kontraktem izolacji

Rozdziel zespoły i środowiska na przestrzenie nazw lub klastry, przypisz w nich wąskie role Kubernetes RBAC i stosuj limity zasobów oraz NetworkPolicies. Unikaj uprawnień do zapisu w całym klastrze na potrzeby dostarczania aplikacji i nadaj każdemu obciążeniu własne konto usługi, gdy potrzebuje odrębnej tożsamości.

### Dopuszczaj tylko obrazy i konfiguracje, którym ufasz

Wymuszaj standard Pod Security na poziomie restricted lub równoważne reguły Policy Controller. Wdrażaj obrazy według niezmiennego skrótu (digest), skanuj je pod kątem luk w zabezpieczeniach, używaj Binary Authorization tam, gdzie liczy się pochodzenie, i odrzucaj nieoczekiwany dostęp do hosta, eskalację uprawnień oraz powiązania z rolą cluster-admin.

### Usuń zbędne uprawnienia kontenerów

Uruchamiaj kontenery jako użytkownik inny niż root, odbieraj uprawnienia (capabilities) systemu Linux, tam, gdzie to możliwe, używaj głównego systemu plików tylko do odczytu i stosuj profil seccomp RuntimeDefault. Nie montuj tokena konta usługi bez potrzeby, unikaj kontenerów uprzywilejowanych i przestrzeni nazw hosta, ogranicz uprawnienia konta usługi węzła do minimum i używaj Shielded Nodes oraz Container-Optimized OS.

## Wykrywanie i odzyskiwanie

Mechanizmy kontroli zawodzą. Polegaj na dowodach i przećwiczonych działaniach, a nie na przekonaniu, że nikt nie popełnił błędu.

### Zbierz potrzebne dowody

Przechowuj Cloud Audit Logs oraz logi systemowe i logi obciążeń GKE w centralnym miejscu, z okresem przechowywania dopasowanym do potrzeb dochodzeń. Włączaj logi audytu dostępu do danych wybiórczo dla danych wrażliwych, ograniczaj dostęp do logów i rejestruj zmiany administracyjne w IAM, zaporze sieciowej, pamięci masowej i konfiguracji klastra.

### Powiadamiaj o zmianach mających znaczenie dla bezpieczeństwa

Konfiguruj alerty dla publicznego udostępnienia pamięci masowej, szerokich zmian w zaporze sieciowej lub IAM, nieoczekiwanych kluczy kont usługi, odmów dopuszczenia, wystawienia platformy sterowania, powtarzających się błędów uwierzytelniania, wyłączonego logowania, nieudanych kopii zapasowych i wygasających certyfikatów. Kieruj każdy alert do właściciela wraz z krokami pozwalającymi go potwierdzić lub odrzucić.

### Przećwicz reagowanie

Napisz krótkie runbooki na wypadek wycieku danych logowania, upublicznienia danych, przejęcia obciążeń oraz utraty regionów lub projektów. Uwzględnij, kto może zatwierdzić działania ograniczające, jak odebrać dostęp, jak zabezpieczyć dowody i jak przywrócić usługę. Przetestuj runbooki z osobami, które będą z nich korzystać.

## Lista kontrolna z priorytetami na 30, 60 i 90 dni

Jeśli zaczynasz od niepełnego poziomu bazowego, ułóż prace tak, aby najpierw ograniczyć ekspozycję, a późniejsze przeglądy uczynić powtarzalnymi.

### Dni 1–30: zamknij oczywiste ścieżki

Zinwentaryzuj projekty i ich właścicieli, usuń nieużywane i długoterminowe dane logowania, sprawdź, czy logowanie audytowe działa, zablokuj publiczne zasobniki, przejrzyj najszersze reguły zapory sieciowej i uprawnienia IAM, zidentyfikuj luki w kopiach zapasowych środowiska produkcyjnego i napraw każdy publiczny punkt końcowy bez właściciela. Przypisz właściciela i termin do każdego ustalenia.

### Dni 31–60: spraw, aby poziom bazowy był powtarzalny

Przenieś konfigurację sieci, tożsamości i obciążeń do infrastruktury jako kodu podlegającej przeglądom oraz do dostarczania przez GitOps. Wdróż Workload Identity, prywatne węzły, Pod Security na poziomie restricted, weryfikację zaufanych obrazów, scentralizowane logi oraz alerty dla najważniejszych zmian.

### Dni 61–90: udowodnij skuteczność i ją utrzymaj

Przeprowadź testy przywracania i ćwiczenie sztabowe (tabletop) z obsługi incydentu, przejrzyj dostęp uprzywilejowany i terminy wygaśnięcia wyjątków, ponownie przeskanuj obrazy i zależności, sprawdź, czy właściciele otrzymują alerty, i zmierz pozostałe luki. Włącz kontrole w cykl regularnych przeglądów, zanim dowody się zdezaktualizują.

Potraktuj tę listę kontrolną jako punkt wyjścia. Snow Tree może wdrożyć ten poziom bazowy w ramach obsługi platformy zarządzanej lub ukierunkowanego projektu konsultingowego.

[Platforma zarządzana](https://www.snow-tree.com/pl/managed-platform/) [Konsulting](https://www.snow-tree.com/pl/consulting/)

## Oficjalne źródła

Gdy zmieniają się ustawienia domyślne platformy lub możliwości produktów, traktuj aktualne wytyczne Google jako techniczne źródło prawdy.

- [Google Cloud: Sprawdzone metody wzmacniania zabezpieczeń klastra GKE](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [Google Cloud: Sprawdzone metody zabezpieczania GKE](https://docs.cloud.google.com/docs/security/gke-security-bps)

Zarządzana platforma

## Powierz Snow Tree tworzenie, hosting i obsługę oprogramowania.

[Rozpocznij projekt](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)