Monitoring bezpieczeństwa chmur

Przenoszenie danych i aplikacji do chmur stanowi nowe wyzwanie dla korporacyjnych SOC-ów, które nie zawsze są gotowe do monitorowania cudzej infrastruktury. Według danych Netoskope średnie przedsiębiorstwo (zdaje się w USA) korzysta z 1246 różnych usług powiązanych z chmurą, co oznacza wzrost o 22% w porównaniu z rokiem ubiegłym. 1246 usług chmurowych!!! 175 z nich dotyczy usług HR, 170 związanych jest z marketingiem, 110 - z komunikacją, a 76 w finansach i CRM. W Cisco wykorzystuje się „zaledwie” 700 zewnętrznych usług chmurowych. Dlatego trochę zaskakują mnie te liczby. Ale w każdym razie problem nie leży w nich, lecz w tym, że chmury zaczynają być aktywnie wykorzystywane przez coraz większą liczbę firm, które chciałyby mieć te same możliwości monitorowania infrastruktury chmurowej, co w własnej sieci. A ten trend rośnie — według danych amerykańskiego biura rachunkowego W 2023 roku w Stanach Zjednoczonych planowane jest zamknięcie 1200 centrów danych (6250 już zostało zamkniętych). 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 funkcjonowaniu nie tylko IT, ale także bezpieczeństwa informacji. A jeśli dostawcy chmur nauczyli się jakoś radzić sobie z bezpieczeństwem samej chmury (na szczęście istnieje wiele zaleceń), to w przypadku monitorowania bezpieczeństwa w chmurze, zwłaszcza na platformach SaaS, występują poważne trudności, o których porozmawiamy.

Załóżmy, że twoja firma przeniosła część swojej infrastruktury do chmury… Stop. To nie tak. Jeśli infrastruktura została przeniesiona, a ty dopiero teraz zastanawiasz się, jak ją monitorować, to już przegrałeś. Jeśli to nie jest Amazon, Google ani Microsoft (choć i to z zastrzeżeniami), prawdopodobnie nie będziesz miał wiele możliwości monitorowania swoich danych i aplikacji. Dobrze, jeśli pozwolą ci pracować z logami. Czasami informacje o zdarzeniach związanych z bezpieczeństwem będą dostępne, ale nie będziesz miał do nich dostępu. Na przykład, Office 365. Jeśli masz najtańsze licencje E1, to zdarzenia bezpieczeństwa są całkowicie niedostępne. Przy licencji E3 masz dane przechowywane przez tylko 90 dni, a tylko przy E5 długość logów jest dostępna przez rok (choć są tu również swoje niuanse związane z koniecznością osobnego wnioskowania o szereg funkcji związanych z logami u wsparcia Microsoft). A tak przy okazji, licencja E3 jest znacznie słabsza pod względem funkcji monitorowania w porównaniu do korporacyjnego Exchange. Aby osiągnąć ten sam poziom, potrzebujesz licencji E5 lub dodatkowej licencji Advanced Compliance, które mogą wymagać dodatkowych pieniędzy, które nie zostały uwzględnione w twoim modelu finansowym przejścia na infrastrukturę chmurową. I to tylko jeden przykład niedoceniania kwestii związanych z monitorowaniem bezpieczeństwa chmur. W tym artykule, nie roszcząc sobie pretensji do wyczerpania tematu, pragnę zwrócić uwagę na kilka niuansów, które warto wziąć pod uwagę przy wyborze dostawcy chmury z perspektywy bezpieczeństwa. Na końcu artykułu będzie zamieszczona lista kontrolna, którą warto wykonać, zanim uznasz, że zagadnienie monitorowania bezpieczeństwa w chmurze jest już rozwiązane.

Można wyróżnić kilka typowych problemów, które prowadzą do incydentów w chmurze, na które służby bezpieczeństwa informacji nie są w stanie odpowiednio zareagować lub ich nie dostrzegają:

• Logi bezpieczeństwa nie istnieją. To dość powszechny problem, zwłaszcza wśród nowych graczy na rynku rozwiązań chmurowych. Jednak nie należy od razu skreślać takich dostawców. Mniejsi gracze, szczególnie krajowi, są bardziej wrażliwi na potrzeby klientów i mogą szybko wdrożyć poszukiwane funkcje, dostosowując zatwierdzony harmonogram rozwoju swoich produktów. Tak, to nie będzie analogiem GuardDuty od Amazon czy modułem „Proaktywnej ochrony” od Bitrix, ale zawsze coś.
• Służby bezpieczeństwa informacji nie wiedzą, gdzie są przechowywane logi lub nie mają do nich dostępu. Należy rozpocząć negocjacje z dostawcą usług chmurowych — być może udostępni takie informacje, jeśli uzna klienta za istotnego. Ogólnie rzecz biorąc, to nie jest dobre, gdy dostęp do logów jest przyznawany „na specjalne życzenie”.
• Może zdarzyć się, że dostawca chmury dysponuje logami, ale zapewniają one ograniczone monitorowanie i rejestrację zdarzeń, niewystarczające do wykrywania wszystkich incydentów. Na przykład, mogą udostępnić tylko logi zmian na stronie lub logi prób uwierzytelnienia użytkowników, ale inne zdarzenia, takie jak o ruchu sieciowym, mogą być niedostępne, co ukryje przed Państwem szereg informacji, charakterystycznych dla prób włamania do Państwa infrastruktury chmurowej.
• Logi są, ale dostęp do nich trudno zautomatyzować, co powoduje, że są monitorowane nie w sposób ciągły, ale według harmonogramu. A jeśli dodatkowo nie można pobrać logów w trybie automatycznym, eksport logów, na przykład w formacie Excel (tak jak u niektórych krajowych dostawców rozwiązań chmurowych), może całkowicie zniechęcić dział bezpieczeństwa firmy do ich przetwarzania.
• Brak monitorowania logów. To chyba najbardziej niezrozumiały powód występowania incydentów bezpieczeństwa w środowiskach chmurowych. Wydaje się, że logi są dostępne i można zautomatyzować dostęp do nich, a jednak nikt tego nie robi. Dlaczego?

Koncepcja dzielonego bezpieczeństwa chmury

