Bezpieczeństwo sklepu internetowego: co zabezpiecza platforma, a co zależy od sprzedawcy

Bezpieczeństwo sklepu internetowego dzieli się na dwie części: warstwę serwerową, którą w abonamencie utrzymuje dostawca platformy, i warstwę kont, danych oraz procedur, za którą odpowiada sprzedawca. Sklep pada ofiarą incydentu najczęściej przez tę drugą część: przejęte konto pracownika, phishing na skrzynkę firmową albo brak procedury na wypadek awarii. Ten artykuł pokazuje, gdzie kończy się odpowiedzialność dostawcy, a zaczyna odpowiedzialność sprzedawcy.

Kto odpowiada za bezpieczeństwo sklepu internetowego: platforma czy sprzedawca?

Bezpieczeństwo sklepu internetowego rozkłada się na dwie strony: dostawca platformy odpowiada za warstwę serwerową w abonamencie, sprzedawca za konta, dane i procedury.

W przypadku platformy działającej w modelu abonamentowym właściciel sklepu nie zarządza bezpośrednio serwerem ani silnikiem oprogramowania. Dlatego pytanie „czy mój sklep jest bezpieczny?” warto rozbić na dwa osobne zagadnienia: jakie zabezpieczenia zapewnia dostawca w ramach usługi oraz jakie ryzyka powstają przez codzienne decyzje po stronie firmy.

Taki podział można określić jako model podzielonej odpowiedzialności. Dostawca chroni infrastrukturę i warstwę serwerową, natomiast sprzedawca odpowiada między innymi za sposób logowania do panelu administracyjnego, uprawnienia pracowników, bezpieczeństwo danych wyeksportowanych poza sklep czy reakcję na incydent.

Wiele poradników dotyczących bezpieczeństwa sklepu internetowego miesza obie warstwy w jedną listę, obok siebie wymieniając certyfikat SSL, kopie zapasowe, silne hasła i dwuskładnikowe logowanie. W efekcie właściciel sklepu może nie wiedzieć, które zadania wykonuje za niego dostawca platformy, a które wymagają działania wewnątrz jego firmy.

Co zabezpiecza dostawca platformy w ramach abonamentu?

Dostawca platformy w abonamencie odpowiada przede wszystkim za techniczną warstwę działania sklepu. Obejmuje to szyfrowanie transmisji pomiędzy przeglądarką klienta a serwerem, ochronę infrastruktury przed atakami wolumetrycznymi, aktualizacje silnika platformy, kopie zapasowe infrastruktury oraz monitoring serwerów.

Sprzedawca nie musi ręcznie instalować poprawek do podstawowego oprogramowania ani samodzielnie zarządzać serwerem. Przykładem takiego modelu jest IdoSell, gdzie warstwa infrastruktury pozostaje po stronie dostawcy platformy.

Przy własnym hostingu podział wygląda inaczej. Właściciel sklepu albo jego wykonawca musi wtedy sam zadbać o aktualizacje, konfigurację środowiska, kopie zapasowe, monitoring oraz zabezpieczenia infrastruktury. Abonament przenosi więc część obowiązków technicznych na dostawcę, ale nie usuwa wszystkich ryzyk związanych z prowadzeniem sprzedaży.

Co zostaje po stronie sprzedawcy niezależnie od platformy?

Bezpieczeństwo sklepu internetowego po stronie sprzedawcy zaczyna się od kont użytkowników. Właściciel firmy odpowiada za silne hasła, uwierzytelnianie dwuskładnikowe, przyznawanie uprawnień i ich odbieranie osobom, które nie powinny już mieć dostępu do panelu administracyjnego.

Po stronie sprzedawcy pozostaje także bezpieczeństwo kluczy do integracji, sposób przechowywania danych klientów poza panelem, na przykład w arkuszach lub załącznikach mailowych, oraz procedura działania w przypadku incydentu. Firma musi również ustalić, jaki zakres obowiązków dotyczących PCI DSS wynika ze sposobu obsługi płatności kartą.

