Monitorowanie bezpieczeństwa chmur

Przenoszenie danych i aplikacji do chmur staje się nowym wyzwaniem dla korporacyjnych SOC, które nie zawsze są gotowe do monitorowania cudzej infrastruktury. Według danych Netoskope przeciętne przedsiębiorstwo (wyraźnie w USA) korzysta z 1246 różnych usług chmurowych, co stanowi wzrost o 22% w porównaniu do roku ubiegłego. 1246 usług chmurowych!!! 175 z nich dotyczy usług HR, 170 związanych jest z marketingiem, 110 — w zakresie komunikacji i 76 w finansach oraz CRM. W Cisco używa się „tylko” 700 zewnętrznych usług chmurowych. Dlatego te liczby trochę mnie niepokoją. Niemniej jednak problem nie tkwi w nich, lecz w tym, że chmury zyskują na znaczeniu i zaczynają być stosowane przez coraz większą liczbę firm, które chciałyby mieć te same możliwości w zakresie monitorowania chmurowej infrastruktury, co w swojej własnej sieci. A ta tendencja rośnie — według danych amerykańskiej izby audytowej do 2023 roku w USA planuje się zamknąć 1200 centrów danych (6250 już zamknięto). Ale przejście do chmury to nie tylko „przenieśmy nasze serwery do zewnętrznego dostawcy”. Nowa architektura IT, nowe oprogramowanie, nowe procesy, nowe ograniczenia… To wszystko wprowadza znaczące zmiany w pracy nie tylko IT, ale również w obszarze bezpieczeństwa informacji. A jeśli dostawcy nauczyli się radzić sobie z zapewnieniem bezpieczeństwa samej chmury (na szczęście jest dostateczna ilość rekomendacji), to monitorowanie bezpieczeństwa w chmurze, szczególnie na platformach SaaS, wiąże się z poważnymi trudnościami, o których będziemy rozmawiać.

Załóżmy, że Twoja firma przeniosła część swojej infrastruktury do chmury... Zatrzymaj się. Nie tak. Jeśli infrastruktura została przeniesiona, a Ty dopiero teraz myślisz o tym, jak będziesz ją monitorować, to już przegrałeś. Jeśli to nie Amazon, Google lub Microsoft (a nawet w ich przypadku z zastrzeżeniami), prawdopodobnie nie będziesz miał wielu możliwości monitorowania swoich danych i aplikacji. Dobrze, jeśli dostaniesz możliwość pracy z logami. Czasami dane o zdarzeniach bezpieczeństwa będą dostępne, ale nie będziesz miał do nich dostępu. Na przykład, Office 365. Jeśli masz najtańsza licencję E1, to dane o zdarzeniach bezpieczeństwa będą dla Ciebie całkowicie niedostępne. Przy posiadaniu licencji E3 masz dane przechowywane tylko przez 90 dni, a jedynie w przypadku licencji E5 długość przechowywania logów wynosi rok (prawda, że są też pewne niuanse związane z koniecznością dodatkowego zgłaszania niektórych funkcji związanych z logami do wsparcia technicznego Microsoft). Tak na marginesie, licencja E3 jest znacznie słabsza pod względem funkcji monitorowania niż korporacyjny Exchange. Aby osiągnąć ten sam poziom, potrzebujesz licencji E5 lub dodatkowej licencji Advanced Compliance, które mogą wymagać dodatkowych kosztów, które nie zostały uwzględnione w Twoim modelu finansowym przejścia na chmurę. I to tylko jeden przykład niedoszacowania kwestii związanych z monitorowaniem bezpieczeństwa w chmurze. W tym artykule, nie aspirując do wyczerpania tematu, chciałem zwrócić uwagę na niektóre niuanse, które należy wziąć pod uwagę przy wyborze dostawcy chmury z punktu widzenia bezpieczeństwa. Na końcu artykułu zamieszczony zostanie lista kontrolna, którą warto wykonać, zanim uznasz, że problem monitorowania bezpieczeństwa chmury jest rozwiązany.

Można wyróżnić kilka typowych problemów prowadzących do incydentów w środowiskach chmurowych, na które służby bezpieczeństwa nie zdążają reagować lub w ogóle ich nie dostrzegają:

• Logi bezpieczeństwa nie istnieją. To dosyć powszechna sytuacja, zwłaszcza wśród początkujących graczy na rynku rozwiązań chmurowych. Ale nie należy od razu skreślać tych firm. Mniejsi gracze, szczególnie krajowi, są bardziej wrażliwi na wymagania klientów i mogą szybko wprowadzić jakieś pożądane funkcje, zmieniając zatwierdzony plan rozwoju swoich produktów. Tak, to nie będzie odpowiednik GuardDuty od Amazona ani moduł „Proaktywnej ochrony” od Bitrix, ale zawsze coś.
• Dział IT nie wie, gdzie przechowywane są logi lub nie ma do nich dostępu. Należy prowadzić negocjacje z dostawcą usług chmurowych — być może udzieli on takich informacji, jeśli uzna klienta za istotnego. Ogólnie rzecz biorąc, to nie jest najlepiej, gdy dostęp do logów przyznawany jest „na specjalne zlecenie”.
• Czasami zdarza się, że dostawca chmury ma logi, ale zapewniają one ograniczone monitorowanie i rejestrację zdarzeń, niewystarczającą do wykrywania wszystkich incydentów. Na przykład mogą przekazać tylko logi zmian na stronie lub logi prób uwierzytelnienia użytkowników, natomiast inne zdarzenia, takie jak te dotyczące ruchu sieciowego, mogą być zatajane, co ukryje przed wami ogromną liczbę zdarzeń charakteryzujących próby włamania do waszej infrastruktury chmurowej.
• Logi są, ale dostęp do nich trudno zautomatyzować, co zmusza do ich monitorowania nie ciągłego, a według harmonogramu. A jeśli dodatkowo nie można automatycznie załadować logów, to ich eksport, na przykład w formacie Excel (jak u niektórych krajowych dostawców rozwiązań chmurowych), może całkowicie zniechęcić korporacyjną służbę IT do zajmowania się nimi.
• Brak monitorowania logów. To chyba najbardziej niezrozumiały powód powstawania incydentów IT w środowiskach chmurowych. Logi są, a dostęp do nich można zautomatyzować, a nikt tego nie robi. Dlaczego?

Koncepcja podzielonego bezpieczeństwa chmury

Przechodzenie do chmury zawsze wiąże się z poszukiwaniem równowagi między chęcią zachowania kontroli nad infrastrukturą a przekazaniem jej w bardziej profesjonalne ręce dostawcy chmury, który specjalizuje się w jej wsparciu. Również w zakresie bezpieczeństwa środowisk chmurowych, trzeba tę równowagę znaleźć. Tym bardziej, że w zależności od stosowanego modelu świadczenia usług chmurowych (IaaS, PaaS, SaaS) ta równowaga będzie się ciągle zmieniać. W każdej sytuacji należy pamiętać, że wszyscy dostawcy chmury współczesnego świata działają według tzw. modelu podzielonej odpowiedzialności oraz podzielonego bezpieczeństwa informacji. Za coś odpowiada chmura, za coś odpowiada klient, który umieszcza w chmurze swoje dane, aplikacje, wirtualne maszyny i inne zasoby. Nierozsądne byłoby zakładać, że przechodząc do chmury, przeniesiemy całą odpowiedzialność na dostawcę. Jednak budowanie całego bezpieczeństwa samodzielnie przy przejściu do chmury również nie jest rozsądne. Potrzebna jest równowaga, która będzie zależała od wielu czynników: strategii zarządzania ryzykiem, modelu zagrożeń, istniejących mechanizmów ochronnych u dostawcy chmury, legislacji itp.

