Chmura obliczeniowa? To czyjś komputer – cz. 2

Zarządzenie bezpieczeństwem danych w chmurze obliczeniowej przez dzierżawcę jej instancji jest mocno ograniczone, a odpowiedzialność podzielona między operatora, klienta i użytkownika. W efekcie analiza śledcza potencjalnych nadużyć, która wymaga zabezpieczenia niezaprzeczalnych, cyfrowych dowodów, może być nacechowana utrudnieniami niespotykanymi w innych modelach przetwarzania informacji. Można jednak przygotować się do niej, wybierając chmury o parametrach sprzyjających procesom informatyki śledczej.

W poprzedniej części publikacji o chmurach obliczeniowych zastanawialiśmy się nad problemami, które towarzyszą akwizycji cyfrowych dowodów z systemów przetwarzania danych. W tym odcinku spróbujemy poznać niektóre z rozwiązań i obejść tych problemów – zarówno od strony klienta, jak i operatora usług.

Ślady intruza w chmurze obliczeniowej

Aby analizować działania sprawcy, potrzebujemy śladów jego aktywności, które będzie cechowała niezaprzeczalność (ang. repudiation). Nie zawsze wystarczać nam będą opatrzone sygnaturami raporty obsługi bieżącej – musimy mieć dostęp do twardych, cyfrowych dowodów: zazwyczaj danych z powierzchni dysku i pamięci komputera, który przetwarza dane. Systemowe i aplikacyjne raporty zdarzeń również będą pomocne, ponieważ dostarczą metadanych.

Problem polega na tym, że wspomnianych śladów próżno szukać w raportach zdarzeń działania usługi chmurowej dostępnych klientowi – szczególnie wtedy, gdy mamy do czynienia z atakiem wymierzonym w środowisko operacyjne usługodawcy. Wynika to z faktu, że jako klient czy upoważniony przez klienta śledczy najzwyczajniej w świecie nie mamy dostępu do infrastruktury. Nawet, gdy zidentyfikujemy zbiory danych, których analiza jest niezbędna, możemy mieć problem z zabezpieczeniem cyfrowego materiału dowodowego.

Powyższy problem można próbować rozwiązać umownie, gwarantując sobie zawczasu odpowiedni dostęp do nośników lub ich kopii. Uzyskanie porozumienia z operatorem na tym poziomie jest jednak mało prawdopodobne, ponieważ nawet ewentualna zgoda na dostęp do „surowych danych” nie gwarantuje pełnego sukcesu, kiedy okaże się, że w chmurze zastosowano model, w którym dane różnych klientów separowane są logicznie, a nie fizycznie. Jest to scenariusz bardzo prawdopodobny, gdyż właśnie w ten sposób obniża się koszty zarządzania zbiorami danych – bazy danych, systemy plikowe czy urządzenia pamięci masowych są współdzielone między klientami o różnych potrzebach pod względem zasobów. Gromadzeniu i analizie nie będą poddawane wyłącznie dane interesującego dzierżawcy, lecz najprawdopodobniej informacje należące do kilkudziesięciu innych usługobiorców, które mogą stanowić tajemnicę wymagającą zwolnienia z obowiązku ochrony przez upoważniony organ państwowy (np. sąd bądź prokuraturę).

Próbując pozyskać zidentyfikowane dane możemy też napotkać inny, prozaiczny problem: informacje, owszem są, lecz część znajduje się na macierzy dyskowej w Los Angeles, a część na dyskach wbudowanych w serwery działające w kilku serwerowniach zlokalizowanych gdzieś między Bugiem a Nysą. Poza rozproszeniem istotna dla zdolności i kosztu badania będzie też ilość informacji. Śledczy będą musieli wręcz brodzić w jeziorze danych (ang. data lake) i wnioskować o raporty zdarzeń pochodzące z wielu lokalizacji.

Podsumowując: w przypadku chmur trudność pozyskania i analizy materiału dowodowego polega na tym, że jest on często ulotny (ang. volatile), nietrwały (ang. fragile), nielokalny (ang. nonlocal) oraz zdecentralizowany (ang. decentralized). Specjalizowane struktury danych stosowane przez dostawców usług chmurowych sprawiają też, że trudne lub niemożliwe jest badanie z użyciem oprogramowania automatyzującego ten proces. Zamiast gotowych narzędzi trzeba korzystać z odpowiedników generycznych (heksadecymalnych przeglądarek zawartości dysku, tekstowych i binarnych narzędzi przeszukujących czy generatorów kryptograficznych funkcji skrótu); agregowanie i późniejsza analiza informacji są możliwe pod warunkiem przekształcenia zebranych danych do właściwych formatów, np. z wykorzystaniem własnoręcznie stworzonych skryptów i aplikacji.

