Pracownik odszedł. Prowadzimy sklep — i nie umieliśmy udowodnić, że dostęp też zniknął.

Ustalenie, które przerwało przegląd

Tworzymy i utrzymujemy sklepy PrestaShop dla innych firm. Sklepy nie należą do nas — prowadzimy je w imieniu klientów, co oznacza, że to my odpowiadamy za bezpieczeństwo ich Back Office. Na tym polega ta praca. I właśnie dlatego historia, którą zaraz opowiem, wylądowała u nas, a nie u kogoś innego.

Jakiś czas temu z jednej z firm, których sklepami się opiekujemy, odszedł pracownik. Nic dramatycznego, w samym odejściu nie było historii wartej opowiadania. Ale ta osoba miała dostępy porozrzucane po całym środowisku, które obsługujemy, którą prowadzimy dla jej pracodawcy — w tym konto w PrestaShop Back Office — a jej odejście uruchomiło coś, co powinno być rutynowym przeglądem dostępów do sklepu, poczty i hostingu. Jako opiekunowie tego sklepu to my mieliśmy ten przegląd przeprowadzić.

Znaleźliśmy zwykły bałagan, jakiego można się spodziewać po firmie, która rosła szybciej niż jej procesy. Ale jedno ustalenie zatrzymało wszystko w miejscu — i nie był to login do Back Office, o który wszyscy zwykle martwią się najpierw. To była skrzynka pocztowa:

Skrzynka byłego pracownika — jego osobista skrzynka odbiorcza oraz współdzielone skrzynki funkcyjne, z których korzystał — nadal była aktywna. Hasło nigdy nie zostało zmienione. I ktoś logował się do niej każdego dnia.

Najbardziej niepokojące nie jest samo ustalenie, tylko to, co stało za nim: ponieważ cały zespół klienta pracował z jednego wspólnego łącza biurowego, a część danych logowania była współdzielona między ludźmi, nie dało się ustalić, czy te codzienne logowania wykonywała osoba, która już odeszła, czy obecny pracownik wykonujący dawną pracę z dawnej skrzynki. Oba wyjaśnienia idealnie pasowały do logów. Wpis w logu mówi, że danych logowania użyto z danego adresu — a adres IP identyfikuje połączenie, nie człowieka. Kilka tygodni po tym, jak ktoś przestał pracować w firmie, my — agencja odpowiedzialna za bezpieczeństwo tego sklepu — nie potrafiliśmy udowodnić, że jego dostęp skończył się razem z nim.

O tym jest ten wpis. Nie o włamaniu — nie znaleźliśmy żadnych jego śladów, a precyzyjnie mówiąc o tym, co faktycznie pokazały logi: nadal aktywne dane logowania do skrzynki byłego pracownika były używane; kto je miał, to dokładnie ta rzecz, której nikt nie potrafił ustalić. To coś cichszego i, moim zdaniem, częstszego niż włamanie: sklep, którego opiekunowie nie potrafili odpowiedzieć na pytanie „kto w tej chwili może wejść gdziekolwiek?” — a kiedy próbowaliśmy odtworzyć odpowiedź z logów, okazało się, że logi też nie potrafią jej dać. I jeśli to prawda dla skrzynki pocztowej, ta sama architektura zostawia Cię równie ślepym przy Back Office — tam celuje dalsza część tego wpisu.

Jeśli prowadzisz — albo prowadzisz dla kogoś innego — sklep PrestaShop, w którym więcej niż jedna osoba dotyka Back Office, ten wpis jest checklistą, którą chciałbym mieć pod ręką, zanim stała się potrzebna.

Dlaczego forensyka zawiodła — i dlaczego Twoja też by zawiodła

Gdy pojawiło się ustalenie „nadal aktywne, nadal logowane”, oczywistym następnym krokiem była forensyka: wyciągnąć logi, przypisać każde logowanie, potwierdzić, że nie stało się nic niewłaściwego. Zrobiliśmy tę pracę. W większości się nie udała, a sposoby, w jakie się nie udała, warto nazwać wprost, bo nie są specyficzne dla tego klienta — to domyślny stan typowego stacku hostingowego małej firmy i ten sam kształt widzimy w sklepach, którymi zarządzamy.

