Bezpieczeństwo PrestaShop: zabezpieczenia, dostęp i odtwarzanie

Co byśmy zrobili

Najpierw ustalilibyśmy, czy zapobiegasz problemowi, czy reagujesz na dowody naruszenia. Przy rutynowym wzmacnianiu zabezpieczeń przed wyborem narzędzi zinwentaryzuj to, czego już używasz: hosting, PrestaShop i PHP, moduły, integracje, modyfikacje motywu, przechowywane dane, rynki i osoby potrzebujące dostępu. Integracja magazynowa, podróżujący zespół wsparcia i osadzony formularz płatności mają różne wymagania. Zachowaj działające zabezpieczenia i zajmij się lukami, które potrafisz wykazać.

Jeśli sklep nie może korzystać z utrzymywanego oprogramowania, porównaj aktualizację obecnej instalacji z czystą instalacją docelową i kontrolowaną migracją danych. Właściwa ścieżka zależy od własnego kodu, zamienników modułów, motywu, integracji i jakości danych. Wzmacnianie niewspieranego sklepu ogranicza konkretne zagrożenia na czas tych prac; nie przywraca utrzymania przez producenta. Jeśli podejrzewasz włamanie, zabezpiecz dowody i wykonaj kroki z sekcji reagowania na incydenty, zanim uznasz sklep za bezpieczną kopię wyjściową.

Do planowanych zmian używaj chronionej kopii testowej, przećwicz odpowiednie ścieżki biznesowe, zapisz sposób cofnięcia zmiany i uzgodnij przełączenie produkcji z osobą obserwującą wynik. Migracja platformy lub bazy wymaga też planu dla zamówień i innych zapisów napływających podczas przygotowania kopii.

Jeśli potrzebujesz niezależnej oceny, PrestaShop Security Audit & Hardening Report bada uzgodniony zakres narażenia i dostarcza plan z priorytetami; wdrożenie i usuwanie skutków incydentu mają osobny zakres.

Zacznij od zapobiegania, wykrywania i odtwarzania

Chroń sklep na kilku poziomach: wspierane oprogramowanie, indywidualne loginy, ograniczone uprawnienia, reguły serwera, filtrowanie ruchu, monitoring i kopie umożliwiające odtworzenie. HTTPS chroni dane w przesyle. Kopia zapasowa pomaga w odtworzeniu. Żadne z nich nie zastępuje instalowania poprawek.

Zagrożenia obejmują SQL injection w rdzeniu lub modułach, kradzież danych logowania pracowników, podatne mechanizmy przesyłania plików, złośliwe pakiety oraz publicznie dostępne kopie lub konfigurację. Proces zamówienia może nadal działać, gdy wstrzyknięty JavaScript kradnie dane. Mały sklep także potrzebuje tych zabezpieczeń.

1. Zapisz dokładne wersje PrestaShop, PHP, bazy danych, motywu i modułów.
2. Wykonaj kopię plików i bazy danych, a następnie potwierdź możliwość odtworzenia na odizolowanej kopii.
3. Wdrażaj poprawki bezpieczeństwa na środowisku testowym i sprawdzaj składanie zamówień przed produkcją.
4. Zapewnij każdemu pracownikowi unikalne konto, silne hasło i drugi składnik.
5. Sprawdź ścieżki z prawem zapisu, publiczne endpointy i alerty monitoringu.

Przypisz osobę odpowiedzialną i datę przeglądu do każdego zabezpieczenia. Sprawdzaj dostęp po zmianach personelu i regularnie powtarzaj szerszy przegląd. Chroń środowisko testowe uwierzytelnianiem oraz wyłącz w nim prawdziwe płatności, e-maile do klientów i integracje produkcyjne.

Korzystaj ze wspieranych wersji PrestaShop i PHP

Zgodność i utrzymanie bezpieczeństwa to odrębne kwestie. PrestaShop od 8.0 do 8.2 obsługuje PHP tylko do 8.1. PrestaShop 9.0 obsługuje PHP od 8.1 do 8.4; 9.1 od 8.1 do 8.5. Wydanie 9.2 także obsługuje PHP od 8.1 do 8.5. Przed zmianą PHP dopasuj dokładne wydanie i każdy moduł. Zobacz tabelę zgodności i wymagania 9.2.

Według stanu na 26 października 2026 r. PHP 8.1 jest już po zakończeniu cyklu wsparcia. Wsparcie bezpieczeństwa projektu zakończyło się 31 grudnia 2025 r. Wsparcie PHP 7.4 zakończyło się 28 listopada 2022 r. Sprawdzaj cykl życia PHP oraz zgodność platformy. Zaplanuj aktualizację platformy, jeśli sklep nie może korzystać z utrzymywanego środowiska; każdą umowę przedłużonego wsparcia zweryfikuj bezpośrednio.

Regularne utrzymanie PrestaShop 1.7 przez projekt zakończyło się wraz z wydaniem 9.0. Wyjątkowa późniejsza poprawka awaryjna nie oznacza ciągłego utrzymania gałęzi. PrestaShop 1.6 także pozostaje poza oficjalnym utrzymaniem. Śledź politykę utrzymania i zaplanuj migrację.

Aktualizuj także system operacyjny, bazę danych, serwer WWW i moduły. Prowadź inwentarz modułów i subskrybuj komunikaty dostawców oraz ostrzeżenia bezpieczeństwa Friends of Presta. Sam numer wersji nie dowodzi podatności na konkretny exploit.

Skorzystaj z listy kontrolnej migracji, aby zaplanować zmiany między wersjami PHP i PrestaShop.

Przećwicz zmianę i powrót do poprzedniego stanu

Na przykład zaostrzenie reguł przesyłania plików może chronić załączniki klientów, a jednocześnie zepsuć moduł przetwarzający je przez stary endpoint. Najpierw zapisz rzeczywiste ścieżki używane przez moduł. Osobno przetestuj normalne przesyłanie i blokowane nazwy plików wykonywalnych, aby działający obraz produktu nie ukrył zepsutej obsługi załączników.