Na przykład, klasyfikacja danych przechowywanych w chmurze zawsze leży w gestii klienta. Dostawca chmury lub zewnętrzny dostawca usług może jedynie pomóc w dostarczeniu narzędzi, które będą wspierały oznaczanie danych w chmurze, identyfikowanie naruszeń, usuwanie danych naruszających przepisy lub ich maskowanie przy użyciu różnych metod. Z drugiej strony fizyczne bezpieczeństwo zawsze jest odpowiedzialnością dostawcy chmury, której nie może on dzielić z klientami. Wszystko, co znajduje się pomiędzy danymi a fizyczną infrastrukturą, jest przedmiotem dyskusji w tym artykule. Na przykład, dostępność chmury jest odpowiedzialnością dostawcy, podczas gdy ustawienia zasad MŚE lub włączenie szyfrowania to już odpowiedzialność klienta. W tym artykule spróbujemy przyjrzeć się, jakie mechanizmy monitorowania bezpieczeństwa informatycznego oferują dziś różni popularni dostawcy chmur w Rosji, jakie są szczegóły ich zastosowania i kiedy warto rozważyć zewnętrzne rozwiązania (na przykład Cisco E-mail Security), które rozszerzają możliwości twojej chmury w zakresie cyberbezpieczeństwa. W niektórych przypadkach, szczególnie w przypadku realizacji strategii multichmurowej, nie będziesz miał innego wyboru, jak tylko korzystać z zewnętrznych rozwiązań do monitorowania bezpieczeństwa informatycznego w kilku środowiskach chmurowych (na przykład Cisco CloudLock lub Cisco Stealthwatch Cloud). W innych przypadkach zrozumiesz, że wybrany przez ciebie (lub narzucony ci) dostawca chmury w ogóle nie oferuje żadnych możliwości monitorowania bezpieczeństwa informatycznego. To niemiłe, ale także przydatne, ponieważ pozwala adekwatnie ocenić poziom ryzyka związanego z korzystaniem z tej chmury.

Cykl życia monitorowania bezpieczeństwa chmury

Aby monitorować bezpieczeństwo używanych przez ciebie chmur, masz trzy opcje:

• polegać na narzędziach dostarczonych przez twojego dostawcę chmury,
• skorzystać z rozwiązań firm trzecich, które będą monitorować używane przez ciebie platformy IaaS, PaaS lub SaaS,
• tworzyć własną infrastrukturę monitorowania środowisk chmurowych (tylko dla platform IaaS/PaaS).

Zobaczmy, jakie cechy mają poszczególne opcje. Ale najpierw musimy zrozumieć ogólny schemat, który będzie stosowany w monitorowaniu platform chmurowych. Wyróżniłbym 6 głównych komponentów procesu monitorowania bezpieczeństwa w chmurze:

• Przygotowanie infrastruktury. Określenie niezbędnych aplikacji i infrastruktury do zbierania zdarzeń ważnych dla bezpieczeństwa w magazynie.
• Zbieranie. Na tym etapie zdarzenia bezpieczeństwa są agregowane z różnych źródeł w celu ich dalszego przekazania do przetwarzania, przechowywania i analizy.
• Przetwarzanie. Na tym etapie dane są przekształcane i wzbogacane, aby ułatwić ich późniejszą analizę.
• Przechowywanie. Ten komponent odpowiada za krótkoterminowe i długoterminowe przechowywanie zebranych przetworzonych i "surowych" danych.
• Analiza. Na tym etapie masz możliwość wykrywania incydentów i reagowania na nie w trybie automatycznym lub ręcznym.
• Raportowanie. Ten etap pomaga w tworzeniu dla zainteresowanych stron (kierownictwa, audytorów, dostawcy chmurowego, klientów itp.) kluczowych wskaźników, które pomagają nam podejmować różne decyzje, na przykład zmianę dostawcy lub wzmocnienie bezpieczeństwa.

Zrozumienie tych komponentów pozwoli Ci w przyszłości szybko zdecydować, co możesz uzyskać od swojego dostawcy, a co będziesz musiał zrobić samodzielnie lub z pomocą zewnętrznych konsultantów.

Wbudowane możliwości usług chmurowych

Już wcześniej wspomniałem, że wiele dzisiejszych usług chmurowych nie oferuje żadnych możliwości monitorowania bezpieczeństwa informacji. Ogólnie rzecz biorąc, na temat bezpieczeństwa informacji nie zwraca się tu dużej uwagi. Na przykład, jedna z popularnych rosyjskich usług do przesyłania sprawozdań do organów państwowych przez Internet (specjalnie nie podam jej nazwy). Cała sekcja dotycząca bezpieczeństwa tej usługi koncentruje się na zastosowaniu certyfikowanych systemów ochrony informacji. Sekcja o bezpieczeństwie informacji innej krajowej usługi chmurowej do elektronicznego obiegu dokumentów jest znacznie bardziej rozbudowana. Mówi się w niej o certyfikatach kluczy publicznych, certyfikowanej kryptografii, usuwaniu luk webowych, ochronie przed atakami DDoS, zastosowaniu systemów klasy M, tworzeniu kopii zapasowych, a nawet regularnym przeprowadzaniu audytów bezpieczeństwa informacji. Lecz o monitorowaniu ani słowa, podobnie jak o możliwości uzyskania dostępu do wydarzeń dotyczących bezpieczeństwa informacji, które mogą być interesujące dla klientów tego dostawcy usług.

Ogólnie rzecz biorąc, po tym, jak dostawca chmur opisuje kwestie bezpieczeństwa informacji na swojej stronie i w dokumentacji, można ocenić, jak poważnie podchodzi do tego tematu. Na przykład, jeśli przeczytać instrukcje dotyczące produktów „Mój biuro”, to nie ma tam ani słowa o bezpieczeństwie, a w dokumentacji jednego z produktów „Mój biuro. KS3”, który ma na celu ochronę przed dostępem nieautoryzowanym, znajduje się jedynie zwykła lista punktów 17. rozkazu FSTEK, które realizuje „Mój biuro. KS3”, ale nie opisano, jak je realizuje, ani co najważniejsze, jak zintegrować te mechanizmy z korporacyjnym bezpieczeństwem informacji. Być może taka dokumentacja istnieje, ale w publicznym dostępie, na stronie „Mój biuro” jej nie znalazłem. Chociaż może po prostu nie mam dostępu do tych tajnych informacji...

W przypadku Bitrixa sytuacja jest znacznie lepsza. Dokumentacja opisuje formaty dzienników zdarzeń oraz, co ciekawe, dziennika włamań, który zawiera zdarzenia związane z potencjalnymi zagrożeniami dla platformy chmurowej. Stamtąd można wyciągnąć adres IP, nazwisko użytkownika lub gościa, źródło zdarzenia, czas, User Agent, typ zdarzenia itp. Jednak aby pracować z tymi zdarzeniami, trzeba albo skorzystać z panelu zarządzania chmurą, albo wyeksportować dane w formacie MS Excel. Automatyzacja pracy z logami Bitrixa jest obecnie trudna, więc część zadań będziesz musiał wykonać ręcznie (eksportowanie raportu i załadowanie go do swojego SIEM). Ale pamiętając, że jeszcze stosunkowo niedawno taka możliwość nie istniała, to jest to duży postęp. Warto również zauważyć, że wielu zagranicznych dostawców chmur oferuje podobną funkcjonalność "dla początkujących" — albo przeglądanie logów w panelu zarządzania, albo eksportowanie danych na własne potrzeby (chociaż większość eksportuje dane w formacie .csv, a nie Excel).

Jeśli nie brać pod uwagę opcji braku logów, dostawcy chmurowi zazwyczaj oferują trzy metody monitorowania zdarzeń bezpieczeństwa – panele kontrolne, eksport danych i dostęp do nich przez API. Pierwsza opcja wydaje się rozwiązywać wiele problemów, ale to nie do końca tak jest – przy posiadaniu kilku dzienników trzeba przełączać się między ekranami je wyświetlającymi, tracąc ogólny obraz. Ponadto, dostawca chmury raczej nie da ci możliwości korelacji zdarzeń bezpieczeństwa i ich analizy w kontekście bezpieczeństwa (zazwyczaj masz do czynienia z surowymi danymi, które musisz samodzielnie zrozumieć). Są wyjątki i o nich porozmawiamy później. Wreszcie warto dopytać, jakie zdarzenia rejestruje twój dostawca chmury, w jakim formacie, oraz jak bardzo pasują one do twojego procesu monitorowania bezpieczeństwa informacji? Na przykład, identyfikacja i autoryzacja użytkowników i gości. Ten sam Bitrix pozwala ci przy tych zdarzeniach zarejestrować datę i czas zdarzenia, nazwisko użytkownika lub gościa (przy włączonym module “Web-Analitika”), obiekt, do którego uzyskano dostęp oraz inne typowe elementy dla strony internetowej. Jednakże korporacyjne służby bezpieczeństwa informacji mogą potrzebować informacji o tym, z zaufanego urządzenia użytkownik zalogował się do chmury (na przykład w sieci korporacyjnej taką funkcjonalność wdraża Cisco ISE). A taka prosta funkcjonalność, jak geo-IP, która pomoże określić, czy konto użytkownika usługi chmurowej nie zostało skradzione? I nawet jeśli dostawca chmury mu to udostępni, to nadal za mało. Ten sam Cisco CloudLock nie tylko analizuje geolokalizację, ale także wykorzystuje uczenie maszynowe i analizuje dane historyczne dla każdego użytkownika oraz śledzi różne anomalie w próbach identyfikacji i autoryzacji. Podobną funkcjonalność ma tylko MS Azure (przy posiadaniu odpowiedniej subskrypcji).

Istnieje jeszcze jedna trudność — ponieważ monitorowanie bezpieczeństwa informacji dla wielu dostawców chmurowych to nowy temat, którym dopiero zaczynają się zajmować, ciągle wprowadzają zmiany w swoich rozwiązaniach. Dziś mają jedną wersję API, jutro inną, a pojutrze jeszcze inną. Na to również trzeba być gotowym. To samo dotyczy funkcjonalności, która może się zmieniać, co należy uwzględnić w swoim systemie monitorowania bezpieczeństwa informacji. Na przykład, Amazon początkowo oferował oddzielne usługi do monitorowania zdarzeń w chmurze — AWS CloudTrail i AWS CloudWatch. Potem został wprowadzony oddzielny serwis do monitorowania zdarzeń dotyczących bezpieczeństwa informacji — AWS GuardDuty. Po pewnym czasie Amazon uruchomił nowy system zarządzania Amazon Security Hub, który obejmuje analizę danych uzyskiwanych z GuardDuty, Amazon Inspector, Amazon Macie i wielu innych. Inny przykład to narzędzie integracji logów Azure z SIEM — AzLog. Było intensywnie wykorzystywane przez wielu dostawców SIEM, dopóki w 2018 roku Microsoft nie ogłosił zakończenia jego rozwoju i wsparcia, co postawiło wielu klientów, którzy korzystali z tego narzędzia, przed problemem (jak rozwiązano tę sytuację, omówimy później).

Dlatego uważnie obserwuj wszystkie funkcje monitorowania, które oferuje Twój dostawca chmury. Możesz też zaufać zewnętrznym dostawcom rozwiązań, którzy będą działać jako pośrednicy między Twoim SOC a chmurą, którą chcesz monitorować. Tak, to będzie droższe (choć nie zawsze), ale zyskasz, przenosząc odpowiedzialność na inne osoby. A może nie całkowicie? Przypomnijmy sobie koncepcję dzielonego bezpieczeństwa i zrozummy, że nie możemy przenieść całej odpowiedzialności — będziemy musieli samodzielnie zgłębić, jak różni dostawcy chmur zapewniają monitorowanie bezpieczeństwa informacji Twoich danych, aplikacji, maszyn wirtualnych i innych zasobów umieszczonych w chmurze. I zaczniemy od tego, co oferuje Amazon w tej kwestii.

Przykład: Monitorowanie bezpieczeństwa informacji w IaaS opartym na AWS

Tak, rozumiem, że Amazon nie jest najlepszym przykładem, ponieważ to amerykański serwis, który może być blokowany w związku z walką z ekstremizmem i rozpowszechnianiem zakazanych informacji w Rosji. W tej publikacji chciałbym jednak pokazać, jak różne platformy chmurowe różnią się pod względem możliwości monitorowania bezpieczeństwa informacji oraz na co warto zwrócić uwagę przy przenoszeniu kluczowych procesów do chmury z perspektywy bezpieczeństwa. A jeśli któryś z rosyjskich dostawców rozwiązań chmurowych wyciągnie coś użytecznego dla siebie, to byłoby to wspaniałe.

Na początku należy zaznaczyć, że Amazon nie jest niezdobytą twierdzą. Jego użytkownicy regularnie doświadczają różnych incydentów. Przykładem jest sytuacja, kiedy z Deep Root Analytics skradziono imiona, adresy, daty urodzenia i numery telefonów 198 milionów wyborców. W przypadku izraelskiej firmy Nice Systems skradziono 14 milionów rekordów abonentów Verizon. Wbudowane możliwości AWS pozwalają jednak na wykrywanie różnych incydentów. Na przykład:

• atak na infrastrukturę (DDoS)
• kompromitacja węzła (injecting commands)
• kompromitacja konta i nieautoryzowany dostęp
• nieprawidłowa konfiguracja i luki w zabezpieczeniach
• niezabezpieczone interfejsy i API.

To rozbieżność wynika z tego, że za bezpieczeństwo danych klienta, jak ustaliliśmy powyżej, odpowiada sam klient. Jeśli nie zadbał o włączenie mechanizmów ochronnych i narzędzi monitorujących, dowie się o incydencie tylko z mediów lub od swoich klientów.

Do identyfikacji incydentów można wykorzystać szeroki wachlarz różnych usług monitorujących opracowanych przez Amazon (chociaż często są one uzupełniane zewnętrznymi narzędziami, takimi jak osquery). W AWS śledzone są wszystkie działania użytkowników, niezależnie od tego, jak są realizowane - przez konsolę zarządzania, linię poleceń, SDK lub inne usługi AWS. Wszystkie zapisy działań każdego konta AWS (w tym nazwa użytkownika, działanie, usługa, parametry aktywności i jej wynik) oraz wykorzystanie API są dostępne przez usługę AWS CloudTrail. Możesz przeglądać te zdarzenia (np. logowanie do konsoli AWS IAM) z konsoli CloudTrail, analizować je za pomocą Amazon Athena lub przekazać je do zewnętrznych rozwiązań, takich jak Splunk, AlienVault itp. Same logi AWS CloudTrail są umieszczane w twoim koszu AWS S3.

Dwie inne usługi AWS zapewniają dodatkowe istotne możliwości monitorowania. Po pierwsze, Amazon CloudWatch - to usługa monitorowania zasobów i aplikacji AWS, która pozwala między innymi wykrywać różne anomalie w twojej chmurze. Wszystkie wbudowane usługi AWS, takie jak Amazon Elastic Compute Cloud (serwery), Amazon Relational Database Service (bazy danych), Amazon Elastic MapReduce (analiza danych) oraz 30 innych usług Amazon, korzystają z Amazon CloudWatch do przechowywania swoich logów. Programiści mogą korzystać z otwartego API Amazon CloudWatch, aby dodać funkcję monitorowania logów do aplikacji i usług użytkowników, co pozwala na rozszerzenie zakresu analizowanych zdarzeń w kontekście bezpieczeństwa.

Po drugie, usługa VPC Flow Logs pozwala analizować ruch sieciowy wysyłany lub odbierany przez twoje serwery AWS (na zewnątrz lub wewnątrz), a także między mikrousługami. Gdy jakikolwiek z twoich zasobów AWS VPC wchodzi w interakcję z siecią, usługa VPC Flow Logs rejestruje szczegóły dotyczące ruchu sieciowego, w tym interfejs sieciowy źródła i docelowego, a także adresy IP, porty, protokół, liczbę bajtów oraz liczbę pakietów, które zauważyłeś. Ci, którzy mają doświadczenie w lokalnym bezpieczeństwie sieci, rozpoznają to jako odpowiednik strumieni. NetFlow, które mogą być tworzone przez przełączniki, routery i zapory ogniowe klasy korporacyjnej. Te dzienniki są istotne dla celów monitorowania bezpieczeństwa informacji, ponieważ w przeciwieństwie do zdarzeń związanych z działaniami użytkowników i aplikacji, pozwalają również na zarejestrowanie interakcji sieciowej w wirtualnym, prywatnym środowisku chmurowym AWS.

Tak więc te trzy usługi AWS — AWS CloudTrail, Amazon CloudWatch i VPC Flow Logs — w połączeniu zapewniają wystarczająco skuteczny obraz użycia Twojego konta, zachowań użytkowników, zarządzania infrastrukturą, aktywności aplikacji i usług oraz aktywności sieciowej. Na przykład, dzięki nim można wykrywać następujące nieprawidłowości:

• Próby skanowania witryn, poszukiwania backdoorów, wyszukiwania luk bezpieczeństwa poprzez eksplozje „błędów 404”.
• Ataki typu injection (np. SQL injection) poprzez eksplozje „błędów 500”.
• Znane narzędzia do ataków, takie jak sqlmap, nikto, w3af, nmap itp. poprzez analizę pola User Agent.

Amazon Web Services również opracował inne usługi dla celów cyberbezpieczeństwa, które umożliwiają rozwiązywanie wielu różnych problemów. Na przykład, w AWS znajduje się wbudowana usługa do audytu polityk i konfiguracji — AWS Config. Ta usługa zapewnia ciągły audyt zasobów AWS i ich konfiguracji. Rozważmy prosty przykład: załóżmy, że chcesz upewnić się, że hasła użytkowników są wyłączone na wszystkich Twoich serwerach, a dostęp jest możliwy tylko na podstawie certyfikatów. AWS Config umożliwia łatwe sprawdzenie tego na wszystkich Twoich serwerach. Istnieją również inne polityki, które mogą być stosowane do Twoich serwerów w chmurze: „Żaden serwer nie może używać portu 22”, „Tylko administratorzy mogą zmieniać zasady zapory” lub „Tylko użytkownik Iwaszko może tworzyć nowe konta użytkowników, a może to robić tylko we wtorki”. Latem 2016 roku usługa AWS Config została rozszerzona, aby umożliwić automatyzację wykrywania naruszeń określonych polityk. AWS Config Rules to w zasadzie ciągłe zapytania o konfigurację używanych przez Ciebie usług Amazon, które generują zdarzenia w przypadku naruszenia odpowiednich polityk. Na przykład, zamiast okresowo wykonywać zapytania AWS Config w celu sprawdzenia, czy wszystkie dyski wirtualnego serwera są zaszyfrowane, można użyć AWS Config Rules do ciągłego sprawdzania dysków serwera pod kątem spełnienia tego warunku. I co najważniejsze, w kontekście tej publikacji, wszelkie naruszenia generują zdarzenia, które mogą być analizowane przez Twoją służbę bezpieczeństwa informacji.

W AWS znajdują się również swoje odpowiedniki tradycyjnych korporacyjnych rozwiązań w zakresie bezpieczeństwa, które również generują zdarzenia bezpieczeństwa, które możesz i powinieneś analizować:

• wykrywanie intruzji — AWS GuardDuty
• kontrola wycieków informacji — AWS Macie
• EDR (chociaż mówienie o urządzeniach końcowych w chmurze brzmi trochę dziwnie) — AWS Cloudwatch + rozwiązania open source osquery lub GRR
• analiza Netflow — AWS Cloudwatch + AWS VPC Flow
• analiza DNS — AWS Cloudwatch + AWS Route53
• AD — AWS Directory Service
• zarządzanie kontami — AWS IAM
• SSO — AWS SSO
• analiza bezpieczeństwa — AWS Inspector
• zarządzanie konfiguracjami — AWS Config
• WAF — AWS WAF.

Nie będę szczegółowo opisywał wszystkich usług Amazon, które mogą być przydatne w kontekście bezpieczeństwa informacji. Najważniejsze, co trzeba zrozumieć, to że wszystkie mogą generować zdarzenia, które możemy i powinniśmy analizować w kontekście IB, korzystając zarówno z wbudowanych możliwości samego Amazon, jak i zewnętrznych rozwiązań, takich jak SIEM, które mogą pobierać zdarzenia bezpieczeństwa do twojego centrum monitorowania i analizować je tam wśród zdarzeń z innych usług chmurowych czy wewnętrznej infrastruktury, perymetru lub urządzeń mobilnych.

W każdym razie wszystko zaczyna się od źródeł danych, które dostarczają ci zdarzenia IB. Do takich źródeł można zaliczyć między innymi:

• CloudTrail — użycie API i działania użytkowników
• Trusted Advisor — sprawdzanie bezpieczeństwa pod kątem najlepszych praktyk
• Config — inwentaryzacja i konfiguracja kont oraz ustawień usług
• VPC Flow Logs — połączenia z wirtualnymi interfejsami
• IAM — usługa identyfikacji i uwierzytelniania
• ELB Access Logs — logi balancera obciążenia
• Inspector — luki w aplikacjach
• S3 — magazyn plików
• CloudWatch — aktywność aplikacji
• SNS — usługa powiadomień.

Amazon, oferując tak szeroki wachlarz źródeł zdarzeń i narzędzi do ich generacji, jest jednocześnie mocno ograniczony w możliwościach analizy zebranych danych w kontekście IB. Będziesz musiał samodzielnie przeszukiwać dostępne logi, szukając w nich odpowiednich wskaźników kompromitacji. AWS Security Hub, który niedawno uruchomił Amazon, ma na celu rozwiązanie tego problemu, będąc swoistym chmurowym SIEM dla AWS. Jednak na razie jest jeszcze na początku swojej drogi i ograniczony zarówno pod względem liczby źródeł, z którymi współpracuje, jak i innymi ograniczeniami narzuconymi przez architekturę i subskrypcje samego Amazon.

Przykład: Monitoring IB w IaaS oparty na Azure

Nie chcę wdawać się w długą dyskusję, który z trzech dostawców chmurowych (Amazon, Microsoft czy Google) jest najlepszy (tym bardziej, że każdy z nich ma swoją specyfikę i nadaje się do rozwiązywania różnych zadań); skupmy się na możliwościach monitorowania bezpieczeństwa informacji, które oferują ci gracze. Trzeba przyznać, że Amazon AWS był jednym z pierwszych w tym segmencie i dlatego osiągnął najwięcej, jeśli chodzi o funkcje zabezpieczeń (choć wielu uznaje, że korzystanie z nich jest dość skomplikowane). Ale to nie oznacza, że zignorujemy możliwości, które oferują nam Microsoft i Google.

Produkty Microsoftu zawsze charakteryzowały się swoją "otwartością" i w przypadku Azure situacja jest podobna. Na przykład, podczas gdy AWS i GCP zawsze bazują na koncepcji "wszystko, co nie jest dozwolone, jest zabronione", w Azure podejście jest wręcz odwrotne. Na przykład, tworząc wirtualną sieć w chmurze oraz wirtualną maszynę w niej, wszystkie porty i protokoły są domyślnie otwarte i dozwolone. Dlatego będziesz musiał włożyć nieco więcej wysiłku w początkową konfigurację systemu kontroli dostępu w chmurze Microsoftu. To również nakłada na ciebie większe wymagania w zakresie monitorowania aktywności w chmurze Azure.

AWS ma pewną cechę, która polega na tym, że kiedy monitorujesz swoje zasoby wirtualne, jeśli znajdują się w różnych regionach, napotykasz trudności w łączeniu wszystkich zdarzeń i ich wspólnej analizy. Aby je przezwyciężyć, musisz sięgać po różne sztuczki, takie jak tworzenie własnego kodu dla AWS Lambda, który przemieszcza zdarzenia między regionami. W Azure nie ma takiego problemu — jego mechanizm Activity Log śledzi całą aktywność w ramach całej organizacji bez ograniczeń. To samo dotyczy AWS Security Hub, który został niedawno opracowany przez Amazon w celu konsolidacji wielu funkcji bezpieczeństwa w ramach jednego centrum bezpieczeństwa, ale tylko w ramach swojego regionu, co niestety nie jest istotne dla Rosji. W Azure istnieje jego własne Security Center, które nie podlega ograniczeniom regionalnym, udostępniając dostęp do wszystkich funkcji bezpieczeństwa platformy chmurowej. Co więcej, dla różnych lokalnych zespołów może ono dostarczyć swój zestaw możliwości ochrony, w tym zarządzanych przez nich zdarzeń bezpieczeństwa. AWS Security Hub dopiero stara się stać się podobny do Azure Security Center. Jednak warto dodać łyżkę dziegciu — możesz wycisnąć z Azure wiele z tego, co zostało wcześniej opisane w AWS, ale najwygodniej robi się to tylko dla Azure AD, Azure Monitor i Azure Security Center. Wszystkie inne mechanizmy ochrony Azure, w tym analiza zdarzeń bezpieczeństwa, są obecnie zarządzane w sposób, który nie jest najwygodniejszy. Częściowo problem rozwiązuje API, które przenika wszystkie usługi Microsoft Azure, ale wymaga to od Ciebie dodatkowych wysiłków w celu integracji Twojej chmury z Twoim SOC oraz posiadania wykwalifikowanych specjalistów (co jest właściwie wymagane w przypadku każdego innego SIEM, który działa z chmurowymi API). Niektóre SIEM, o których mowa będzie dalej, już wspierają Azure i mogą zautomatyzować zadanie jego monitorowania, ale i w tym przypadku są pewne trudności — nie wszystkie mogą pobierać wszystkie logi dostępne w Azure.

Zbieranie zdarzeń i ich monitorowanie w Azure odbywa się za pomocą usługi Azure Monitor, która jest podstawowym narzędziem do zbierania, przechowywania i analizy danych w chmurze Microsoft oraz jej zasobach — repozytoriach Git, kontenerach, maszynach wirtualnych, aplikacjach itd. Wszystkie dane zbierane przez Azure Monitor dzielą się na dwie kategorie — metryki zbierane w czasie rzeczywistym, które opisują kluczowe wskaźniki wydajności chmury Azure, oraz dzienniki, zawierające dane zorganizowane w zapisach, charakteryzujące różne aspekty działalności zasobów i usług Azure. Ponadto, za pomocą Data Collector API usługa Azure Monitor może zbierać dane z dowolnego źródła REST, aby budować własne scenariusze monitorowania.

Oto kilka źródeł zdarzeń bezpieczeństwa, które oferuje Azure i do których możesz uzyskać dostęp przez Azure Portal, CLI, PowerShell lub REST API (a niektóre tylko przez Azure Monitor / Insight API):

• Dzienniki aktywności — ten dziennik odpowiada na klasyczne pytania „kto”, „co” i „kiedy” w odniesieniu do każdej operacji zapisu (PUT, POST, DELETE) nad zasobami chmurowymi. Zdarzenia związane z dostępem do odczytu (GET) nie trafiają do tego dziennika, podobnie jak szereg innych.
• Dzienniki diagnostyczne — zawierają dane dotyczące operacji z danym zasobem wchodzącym w skład twojej subskrypcji.
• Raportowanie Azure AD — zawiera zarówno aktywność użytkowników, jak i aktywność systemową związaną z zarządzaniem grupami i użytkownikami.
• Dziennik zdarzeń systemu Windows oraz Linux Syslog — zawiera zdarzenia z maszyn wirtualnych umieszczonych w chmurze.
• Metryki — zawierają telemetrykę o stanie wydajności i „zdrowia” twoich usług i zasobów chmurowych. Mierzone co minutę i przechowywane przez 30 dni.
• Dzienniki przepływu grup zabezpieczeń sieci — zawierają dane o sieciowych zdarzeniach bezpieczeństwa zbierane za pomocą usługi Network Watcher i monitorowania zasobów na poziomie sieci.
• Dzienniki przechowywania — zawierają zdarzenia związane z dostępem do magazynów.

Do monitoringu możesz używać zewnętrznych SIEM lub wbudowanego Azure Monitor i jego rozszerzeń. O systemach zarządzania zdarzeniami bezpieczeństwa porozmawiamy jeszcze, a tymczasem przyjrzyjmy się, co oferuje sam Azure do analizy danych w kontekście bezpieczeństwa. Głównym ekranem dla wszystkiego, co związane z bezpieczeństwem w Azure Monitor, jest Log Analytics Security and Audit Dashboard (bezpłatna wersja wspiera przechowywanie ograniczonej liczby zdarzeń przez tylko tydzień). Ten panel jest podzielony na 5 głównych obszarów, wizualizujących zbiorczą statystykę dotycząca tego, co dzieje się w Twoim używanym środowisku chmurowym:

• Domeny bezpieczeństwa — kluczowe wskaźniki ilościowe związane z bezpieczeństwem — liczba incydentów, liczba skompromitowanych węzłów, niezałatane węzły, zdarzenia związane z bezpieczeństwem sieci itp.
• Znaczące problemy — wyświetla liczby i ważność aktywnych problemów związanych z bezpieczeństwem
• Wykrycia — wyświetla wzory ataków wykorzystanych przeciwko tobie
• Inteligencja zagrożeń — wyświetla informacje geograficzne dotyczące zewnętrznych węzłów, które cię atakują
• Typowe zapytania dotyczące bezpieczeństwa — typowe zapytania, które pomogą ci lepiej monitorować twoje bezpieczeństwo.

Jako rozszerzenia Azure Monitor można wymienić Azure Key Vault (ochrona kluczy kryptograficznych w chmurze), Malware Assessment (analiza obrony przed złośliwym oprogramowaniem na maszynach wirtualnych), Azure Application Gateway Analytics (analiza, między innymi, logów chmurowego zapory sieciowej) itp. Te narzędzia, wzbogacone o określone zasady przetwarzania zdarzeń, pozwalają wizualizować różne aspekty działalności usług chmurowych, w tym bezpieczeństwa, oraz wykrywać wszelkie odchylenia od pracy. Jednak, jak to często bywa, każda dodatkowa funkcja wymaga odpowiedniej płatnej subskrypcji, co wymaga od ciebie zaplanowania odpowiednich wydatków z wyprzedzeniem.

Azure oferuje szereg wbudowanych możliwości monitorowania zagrożeń, które są zintegrowane z Azure AD, Azure Monitor i Azure Security Center. Należą do nich m.in. wykrywanie interakcji maszyn wirtualnych z znanymi złośliwymi adresami IP (dzięki integracji z usługami Threat Intelligence od Microsoft), wykrywanie złośliwego oprogramowania w infrastrukturze chmurowej poprzez sygnały alarmowe z maszyn wirtualnych umieszczonych w chmurze, ataki typu „bruteforce” na maszyny wirtualne, podatności w konfiguracji systemu identyfikacji użytkowników, logowanie z anonimowych lub zainfekowanych węzłów, wycieki danych logowania, logowanie z nietypowych lokalizacji itp. Dziś Azure jest jednym z nielicznych dostawców chmurowych, którzy oferują wbudowane możliwości Threat Intelligence do wzbogacania zbieranych zdarzeń bezpieczeństwa.

Jak już wspomniano powyżej, funkcjonalność zabezpieczeń oraz, w efekcie, generowane przez nią zdarzenia bezpieczeństwa, nie są dostępne dla wszystkich użytkowników w jednakowy sposób, lecz wymagają posiadania odpowiedniej subskrypcji, która zawiera potrzebną funkcjonalność, generującą odpowiednie zdarzenia do monitorowania bezpieczeństwa. Na przykład część funkcji opisanych w poprzednim akapicie dotyczących monitorowania anomalii w kontach jest dostępna jedynie w licencji premium P2 dla usługi Azure AD. Bez niej, podobnie jak w przypadku AWS, będziesz musiał analizować zbierane zdarzenia bezpieczeństwa „ręcznie”. Dodatkowo, w zależności od typu licencji na Azure AD, nie wszystkie zdarzenia będą dostępne do analizy.

Na portalu Azure możesz zarządzać zarówno zapytaniami do interesujących Cię dzienników zdarzeń, jak i konfigurować panele do wizualizacji kluczowych wskaźników bezpieczeństwa. Ponadto, tam również możesz wybierać rozszerzenia Azure Monitor, które pozwalają ci na poszerzenie funkcjonalności dzienników Azure Monitor i uzyskanie głębszej analizy zdarzeń z punktu widzenia bezpieczeństwa.

Jeśli potrzebujesz nie tylko możliwości pracy z dziennikami, ale wszechstronnego centrum bezpieczeństwa twojej platformy w chmurze Azure, w tym zarządzania politykami bezpieczeństwa informacji, warto rozważyć korzystanie z Azure Security Center, które oferuje wiele przydatnych funkcji dostępnych za dodatkową opłatą, takich jak wykrywanie zagrożeń, monitorowanie poza Azure, ocena zgodności itp. (w wersji bezpłatnej masz dostęp tylko do oceny bezpieczeństwa i zaleceń dotyczących naprawy zidentyfikowanych problemów). Konsoliduje wszystkie kwestie bezpieczeństwa w jednym miejscu. Można powiedzieć, że oferuje wyższy poziom bezpieczeństwa informacji niż Azure Monitor, ponieważ w tym przypadku zebrane dane z całej twojej chmury są wzbogacane z wielu źródeł, takich jak Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) i Microsoft Security Response Center (MSRC), na które nakładają się różne zaawansowane algorytmy uczenia maszynowego i analityki behawioralnej, co powinno w efekcie zwiększyć skuteczność wykrywania zagrożeń i reagowania na nie.

Azure ma też swoje SIEM — pojawiło się na początku 2019 roku. To Azure Sentinel, który opiera się na danych z Azure Monitor i może integrować się z zewnętrznymi rozwiązaniami bezpieczeństwa (takimi jak NGFW czy WAF), których lista jest stale aktualizowana. Dodatkowo, dzięki integracji z Microsoft Graph Security API masz możliwość podłączenia własnych źródeł Threat Intelligence do Sentinel, co wzbogaca możliwości analizy incydentów w twoim chmura Azure. Można stwierdzić, że Azure Sentinel jest pierwszym „rodzimym” SIEM, który pojawił się u dostawców chmur (podobnie jak Splunk czy ELK, które można wdrożyć w chmurze, np. AWS, są jednak opracowywane przez dostawców tradycyjnych usług chmurowych). Azure Sentinel i Security Center można by nazwać SOC dla chmury Azure i można by na nich się skupić (z pewnymi zastrzeżeniami), gdybyś nie miał żadnej innej infrastruktury i wszystkie swoje zasoby obliczeniowe przeniósł do chmury, a była to chmura Microsoft Azure.

Jednakże, ponieważ wbudowane możliwości Azure (nawet przy subskrypcji na Sentinel) często są niewystarczające do celów monitorowania bezpieczeństwa informacji i integracji tego procesu z innymi źródłami zdarzeń bezpieczeństwa (zarówno chmurowymi, jak i wewnętrznymi), pojawia się potrzeba eksportu zebranych danych do zewnętrznych systemów, takich jak SIEM. Można to zrobić zarówno za pomocą API, jak i specjalnych rozszerzeń, które w tej chwili są oficjalnie dostępne tylko dla następujących SIEM – Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight oraz ELK. Jeszcze niedawno było więcej takich SIEM, ale od 1 czerwca 2019 roku Microsoft zaprzestał wsparcia dla Azure Log Integration Tool (AzLog), który na początku działalności Azure, w czasach braku normalnej standaryzacji pracy z logami (Azure Monitor jeszcze nie istniał), umożliwiał łatwą integrację zewnętrznych SIEM z chmurą Microsoftu. Obecnie sytuacja się zmieniła, a Microsoft zaleca platformę Azure Event Hub jako główne narzędzie integracyjne dla pozostałych SIEM. Wiele firm już przeprowadziło taką integrację, ale należy być ostrożnym – mogą one nie rejestrować wszystkich logów Azure, a jedynie niektóre (sprawdź w dokumentacji swojego SIEM).

Zakończając krótki przegląd Azure, chciałbym dać ogólną rekomendację dotyczącą tej usługi chmurowej — zanim cokolwiek stwierdzisz na temat funkcji monitorowania bezpieczeństwa w Azure, warto je bardzo starannie skonfigurować i przetestować, aby upewnić się, że działają tak, jak opisano w dokumentacji oraz jak powiedzieli konsultanci Microsoft (a ich opinie mogą się różnić w kwestii funkcjonalności Azure). W przypadku odpowiednich funduszy, Azure może dostarczyć wiele wartościowych informacji w zakresie monitorowania bezpieczeństwa. Jeśli jednak Twoje zasoby są ograniczone, wówczas tak jak w przypadku AWS, będziesz musiał polegać jedynie na własnych siłach i surowych danych, które zapewnia Azure Monitor. Pamiętaj, że wiele funkcji monitorowania wiąże się z kosztami, dlatego warto wcześniej zapoznać się z polityką cenową. Na przykład, możesz bezpłatnie przechowywać dane przez 31 dni, do 5 GB na klienta — przekroczenie tych wartości będzie wymagać dodatkowych środków (około 2+ dolarów za każdy dodatkowy GB oraz 0,1 dolara za przechowanie 1 GB każdego dodatkowego miesiąca). Praca z telemetrią aplikacji i metrykami również może wymagać dodatkowych kosztów, podobnie jak praca z alertami i powiadomieniami (dostępny jest darmowy limit, który może okazać się niewystarczający dla Twoich potrzeb).

Przykład: Monitorowanie bezpieczeństwa w IaaS na podstawie Google Cloud Platform

Google Cloud Platform na tle AWS i Azure wygląda na zupełnie nową platformę, ale w pewnym sensie to dobrze. W przeciwieństwie do AWS, które rozwijało swoje możliwości, w tym zabezpieczenia, stopniowo, napotykając problemy z centralizacją; GCP, podobnie jak Azure, jest znacznie lepiej zarządzane centralnie, co redukuje liczbę błędów i czas wdrażania w przedsiębiorstwie. Z perspektywy bezpieczeństwa, GCP znajduje się w pewnym sensie pomiędzy AWS a Azure. Posiada ono również wspólne dla całej organizacji rejestrowanie zdarzeń, ale jest ono niepełne. Niektóre funkcje są nadal w trybie beta, ale stopniowo ten niedobór powinien zostać wyeliminowany i GCP stanie się bardziej dojrzałą platformą pod względem monitorowania bezpieczeństwa.

Głównym narzędziem do rejestrowania zdarzeń w GCP jest Stackdriver Logging (odpowiednik Azure Monitor), który pozwala na zbieranie zdarzeń w całej twojej infrastrukturze chmurowej (a także z AWS). Z punktu widzenia bezpieczeństwa w GCP każda organizacja, projekt lub folder mają cztery dzienniki rejestracji:

• Admin Activity — zawiera wszystkie zdarzenia związane z dostępem administracyjnym, takie jak tworzenie maszyny wirtualnej, zmiana uprawnień itp. Ten dziennik jest zawsze aktywowany, niezależnie od twojej woli, i przechowuje dane przez 400 dni.
• Data Access — zawiera wszystkie zdarzenia związane z pracą użytkowników chmurowych z danymi (tworzenie, zmiana, czytanie itp.). Domyślnie ten dziennik nie jest aktywowany, ponieważ jego objętość szybko rośnie. Z tego powodu czas przechowywania wynosi zaledwie 30 dni. Ponadto не wszystkie zdarzenia są rejestrowane w tym dzienniku. Na przykład zdarzenia związane z zasobami publicznie dostępnymi dla wszystkich użytkowników lub które są dostępne bez logowania do GCP nie są w nim rejestrowane.
• System Event — zawiera zdarzenia systemowe, które nie są związane z użytkownikami, ani działaniami administratora zmieniającego konfigurację zasobów chmurowych. Jest aktywowany zawsze i przechowywany przez 400 dni.
• Access Transparency — to unikalny przykład dziennika rejestracji, który dokumentuje wszystkie działania pracowników Google (jednak na razie nie dla wszystkich usług GCP), które uzyskują dostęp do twojej infrastruktury w ramach wykonywania swoich obowiązków służbowych. Ten dziennik jest przechowywany przez 400 dni i nie jest dostępny dla każdego klienta GCP, a tylko pod spełnieniem pewnych warunków (albo wsparcie na poziomie Gold lub Platinum, albo posiadanie 4 ról określonego typu w ramach wsparcia korporacyjnego). Podobną funkcję ma również, na przykład, Office 365 — Lockbox.

Przykład dziennika: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "US"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "CA"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Numer sprawy: bar123"
 type: "CUSTOMER_INITIATED_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

Dostęp do wskazanych dzienników jest możliwy na kilka sposobów (podobnie jak w przypadku Azure i AWS) — przez interfejs Log Viewer, przez API, przez Google Cloud SDK lub przez stronę Aktywność Twojego projektu, którego wydarzeniami jesteś zainteresowany. W ten sam sposób można je eksportować do zewnętrznych rozwiązań w celu dodatkowej analizy. Ostatnie można zrealizować poprzez eksport dzienników do magazynu BigQuery lub Cloud Pub/Sub.

Oprócz Stackdriver Logging platforma GCP oferuje również funkcjonalność Stackdriver Monitoring, która pozwala śledzić kluczowe metryki (wydajność, czas pracy na awarię, ogólny stan itp.) usług i aplikacji w chmurze. Przetworzone specjalnie i zwizualizowane dane mogą ułatwić identyfikację problemów w infrastrukturze chmurowej, w tym w kontekście bezpieczeństwa. Należy jednak zauważyć, że ta funkcjonalność nie będzie szczególnie bogata właśnie w kontekście bezpieczeństwa informacji, ponieważ obecnie GCP nie ma odpowiednika AWS GuardDuty i nie potrafi wyodrębnić spośród wszystkich rejestrowanych wydarzeń tych, które są rzeczywiście problematyczne (Google opracował Event Threat Detection, ale na razie jest on w fazie beta i trudno ocenić jego przydatność). Stackdriver Monitoring mógłby być wykorzystany jako system wykrywania anomalii, które następnie byłyby badane w celu znalezienia przyczyn ich wystąpienia. Jednak w warunkach niedoboru wykwalifikowanego personelu w dziedzinie bezpieczeństwa informacji na rynku, zadanie to obecnie wydaje się być trudne.

Warto również podać listę niektórych modułów zabezpieczeń, które mogą być stosowane w ramach Twojej chmury GCP, i które są podobne do tego, co oferuje AWS:

• Cloud Security Command Center — to odpowiednik AWS Security Hub i Azure Security Center.
• Cloud DLP — automatyczne wykrywanie i redagowanie (np. maskowanie) danych umieszczonych w chmurze, według ponad 90 wstępnie zdefiniowanych polityk klasyfikacji.
• Cloud Scanner — skaner znanych luk w zabezpieczeniach (XSS, Flash Injection, niezałatane biblioteki itp.) w App Engine, Compute Engine oraz Google Kubernetes.
• Cloud IAM — zarządzanie dostępem do wszystkich zasobów GCP.
• Cloud Identity — zarządzanie kontami użytkowników, urządzeń i aplikacji GCP z jednej konsoli.
• Cloud HSM — ochrona kluczy kryptograficznych.
• Cloud Key Management Service — zarządzanie kluczami kryptograficznymi w GCP.
• VPC Service Control — tworzenie zabezpieczonej granicy wokół Twoich zasobów GCP w celu ochrony przed wyciekami.
• Titan Security Key — ochrona przed phishingiem.

Wiele z tych modułów generuje zdarzenia bezpieczeństwa, które mogą być wysyłane do magazynu BigQuery w celu analizy lub eksportu do innych systemów, w tym SIEM. Jak już wspomniano, GCP to aktywnie rozwijana platforma, a Google opracowuje wiele nowych modułów bezpieczeństwa dla swojej platformy. Wśród nich Event Threat Detection (aktualnie dostępny w wersji beta), który skanuje logi Stackdriver w poszukiwaniu śladów nieautoryzowanej aktywności (analogicznie do GuardDuty w AWS), oraz Policy Intelligence (dostępny w wersji alfa), który umożliwi rozwijanie inteligentnych polityk dostępu do zasobów GCP.

Zrobiłem krótki przegląd wbudowanych możliwości monitorowania w popularnych platformach chmurowych. Ale czy macie specjalistów, którzy potrafią pracować z "surowymi" logami dostawcy IaaS (nie wszyscy są gotowi kupować rozszerzone możliwości AWS, Azure lub Google)? Ponadto, wiele osób zna powiedzenie "ufaj, ale weryfikuj", które w obszarze bezpieczeństwa jest bardziej aktualne niż kiedykolwiek. Na ile ufacie wbudowanym możliwościom dostawcy chmury, które dostarczają Wam zdarzenia bezpieczeństwa? Na ile w ogóle koncentrują się na bezpieczeństwie?

Czasami warto rozważyć rozwiązania do monitorowania infrastruktur chmurowych, które mogą uzupełnić wbudowane zabezpieczenia chmury, a czasami takie rozwiązania są jedyną opcją uzyskania danych na temat bezpieczeństwa Twoich danych i aplikacji umieszczonych w chmurze. Ponadto są one po prostu wygodniejsze, ponieważ przejmują wszystkie zadania związane z analizy potrzebnych logów generowanych przez różne usługi chmurowe od różnych dostawców chmury. Jako przykład takiego zewnętrznego rozwiązania można podać Cisco Stealthwatch Cloud, które koncentruje się na jednym zadaniu – monitorowaniu anomalii bezpieczeństwa w chmurowych środowiskach, w tym nie tylko Amazon AWS, Microsoft Azure i Google Cloud Platform, ale także prywatnych chmur.

