Bezpieczeństwo sklepów internetowych opartych na platformie Magento 2

Marcin Bukowski – Head of Development i Członek Zarządu w Fast White Cat, na co dzień kieruje zespołem deweloperów, dbając o jakość dostarczanych projektów pod względem oprogramowania. 

Wcześniej, jako Magento Tech Lead i Backend Developer, nabierał doświadczenia w programowaniu i wdrażaniu Magento dla dużych, znanych brandów z obszaru eCommerce.

Można dostrzec pewne utopijne przeświadczenie w ciągłej rywalizacji o klienta w online, gdzie konieczne są wdrożenia coraz to nowych funkcjonalności spełniających oczekiwania biznesowe, implementowanie kolejnych integracji z systemami zewnętrznymi czy też  z  wprowadzanymi zmianami technologicznymi, które zachodzą w sklepach internetowych w celu utrzymania odpowiedniej pozycji sklepu lub zwiększenia jego konkurencyjności poprzez większą atrakcyjność samej platformy.   Przeświadczenie to zdaje się sugerować, iż sfera związana z bezpieczeństwem sklepów internetowych jest auto-adaptacyjna i nie wymaga dużej uwagi – wszak wiele mechanizmów zabezpieczających otrzymujemy out of the box, stawiając na przykład na Magento 2. Podejście to – czasem  nieumyślnie – kładzie ogromny nacisk na obszar wytwarzania oprogramowania “samego w sobie” i odpowiedniej jakości, a przy tym przy stosowaniu dobrych praktyk, ale z pominięciem etapu analizy danego utworu pod kątem bezpieczeństwa. 

W tym artykule chciałbym skupić się jednak na tym właśnie obszarze. Spróbuję wskazać, jakie działania podejmować, by jak najlepiej utrzymywać i rozwijać platformy e-commerce (w szczególności te oparte na Magento 2), przy tym zachowując odpowiedni poziom ich bezpieczeństwa. Podejście do tego zagadnienia powinno być holistyczne. Cóż nam bowiem po zapewnieniu pełnego poziomu bezpieczeństwa naszej aplikacji w kontekście, dajmy na to OWASP Top 10, jeśli nie zabezpieczyliśmy odpowiednio dostępu np. do sieci, w której uruchomiona jest infrastruktura lub fizycznego dostępu do serwerowni (co może i brzmi absurdalnie, ale również jest zagadnieniem z obszaru bezpieczeństwa)?  W tekście przekażę również konkretne, praktyczne wskazówki wypracowane na podstawie wielu lat doświadczenia w pracy z Magento 2 oraz kilkunastu wdrożonych, utrzymywanych i rozwijanych stale projektów.

Infrastruktura

Jednym z elementów, bez którego sklep internetowy nie będzie działał, a tym bardziej sprzedawał, jest odpowiednio dobrana infrastruktura, czyli krótko pisząc – wybór rozwiązania serwerowego, a w tym zapewnienie takiej konfiguracji oraz mocy obliczeniowej, aby platforma obsłużyła ruch oraz działała sprawnie i szybko. Jest to też oczywiście sfera o ogromnym znaczeniu w kontekście bezpieczeństwa. 

Projektując architekturę, należy zwrócić szczególną uwagę na następujące elementy:

• Odpowiednie zabezpieczenie warstwy sieciowej np. poprzez właściwe wydzielenie i  konfigurację sieci prywatnej, w której uruchamiamy usługi składowe (MySql, Redis, Elasticsearch, itd.) naszej platformy, uniemożliwiając dostęp do tych usług bezpośrednio z sieci publicznej, ale jednocześnie umożliwiając dostęp do nich np. poprzez wdrożenie rozwiązania typu Bastion Host z dostępem do warstwy SSH wyłącznie po kluczach (również z mechanizmem 2FA) ze ściśle określonej listy adresów IP.
  Zdarzają się wciąż platformy i  systemy, których maszyny/serwery posiadają adresację publiczną oraz mają otwarte na świat nadmiarowe porty.
• Szyfrowaną komunikację (z wykorzystaniem np. protokołu SSL) nie tylko w komunikacji klienta z serwerem, ale również w komunikacji między usługami składowymi w sieci prywatnej oraz zabezpieczenie połączeń między poszczególnymi usługami, choćby z wykorzystaniem loginu i hasła.
  Aby w złym zamiarze wykorzystać brak szyfrowania lub dostęp do usług bez konieczności logowania, przy odpowiednim zabezpieczeniu sieci,  należałoby najpierw złamać zabezpieczenia sieci, aczkolwiek ten aspekt jest często pomijany, gdyż może wymagać dodatkowych zmian w systemach, platformach i ich modułach.
• Szyfrowanie dysków, zasobów bazodanowych, zasobów typu s3. 
• Ograniczenie ruchu między usługami tylko do niezbędnego zakresu otwartych portów, konfiguracja reguł przyjmujących i wysyłających ruch tylko od/do określonych usług.
• Bazowanie na wspieranych wersjach systemów operacyjnych, automatyczne aktualizacje pakietów systemów operacyjnych, na których uruchamiany usługi, np. poprzez mechanizm unattended-upgrades.
  Przy ekosystemach złożonych z dziesiątek lub setek maszyn wirtualnych czy serwerów, konieczne jest wdrożenie mechanizmów automatyzujących ten aspekt.
• Przechowywanie logów i ich odpowiednia retencja.
  Praktyka ta jest szczególnie istotna dla analizy ataków i proaktywnej reakcji na nie lub np. w momencie stwierdzenia incydentu związanego z bezpieczeństwem.
• Umieszczanie haseł w usługach typu secret manager.
  Jest to odpowiedź na praktykę przechowywania haseł w plikach konfiguracyjnych, plikach zmiennych środowiskowych.
• Stosowanie się do zasady najmniejszych przywilejów dla użytkowników oraz dbanie o utrzymanie jak najmniejszej, niezbędnej ilości kont administracyjnych.
  Tę rekomendację najefektywniej można zrealizować  poprzez centralne systemy zarządzania dostępami wraz ze szczególnymi politykami dostępów i odpowiednimi procedurami w przypadku konieczności usunięcia np. konta administratora czy użytkownika.

Powyższe rekomendacje wdrożymy bez względu na dostawcę usługi serwerowej, choć niektóre z nich będą łatwiejsze w implementacji przy pracy w zaawansowanych rozwiązaniach cloud’owych (AWS, Azure, GCP), gdzie wykorzystanie natywnych usług sprowadzi się wręcz tylko do poprawnych ich konfiguracji. Trudniej i dłużej będzie przy korzystaniu z maszyn typu VPS, serwerów dedykowanych czy też dla infrastruktury w modelu on-premise. W związku z tym, już na etapie wyboru usługi serwerowej, rozsądnie jest przeanalizować oferowane możliwości i skorzystać z tych rozwiązań, które posiadają wbudowane mechanizmy zapewniające lepszy poziom bezpieczeństwa, mimo iż nominalnie koszty ich utrzymania będą większe.

Aplikacja

Oprócz oczywistych zaleceń, np. związanych z konfiguracją aplikacji dotyczących polityki haseł, wspomnianych zasad projektu OWASP Top 10, przedstawiam również inne wskazówki związane z obszarem samej aplikacji:

• Systematyczna aktualizacja i utrzymywanie aplikacji oraz jej składowych w najnowszych wersjach.
  Mimo tego, iż powyższa zasada jest podstawową, a przestrzeganie jej to absolutna koniecznością, w dalszym ciągu aspekt ten bywa traktowany bez należytej uwagi. Wynika to m.in. z relatywnie sporych nakładów pracy i inwestycji, aby na bieżąco utrzymywać usługi, systemy czy pakiety w aktualnych, wspieranych wersjach, w szczególności dla systemów składających się z wielu elementów.
• Zabezpieczenie  strefy back-office (np. admin panel) poprzez zastosowanie unikalnej ścieżki dostępowej do panelu (w tym również innej subdomeny) oraz wyodrębnienie tej części aplikacji w taki sposób, aby dostęp do niej możliwy był tylko z określonej listy adresów IP (allow-list) przy wykorzystaniu usług typu load balancer.
• Niestosowanie ścieżek zawierających liczbowe identyfikatory obiektów przy aplikacjach stosujących np. autoinkrementację rekordów zapisywanych w bazie danych.
  Ujawniając tego rodzaju identyfikatory, możemy narazić naszą aplikację na dostęp do  danych lub informacji poprzez zastosowanie techniki enumeracji.
