Ochrona danych w chmurze: Nowe podejście do modeli zagrożeń

Chmura zmieniła kontekst, na którym specjaliści ds. bezpieczeństwa opierali analizę powierzchni ataku. Ataki nie odbywają się już w linii prostej na płaszczyźnie sieci, gdzie ruch można prześledzić na przewidywalnej warstwie stosu sieciowego. W chmurze, aby zaobserwować podejrzany ruch, należy go odnieść do infrastruktury na której działa.

Techniki atakujących a charakterystyka stosu technologicznego

Atakujący wykorzystują, to co dostępne i dostosowują swoją metodologię do stosu technologicznego, w ramach którego działają. Systemy lokalne mają często zainstalowany w pełni funkcjonalny system operacyjny - ta powierzchnia ataku może zostać wykorzystana do przejścia ze zhakowanej stacji roboczej do widocznego z niej serwera w centrum danych ofiary.

Serwery nie są odizolowane, są połączone ze sobą za pośrednictwem sieci, poprzez którą atakujący mogą przenosić się z jednego hosta na drugi.

– W tradycyjnej architekturze centrów danych często można zaobserwować luźniejsze reguły ruchu wychodzącego. To właśnie na tej ścieżce sieciowej atakujący dążą do ustanowienia trwałego dostępu poprzez techniki Command-and-Control i wyciągania danych na zewnątrz zaufanej sieci – wyjaśnia Christian Putz, Country Manager w Vectra AI.

Przebieg ataku na system lokalny przedstawiony na powyższym diagramie zależy od powierzchni dostępnej dla atakującego. W sekcji dotyczącej architektury chmury, będzie można zauważyć, że zasady dobierania drogi ataku pozostają te same, stos technologii determinuje taktykę i techniki stosowane przez atakujących.

Architektura chmury i nowy model zagrożeń

Chmura opiera się na koncepcji współdzielonej infrastruktury, w której klienci otrzymują punktowy dostęp do określonych warstw stosu w celu tworzenia nowych i utrzymywania istniejących zasobów. Klient chmury ma pełną autonomię w zakresie tworzenia zasobów IaaS, korzystania z usług PaaS, przesyłania danych i tworzenia zasad IAM (Identity and Access Management) w celu zarządzania dostępem - wszystko dzięki delegowanym uprawnieniom do fragmentu infrastruktury utrzymywanej przez dostawców usług w chmurze.

Dostęp do funkcjonalności jest delegowany i udostępniany klientowi za pośrednictwem warstwy interfejsów, szeroko określanych jako API warstwy kontroli chmury (Cloud Control-Plane).

Wszystkie interakcje użytkowników końcowych ze środowiskiem chmurowym odbywają się za pośrednictwem Cloud Control-Plane, przez tysiące publicznie dostępnych interfejsów. API płaszczyzny kontroli umożliwiają klientom wykonywanie zadań administracyjnych, takich jak tworzenie nowych środowisk, kont użytkowników, utrzymywanie zasobów i uzyskiwanie dostępu do danych przechowywanych w zarządzanych usługach PaaS.

Do zadań interfejsu Control Plane należy autoryzacja użytkowników wywołujących dany punkt, by upewnić się, że mają odpowiednie uprawnienia do wykonywania zleconych działań, a także odtworzenie akcji w komponencie podrzędnym. Akcją może być włączenie i wyłączenie maszyny wirtualnej, skopiowanie obiektu z jednego nadrzędnego folderu, zasobnika (bucket) do drugiego lub aktualizacja uprawnień użytkownika.

Chmura to potężne narzędzie!

Budowanie infrastruktury w chmurze ma niezwykle pozytywny wpływ na efektywność rozwoju, dlatego migracja trwa w najlepsze, we wszystkich sektorach.

Jak więc należy modelować zagrożenia wobec danych przechowywanych w chmurze?

Pierwszy punkt przełamania zabezpieczeń, w bardzo dobry sposób pokazuje podobieństwa i różnice między modelami zagrożeń on-prem i w chmurze.

• Początkowym punktem przedarcia się mogę być otwarte porty do zarządzania zasobami IaaS. Wszyscy znamy sytuację, w której otwarty port SSH lub RDP przyciąga niepożądaną uwagę. W chmurze ryzyko to nadal istnieje.
   
• Luki w zabezpieczeniach warstwy aplikacji są nadal istotne. Niezabezpieczony kod wdrożony w publicznie dostępnych aplikacjach internetowych w najlepszym przypadku może doprowadzić do zakłócenia działalności biznesowej, a w najgorszym daje atakującym przyczółek w strefie DMZ.

Doświadczenie w zakresie zapobiegania i wykrywania punktu przełamania obrony za pośrednictwem tych dwóch wektorów sprawdzą się także w chmurze.