1. Zachowaj obecną konfigurację, zmieniane ścieżki, dane dostępowe integracji i spójny punkt odtworzenia plików oraz bazy. Zapisz oczekiwane zachowanie przed zmianami.
2. Zbuduj chronioną kopię z tymi samymi odpowiednimi handlerami serwera, regułami proxy, modułami i motywem. Ogranicz dostęp do skopiowanych danych klientów i zastąp produkcyjnych odbiorców usługami testowymi lub kontrolowanymi atrapami.
3. Wprowadzaj jedną logiczną zmianę naraz. Jednoczesna zmiana PHP, wymiana modułu i zmiana zapory utrudniają ustalenie przyczyny błędu.
4. Testuj działania dozwolone i zabronione: logowanie pracownika i odzyskiwanie dostępu, próby wyjścia poza rolę, przeglądanie katalogu, przesyłanie plików, finalizację zakupów, powiadomienia płatnicze, zwroty, zadania harmonogramu i synchronizację partnerów, zależnie od zastosowania.
5. Przećwicz cofnięcie. Przywrócenie pliku konfiguracji, cofnięcie wdrożonego kodu i odtworzenie bazy mają różne skutki; ustal, czego wymaga zmiana i kto może to wykonać.
6. Uzgodnij okno przełączenia, kontrole decyzji o wdrożeniu i warunek cofnięcia. Przy przenoszeniu danych między instalacjami określ wstrzymanie lub uzgodnienie zapisów oraz obsługę przychodzących powiadomień płatniczych.
7. Po przełączeniu sprawdź rzeczywistą obsługę zamówień i kanał alertów. Zachowaj wyniki testów, zmienione ustawienia i instrukcje utrzymania do następnego wdrożenia.

Odtworzenie bazy może usunąć zamówienia złożone po punkcie przywracania. Przy cofnięciu migracji uzgodnij sposób rozliczenia tych zamówień i płatności dostawców przed powrotem. Chroń poprzednie środowisko przez cały okres zachowania do odtworzenia.

Dla starszego sklepu potrzebującego utrzymywanej platformy PrestaShop Upgrade Service: Any Version to PrestaShop 9 ocenia obecną wersję, PHP, hosting, motyw i moduły przed pisemną wyceną, a potem pracuje na kopii testowej przed przełączeniem produkcji.

Znajdź lub zmień URL panelu administracyjnego

Panel administracyjny znajduje się w fizycznym katalogu w katalogu głównym sklepu. Jeśli sklep jest zainstalowany w /shop/, uwzględnij tę ścieżkę bazową przed katalogiem administracyjnym. Znajdź go przez SFTP, menedżer plików hostingu lub SSH.

Szukaj katalogu głównego sklepu zawierającego classes/, modules/ i themes/. Nazwy potencjalnych katalogów często zaczynają się od admin, ale katalog po zmianie nazwy może nazywać się inaczej. Sprawdź w jego index.php kod uruchomienia panelu i definicję _PS_ADMIN_DIR_. Podkatalog controllers/ nie jest w nim wymagany.

Standardowy plik app/config/parameters.php nie przechowuje nazwy folderu administracyjnego. Zachowaj obecną losową nazwę w tajemnicy albo zmień nazwę rzeczywistego folderu w uzgodnionym oknie dostępu. Nie trzeba zmieniać żadnego standardowego ustawienia bazy danych, aby do niej pasowało.

1. Zachowaj działający dostęp SFTP lub do hostingu.
2. Poproś współpracowników o wylogowanie, a następnie zmień nazwę katalogu.
3. Zaktualizuj własne odwołania proxy, zapory, zadań harmonogramu lub modułów do starej ścieżki.
4. Otwórz nowy URL HTTPS i przetestuj logowanie.
5. Zaktualizuj zakładki i wpisy menedżera haseł. Sprawdź, czy stara ścieżka nie otwiera już panelu.

Dowiązanie symboliczne ze starej nazwy utrzymuje dostępność tego punktu wejścia. Prywatna ścieżka ogranicza przypadkowe skanowanie, lecz nadal wymaga silnego uwierzytelniania i ograniczeń dostępu.

Hasła, uwierzytelnianie dwuskładnikowe i sesje pracowników

W nowszych wersjach otwórz Parametry zaawansowane > Zespół > Pracownicy, Profile i Uprawnienia. W PrestaShop 1.6 te strony znajdują się w Administracja. Daj każdej osobie imienne konto pracownika. Unikaj udostępniania loginu właściciela.

Używaj długich, unikalnych haseł generowanych przez menedżer haseł. Losowe hasło o długości co najmniej 16 znaków jest praktyczną zasadą. Niezwłocznie zmieniaj przejęte lub powtórnie używane hasła. Rutynowe wymuszanie zmiany nie zastępuje długości i unikalności. Nowszy rdzeń używa usługi Crypto Hashing z bcrypt i weryfikacją starszych skrótów; nie resetuj haseł surowym MD5.

TOTP w panelu wymaga zgodnego modułu lub zewnętrznej warstwy tożsamości i dostępu. Rdzeń nie zapewnia uniwersalnego przełącznika TOTP opisywanego w wielu starszych poradnikach. Zewnętrzny dostawca tożsamości może także wymuszać indywidualne MFA. TOTP ogranicza ataki oparte tylko na haśle, ale atakujący może przekazać bieżący kod przez phishing. Poprawnie wdrożone uwierzytelnianie WebAuthn/FIDO zapewnia inny poziom odporności na phishing. Zobacz wytyczne NIST dotyczące uwierzytelniania.

Przetestuj rejestrację i odzyskiwanie przed wymaganiem drugiego składnika od zespołu. Przechowuj kody odzyskiwania poza telefonem, sprawdź zegary serwera i telefonu oraz udokumentuj procedurę odzyskiwania narzędzia. Rdzeń nie ma standardowych kolumn 2FA pracownika do wyczyszczenia.

Security Revolution dodaje TOTP pracowników, kody zapasowe, kontrolę logowania, zarządzanie nagłówkami bezpieczeństwa i porównania plików z bazą odniesienia; konfigurację i odzyskiwanie opisuje pomoc modułu.

Oddziel wygasanie ciasteczka od bezczynności

PS_COOKIE_LIFETIME_BO jest mierzone w godzinach. Kontroluje czas życia cookie, a nie ogólną politykę bezczynności. Trwałe logowanie i kontrole bezczynności różnią się między wersjami; PrestaShop 1.7.8 ma osobną jednogodzinną kontrolę ostatniej aktywności we właściwym trybie logowania. Sprawdź rzeczywiste zachowanie wylogowania.

PS_PASSWD_TIME_BACK jest mierzone w minutach i dotyczy ostatniego wygenerowania hasła. Nie gwarantuje odstępu między żądaniami e-maili resetujących. W razie potrzeby dodaj osobne ograniczanie żądań.

Wymagaj HTTPS i sprawdź rzeczywiste ciasteczko panelu pod kątem flag Secure i HttpOnly oraz odpowiedniej polityki SameSite. Ustawienia ciasteczek sesji PHP niekoniecznie sterują każdym ciasteczkiem PrestaShop. Blokuj pozostawione bez nadzoru stanowiska i unieważniaj sesje po przejęciu urządzenia lub konta.