Migracja do chmury zawsze wymaga znalezienia równowagi między chęcią zachowania kontroli nad infrastrukturą a przekazaniem jej w bardziej profesjonalne ręce dostawcy chmurowego, specjalizującego się w jej wsparciu. W zakresie bezpieczeństwa środowisk chmurowych także należy dążyć do tego balansu. Co więcej, w zależności od zastosowanego modelu świadczenia usług chmurowych (IaaS, PaaS, SaaS) ta równowaga będzie się różnić. W każdym przypadku należy pamiętać, że wszyscy dostawcy chmur dzisiaj stosują tak zwaną model podzielonej odpowiedzialności i wspólnego bezpieczeństwa informacji. Za coś odpowiada chmura, za coś odpowiada klient, który umieścił w chmurze swoje dane, aplikacje, maszyny wirtualne i inne zasoby. Byłoby nierozsądne zakładać, że przechodząc do chmury, przerzucimy całą odpowiedzialność na dostawcy. Jednak również nie jest mądrze budować całego bezpieczeństwa samodzielnie podczas migracji do chmury. Niezbędna jest równowaga, która będzie zależna od wielu czynników: strategii zarządzania ryzykiem, modeli zagrożeń, dostępnych u dostawcy chmurowego mechanizmów ochrony, legislacji itp.

Na przykład klasyfikacja danych umieszczonych w chmurze zawsze jest odpowiedzialnością zleceniodawcy. Dostawca chmury lub zewnętrzny dostawca usług może jedynie pomóc w udostępnieniu narzędzi, które pomogą oznaczać dane w chmurze, identyfikować naruszenia, usuwać dane naruszające przepisy lub maskować je za pomocą wybranej metody. Z drugiej strony, bezpieczeństwo fizyczne zawsze jest odpowiedzialnością dostawcy chmury, której nie może dzielić z klientami. Natomiast wszystko, co znajduje się pomiędzy danymi a infrastrukturą fizyczną, jest właśnie przedmiotem dyskusji w niniejszym artykule. Na przykład dostępność chmury to odpowiedzialność dostawcy, natomiast konfiguracja zasad MSCE lub włączenie szyfrowania to już odpowiedzialność klienta. W tym artykule spróbujemy przyjrzeć się, jakie mechanizmy monitorowania bezpieczeństwa informacji oferują dzisiaj różni popularni dostawcy chmur w Rosji, jakie są ich szczegóły zastosowania oraz kiedy warto rozważyć zewnętrzne rozwiązania (np. Cisco E-mail Security), które rozszerzają możliwości Twojej chmury w zakresie cyberbezpieczeństwa. W niektórych przypadkach, szczególnie przy stosowaniu strategii multi-cloud, nie będziesz miał innego wyboru, jak tylko skorzystać z zewnętrznych rozwiązań do monitorowania bezpieczeństwa informacji w kilku środowiskach chmurowych (np. Cisco CloudLock lub Cisco Stealthwatch Cloud). A w niektórych sytuacjach zorientujesz się, że wybrany przez Ciebie (lub narzucony) dostawca chmury w ogóle nie oferuje żadnych możliwości monitorowania bezpieczeństwa informacji. To niezbyt korzystne, ale również istotne, ponieważ pozwala na adekwatną ocenę poziomu ryzyka związanego z pracą w tej chmurze.

Cykl życia monitorowania bezpieczeństwa chmury

Aby monitorować bezpieczeństwo używanych przez Ciebie chmur, masz trzy możliwości:

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

Przyjrzyjmy się, jakie cechy ma każdy z tych wariantów. Zanim jednak to zrobimy, musimy zrozumieć ogólny schemat, który będzie stosowany podczas monitorowania platform chmurowych. Wydzielam 6 głównych elementów procesu monitorowania bezpieczeństwa w chmurze:

• Przygotowanie infrastruktury. Określenie niezbędnych aplikacji i infrastruktury do zbierania zdarzeń istotnych dla bezpieczeństwa w składowisku.
• Zbieranie. Na tym etapie zdarzenia bezpieczeństwa są agregowane z różnych źródeł, aby następnie przekazać je 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ótko- i długoterminowe przechowywanie zebranych przetworzonych oraz „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 sformułować dla zainteresowanych stron (kierownictwa, audytorów, dostawcy chmury, klientów itp.) kluczowe wskaźniki, które pomagają nam podejmować decyzje, na przykład zmianę dostawcy lub wzmocnienie ochrony informacji.

Zrozumienie tych komponentów pozwoli Ci w przyszłości szybko określić, 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

Wcześniej wspomniałem, że wiele dzisiejszych usług chmurowych nie oferuje żadnych możliwości monitorowania bezpieczeństwa informacji (IB). Właściwie, temat IB nie jest dla nich priorytetowy. Na przykład, jeden z popularnych rosyjskich serwisów do przesyłania sprawozdań do instytucji państwowych przez Internet (celowo nie będę podawał jego nazwy). Cała sekcja dotycząca bezpieczeństwa tego serwisu koncentruje się na stosowaniu certyfikowanych środków ochrony informacji. Sekcja o IB innej krajowej usługi chmurowej zajmującej się elektronicznym obiegiem dokumentów jest znacznie obszerniejsza. Mówi się w niej o certyfikatach kluczy publicznych, certyfikowanej kryptografii, eliminacji luk w aplikacjach internetowych, ochronie przed atakami DDoS, zastosowaniu systemów zarządzania bezpieczeństwem informacji, tworzeniu kopii zapasowych, a nawet regularnym przeprowadzaniu audytów IB. Ale o monitorowaniu ani słowa, tak samo jak o możliwości dostępu do zdarzeń IB, które mogą być interesujące dla klientów tego dostawcy usług.

W rzeczywistości, na podstawie tego, jak dostawca chmury opisuje kwestie bezpieczeństwa informacji na swojej stronie internetowej i w dokumentacji, można ocenić, jak poważnie podchodzi do tego tematu. Na przykład, czytając przewodniki dotyczące produktów „Mój biuro”, nie ma w nich ani słowa o bezpieczeństwie, natomiast w dokumentacji dotyczącej konkretnego produktu „Mój biuro. KS3”, przeznaczonego do ochrony przed nieautoryzowanym dostępem, znajduje się jedynie standardowe wymienienie punktów 17. rozporządzenia FSTEK, które wykonuje „Mój biuro. KS3”, ale nie ma opisu, jak dokładnie to realizuje i, co najważniejsze, jak zintegrować te mechanizmy z korporacyjnym systemem bezpieczeństwa informacji. Być może taka dokumentacja istnieje, ale nie mogłem jej znaleźć w publicznym dostępie na stronie „Mój biuro”. Chociaż może po prostu nie mam dostępu do tych tajnych informacji?