Zmiana paradygmatu

Trudności z analizą śledczą danych znajdujących się w chmurach obliczeniowych nie można uniknąć bez gruntownej zmiany podejścia. Należy przyznać, że niektóre metodyki nie znajdą tu zastosowania i poszukać skutecznych alternatyw, w których powstawanie zaangażowane będą nie tylko laboratoria informatyki śledczej, ale też projektanci i administratorzy chmur. Aby tego dokonać, należy świeżym okiem spojrzeć na problem bezpieczeństwa przetwarzania chmurowego i zauważyć, że uczestniczą w nim następujące komponenty:

  • operacyjny system kliencki (uruchamianie oprogramowania klienckiego),
  • oprogramowanie klienckie (łączność z usługą działającą w chmurze),
  • lokalna lub rozległa sieć komputerowa (przesyłanie danych klient-serwer),
  • serwer usługi chmurowej (zarządzanie informacjami),
  • środowisko operacyjne chmury (zarządzanie danymi).

Mogliśmy wcześniej zauważyć, że skupianie się wyłącznie na ostatnich ogniwach środowiska przetwarzania (serwerze usługi i środowisku chmury) nie daje zadowalających rezultatów. Warto więc zogniskować energię na pozostałych fragmentach łańcucha komponentów biorących udział w operacjach, a także zastanowić się, co mogliby zrobić dostawcy chmur, aby otworzyć możliwości analizy śledczej.

W przypadkach naruszeń dokonywanych przez użytkowników usługi chmurowej cennym źródłem danych do analizy będzie aktywność ich systemów klienckich i działającego na nich oprogramowania. Przydatne są tu znajdujące się w systemie plikowym podręczne bufory, często wykorzystywane do synchronizowania danych między systemami końcowymi a usługami działającymi w chmurach – znajdziemy tam artefakty wykonywanych operacji i danych umieszczanych w zdalnych lokalizacjach, a czasem nawet wierne kopie zbiorów informacji, z których można odzyskać najbardziej aktualne dane. W praktyce potrzebujemy tu dostępu do nośników stacji użytkowników (komputerów stacjonarnych czy urządzeń przenośnych). Niestety, badanie zawartości końcówek w przypadku ataku wymierzonego w systemy samej chmury nie zda się na wiele, ponieważ nie będzie dostępu do komponentów, których zabezpieczenia zostały przełamane.

Równie pomocna, jak wyżej opisana, metoda analizy polega na badaniu aktywności sieciowej między klientem a chmurą. Zastosowanie znajdą tu raporty zdarzeń dotyczące wykonywanych połączeń, a także logi systemów wykrywania włamań (ang. intrusion detection systems, skr. IDSs), które są w stanie wykrywać i rejestrować anomalie w ruchu sieciowym. Informacje o połączeniach sieciowych mogą być cennymi metadanymi, które dostarczą wiedzy o tym, gdzie szukać dalszych śladów, jak również potwierdzą lub zaprzeczą występowaniu pewnych zdarzeń, a tym samym pozwolą wyeliminować fałszywe przesłanki, np. umieszczone przez potencjalnego intruza, aby utrudnić analizę.

Prewencja

Rozwiązaniem problemu braku dostępu do niskopoziomowych informacji dotyczących kondycji chmur mogłaby być praktyka wyposażania ich w odpowiednie interfejsy administracyjne nadające się do użytkowania przez śledczych. Pozwalałyby one na badanie stanu wirtualnego środowiska (usługi bądź wirtualnego systemu operacyjnego), np. przez sondowanie procesów (uruchomionych programów) działających na konkretnych rdzeniach CPU, określanie fizycznej lokalizacji danych (ze wskazaniem konkretnego wolumenu macierzy dyskowej) czy dostęp do informacji o aktualnie utrzymywanych połączeniach sieciowych (z opcjonalnym rejestrowaniem pakietów spełniających pewne kryteria). Zainteresowani klienci byliby wtedy w stanie prewencyjnie gromadzić dane diagnostyczne, które umożliwiałyby późniejsze korelowanie istotnych faktów, a w pewnych przypadkach wysuwanie żądań o dostęp do wskazanych zasobów.