Logi nie sięgały wystarczająco daleko wstecz. Serwer pocztowy przechowywał szczegółowe logi logowań tylko przez mniej więcej cztery tygodnie. Wszystko starsze po prostu zniknęło. Jeśli pytanie brzmi: „czy to konto było nadużywane od czasu odejścia tej osoby kilka miesięcy temu?”, okno czterech tygodni nie potrafi na nie odpowiedzieć — i żadna wiedza techniczna tego nie zmieni.

Webmail ukrywał prawdziwe źródło. Logowania przez hostowany klient webmail były proxyowane przez sam serwer, więc log poczty zapisywał jako źródło sesji lokalny adres serwera — nie faktyczne IP osoby. Cała klasa dostępu była anonimowa z samej architektury.

Współdzielone IP uniemożliwiły przypisanie logowań. Wszyscy w biurze klienta wychodzili do internetu przez jedno łącze. Logowanie z biurowego IP mogło należeć do dowolnej z kilkunastu osób — potencjalnie także do kogoś, kto już tam nie pracował, ale nadal miał hasło i, powiedzmy, powód, żeby wpaść, albo do urządzenia, które wciąż automatycznie się synchronizowało. NAT, VPNy i współdzielone sieci dają ten sam efekt: IP mówi, skąd przyszło połączenie, nigdy kto za nim stał.

Współdzielone dane logowania zniszczyły ją drugi raz. Kilka skrzynek funkcyjnych i sam dostęp do hostingu używały haseł znanych wielu osobom. Gdy pięć osób zna hasło, wpis w logu dowodzi, że użyto hasła — nigdy kto go użył.

Wcześniej istniejący dostęp był niewidzialny. Najważniejsze ograniczenie ze wszystkich: logi zapisują zdarzenia, nie wiedzę. Jeśli ktoś skopiował hasło, wyeksportował skrzynkę albo zapisał klucz API w czasie, gdy legalnie miał dostęp, żaden log nigdy tego nie pokaże. Przegląd mógł uczciwie stwierdzić „nie znaleźliśmy dowodów nadużycia” — i natychmiast musieliśmy dodać zastrzeżenie, które zna każdy od bezpieczeństwa: brak dowodów nie jest dowodem braku.

Razem daje to właściwą lekcję i tezę całego wpisu:

Nie da się zbadać tego, czemu nigdy nie zapobiegłeś. W chwili, gdy robisz forensykę, przegrałeś już tę wersję historii, w której dostajesz czystą odpowiedź. Prewencja jest nie tylko tańsza od forensyki — w typowym stacku sklepu jest jedyną z tych dwóch rzeczy, która naprawdę działa.

U nas też nie było idealnie

Napisałbym nieuczciwy tekst, gdybym przedstawił to jako „klient miał słabą higienę, a my, pilna agencja, kręciliśmy głową z boku”. Ten sam przegląd objął dostęp, który zawierał nasze własne konta agencyjne w tym sklepie — i znalazł dwie rzeczy, z których nie jestem dumny.

Jedno z moich własnych haseł nie było zmieniane od mniej więcej pięciu lat. Było długie, było unikalne, nigdy — o ile jakikolwiek log mógł to pokazać — nie zostało nadużyte. Nie o to chodzi. Pięć lat to pięć lat byłych współpracowników, starych urządzeń, zapomnianych profili przeglądarek i wycieków u zewnętrznych usługodawców, które narastają wokół jednego statycznego sekretu. Jako ludzie, którym płaci się za opiekę nad tym sklepem, wiedzieliśmy lepiej. A jednak tak było.

