Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



01.12.2022

Wyższy poziom programowania

Progress oferuje nowe narzędzia programistyczne: Progress Telerik, Progress Kendo UI i...
01.12.2022

Łączność w podróży

VMware SD-WAN VMware zaprezentował rozwiązanie SD-WAN nowej generacji, w tym nowego...
01.12.2022

Bezpieczne e-maile

Nowa aplikacja firmy Cypherdog Security Inc. umożliwia bezpieczną wymianę maili i...
01.12.2022

Pierwszy w branży

Schneider Electric wprowadza na rynek APC Smart-UPS Ultra. To pierwszy w branży...
01.12.2022

Przełączniki 10G dla MŚP

Nowe urządzenia to przełączniki 10G kompatybilne z systemem Omada SDN.
01.12.2022

Zarządzanie danymi

Firma Synology wprowadziła na rynek czterokieszeniowy DiskStation DS923+.
01.12.2022

Nowatorski system chłodzenia

OVHcloud zaprezentował nową, autorską technologię hybrydowego zanurzeniowego chłodzenia...
01.12.2022

Linia smart routerów

D-Link zaprezentował najnowszą rodzinę routerów Smart Wi-Fi z algorytmami sztucznej...
04.11.2022

Nowa platforma Red Hat

Nowa platforma Red Hat Enterprise Linux (RHEL) w wersjach 8.7 i 9.1 Beta obsługuje...

Ochrona środowisk hybrydowych

Data publikacji: 06-10-2022 Autor: Michał Furmankiewicz

Skala cyberataków stale rośnie i dopóki za atakującymi stoją duże pieniądze, nic się tutaj nie zmieni. Nowe technologie i koncepcje dostarczania usług IT, coraz większa liczba urządzeń podłączonych do sieci, rosnący poziom komplikacji systemów oraz ogromny wzrost użycia usług SaaS powiększają tylko skalę i zasięg ataków.

 

Mimo wzrostu skali skuteczne i masowe ataki są proste w swej naturze. Również w tej kwestii niewiele się zmienia, dlatego że ciągle łatwiej atakować człowieka (który zawsze jest najsłabszym ogniwem) niż system. Zapraszamy do zapoznania się z krótką historią, która pokazuje możliwe wektory ataku mogące opróżnić kieszenie niejednej firmy lub skończyć się poważną sprawą w sądzie.


> Scenariusz ataku


Do projektu wdrożeniowego firma postanawia wynająć zespół konsultantów od firmy doradczej. Na potrzeby prac w chmurowym katalogu użytkowników tworzone są dla nich konta potrzebne do wdrożenia i uruchomienia rozwiązania. W pośpiechu pada decyzja i popełnianych jest szereg błędów: „Po co nam wiele kont? Stwórzmy jedno, którym dostawca będzie się wymieniał (błąd 1). Ponieważ jest tylko jedno konto, to darujmy sobie dodatkowy składnik uwierzytelniania czy potrzebę jakichkolwiek ograniczeń w procesie logowania. W końcu trzeba ufać dostawcy i wspierać nasz biznes w szybkości dostarczenia rozwiązania (błąd 2). Prace, które dostawca musi wykonać, mogą wymagać znacznych uprawnień w środowisku chmurowym. Żeby nie spowalniać jego pracy, dajmy mu wszystkie możliwe uprawnienia w Azure, w usłudze uwierzytelniającej, a nawet w portalu do zarządzania umową (błąd 3). W końcu tak będzie łatwiej i szybciej. Wierzymy, że dostawca wie, co robi – w końcu buduje rozwiązania w chmurze! Nie musimy kontrolować środowiska w chmurze. Nasze środowisko jest statyczne, nie podlega zmianom (błąd 4), nie mamy automatycznego skalowania zasobów, koszty są przewidywalne i stałe. Co więcej, dostawca pokazał nam architekturę nowego rozwiązania – tam również koszt jest dobrze określony. Nie korzystamy z chmurowych narzędzi bezpieczeństwa, nawet jeśli wysyłają nam alerty, rekomendacje i pokazują bardzo niską ocenę bezpieczeństwa naszego środowiska. Mamy przecież podłączone swoje rozwiązanie SIEM/SOAR, dodaliśmy naszego XDR-a. Co prawda, rzadko do niego zaglądamy (błąd 5) – będziemy patrzeć, jak pojawi się problem. Poza tym przecież dostawca chmury zrobi wszystko za nas w zakresie bezpieczeństwa (błąd 6), wszakże korzystamy z jego usług i płacimy!”.


To jeden z potencjalnych przykładów, gdzie mimo świadomości tego, co dzieje się w cyberświecie, ignorujemy wszystkie ostrzeżenia i mamy błędne poczucie, „że wszystko będzie dobrze”. Do dnia, kiedy okaże się, że nic nie jest dobrze i kiedy koncepcja Zero Trust przestaje być sloganem marketingowym, a staje się brakującym elementem naszego podejścia do zabezpieczenia naszych hybrydowych środowisk.

 

> Zero-day


Średni czas przebywania atakującego w środowisku wydłużył się. Obecnie szacunki mówią o ponad 270 dniach obecności w środowisku, zanim zostanie to wykryte. Trudno więc jednoznacznie stwierdzić, kiedy faktyczny dzień „0” miał miejsce, ale przyjmijmy pewien scenariusz opisany poniżej. „Infrastruktura jako kod” i „automatyzacja wszystkiego” to pryncypia, które w świecie ataków rozwinięto do najwyższego poziomu, który – ze szkodą dla nas – jest piekielnie skuteczny i to niezależnie od dostawcy chmurowego.