Model podzielonej odpowiedzialności oznacza więc, że dostawca zabezpiecza techniczne fundamenty platformy, a sprzedawca odpowiada za sposób korzystania z tych zabezpieczeń w codziennej pracy. Dalej w tym artykule każdy z tych obszarów jest rozwinięty osobno, od dostępów pracowników po dane, incydenty i zgodność płatniczą.

Ile realnie kosztuje przestój: jak przeliczyć SLA i dostępność na minuty w roku?

Bezpieczeństwo sklepu internetowego obejmuje też dostępność: SLA 99,9% oznacza około 8 godzin 45 minut przestoju rocznie, a 99,99% około 52 minuty.

SLA, czyli zobowiązanie dotyczące poziomu dostępności usługi, często jest podawane w procentach. Sama wartość 99,9% albo 99,99% niewiele jednak mówi właścicielowi sklepu, dopóki nie zostanie przeliczona na realny czas, przez który sklep może pozostawać niedostępny.

Obliczenie jest proste. Rok nieprzestępny ma 525 600 minut. Wystarczy pomnożyć procent dopuszczalnej niedostępności przez tę liczbę. Przy SLA 99,9% niedostępność wynosi 0,1%, czyli około 525,6 minuty w ciągu roku. Daje to około 8 godzin 45 minut. Przy dostępności 99,99% niedostępność spada do 0,01%, czyli około 52 minut rocznie.

Wartości w tabeli są wyliczeniem własnym na podstawie 525 600 minut w roku, a nie statystyką pochodzącą od konkretnego dostawcy.

SLA nie należy też utożsamiać z rzeczywistą dostępnością sklepu w przeszłości. SLA jest zobowiązaniem umownym dotyczącym poziomu usługi, natomiast historyczna dostępność pokazuje, jak system działał w określonym okresie. Dostawca może więc deklarować konkretny poziom SLA, ale sama deklaracja nie mówi jeszcze, ile przestojów faktycznie wystąpiło w poprzednim roku.

Tabela przeliczeniowa: 99%, 99,9%, 99,99% i 99,999% dostępności

Procentowa deklaracja dostępności staje się użyteczna dopiero po przeliczeniu jej na realny czas przestoju. Poniższa tabela pokazuje, ile maksymalnie może wynosić niedostępność w skali roku przy poszczególnych poziomach SLA, przy założeniu roku nieprzestępnego liczącego 525 600 minut.

Różnica między dostępnością 99,9% a 99,99% na pierwszy rzut oka wygląda jak niewielka zmiana po przecinku. W praktyce oznacza jednak przejście z niemal dziewięciu godzin potencjalnego przestoju rocznie do mniej niż jednej godziny.

Bezpieczeństwo sklepu internetowego warto więc oceniać nie tylko przez sam procent SLA, ale przez jego realne przełożenie na czas niedostępności. Konkretnej wartości nie należy przypisywać żadnemu dostawcy bez sprawdzenia aktualnych warunków umowy, daty deklaracji i sposobu mierzenia dostępności.

Jak zabezpieczyć konta i dostępy pracowników w sklepie internetowym?

Bezpieczeństwo sklepu internetowego najczęściej przełamuje się przez przejęte konto pracownika, nie przez lukę w serwerze dostawcy.

W praktyce wiele incydentów zaczyna się w warstwie ludzi, kont i dostępu do narzędzi. Wystarczy przejęta skrzynka pocztowa, współdzielone hasło albo konto byłego pracownika, aby osoba nieuprawniona uzyskała dostęp do panelu administracyjnego, integracji płatniczej, konta kurierskiego czy marketplace'u. Dlatego ochrona sklepu internetowego powinna obejmować nie tylko samo hasło właściciela, lecz cały obieg dostępów w firmie.

Lista kontrolna dostępów: role, dwuskładnikowe logowanie, offboarding

Najlepiej potraktować zarządzanie dostępami jako prostą listę do regularnego odhaczenia:

• Każdy pracownik powinien mieć imienne konto. Współdzielone loginy utrudniają ustalenie, kto wykonał konkretną operację i kto nadal zna hasło. Zasada dotyczy również skrzynki obsługującej zamówienia.

• Uprawnienia powinny odpowiadać zakresowi obowiązków. Księgowa nie potrzebuje dostępu do ustawień integracji, a osoba zajmująca się integracją nie musi widzieć pełnych danych finansowych. Im mniej zbędnych uprawnień, tym mniejszy zakres potencjalnego incydentu.

• Uwierzytelnianie dwuskładnikowe powinno działać na każdym koncie z dostępem do panelu administracyjnego. Zabezpieczenie wyłącznie konta właściciela nie wystarczy, jeżeli pozostali użytkownicy logują się tylko hasłem.

• Offboarding powinien być częścią procedury odejścia pracownika. Należy odebrać dostęp do panelu sklepu, skrzynki firmowej, operatora płatności, kont kurierskich, marketplace'ów i innych narzędzi integracyjnych.

• Aktywne konta warto przeglądać raz na kwartał. Przegląd powinien obejmować zarówno użytkowników, jak i zakres ich uprawnień.

W codziennej pracy pomocny jest również menedżer haseł, szczególnie gdy pracownicy korzystają z wielu systemów. Przy pracy zdalnej warto dodatkowo ustalić zasady korzystania z bezpiecznych sieci i firmowych urządzeń.

Przejęcie skrzynki pocztowej firmowej jako najczęstszy scenariusz wejścia

Phishing skierowany do pracownika różni się od fałszywych wiadomości wysyłanych do klientów sklepu. Celem atakującego jest przejęcie skrzynki firmowej, na przykład przez fałszywy formularz logowania albo wykorzystanie hasła, które pojawiło się wcześniej w innym wycieku.

Przejęta skrzynka może stać się bramą do kolejnych systemów. Osoba atakująca może uruchomić funkcję resetowania hasła do panelu administracyjnego, operatora płatności, konta kurierskiego lub innych usług powiązanych z adresem e-mail pracownika.

Dlatego uwierzytelnianie dwuskładnikowe powinno być aktywne również na samej skrzynce pocztowej. Bezpieczeństwo sklepu internetowego zależy w tym przypadku od zabezpieczenia punktu, przez który można odzyskać dostęp do pozostałych kont.

Klucze API do integracji: rotacja i ograniczenie zakresu

Klucz API to dane umożliwiające zewnętrznemu systemowi komunikację ze sklepem lub inną usługą. Klucze wykorzystywane przez integracje z płatnościami, kurierami czy marketplace'ami należy traktować podobnie jak hasła, ponieważ mogą dawać dostęp do określonych operacji lub danych.

Bezpieczne zarządzanie kluczami API opiera się na trzech zasadach. Po pierwsze, klucz powinien mieć tylko takie uprawnienia, których dana integracja faktycznie potrzebuje. Po drugie, po zakończeniu współpracy z wykonawcą, agencją albo pracownikiem należy unieważnić dotychczasowy klucz i wygenerować nowy. Po trzecie, kluczy nie należy przechowywać we współdzielonych arkuszach, plikach tekstowych ani na firmowym czacie.

Bezpieczeństwo sklepu internetowego w warstwie dostępów można więc uporządkować trzema prostymi regułami: każdy korzysta z własnego konta, każdy ma tylko potrzebne uprawnienia, a każdy dostęp jest odbierany natychmiast, gdy przestaje być potrzebny.

Dane osobowe klientów poza bazą sklepu: pliki robocze i eksporty

Bezpieczeństwo sklepu internetowego obejmuje też dane, które opuściły panel administracyjny: eksporty do arkuszy, załączniki mailowe i foldery współdzielone.

Panel administracyjny zwykle zapewnia własne mechanizmy ochrony, takie jak uprawnienia użytkowników, historia zmian czy szyfrowanie transmisji. W momencie wykonania eksportu danych zabezpieczenia panelu przestają jednak obejmować utworzony plik. Arkusz z listą zamówień może trafić na dysk pracownika, do skrzynki pocztowej, folderu współdzielonego albo prywatnej chmury i od tego momentu funkcjonuje niezależnie od zabezpieczeń sklepu.

Znaczenie ma więc nie tylko ochrona samej bazy, lecz również sposób pracy z kopiami danych osobowych. RODO wymaga między innymi ograniczania zakresu przetwarzanych informacji do tego, co rzeczywiście jest potrzebne do konkretnego celu. W praktyce minimalizacja danych powinna dotyczyć również każdego eksportu, pliku roboczego i zestawienia przygotowanego poza panelem administracyjnym.

Gdzie realnie wyciekają dane, których nie widać w panelu administracyjnym?

Pierwszym przykładem jest arkusz z listą klientów przygotowany do mailingu i pozostawiony we współdzielonym folderze bez odpowiednich ograniczeń dostępu. Plik może zawierać imiona, adresy e-mail i inne informacje, mimo że po zakończeniu kampanii nie jest już potrzebny.

Drugi scenariusz to eksport zamówień przekazywany do biura księgowego zwykłym mailem. Załącznik trafia wówczas do skrzynek nadawcy i odbiorcy, może zostać pobrany na kilka urządzeń i pozostać w archiwum znacznie dłużej, niż wymaga tego cel przetwarzania.

Trzecim przykładem jest plik roboczy z danymi dotyczącymi zwrotów lub reklamacji przechowywany na prywatnym laptopie pracownika bez szyfrowania dysku. Utrata urządzenia albo przejęcie konta może wtedy oznaczać również dostęp do danych klientów.

Bezpieczeństwo sklepu internetowego poza panelem warto oprzeć na zasadzie minimalizacji danych. Kurierowi potrzebny jest na przykład adres dostawy i numer zamówienia, a nie pełna historia zakupów klienta. Eksport powinien zawierać tylko niezbędne kolumny, a pliki tymczasowe warto oznaczać datą wygaśnięcia i usuwać po zakończeniu zadania.

Eksport danych nie powinien więc oznaczać automatycznego przeniesienia całej bazy poza chronione środowisko. Im mniej danych trafia do plików roboczych i im krócej są przechowywane, tym mniejszy zakres informacji pozostaje poza zabezpieczeniami panelu administracyjnego.

Co robić w pierwszej godzinie po incydencie bezpieczeństwa?

Bezpieczeństwo sklepu internetowego kończy się na prewencji, ale zarządzanie incydentem zaczyna się w pierwszej godzinie po jego wykryciu.

Nawet przy dobrze rozdzielonej odpowiedzialności między dostawcę platformy a sprzedawcę incydent bezpieczeństwa może się zdarzyć. Dlatego procedura reakcji powinna być traktowana jako element ochrony sklepu internetowego na równi z hasłami, uwierzytelnianiem dwuskładnikowym czy kontrolą uprawnień. W pierwszych kilkudziesięciu minutach najważniejsze są trzy rzeczy: zatrzymanie dalszego dostępu, ustalenie możliwego zakresu zdarzenia i zabezpieczenie informacji potrzebnych do późniejszej oceny.

Kolejność działań krok po kroku

Pierwsza godzina po wykryciu incydentu bezpieczeństwa powinna służyć przede wszystkim ograniczeniu dalszego dostępu, rozpoznaniu skali zdarzenia i zachowaniu informacji potrzebnych do późniejszej analizy. Kolejność ma znaczenie, ponieważ zbyt szybkie usuwanie śladów albo chaotyczna zmiana ustawień może utrudnić ustalenie, co dokładnie się wydarzyło.

1. Odciąć dalszy dostęp. Zmień hasła do kont, które mogły zostać przejęte, wyloguj aktywne sesje i wyłącz podejrzany klucz API albo inną integrację, jeśli mogła zostać wykorzystana podczas incydentu.

2. Ustalić zakres incydentu. Sprawdź, do jakich kont, danych i funkcji mogła uzyskać dostęp osoba nieuprawniona. Na tym etapie liczy się szybkie rozpoznanie potencjalnego zakresu, nie pełna pewność co do każdego szczegółu.

3. Zawiadomić dostawcę platformy albo hostingu. Jeżeli podejrzenie dotyczy warstwy serwerowej, infrastruktury lub działania samej platformy, zgłoszenie powinno trafić do podmiotu odpowiedzialnego za tę część systemu.

4. Zabezpieczyć dowody przed zmianami naprawczymi. Zachowaj dostępne zapisy zdarzeń, zrzuty ekranu, daty, godziny i informacje o podejrzanych logowaniach. Działania naprawcze mogą zmienić część śladów, dlatego warto je udokumentować przed dalszymi zmianami.

5. Ocenić, czy doszło do naruszenia ochrony danych osobowych. Incydent bezpieczeństwa nie zawsze oznacza naruszenie ochrony danych. Krótki przestój bez dostępu do informacji o klientach może pozostać incydentem technicznym, podczas gdy przejęcie konta z dostępem do danych klientów wymaga już odrębnej oceny.

Po wykonaniu tych czynności firma powinna mieć już podstawę do dalszych decyzji: czy wystarczy reakcja techniczna, czy konieczna jest również analiza obowiązków wynikających z RODO. Najważniejsze jest zachowanie właściwej kolejności: najpierw ograniczyć zagrożenie i zabezpieczyć informacje o zdarzeniu, a dopiero później przechodzić do pełnej analizy i działań naprawczych.

Obowiązek zgłoszenia naruszenia do UODO w 72 godziny (RODO art. 33)

Bezpieczeństwo sklepu internetowego ma również wymiar prawny. Art. 33 rozporządzenia (UE) 2016/679, czyli RODO, przewiduje obowiązek zgłoszenia naruszenia ochrony danych osobowych organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia.

W Polsce organem nadzorczym jest Urząd Ochrony Danych Osobowych, czyli UODO. Obowiązek zgłoszenia spoczywa na administratorze danych. W przypadku danych klientów sklepu administratorem jest co do zasady sprzedawca, a nie dostawca platformy. Oznacza to, że odpowiedzialność za ocenę obowiązku zgłoszenia pozostaje po stronie sprzedawcy także wtedy, gdy techniczna przyczyna incydentu leżała po stronie dostawcy platformy, hostingu albo zewnętrznej integracji.

Nie każde zdarzenie techniczne automatycznie podlega zgłoszeniu do UODO. Znaczenie ma ocena ryzyka dla praw i wolności osób, których dane dotyczą. Dlatego po opanowaniu pierwszej fazy incydentu trzeba ustalić, czy doszło do utraty poufności, integralności albo dostępności danych osobowych oraz jakie skutki takie zdarzenie może mieć dla klientów.

Dobra procedura pierwszej godziny powinna więc łączyć reakcję techniczną z oceną prawną. Najpierw ograniczasz dalszy dostęp i zabezpieczasz informacje o zdarzeniu, a następnie ustalasz, czy incydent bezpieczeństwa stał się naruszeniem ochrony danych w rozumieniu RODO.

Kto naprawdę potrzebuje zgodności PCI DSS w sklepie internetowym?

Bezpieczeństwo sklepu internetowego w obszarze płatności kartą zależy od tego, czy sklep w ogóle dotyka numeru karty, czy cały proces dzieje się u operatora płatności.

PCI DSS to standard bezpieczeństwa dotyczący przetwarzania danych kart płatniczych. Zakres obowiązków sklepu nie wynika jednak wyłącznie z tego, że umożliwia klientom płatność kartą. Kluczowe jest to, w jaki sposób została zbudowana integracja z operatorem płatności i czy numer karty trafia do infrastruktury sklepu.

Jeżeli klient zostaje przekierowany na stronę operatora płatności i tam wpisuje dane karty, sklep nie widzi numeru karty ani nie przechowuje go w swoim systemie. Podobnie działa osadzony formularz operatora, jeżeli dane karty są przekazywane bezpośrednio do jego infrastruktury. W takim modelu główna odpowiedzialność za obsługę danych kart pozostaje po stronie operatora płatności, a zakres obowiązków sklepu jest znacznie mniejszy.

Inaczej wygląda sytuacja, gdy dane karty trafiają bezpośrednio do systemu sklepu albo są przez niego przechowywane. Taki model występuje rzadziej w małych i średnich sklepach, ale może pojawić się przy niestandardowych integracjach. Wtedy zakres odpowiedzialności związanej z PCI DSS rośnie, ponieważ właściciel sklepu uczestniczy bezpośrednio w przetwarzaniu danych kart.

Znaczenie ma również tokenizacja. Polega ona na zastąpieniu danych karty specjalnym tokenem, który może być później wykorzystany do obsługi płatności bez ponownego przechowywania pełnego numeru karty przez sklep. Sam fakt użycia tokenizacji nie zwalnia jednak z potrzeby sprawdzenia, gdzie i w jaki sposób dane karty są przetwarzane.

Bezpieczeństwo sklepu internetowego w obszarze PCI DSS warto więc oceniać przez model integracji, a nie przez samą nazwę standardu. W dokumentacji operatora płatności należy sprawdzić, czy płatność odbywa się przez przekierowanie, formularz operatora osadzony w sklepie czy bezpośrednie przekazywanie danych karty.

Odpowiedź na pytanie „kto dotyka numeru karty?” najprościej pokazuje, po której stronie znajduje się większa część obowiązków związanych z PCI DSS.

O co zapytać dostawcę platformy lub hostingu, zanim uznasz słowo „certyfikowany" za dowód?

Bezpieczeństwo sklepu internetowego trudno ocenić po samej nazwie normy, dopiero numer certyfikatu i nazwa jednostki certyfikującej są sprawdzalnym dowodem.

Sformułowania takie jak „zgodność z PCI DSS”, „szyfrowanie AES-256” czy „certyfikowany hosting” brzmią konkretnie, ale bez dodatkowych informacji trudno ocenić ich znaczenie. Sama deklaracja nie pokazuje jeszcze, kto przeprowadził weryfikację, kiedy miała miejsce ani czy potwierdzenie nadal jest ważne.

Sprawdzalny dowód powinien zawierać co najmniej trzy elementy: numer certyfikatu, nazwę jednostki certyfikującej oraz datę ważności dokumentu. Dzięki temu można zweryfikować, czy dana deklaracja odnosi się do rzeczywistego i aktualnego potwierdzenia, a nie tylko do ogólnego opisu stosowanych zabezpieczeń.

Przed wyborem platformy lub hostingu warto zadać dostawcy kilka konkretnych pytań:

• Jaki jest numer certyfikatu i kto go wydał? Nazwa standardu bez numeru dokumentu i wskazania jednostki certyfikującej nie daje możliwości samodzielnej weryfikacji.

• Kiedy przeprowadzono ostatni audyt bezpieczeństwa i kiedy planowany jest kolejny? Data audytu pokazuje, czy ocena odnosi się do aktualnego środowiska i procedur.

• Czy deklarowana dostępność jest zapisana w umowie? Warto odróżnić SLA, czyli zobowiązanie umowne, od historycznego wyniku dostępności osiągniętego w konkretnym okresie.

• Czy dostawca publikuje historię awarii? Publiczna strona statusu pozwala sprawdzić, czy i jak często występowały incydenty oraz jak długo trwało przywracanie działania usług.

Bezpieczeństwo sklepu internetowego warto oceniać więc na podstawie danych, które można zweryfikować, a nie samych określeń marketingowych. Numer certyfikatu, jednostka certyfikująca, data ważności, wynik audytu bezpieczeństwa i publiczna strona statusu dają znacznie więcej informacji niż sama deklaracja zgodności z normą.

Im bardziej konkretne są odpowiedzi dostawcy, tym łatwiej porównać oferty na podstawie faktycznych zobowiązań i potwierdzonych zabezpieczeń, a nie ogólnych zapewnień.