Mój „VPN” pogarszał sprawę, zamiast ją poprawiać. Przez lata korzystałem z darmowej usługi VPN, która rotuje serwery wyjściowe po przypadkowych centrach danych. Z punktu widzenia bezpieczeństwa wnosiła niewiele. Z punktu widzenia forensyki była katastrofą w odwrotną stronę: moje własne, legalne logowania do sklepu pojawiały się w logach jako serie wejść z nieznanych adresów IP centrów danych w kilku krajach — dokładny odcisk palca przejęcia konta. Podczas przeglądu spaliliśmy realne godziny, udowadniając, że najgroźniej wyglądający wzorzec w całej historii logów to byłem ja, administrator tego sklepu, przeglądający go przez ruletkę węzłów wyjściowych darmowego VPN. Narzędzie przyjęte przeze mnie w imię bezpieczeństwa wygenerowało szum, który prawie zakopał sygnał.

Opisuję to, bo tak naprawdę wygląda ten problem, i dlatego, że trzymanie Back Office klientów oznacza trzymanie siebie według tej samej listy. Higiena danych logowania nie zawodzi dlatego, że ludzie są niedbali albo głupi. Zawodzi dlatego, że nic w codziennych operacjach nie wymusza zajęcia się tematem. Sklep działa. Poczta dochodzi. Hasło z 2021 nadal loguje. Każdy dzień, w którym nic się nie dzieje, jest dniem, w którym dług narasta po cichu — aż odejście, audyt albo incydent każe Ci spojrzeć.

Cykl życia danych logowania ma dwie połowy. Wszyscy robią jedną.

Gdy ktoś dołącza — pracownik, freelancer, agencja, partner biznesowy — dostęp powstaje w kilka godzin. Musi powstać, inaczej ta osoba nie może pracować. Jest zmotywowany człowiek (nowa osoba), zmotywowany przełożony (który potrzebuje jej produktywnej) i natychmiastowy, widoczny tryb awarii, jeśli to się nie wydarzy.

Gdy relacja się kończy, odebranie dostępu nie ma żadnej z tych cech. Nikt nie jest blokowany przez to, że konto osoby, która odeszła, nadal istnieje. Nie ma komunikatu błędu, skargi, zgłoszenia. Domyślnym skutkiem nierobienia niczego jest to, że wszystko dalej działa — i właśnie to jest problem. Onboarding wymusza się sam; offboarding dzieje się tylko wtedy, gdy zrobisz z niego celowy, spisany proces. I dotyczy to każdego rodzaju odejścia tak samo: pracownika, który składa wypowiedzenie, kontraktora, którego projekt się kończy, agencji, od której klient odchodzi. Jest tu druga pułapka, która uderzyła nas bezpośrednio: gdy sklep prowadzi agencja, ale obsługują go ludzie klienta, offboarding może wpaść w szczelinę między nimi — klient zakłada, że odchodzący pracownik to „problem naszego dostawcy”, agencja nigdy nie słyszy, że ta osoba odeszła. Dostęp nie wie, czyim problemem miał być. Ktoś musi być za niego wprost odpowiedzialny, na piśmie, po obu stronach.

A w e-commerce „dostęp” nigdy nie jest jednym kontem. To rozlewisko: PrestaShop Back Office, skrzynki pocztowe, współdzielone skrzynki funkcyjne, SSH i FTP, panel hostingu, dostęp do bazy danych, klucze webservice API, panel operatora płatności, platforma wysyłkowa, analytics, marketplace'y, menedżer haseł, współdzielone dokumenty. Pominiesz jedno z nich i odejście nie jest domknięte — po prostu przestałeś patrzeć.

Checklista offboardingowa, której większość sklepów nie ma

To jest rzecz do zabrania z tego wpisu. Wydrukuj ją, dopasuj i przypnij do swojego procesu odejścia — niezależnie od tego, czy jesteś właścicielem sklepu, czy agencją prowadzącą sklep. Cel jest taki, żeby w ostatnim dniu czyjejś pracy wykonywać listę, a nie próbować pod presją czasu przypomnieć sobie cały stack.

