Panel dostawcy usług zarządzanych.
Od klucza CI/CD do innego tenanta.

Separacja klientów musi istnieć także w automatyzacji

W skrócie: w zbiorczym scenariuszu opartym na autoryzowanych testach środowisk chmurowych dostęp do testowego repozytorium ujawnił sekret używany przez potok CI/CD. Poświadczenie pozwalało przyjąć nadmiarową rolę, a wspólny komponent orkiestracji nie wymuszał pełnej separacji tenantów. Kontrolowany test potwierdził możliwość odczytu syntetycznego sekretu należącego do innej organizacji.

• Kluczowe ryzyka: sekret długoterminowy, zbyt szerokie trust policy, współdzielona automatyzacja i niewystarczająca izolacja namespace.
• Wpływ: naruszenie granicy odpowiedzialności dostawcy i potencjalny efekt łańcucha dostaw.
• Rezultat: federacja krótkoterminowa, per-tenant roles, policy-as-code i testy separacji.

Autor: Michał Błaszczak · 29 lipca 2026 · BSTA sp. z o.o.

Opis nie wskazuje dostawcy ani klienta

To zbiorcze case study. Nazwy chmur, kont, klastrów, repozytoriów, organizacji, polityk i narzędzi zostały uogólnione. Role oraz sekrety są syntetyczne. Materiał pokazuje klasę ryzyka, nie gotową instrukcję ataku na konkretne środowisko.

Uprawnienia rosły przy każdym przekroczeniu granicy systemu

Najważniejsze przyczyny techniczne

Architektura per tenant zamiast kontroli wyłącznie w kodzie

1. OIDC/workload identity i krótkoterminowe poświadczenia zamiast sekretów statycznych.
2. Osobne role i granice uprawnień dla klienta, środowiska i funkcji.
3. Izolacja namespace, NetworkPolicy, admission policies i brak wspólnych sekretów.
4. Policy-as-code testowana w CI oraz automatyczne testy negatywne między tenantami.
5. Detekcja nietypowego AssumeRole, odczytu sekretów i operacji w wielu tenantach.

Audyt bezpieczeństwa chmury, Kubernetes, CI/CD i platformy multi-tenant

Zakres nie ograniczał się do skanowania klastra Kubernetes. Zbadaliśmy drogę od kodu źródłowego i procesu budowania obrazu, przez registry, runner CI/CD i mechanizm wdrożeniowy, aż po chmurowe IAM, API panelu dostawcy, sekrety workloadów oraz granice pomiędzy klientami. Dla operatora MSP lub MSSP każdy z tych elementów jest częścią powierzchni ataku i łańcucha dostaw.

Test obejmował scenariusze black-box i assumed breach. W pierwszym ocenialiśmy publiczny panel, API oraz punkty administracyjne. W drugim otrzymaliśmy kontrolowany dostęp odpowiadający przejętemu kontu deweloperskiemu lub repozytorium i sprawdziliśmy, czy mechanizmy least privilege zatrzymają dalszą eskalację.

• cloud IAM: role, trust policies, service accounts, workload identity i ścieżki eskalacji;
• Kubernetes: RBAC, namespace, NetworkPolicy, admission control, sekrety i konta serwisowe;
• DevSecOps: repozytoria, pipeline, artefakty, registry, podpisywanie obrazów i ochrona branchy;
• multi-tenancy: autoryzacja obiektowa, izolacja danych, zadania asynchroniczne, eksporty i backupy;
• monitoring: CloudTrail lub odpowiedniki, audit log klastra, alerty IAM oraz korelacja w SIEM.

Dlaczego dostawca MSP lub MSSP powinien testować przekroczenie granicy tenanta

W środowisku jednego klienta podatność zwykle dotyczy jednej organizacji. U dostawcy usług zarządzanych błąd wspólnego komponentu może zwiększyć promień rażenia. Dlatego analizowaliśmy nie tylko to, czy użytkownik ma prawidłowy token, lecz także czy tenant jest wiązany z żądaniem na każdej warstwie: w API, kolejce zadań, cache, obiekcie chmurowym, namespace i systemie raportowym.

Najbardziej ryzykowne okazały się miejsca, w których system przechodził z kontekstu klienta do kontekstu operatora. Automatyzacja miała wykonać operację wygodnie, ale otrzymywała zbyt szerokie uprawnienia. Gdy dodatkowo długoterminowy sekret był dostępny dla procesu CI/CD, powstała ścieżka ataku łącząca supply chain, cloud privilege escalation i naruszenie izolacji tenantów.

Jak potwierdziliśmy wpływ bez pobierania danych klientów

Dowód rozpoczął się od kontrolowanego repozytorium i poświadczenia testowego. Zweryfikowaliśmy jego przeznaczenie, możliwość użycia poza konkretnym jobem oraz warunki przyjęcia roli. Następnie sprawdziliśmy zakres operacji wspólnego komponentu orkiestracji. Nie enumerowaliśmy danych klientów i nie kopiowaliśmy produkcyjnych sekretów.

Właściciel środowiska przygotował syntetyczny sekret w odrębnym tenancie testowym. Odczyt tej jednej wartości potwierdził, że granica organizacyjna może zostać przekroczona. W tym miejscu zatrzymaliśmy ścieżkę. Raport zawierał zapis żądań, identyfikatory kontrolnych zasobów, warunki powodzenia i minimalny zestaw kroków potrzebny zespołowi do odtworzenia problemu.