Sytuacja z Bitrixem jest zdecydowanie lepsza. Dokumentacja opisuje formaty dzienników zdarzeń, a co ciekawe, także dziennik naruszeń, który zawiera zdarzenia związane z potencjalnymi zagrożeniami dla chmury. Możesz stamtąd wyciągnąć IP, nazwisko użytkownika lub gościa, źródło zdarzenia, czas, User Agent, typ zdarzenia itd. Niestety, praca z tymi zdarzeniami jest możliwa tylko z panelu zarządzania chmurą lub poprzez eksportowanie danych w formacie MS Excel. Automatyzacja pracy z logami Bitrixa jest obecnie utrudniona i będziesz musiał część pracy wykonywać ręcznie (eksport raportu i załadowanie go do swojego SIEM). Jednak przypominając sobie, że jeszcze niedawno nie było takiej możliwości, to jest to duży krok naprzód. Warto również zauważyć, że wielu zagranicznych dostawców chmur oferuje podobne funkcjonalności „dla początkujących” — możesz albo przeglądać logi ręcznie w panelu zarządzania, albo eksportować dane na własny użytek (choć większość eksportuje dane w formacie .csv, a nie Excel).

Z wyjątkiem scenariusza braku logów, dostawcy chmury zazwyczaj oferują trzy opcje monitorowania wydarzeń bezpieczeństwa — panele monitorujące, eksport danych i dostęp do nich za pomocą API. Pierwsza opcja rozwiązuje wiele problemów za nas, ale to nie do końca prawda — mając wiele dzienników, musimy przełączać się między ekranami, co powoduje utratę ogólnego obrazu. Ponadto, dostawca chmury najprawdopodobniej nie zaoferuje nam możliwości korelacji zdarzeń bezpieczeństwa ani ich analizy z perspektywy bezpieczeństwa (najczęściej mamy do czynienia z surowymi danymi, które musimy samodzielnie zrozumieć). Są wyjątki, o których omówimy później. Wreszcie warto zapytać, jakie zdarzenia rejestruje twój dostawca chmury, w jakim formacie i jak dobrze odpowiadają twojemu procesowi monitorowania zabezpieczeń? Na przykład identyfikacja i autoryzacja użytkowników oraz gości. Ten sam Bitrix pozwala na rejestrację daty i godziny zdarzenia, nazwy użytkownika lub gościa (w przypadku posiadania modułu „Web Analytics”), obiektu, do którego uzyskano dostęp, oraz innych typowych elementów dla strony internetowej. Jednak dla korporacyjnych służb bezpieczeństwa może być potrzebna informacja o tym, z zaufanego urządzenia użytkownik uzyskał dostęp do chmury (na przykład w korporacyjnej sieci taką funkcję realizuje Cisco ISE). A nawet tak prosta funkcja jak geolokalizacja IP, która pomoże określić, czy konto użytkownika usługi chmurowej nie zostało skradzione? I nawet jeśli dostawca chmury ją oferuje, to nadal może być niewystarczające. Cisco CloudLock nie tylko analizuje geolokalizację, ale wykorzystuje do tego uczenie maszynowe i analizy danych historycznych każdego użytkownika oraz monitoruje różne anomalie w próbach identyfikacji i autoryzacji. Podobną funkcjonalność ma tylko MS Azure (przy odpowiedniej subskrypcji).

Istnieje jeszcze jedna trudność — ponieważ dla wielu dostawców usług chmurowych monitoring bezpieczeństwa to nowy temat, którym dopiero zaczynają się zajmować, ciągle zmieniają swoje rozwiązania. Dziś mają jedną wersję API, jutro inną, a pojutrze trzecią. Należy być na to przygotowanym. To samo dotyczy funkcjonalności, która może się zmieniać, co trzeba uwzględnić w swoim systemie monitorowania bezpieczeństwa. Na przykład, Amazon początkowo miał osobne usługi monitorowania zdarzeń w chmurze — AWS CloudTrail oraz AWS CloudWatch. Następnie pojawiła się osobna usługa monitorowania zdarzeń związanych z bezpieczeństwem — AWS GuardDuty. Po pewnym czasie Amazon uruchomił nowy system zarządzania Amazon Security Hub, który obejmuje analizę danych z GuardDuty, Amazon Inspector, Amazon Macie i innych. Inny przykład to narzędzie do integracji logów Azure z SIEM — AzLog. Było ono aktywnie używane przez wielu dostawców SIEM, aż w 2018 roku Microsoft ogłosił zakończenie jego rozwoju i wsparcia, co postawiło wielu klientów korzystających z tego narzędzia przed problemem (jak to zostało rozwiązane, omówimy później).

Dlatego dokładnie śledź wszystkie funkcje monitorowania oferowane przez twojego dostawcę chmury. Lub zaufaj zewnętrznym dostawcom rozwiązań, którzy będą pośredniczyć między twoim SOC a chmurą, którą chcesz monitorować. Tak, będzie to droższe (choć nie zawsze), ale zyskasz spokój, przenosząc odpowiedzialność na innych. A może nie całą? Przypomnijmy sobie o koncepcji wspólnego bezpieczeństwa i zrozummy, że nie możemy przenieść wszystkiego — będziemy musieli samodzielnie zająć się tym, jak różni dostawcy chmury zapewniają monitorowanie bezpieczeństwa twoich danych, aplikacji, maszyn wirtualnych i innych zasobów umieszczonych w chmurze. Zaczniemy od tego, co oferuje Amazon w tej dziedzinie.

Przykład: Monitorowanie zabezpieczeń w IaaS opartym na AWS

Zgadza się, rozumiem, że Amazon to niekoniecznie najlepszy przykład, biorąc pod uwagę, że jest to amerykańska usługa, która może być blokowana w ramach walki z ekstremizmem oraz rozpowszechnianiem zabronionych informacji na terenie Rosji. W tej publikacji chciałbym jednak pokazać, jak bardzo różnią się różne platformy chmurowe pod względem możliwości monitorowania bezpieczeństwa informacji oraz na co zwrócić uwagę przy przenoszeniu kluczowych procesów do chmury z punktu widzenia bezpieczeństwa. Jeśli rosyjscy deweloperzy rozwiązań chmurowych wyniosą z tego coś wartościowego, to będzie to naprawdę świetne.

Najpierw trzeba powiedzieć, że Amazon to nie jest nieprzystępna twierdza. Jego klienci regularnie doświadczają różnych incydentów. Na przykład, firma Deep Root Analytics straciła 198 milionów imion, adresów, dat urodzenia i numerów telefonów wyborców. Izraelska firma Nice Systems zgubiła 14 milionów rekordów abonentów Verizon. Warto podkreślić, że wbudowane możliwości AWS umożliwiają wykrywanie szerokiego zakresu incydentów. Na przykład:

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

Niezgodność ta wynika z faktu, ż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 nie uruchomił narzędzi monitorujących, o incydencie może dowiedzieć się tylko z mediów lub od swoich klientów.