Brak fizycznej separacji danych należących do różnych instancji chmur może być też kłopotliwy dla usługodawców, jeżeli naruszenie jest przedmiotem postępowania prowadzonego przez organy ścigania. Wydając odpowiednie postanowienie uprawniony urząd może zażądać wydania wszystkich danych dotyczących konkretnego klienta bez względu na ich fizyczną lokalizację. Dla operatora chmury oznacza to sporo pracy, do której może jednak zawczasu się przygotować, najlepiej już w momencie tworzenia architektury. Pomocne są w tym przypadku mechanizmy oznaczania (ang. tagging) przepływających i magazynowanych danych unikatowymi identyfikatorami instancji. Gdy nadejdzie żądanie udostępnienia zbioru danych dotyczących konkretnego klienta, możliwe jest filtrowanie zawartości wolumenów po wspomnianych znacznikach. Podobnie będzie w przypadku analiz cyber forensics, np. podsłuchiwania ruchu sieciowego – tu do oznaczania można wykorzystać zarezerwowane pola nagłówkowe pakietów IP lub pakietów warstwy transportowej. Podejście to pozwala też operatorowi skuteczniej zarządzać chmurą i chronić się przed wyciekami danych, ponieważ na niskim poziomie jest w stanie odróżniać aktywność związaną z instancjami oraz precyzyjnie sterować dostępem.

Określone miejsce

Niektórzy dostawcy rozwiązań chmurowych pozwalają klientom określić fizyczną lokalizację danych przetwarzanych w ich chmurach. Ma to szczególne znaczenie w przypadku konieczności zachowania zgodności z normatywnymi aktami prawnymi dotyczącymi ochrony i przetwarzania danych. Na przykład microsoftowa chmura Azure umożliwia przyporządkowanie zasobów dyskowych dzierżawionej instancji do centrów danych znajdujących się w Europie, aby nie dochodziło do działań sprzecznych z ustawami o ochronie danych osobowych, jeżeli w usłudze przetwarzane będą dane klientów spółki, która działa na terenie UE.

Z punktu widzenia informatyki śledczej możliwość wyboru fizycznej lokalizacji danych (np. regionu geograficznego, kraju bądź konkretnego centrum przetwarzania danych) jest krokiem w dobrym kierunku. Po pierwsze redukcji ulega zbiór możliwych miejsc, w których należy poszukiwać materiału dowodowego, a po wtóre ułatwia akwizycję danych w drodze formalnego postanowienia (ten sam system prawny, brak konieczności współpracy organów ścigania z różnych państw itd.).

Szyfrowanie homomorficzne

Nadzieję na wyłączne zarządzanie danymi przez dzierżawcę chmury, a w związku z tym na możliwość pełnego zarządzania przez niego bezpieczeństwem informacji, daje intensywnie rozwijany mechanizm szyfrowania zwany szyfrowaniem w pełni homomorficznym (ang. fully homohorphic enctryption, skr. FHE). Pomijając szczegóły techniczne, polega ono na tym, że usługodawca jest w stanie operować na zaszyfrowanej postaci danych klienta i na przykład dokonywać obliczeń czy zestawień (stosować algorytmy) bez dostępu do jawnych form informacji. Dopiero klient, wyposażony w odpowiedni klucz, może dokonać odszyfrowania rezultatów. W ten sposób bezpieczeństwo przetwarzania staje się niezależne od sprzętu, a więc zachowana jest poufność i integralność nawet wtedy, gdy zbiór danych jest przesyłany bądź magazynowany w niezaufanym ośrodku.

Gwarancje integralności i utajnienia – oczywiście pod warunkiem, że nie doszło do ujawnienia klucza deszyfrującego – może znacznie ułatwić proces cyfrowej analizy śledczej, szczególnie wykonywanej w modelu B2B, gdyż materiałem dowodowym jest wtedy logiczny zbiór danych, a nie nośnik. Ten ostatni, chociaż w posiadaniu operatora chmury, będzie zawierał wyłącznie szyfrogramy, bezużyteczne z punktu widzenia badania zawartości. Oznacza to, że podmiotem wyłącznie odpowiedzialnym za zarządzanie danymi (z technicznego punktu widzenia) stanie się dzierżawca chmury i wyłącznie on będzie mógł przekazać dane do analizy.

Niezależność informacji od środowiska operacyjnego, w którym są przetwarzane, oznacza też, że potencjalne ataki cybernetyczne wymierzone w systemy zarządzające danymi nie będą mogły skutkować kradzieżami. Wciąż możliwe będzie zakłócenie pracy usługi (np. z wykorzystaniem ataków typu DoS czy DDoS), usunięcie zbioru danych, a nawet prowokowanie błędów w obliczeniach (np. przez podmianę aplikacji chmurowej lub jej konfiguracji), jednak nie dojdzie do klasycznego wycieku, który polegałby na przełamaniu zabezpieczeń systemu należącego do operatora i ekstrakcji danych.