Dwie uwagi procesowe są równie ważne jak sama lista: wykonuje się ją ostatniego dnia, nie „w ciągu kilku tygodni” — przegląd, który doprowadził do tego wpisu, znalazł lukę właśnie dlatego, że odebranie dostępu potraktowano jako zadanie „kiedyś”. I ktoś jest jej właścicielem z imienia i nazwiska — a gdy sklep prowadzi agencja, ten „ktoś” oraz przekazanie między klientem i agencją muszą być ustalone, zanim ktokolwiek odejdzie, nie improwizowane po fakcie. Checklista bez właściciela jest sugestią.

Jedna świadoma decyzja z wiersza 1 jest warta powtórzenia: wyłącz, nie usuwaj. Wyłączone konto nie może się zalogować, ale zachowuje swoją tożsamość i istniejące odwołania — więc rekordy, które rzeczywiście o nim wspominają, nadal prowadzą do znanej osoby, zamiast wisieć w próżni. Usunięcie wydaje się schludniejsze i osieroca dokładnie te powiązania, które później mogą być potrzebne, żeby zrozumieć, co się stało.

Utwardzenie: żeby wyciekłe hasło nigdy nie wystarczyło

Offboarding to kontrola szkód w systemie, w którym hasło równa się dostęp. Głębsza poprawka polega na tym, żeby Back Office przetrwał nawet wtedy, gdy dane logowania wyciekną — bo prędzej czy później wyciekną. Oto sześć zmian, które dziś wdrażamy w każdym sklepie, który prowadzimy, w kolejności, w jakiej sam bym je robił:

1. Zlikwiduj współdzielone konta — jedna osoba, jedno konto. To fundament wszystkiego innego. System pracowników PrestaShop (Zaawansowane → Zespół) istnieje dokładnie po to, żeby nigdy nie współdzielić loginu: daj każdej osobie własne konto z profilem odpowiadającym jej realnej pracy, a SuperAdmin zostaw jednej lub dwóm osobom, które naprawdę go potrzebują. Zysk jest dokładnie tym, czego ten sklep nie miał, gdy przejęliśmy jego historię: kiedy każde konto mapuje się na jednego człowieka, możesz przypisywać działania i możesz odebrać dostęp jednej osobie bez resetowania wszystkich.

2. Odbieraj dostęp całkowicie, nie tylko oczywiste hasło. O to chodzi w checkliście powyżej: odejście oznacza wykonanie wszystkich dwunastu wierszy, a nie wyłączenie loginu do Back Office i uznanie sprawy za zamkniętą. Ustalenie, które otworzyło ten wpis, nie dotyczyło konta w Back Office — dotyczyło skrzynki pocztowej. Dostęp, o którym zapomnisz, zawsze jest tym, który ma znaczenie.

3. Postaw Back Office za ścianą IP — na krawędzi serwera, nie tylko w aplikacji. Zmiana nazwy katalogu admina to zaciemnienie, nie kontrola; jedna ujawniona URL ją unieważnia. To, co naprawdę zmienia rachunek, to allowlista: Back Office odpowiada tylko znanym adresom wyjściowym biura i VPN, i nikomu innemu w internecie. Uczciwa odpowiedź inżynierska brzmi: najlepiej egzekwować to całkowicie przed PrestaShop — regułą na poziomie serwera (nginx allow/deny, Apache Require ip), polityką Cloudflare Access albo regułą WAF na ścieżce admina, albo VPNem, który jest jedyną trasą sieciową do Back Office. Wymuszone tam blokowanie dzieje się, zanim uruchomi się choć jedna linia PHP, więc nawet podatność na poziomie aplikacji nie przegada się przez tę blokadę. Allowlista w aplikacji jest wtedy wartościową drugą warstwą — defense in depth, a często jedyną dostępną na restrykcyjnym hostingu współdzielonym, gdzie nie kontrolujemy krawędzi. Nasz moduł mprsecurityrevolution daje tę warstwę jako firewall IP — reguły blokowania, reguły whitelist, blokowanie na poziomie krajów — i stosuje to samo myślenie allowlistowe bezpośrednio do logowań pracowników przez trusted-admin-IP gate w Back Office. Efekt w każdym wariancie jest ten sam: wyciekłe albo niezrotowane hasło admina — dokładnie ta awaria z tej historii — nie wystarcza już samo w sobie. Atakujący potrzebuje danych logowania i pozycji w Twojej sieci.