Aby identyfikować incydenty, można skorzystać z szerokiego wachlarza usług monitorujących opracowanych przez Amazon (czasami uzupełnionych o zewnętrzne narzędzia, takie jak osquery). W AWS śledzone są wszystkie działania użytkowników, niezależnie od sposobu ich wykonania — za pomocą konsoli zarządzania, wiersza poleceń, SDK czy innych usług AWS. Wszystkie zapisy dotyczące działań każdej konta AWS (w tym nazwa użytkownika, działanie, usługa, parametry aktywności i jej rezultat) oraz korzystania z API są dostępne za pośrednictwem usługi AWS CloudTrail. Możesz przeglądać te zdarzenia (na przykład logowanie do konsoli AWS IAM) z konsoli CloudTrail, analizować je za pomocą Amazon Athena lub przekazywać do zewnętrznych rozwiązań, takich jak Splunk, AlienVault itp. Same logi AWS CloudTrail są przechowywane w twoim zasobie AWS S3.

Dwie inne usługi AWS oferują szereg istotnych możliwości monitorowania. Po pierwsze, Amazon CloudWatch to usługa monitorowania zasobów i aplikacji AWS, która pozwala między innymi na wykrywanie różnych anomalii w 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 ponad 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 informacji.

Po drugie, usługa VPC Flow Logs umożliwia analizowanie ruchu sieciowego wysyłanego lub odbieranego przez Twoje serwery AWS (zarówno z zewnątrz, jak i wewnątrz), a także między mikroserwisami. Kiedy którykolwiek 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 docelowy, a także adresy IP, porty, protokół, liczbę bajtów i liczbę pakietów, które widziałeś. Ci, którzy mają doświadczenie w lokalnym bezpieczeństwie sieci, uznają to za odpowiednik strumieni NetFlow, które mogą być generowane przez przełączniki, routery i firewalle klasy korporacyjnej. Te logi są ważne dla celów monitorowania bezpieczeństwa informacji, ponieważ w przeciwieństwie do zdarzeń dotyczących działań użytkowników i aplikacji, pozwalają nie pomijać także interakcji sieciowych w wirtualnym prywatnym chmurze AWS.

Te trzy usługi AWS — AWS CloudTrail, Amazon CloudWatch i VPC Flow Logs — zapewniają skuteczny wgląd w wykorzystanie Twojego konta, zachowanie użytkowników, zarządzanie infrastrukturą, aktywność aplikacji i usług oraz ruch sieciowy. Na przykład mogą pomóc w wykrywaniu następujących anomalii:

• Próby skanowania witryny, wyszukiwania backdoorów oraz wykrywania luk w zabezpieczeniach poprzez wzrost liczby „błędów 404”.
• Ataki typu injection (np. SQL injection) na podstawie wzrostu liczby „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 opracowało również inne usługi dla celów cyberbezpieczeństwa, które pozwalają rozwiązywać wiele różnych zadań. Na przykład, w AWS znajduje się wbudowana usługa 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 i dostęp jest możliwy jedynie na podstawie certyfikatów. AWS Config pozwala łatwo to zweryfikować dla wszystkich twoich serwerów. Istnieją też inne polityki, które mogą być stosowane do twoich serwerów w chmurze: „Żaden serwer nie może korzystać z 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 o automatyzację wykrywania naruszeń ustalonych 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, aby sprawdzić, czy wszystkie dyski serwera wirtualnego są zaszyfrowane, AWS Config Rules można używać do stałego monitorowania 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.

W AWS znajdują się również odpowiedniki tradycyjnych rozwiązań korporacyjnych w zakresie bezpieczeństwa informacji, które generują zdarzenia bezpieczeństwa, które można i należy analizować:

• wykrywanie intruzji — AWS GuardDuty
• kontrola wycieków informacji — AWS Macie
• EDR (choć mówienie o urządzeniach końcowych w chmurze brzmi nieco 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 zabezpieczeń — 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 to zrozumieć, że wszystkie one mogą generować zdarzenia, które możemy i powinniśmy analizować w kontekście bezpieczeństwa informacji, angażując zarówno wbudowane możliwości samego Amazon, jak i zewnętrzne rozwiązania, takie jak SIEM, które mogą zbierać zdarzenia bezpieczeństwa w Twoim centrum monitorowania i analizować je tam obok zdarzeń z innych usług chmurowych lub z wewnętrznej infrastruktury, perymetru lub urządzeń mobilnych.

W każdym przypadku wszystko zaczyna się od źródeł danych, które dostarczają Ci zdarzenia w zakresie bezpieczeństwa informatycznego. Do takich źródeł można w szczególności zaliczyć:

• CloudTrail — użycie API i działania użytkowników
• Trusted Advisor — audyt bezpieczeństwa według 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 z load balancera
• Inspector — wykrywanie luk w aplikacjach
• S3 — magazyn plików
• CloudWatch — aktywność aplikacji
• SNS — usługa powiadomień.

Amazon, oferując tak szeroki zakres źródeł zdarzeń i narzędzi do ich generowania, jest jednocześnie mocno ograniczony w możliwościach analizy zebranych danych w kontekście bezpieczeństwa informacji. Będziesz musiał samodzielnie przeszukiwać dostępne logi w poszukiwaniu odpowiednich wskaźników kompromitacji. AWS Security Hub, który niedawno uruchomił Amazon, ma na celu rozwiązanie tego problemu, działając jako rodzaj chmurowego SIEM dla AWS. Jednak na razie jest dopiero na początku swojej drogi i ma ograniczenia zarówno w liczbie źródeł, z którymi współpracuje, jak i w innych ograniczeniach wynikających z architektury i subskrypcji samego Amazona.

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

Nie chcę wdawać się w długą dyskusję o tym, który z trzech dostawców chmurowych (Amazon, Microsoft czy Google) jest lepszy (zwłaszcza, że każdy z nich ma swoją specyfikę i nadaje się do różnych zastosowań); skoncentrujmy się na możliwościach monitorowania bezpieczeństwa informacji, jakie oferują ci gracze. Trzeba przyznać, że Amazon AWS był jednym z pierwszych na tym rynku i dlatego wyprzedził wszystkich pod względem funkcji dotyczących bezpieczeństwa informacji (choć wielu przyznaje, że korzystanie z nich jest dość skomplikowane). Jednak nie oznacza to, że zignorujemy możliwości, jakie oferują Microsoft i Google.

Produkty Microsoft zawsze wyróżniają się swoją "otwartością" i w przypadku Azure jest podobnie. Na przykład, podczas gdy AWS i GCP zawsze przyjmują koncepcję "wszystko, co nie jest dozwolone, jest zabronione", podejście Azure jest całkowicie odwrotne. Tworząc wirtualną sieć w chmurze oraz wirtualną maszynę w tej sieci, wszystkie porty i protokoły są domyślnie otwarte i dozwolone. Dlatego też będziesz musiał poświęcić nieco więcej wysiłku na wstępne skonfigurowanie systemu kontroli dostępu w chmurze Microsoftu. To również wiąże się z bardziej rygorystycznymi wymaganiami dotyczącymi monitorowania aktywności w chmurze Azure.

AWS ma jedną szczególną cechę. Kiedy monitorujesz swoje zasoby wirtualne, napotykasz trudności w łączeniu wszystkich wydarzeń i ich jednolitej analizy, szczególnie gdy znajdują się w różnych regionach. Aby to obejść, musisz korzystać z różnych sztuczek, takich jak tworzenie własnego kodu dla AWS Lambda, który będzie przenosił wydarzenia pomiędzy regionami. W Azure ten problem nie występuje – jego mechanizm Activity Log śledzi całą aktywność w ramach organizacji bez żadnych ograniczeń. Podobnie jest z AWS Security Hub, który został niedawno opracowany przez Amazon, aby skonsolidować różne funkcje zabezpieczeń w jednym centrum bezpieczeństwa, ale tylko w ramach danego regionu, co w przypadku Rosji nie ma zastosowania. Azure ma własne Security Center, które nie jest ograniczone regionalnie, zapewniając dostęp do wszystkich funkcji bezpieczeństwa platformy chmurowej. Co więcej, dla różnych lokalnych zespołów może dostarczyć zestaw możliwości ochronnych, w tym zarządzane wydarzenia bezpieczeństwa. AWS Security Hub wciąż dąży do upodabniania się do Azure Security Center. Należy jednak dodać szczyptę goryczy – możesz wiele osiągnąć w Azure, z rzeczy, które były wcześniej opisane dla AWS, ale najwygodniej jest to zrobić tylko dla Azure AD, Azure Monitor i Azure Security Center. Wszystkie inne mechanizmy ochrony Azure, w tym analiza wydarzeń bezpieczeństwa, nie są obecnie zarządzane w najwygodniejszy sposób. Częściowo problem rozwiązują API, które przenikają wszystkie usługi Microsoft Azure, ale wymaga to dodatkowych wysiłków w zakresie integracji chmury z SOC oraz posiadania wykwalifikowanych specjalistów (właściwie jak w przypadku każdego innego SIEM, działającego z chmurowymi API). Niektóre SIEM, o których będzie mowa później, już obsługują Azure i mogą zautomatyzować monitorowanie jego funkcji, ale również z nimi występują pewne trudności – nie wszystkie potrafią pobierać wszystkie logi, które są dostępne w Azure.

Zbieranie i monitorowanie zdarzeń w Azure jest realizowane przez usługę Azure Monitor, która stanowi podstawowe narzędzie do gromadzenia, 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 działalności chmury Azure, oraz logi, zawierające dane zorganizowane w rekordach, charakteryzujące różne aspekty działania zasobów i usług Azure. Dodatkowo, dzięki Data Collector API, usługa Azure Monitor może zbierać dane z dowolnego źródła REST w celu budowania własnych scenariuszy 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. Wydarzenia związane z dostępem do odczytu (GET) nie są w nim rejestrowane, podobnie jak szereg innych.
• Dzienniki diagnostyczne — zawierają dane dotyczące operacji wykonywanych na wszystkich zasobach w 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ń Windows i Linux Syslog — zawiera zdarzenia z maszyn wirtualnych hostowanych w chmurze.
• Metryki — zawierają telemetryczne informacje o stanie wydajności i „zdrowia” Twoich usług i zasobów chmurowych. Mierzone co minutę, przechowywane przez 30 dni.
• Dzienniki przepływu grupy zabezpieczeń sieciowych — zawierają dane o zdarzeniach bezpieczeństwa w sieci, zbierane przy użyciu usługi Network Watcher oraz monitorowania zasobów na poziomie sieci.
• Dzienniki pamięci masowej — zawierają zdarzenia związane z dostępem do zasobów pamięci masowej.

Do monitorowania można używać zewnętrznych systemów SIEM lub wbudowanego Azure Monitor oraz jego rozszerzeń. O systemach zarządzania zdarzeniami związanymi z bezpieczeństwem porozmawiamy później, a teraz przyjrzyjmy się, co Azure oferuje do analizy danych w kontekście bezpieczeństwa. Głównym ekranem dla wszelkich informacji związanych z bezpieczeństwem w Azure Monitor jest Log Analytics Security and Audit Dashboard (darmowa wersja obsługuje przechowywanie ograniczonej liczby zdarzeń przez zaledwie tydzień). Panel ten dzieli się na pięć głównych obszarów, które wizualizują podsumowaną statystykę tego, co dzieje się w używanym przez ciebie środowisku chmurowym:

• Obszary 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.
• Ważne problemy — pokazuje liczbę i istotność aktywnych problemów związanych z bezpieczeństwem
• Wykrycia — przedstawia wzorce ataków, które zostały wymierzone przeciwko tobie
• Inteligencja zagrożeń — wyświetla informacje geograficzne dotyczące zewnętrznych węzłów, które cię atakują
• Typowe zapytania bezpieczeństwa — typowe zapytania, które pomogą ci lepiej monitorować swoje bezpieczeństwo.

Wśród rozszerzeń Azure Monitor można wymienić Azure Key Vault (ochrona kluczy kryptograficznych w chmurze), Malware Assessment (analiza ochrony przed złośliwym oprogramowaniem na maszynach wirtualnych), Azure Application Gateway Analytics (analiza, w tym logów chmurowej zapory) itd. 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 identyfikować wszelkie odchylenia w działaniu. Jednak, jak to często bywa, każdy dodatkowy funkcjonalność wymaga odpowiedniej płatnej subskrypcji, co wiąże się z koniecznością wcześniejszego planowania wydatków.

Azure oferuje szereg wbudowanych funkcji monitorowania zagrożeń, które są zintegrowane z Azure AD, Azure Monitor i Azure Security Center. Należą do nich na przykład 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 odbieranie alarmów z maszyn wirtualnych umieszczonych w chmurze, ataki typu „brute force” na maszyny wirtualne, luki w konfiguracji systemu identyfikacji użytkowników, logowanie się z anonimizatorów lub zainfekowanych węzłów, wyciek danych logowania, logowanie się z nietypowych lokalizacji itd. Obecnie Azure jest jednym z nielicznych dostawców chmurowych, którzy oferują wbudowane funkcje Threat Intelligence do wzbogacania zebranych zdarzeń związanych z bezpieczeństwem.

Jak już wspomniano wcześniej, funkcje ochrony oraz generowane przez nie zdarzenia bezpieczeństwa nie są dostępne dla wszystkich użytkowników w jednakowy sposób, wymagają określonej subskrypcji, która obejmuje potrzebne funkcje, generujące odpowiednie wydarzenia do monitorowania bezpieczeństwa informacji. Na przykład część funkcji opisanych w poprzednim akapicie dotyczących monitorowania anomalii w kontach jest dostępna tylko w licencji premium P2 dla usługi Azure AD. Bez niej, jak to ma miejsce w AWS, będziesz musiał analizować zebrane zdarzenia bezpieczeństwa „ręcznie”. 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 rejestracji, jak i konfigurować dashboardy do wizualizacji kluczowych wskaźników bezpieczeństwa informacji. Ponadto możesz tam wybierać rozszerzenia Azure Monitor, które pozwalają na rozszerzenie funkcjonalności dzienników Azure Monitor i uzyskanie bardziej szczegółowej analizy zdarzeń z perspektywy bezpieczeństwa.

Jeśli potrzebujesz nie tylko możliwości pracy z logami, ale także kompleksowego centrum bezpieczeństwa swojej platformy chmurowej Azure, w tym zarządzania politykami bezpieczeństwa informacji, warto rozważyć korzystanie z Azure Security Center. Większość przydatnych funkcji jest dostępna za dodatkową opłatą, takich jak wykrywanie zagrożeń, monitorowanie zewnętrzne oraz ocena zgodności. (W darmowej wersji dostępna jest tylko ocena bezpieczeństwa i rekomendacje dotyczące eliminacji wykrytych problemów). Konsoliduje to wszystkie kwestie bezpieczeństwa w jednym miejscu. W zasadzie można mówić o wyższym poziomie bezpieczeństwa informacji, niż oferuje Azure Monitor, ponieważ w tym przypadku dane z całej twojej chmury są wzbogacane o różnorodne źródła, takie jak Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) oraz Microsoft Security Response Center (MSRC), na które nakładane są zaawansowane algorytmy uczenia maszynowego i analizy behawioralnej, co powinno ostatecznie zwiększyć skuteczność wykrywania zagrożeń i reagowania na nie.

