Bezpieczeństwo chmury i Kubernetes sprawdzone jak realny łańcuch ataku.

Nie zawsze. Test może rozpocząć się od read-only review, konkretnej roli testowej albo perspektywy zewnętrznej. Zakres dobieramy do celu.

Nie. CIS daje punkt odniesienia dla konfiguracji, ale nie pokazuje automatycznie wykonalnego łańcucha ataku i wpływu biznesowego.

Tak. Obejmujemy konfigurację klastra, RBAC, sieć, workloady, sekrety, obrazy i możliwe ścieżki pod-node-control plane.

Tak, po uzgodnieniu bezpiecznych zasad, ograniczeń i kont testowych. Część walidacji może zostać wykonana w sposób pasywny.

Tak. Sprawdzamy privileged containers, hostPath, hostNetwork, capabilities, seccomp, AppArmor, obrazy uruchamiane jako root oraz możliwość zapisu do systemu plików. Oceniamy realną drogę z poda do węzła i zasobów klastra.

Tak. Analizujemy RBAC, ClusterRoleBinding, service accounts, impersonation, wildcard permissions i możliwość eskalacji przez tworzenie workloadów lub wiązań ról. Weryfikujemy uprawnienia w praktyce, nie tylko manifesty.

Tak. Sprawdzamy sekrety w manifestach, repozytoriach, zmiennych, obrazach, logach, etcd, CI/CD i zewnętrznych vaultach. Oceniamy rotację, zakres, szyfrowanie oraz możliwość użycia przejętego sekretu.

Tak. Weryfikujemy Pod Security Standards, admission control, polityki Kyverno/Gatekeeper, kontrolę rejestrów i zasady wdrażania. Sprawdzamy, czy użytkownik może ominąć politykę alternatywnym zasobem lub ścieżką wdrożenia.

Tak. Testujemy NetworkPolicy, ruch między namespace, egress, DNS, dostęp do control plane, metadanych chmurowych i usług zarządzanych. Sprawdzamy zarówno deklaracje, jak i rzeczywisty przepływ pakietów.

Tak. Szukamy publicznego kube-apiserver, kubelet, dashboard, etcd, metrics i paneli operatorskich. Weryfikujemy uwierzytelnianie, autoryzację, ograniczenia źródeł i możliwość wykorzystania zdobytych poświadczeń.

Tak. Analizujemy konfigurację API server, kubelet, runtime, CNI, CSI, ingress, operatorów i węzłów. Łączymy błędy konfiguracji z wersjami podatnymi i realnymi ścieżkami eskalacji.

Tak. Sprawdzamy workload identity, IAM roles for service accounts, metadata service, klucze w podach i dostęp do API chmurowego. Celem jest ustalenie, czy przejęty workload pozwala wyjść poza klaster.

Tak. Weryfikujemy certyfikaty, tokeny service account, OIDC, kubeconfig, rotację, konta użytkowników i mechanizmy dostępu awaryjnego. Sprawdzamy również poświadczenia pozostawione w pipeline i stacjach administratorów.

Tak. Oceniamy audit logs, zdarzenia control plane, runtime telemetry, wykrywanie exec do poda, zmian RBAC, tworzenia privileged workload i dostępu do sekretów. Raport zawiera rekomendowane scenariusze dla SOC/SIEM.

Tak. Zakres może objąć IAM, sieci, storage, funkcje serverless, sekrety, klucze KMS, logowanie, konta i usługi zarządzane. Test uzgadniamy z zasadami dostawcy oraz wymaganiami bezpieczeństwa środowiska produkcyjnego.

Tak. Sprawdzamy tokeny pipeline, runnerów, uprawnienia repozytorium, podpisy obrazów, provenance, podatne zależności i możliwość podmiany artefaktu. Analizujemy drogę od commitu do działającego workloadu.