Dostawcy chmury powtarzają jak mantrę – „identity is a new perimeter” (tożsamość to nowa granica). Dlatego załóżmy, że tożsamość, którą posługiwał się dostawca naszego klienta, „wypływa” lub zostaje przejęta. Jest tylko jedna tożsamość, którą pracownicy dostawcy wymieniają się podczas pracy, więc o to nietrudno. Atakujący nie musi nic łamać – nie ma dodatkowego składnika uwierzytelnienia, więc loguje się bez przeszkód i okazuje się, że może wszystko. Kod, który atakuje, jest sprytny – zamiast atakować systemy lokalne, realizować skomplikowane scenariusze wykradania danych czy niszczyć usługi klienta, skupia się na tym, by przeżyć. Takie zachowanie można zaobserwować w wielu różnych, hybrydowych środowiskach. Tak jest, ten kod też ma życie, a w zasadzie ma ich bardzo wiele. Na początek zaprasza do katalogu użytkowników dodatkowe konta z innej domeny Azure AD i nadaje im wysokie uprawnienia. Kont zakłada na tyle dużo, by jak najdłużej mieć dostęp i, co więcej, zmienia domeny, z których zaprasza, by utrudnić śledzenie i ewentualne działanie. Mając bardzo wysokie uprawnienia, może usunąć powiadomienia ze środowiska. Wyłącza integrację z systemem SIEM on-premises, aby nie zostawiać śladów i spokojnie działać dalej.


W wysoce zautomatyzowanym środowisku, jakim jest środowisko chmury (publicznej czy prywatnej), z wyjątkową łatwością można np. utworzyć znaczną infrastrukturę opartą na maszynach z kartami graficznymi. Na takich urządzeniach najlepiej „kopie się” walutę i to taką, którą łatwo umieścić w elektronicznym portfelu i zamienić na czarnym rynku na inne, użyteczne „przedmioty”. W takim środowisku może również powstać infrastruktura, rozproszona po świecie, którą atakujący wykorzystują do przejęcia faktycznego celu, czy to stosując klasyczny DDoS, czy próbując metody siłowej (ang. brute force) na kontach do środowiska, czy wreszcie wykonując kolejny „lateral movement”. Możliwości jest bardzo dużo, a z rozproszonej po świecie infrastruktury trudniej wyłowić winnego (warto dodać, że atakowanie innych środowisk z infrastruktury chmurowej jest zakazane i może prowadzić do zamknięcia konta, a nawet anulowania kontraktu)


Wróćmy do naszego hipotetycznego środowiska. Ponieważ alertów brak, logi nie spływają (bo atakujący je odciął), a faktycznego włamania nie było – przecież atakujący posługuje się działającym kontem – to wszystko funkcjonuje normalnie. Aż po jakimś czasie nagle okazuje się, że rachunek za środowisko liczymy w milionach.


> Metody ochrony


Wyścig zbrojeń pomiędzy atakującymi i broniącymi trwa. Nie ma systemów idealnych i odpornych na każde działanie. Ale skoro dostawca chmury potrafi zabezpieczyć siebie i swoich klientów, to pewnie można wykorzystać jego portfel rozwiązań i przynajmniej poważnie ograniczyć wektor ataku. Przedstawiamy zatem chmurowe ABC, do których warto się stosować, aby zwiększyć bezpieczeństwo środowiska.

 

Weryfikacja tożsamości (Azure AD, dodatkowy składnik logowania, Conditional Access)


Azure AD nawet w wersji Basic pozwala włączyć drugi składnik logowania. Choć próby przejęcia tożsamości stanowią 95% ataków na środowiska chmurowe, to ponad 88% z nich dałoby się zapobiec, wprowadzając drugi składnik uwierzytelnienia (SMS, telefon, e-mail czy powiadomienie push do aplikacji). W wersjach płatnych Azure AD jeszcze lepiej sprawdza się Conditional Access (bit.ly/2W2nV4h), czyli możliwość odkształcenia procesu logowania i dodanie takich warunków jak logowanie dopuszczone z wybranych: sieci, lokalizacji, urządzeń czy do wybranych aplikacji. Warunki można łączyć, tj. można pozwolić na logowanie do aplikacji z urlopami z dowolnej sieci i dowolnego urządzenia, o ile zostanie wprowadzony drugi składnik, i równocześnie zablokować dostęp do systemu HR, w przypadku gdy urządzenie nie ma odpowiedniego certyfikatu i nie korzysta z tunelu VPN. Tylko to jedno ustawienie dotyczące MFA naprawiłoby błąd 1 i zakończyło atak na samym początku. Dodając do tego Azure AD Identity Protection, dostalibyśmy powiadomienie, że logowania do naszego Azure AD odbiegają od typowych logowań naszych użytkowników – następują z różnych lokalizacji, z dużo większą intensywnością czy z adresów IP, które mają złą reputację. Małej firmie trudno odtworzyć taką funkcjonalność bez znacznych nakładów.

 

[...]

 

Autor jest Program Managerem w globalnym zespole odpowiedzialnym za rozwój regionów chmury Microsoft Azure. Obecnie zajmuje się nowo powstającym regionem PolandCentral.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik \"IT Professional\"