Azure ma również swój system SIEM, który zadebiutował na początku 2019 roku. To Azure Sentinel, oparty na danych z Azure Monitor, który może integrować się z zewnętrznymi rozwiązaniami zabezpieczającymi (takimi jak NGFW czy WAF), a lista tych integracji wciąż się powiększa. 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 analityczne w zakresie incydentów w chmurze Azure. Można śmiało stwierdzić, że Azure Sentinel jest pierwszym „rodzimym” SIEM wśród dostawców usług chmurowych (przykładowo, Splunk czy ELK, które można umieścić w chmurze, takiej jak AWS, zostały stworzone przez innych dostawców usług chmurowych). Azure Sentinel oraz Security Center można uznać za SOC dla chmury Azure, i w zasadzie można by na nich poprzestać (z pewnymi zastrzeżeniami), jeśli nie masz żadnej innej infrastruktury, a wszystkie swoje zasoby obliczeniowe przeniosłeś do chmury, a ta chmura to Microsoft Azure.

Jednakże, ponieważ wbudowane możliwości Azure (nawet z subskrypcją Sentinel) często nie wystarczają do celów monitorowania bezpieczeństwa informacji i integracji tego procesu z innymi źródłami zdarzeń zabezpieczeń (zarówno chmurowymi, jak i wewnętrznymi), pojawia się potrzeba eksportu zebranych danych do zewnętrznych systemów, wśród których może znajdować się także SIEM. Może to być realizowane 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 i ELK. Jeszcze niedawno takich SIEM było więcej, ale od 1 czerwca 2019 roku Microsoft zaprzestał wsparcia dla Azure Log Integration Tool (AzLog), który na początku istnienia Azure, przy braku odpowiedniej standaryzacji pracy z logami (Azure Monitor jeszcze nie istniał), umożliwiał łatwą integrację zewnętrznych SIEM z chmurą Microsoft. Obecnie sytuacja się zmieniła i Microsoft zaleca platformę Azure Event Hub jako główne narzędzie integracji dla pozostałych SIEM. Wiele osób już przeprowadziło tę integrację, ale zachowaj ostrożność — mogą one nie obejmować wszystkich logów Azure, a jedynie niektóre (sprawdź w dokumentacji swojego SIEM).

Podsumowując krótką wizytę w Azure, chciałbym dać ogólną rekomendację dotyczącą tej usługi chmurowej. Zanim jednak zaczniecie oceniać funkcje monitorowania bezpieczeństwa w Azure, warto je dokładnie skonfigurować i przetestować, aby upewnić się, że działają zgodnie z dokumentacją oraz jak przekazali to doradcy Microsoft (może być różnica w ich spojrzeniu na funkcjonalność Azure). W przypadku wystarczających środków finansowych, Azure może przynieść wiele korzyści w zakresie monitorowania zabezpieczeń. Jeśli jednak Państwa zasoby są ograniczone, tak jak w przypadku AWS, będziecie musieli polegać jedynie na własnych zasobach i surowych danych dostarczanych przez Azure Monitor. Pamiętajcie, że wiele funkcji monitorowania wiąże się z kosztami, dlatego warto wcześniej zapoznać się z polityką cenową. Na przykład, za darmo można przechowywać dane przez 31 dni na maksymalnie 5 GB na klienta — przekroczenie tych wartości będzie wiązać się z dodatkowymi kosztami (około 2+ dolarów za przechowywanie każdego dodatkowego GB i 0,1 dolara za przechowywanie 1 GB co dodatkowy miesiąc). Praca z telemetrią aplikacji i metrykami również może wymagać dodatkowego finansowania, podobnie jak zarządzanie alertami i powiadomieniami (dostępny jest limit darmowy, który może nie być wystarczający dla Państwa potrzeb).

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

Google Cloud Platform w porównaniu do AWS i Azure wydaje się całkiem młody, ale to w pewnym sensie dobrze. W przeciwieństwie do AWS, który stopniowo rozwijał swoje funkcje, w tym zabezpieczenia, z problemami z centralizacją, GCP, podobnie jak Azure, jest lepiej zarządzany centralnie, co zmniejsza liczbę błędów i czas implementacji w przedsiębiorstwie. Z punktu widzenia bezpieczeństwa, GCP znajduje się, co dziwne, pomiędzy AWS a Azure. Posiada także wspólny dla całej organizacji rejestr zdarzeń, ale jest on niepełny. Niektóre funkcje są wciąż w fazie beta, ale stopniowo ta wada powinna zostać usunięta, a GCP stanie się bardziej dojrzałą platformą z punktu widzenia monitorowania bezpieczeństwa.

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

• Aktywność administratora — zawiera wszystkie zdarzenia związane z dostępem administracyjnym, takie jak tworzenie maszyny wirtualnej, zmiana uprawnień itp. Ten dziennik jest zapisany zawsze, niezależnie od Twojej woli, i przechowuje swoje dane przez 400 dni.
• Dostęp do danych — zawiera wszystkie zdarzenia związane z pracą użytkowników chmurowych (tworzenie, zmiana, odczyt itp.). Domyślnie ten dziennik nie jest zapisywany, ponieważ jego objętość szybko rośnie. Z tego powodu okres jego przechowywania wynosi zaledwie 30 dni. Co więcej, nie wszystkie zdarzenia są w nim rejestrowane. Na przykład, nie zapisuje on zdarzeń związanych z zasobami publicznie dostępnymi dla wszystkich użytkowników lub które są dostępne bez logowania się do GCP.
• Zdarzenie systemowe — zawiera zdarzenia systemowe, które nie są związane z użytkownikami, ani działania administratora, który zmienia konfigurację zasobów chmurowych. Jest zawsze zapisywane i przechowywane przez 400 dni.
• Access Transparency to unikalny przykład dziennika audytu, który rejestruje wszystkie działania pracowników Google (choć na razie nie dla wszystkich usług GCP), które mają dostęp do Twojej infrastruktury w ramach wykonywania swoich obowiązków. Dziennik ten jest przechowywany przez 400 dni i jest dostępny tylko dla wybranych klientów GCP, jeśli spełnione są określone warunki (lub wsparcie na poziomie Gold lub Platinum, lub posiadanie czterech ról określonego typu w ramach wsparcia korporacyjnego). Podobna funkcja występuje również na przykład w 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:  "Case number: 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.com%2Faccess_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 możliwy jest na kilka sposobów (podobnie jak w przypadku wcześniej omawianych Azure i AWS) — przez interfejs Log Viewer, przez API, przez Google Cloud SDK lub przez stronę Aktywności Twojego projektu, w którym interesują Cię zdarzenia. W ten sam sposób można je exportować do zewnętrznych rozwiązań w celu dodatkowej analizy. Ostatnia opcja polega na eksporcie dzienników do BigQuery lub Cloud Pub/Sub.

Oprócz Stackdriver Logging platforma GCP oferuje także funkcjonalność Stackdriver Monitoring, która pozwala na monitorowanie kluczowych metryk (wydajności, czasu pracy na awarię, ogólnego stanu itd.) usług i aplikacji chmurowych. Specjalnie przetworzone 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 funkcja ta będzie raczej uboga w aspekcie bezpieczeństwa informacji, ponieważ obecnie GCP nie ma odpowiednika AWS GuardDuty i nie potrafi wyróżniać spośród wszystkich rejestrowanych zdarzeń tych rzeczywiście niepożądanych (Google opracował Event Threat Detection, ale na razie znajduje się w wersji beta, więc o jego przydatności jeszcze za wcześnie mówić). Stackdriver Monitoring można by wykorzystać jako system wykrywania anomalii, które następnie byłyby badane w celu ustalenia przyczyn ich wystąpienia. Jednak w obecnych warunkach braku wykwalifikowanego personelu w zakresie bezpieczeństwa informacji na rynku, to zadanie wydaje się na chwilę obecną dość skomplikowane.

Warto również wymienić niektóre moduły dotyczące bezpieczeństwa, które można zastosować w chmurze GCP i które są podobne do tych oferowanych przez AWS:

• Cloud Security Command Center — odpowiednik AWS Security Hub oraz Azure Security Center.
• Cloud DLP — automatyczne wykrywanie i edytowanie (np. maskowanie) danych umieszczonych w chmurze, zgodnie z ponad 90 predefiniowanymi politykami klasyfikacji.
• Cloud Scanner — skaner znanych podatności (XSS, Flash Injection, niezałatane biblioteki itp.) w App Engine, Compute Engine i Google Kubernetes.
• Cloud IAM — zarządzanie dostępem do wszystkich zasobów GCP.
• Cloud Identity — zarządzanie kontami użytkowników, urządzeniami i aplikacjami GCP z jednego miejsca.
• Cloud HSM — ochrona kluczy kryptograficznych.
• Cloud Key Management Service — zarządzanie kluczami kryptograficznymi w GCP.
• VPC Service Control — tworzenie zabezpieczonego obszaru wokół 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ć przesyłane do przechowalni BigQuery w celu analizy lub eksportu do innych systemów, w tym do SIEM. Jak już wcześniej wspomniano, GCP to platforma w aktywnym rozwoju, a Google opracowuje szereg nowych modułów dotyczących bezpieczeństwa dla swojej platformy. Wśród nich znajduje się Event Threat Detection (obecnie dostępny w wersji beta), który przeszukuje logi Stackdriver w poszukiwaniu nieautoryzowanej aktywności (odpowiednik GuardDuty w AWS), oraz Policy Intelligence (dostępny w wersji alfa), który umożliwi opracowanie inteligentnych zasad dostępu do zasobów GCP.

Przygotowałem krótką analizę 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 na zakup rozszerzonych funkcji AWS, Azure czy Google)? Ponadto wielu jest znane powiedzenie „ufaj, ale sprawdzaj”, które w dziedzinie bezpieczeństwa jest bardziej aktualne niż kiedykolwiek. Jak bardzo ufacie wbudowanym możliwościom chmurowego dostawcy, które przekazują Wam zdarzenia dotyczące bezpieczeństwa? Jak bardzo koncentrują się w ogóle na bezpieczeństwie?

Czasami warto zwrócić uwagę na zewnętrzne rozwiązania do monitorowania infrastruktury chmurowej, które mogą uzupełnić wbudowane zabezpieczenia chmury, a czasem takie rozwiązania są jedyną opcją, aby uzyskać dane na temat bezpieczeństwa Twoich danych i aplikacji umieszczonych w chmurze. Ponadto są po prostu wygodniejsze, ponieważ przejmują wszystkie obowiązki związane z analizą potrzebnych logów generowanych przez różne usługi chmurowe różnych dostawców chmury. Przykładem takiego zewnętrznego rozwiązania jest Cisco Stealthwatch Cloud, który koncentruje się na jednej kwestii – monitorowaniu anomalii bezpieczeństwa w środowiskach chmurowych, w tym nie tylko Amazon AWS, Microsoft Azure i Google Cloud Platform, ale także chmur prywatnych.

