Czy Big Data to Big Problem?
-
- 20.11.2013
W systemach przetwarzających dane klasy Big Data podobny mechanizm jest trudno zaimplementować. Przeważnie obowiązuje proste uwierzytelnienie użytkownika za pomocą loginu i hasła, zintegrowane z firmowymi usługami katalogowymi. Na przeszkodzie przed wdrożeniem systemów z precyzyjnie określonymi poziomami uprawnień stoi zazwyczaj problem związany z samą istotą analityki obecnej w tych systemach – nie da się dokładnie ograniczyć możliwych zapytań, gdyż do chwili ich wykonania nie wiadomo, jakie dane będą podlegać analizie.
Podatny front-end
Aby aplikacja korzystająca z zasobów klasy Big Data była łatwa w obsłudze, często integruje się ją z narzędziami front-end działającym z użyciem interfejsu webowego. Aplikacja od strony klienta jest realizowana za pomocą języków, takich jak: PHP, ASP czy nawet Node.js, a zatem może zawierać podatności typowe dla innych aplikacji webowych. Oznacza to, że pospolita podatność SQL Injection czy Cross-Site Scripting (obie razem stanowią większość znalezionych luk w stronach webowych) umożliwi napastnikowi skorzystanie z narzędzia Big Data z pominięciem uwierzytelnienia lub na podwyższonym poziomie uprawnień. Jest to poważne zagrożenie, gdyż jak podaje raport WhiteHat Security za maj 2013 r., prawdopodobieństwo wystąpienia przynajmniej jednej luki w bezpieczeństwie w aplikacji webowej wynosi aż 55% w przypadku luki skutkującej wyciekiem informacji i aż 53%, gdy mówimy o podatności Cross-Site Scripting.
Zobacz również:
- IDC CIO Summit – potencjał drzemiący w algorytmach
- Kwanty od OVHCloud dla edukacji
- Inteligentna chmura danych
Drugim kanałem komunikacji, coraz częściej wykorzystywanym w rozwiązaniach wykorzystujących Big Data, są aplikacje instalowane na smartfonach. Aplikacje te również mogą zawierać błędy, które napastnik mógłby wykorzystać. W przypadku obu najważniejszych platform – Androida oraz iOS – najpopularniejsze podatności dotyczą możliwości wstrzyknięcia kodu lub wycieku informacji. Raport State of Software Security 2013 firmy VeraCode wskazuje, że w przypadku 76% problemów z bezpieczeństwem aplikacji na platformie Google Android przyczyną jest jakość kodu, a przy Apple iOS obsługa błędów (76%). W obu platformach występują problemy z zabezpieczeniami kryptograficznymi (wg raportu VeraCode podatności dotyczą aż 64% badanych aplikacji dla Androida i 58% dla iOS).
Trudno znaleźć nadużycie
W aplikacjach korzystających z koncepcji klasy Big Data analiza obejmuje porcje informacji pobierane z różnych źródeł i obecne w różnej formie – strukturalnej, takiej jak baza danych i niestrukturalnej, w postaci plików. Ponieważ działania ściśle analityczne obejmują oba zasoby, włamywacz nie musi korzystać z danych zawartych w bazach – niekiedy o wiele ważniejsze informacje można pozyskać z innych źródeł. O ile w systemach takich jak ERP można łatwo ograniczyć zakres danych dostępnych dla każdego zalogowanego użytkownika, w przypadku aplikacji analitycznych korzystających z Big Data jest to o wiele trudniejsze.
Aby zmniejszyć ryzyko utraty danych z rozwiązań klasy Big Data, można wykorzystać te same środki, które były przez lata stosowane w aplikacjach biznesowych, takich jak ERP. Podstawowe mechanizmy to redakcja, tokenizacja i wprowadzenie zabezpieczeń w niższych warstwach.
Redakcja
Mechanizm redakcji danych polega na usuwaniu informacji szczególnego znaczenia, zastępując ją przy tym jednolitymi ciągami, takimi jak XXX-XXX. Metoda ta sprawdza się w aplikacjach ERP i może być zastosowana selektywnie, zależnie od poziomu uprawnień. Przy oprogramowaniu korzystającym z biznesowej bazy danych (np. Oracle) redakcję danych można przeprowadzić już na poziomie bazy, a dzięki temu zmniejszyć ryzyko wycieku, nawet gdyby napastnik ominął aplikację i zalogował się na poziomie swoich uprawnień bezpośrednio do bazy danych. Redakcję zasobów klasy Big Data można przeprowadzić w samej aplikacji albo przed zasileniem danych, na etapie pozyskiwania i wczytywania informacji.
W odróżnieniu od systemów ERP w rozwiązaniach Big Data mamy przeważnie do czynienia z zaawansowaną analityką biznesową, dlatego też skuteczność redakcji danych może być niższa od oczekiwanej. Jeśli tylko te same porcje informacji znajdą się pod różną postacią w różnych miejscach, możliwe jest cofnięcie tych zmian. Przykładem może być wskazanie konkretnego klienta na podstawie podanego przez niego kodu pocztowego i ostatnich cyfr karty płatniczej. Na problem związany z cofnięciem redakcji w zbiorach związanych z programami lojalnościowymi niektórych sklepów zwracał uwagę nawet Generalny Inspektor Ochrony Danych Osobowych. Mimo że klient nie podawał informacji umożliwiających bezpośrednią personifikację listy zakupów, kombinacja wymienionych informacji z powodzeniem umożliwiła wskazanie zakupów konkretnej osoby.
Innym problemem, bardzo dokuczliwym w przypadku redakcji danych przy tworzeniu osobnej instancji oprogramowania do celów testowych, jest inne zachowanie baz danych po wyredagowaniu danych w bazie. Baza danych strojona pod kątem wydajności w środowisku testowym na wyredagowanych danych będzie zachowywać się inaczej niż docelowa, w środowisku produkcyjnym.
Tokenizacja
Nieco mniej radykalną metodą ochrony danych od redakcji jest ich tokenizacja. Zamiast porcji informacji o szczególnym znaczeniu, takich jak numery PESEL pracowników i innych podobnych rekordów, w bazie umieszcza się losowe wartości. Pomiędzy tymi losowymi rekordami a oryginalną wartością istnieje przyporządkowanie przechowywane w osobnych, strzeżonych zasobach. Dzięki zastąpieniu ważnych porcji danych przez ich losowe odpowiedniki ewentualna kradzież informacji przyniesie o wiele mniej dotkliwe skutki dla firmy. Dane po tokenizacji mają o wiele mniejszą wartość dla włamywacza niż oryginalne. Oznacza to, że niekiedy atak może się po prostu nie opłacać.
Podobnie jak w przypadku redakcji niekiedy istnieje możliwość cofnięcia tokenizacji, czyli odkrycie przypisania danych za pomocą informacji znajdujących się w zasobach, ale w innej formie. Przykładem jest odkrycie tych samych informacji, takich jak PESEL czy NIP, w dokumentach niestrukturalnych i przypisanie ich do danych strukturalnych dostępnych w innej części zasobów.
Dodatkowe zabezpieczenia
Najczęściej stosowanym zabezpieczeniem jest separacja zasobów, która zakłada dodatkowe uwierzytelnienie, np. za pomocą tokenów. Metoda