A co z interfejsami płaszczyzny kontroli?

– W przypadku publicznych punktów dostępu, które konfiguruje i zarządza klient, powierzchnia ataku jest całkowicie nowa i właśnie tam sprawny atakujący skorzysta z udogodnień chmury – mówi ekspert Vectra AI.

Wykradanie danych w chmurze

Kluczowym zasobem każdego CSP (Cloud Service Provider) jest jego sieć szkieletowa, czyli warstwa usługowa dostawcy usług w chmurze. Szkielet odnosi się również do sieci używanej przez CSP do przesyłania danych klientów, w przeciwieństwie do danych przesyłanych przez otwartą sieć.

Sieć szkieletowa związana jest z licznymi zarządzanymi usługami np. łączącymi repozytoria danych w chmurze z wszystkimi innymi repozytoriami CSP.

Jeśli chcemy przenieść dane z jednego zasobnika S3 do innego zasobnika S3, wszystko, co jest wymagane, to uprawnienia IAM. Ścieżka sieciowa jest już wytyczona przez sieć szkieletową CSP.

Jako użytkownik chmury nie możemy wprowadzić żadnych ograniczeń dotyczących danych przechowywanych w natywnej pamięci masowej w chmurze i nie mamy wglądu w sieć, przez którą się są przesyłane. Na przykład, nie jest możliwe pozyskanie żadnych dzienników warstwy sieciowej w celu przechwycenia ruchu między dwoma zasobnikami S3. To z kolei tworzy sprzyjające okoliczności dla atakującego do wykradzenia danych ze środowiska chmury.

Jeśli uzyska on odpowiednie uprawnienia IAM, dane mogą zostać przeniesione z zasobnika ofiary do zasobnika na koncie kontrolowanym przez atakującego poprzez przesłanie żądań do płaszczyzny kontroli chmury poprzez API warstwy 7.

Aby to wykonać, atakujący wchodzi w interakcję wyłącznie z publicznie dostępnymi interfejsami API płaszczyzny kontroli chmury i wykorzystuje sieć szkieletową CSP, wstępnie skonfigurowaną trasę niedostępną dla klienta.

Widoczność w płaszczyźnie kontroli (Control plane)

Jak zauważa Christian Putz, dane przenoszone z jednego zasobnika do drugiego nie pozostawiają śladu, do którego przyzwyczajona jest większość specjalistów odpowiedzialnych za bezpieczeństwo.

Dzienniki warstwy sieci, które mogą ujawniać pakiety danych przenoszone z jednego zasobnika do drugiego — nie są dostępne dla użytkownika jako konsumenta chmury.

Oznacza to, że ruch danych odbywa się przez sieć szkieletową, do której klienci chmury nie mają wglądu.

Widocznośćw warstwie hosta

Natywna pamięć masowa w chmurze, taka jak zasobniki S3, bloki pamięci masowej Azure i tym podobne, to usługi zarządzane. Klient nie ma dostępu do poziomu hosta lub systemu operacyjnego, jak w przypadku modelu infrastruktury jako usługi. W usługach zarządzanych nie można używać agentów. Pozostaje nam więc płaszczyzna kontroli. Żadnego z działań podjętych przez atakującego nie można zidentyfikować za pomocą tradycyjnych czujników, ale wskaźniki aktywności pojawiają się w dziennikach zapisywanych przez płaszczyznę kontroli chmury.

Wszystkie działania na zasobach i danych hostowanych w chmurze są autoryzowane przez interfejsy proxy w chmurze i skutkują pewną formą zapisu w dzienniku. W rezultacie, gdy hakerzy wykorzystują API płaszczyzny kontrolnej w chmurze, ich działania są rejestrowane jako to samo zdarzenie.

Te rekordy zdarzeń opowiadają historię środowiska firmowej chmury (kto uzyskał dostęp do czego, skąd i przy użyciu jakich poświadczeń), ale nie intencje użytkownika. Określenie, czy dane działanie jest złośliwe lub nieszkodliwe, wymaga dodatkowych wskazówek kontekstowych i często szerszego spojrzenia na środowisko.

– Przeciwnicy będą wykorzystywać unikalną architekturę chmury i natywne usługi w chmurze z tego samego powodu, dla którego deweloperzy korzystają z chmury - jest szybka! Jest skalowalna! A interfejsy na płaszczyźnie kontroli chmury pomagają im w realizacji ich celów – podsumowuje Putz.

– Płaszczyzna kontroli to miejsce, w którym możemy znaleźć dowody aktywności w środowisku chmurowym, złośliwej lub nie. Monitorowanie oparte na sieci i hoście nie zapewni wymaganej widoczności – dodaje.

Źródło: Vectra AI