• Usunięcie, wyłączenie lub zabezpieczenie ścieżek czy narzędzi służących do diagnostyki lub opisu pewnych części aplikacji.
  W Magento 2 szczególnie często nie są ukrywane informacje na temat zainstalowanej wersji aplikacji, dostęp do “Swaggera”, itd.
• Zabezpieczenie informacji, które mogą zostać ujawnione poprzez stosowanie tzw. systemu introspekcji.
  Spotykane w zyskujących na popularności rozwiązaniach typu headless, gdzie do komunikacji między backend a frontend używany jest GraphQL (PWA Studio).
• Odpowiednie mechanizmy bezpieczeństwa dla API typu GraphQL, np.: ograniczenie głębokości zapytania, ograniczenie złożoności zapytania, wprowadzenie limitów na wielkości zwracanych kolekcji danych, nietworzenie zapytań GraphQL dynamicznie np. w javascript.
• Korzystanie w komunikacji z odpowiednich nagłówków HTTP (np. Content-Security-Policy, Strict-Transport-Security) oraz ograniczenie dozwolonych metod w tym również zablokowanie metod typu TRACK / TRACE.
• Ograniczenie ujawniania informacji o środowisku w nagłówkach odpowiedzi HTTP.
  Wdrożenie konfiguracji poszczególnych usług, ukrywającej meta-tagi. 
• Stosowanie rozwiązań typu WAF, narzędzi i usług anty-ddos np. AWS WAF, AWS Shield, CloudFlare, Akamai. W tym również mechanizmów zabezpieczających aplikację na warstwie siódmej wg modelu OSI.
• Nieprzesyłanie danych uwierzytelnienia otwartym tekstem np. w formularzach logowania.

Inne

W tej części wymienię pozostałe zalecenia, które ciężko przypisać do w/w obszarów lub ich klasyfikacja znalazłaby się na ich styku:

• Wdrożyć i rozwijać odpowiednie standardy w procesie wytwarzania oprogramowania w celu zapobiegania błędom, które mogą skutkować wyciekiem danych z systemu, np:
  • nieumieszczanie plików importów / eksportów lub innych plików zawierających np. dane wrażliwe na zasobach publicznie dostępnych,
  • anonimizacja danych, które mogą zostać zapisane w plikach logów lub w centralnych serwerach logów,
  • zwrócenie szczególnej uwagi na zapobieganie umieszczenia w cache (np. typu full page cache) informacji, które zawierać mogą indywidualne dane użytkownika, 
  • zabezpieczenie wysyłki wiadomości z danymi klientów i/lub zamówień do wielu adresatów (w tym adresata innego niż właściciel zamówienia).
• Ukrycie za allow-list lub choćby mechanizmem basic-auth środowisk typu test, stage, itd. bez względu na okoliczności.
• Monitorowanie i analiza logów oraz metryk w celu wykrywania potencjalnych incydentów związanych z bezpieczeństwem.
• Ciągły rozwój, wdrażanie zmian, usprawnień i poprawek do swoich systemów, nie kultywowanie tezy “działa – nie ruszam” przy tematach związanych z bezpieczeństwem, a dotykających również tzw. projektów “legacy”.
• Regularne skanowanie aplikacji dedykowanymi narzędziami, sprawdzającymi występowanie podatności, aktualność wersji oprogramowania, wdrożone patche bezpieczeństwa.

Podsumowanie

Bezpieczeństwo jest cenne. Zabezpieczajmy swoje aplikacje, wdrażajmy coraz to wyższe standardy i coraz dokładniejsze procedury dotyczące jakości wytwarzanego oprogramowania, w tym również w obszarze bezpieczeństwa. Warto to robić, nawet mimo konieczności poniesienia czasem sporych nakładów inwestycji i pracy, które nie są widoczne na pierwszy rzut oka przez klienta naszego sklepu oraz mogą być niezauważane, pomijane i trudno akceptowane przez tzw. “biznes”. Ostatecznie to udostępnienie sklepu bezpiecznego, dającego pewność ochrony danych klientów, buduje odpowiedni poziom zaufania.

Chcesz  więcej? https://fastwhitecat.com/