Przykład: Monitoring bezpieczeństwa za pomocą Stealthwatch Cloud

AWS oferuje elastyczną platformę do obliczeń, jednak ta elastyczność może prowadzić do popełniania błędów przez firmy, co z kolei prowadzi do problemów z bezpieczeństwem. Dzielony model cyberbezpieczeństwa tylko to potęguje. Uruchamianie w chmurze oprogramowania z nieznanymi podatnościami (z tymi znanymi można walczyć, na przykład, za pomocą AWS Inspector lub GCP Cloud Scanner), słabe hasła, nieprawidłowe konfiguracje, insajderzy itp. Wszystko to wpływa na działanie zasobów chmurowych, które mogą być monitorowane przez Cisco Stealthwatch Cloud, będący systemem monitorowania bezpieczeństwa i wykrywania ataków w chmurach publicznych i prywatnych.

Jedną z kluczowych funkcji Cisco Stealthwatch Cloud jest możliwość modelowania zasobów. Dzięki temu można stworzyć model programowy (czyli symulację prawie w czasie rzeczywistym) każdego z Twoich zasobów chmurowych (nieważne, czy jest to AWS, Azure, GCP czy coś innego). Mogą to być serwery oraz użytkownicy, a także typy zasobów specyficzne dla Twojego środowiska chmurowego, takie jak grupy zabezpieczeń i grupy automatycznego skalowania usług (auto-scale). Modele te wykorzystują ustrukturyzowane strumienie danych dostarczane przez usługi chmurowe jako dane wejściowe. Na przykład w przypadku AWS będą to VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda oraz AWS IAM. Modelowanie zasobów automatycznie identyfikuje rolę i zachowanie każdego z Twoich zasobów (można mówić o profilowaniu całej aktywności chmurowej). Wśród takich ról znajdują się urządzenia mobilne Android lub Apple, serwer Citrix PVS, serwer RDP, brama pocztowa, klient VoIP, serwer terminalowy, kontroler domeny itp. Następnie nieprzerwanie monitoruje ich zachowanie, aby określić, kiedy pojawia się ryzykowne lub zagrażające bezpieczeństwu zachowanie. Możesz zidentyfikować próby łamania haseł, ataki DDoS, wycieki danych, nieautoryzowany dostęp zdalny, działanie złośliwego oprogramowania, skanowanie luk oraz 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:

Oto jak wygląda przypuszczony wyciek informacji z bazy danych Postgres do kraju, z którym wcześniej nie współpracowano:

Na koniec, tak wygląda zbyt duża liczba nieudanych prób dostępu przez SSH z Chin i Indonezji z zewnętrznego urządzenia:

Załóżmy, że instancja serwera w VPC według polityki nigdy nie powinna być punktem docelowym dla zdalnego dostępu do systemu. Zakładając, że na tym komputerze doszło do zdalnego logowania w wyniku błędnej zmiany polityki zasad zapory sieciowej. Funkcja modelowania encji wykryje i zgłosi tę aktywność („Nietypowy zdalny dostęp”) w prawie rzeczywistym czasie oraz wskaże konkretne wywołanie API AWS CloudTrail, Azure Monitor lub GCP Stackdriver Logging (w tym nazwę użytkownika, datę i godzinę oraz inne szczegóły), które spowodowały zmianę w zasadzie MSE. Następnie te informacje mogą być przekazane do SIEM do 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 nieznane problemy związane z naszymi pracownikami, procesami lub technologiami. Na przykład, pozwala to na identyfikację różnych problemów bezpieczeństwa, takich jak:

• Czy ktoś odkrył backdoor w oprogramowaniu, które używamy?
• Czy w naszym chmurze znajdują się jakiekolwiek nieautoryzowane oprogramowanie lub urządzenia?
• Czy autoryzowany użytkownik nadużywa przywilejów?
• Czy wystąpił błąd w konfiguracji, który umożliwia zdalny dostęp lub inne niezamierzone wykorzystanie zasobów?
• Czy nie występuje przeciek danych z naszych serwerów?
• Czy ktoś próbował się z nami połączyć z nietypowego miejsca geograficznego?
• Czy nasze chmura nie jest zainfekowana złośliwym oprogramowaniem?

Wykryte zdarzenie związane z bezpieczeństwem może być przekazane w postaci odpowiedniego zgłoszenia do Slacka, Cisco Spark, systemu zarządzania incydentami PagerDuty oraz przekazywane 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 opisane powyżej sprawiają, że zastosowanie Cisco Stealthwatch Cloud jest rozsądną opcją dla uzyskania zunifikowanego zestawu narzędzi do monitorowania wiodących graczy chmurowych — Amazonu, Microsoftu i Google. Co ciekawe, porównując ceny Stealthwatch Cloud z zaawansowanymi licencjami na monitorowanie bezpieczeństwa w AWS, Azure czy GCP, może się okazać, że rozwiązanie Cisco jest nawet tańsze od wbudowanych możliwości Amazonu, Microsoftu i Google. Paradoksalnie, ale to prawda. Im więcej chmur i ich możliwości wykorzystujesz, tym bardziej oczywista staje się przewaga skonsolidowanego rozwiązania.

Co więcej, Stealthwatch Cloud może monitorować także prywatne chmury wdrożone w twojej organizacji, na przykład te oparte na kontenerach Kubernetes lub poprzez monitorowanie strumieni Netflow czy ruchu sieciowego, pozyskiwanego dzięki mirroringowi w sprzęcie sieciowym (nawet krajowej produkcji), danych AD lub serwerów DNS itd. Wszystkie te dane będą wzbogacane informacjami Threat Intelligence, zbieranymi przez jednostkę Cisco Talos, która jest największą na świecie pozarządową grupą badaczy zagrożeń w dziedzinie bezpieczeństwa informacji.

Umożliwia to stworzenie jednolitego systemu monitorowania zarówno chmur publicznych, jak i hybrydowych, które może wykorzystać twoja firma. Zebrane informacje mogą być następnie analizowane za pomocą wbudowanych możliwości Stealthwatch Cloud lub przesyłane do twojego SIEM (obsługiwane domyślnie są Splunk, ELK, SumoLogic i inne).

Na tym zakończymy pierwszą część artykułu, w której omówiłem wbudowane i zewnętrzne narzędzia do monitorowania bezpieczeństwa IaaS/PaaS-platform, które pozwalają nam szybko wykrywać i reagować na incydenty mające miejsce w chmurowych środowiskach wybranych przez nasze przedsiębiorstwo. W drugiej części kontynuujemy temat i przyjrzymy się opcjom 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 chmurowych.

Źródło: habr.com