Dlaczego lateral movement w środowisku wielochmurowym jest tak groźny
Osoba, która opanuje ruch boczny (lateral movement) w chmurze, nie musi od razu łamać wszystkich zabezpieczeń. Wystarczy jedno słabe konto, źle skonfigurowana rola lub nieprzemyślana integracja między chmurami, aby krok po kroku rozszerzyć zasięg incydentu na całą organizację. W modelu multi-cloud granice między „wnętrzem” a „zewnętrzem” są rozmyte, a atakujący wykorzystuje właśnie te szare strefy.
Kluczowe staje się nie tylko zatrzymanie pierwszego włamania, ale przede wszystkim ograniczenie możliwości poruszania się napastnika po środowisku po tym, jak już znalazł się w środku. Zrozumienie, jak w praktyce działa lateral movement w chmurach AWS, Azure i GCP oraz pomiędzy nimi, jest podstawą skutecznej obrony i projektowania architektury odpornej na incydenty.
Czym jest lateral movement w chmurze i czym różni się od on‑prem
Definicja ruchu bocznego w kontekście chmury
Lateral movement to zestaw technik, które napastnik wykorzystuje po początkowym włamaniu, aby przemieszczać się pomiędzy zasobami, kontami i systemami, eskalować uprawnienia oraz docierać do bardziej wrażliwych danych lub systemów. W klasycznych środowiskach on-prem ruch boczny oznaczał zwykle „skakanie” między maszynami w tej samej sieci lub domenie Active Directory.
W chmurze, a szczególnie w środowiskach wielochmurowych, lateral movement odbywa się nie tylko po sieci IP, ale w dużej mierze poprzez tożsamości, uprawnienia, tokeny i API. Atakujący nie musi skanować podsieci – może wywoływać API danej chmury, badać polityki IAM, enumerować role i szukać sposobu przejęcia kolejnych uprawnień.
Zamiast klasycznego „przeskoku z hosta A na host B”, w świecie cloud częściej dochodzi do scenariusza: „przejęcie jednego konta → wykorzystanie posiadanych ról → uzyskanie nowych tokenów → dostęp do innej subskrypcji lub innej chmury poprzez federację”. To fundamentalna różnica, która wpływa na sposób projektowania zabezpieczeń.
Różnice między ruchem bocznym on‑prem a w usługach chmurowych
W modelu on-prem głównym „paliwem” dla lateral movement są protokoły sieciowe (SMB, RDP, SSH, WMI), mechanizmy domenowe (Kerberos, NTLM) oraz błędy w segmentacji. Atakujący szuka otwartych portów, luk w systemach operacyjnych, słabych haseł lub podatności w aplikacjach.
W chmurze obraz jest inny:
główne wektory ruchu bocznego przebiegają przez API chmurowe (AWS API, Azure Resource Manager, GCP API),
kluczowym zasobem dla napastnika są tokeny dostępu, role i polityki uprawnień,
wiele usług to usługi zarządzane, nie mające klasycznego dostępu RDP/SSH, ale dające ogromne możliwości poprzez konfigurację i API,
tożsamości są bardziej rozproszone i federowane – łatwiej ukryć się za różnymi warstwami abstrakcji.
Dla obrony oznacza to konieczność monitorowania nie tylko logów systemów operacyjnych, lecz przede wszystkim logów zdarzeń chmurowych (CloudTrail, Activity Log, Audit Logs) oraz zdarzeń w systemach tożsamości (Entra ID / Azure AD, AWS IAM, IdP zewnętrzne).
Dlaczego środowiska wielochmurowe powiększają przestrzeń dla ruchu bocznego
W modelu single-cloud perymetr jest już i tak trudny do zdefiniowania. W multi-cloud sytuacja komplikuje się jeszcze bardziej. Atakujący może mieć do dyspozycji:
osobne modele IAM w każdej chmurze, często zarządzane przez różne zespoły, z różnymi standardami,
różne federacje tożsamości, łączące chmurę z IdP, SaaS i innymi chmurami,
wiele połączeń sieciowych między chmurami i on-prem (VPN, Direct Connect, ExpressRoute, peering, SD-WAN),
integracje na poziomie aplikacji i danych: replikacje baz, kopiowanie backupów, data lake’i obejmujące więcej niż jednego dostawcę chmury.
Każda z tych integracji może stać się „mostem” do ruchu bocznego. Jeśli architektura nie jest spójna, napastnik może wykorzystać najmniej dojrzały fragment (np. słabiej zabezpieczoną GCP używaną do eksperymentów) jako punkt startowy do bardziej krytycznych zasobów w Azure czy AWS.
Zmiana pojęcia perymetru w modelu multi‑cloud
Pojęcie „początkowego dostępu” traci ostre granice. Czy dostęp do Azure DevOps, który zarządza pipeline’ami wdrażającymi do AWS, to już „wewnątrz”, czy jeszcze „na zewnątrz”? Czy dostęp do SaaS z rolą integratora z GCP jest częścią perymetru? W praktyce perymetr przesuwa się w stronę tożsamości, urządzeń i zaufanych połączeń.
Model zero trust w chmurze zakłada, że żadne połączenie (również z innej chmury lub z własnej sieci) nie jest automatycznie zaufane. Każdy ruch musi być autoryzowany, logowany i – w miarę możliwości – oceniany pod kątem ryzyka. Z perspektywy lateral movement oznacza to dążenie do tego, aby nawet przy kompromitacji jednego elementu ścieżka do kolejnych zasobów była jak najdłuższa, bardziej widoczna i trudniejsza do przejścia.
Specyfika środowisk wielochmurowych a powierzchnia ataku
Typowe kombinacje środowisk i ich konsekwencje
Większość organizacji nie korzysta z jednej chmury w próżni. Częste są konfiguracje:
AWS + Azure – np. Azure jako główna platforma dla użytkowników końcowych i usług Office 365, AWS jako główna platforma aplikacyjna,
Azure + GCP – Azure dla systemów biznesowych, GCP dla rozwiązań analitycznych i machine learning,
Multi-cloud + on-prem / kolokacja – krytyczne systemy pozostają on-prem, a chmury służą do front-endów, integracji, testów.
Każdy taki zestaw oznacza więcej niż jedną domenę zaufania, więcej niż jedną przestrzeń adresową, a często także wiele niezależnych polityk bezpieczeństwa. Tam, gdzie jeden zespół adminów zarządza Azure, inny AWS, a trzeci infrastrukturą on-prem, powstają naturalne szczeliny procesowe i techniczne. Atakujący próbuje je wykorzystać, szczególnie jeśli standardy haseł, MFA, rotacji kluczy i przeglądów uprawnień nie są spójne.
Rozproszone tożsamości i złożony krajobraz IAM
Tożsamość w środowisku wielochmurowym może mieć wiele warstw:
kontrola użytkowników i urządzeń w Entra ID / Azure AD lub innym IdP (Okta, Ping, ADFS),
lokalne konta w poszczególnych chmurach (np. IAM User w AWS niewiązany z IdP),
konta serwisowe i tożsamości zarządzane (Managed Identities, Service Accounts, Workload Identities),
identyfikatory i tokeny pochodzące z systemów SaaS (np. GitHub, GitLab, CI/CD) mające dostęp do API chmur.
Ruch boczny w chmurze w dużej części polega na przechodzeniu między tymi warstwami. Przykład:
atakujący przejmuje konto dewelopera z MFA w Entra ID,
zyskuje dostęp do Azure DevOps i zapisanych tam service connection do AWS,
wyciąga klucze lub wykorzystuje role AWS IAM przypisane do pipeline’ów,
używa ich, aby uzyskać dostęp do konta AWS z dostępem do krytycznych danych.
Żadna pojedyncza warstwa nie wydaje się krytyczna, ale w kombinacji tworzą one ścieżkę lateral movement, którą trudno dostrzec, jeśli patrzy się tylko na jedną chmurę na raz.
Niespójne modele uprawnień i ich implikacje dla atakującego
Każda chmura ma własny model uprawnień:
AWS – IAM Users, Roles, Policies, konta organizacyjne (Organizations),
Azure – RBAC oparty na rolach, subskrypcjach, grupach zasobów, rola właściciela (Owner), Contributor, itp.,
GCP – projekty, foldery, organizacje, role (basic, predefined, custom), service accounts.
Z perspektywy bezpieczeństwa wyzwaniem jest to, że zespoły często przenoszą nawyki z jednej chmury do drugiej, nie biorąc pod uwagę różnic. Efektem są nadmierne uprawnienia, role „z wygody” nadające więcej niż trzeba lub ręcznie tworzone wyjątki.
Dla atakującego niespójność to szansa. Jeśli jedna chmura jest zabezpieczona restrykcyjnie, a druga „tymczasowo” ma włączone role właścicieli dla zbyt wielu osób, lateral movement może przebiegać przez tę słabszą stronę. Pivotowanie między chmurami staje się możliwe, gdy napastnik:
znajdzie konto z szerokimi uprawnieniami w chmurze mniej krytycznej,
odkryje integracje (np. pipeline’y, skrypty, integracje danych) z bardziej krytyczną chmurą,
z wykorzystaniem tych integracji uzyska dostęp do bardziej chronionych zasobów.
Mosty między chmurami: sieć, tożsamość, SaaS
Środowiska wielochmurowe są spojone przez różne „mosty”. Z perspektywy lateral movement to miejsca o szczególnie wysokim znaczeniu:
VPN, ExpressRoute, Direct Connect, Cloud Interconnect – łączą VPC/VNet między sobą i z on-prem, czyniąc z nich jedną logiczną sieć,
peering VPC/VNet – umożliwia komunikację między zasobami w różnych kontach czy subskrypcjach, nierzadko z minimalnymi filtrami,
federacje tożsamości – SAML/OIDC pomiędzy IdP a chmurami, a także między chmurami a SaaS,
integracje SaaS – narzędzia DevOps, systemy backupowe, platformy integracyjne, które mają dostęp do wielu chmur jednocześnie.
Każdy z tych elementów może zostać użyty jako punkt pivotu. Przykładowo: źle skonfigurowany routing w VPN może umożliwić skanowanie i ataki na zasoby w drugiej chmurze, a konto serwisowe w SaaS z tokenem do trzech różnych chmur pozwala na ruch boczny bez konieczności przełamywania zabezpieczeń sieciowych.
Źródło: Pexels | Autor: Tima Miroshnichenko
Typowy łańcuch ataku prowadzący do lateral movement w multi‑cloud
Początek: przejęcie pojedynczej tożsamości lub tokenu
Atak w środowisku multi-cloud często zaczyna się od prostego wektora: phishing, przejęcie sesji, token hijacking, malware kradnący zapisane sekretu z przeglądarki. Cele to:
konto użytkownika w IdP (np. Entra ID, Okta),
konto dewelopera w GitHub/GitLab/Bitbucket,
token dostępu do API chmury zapisany w konfiguracji CLI (np. AWS CLI, Azure CLI),
klucz dostępu CI/CD zapisany w pliku konfiguracyjnym.
Po przejęciu takich danych atakujący sprawdza, do czego realnie ma dostęp. Często pierwsza zdobycz wydaje się mało istotna („zwykły deweloper, bez roli admina”), ale właśnie takie konta bywają przepustką do dalszego ruchu bocznego.
Eskalacja uprawnień w jednej chmurze
Drugi krok to eskalacja w ramach jednej platformy. Atakujący bada polityki IAM, role, przypisania do grup i instancji. Typowe techniki obejmują:
wyszukiwanie ról, które można assume’ować (AWS AssumeRole, Azure role assignments dla Managed Identities),
wykorzystanie błędnych polityk, które pozwalają tworzyć/aktualizować własne uprawnienia,
wykorzystanie błędów w konfiguracji usług zarządzanych (np. funkcji serverless, które mogą wykonywać się z uprawnieniami administratora).
Przykładowy scenariusz: konto dewelopera w AWS ma prawo tworzyć nowe role lub aktualizować istniejące role przypisane do instancji EC2. Napastnik tworzy nową rolę z uprawnieniami administratora, przypisuje ją do bieżącej instancji lub funkcji Lambda, a następnie z jej poziomu generuje token z uprawnieniami administracyjnymi. W ten sposób przeskakuje z konta o niskych uprawnieniach na poziom konta organizacyjnego.
Rozszerzanie zasięgu w obrębie chmury: konta, subskrypcje, projekty
W środowisku multi-account (AWS), multi-subscription (Azure) lub multi-project (GCP) kolejnym celem jest przejście do innych przestrzeni logicznych:
w AWS – wykorzystanie trust relationships między kontami w Organizations,
w Azure – wykorzystanie ról przypisanych na poziomie Management Group lub całej subskrypcji,
w GCP – wykorzystanie kont serwisowych z uprawnieniami organizacyjnymi i ich kluczy.
Wiele organizacji ma centralne konta/projekty zarządzające logowaniem, siecią, tożsamością. Jeśli napastnik zdoła „wspiąć się” do takiego centralnego konta, lateral movement staje się znacznie prostszy – może tworzyć nowe połączenia, zmieniać polityki i otwierać sobie drogę do kolejnych środowisk (PROD, UAT, DEV).
Pivotowanie między chmurami przez połączenia sieciowe
Pivotowanie między chmurami przez połączenia sieciowe (kontynuacja)
Jeśli napastnik ma już kontrolę nad zasobem w jednej chmurze – maszyną wirtualną, kontenerem, funkcją serverless w sieci prywatnej – kolejnym krokiem jest rozpoznanie topologii sieciowej. Typowe działania obejmują:
enumerację tras (tablice routingu, konfiguracje gateway’y, VRF/VNet/VPC peering),
skanowanie portów i usług po prywatnych adresach IP w podsieciach przypisanych do innych chmur lub on-prem,
sprawdzenie konfiguracji security groups, NSG, firewalli oraz ACL-i pod kątem nadmiernie otwartych reguł „any‑any”.
Ruch boczny na tym etapie często wygląda jak „zwykły” ruch administracyjny. Źródłowy adres IP należy do zaufanej podsieci, a protokół to RDP, SSH, WinRM czy HTTPS do interfejsów API. Jeśli monitoring opiera się tylko na permit/deny z firewalli, a nie obserwuje konkretnych zachowań na poziomie hosta i aplikacji, pivot między chmurami może odbyć się bez wyraźnych sygnałów alarmowych.
Praktyczny przykład: maszyna w Azure pełni rolę jump hosta do systemów on‑prem. Po zestawieniu nowego połączenia VPN między on‑prem a AWS, ta sama maszyna „zobaczy” prywatne adresy VPC w AWS. Z punktu widzenia atakującego to dodatkowy segment, który można przeskalować. Jeśli na maszynie nie ma twardej segmentacji aplikacyjnej ani zasad just‑in‑time access, lateral movement przechodzi z Azure przez on‑prem do AWS niemal niezauważalnie.
Pivot przez warstwę tożsamości i federacje między dostawcami
Sieć to tylko jeden z poziomów. W środowiskach wielochmurowych równie istotne są ścieżki oparte na tożsamości – SSO, federacje, delegacje uprawnień. Typowe mechanizmy, które ułatwiają ruch boczny:
federacja SAML/OIDC z centralnym IdP do wielu chmur (np. Entra ID → AWS, Entra ID → GCP),
role AWS AssumeRoleWithSAML przypisane do grup Entra ID / Okta,
federacja między SaaS a chmurami (np. GitHub Actions OIDC do AWS/GCP/Azure).
Napastnik, który przejął konto w IdP albo uzyskał token refresh, może „przelogować się” do kolejnych chmur bez dotykania warstwy sieci. W praktyce wygląda to jak normalne użycie SSO – generowany jest token, przydzielana rola, a aktywność widoczna jest jedynie w logach audytowych IdP i providerów chmurowych.
Istotna jest relacja: grupa → aplikacja → rola. Jeśli grupa w IdP ma przypisaną aplikację „AWS Prod” z możliwością przyjęcia roli OrganizationAccountAccessRole, każde przejęcie członkostwa w tej grupie daje napastnikowi wejście na poziom całej organizacji AWS. W środowisku wielochmurowym takie powiązania potrafią być nieaktualne i słabo udokumentowane, co sprzyja przeoczeniom podczas przeglądu uprawnień.
Wykorzystanie SaaS i DevOps jako „mostu” między chmurami
Narzędzia CI/CD, repozytoria kodu i platformy integracyjne są wygodnym celem, ponieważ często łączą kilka chmur naraz. Typowy łańcuch wygląda następująco:
przejęcie konta w GitHub/GitLab/Bitbucket lub tokenu do ich API,
dostęp do sekcji z sekretami (Secrets, Variables, Environments),
odczyt kluczy i tokenów do wielu chmur jednocześnie,
uruchomienie pipeline’ów lub jobów w celu wykonania złośliwego kodu z uprawnieniami technicznymi.
Jeśli pipeline ma globalne uprawnienia (np. rola Contributor na poziomie całej subskrypcji Azure i jednocześnie rola AdministratorAccess w AWS), jedna kompromitacja w SaaS zamienia się w szerokie lateral movement w całym krajobrazie multi-cloud. Do tego dochodzą systemy backupu, monitoring (np. narzędzia APM) i platformy integracyjne iPaaS, które często mają stałe połączenia z VPC/VNet i tokeny do API.
Dodatkowym problemem jest to, że konta serwisowe w SaaS często są wyłączone z standardowych polityk bezpieczeństwa: mają długie okresy ważności tokenów, są wykluczone z wymogu MFA, a ich użycie jest słabo logowane. Z perspektywy napastnika to idealne wejście na scenę lateral movement.
Techniki obserwacji i detekcji lateral movement w środowiskach wielochmurowych
Modelowanie ścieżek ruchu bocznego zamiast patrzenia na pojedyncze zdarzenia
Tradycyjne podejście do detekcji opiera się na sygnałach typu: nieudane logowania, podejrzane adresy IP, nietypowe komendy. W multi-cloud potrzebne jest spojrzenie ścieżkowe: co się stało „przed” i „po” danym zdarzeniu w innych domenach zaufania. Przykładowy wzorzec:
logowanie użytkownika do Entra ID z nowej lokalizacji,
w krótkim czasie – wygenerowanie tokenu SAML do AWS,
następnie – utworzenie w AWS nowej roli z szerokimi uprawnieniami,
po chwili – zestawienie nowego połączenia VPC peering lub modyfikacja tablic routingu.
Każdy z tych kroków osobno może wyglądać akceptowalnie. Dopiero połączenie w jedną ścieżkę pokazuje typowy ruch boczny: wejście przez tożsamość, eskalacja w jednej chmurze, otwarcie mostu sieciowego do dalszej ekspansji.
Normalizacja logów z różnych chmur i IdP
Logi bezpieczeństwa w chmurach różnią się formatem, nazewnictwem pól i poziomem szczegółowości. Aby skutecznie wykrywać lateral movement, trzeba je znormalizować do wspólnego modelu (np. opierając się o typy zdarzeń: Authentication, Authorization, ResourceChange, NetworkFlow):
IdP – logi logowań, przydzielania tokenów, zmian w grupach i aplikacjach,
AWS – CloudTrail, VPC Flow Logs, CloudWatch Logs,
Azure – Entra ID Sign‑in Logs, Activity Logs, NSG Flow Logs, Defender for Cloud Alerts,
SaaS – logi z GitHub/GitLab/CI/CD, systemów ITSM, backupu.
Jeśli każde z tych źródeł trafia do innego SIEM-a czy w ogóle nie jest centralnie zbierane, budowanie obrazu ruchu bocznego jest praktycznie niemożliwe. Dopiero wspólne miejsce korelacji umożliwia wykrycie przejść między chmurami oraz powiązanie ich z jedną tożsamością lub hostem źródłowym.
Detekcja anomalii w użyciu ról, tożsamości i połączeń sieciowych
Zamiast ograniczać się do sygnatur, skuteczniejsze jest wykrywanie odchyleń od standardowego zachowania w danej organizacji. Kilka przydatnych przykładów:
nowe użycie roli między-chmurowej (np. AWS role dla SAML) przez użytkownika, który wcześniej jej nie używał,
wygenerowanie długotrwałego tokenu dostępu z konta, które zwykle korzysta z krótkich sesji interaktywnych,
zainicjowanie połączenia sieciowego z podsieci DEV w Azure do produkcyjnych VPC w AWS, co nie występowało w normalnym ruchu,
wykonanie operacji IAM (tworzenie ról, trust policies, service accounts) zaraz po pierwszym logowaniu z nietypowego kraju.
Opisane sygnały można powiązać z jedną „kampanią” ruchu bocznego, jeżeli stosuje się korelacje czasowe i atrybutowe: ten sam principal (user/service account), ten sam host źródłowy lub ten sam token pochodny.
Śledzenie pochodzenia (provenance) tokenów i poświadczeń
Znaczna część lateral movement w chmurze polega na generowaniu nowych tokenów na podstawie już posiadanego dostępu. Przykładowo: token OIDC uzyskany z IdP → token krótkotrwały STS w AWS → klucz dla aplikacji uruchamianej na EC2. Aby odtworzyć łańcuch ataku, potrzebne jest powiązanie:
kto (jaka tożsamość) wygenerował token,
na jakim urządzeniu lub zasobie chmurowym to zrobił,
jakie operacje wykonano z użyciem tego konkretnego tokenu.
Praktyczne podejście to dodawanie kontekstu „session id” lub „token id” do logów operacji oraz przechwytywanie informacji o delegacjach (np. w AWS – sourceIdentity, sessionContext). Bez takiej historii pochodzenia trudno jednoznacznie rozpoznać, że np. konto serwisowe zostało wykorzystane przez napastnika, a nie przez regularny pipeline.
Praktyczne techniki utrudniania lateral movement w multi‑cloud
Segmentacja oparta na ryzyku, a nie wyłącznie na granicach chmur
Silna segmentacja, która utrudnia ruch boczny, powinna bazować na krytyczności zasobów i ich funkcji biznesowej. Podział „AWS vs Azure vs GCP” jest zbyt prymitywny. Skuteczniejszy podział obejmuje:
strefy produkcyjne z danymi wrażliwymi (bez względu na chmurę),
strefy integracyjne/DMZ,
środowiska deweloperskie i testowe,
strefy narzędziowe (CI/CD, monitoring, backup).
Jeśli każda strefa ma jasno zdefiniowane zasady dostępu sieciowego i tożsamościowego, pivot np. z DEV w jednej chmurze do PROD w innej będzie wymagał przełamania kilku niezależnych barier. Kluczowe są:
minimalne reguły routingu między strefami (deny by default, precyzyjne allow),
oddzielne konta/subskrypcje/projekty dla stref o różnym poziomie ryzyka,
brak współdzielonych kluczy i kont serwisowych między strefami o dużej różnicy krytyczności.
Standaryzacja polityk IAM na poziomie organizacji
Ruch boczny korzysta z niespójności w modelach uprawnień. Tę powierzchnię da się zmniejszyć przez ujednolicenie kilku kluczowych zasad na poziomie całej organizacji, niezależnie od chmury:
zdefiniowane „profilowe” role (np. Developer, Operator, Auditor) z równoważnym zakresem w AWS, Azure i GCP,
centralne reguły dla kont uprzywilejowanych – odseparowane konta admin, silne MFA, brak stałych kluczy,
zakaz używania lokalnych kont IAM (np. AWS IAM Users) tam, gdzie można użyć federacji z IdP,
okresowe recertyfikacje uprawnień, prowadzone wspólnie dla wszystkich chmur i głównego IdP.
Dodatkowo warto wprowadzić tzw. guardrails techniczne – polityki organizacyjne, które uniemożliwią stworzenie zbyt szerokich ról (np. blokada roli z *:* w AWS na poziomie Organizations, zakaz przypisywania Owner poza określonymi grupami w Azure).
Ujednolicone podejście do kont serwisowych i sekretów
Konta serwisowe i sekrety to „paliwo” lateral movement. Typowe problemy obejmują długowieczne klucze, brak rotacji, przechowywanie w kodzie lub w konfiguracjach CLI. Praktyczne kroki utrudniające wykorzystanie ich przez napastnika:
maksymalne wykorzystanie krótkotrwałych tokenów i rozwiązań typu workload identity / managed identity,
centralne skarbce (Key Vault, Secrets Manager, Secret Manager) z audytem, zamiast sekretów w plikach konfiguracyjnych,
automatyczna rotacja kluczy i haseł – skrócenie „okna czasowego”, w którym przechwycone dane są użyteczne,
oddzielne konta serwisowe dla różnych chmur i środowisk, z minimalnym zakresem dostępu.
W praktyce dobrą taktyką jest założenie, że każdy artefakt mogący przechowywać sekret (repozytorium kodu, obraz kontenera, plik Terraform State, konfiguracja narzędzi CLI) zostanie kiedyś odczytany przez osobę nieuprawnioną. Jeśli sekrety tam w ogóle nie występują lub są krótkotrwałe, skala potencjalnego lateral movement znacząco maleje.
Wprowadzenie „just‑in‑time” i „just‑enough” dla dostępu uprzywilejowanego
Modele just‑in‑time (JIT) i just‑enough‑access (JEA) znacząco komplikują życie napastnikowi, bo ograniczają czas i zakres dostępnych uprawnień. W multi‑cloud mogą działać spójnie, jeśli:
dostępy administacyjne są nadawane tylko na żądanie (PAM, PIM, rozwiązania własne) z twardym logowaniem i zatwierdzeniem,
sesje uprzywilejowane mają maksymalnie krótką ważność tokenów,
część operacji administacyjnych wymaga „czystego” środowiska jump‑host / bastionu, bez dostępu do Internetu.
Napastnik, który przejął konto admina, ale bez aktywnej sesji uprzywilejowanej, ma znacznie utrudnione zadanie. Musi dodatkowo pokonać proces wnioskowania o podniesienie uprawnień, a to generuje zarówno ślady w logach, jak i możliwość reakcji w czasie rzeczywistym.
Kontrola i monitoring połączeń między strefami a Internetem
Ruch boczny potrzebuje kanału komunikacyjnego z infrastrukturą atakującego: C2, exfiltracja danych, zdalne zarządzanie malwarem. W środowiskach wielochmurowych punkty wyjścia do Internetu bywają liczne i słabo kontrolowane:
publiczne IP na VM, kontenerach, load balancerach,
serwisy PaaS z możliwością wykonywania outbound (Functions, App Service, Cloud Run, Cloud Functions),
serwery narzędziowe i jump‑hosty, które mają „tymczasowy” dostęp do Internetu, a potem już nikt nie wraca do ich konfiguracji,
domyślne wyjścia NAT dla całych VPC/VNet, bez podziału na strefy krytyczności.
Praktyczny model ograniczania powierzchni obejmuje kilka warstw:
centralne punkty wyjścia do Internetu (hub VPC/VNet, dedykowane projekty egress w GCP) z inspekcją ruchu (proxy, FW L7, DLP),
blokadę bezpośrednich publicznych IP dla zasobów z najbardziej wrażliwych stref,
statyczne listy dozwolonych destynacji dla ruchu wychodzącego z serwerów administracyjnych i narzędziowych,
telemetrię na poziomie DNS i HTTP(S), która pozwala szybko wychwycić nietypowe domeny C2, tunelowanie i masową exfiltrację.
Dobrze zaprojektowane punkty egress sprawiają, że atakujący – nawet jeśli zbuduje lateral movement między chmurami – ma dużo trudniejsze zadanie przy ustanowieniu stabilnego kanału C2 lub wynoszeniu danych w sposób niezauważalny.
Ograniczanie „kaskadowej” federacji i trustów między chmurami
Lateral movement w multi‑cloud bardzo często opiera się na łańcuchu federacji: IdP → Azure → AWS → GCP lub w dowolnej innej kombinacji. Każde ogniwo takiego łańcucha to potencjalny punkt eskalacji. Jeśli trust policies i federation settings są zbyt luźne, uzyskanie przyczółka w jednej chmurze może dać dostęp do wielu pozostałych.
Bezpieczniejsze podejście to budowa modelu gwiazdy, w którym:
główny IdP jest jedynym „źródłem prawdy” o tożsamości użytkowników,
każda chmura ufa bezpośrednio IdP (SAML/OIDC), ale nie ufa innym chmurom jako IdP dla użytkowników ludzkich,
federacje między chmurami (np. workload identity federation, STS/Workload Identity Pool) są wykorzystywane wyłącznie dla konkretnych workloadów, z bardzo wąskim zakresem ról.
Przy przeglądzie konfiguracji federation/trust przydaje się kilka prostych kryteriów:
czy dana relacja trust jest rzeczywiście potrzebna do działania systemu,
czy scope uprawnień, jakie nadaje, można zawęzić (resource‑level, condition‑level),
czy istnieje alternatywa w postaci bezpośredniej federacji z IdP, bez pośrednictwa innej chmury.
Eliminacja niepotrzebnych „podwójnych” i „potrójnych” trustów znacząco redukuje liczbę potencjalnych ścieżek ruchu bocznego, które atakujący może wykorzystać.
Konsekwentny hardening płaszczyzny kontroli (control plane)
Lateral movement w chmurze w mniejszym stopniu dotyczy samych serwerów, a w większym – płaszczyzny zarządzania: paneli, API i usług orkiestrujących. Jeśli atakujący przejmie konto z prawem wywoływania API zarządzających, może przeskakiwać między regionami, projektami, a nawet chmurami szybciej niż klasyczny malware w sieci on‑prem.
Hardening control plane powinien objąć spójne mechanizmy we wszystkich chmurach:
wymuszenie MFA + phishing‑resistant MFA dla dostępu do portali i API administracyjnych,
blokadę dostępu do paneli zarządzania z Internetu dla kont technicznych (VPN, ZTNA, dedykowane sieci administracyjne),
ograniczenia sieciowe do endpointów API (Private Endpoints, Private Service Connect, VPC Endpoints) tam, gdzie to możliwe,
separację kont i subskrypcji administracyjnych od tych, na których działają workloady biznesowe,
dedykowane logowanie i alertowanie dla operacji modyfikujących IAM, sieć, federation/trust i audit logging.
W praktyce wiele incydentów wygląda podobnie: po zdobyciu tokenu z wysokimi uprawnieniami atakujący w ciągu kilku minut tworzy nowe role, dodaje wyjątki w firewallach i wyłącza logowanie. Jeśli kluczowe operacje w control plane są objęte dodatkowymi barierami (approval, step‑up MFA, blokada z określonych lokalizacji), tempo lateral movement drastycznie spada.
Red teaming i scenariusze „purple” dla ruchu bocznego w chmurze
Teoretyczne modele zabezpieczeń często rozpadają się przy pierwszym praktycznym teście. Dlatego obok klasycznego pentestu usług chmurowych potrzebne są ćwiczenia red team / purple team nastawione konkretnie na ruch boczny.
Dobrze zaplanowany scenariusz obejmuje:
wejście przez realistyczny wektor (np. przejęta tożsamość w IdP, skompromitowany runner CI/CD, podatna aplikacja PaaS),
pivot w ramach jednej chmury (np. z konta deweloperskiego do roli operatorskiej),
wykorzystanie istniejących trustów/federacji do przeskoku do drugiej chmury,
próbę dotarcia do zasobów o najwyższej krytyczności (produkcyjne bazy danych, kluczowe repozytoria kodu).
Wspólna praca zespołów ofensywnych i defensywnych pozwala odpowiedzieć na kilka kluczowych pytań: jak szybko SOC zauważa podejrzane ścieżki, czy korelacja logów między chmurami w ogóle działa, ile czasu zajmuje izolacja zainfekowanego workloadu lub blokada tożsamości. Bez takich ćwiczeń wiele mechanizmów obronnych pozostaje jedynie „na papierze”.
Runbooki reagowania na incydenty z uwzględnieniem multi‑cloud
Lateral movement w środowisku wielochmurowym wymusza inny sposób projektowania procedur IR. Klasyczny runbook „wyłącz serwer, zresetuj hasła, przejrzyj logi AD” nie wystarcza, jeśli jedna tożsamość ma dostęp do kilku chmur, dziesiątek subskrypcji i setek kont serwisowych.
Skuteczny runbook powinien jasno określać:
jak szybko można globalnie zablokować tożsamość w IdP i co to oznacza dla aktywnych sesji w poszczególnych chmurach,
które mechanizmy „kill switch” są dostępne w każdej chmurze (np. blokada tokenów, wymuszenie reautoryzacji, global deny policy),
jak odseparować poszczególne strefy i chmury od siebie (zmiana routingu, wyłączenie peeringów, blokada VPN),
kto ma prawo decydować o działaniach ingerujących w produkcję w konkretnej chmurze i jak eskalować decyzje.
Dobrą praktyką jest przygotowanie kilku typowych wzorców runbooków, np. „kompromitacja konta uprzywilejowanego”, „przejęcie runnera CI/CD”, „wyciek klucza konta serwisowego”. Każdy z nich powinien mieć warianty dla AWS, Azure, GCP oraz krok opisujący, jak sprawdzić i zablokować potencjalne ścieżki między chmurami.
Automatyzacja reakcji na podejrzane ścieżki ruchu bocznego
Ręczna reakcja na incydent w multi‑cloud jest z natury zbyt wolna. Atakujący, który porusza się głównie po control plane, może w kilka minut pozostawić trwałe ślady w postaci nowych ról, kluczy czy trustów. Dlatego potrzebne są zautomatyzowane playbooki reagujące na wczesne sygnały lateral movement.
Przykładowe akcje automatyczne, które sprawdzają się w praktyce:
tymczasowa blokada lub zawężenie roli w kilku chmurach jednocześnie po wykryciu nietypowej aktywności z nowego kraju lub sieci,
natychmiastowe wygaszenie tokenów i wymuszenie ponownego logowania, jeśli wykryty zostanie podejrzany wzorzec użycia (np. skrypty API z konta typowo interaktywnego),
odcięcie konkretnego segmentu sieciowego od peeringów i VPN po wykryciu nietypowego skanowania między chmurami,
zablokowanie tworzenia nowych trustów lub ról z uprawnieniami administracyjnymi, jeśli akcja nie jest związana z zatwierdzoną zmianą (integracja z systemem change management).
Automatyzacja powinna być parametryzowana – inny poziom agresywności dla środowisk deweloperskich, a inny dla produkcyjnych systemów krytycznych. Lepiej jednak tolerować kilka „fałszywie pozytywnych” blokad w DEV niż pozwolić, by atakujący bez przeszkód rozprzestrzeniał się między chmurami.
Integracja zarządzania konfiguracją i zgodnością między chmurami
Rozproszone narzędzia do zarządzania konfiguracją (IaC, policy as code, CSPM) mogą zarówno ograniczać, jak i ułatwiać lateral movement. Zależy to od tego, czy pozwalają spójnie egzekwować zasady, czy raczej utrwalają różnice między chmurami.
Skuteczny model to taki, w którym:
kluczowe polityki bezpieczeństwa (m.in. zakaz publicznych IP, obowiązek użycia krótkotrwałych tokenów, minimalne logowanie) są wyrażone w jednym, wspólnym zestawie reguł i tłumaczone na specyfikę poszczególnych chmur,
narzędzia CSPM/CNAPP wykrywają przede wszystkim „mosty” sprzyjające ruchowi bocznemu – nadmierne uprawnienia, otwarte peeringi, szerokie security group/NSG,
zmiany w konfiguracji, które wpływają na możliwości lateral movement (np. nowe trasy między VPC/VNet, nowy cross‑account role, nowe federacje) są objęte twardym procesem change management.
Jeśli zarządzanie konfiguracją jest w pełni zautomatyzowane, atakujący ma mniejsze pole do tworzenia „jednorazowych” ścieżek ruchu bocznego – każda manualna zmiana wyróżnia się w logach i w systemach kontroli zgodności.
Bezpieczne praktyki dla narzędzi developerskich i CI/CD
Systemy CI/CD oraz narzędzia developerskie to jeden z najczęstszych wektorów wejścia do chmury i wygodny punkt do dalszego ruchu bocznego. Z ich perspektywy poszczególne chmury są po prostu kolejnymi endpointami API, do których mają skonfigurowane dostępne poświadczenia.
Aby utrudnić pivot przez warstwę CI/CD:
stosuje się krótkotrwałe, per‑pipeline tokeny lub workload identity, zamiast statycznych kluczy zapisanych w systemie CI,
każdy pipeline ma osobny, minimalny zestaw uprawnień – brak „super‑pipeline”, który może zarządzać wszystkimi chmurami i środowiskami,
sekrety używane przez pipeline’y są trzymane w zewnętrznych skarbcach z audytem użycia, a nie w samym systemie CI,
dostęp interaktywny do runnerów/agentów jest wyłączony lub mocno ograniczony, a ich obraz jest regularnie odtwarzany z zaufanego źródła.
Incydenty, w których napastnik przejmuje pojedynczy pipeline i wykorzystuje go do wdrożenia złośliwych artefaktów w kilku chmurach, są szczególnie trudne do opanowania. Im bardziej podzielona i zdefiniowana jest odpowiedzialność poszczególnych pipeline’ów, tym krótsza i mniej groźna staje się możliwa ścieżka lateral movement.
Budowanie kompetencji zespołów wokół specyfiki multi‑cloud
Nawet najlepiej zaprojektowane mechanizmy techniczne nie zatrzymają ruchu bocznego, jeśli zespoły nie rozumieją różnic między chmurami i typowych technik ataków w każdej z nich. W praktyce częstym problemem jest silna specjalizacja „AWS‑owa” lub „Azure‑owa” bez szerszego spojrzenia.
Program rozwoju kompetencji może obejmować:
wspólne warsztaty dla zespołów bezpieczeństwa, platformowych i developerskich, oparte na realnych incydentach i ćwiczeniach typu „table‑top”,
rotacje między zespołami obsługującymi różne chmury, aby przenikały się dobre praktyki i wzorce zabezpieczeń,
regularne przeglądy architektury, w których analizuje się konkretne ścieżki potencjalnego ruchu bocznego między chmurami i strefami,
zestaw minimalnych, obowiązkowych szkoleń z zakresu IAM, sieci i logowania dla wszystkich osób mających dostęp do konfiguracji chmury.
Jeśli zespół rozumie, jak łatwo pojedyncza luka w jednej chmurze może otworzyć drogę do krytycznych zasobów w innej, decyzje projektowe i operacyjne stają się znacznie bardziej ostrożne. Multi‑cloud przestaje być zbiorem niezależnych silosów, a zaczyna być traktowany jako jeden, wspólny ekosystem, w którym lateral movement jest realnym, codziennym ryzykiem, a nie abstrakcyjnym scenariuszem.
Najczęściej zadawane pytania (FAQ)
Co to jest lateral movement w chmurze i jak działa w praktyce?
Lateral movement w chmurze to etap ataku, w którym napastnik, mając już jakiś dostęp, przemieszcza się między zasobami, kontami i usługami, aby zdobywać kolejne uprawnienia i docierać do ważniejszych systemów lub danych. Zamiast „skakać” po hostach w sieci, atakuje głównie tożsamości (użytkownicy, konta serwisowe), tokeny i API dostawców chmury.
Typowy schemat wygląda tak: przejęcie jednego konta → wykorzystanie przypisanych ról i uprawnień → wygenerowanie lub pozyskanie nowych tokenów → dostęp do kolejnych subskrypcji, projektów lub nawet innych chmur, jeśli istnieją federacje tożsamości lub integracje międzyplatformowe.
Czym różni się lateral movement w chmurze od ruchu bocznego w środowisku on‑prem?
W środowisku on‑prem ruch boczny opiera się głównie na protokołach sieciowych (RDP, SMB, SSH), mechanizmach domenowych (Kerberos, NTLM) i błędach w segmentacji sieci. Atakujący skanuje podsieci, szuka otwartych portów i podatnych hostów.
W chmurze kluczowe są:
wywołania API dostawcy (AWS API, Azure Resource Manager, GCP API),
polityki i role w systemach IAM,
tokeny dostępu oraz mechanizmy federacji tożsamości.
Z punktu widzenia obrony oznacza to konieczność silnego monitorowania logów zdarzeń chmurowych i systemów tożsamości, a nie tylko ruchu sieciowego i logów systemów operacyjnych.
Dlaczego lateral movement w środowisku wielochmurowym (multi‑cloud) jest szczególnie groźny?
W środowisku wielochmurowym rośnie liczba domen zaufania, modeli IAM i integracji. Każda dodatkowa chmura to nowe konto organizacyjne, nowy sposób nadawania ról, kolejny zestaw tokenów, a często także osobny zespół administrujący środowiskiem według innych standardów.
Atakujący szuka najsłabszego ogniwa: np. eksperymentalnego projektu w GCP z luźną kontrolą dostępu lub mało istotnego konta AWS używanego do testów. Jeśli istnieją połączenia sieciowe, integracje CI/CD, replikacje baz lub federacje tożsamości, z takiego „miękkiego” punktu startowego może przejść do bardziej krytycznych zasobów w innej chmurze.
Jak atakujący wykorzystuje integracje między AWS, Azure i GCP do ruchu bocznego?
Ruch boczny często odbywa się „po szwach” między chmurami, a nie tylko w ich wnętrzu. Przykładowe ścieżki to:
przejmowanie kont deweloperskich z dostępem do systemów CI/CD (np. Azure DevOps, GitHub) i używanie zapisanych tam poświadczeń do AWS lub GCP,
wykorzystanie federacji tożsamości (np. Entra ID → AWS IAM Role) do uzyskania tymczasowych tokenów w drugiej chmurze,
dostęp do replik danych, backupów lub data lake’ów obejmujących wielu dostawców chmurowych.
Jeśli integracje nie są projektowane w modelu „najmniejszych uprawnień” i nie są regularnie weryfikowane, stają się naturalnymi mostami dla lateral movement.
Jak ograniczyć lateral movement w środowisku multi‑cloud w praktyce?
Kluczowe działania to połączenie kilku obszarów: silne zarządzanie tożsamościami (centralny IdP, spójne MFA, brak lokalnych kont „poza systemem”), restrykcyjne modele uprawnień (least privilege, regularne przeglądy ról) oraz widoczność działań (logi CloudTrail, Azure Activity Log, GCP Audit Logs, logi IdP).
W praktyce oznacza to m.in.:
projektowanie integracji między chmurami jako relacji o ściśle ograniczonym zakresie,
segregację środowisk (prod/test/dev) także na poziomie tożsamości i ról,
automatyczne wykrywanie nadmiernych lub nieużywanych uprawnień,
stosowanie modelu zero trust – żadna ścieżka z jednej domeny zaufania do drugiej nie jest domyślnie bezpieczna.
Celem nie jest pełna eliminacja ruchu bocznego (to nierealne), tylko jego maksymalne utrudnienie i uczynienie go dobrze widocznym.
Jakie są typowe błędy organizacji sprzyjające lateral movement w chmurze?
Często pojawiają się te same wzorce:
niespójne wymagania bezpieczeństwa między chmurami (inne zasady haseł, MFA, rotacji kluczy),
pozostawione lokalne konta IAM (np. w AWS) poza centralnym IdP,
nadawanie ról „Owner/Contributor/Admin” „na wszelki wypadek” i brak późniejszego ograniczania zakresu,
brak widoczności w logach jednej z chmur, bo jest traktowana jako „poboczna”.
W efekcie powstają ścieżki ataku, które są niewidoczne z perspektywy pojedynczego zespołu (np. zespół Azure nie widzi konsekwencji błędów w GCP, a zespół on‑prem nie śledzi integracji CI/CD do AWS).
Jaką rolę odgrywa model zero trust w obronie przed lateral movement w multi‑cloud?
Zero trust przesuwa „perymetr” z sieci na tożsamości, urządzenia i połączenia. W praktyce zakłada, że nawet ruch z „zaufanej” chmury lub własnego data center nie jest automatycznie bezpieczny i musi być jawnie autoryzowany i monitorowany.
Z perspektywy lateral movement chodzi o to, aby:
nie istniały domyślnie zaufane mosty między chmurami i on‑prem (np. pełne zaufanie sieciowe VPN/peering bez dodatkowej kontroli),
każdy krok atakującego wymagał nowej autoryzacji i generował ślad w logach,
kompromitacja jednego elementu (konto, subskrypcja, projekt) nie dawała prostego dostępu do całej reszty środowiska.
Im krótsze są „skoki” możliwe bez ponownego sprawdzenia tożsamości i kontekstu, tym trudniejsze staje się skuteczne lateral movement.