4. Dodaj drugi składnik do logowań adminów — PrestaShop nie zrobi tego za Ciebie. Oto fakt, który zaskakuje wielu merchantów: PrestaShop core — zarówno 1.7, 8, jak i 9 — nie dostarcza natywnego uwierzytelniania dwuskładnikowego dla Back Office. PrestaShop 8 i 9 wzmocniły dostęp administracyjny na inne sposoby (konfigurowalna polityka haseł i ulepszone zarządzanie sesjami), ale drugi składnik nigdy nie trafił do core. Jeśli chcesz 2FA dla logowań pracowników, musi pochodzić z modułu albo z warstwy przed sklepem (portal SSO albo coś w rodzaju Cloudflare Access). Warto je mieć: aplikacja TOTP na telefonie każdego admina kosztuje sekundy przy logowaniu i usuwa całą kategorię „ktoś, gdzieś, nadal zna stare hasło” jako wystarczający sposób wejścia. mprsecurityrevolution dodaje uwierzytelnianie dwuskładnikowe TOTP do logowań pracowników PrestaShop, więc Back Office dostaje je bez własnej infrastruktury. Trzeba jednak jasno widzieć, co daje 2FA: dramatycznie zmniejsza ryzyko password-only — nie przeprowadza za nikogo offboardingu. Były pracownik, którego konto nadal jest aktywne i którego telefon nadal jest zapisany, przechodzi przez 2FA bez przeszkód. To uzupełnia checklistę; nie może jej zastąpić.

5. Rotuj zgodnie z harmonogramem i przy każdym odejściu — i używaj prawdziwego VPN. Rotacja nie jest paranoją; chodzi o ograniczenie wieku każdego sekretu, który może nadal mieć były współpracownik, stary laptop albo naruszona usługa zewnętrzna. Rotuj krytyczne dane logowania według kalendarza (co najmniej panel hostingu, baza danych, panele płatności) i rotuj wszystko, czego dotknęła osoba odchodząca w jej ostatnim dniu — to wiersze 3, 5, 6 i 9 checklisty. A jeśli Ty albo zespół klienta łączycie się gdziekolwiek przez VPN, używajcie porządnego rozwiązania ze stałymi, znanymi adresami wyjściowymi — self-hosted WireGuard albo renomowanego dostawcy biznesowego. Mój darmowy VPN z rotującymi wyjściami nie tylko dawał znikome bezpieczeństwo; aktywnie zatruł logi, których później potrzebowałem. VPN ze stabilnym IP wyjściowym robi odwrotnie: sprawia, że legalny dostęp jest bardziej przypisywalny i daje allowliście IP czysty adres, któremu może ufać.

6. Loguj działania adminów — bo możesz zbadać tylko to, co zalogowałeś. Wcześniejsze ślepe uliczki forensyczne nie były pechem; były domyślną postawą loggingu standardowego stacku. I warto jasno powiedzieć jedno zastrzeżenie: wbudowane logowanie PrestaShop nie jest pełnym audit trail. Strona logów w core (Zaawansowane → Logi) zapisuje błędy i część zdarzeń, ale wiele działań istotnych dla bezpieczeństwa — logowania i ich źródła, zmiany uprawnień, edycje konfiguracji — nie zostawia trwałego, przeglądalnego śladu, a retencja jest tym, co akurat zostawi Twoja rutyna utrzymaniowa. Zdecyduj teraz, na jakie pytania musiałbyś odpowiedzieć po incydencie — kto zalogował się do Back Office i skąd, kto utworzył lub wyłączył pracownika, kto zmienił uprawnienia, kto dotykał konfiguracji istotnej dla bezpieczeństwa — i upewnij się, że coś trwale zapisuje te odpowiedzi dzisiaj, z retencją dłuższą niż cztery tygodnie. Dlatego activity i audit logging jest jednym z filarów ochrony admina w mprsecurityrevolution, obok zarządzania sesjami (jedno wspólne miejsce, w którym widać każdą aktywną sesję Back Office i można zakończyć te, które nie powinny istnieć — problem „nadal zalogowany ze starego urządzenia” — w PS 1.7, 8 i 9; starsze wersje w ogóle nie mają takiej kontroli, a w PS 9 działa to obok własnego zarządzania sesjami w core jako jedna konsola do zauważania i zabijania sesji), monitorowania integralności plików i kontroli bezpieczeństwa e-mail. Kiedy w końcu padnie niewygodne pytanie — a jeśli prowadzisz sklepy dla innych, ono padnie — „logujemy, kto co zrobił w Back Office” jest różnicą między odpowiedzią a wzruszeniem ramion.

Od czego zacząć, jeśli ten wpis Cię zaniepokoił

Zacznij od prawdy, nie od narzędzi. Nasz darmowy, open-source'owy skaner mprsecurityscan audytuje sklep od środka — wystawione pliki, brakujące utwardzenia, ryzykowne ustawienia domyślne — i daje ustalenia wraz z ręcznymi krokami naprawy. Jest tylko do wykrywania i jest darmowy, bo pierwszy krok to wiedzieć, gdzie naprawdę jesteś. Potem przejdź checklistę powyżej wobec każdego, kto kiedykolwiek miał dostęp — każdego obecnego i byłego pracownika, kontraktora, agencji i partnera — i pozwól wynikom powiedzieć, którego z sześciu kroków utwardzenia potrzebujesz najpierw. Gdy chcesz, żeby kontrole administracyjne były egzekwowane, a nie pamiętane, do tego służy mprsecurityrevolution: firewall IP, zarządzanie sesjami, activity i audit logging, monitoring integralności plików oraz bezpieczeństwo e-mail, które ma już dziś, plus uwierzytelnianie dwuskładnikowe i trusted-admin-IP login gate dla Back Office. Żaden moduł nie sprawia, że offboarding dzieje się automatycznie albo że ryzyko insidera znika — nic tego nie robi — ale przenosi krytyczne kontrole z „ktoś pamiętał” do „system egzekwuje”. To standard, którego trzymamy się w każdym sklepie, który prowadzimy, i którego chcielibyśmy dla własnego.

Ciche zakończenie

Przegląd, od którego wszystko się zaczęło, zakończył się bez dramatu: konto byłego pracownika zostało wyłączone — wyłączone, nie usunięte, żeby jego tożsamość i odwołania pozostały nienaruszone zamiast osierocone — hasła zostały zmienione, a checklista teraz istnieje, ma właściciela i jest wpisana w sposób, w jaki przekazujemy dostęp z tym klientem.

Nie znaleziono włamania. Ale „nie znaleziono włamania” i „włamania nie było” to dwa różne zdania, a luka między nimi jest trwała — ten sklep po prostu nigdy nie będzie wiedział tego na pewno, bo logi, które mogłyby to powiedzieć, nigdy nie były przechowywane, a dostęp, który powinien skończyć się razem z zatrudnieniem, po cichu przeżył je dłużej.

Ta trwała, nierozwiązywalna niewiedza jest prawdziwym kosztem źle obsłużonego cyklu życia danych logowania. Nie zapłacisz go w dniu, w którym ktoś odchodzi. Zapłacisz go miesiące później, podczas przeglądu albo incydentu, gdy każde pytanie wróci jako „nie da się ustalić”. A jeśli to Tobie powierzono cudzy sklep, płaci za to biznes klienta — dlatego traktujemy to jako naszą odpowiedzialność, żeby zrobić to dobrze.

Najlepsza reakcja na incydent to logowanie, które nigdy się nie wydarzyło. Odbieraj dostęp tak, jakby to naprawdę miało znaczenie.