Szyfrowanie w pełni homomorficzne jest na dzień dzisiejszy możliwe, chociaż mocno niewydajne – w wielu poważnych ośrodkach badawczych trwają intensywne prace, aby zmienić ten stan rzeczy. Poza tym nie istnieją jeszcze standardy dotyczące konkretnych metod szyfrowania czy mechanizmów generowania i wymiany kluczy. Istotnych zmian w tej kwestii możemy spodziewać się najwcześniej za kilka lat.

Chmura obliczeniowa – Wnioski

Informatyka śledcza usług chmurowych stawia przed nami nowe wyzwania i skłania do prowadzenia badań oraz analiz, które pozwolą ustalić dobre praktyki zarówno w postępowaniu z materiałem dowodowym, jak i w tworzeniu przestrzeni dla klientów, aby odzyskali możliwość zarządzania bezpieczeństwem własnych danych. Ten drugi proces wymaga współpracy i standaryzacji na poziomie operatorów i architektów chmur – będziemy więc świadkami ewolucji w tej dziedzinie i powinniśmy przy różnych okazjach komunikować nasze potrzeby. Warto zauważyć, że łatwość akwizycji danych leży również w interesie operatora chmury – unika w ten sposób żmudnego, ręcznego procesu gromadzenia i filtrowania informacji bądź metadanych pochodzących z wielu źródeł i od wielu instancji oprogramowania usługowego.

Już teraz możemy tak poprowadzić procesy określania wymagań klienta i planowania architektury jego systemu IT, aby ewentualna analiza computer forensics była możliwa i wykonalna. Poza zapisami umownymi powinniśmy zadbać o techniczne możliwości dostępu do raportów zdarzeń dotyczących naszych danych, a nawet (w miarę możliwości) do pozyskania informacji z nośników. Wydaje się to trudne – szczególnie, gdy mamy do czynienia ze współdzieleniem zasobów między różnymi dzierżawcami – lecz z problemem tym jesteśmy w stanie sobie poradzić, włączając w proces świadczenia usług trzecią, zaufaną stronę, czyli bezstronną organizację powołaną do reagowania na incydenty związane z naruszeniami. Powinna mieć ona pełen dostęp do danych chmury, również na poziomie nośników, a jej zadaniem byłoby odpowiednie filtrowanie, gromadzenie i uprawnione przekazywanie danych, gdy pojawi się taka konieczność. W tym miejscu warto zaznaczyć, że pomysł na niezależnego partnera technologiczno-operacyjnego w procesie korzystania z chmur jest propozycją standardu i pewnego rodzaju innowacją, a nie powszechną praktyką.

Na koniec warto pamiętać o sprawach formalnych. Chcemy unikać fizycznego przechowywania danych w miejscach, które znajdują się na geograficznych obszarach podlegających innym systemom prawnym, aby w razie incydentu wymagającego zaangażowania organów ścigania nie ryzykować międzynarodowej współpracy i ewentualnych odmów udostępnienia danych. Jeżeli jest to niemożliwe, warto zdecydować się na takie kraje, między którymi od dłuższego czasu funkcjonują odpowiednie umowy i porozumienia (np. o ochronie danych), dzięki czemu w razie potrzeby będziemy mogli korzystać z przetartych już ścieżek postępowania.

Literatura przedmiotu

  •  Z. Hassan, R. Ismail, Y. Yusoff, „Comon Phases of Computer Forensics Investigation Models” [online], Universiti Tenaga National, Selangor, aktualizacja 14.06.2011 [dostęp 04.06.2016], http://airccse.org/journal/jcsit/0611csit02.pdf
  • W. E. May, „NIST Cloud Computing Forensic Science Challenge” [online], NIST, Gaithesburg, aktualizacja 23.06.2014 [dostęp 05.06.2016], http://csrc.nist.gov/publications/drafts/nistir-8006/draft_nistir_8006.pdf
  • G. Meyer, A. Stander, „Cloud Computing: The digital forensics challenge” [online] [na:] konferencja inSITE 2015, University of South Florida, Tampa, aktualizacja 09.06.2015 [dostęp 04.06.2016], http://proceedings.informingscience.org/InSITE2015/InSITE15p285-299Meyer1562.pdf
  • P. Wilk, „Nadciąga rewolucja w kryptografii” [online] [w:] BAD[SECTOR].PL, Wrocław, aktualizacja 05.05.2013 [dostęp 07.06.2016], https://badsector.pl/w-praktyce/wiadomosci/2013/05/nadciaga-rewolucja-w-kryptografii.90.html

Podobne wpisy

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *