As Secure As Possible
Bezpieczeństwo systemów IT jest zagadnieniem złożonym i skomplikowanym - ściśle technicznym. Łącząc świat biznesu i technologii, zapraszam Cię do rozmowy o bezpieczeństwie, do której nie będziemy potrzebować słownika IT.
Bezpieczeństwo systemów IT jest zagadnieniem złożonym i skomplikowanym - ściśle technicznym. Łącząc świat biznesu i technologii, zapraszam Cię do rozmowy o bezpieczeństwie, do której nie będziemy potrzebować słownika IT.
Na potrzeby tego artykułu przyjmijmy na początku kilka założeń. Jestem managerem średniej wielkości sklepu internetowego sprzedającego części motoryzacyjne. Firma ma stałych klientów i wyrobioną, rozpoznawalną markę. Zespół tworzy 4 developerów rozwijających aplikację i 1 administrator serwerów. Wykorzystuję usługi chmurowe jednego z większych dostawców cloud, ale mój zespół jest odpowiedzialny za całość. Korzystam z dedykowanego silnika eCommerce Magento w wersji open source. Zamówienia i dane Klientów zarządzane są z dodatkowych systemów klasy ERP (Enterprise Resources Planning) i CRM (Customer Relationship Management). Magazyn korzysta z wbudowanego modułu WMS (Warehouse Management System), który zarządza stanami magazynowymi i wysyłkami.
Aplikacja
Aby usługa eCommerce mogła zarabiać na siebie, jako manager potrzebuję aplikacji, która realizuje taką funkcjonalność. Wybrany system - Magento - opisywany jest jako stabilny, wszystko-mający i przede wszystkim bezpieczny silnik. I to wszystko jest prawdą. Adobe raz na kwartał publikuje poprawki bezpieczeństwa i nowe funkcjonalności. Jednak aktualizacja systemu zajmuje czas, wymaga testów i nierzadko dodatkowych prac programistycznych, aby system działał zgodnie z wymaganiami. Co kwartał, razem z wydanymi poprawkami publikowane są również informacje[1] na temat wykrytych i naprawionych zagrożeń Magento. Oznacza to, że potencjalne luki bezpieczeństwa w systemie są publiczne i jeśli posiadamy wystarczającą wiedzę, możemy je wykorzystać.
Ale skąd ktokolwiek będzie wiedział, że mam Magento i w jakiej wersji? Przecież nigdzie tego nie publikuję. Otóż rozpoznanie Magento na podstawie kodu HTML w przeglądarce jest bardzo proste: strona zawiera charakterystyczne struktury, które na pierwszy rzut oka wręcz krzyczą, że jest to Magento.
Jeżeli sklep jest obsługiwany przez zespół z mniejszym doświadczeniem, często pomijane jest ukrycie wersji systemu, która standardowo dostępna jest pod adresem /magento_version
Co zatem mogę zrobić?
Wiedząc o cyklicznych wydaniach poprawek[2] mogę zaplanować z moim zespołem testy i aktualizacje. Takie podejście minimalizuje czas potrzebny na wdrożenie poprawek bezpieczeństwa i eliminuje element zaskoczenia w kontekście zasobów i budżetu. Świadoma rezygnacja z aktualizacji, znając luki bezpieczeństwa, które zostały wykryte i naprawione, jest dopuszczalna w określonych sytuacjach, ale wysoce niezalecana. Tylko ode mnie zależy, czy biorę to ryzyko na siebie. Cykliczne aktualizacje aplikacji na pierwszy rzut oka nie wnoszą większej wartości biznesowej do systemu. Ich brak może jednak spowodować skompromitowanie systemu, wyciek danych klientów, instalację złośliwego oprogramowania, a w najgorszym przypadku całkowite unieruchomienie usługi lub nawet kary finansowe (hello RODO). Muszę też pamiętać, że nawet po aktualizacji bezpieczeństwa nikt nie gwarantuje, że przez kolejny kwartał nic się nie wydarzy. Co więcej mogę zrobić?
Jak monitorować bezpieczeństwo?
Aktualizuję Magento zgodnie z harmonogramem. Mój zespół jest przygotowany na kolejne wydania. Mój system jest bezpieczny.
Mając z tyłu głowy wiedzę, że nie ma systemów perfekcyjnie zabezpieczonych, muszę sobie odpowiedzieć na pytania:
- Skąd mam wiedzieć, że zastosowane poprawki bezpieczeństwa przyniosły zamierzony efekt?
- Jak sprawdzić, czy aplikacja nie zawiera dodatkowych podatności bezpieczeństwa?
Web Application Security Testing
Jest to klasa wyspecjalizowanych narzędzi, które skanują w sposób automatyczny sklep i aktywnie informują o wykrytych problemach. Przykładem takiego systemu jest Acunetix[3].
Co mi to da?
- Cykliczne skany bezpieczeństwa (np. raz na tydzień, co każde wydanie nowej wersji przygotowanej przez mój zespół)
- Przejrzyste raporty pokazujące kondycję mojego sklepu
- Dokładne wskazówki dla mojego zespołu technicznego, jak szybko naprawić problemy.
Wybierając rozwiązanie dla siebie zwróć uwagę na to, czy skaner wykonuje proof of exploit. Mniej dopracowane skanery potrafią w raportach wskazywać setki pozycji, które mogą być potencjalnie groźne, ale nie zostały niepotwierdzone - tak zwany False Positive. Często jest to niepotrzebny szum.
IDS/IPS
Intrusion Detection Systems, czyli swojego rodzaju alarm, jak w samochodzie. Głównym zadaniem tego narzędzia jest wykrycie próby włamania i poinformowanie o tym odpowiednich osób.
Intrusion Prevention Systems, czyli, korzystając z tej samej analogii, pies przy samochodzie. Są to rozwiązania, których zadaniem jest wykrywanie ataków oraz ich blokowanie. Często są powiązane z IDS.
Inne ciekawe możliwości realizowane przez tego typu narzędzia to:
- File Integrity Monitoring – sprawdzanie, czy pliki systemowe oraz pliki aplikacji zostały zmodyfikowane w nieuprawniony sposób.
- Malware Detection - "antywirus" dla aplikacji webowych.
Narzędzia klasy Web Application Security Testing oraz IPD/IDS uzupełniają się wzajemnie i stanowią relatywnie łatwy sposób na monitorowanie zagrożeń i potencjalnych incydentów.
WAF i Firewall
Opisane wcześniej systemy monitorowania w żaden sposób nie zabezpieczają mnie przez zagrożeniami. Wykryte problemy muszą zostać rozwiązane przez odpowiednie osoby techniczne. Co zatem zrobić, aby ograniczyć atakującym osobom i botom pole manewru? Jednym z dostępnych rozwiązań są firewalle sieciowe oraz ich wersja dla aplikacji: Web Application Firewall. Są to systemy, które na podstawie predefiniowanych reguł weryfikują ruch do naszego eCommerce i blokują go, jeżeli zostanie spełniony warunek w regułach.
Dla przykładu: chcę zablokować ruch do mojego sklepu wszystkich botów innych niż zbierających dane dla określonych wyszukiwarek.
Co mogą blokować systemy WAF? Na przykład niektóre ataki typu XSS, SQL Injection, ruch szkodliwych botów.
Ponieważ powstają coraz to nowsze metody ataków, coraz bardziej wyrafinowane i trudniejsze do wykrycia, bardziej zaawansowane systemy WAF posiadają algorytmy Machine Learning i częste aktualizacje predefiniowanych reguł. Możemy również ograniczyć ruch do naszego systemu bazując na geolokalizacji - na przykład jeżeli sprzedajemy wyłącznie do klientów z Polski.
Zastosowanie WAF ogranicza w znaczący sposób szkodliwy ruch i limituje poziom wystąpienia incydentów bezpieczeństwa. Należy jednak pamiętać, żeby używać ich z głową. Nie chcemy przecież blokować najszej platformy eCommerce dla klientów i dobrych botów (bramki płatności, Google)
Izolacja kluczowych usług
Posiadając system eCommerce muszę być świadomy, że pewna część usług, które są wymagane do prawidłowego działania, nie powinna być dostępna publicznie. Warto na przykład sprawdzić, czy panel administracyjny nie znajduje się pod domyślnym adresem /admin i dodatkowo wprowadzić ograniczenie adresów IP, które mogą mieć dostęp (IP restriction) lub nawet prosty system Basic Authentication (dodatkowy login i hasło).
Z perspektywy biznesu może to być pewnego rodzaju przeszkoda - jestem na wakacjach i chcę się dostać do raportów albo w trakcie podróży służbowej chcę zobaczyć, ile mam nowych zamówień. Dobrym remedium na to jest posiadanie systemu Virtual Private Network (VPN), który umożliwi nam dostęp do ukrytych przed światem zewnętrznym zasobów z każdego miejsca. Aktualne systemy VPN pozwalają na instalację na niemal każdym urządzeniu (laptop, telefon, tablet) i są łatwe w obsłudze.
Infrastruktura
Wróćmy do naszego eCommerce.
Aktualizacje są, monitoring jest, mam WAF, który chroni mój sklep.
Czas porozmawiać o infrastrukturze.
W nocy z 9 na 10 marca 2021 roku w Strasburgu spłonęło centrum danych należące do dużego europejskiego dostawcy serwerów dedykowanych. Wiele usług w Polsce i innych krajach Unii, a w przypadku niektórych stron - globalnie, przestało działać; część z nich nie podniosła się do dnia dzisiejszego.
Jakie wnioski można wyciągnąć z tego zdarzenia?
Żaden operator serwerów dedykowanych i hostingu, niezależnie od wielkości, nigdy nie da 100% gwarancji na dostępność swoich usług. Teoretycznie może tak napisać, ale życie pokazuje, że jest to niemożliwe. Rozważmy zatem kilka aspektów tego, co można zrobić, żeby ustrzec się przed długą przerwą w działaniu mojego sklepu.
Architektura High Availability (dalej zwana HA)
Jest to tak zaprojektowana architektura infrastruktury i aplikacji, która umożliwia prawidłowe działanie, nawet w przypadku awarii komponentów systemu. W większości przypadków kluczowe komponenty są zwielokrotniane w trybie High Availability i w czasie normalnej pracy nie biorą udziału w dostarczaniu usług. Możemy tutaj również wspomnieć o rozproszonym HA, którego komponenty są rozmieszczone w różnych datacenter (serwerowniach), różnych krajach czy nawet kontynentach. Budując architekturę klasy HA musimy się liczyć z jej znacznym kosztem. Wspomniana duplikacja usług oraz wysoki koszt utrzymania powodują, że nie wszystkie organizacje mogą się w całości zaopatrzyć w takie rozwiązania.
Infrastructure as a Code
Innym sposobem na szybkie przywrócenie w pełni funkcjonalnej infrastruktury jest Infrastructure as Code.
W dużym skrócie: nie tworzymy zasobów z panelu administracyjnego danego operatora, zamiast tego piszemy odpowiednią definicję infrastruktury, reszta robiona jest automatycznie. Zaczynając od maszyn, sieci, dysków, a na domenach i zaawansowanej konfiguracji kończąc.
W skrócie: praca, która normalnie wymaga kilku czy nawet kilkunastu dni na konfigurację, trwa kilkanaście minut. Oprócz tego jest powtarzalna i przewidywalna.
Kopie zapasowe
"Ludzie dzielą się na dwa typy – tych, którzy już robią backupy, oraz tych, którzy będą je robić."
Podchodząc do zagadnienia kopii zapasowych należy sobie zadać kilka pytań:
Co?
- Jakie dane są dla mnie ważne?
- Czy posiadając kopie zapasowe, przykładowo samej bazy danych, będę w stanie odtworzyć działanie sklepu?
Najczęstszą praktyką w kopiach zapasowych jest wykonywanie kopii baz danych zawierających klientów, zamówienia, produkty i wszystkie inne dane dotyczące samego sklepu. Dodatkowo warto wykonywać kopie plików konfiguracyjnych aplikacji oraz pliki mediów (grafiki, filmy, itp.).
Oczywiście każdy eCommerce jest inny, ale odpowiadając sobie na powyższe pytania można w prosty sposób wskazać obszary, które muszą być archiwizowane/objęte polityką kopii zapasowych.
Jak często?
- Jak szybko zmieniają się dane w moim sklepie?
- Ile dziennie dochodzi klientów, zamówień, produktów?
Definiując czas między kopiami zapasowymi musimy mieć świadomość, że rzadko wykonywane są one w locie - to znaczy, że przy poważnej awarii część danych może zostać bezpowrotnie utracona. Systematyka tworzenia backupów uwarunkowana jest potrzebami i zachowaniem klientów rozwiązania eCommerce. Lokalny sklep może pozwolić sobie na włączenie trybu "maintenance" (czyli de facto chwilowym wyłączeniem pełnej funkcjonalności sklepu) w godzinach nocnych, a sklep działający globalnie musi takie same prace przeprowadzać dużo ostrożniej. Nie możemy przecież wyłączyć funkcjonowania sklepu w czasie kiedy klient finalizuje zamówienie. Znając to ryzyko można oszacować, jak utrata danych z kilku lub kilkunastu godzin działania aplikacji dotknie mój biznes. Jeżeli dojdziemy do akceptowalnych wartości - mamy odpowiedź, jak często.
Jak?
Nie ma jednoznacznie optymalnego sposobu, w jaki sposób wykonywać kopie zapasowe. Kopie przyrostowe, kopie całościowe, dedykowane aplikacje, snapshoty - wszystko zależy od złożoności architektury oraz konkretnych wymogów klienta i jego budżetu. Jeżeli nie wiesz, od czego zacząć, zacznij od kopii całościowych; na przykład pełnego zrzutu bazy danych i kopii plików sklepu.
Ale pamiętaj: lepszy prosty backup niż żaden.
Gdzie?
Kopie zapasowe muszą być składowane w innym miejscu niż oryginalne źródło danych. Co to oznacza?
Dobrą praktyką jest strategia 3-2-1
Trzy kopie danych (źródło danych i dwie kopie), dwa niezależne urządzenia (na przykład dysk i dodatkowy snapshot dysku), przynajmniej jedna z kopii przechowywana w innym miejscu.
Wróćmy na chwilę do pożaru w Strasburgu. Wiele poważnych serwisów bezpowrotnie utraciło dane i kopie zapasowe właśnie dlatego, że były one przechowywany w tylko jednym datacenter.
Strategia 3-2-1 nie jest doskonała, ale nie ma rzeczy doskonałych. Podejście jest dobrą praktyką rekomendowaną przez specjalistów czy instytucje rządowe różnych państw, np. US-CERT (United States Computer Emergency Readiness Team), który opisał zasadę 3-2-1 w swojej publikacji już w 2012 roku[4].
Czy da się to odtworzyć?
Okresowe testy odtwarzania kopii zapasowych mają równie duże znaczenie jak wykonywanie kopii. Po co nam backup, jeżeli nie da się go wykorzystać?
Niezależnie od tego, czy testy będą wykonywane manualnie czy automatycznie, powinny być przeprowadzane w środowisku nieprodukcyjnym (np. środowisko stage) - nie chcemy przecież uszkodzić danych źródłowych. Dobrą praktyką jest przeprowadzanie odtwarzania z kopii zapasowej w kontrolowanym środowisku co minimum 3 - 4 miesiące.
Wnioski
Omówiliśmy podstawowe zagadnienia dotyczące bezpieczeństwa systemów IT w kontekście eCommerce.
Aby oszacować, które z przedstawionych zagadnień mogą być dla Ciebie szybkie do wdrożenia, zakładając relatywnie niewielki budżet, przygotowałem poniższe zestawienia:
Powyższe diagramy mogą być użyte w większości przypadków jako pomoc do planowania budżetu i specjalistów wdrażających poszczególne zabezpieczenia.
Dodatkowo, proponuję Ci pobranie przygotowanego dokumentu.
Ten Excel pomoże Ci w oszacowaniu ryzyk technicznych i ustaleniu, gdzie na skali bezpieczeństwa znajduje się Twój biznes.
Z tego miejsca chciałbym Cię zaprosić na drugą część tematyki IT Security, w której poruszymy zagadnienie obszarów miękkich, związanych z ludźmi w Twojej organizacji.
Jeśli masz pytania czekamy na Twój kontakt.