Sprawdź rejestrację i odzyskiwanie na zwykłym pracowniku

1. Użyj imiennego pracownika z docelowym profilem uprawnień, zamiast testować tylko jako SuperAdmin.
2. Dokończ rejestrację, wyloguj się i przetestuj nowe logowanie. Potwierdź, że nie można wejść na chronioną ścieżkę z pominięciem strony drugiego składnika.
3. Przetestuj udokumentowane odzyskiwanie po utracie urządzenia przy dostępności upoważnionej osoby do pomocy. Potwierdź, co unieważnia odzyskanie i jak pracownik rejestruje urządzenie zastępcze.
4. Sprawdź rejestrację każdego aktywnego pracownika, także wykonawców i kont używanych sporadycznie. Określ, kto zatwierdza wyjątek i kiedy on wygasa.

CAPTCHA formularzy klientów i uwierzytelnianie pracowników to osobne obszary. Instalacja ochrony logowania w sklepie nie dowodzi ochrony panelu administracyjnego; przetestuj rzeczywistą ścieżkę pracownika.

Ogranicz dostęp i wykrywaj nieudane logowania

Jeśli zespół używa stałego adresu biura lub VPN, ogranicz panel na proxy lub serwerze. Zachowaj autoryzowaną ścieżkę odzyskiwania i testuj z adresów dozwolonych i zabronionych. Przy reverse proxy skonfiguruj zaufane ustalanie IP klienta przed użyciem reguł IP.

Dla Apache 2.4 poniżej podano przykład katalogu administracyjnego, którego uprawnione biuro korzysta z pokazanej sieci dokumentacyjnej. Przy wdrożeniu użyj własnej zatwierdzonej sieci.

Require ip 203.0.113.10
Require ip 198.51.100.0/24

Ograniczaj częstotliwość nieudanych uwierzytelnień mechanizmem sprawdzonym z trasą logowania Twojej wersji. Nie wnioskuj o błędzie z HTTP 200 lub 302: udane i nieudane próby mogą używać tych samych kodów. Filtr fail2ban potrzebuje logów właściwych dla błędów i testów potwierdzających, że nie blokuje udanego logowania.

Logi rdzenia są częściowym zapisem. PrestaShop 1.6, 1.7.8 i 8.2 zapisują udane połączenia z panelem wraz z pracownikiem i źródłowym IP. Wykrywanie nieudanych logowań, analiza lokalizacji i doręczanie alertów wymagają osobnych mechanizmów. Przechowuj razem logi proxy, uwierzytelniania i aplikacji ze zsynchronizowanymi znacznikami czasu.

Własne powiadomienia o logowaniu muszą używać właściwej integracji: zgodne starsze wydania udostępniają actionAdminLoginControllerLoginAfter; PrestaShop 9 używa zdarzeń uwierzytelniania Symfony, takich jak LoginSuccessEvent. Działający alert e-mail wymaga też zarejestrowanych listenerów, rzeczywistych przetłumaczonych szablonów, ścieżki szablonu, skutecznego doręczenia i obsługi błędów.

Uprawnienia plików, tożsamości hostingu i błędy pamięci podręcznej

Przed zmianą właściciela ustal tożsamość procesu PHP. Procesy robocze PHP-FPM działają jako użytkownik i grupa skonfigurowane dla puli, które mogą różnić się od użytkownika i grupy Nginx, Apache lub nadrzędnego procesu działającego jako root. Przy mod_php PHP działa w procesie Apache. Na hostingu opartym na kontach lub przy suPHP może działać jako użytkownik hostingu.

Dla zwykłego kodu aplikacji wymagającego odczytu częstym punktem wyjścia jest 755 dla katalogów i 644 dla plików. Prawo wykonywania katalogu pozwala przez niego przechodzić. Właściciel, grupa i ACL decydują, kto może pisać. Uczynienie użytkownika PHP właścicielem każdego pliku kodu pozwala też przejętemu PHP je nadpisywać. Preferuj kod należący do użytkownika wdrożeniowego i wąsko ograniczony zapis w czasie działania, jeśli pozwala na to Twój proces utrzymania.

Zapewnij PHP możliwość odczytu app/config/parameters.php w PrestaShop 1.7, 8 i 9. Starszy 1.6 używa config/settings.inc.php. Zbiorcze ustawienie trybu 400 może zepsuć sklep, jeśli PHP nie jest właścicielem. Nie stosuj 777 do naprawienia błędu zapisu. Podatne PHP nadal może pisać do katalogu 755, którego jest właścicielem.

Napraw błąd zapisu pamięci podręcznej po migracji

1. Odczytaj dokładną ścieżkę błędu i sprawdź właściciela, grupę, tryb oraz uprawnienia przechodzenia katalogów nadrzędnych.
2. Sprawdź rzeczywisty proces roboczy PHP-FPM i konfigurację puli.
3. Nadaj wymaganej tożsamości PHP odczyt, zapis i przeszukiwanie przez właściciela, zaufaną grupę lub ACL.
4. Dopiero po naprawie dostępu usuń wygenerowaną zawartość pamięci podręcznej we właściwym środowisku i rozgrzej ją jako docelowy użytkownik środowiska wykonawczego.
5. Jeśli dostęp nadal nie działa, sprawdź miejsce na dysku, i-węzły, montowania tylko do odczytu, SELinux/AppArmor, ścieżki chroot i umask wdrożenia.

Przykład zakłada potwierdzenie, że proces roboczy PHP działa jako www-data i powinien być właścicielem tej pamięci podręcznej. Używa podwyższonych uprawnień do wszystkich zmian trybów i osobno zmienia pliki oraz katalogi.

sudo chown -R www-data:www-data /var/www/html/var/cache
sudo find /var/www/html/var/cache -type d -exec chmod 750 {} +
sudo find /var/www/html/var/cache -type f -exec chmod 640 {} +

Nowsze ścieżki wymagające zapisu obejmują var/cache/, logi, img/, upload/ i download/. Instalacja modułów, zmiany motywów, tłumaczenia i aktualizacje wymagają dodatkowego tymczasowego zapisu. Starsze pamięci podręczne Smarty w 1.6 mogą znajdować się w cache/smarty/. Oddziel uprawnienia aktualizatora od rutynowych uprawnień sklepu.

W Dockerze porównuj liczbowe UID/GID wewnątrz i poza kontenerem. Bind mounty zachowują właściciela z hosta. Nazwane wolumeny też wymagają właściwej inicjalizacji i właściciela; nie dają automatycznie dostępu PHP. Unikaj cyklicznego chown całego drzewa zamiast świadomego modelu tożsamości.

Przy błędach przesyłania plików sprawdź też limity uploadu PHP. Przy pustej stronie po chmod sprawdź przechodzenie przez katalogi i log PHP. Sprawdź uprawnienia klienta SFTP i umask, jeśli przesyłanie stale zmienia tryby.

Chroń konfigurację, przesyłane pliki i środowisko PHP

Wyłącz produkcyjne wyświetlanie debugowania. Ustaw _PS_MODE_DEV_ na false w config/defines.inc.php i sprawdź odpowiednią opcję Zaawansowane > Wydajność > Tryb debugowania. Zapisuj błędy w chronionym miejscu. Sprawdź skuteczne ustawienia webowego SAPI zamiast polegać na PHP CLI. Podstawowy zestaw obejmuje display_errors=Off, log_errors=On, expose_php=Off i allow_url_include=Off.

Wyłączenie funkcji procesowych, takich jak exec, system, shell_exec, passthru, popen i proc_open, może ograniczyć niektóre ładunki ataku, lecz zepsuć prawidłowe zadania. Pule PHP-FPM mogą ustawiać php_admin_value[disable_functions] podobnie jak php.ini. Zrestartuj właściwą usługę, sprawdź środowisko webowe i przetestuj przetwarzanie obrazów, importy i zadania PDF. Nie uniemożliwia to PHP odczytu zapisywalnych danych ani używania danych logowania do bazy.

open_basedir może ograniczać ścieżki, lecz wymaga wszystkich prawidłowych ścieżek tymczasowych i aplikacji. Traktuj to jako dodatkowe ograniczenie, a nie piaskownicę. Nie udostępniaj trwale phpinfo ani testowego pliku powłoki.

Blokuj wrażliwe ścieżki HTTP

Wyłącz listowanie katalogów. Zabroń publicznego dostępu do konfiguracji, logów, kopii zapasowych, zrzutów SQL, metadanych repozytorium i manifestów zależności. Trzymaj kopie poza katalogiem publicznym. Poprawnie wykonywany plik parametrów PHP nie wypisuje zwracanej tablicy, ale ujawnienie źródła lub kopia pliku mogą ujawnić dane logowania.

Przy ograniczaniu plików zaczynających się od kropki zachowaj niezbędne ścieżki certyfikatów /.well-known/. Nie blokuj bezrefleksyjnie wszystkich plików PHP modułów: callbacki, zadania cron i starsze endpointy AJAX mogą na nich polegać.

Nie pozwól, by przesłane skrypty trafiały do PHP

Obejmij img/, upload/ i download/, uwzględniając alternatywne wykonywalne rozszerzenia i nazwy z wieloma rozszerzeniami. Sprawdź rzeczywistą konfigurację handlera PHP. Ten przykład wirtualnego hosta Apache 2.4 blokuje typowe nazwy plików wykonywalnych w tych ścieżkach:

<DirectoryMatch "/var/www/html/(img|upload|download)(/|$)">
    <FilesMatch "(?i)\.(php[0-9]?|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

DirectoryMatch należy do konfiguracji serwera lub wirtualnego hosta. php_admin_flag engine off dotyczy mod_php i nie wolno kopiować tego bez zabezpieczeń do konfiguracji PHP-FPM. Przy PHP-FPM wyklucz te ścieżki również z wykonywania FastCGI.

W Nginx umieść blokującą lokalizację dla nazw wykonywalnych przed ogólną lokalizacją regex PHP, dostosuj ją do ewentualnego podkatalogu sklepu i sprawdź wszystkie lokalizacje handlerów. Na przykład:

location ~* ^/(img|upload|download)/.*\.(php[0-9]?|phtml|phar)(\.|$) {
    return 403;
}
autoindex off;

Zweryfikuj konfigurację serwera, a następnie przetestuj blokowane nazwy i zwykłe obrazy, pliki klientów, pliki do pobrania i callbacki płatności. Dopasuj reguły do każdego rozszerzenia faktycznie wykonywanego przez serwer.

HTTPS, nagłówki bezpieczeństwa i CSP

Zainstaluj i odnawiaj ważny certyfikat, włącz SSL i SSL na wszystkich stronach w Parametry sklepu > Ogólne w nowszych wersjach, a następnie sprawdź przekierowania HTTP, składanie zamówień i mieszaną zawartość. W 1.6 ustawienia ogólne znajdują się w Preferencje. Przeglądarki blokują aktywną mieszaną zawartość, taką jak skrypty, i mogą automatycznie przełączać mieszane zasoby multimedialne na HTTPS. Znajdź ją w konsoli przeglądarki i panelu Network.

Przekierowuj do skonfigurowanego zaufanego hosta. Uwzględnij zakończenie TLS na proxy, aby uniknąć pętli. Dodaj HSTS dopiero po uzyskaniu niezawodnego HTTPS; używaj includeSubDomains tylko wtedy, gdy każda objęta subdomena obsługuje HTTPS.

Sprawdź X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, ograniczenia osadzania w ramkach i odpowiednią Permissions-Policy. Przed wymuszeniem ograniczeń ramek przetestuj osadzone płatności i inne integracje.

Wdrażaj Content Security Policy etapami

default-src zapewnia wartości zastępcze. script-src kontroluje skrypty; style-src, img-src i font-src inne zasoby; connect-src połączenia skryptów. frame-src kontroluje osadzone ramki, a frame-ancestors to, kto może osadzać Twoją stronę. form-action ogranicza miejsca wysyłania formularzy. Rozważ object-src 'none', aby blokować obiekty i osadzane treści, oraz base-uri 'self', aby ograniczyć bazowe URL, po przetestowaniu integracji. Ustaw jawnie base-uri, form-action i frame-ancestors: nie korzystają z wartości zastępczych default-src.

1. Zacznij od Content-Security-Policy-Report-Only.
2. Sprawdzaj diagnostykę przeglądarki podczas obsługi produktu, koszyka, konta, kontaktu, zamówienia, przekierowania i 3-D Secure.
3. Aby zbierać raporty, wdróż usługę odbiorczą, skonfiguruj Reporting-Endpoints z report-to i odpowiednim mechanizmem zastępczym report-uri, a następnie potwierdź nadejście celowo wywołanego naruszenia testowego.
4. Zbuduj listę dozwolonych źródeł z faktycznie wymaganych originów. Usuń szerokie dopuszczenia https:, 'unsafe-inline' i 'unsafe-eval' tam, gdzie pozwala na to zgodna obsługa nonce, hashy i szablonów.
5. Po testach przejdź do wymuszania polityki i nadal monitoruj raporty.

Nagłówek report-only niczego nie blokuje. Bez działającego odbiornika pusty log serwera nie mówi nic o naruszeniach. Nie ufaj automatycznie raportowanym źródłom ani nie dodawaj ich do listy dozwolonych. Dyrektywy raportowania definiuje CSP Level 3.

Polityka dopuszczająca 'self' nadal może przepuścić zainfekowany lokalny skrypt lub przekaźnik o tym samym pochodzeniu (origin). Nadal potrzebne są niezależnie chronione kontrole integralności skryptów, monitoring serwera i załatany kod.

Moduły, dostęp do bazy i publiczne punkty wejścia

Instaluj moduły ze źródeł, za które ktoś odpowiada. Sprawdzaj utrzymanie, dzienniki zmian, poprawki bezpieczeństwa i integralność pakietów. Niezaufane lub zmodyfikowane pakiety mogą zawierać malware. Obecność na renomowanym marketplace nie dowodzi braku podatności w kodzie.

Wyłączenie modułu zwykle blokuje jego standardowe trasy ModuleFrontController. Samodzielne skrypty PHP mogą nadal być wykonywalne. Przed odinstalowaniem nieużywanego oprogramowania zachowaj dane biznesowe i sprawdź zależności, callbacki oraz zadania harmonogramu; następnie usuń pliki.

Przegląd kodu powinien śledzić dane żądania przez autoryzację, walidację typów, SQL, zapisy plików i escapowanie wyjścia. eval lub zdekodowane dane wykonywalne wymagają uwagi. file_get_contents pobiera bajty zamiast je wykonywać, więc sprawdź miejsce docelowe i późniejsze użycie. Wykonywanie asercji tekstowych usunięto w PHP 8. Rzutowanie na liczbę całkowitą i pSQL() obsługują konkretne dane SQL; nie zastępują pełnego przeglądu bezpieczeństwa.

Używaj dedykowanego konta bazy ograniczonego do bazy sklepu, a nie konta administratora baz. Nadaj uprawnienia potrzebne rzeczywistym operacjom działania i utrzymania. Unikaj zbędnych uprawnień globalnych, FILE lub administracyjnych. Ogranicz sieciowy dostęp do bazy i stosuj prywatne połączenie, jeśli baza jest zdalna.

Chroń lub usuń publiczne narzędzia administracji bazą. Preferuj uwierzytelnianą prywatną ścieżkę lub tunel SSH i wyłącz webowe logowanie root oraz bez hasła. Inny prefiks tabel nie naprawia SQL injection.

Usuń folder install po instalacji i sprawdzaj, czy nie wrócił po migracji lub przywróceniu kopii: dostępny instalator pozwala każdemu ponownie uruchomić instalację i przejąć sklep. W kwietniu 2026 Sansec znalazł ponad 200 sklepów PrestaShop z dostępnym instalatorem.

Dostęp Webservice, partnerzy logistyczni i odbieranie uprawnień

W Parametry zaawansowane > Webservice wyłącz API, jeśli nie jest używane. W przeciwnym razie wydawaj osobny klucz dla każdej integracji, ogranicz zasoby i metody, wymagaj HTTPS, bezpiecznie przechowuj sekrety i unieważniaj nieużywane klucze. Osobno sprawdzaj klientów i zakresy Admin API tam, gdzie je wdrożono.

Zbuduj listę dostępu operatora 3PL na podstawie jego rzeczywistych żądań. Zamówienia zawierają ID adresów, więc wysyłka może wymagać danych adresu, kraju, regionu, przewoźnika i kontaktu oraz zamówień i ich pozycji. Nadaj tylko to, czego potrzebuje proces.

Uprawnienia zasobów nie zapewniają izolacji na poziomie pól lub zamówień. Szczegóły zamówienia mogą ujawniać pola kosztu zakupu. Lista wyświetlania wybrana przez klienta API nie jest granicą dostępu. Jeśli partner nie może widzieć kosztów lub innych zamówień, udostępnij filtrowany endpoint lub eksport kontrolowany przez serwer.

Aktualizacje śledzenia i zmiany statusu zamówienia używają osobnych ścieżek. Utworzenie zasobu order_histories zmienia status; dodaj sendemail=1, aby zażądać skonfigurowanego e-maila statusowego. Status musi też mieć włączony e-mail i odpowiedni szablon. Aktualizacja zasobu order_carriers zmienia śledzenie; jego osobna opcja sendemail=1 żąda wiadomości o transporcie, która wymaga też URL śledzenia przewoźnika. Domyślnie obie opcje nie wysyłają e-maila. Zaktualizuj śledzenie przed żądaniem odpowiedniej wiadomości i usuwaj duplikaty ponowień.

1. Wyłącz konto odchodzącego pracownika natychmiast po zakończeniu dostępu.
2. Unieważnij jego indywidualne klucze Webservice, klientów API oraz dostęp do hostingu, SFTP, SSH, poczty i usług zewnętrznych.
3. Unieważnij sesje i zmień wspólne sekrety, które znał.
4. Zachowaj przydatne przypisania działań w zamówieniach i audycie.
5. Sprawdź zadania harmonogramu, odpowiedzialność i kontakty odzyskiwania.

Profil to wielokrotnie używana rola uprawnień, a nie login z przełącznikiem aktywności. Zmiana lub usunięcie wspólnego Profilu może wpłynąć na innych pracowników. Zobacz poradnik Webservice, aby poznać pojęcia API.

Przykład: przekazanie do magazynu

Załóżmy, że magazyn potrzebuje opłaconych zamówień i ma zwracać śledzenie, ale nie może otrzymać kosztów zakupu. Zacznij od zamówienia testowego i rzeczywistej listy żądań magazynu. Jeśli standardowe uprawnienia zasobów ujawniają pola poza umową, filtruj je w integracji kontrolowanej przez Twój serwer zamiast ufać polom wyświetlania żądanym przez magazyn.

Przeprowadź przekazanie na środowisku testowym z pocztą wychodzącą przechwytywaną przez skrzynkę testową. Pobierz uzgodnione dane zamówienia i adresu, a potem spróbuj pobrać koszty zakupu i niezwiązane zamówienie przez dostęp partnera; żadna próba nie może ujawnić wykluczonych danych. Zaktualizuj śledzenie przed żądaniem uzgodnionych zmian statusu i e-maili. Odtwórz to samo zdarzenie magazynowe i potwierdź, że obsługa ponowień zapobiega podwójnym wpisom historii i wiadomościom. Unieważnij klucz testowy magazynu i potwierdź błąd następnego żądania; dowodzi to możliwości zakończenia integracji oraz jej uruchomienia.

Zweryfikuj odejście, zamiast tylko usunąć nazwisko

Po powyższych krokach odebrania dostępu sprawdź odrzucenie istniejącej sesji pracownika i nowego logowania oraz niepowodzenie unieważnionych danych API. Potwierdź, że pozostali pracownicy mogą nadal pracować. Jeśli stara sesja nadal działa, zbadaj kontrolę sesji danej wersji lub warstwy dostępu zamiast zakładać, że przełącznik pracownika ją unieważnił. Sprawdź, czy adresy odzyskiwania, dane zadań harmonogramu i miejsca kopii zapasowych należą teraz do odpowiedzialnej osoby.

Zatrudniaj i deleguj z kontrolowanym dostępem

Znajdź wąskie gardło, zanim zatrudnisz pomoc. Sprawdź wiek otwartych wątków pomocy, opóźnienia od zapłaty do wysyłki, błędy stanów, pominięte zapytania i pracę zatrzymującą się podczas Twojej nieobecności. Mierz pierwszą odpowiedź według czasu wiadomości lub raportu helpdesku; lista rdzenia nie jest pełnym panelem czasu reakcji.

Sam przychód lub ruchy bankowe nie dają marży netto zamówienia. Użyj poniższego obliczenia, aby porównać pełny koszt pomocy z dodatkową marżą pokrycia, którą realnie może dać uwolniony czas, uwzględniając sezonowy popyt.

Aby wdrożyć osobę, utwórz rolę w Zespół > Profile, skonfiguruj Uprawnienia, a potem utwórz Pracownika z tym profilem i dostępem tylko do odpowiednich sklepów. Przetestuj rolę, logując się jako ta osoba, także przez bezpośrednie URL i działania modułów zewnętrznych. Ukrycie menu nie wystarcza do testu autoryzacji. Ściśle ogranicz instalację modułów, Menedżer SQL i zarządzanie pracownikami. Uprawnienie instalacji modułu pozwala wprowadzić kod PHP po stronie serwera, więc traktuj je jak uprawnienie wdrażania.

Opisz proces statusów zamówień, zasady zwrotów produktów i pieniędzy, procedury magazynowe i eskalację do wsparcia. Gotowe Wiadomości zamówień wybiera się na stronie zamówienia. Wątki Obsługi klienta mają własne działanie podpisów i odpowiedzi domyślnych; wspólny katalog szablonów wymaga odpowiedniej integracji helpdesku.

Utrzymuj strategię produktów, wybór dostawców, kierunek marki i politykę wobec klientów pod jasno przypisaną odpowiedzialnością. Zlecaj określone wykonanie, gdy uzasadniają to wymogi jakości, częstotliwość, potrzebny kontekst i koszt. Porównaj opłaty 3PL za magazynowanie, przyjęcia, kompletację i pakowanie, wysyłkę, zwroty oraz opłaty minimalne z własnymi kosztami.

Daj usługodawcom pisemny opis zadania, przykłady odbiorcze, harmonogram komunikacji oraz jasne zasady własności materiałów i danych dostępowych. Oceń ponownie stałą współpracę z wykonawcą, gdy koordynacja staje się wąskim gardłem. Status zatrudnienia zależy od lokalnych przepisów i faktycznej relacji, a nie progu godzin tygodniowo. Preferuj hooki, dekorowanie usług i obsługiwane punkty rozszerzeń motywu zamiast starszych mechanizmów override, które dopuszczają tylko jedno nadpisanie.

Dobierz pomoc do wąskiego gardła

Przećwicz obliczenie zatrudnienia na własnych danych: oszacuj dodatkowe zamówienia, które uwolnione zasoby mogą realnie obsłużyć, a potem pomnóż je przez marżę pokrycia dodatkowego zamówienia po koszcie produktu, opłatach płatniczych, realizacji, oczekiwanych zwrotach i innych kosztach zmiennych. Porównaj wynik z wynagrodzeniem lub opłatą wykonawcy, kosztami pracodawcy, szkoleniem, nadzorem i narzędziami w tym samym okresie. Jeśli nie ma realnego dodatkowego popytu, nie ma też wkładu wzrostu; uzasadnienie opiera się wtedy na jakości obsługi, ciągłości lub obciążeniu pracą zamiast założonym przychodzie.

Wykonawcy katalogu przekaż na przykład uzgodnione mapowanie CSV i próbne wiersze przed nadaniem dostępu do importu. Zweryfikuj referencje produktów, język i zakres sklepu na kopii testowej, przejrzyj zmienione produkty, a potem zatwierdź import produkcyjny. Fotograf może dostarczyć pliki nazwane referencjami bez logowania do panelu; rezultat pracy specjalisty nie wymaga automatycznie dostępu do sklepu.

Filtrowanie ruchu i sklepy oczekujące na migrację

WAF może blokować konkretne żądania wykorzystujące podatności, ograniczać nadużycia i chronić kosztowne trasy, takie jak URL wyszukiwania fasetowego. Testuj reguły podczas przeglądania, składania zamówień, użycia API i callbacków dostawców. Robots.txt jest wskazówką dla robotów, a nie kontrolą dostępu. Blokady krajów i IP mogą dotknąć prawdziwych klientów, zwłaszcza we współdzielonych sieciach.

Gdy proxy chroni sklep, ogranicz porty WWW serwera źródłowego do zaufanych sieci proxy i niezbędnych ścieżek zarządzania. Uwzględnij IPv4 i IPv6 oraz aktualizuj listy adresów. Rekordy pocztowe i stary DNS mogą ujawniać IP serwera źródłowego. Dostęp SSH, poczty i panelu hostingu obejmij osobnymi regułami.

Pola wyrażeń limitowania żądań Cloudflare zależą od planu: Free zapewnia pola oparte na ścieżce, Pro dodaje dopasowanie zapytania, a Business pola źródłowego IP i user-agent. Zliczanie per IP jest osobną możliwością. Advanced Rate Limiting to oddzielna oferta Enterprise. Sprawdź aktualną dostępność przed zaprojektowaniem reguły zalewu zależnej od zapytania.

CAPTCHA może ograniczać nadużycia w sklepie, ale wymaga testów dostępności i awarii. reCAPTCHA & hCaptcha Protection obejmuje obsługiwane formularze klientów; konfigurację opisuje pomoc modułu.

Customer Extra Info (IP Ban) zapewnia informacje o odwiedzających i blokowanie IP; właściwy zakres skonfiguruj według pomocy modułu.

Stosuj zabezpieczenia kompensacyjne na czas migracji

Ustal dokładny podatny komponent i komunikat bezpieczeństwa. Zewnętrzna reguła przechwytująca WAF jest wirtualną łatką; zmiana źródła jest bezpośrednią poprawką lub backportem. Śledź i testuj każde tymczasowe rozwiązanie oraz wyznacz termin usunięcia związany z planem aktualizacji.

Dla starszego łańcucha ataku na pamięć podręczną MySQL Smarty sprawdź podatne wydanie i poprawkę projektu. W 1.7.8 _PS_SMARTY_CACHING_TYPE_ jest stałą PHP i steruje ładowaniem zasobu pamięci podręcznej MySQL. Nie jest selektorem na stronie Wydajność. Po naprawie sprawdź faktycznie używany zasób pamięci podręcznej.

Przeglądaj osobno porzucone samodzielne endpointy zamiast blokować całe PHP modułów. Niezmienność plików jest opcjonalną kontrolą administratora dla osobno zinwentaryzowanych plików; niektóre konfiguracje są legalnie zmieniane przez PrestaShop. Udokumentuj odblokowanie na czas utrzymania i ponowne zablokowanie.

Zadbaj o możliwość oceny tymczasowych zabezpieczeń

Dla każdej tymczasowej reguły lub przeniesionej poprawki zapisz komponent i wersję, ostrzeżenie lub dowód z logów, dokładną objętą ścieżkę żądania lub kodu, właściciela, procedurę cofnięcia i zależność migracyjną pozwalającą ją usunąć. Szeroka blokada podejrzanych słów może przepuścić zakodowane dane i odrzucić prawidłowe wyszukiwania; testuj potwierdzoną ścieżkę ataku obok normalnych żądań.

Na przykład stary moduł wyszukiwania może potrzebować zarówno celowanej poprawki wadliwej ścieżki zapytania, jak i reguły ruchu przeciw kosztownym żądaniom robotów. Te zabezpieczenia dotyczą różnych problemów. Potwierdź odrzucenie blokowanego żądania, działanie prawidłowych filtrów i brak obejścia proxy przez serwer źródłowy, a potem zachowaj wyniki z planem migracji. Przed wymuszeniem reguł przejrzyj zdarzenia WAF, aby decyzja uwzględniała powiadomienia płatnicze, przydatne roboty i ruch klientów.

Monitoring i praktyczna kontrola własna

Monitoruj nowe i zmienione pliki PHP, JavaScript i szablony względem zaufanego wzorca wdrożenia. Chroń wzorzec osobno, sprawdzaj wykluczenia i zaplanuj rzeczywiste skany oraz doręczanie alertów, jeśli potrzebujesz wykrywania bez nadzoru. Ręczny skan jest porównaniem w jednym momencie.

Porównaj rdzeń z tym samym czystym wydaniem, a pliki modułów z zaufanymi pakietami. Sprawdź niewyjaśnione konta pracowników, zmienione ustawienia płatności, nieznane pola zamówienia i nieoczekiwane skrypty. Zmiany plików mogą też być prawidłowymi wdrożeniami; badaj je zamiast automatycznie usuwać dopasowania.

Do przeglądu pracowników tylko do odczytu w razie potrzeby zmień prefiks tabeli:

SELECT id_employee, email, id_profile, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

Standardowa tabela pracowników nie ma date_add. Rosnące ID może pomóc przejrzeć nieznane konta, ale nie jest czasem utworzenia. last_connection_date nie jest polem wieku konta.

Te wyszukiwania tylko do odczytu uruchomione w katalogu głównym sklepu wskazują pliki do sprawdzenia:

find img upload download -type f -iname '*.php*' -print
find img upload download -type f \( -iname '*.phtml*' -o -iname '*.phar*' \) -print
find . -type f -name '*.php' -mtime -14 -print
find . -type f -name '*.js' -mtime -14 -print
find . -type f -name '*.php' -exec awk 'length($0)>5000 {print FILENAME ":" FNR}' {} +

Długie linie i zakodowane ciągi mogą być prawidłowe. Powiąż mtime, ctime, obsługiwane czasy utworzenia, logi i migawki. Ctime to ostatnia zmiana stanu i-węzła, a nie pierwsze utworzenie pliku; zmiany właściciela i trybu mogą go aktualizować.

Monitoruj treść strony głównej, reprezentatywne strony katalogu i dostępność składania zamówień, nie tylko HTTP 200. Osobno sprawdzaj odnawianie certyfikatu. Potwierdź, że wybrany plan monitoringu obejmuje alerty certyfikatu i czasu odpowiedzi, a następnie przetestuj ich doręczanie do obsługiwanego kanału.

Samodzielna kontrola powinna obejmować wersje oprogramowania, aktualizacje modułów, pracowników, porównania plików, ograniczenia serwera źródłowego i odtworzoną kopię. Profil pracownika tylko do odczytu nie czyni automatycznie każdego endpointu konfiguracji modułu zewnętrznego bezpiecznym dla audytora; uzgodnij wymagany dostęp i obsługę danych wprost. Do przeglądu zewnętrznego użyj konta tymczasowego, zapewnij w miarę możliwości odczyt plików i logów, a po zakończeniu uzgodnionych prac usuń konto. Poradnik gotowości do audytu pomaga przygotować to przekazanie.

Do wstępnego lokalnego przeglądu Security Scan bezpłatnie zgłasza ustalenia według priorytetów i ręczne kroki naprawy. Badanie działa tylko do odczytu, a wyniki pozostają w sklepie; nie blokuje ruchu, nie poprawia plików ani nie zmienia ustawień. Zaplanowane skany i alerty krytycznych ustaleń wspierają dalszą pracę, ale wynik punktowy nie dowodzi braku infekcji.

Przekuj ustalenia w kolejne działanie

Zachowaj każde nierozwiązane ustalenie z lokalizacją, dowodami, osobą odpowiedzialną i następnym działaniem. Czysta samodzielna kontrola odpowiada tylko na faktycznie wykonane sprawdzenia. Eskaluj niewyjaśnione ustalenia i powtarzaj odpowiednie kontrole po aktualizacji, zmianie motywu, nowej integracji lub przekazaniu dostępu.

Kopie zapasowe i reagowanie na incydenty

Twórz kopie bazy i odpowiadających jej plików według harmonogramu odpowiadającego tolerancji utraty zamówień. Zachowuj wiele punktów odtworzenia, szyfruj wrażliwe archiwa i utrzymuj kopię poza serwerem pod osobnymi danymi dostępowymi. Ustal retencję według potrzeb odtwarzania i biznesu zamiast uniwersalnej liczby dni.

Używaj chronionych danych logowania do bazy i narzędzia kopii sprawdzającego błędy. W poleceniach bezpośrednio w crontab znaki procentu wymagają pojedynczego znaku ucieczki; umieszczenie procesu kopii w skrypcie pozwala uniknąć tej pułapki. Przetestuj odtworzenie na odizolowanym sklepie, w tym logowanie klientów, obrazy, zamówienia i konfigurację. Zobacz poradnik kopii zapasowych.

Jeśli podejrzewasz włamanie

1. Odizoluj sklep na zaufanej warstwie serwera lub proxy. Zapobiegaj dalszym zakupom lub ujawnieniu danych, zachowując dostęp dla osób reagujących.
2. Zabezpiecz dowody incydentu: bazę, pliki, właściwe logi i znaczniki czasu. Zapisz kopie bezpiecznie przed destrukcyjnym czyszczeniem.
3. Zidentyfikuj punkt wejścia i mechanizmy utrzymania dostępu, w tym konta pracowników, zadania harmonogramu i treści wstrzyknięte do bazy.
4. Z czystego urządzenia i środowiska unieważnij sesje oraz zmień ujawnione dane hostingu, SSH, SFTP, bazy, pracowników, poczty i płatności/API. Koordynuj zmiany konfiguracji, aby odtworzenie działało.
5. Odbuduj sklep z zaufanych pakietów oprogramowania i przywróć czyste dane, a następnie załataj punkt wejścia. Nie przenoś przejętego motywu, drzewa obrazów lub bazy bez zbadania.
6. Przed ponownym otwarciem przetestuj zamówienia, płatności, zwroty pieniędzy, pocztę i integracje. Uważnie monitoruj nawroty.

Jeśli używasz Apache do zwracania statusu konserwacji, skonfiguruj ErrorDocument 503 osobno. Reguła przepisywania z R=503 sama nie serwuje podstawionej ścieżki jako strony konserwacji.

W razie potrzeby powiadom hosting, operatora płatności i specjalistów reagowania na incydenty. Zgodnie z art. 33 GDPR powiadom organ nadzorczy bez zbędnej zwłoki i, gdy to możliwe, w ciągu 72 godzin od stwierdzenia naruszenia, chyba że ryzyko dla osób jest mało prawdopodobne. Art. 34 zasadniczo wymaga poinformowania osób bez zbędnej zwłoki, gdy prawdopodobne jest wysokie ryzyko, z zastrzeżeniem wyjątków. Korzystaj z wytycznych EDPB dotyczących naruszeń i swojej procedury ochrony danych.

Przed ponownym otwarciem potwierdź wyłączenie debugowania, usunięcie narzędzi tymczasowych, naprawienie lub usunięcie podatnych endpointów, kontrolę danych dostępowych i pracowników, możliwość odtworzenia kopii i docieranie alertów do osoby odpowiedzialnej.

Uzgodnij wcześniej decyzje o odtwarzaniu

Zapisz, kto może zatwierdzić ograniczenie incydentu, skontaktować się z hostingiem i dostawcą płatności, pobrać chronione kopie i zatwierdzić ponowne otwarcie. Zapisz tolerowaną utratę zamówień i dopuszczalną przerwę, a następnie zmierz względem nich odizolowane odtworzenie. Kopie mogą zawierać te same złośliwe pliki lub wstrzyknięte dane bazy co produkcja, więc wybór punktu odtworzenia wymaga dowodów czasu rozpoczęcia włamania.

Przejrzyj dane osobowe zachowywane przez sklep, moduły, eksporty i logi. Usuń zbędne kopie uzgodnionym procesem retencji, a pozostałe ogranicz. Zbieranie dodatkowych danych bez potrzeby biznesowej zwiększa zasób możliwy do przejęcia przez atakującego; kopiowanie do środowiska testowego lub archiwum incydentu też wymaga kontrolowanego dostępu.

O co zapytać programistę lub agencję

• Który dokładnie komponent i wersja są narażone i jakie dowody wiążą proponowaną zmianę z tym narażeniem?
• Które zabezpieczenia są na hostingu, proxy, w sklepie lub module i kto utrzymuje każde po przekazaniu?
• Które obecne funkcje motywu, ścieżki płatności, rynki i integracje partnerów przetestowano na środowisku testowym, także pod kątem zabronionych działań i odzyskiwania?
• Jaka jest procedura przełączenia i cofnięcia oraz jak uzgodnione zostaną zamówienia lub płatności otrzymane podczas migracji?
• Gdzie są baza wdrożenia, wyniki odtworzenia i dowody doręczania alertów oraz kto reaguje na nieudaną kontrolę?
• Które tymczasowe reguły, dane dostępowe i narzędzia trzeba usunąć, a które prace naprawcze pozostają poza uzgodnioną oceną?

Pytania właścicieli sklepów

Czy hosting zarządzany dba o bezpieczeństwo sklepu?

Poproś o pisemne określenie granic utrzymania. Utrzymanie systemu i serwera nie wskazuje, kto aktualizuje PrestaShop, motyw lub moduły. Potwierdź, kto przegląda ostrzeżenia, zatwierdza zmiany sklepu i reaguje na alerty aplikacji w rzeczywistej umowie.

Co jeśli zespół nie może używać stałych biurowych adresów IP?

Oceń zarządzany adres wyjściowy VPN lub proxy dostępu oparte na tożsamości z indywidualnym uwierzytelnianiem. Przed wymuszeniem przetestuj rzeczywiste miejsca pracy zespołu i odzyskiwanie po utracie urządzenia. Zachowaj zatwierdzoną ścieżkę odzyskiwania zamiast poszerzać listę dozwolonych adresów przy każdej podróży.

Czy od razu instalować skaner przy podejrzeniu włamania?

Najpierw uzgodnij metodę badania z osobą reagującą na incydent. Instalacja oprogramowania zmienia pliki i może naruszyć przydatne dowody lub bazę porównawczą. Zabezpiecz stan objęty incydentem i zorganizuj badanie z zaufanego środowiska przed dodaniem narzędzi do podejrzanej instalacji.

Jak przekazać logi lub dane dostępowe osobie pomagającej?

Uzgodnij chroniony kanał transferu i przekaż tylko to, czego wymaga badanie. Usuń niezwiązane dane osobowe i sekrety ze zwykłych zrzutów i załączników zgłoszeń; jeśli oryginalny log jest dowodem, zachowaj go osobno z kontrolowanym dostępem. Używaj tymczasowego indywidualnego dostępu zamiast wklejać wspólne hasło właściciela do zgłoszenia.

Czy tymczasowe reguły mogą zostać po migracji?

Oceń każdą regułę względem rzeczywistego narażenia zmigrowanego sklepu. Usuń nieaktualne wyjątki, a regułę kompensacyjną wycofaj dopiero po potwierdzeniu naprawy lub usunięcia podatnej ścieżki. Zachowaj przydatną ochronę i monitoring tam, gdzie nadal mają udokumentowany cel.