Tak, po uzgodnieniu ROE, ograniczeń i okien testowych. Techniki o ryzyku wpływu walidujemy konfiguracją, kontrolowanym PoC lub w środowisku reprezentatywnym; dostępność i integralność produkcji mają pierwszeństwo.

Tak. Pokazujemy połączenie podatności, uprawnień i zaufania w formie attack path: punkt wejścia, eskalacja w klastrze, pozyskanie poświadczeń oraz dostęp do zasobów chmurowych. Każdy krok otrzymuje konkretne zalecenia.

Audyt analizuje konfigurację, architekturę i zgodność ustawień z dobrymi praktykami. Pentest kontrolowanie waliduje, czy błędne role, sekrety, usługi lub workloady dają realną ścieżkę dostępu i eskalacji. Najlepszy rezultat daje połączenie przeglądu konfiguracji z bezpiecznym potwierdzeniem wpływu.

Zakres obejmuje control plane, RBAC, service accounts, workloady, sekrety, admission, polityki sieciowe, rejestry, obrazy, węzły i integrację z chmurą. Sprawdzamy także ścieżkę od podatnego kontenera do innych namespace, węzła albo zasobów AWS, Azure lub GCP.

Test bezpieczeństwa chmury lub Kubernetes zaczyna się od 4 999 PLN netto. Ostateczna cena zależy od liczby kont i subskrypcji, klastrów, regionów, workloadów, dostawców oraz oczekiwanego poziomu dostępu. Po krótkim opisie architektury przygotowujemy zakres i wiążącą wycenę.

Tak. Analizujemy użytkowników, role, grupy, trust policies, service principals, federację, uprawnienia wildcard i możliwość eskalacji. Sprawdzamy również rzeczywiste użycie przejętych poświadczeń w granicach uzgodnionych Rules of Engagement.

Zasady zależą od dostawcy i rodzaju usługi. Przed testem weryfikujemy aktualne reguły AWS, Azure, GCP lub innej platformy, definiujemy dozwolone zasoby i wyłączamy działania mogące wpływać na innych klientów. Klient pozostaje właścicielem zakresu i wymaganych zgłoszeń.

Tak. Ocenie podlega konfiguracja klastra, integracja IAM, workload identity, RBAC, węzły, sieć, sekrety, ingress i usługi chmurowe. Uwzględniamy granicę odpowiedzialności dostawcy, ale skupiamy się na elementach kontrolowanych przez organizację.

Tak. Sprawdzamy relacje zaufania, federację tożsamości, VPN i połączenia prywatne, wspólne pipeline, sekrety oraz możliwość ruchu bocznego między dostawcami i infrastrukturą lokalną. Raport pokazuje ścieżki przekraczające granice pojedynczego konta lub platformy.

Zakres może obejmować oba elementy. Najpierw identyfikujemy błędne ustawienia i uprawnienia, a następnie bezpiecznie potwierdzamy wybrane ścieżki, na przykład dostęp do danych, przejęcie roli lub ruch z workloadu do chmury. Nie wykonujemy działań poza uzgodnionymi zasobami.

Tak. Sprawdzamy repozytoria, zmienne pipeline, workload identity, rejestry obrazów, artefakty, podpisy, zależności i uprawnienia runnerów. Celem jest ustalenie, czy zmiana kodu lub obrazu może prowadzić do przejęcia środowiska produkcyjnego.

Tak. Wyniki możemy mapować do CIS Benchmarks i wymagań bezpieczeństwa organizacji, a raport stanowi techniczny dowód weryfikacji konfiguracji oraz plan naprawczy. Nie zastępuje to pełnego audytu zgodności ani procesów zarządzania ryzykiem.

Wykonawca powinien rozumieć zarówno usługi chmurowe, jak i kontenery, IAM, sieć i CI/CD. Warto poprosić o przykładowy raport pokazujący pełne ścieżki ataku, bezpieczne PoC, priorytety i retest. Sama lista błędnych ustawień bez walidacji wpływu jest niewystarczająca.