Takie podejście daje jednoznaczny dowód biznesowy, a jednocześnie respektuje NDA, minimalizację danych i bezpieczeństwo środowiska produkcyjnego.

Plan naprawczy dla chmury i platformy usług zarządzanych

Ograniczenie ryzyka w pierwszej kolejności

Natychmiastowa rotacja sekretów, zawężenie trust policy, blokada operacji między tenantami i dodatkowe alerty redukowały aktywną ścieżkę. Następnie statyczne klucze zastąpiono krótkoterminową tożsamością workloadu, związaną z repozytorium, środowiskiem i konkretnym pipeline.

Zmiana architektoniczna

Najsilniejszą kontrolą okazało się rozdzielenie ról i zasobów per tenant. Warstwa aplikacyjna nadal sprawdzała kontekst klienta, ale przestała być jedyną barierą. Dodatkowe granice uprawnień, osobne klucze, restrykcyjne RBAC, NetworkPolicy i testy policy-as-code ograniczyły skutki ewentualnego błędu w kodzie.

Detekcja i retest

Scenariusze SIEM objęły nietypowe AssumeRole, użycie poświadczeń poza pipeline, odczyt sekretów wielu organizacji i operacje administracyjne z nowej tożsamości. Retest sprawdził zarówno pierwotny PoC, jak i warianty obejścia poprzez zadania asynchroniczne i API.

Kiedy zamówić pentest chmury, Kubernetes lub platformy MSP/MSSP

Test warto wykonać przed uruchomieniem nowej platformy multi-tenant, po migracji do chmury, po zmianie modelu IAM, po wdrożeniu GitOps, po połączeniu kilku klastrów oraz przed dopuszczeniem kolejnej grupy klientów. Regularny pentest jest szczególnie ważny, gdy jedna automatyzacja zarządza zasobami wielu organizacji.

Do wyceny przydają się: używane chmury, liczba kont i klastrów, model tenantów, lista repozytoriów i pipeline, rodzaje tożsamości, krytyczne procesy oraz możliwość przygotowania zasobów kontrolnych. Prace zaczynamy typowo do 7 dni od podpisania umowy, a realizacja zajmuje od 5 dni roboczych. Ostateczny termin zależy od zakresu i potwierdza go oferta.

Zobacz: testy bezpieczeństwa chmury i Kubernetes od 4 999 zł, testy penetracyjne API, SOC/SIEM oraz bezpłatna wycena pentestu.

Najczęstsze pytania o pentest cloud, Kubernetes, MSP i MSSP

Czy audyt Kubernetes obejmuje także chmurowe IAM?

Tak, jeżeli warstwa IAM znajduje się w zakresie. Bez analizy ról, kont serwisowych i workload identity nie da się rzetelnie ocenić, co oznacza przejęcie poda lub tokenu klastra.

Czy potrzebny jest dostęp do kodu i konfiguracji?

Nie zawsze. Test black-box ocenia powierzchnię zewnętrzną, a grey-box lub assumed breach pozwala lepiej sprawdzić konfigurację, sekrety, RBAC i ścieżki eskalacji. Tryb dobieramy do celu badania.

Co to jest test separacji tenantów?

To kontrolowana próba wykonania operacji na danych lub zasobach innego klienta. Obejmuje API, zadania w tle, cache, storage, logi, backupy, role chmurowe i granice klastra.

Czy testujecie AWS, Azure i Google Cloud?

Test może objąć popularne środowiska public cloud, chmurę prywatną i rozwiązania hybrydowe. Zakres zależy od architektury, uprawnień udostępnionych do badania i reguł dostawcy.

Czy pentest CI/CD może zatrzymać wdrożenia?

Nie wykonujemy destrukcyjnych zmian bez wyraźnej zgody. Korzystamy z kontrolowanych repozytoriów, gałęzi i artefaktów, a ryzykowne scenariusze potwierdzamy bezpiecznym PoC.

Co otrzymuje klient po teście?

Klient otrzymuje podsumowanie zarządcze, mapę ścieżek ataku, opis podatności z CVSS i wpływem, dowody techniczne, zalecenia dla IAM/Kubernetes/DevSecOps oraz plan priorytetów. Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej.

Ile kosztuje pentest chmury lub Kubernetes?

Testy bezpieczeństwa chmury i Kubernetes zaczynają się od 4 999 zł netto. Cena zależy od liczby kont, subskrypcji, klastrów, ról, pipeline i zakresu separacji tenantów.

Ile trwa test środowiska cloud?

Realizacja testu zajmuje od 5 dni roboczych. Większe środowiska multi-cloud lub platformy MSP/MSSP wymagają dłuższego zakresu, który potwierdzamy w ofercie.

Dostawcy chmury, data center, MSP i MSSP mają szczególne wymagania dotyczące testów

Rozporządzenie wykonawcze UE 2024/2690 wymaga od wskazanych dostawców polityk i procedur testowania bezpieczeństwa. Rodzaj, zakres i częstotliwość testów mają wynikać z ryzyka; pentest jest jednym z wymienionych sposobów weryfikacji. Nie oznacza to identycznego corocznego pentestu dla każdego dostawcy, ale tworzy mocną podstawę do regularnych testów separacji klientów i łańcucha dostaw.

Źródła: Rozporządzenie (UE) 2024/2690, CIS Controls i OWASP API Security.