Przykład: Monitorowanie bezpieczeństwa z użyciem Stealthwatch Cloud

AWS oferuje elastyczną platformę obliczeniową, ale ta elastyczność sprawia, że firmy łatwiej popełniają błędy, co prowadzi do problemów z bezpieczeństwem. A model współdzielony w bezpieczeństwie jedynie temu sprzyja. Uruchamianie w chmurze oprogramowania z nieznanymi lukami bezpieczeństwa (z znanymi można walczyć na przykład za pomocą AWS Inspector lub GCP Cloud Scanner), słabe hasła, niepoprawne konfiguracje, insajderzy itd. Wszystko to wpływa na zachowanie zasobów chmurowych, które mogą być monitorowane przez Cisco Stealthwatch Cloud, stanowiący system monitorowania bezpieczeństwa i wykrywania ataków w środowiskach publicznych i prywatnych.

Jedną z kluczowych cech Cisco Stealthwatch Cloud jest możliwość modelowania encji. Dzięki temu można stworzyć model programowy (czyli symulację praktycznie w czasie rzeczywistym) każdego z zasobów chmurowych (niezależnie od tego, czy jest to AWS, Azure, GCP czy coś innego). Mogą to być serwery i użytkownicy, a także typy zasobów specyficzne dla Twojego środowiska chmurowego, takie jak grupy zabezpieczeń i grupy automatycznego skalowania usług. Modele te wykorzystują jako dane wejściowe uporządkowane strumienie danych dostarczane przez usługi chmurowe. Na przykład dla AWS będą to VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda i AWS IAM. Modelowanie encji automatycznie odkrywa rolę i zachowanie dowolnego z Twoich zasobów (można mówić o profilowaniu całej aktywności chmurowej). Takie role to np. urządzenie mobilne Android lub Apple, serwer Citrix PVS, serwer RDP, brama pocztowa, klient VoIP, serwer terminalowy, kontroler domeny itp. Następnie ciągle śledzi ich zachowanie, aby określić, kiedy zachowanie staje się ryzykowne lub zagrażające bezpieczeństwu. Możesz identyfikować próby łamania haseł, ataki DDoS, wycieki danych, nieautoryzowany zdalny dostęp, działania złośliwego oprogramowania, skanowanie luk w zabezpieczeniach i inne zagrożenia. Na przykład oto jak wygląda wykrywanie próby zdalnego dostępu z nietypowego dla Twojej organizacji kraju (Korea Południowa) do klastra Kubernetes przez SSH:

A oto jak wygląda podejrzane wycieki informacji z bazy danych Postgress do kraju, z którym wcześniej nie miało się do czynienia:

Na koniec, oto jak wygląda zbyt wiele nieudanych prób dostępu przez SSH z Chin i Indonezji z zewnętrznego zdalnego urządzenia:

Załóżmy, że instancja serwera w VPC zgodnie z polityką nigdy nie powinna być punktem docelowym dla zdalnego logowania. Przyjmijmy dalej, że na tym komputerze nastąpiło zdalne logowanie z powodu błędnej zmiany polityki reguł zapory sieciowej. Funkcja modelowania encji wykryje i zgłosi tę aktywność („Nietypowy zdalny dostęp”) w niemal rzeczywistym czasie, wskazując na konkretne wywołanie API AWS CloudTrail, Azure Monitor lub GCP Stackdriver Logging (w tym nazwę użytkownika, datę i czas, między innymi szczegóły), które spowodowały zmianę w regule MSEC. Następnie te informacje mogą być przekazane do SIEM w celu analizy.

Podobne możliwości są realizowane dla dowolnego środowiska chmurowego wspieranego przez Cisco Stealthwatch Cloud:

Modelowanie encji to unikalna forma automatyzacji bezpieczeństwa, która może wykryć wcześniej nieznany problem z twoimi ludźmi, procesami lub technologią. Na przykład, pozwala na wykrycie, między innymi, takich problemów bezpieczeństwa jak:

• Czy ktoś odkrył backdoor w oprogramowaniu, którego używamy?
• Czy w naszej chmurze istnieje jakieś nieautoryzowane oprogramowanie lub urządzenie?
• Czy autoryzowany użytkownik nadużywa uprawnień?
• Czy doszło do błędu konfiguracyjnego, który umożliwia zdalny dostęp lub inne niezamierzone wykorzystanie zasobów?
• Czy nie ma wycieku danych z naszych serwerów?
• Czy ktoś próbował się z nami połączyć z nietypowego miejsca geograficznego?
• Czy nasza chmura nie jest zainfekowana złośliwym oprogramowaniem?

Wydarzenie związane z bezpieczeństwem IT może zostać przekazane jako odpowiedni bilet do Slacka, Cisco Spark, systemu zarządzania incydentami PagerDuty oraz przekazane do różnych SIEM, w tym Splunk czy ELK. Podsumowując, można stwierdzić, że jeśli Twoja firma stosuje strategię wielochmurową i nie ogranicza się do jednego dostawcy chmurowego, możliwości monitorowania bezpieczeństwa IT, które opisano powyżej, sprawiają, że zastosowanie Cisco Stealthwatch Cloud jest dobrym rozwiązaniem, by uzyskać zintegrowany zestaw możliwości monitorowania wiodących graczy w chmurze — Amazon, Microsoft i Google. Co ciekawe, porównując ceny Stealthwatch Cloud z zaawansowanymi licencjami monitorowania bezpieczeństwa IT w AWS, Azure czy GCP, może się okazać, że rozwiązanie Cisco jest nawet tańsze od wbudowanych możliwości rozwiązań Amazon, Microsoft i Google. To paradoksalne, ale prawdziwe. A im więcej chmur i ich możliwości wykorzystujesz, tym bardziej oczywista staje się przewaga zintegrowanego rozwiązania.

Dodatkowo, Stealthwatch Cloud może monitorować także prywatne chmury wdrożone w Twojej organizacji, na przykład zbudowane na bazie kontenerów Kubernetes lub poprzez monitorowanie strumieni Netflow czy ruchu sieciowego uzyskiwanego poprzez mirrorowanie w sprzęcie sieciowym (nawet krajowej produkcji), danych AD czy serwerów DNS itp. Wszystkie te dane będą wzbogacane informacjami Threat Intelligence zbieranymi przez zespół Cisco Talos, największą na świecie niezależną grupę badawczą zajmującą się zagrożeniami bezpieczeństwa IT.

Pozwala to na realizację jednolitego systemu monitorowania zarówno publicznych, jak i hybrydowych chmur, z których może korzystać Twoja firma. Zebrane informacje następnie mogą być analizowane za pomocą wbudowanych możliwości Stealthwatch Cloud lub przesyłane do Twojego SIEM (domyślnie wspierane są Splunk, ELK, SumoLogic i szereg innych).

Na tym zakończymy pierwszą część artykułu, w której omówiłem wbudowane i zewnętrzne narzędzia do monitorowania bezpieczeństwa platform IaaS/PaaS, które pozwalają nam szybko wykrywać i reagować na incydenty występujące w chmurach wybranych przez nasze przedsiębiorstwo. W drugiej części kontynuujemy temat i rozważymy opcje monitorowania platform SaaS na przykładzie Salesforce i Dropbox, a także spróbujemy podsumować i zebrać wszystko razem, tworząc jedną system monitorowania bezpieczeństwa różnych dostawców chmury.

Źródło: habr.com