Zabezpieczanie PrestaShop: Kompletna lista kontrolna

Zabezpieczanie PrestaShop: Kompletna lista kontrolna

Co tydzień tysiące sklepów PrestaShop zostaje zhakowanych. Właściciele dowiadują się o tym, gdy Google oznacza ich stronę, gdy klienci zgłaszają kradzież kart, lub gdy strona główna zaczyna przekierowywać na spam. Szkody są realne: utracone przychody, zniszczone zaufanie, odpowiedzialność z tytułu RODO i tygodnie sprzątania.

Ten poradnik powstał na podstawie lat doświadczeń w naprawianiu zhakowanych sklepów. Każda rekomendacja dotyczy realnej podatności, którą widzieliśmy wykorzystywaną na produkcji. Realizuj go od początku do końca.

1. Dlaczego sklepy PrestaShop są hakowane

SQL Injection w modułach zewnętrznych

To wektor ataku numer jeden i to z ogromną przewagą. Moduły od niedoswiadczonych programistów często przekazują dane użytkownika bezpośrednio do zapytań SQL. Atakujący wysyła spreparowane żądanie do kontrolera front modułu i wyciąga całą bazę danych. Podatność prawie nigdy nie jest w rdzeniu PrestaShop — jest w modułach.

Ataki brute force na panel administracyjny

PrestaShop nie ma wbudowanego ograniczania liczby prób. Atakujący, który zna nazwę katalogu admina, może testować tysiące kombinacji haseł na minutę. Każde konto używające admin123 lub nazwy firmy zostanie złamane w kilka minut.

Podatności w przesyłaniu plików

Niektóre moduły pozwalają na przesyłanie plików bez odpowiedniej walidacji. Atakujący wgrywa powłokę PHP podszywającą się pod obraz, uzyskuje do niej dostęp przez przeglądarkę i przejmuje pełną kontrolę nad serwerem.

Przestarzałe PHP i oprogramowanie

Wersje PHP po zakończeniu wsparcia mają publicznie udokumentowane podatności z działającymi exploitami. To samo dotyczy przestarzałych wersji PrestaShop, Apache i MySQL.

Odsłonięte pliki konfiguracyjne

Źle skonfigurowane serwery udostępniają pliki .env, katalogi .git i konfiguracje YAML każdemu, kto o nie poprosi — ujawniając dane dostępowe do bazy danych i sekrety szyfrowania.

Sprawdzian rzeczywistości: Większość właścicieli myśli „mój sklep jest zbyt mały, żeby być celem.” Zautomatyzowane skanery nie przejmują się rozmiarem. Skanują każde IP w internecie. Jeśli prowadzisz PrestaShop, jesteś celem.

2. Bezpieczeństwo na poziomie serwera

Wersja i konfiguracja PHP

Używaj najnowszej wersji PHP obsługiwanej przez Twój PrestaShop — PHP 8.1+ dla PS 8.x, PHP 8.1-8.4 dla PS 9.x. Nigdy nie używaj wersji po zakończeniu wsparcia.

Kluczowe ustawienia hardening w php.ini:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen
expose_php = Off
allow_url_include = Off
display_errors = Off
log_errors = On
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
session.cookie_samesite = Lax
open_basedir = /var/www/html:/tmp:/usr/share/php

Uwaga: Niektóre moduły potrzebują exec() do przetwarzania obrazów lub generowania PDF. Jeśli moduł przestał działać, włącz ponownie tylko tę konkretną funkcję, której potrzebuje.

Uprawnienia plików

• Katalogi: 755 — właściciel odczyt/zapis/wykonanie, inni odczyt/wykonanie
• Pliki: 644 — właściciel odczyt/zapis, inni tylko odczyt
• Pliki konfiguracyjne: 400 — app/config/parameters.php powinien być tylko do odczytu przez właściciela

chown -R www-data:www-data /var/www/html/prestashop
find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chmod 400 /var/www/html/prestashop/app/config/parameters.php

# Writable directories PrestaShop needs
chmod -R 775 /var/www/html/prestashop/var/cache
chmod -R 775 /var/www/html/prestashop/var/logs
chmod -R 775 /var/www/html/prestashop/img
chmod -R 775 /var/www/html/prestashop/upload
chmod -R 775 /var/www/html/prestashop/download

Nigdy nie ustawiaj niczego na 777. Jeśli jakiś poradnik każe Ci użyć chmod 777, znajdź lepszy poradnik.

Konfiguracja SSL/TLS

Włącz SSL w PrestaShop (Parametry sklepu > Ogólne), a następnie dodaj nagłówki HSTS:

# Apache .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

# Nginx
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri;
}
server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

Wyłączenie listowania katalogów i wzmocnienie .htaccess

Dodaj te reguły do głównego pliku .htaccess:

Options -Indexes

# Block sensitive file types
<FilesMatch "\.(env|yml|yaml|log|sql|bak|old|orig|save|swp|dist|config|ini|phps)$">
    Require all denied
</FilesMatch>

# Block hidden files and directories (.git, .env, etc.)
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule (^\.|/\.) - [F]
</IfModule>

# Block composer files
<FilesMatch "^(composer\.json|composer\.lock)$">
    Require all denied
</FilesMatch>

# Block config, vendor, and log directories
<IfModule mod_rewrite.c>
    RewriteRule ^config/ - [F]
    RewriteRule ^vendor/ - [F]
    RewriteRule ^var/logs/ - [F]
    RewriteRule ^app/config/ - [F]
</IfModule>

# Block PHP execution in upload directories
<Directory "/var/www/html/prestashop/upload">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/prestashop/img">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

Odpowiednik dla Nginx:

location ~* \.(env|yml|yaml|log|sql|bak|old|swp|dist|config|ini)$ { deny all; return 404; }
location ~ /\. { deny all; return 404; }
location ~* ^/(upload|img|download)/.*\.php$ { deny all; return 404; }
location ~* ^/(config|vendor|var/logs|app/config)/ { deny all; return 404; }
autoindex off;

Przetestuj to: Po dodaniu tych reguł spróbuj otworzyć https://twojsklep.com/.env i https://twojsklep.com/app/config/parameters.php w przeglądarce. Powinieneś zobaczyć 403 lub 404 — nigdy rzeczywistą zawartość.

3. Bezpieczeństwo panelu administracyjnego PrestaShop

Zmień nazwę katalogu admina

PrestaShop generuje losową nazwę katalogu admina podczas instalacji. Nigdy nie zmieniaj jej na admin, backoffice ani panel. Jeśli jest przewidywalna, zmień ją:

mv /var/www/html/prestashop/admin /var/www/html/prestashop/admin-x7k9m2p4
rm -rf /var/www/html/prestashop/var/cache/*

Użyj co najmniej 10 losowych znaków. Dodaj URL do zakładek — nie musi być łatwy do zapamiętania.

Silne hasła i 2FA

Każde konto administratora musi używać unikalnego hasła o długości 16+ znaków z menedżera haseł. Bez wyjątków.

Włącz uwierzytelnianie dwuskładnikowe dla wszystkich kont (Zaawansowane parametry > Administracja). PrestaShop 1.7.6+ obsługuje natywnie Google Authenticator. Ten jeden środek powstrzymuje zdecydowaną większość ataków brute force.

Ogranicz dostęp do panelu admina po IP

Jeśli Twój zespół pracuje ze stałych adresów IP, odpowiednio ogranicz dostęp:

# .htaccess inside admin directory
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
    RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.20$
    RewriteRule .* - [F,L]
</IfModule>

Jeśli używasz VPN, ogranicz do IP VPN — pracownicy mogą pracować z dowolnego miejsca, pozostając ograniczeni po IP.

Wyłącz niepotrzebne konta pracowników

Regularnie audytuj konta pracowników (Zaawansowane parametry > Zespół > Pracownicy):

• Usuń konta byłych pracowników i wykonawców
• Usuń konta testowe z początkowej konfiguracji
• Upewnij się, że każdy pracownik ma minimalny wymagany profil — pracownicy magazynu nie potrzebują SuperAdmin

Monitorowanie logowań do panelu admina

Skonfiguruj fail2ban do ochrony przed brute force:

# /etc/fail2ban/filter.d/prestashop-admin.conf
[Definition]
failregex = ^<HOST> -.*"POST .*/admin.*/index\.php\?controller=AdminLogin.*" (200|302)

# /etc/fail2ban/jail.d/prestashop.conf
[prestashop-admin]
enabled = true
filter = prestashop-admin
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 600
bantime = 3600

4. Bezpieczeństwo modułów

Moduły są największą powierzchnią ataku w każdej instalacji PrestaShop. Traktuj każdy moduł jako potencjalne zagrożenie, dopóki nie udowodnisz inaczej.

Instaluj tylko z zaufanych źródeł

Bezpieczne źródła: PrestaShop Addons Marketplace, uznani deweloperzy z udokumentowanym doświadczeniem oraz dobrze utrzymywane moduły open-source na GitHub.

Nigdy nie instaluj modułów ze stron z „nullowanymi” lub „darmowymi” wersjami, od nieznanych programistów ani z przypadkowych postów na forach.

Ostrzeżenie: Nullowane (pirackie) moduły to najszybsza droga do zhakowania. Atakujący wstrzykują backdoory do legalnych modułów i dystrybuują je za darmo. Backdoor daje im kontrolę nad każdym sklepem, który go zainstaluje. Widzieliśmy to setki razy. Nie ma wyjątków.

Audytuj kod modułów

Przed instalacją jakiegokolwiek modułu szukaj tych sygnałów ostrzegawczych:

# Dangerous — arbitrary code execution
eval($variable)
eval(base64_decode($something))
assert($user_input)

# Dangerous — remote code loading
file_get_contents('http://external-domain.com/...')
include('http://...')

# Dangerous — unsanitized SQL
"SELECT * FROM ps_table WHERE id = " . $_GET['id']
Db::getInstance()->execute("... " . $_POST['value'] . " ...")

Bezpieczny kod używa parametryzowanych zapytań i metod walidacji PrestaShop:

// SAFE: Cast to integer, use pSQL()
$id = (int)Tools::getValue('id');
$name = pSQL(Tools::getValue('name'));

Aktualizuj moduły na bieżąco

• Sprawdzaj aktualizacje co najmniej raz w tygodniu
• Subskrybuj biuletyny bezpieczeństwa deweloperów
• Śledź Friends of Presta security advisories w poszukiwaniu CVE modułów PrestaShop
• Zawsze rób kopię zapasową przed aktualizacją

Całkowicie usuń nieużywane moduły

Wyłączenie modułu nie wystarczy. Pliki wyłączonego modułu nadal istnieją na serwerze, a jego kontrolery front są dostępne przez bezpośredni URL. Jeśli ma podatność, wyłączenie zapewnia zero ochrony.

# Uninstall via Back Office, then delete the files
rm -rf /var/www/html/prestashop/modules/unused_module

Przejrzyj swoją listę modułów teraz. Jeśli zainstalowałeś coś do testów sześć miesięcy temu — usuń to. Każdy nieużywany moduł to niepotrzebna powierzchnia ataku.

Audytuj uprawnienia modułów

find /var/www/html/prestashop/modules -type d -exec chmod 755 {} \;
find /var/www/html/prestashop/modules -type f -exec chmod 644 {} \;

5. Bezpieczeństwo bazy danych

Nigdy nie używaj konta root dla aplikacji

Utwórz dedykowanego użytkownika z minimalnymi uprawnieniami:

CREATE USER 'prestashop_user'@'localhost' IDENTIFIED BY 'long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES
      ON prestashop_db.* TO 'prestashop_user'@'localhost';
FLUSH PRIVILEGES;

Jeśli atakujący wykorzysta SQL injection, ograniczony użytkownik zmniejsza szkody. Root może uzyskać dostęp do innych baz danych, czytać pliki serwera i wykonywać polecenia systemowe.

Regularne kopie zapasowe

# Crontab entries
# Database backup — daily at 3 AM
0 3 * * * mysqldump -u backup_user -p'password' prestashop_db | gzip > /backups/db/ps_$(date +\%Y\%m\%d).sql.gz

# File backup — daily at 3:30 AM
30 3 * * * tar -czf /backups/files/ps_files_$(date +\%Y\%m\%d).tar.gz /var/www/html/prestashop/

# Cleanup backups older than 30 days
0 4 * * * find /backups/ -name "*.gz" -mtime +30 -delete

Kluczowe zasady:

• Przechowuj kopie zapasowe poza serwerem — jeśli serwer zostanie skompromitowany, lokalne kopie również
• Testuj kopie zapasowe co miesiąc — przywracaj do środowiska testowego i weryfikuj działanie strony
• Szyfruj przed transferem poza serwer — dumpy zawierają dane osobowe klientów
• Przechowuj ponad 30 dni codziennych kopii — niektóre włamania nie są wykrywane od razu

Zabezpiecz phpMyAdmin (lub usuń go)

Najbezpieczniejsza opcja: nie instaluj phpMyAdmin na produkcji. Używaj tuneli SSH zamiast tego:

# From your LOCAL machine
ssh -L 3307:localhost:3306 user@yourserver.com
# Then connect your local MySQL client to localhost:3307

Jeśli musisz używać phpMyAdmin: ogranicz po IP, użyj losowej ścieżki URL, włącz HTTP Basic Auth i wyłącz logowanie na root:

$cfg['Servers'][$i]['AllowRoot'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

6. Monitorowanie i wykrywanie

Monitorowanie integralności plików

Atakujący modyfikują pliki — wstrzykują backdoory, dodają shelle do katalogów upload lub zmieniają .htaccess. Wykrywaj zmiany za pomocą codziennego zadania cron:

#!/bin/bash
# /usr/local/bin/prestashop-integrity-check.sh
SHOP_DIR="/var/www/html/prestashop"
BASELINE="/var/backups/prestashop-file-hashes.txt"
CURRENT="/tmp/prestashop-file-hashes-current.txt"
ALERT_EMAIL="admin@yourdomain.com"

find "$SHOP_DIR" -type f \
    -not -path "*/var/cache/*" \
    -not -path "*/var/logs/*" \
    -not -path "*/img/p/*" \
    -not -path "*/img/c/*" \
    -exec md5sum {} \; | sort > "$CURRENT"

if [ -f "$BASELINE" ]; then
    DIFF=$(diff "$BASELINE" "$CURRENT")
    if [ -n "$DIFF" ]; then
        echo "$DIFF" | mail -s "ALERT: PrestaShop files modified" "$ALERT_EMAIL"
    fi
fi

Wygeneruj punkt odniesienia po czystym wdrożeniu, a następnie ten skrypt wyśle Ci e-mail za każdym razem, gdy pliki zostaną nieoczekiwanie zmienione.

Monitorowanie logów

Skanuj logi dostępu w poszukiwaniu wzorców ataków:

# SQL injection attempts
grep -iE "(union\s+select|or\s+1=1|information_schema)" /var/log/apache2/access.log

# File inclusion attempts
grep -iE "(etc/passwd|\.\.\/\.\.\/)" /var/log/apache2/access.log

# Direct module file access (potential exploit attempts)
grep -E "modules/.*/ajax|modules/.*/api" /var/log/apache2/access.log

Skonfiguruj codzienne podsumowania logów przez cron lub przekieruj logi do scentralizowanego systemu, takiego jak Graylog lub Papertrail, aby otrzymywać alerty w czasie rzeczywistym.

Monitorowanie dostępności

• Używaj UptimeRobot, Hetrix Tools lub samodzielnie hostowanego Uptime Kuma
• Monitoruj zarówno stronę główną, jak i stronę kasy
• Sprawdzaj konkretne treści strony, nie tylko HTTP 200 — zdeface’owana strona również zwraca 200
• Sprawdzaj co 1-5 minut z alertami przez e-mail, SMS lub Slack

Alerty o logowaniu do panelu admina

Otrzymuj powiadomienie o każdym logowaniu do panelu admina za pomocą prostego hooka:

public function hookActionAdminLoginControllerLoginAfter($params)
{
    $employee = $params['employee'];
    $ip = Tools::getRemoteAddr();

    Mail::Send(
        (int)Configuration::get('PS_LANG_DEFAULT'),
        'alert_admin_login',
        "Admin Login: {$employee->email} from {$ip}",
        ['{body}' => "Employee: {$employee->email}\nIP: {$ip}\nTime: " . date('Y-m-d H:i:s')],
        'security@yourdomain.com',
        'Security Alert'
    );
}

7. Co zrobić, gdy zostałeś zhakowany

Natychmiastowa reakcja (pierwsze 30 minut)

• Jeszcze niczego nie usuwaj — potrzebujesz plików do analizy kryminalistycznej
• Wyłącz sklep stroną konserwacyjną, aby zatrzymać trwające szkody
• Zmień WSZYSTKIE hasła: SSH, FTP, baza danych, konta admina, panel hostingu, klucze bramki płatności
• Wykonaj kopię zapasową skompromitowanego stanu — oznacz ją jako „skompromitowana” do późniejszej analizy
• Powiadom operatora płatności, jeśli obsługujesz płatności bezpośrednio

# Quick maintenance mode
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.ADDRESS$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule .* /maintenance.html [R=503,L]

Znajdowanie backdoora

Atakujący zawsze zostawiają backdoory, aby móc wrócić. Usunięcie widocznego włamania bez znalezienia backdoora oznacza ponowne włamanie w ciągu kilku dni.

# Search for backdoor patterns
grep -rn "eval(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "base64_decode" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "shell_exec\|passthru\|system(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"

# Find recently modified PHP files
find /var/www/html/prestashop/ -name "*.php" -mtime -7 -not -path "*/cache/*"

# Find PHP files in directories where they should not exist
find /var/www/html/prestashop/img/ -name "*.php"
find /var/www/html/prestashop/upload/ -name "*.php"

# Check for obfuscated code (very long single lines)
find /var/www/html/prestashop/ -name "*.php" -exec awk 'NR==1 && length>5000' {} +

Sprawdź również bazę danych:

SELECT id_cms, meta_title FROM ps_cms_lang WHERE content LIKE '%<?php%' OR content LIKE '%eval(%';
SELECT * FROM ps_employee ORDER BY date_add DESC LIMIT 10;

Proces odzyskiwania

1. Określ punkt wejścia z logów dostępu — szukaj nietypowych żądań POST do kontrolerów modułów w okolicach czasu włamania
2. Przywróć z czystej kopii zapasowej, jeśli jest dostępna. Zweryfikuj, że kopia pochodzi sprzed włamania.
3. Jeśli nie ma czystej kopii zapasowej: zamień wszystkie pliki rdzenia na świeże pobranie Twojej dokładnej wersji PS, zainstaluj ponownie wszystkie moduły z oryginalnych źródeł, zachowaj tylko motyw i katalog img/ (przeskanuj je dokładnie)
4. Przeskanuj bazę danych w poszukiwaniu wstrzykniętej zawartości w ps_configuration, ps_cms_lang i ps_meta_lang
5. Zaktualizuj wszystko — rdzeń, moduły, PHP, MySQL, system operacyjny

Zapobieganie po czyszczeniu

• Usuń lub załataj konkretną podatność, która została wykorzystana
• Intensywnie monitoruj przez pierwszy miesiąc — atakujący często próbują wrócić
• Rozważ WAF (darmowy plan Cloudflare, Sucuri lub ModSecurity)
• Jeśli dane płatnicze mogły zostać skompromitowane, skonsultuj się z prawnikiem w sprawie obowiązków powiadamiania RODO (termin 72 godziny)

Twarda prawda: Jeśli nie możesz ustalić, jak atakujący się dostał, załóż, że dostanie się ponownie. Profesjonalny audyt bezpieczeństwa kosztuje ułamek tego, co drugie włamanie.

8. Lista kontrolna bezpieczeństwa

Wydrukuj tę listę i przejdź przez nią punkt po punkcie. Każdy niezaznaczony element to potencjalny punkt wejścia.

Serwer i PHP

• Wersja PHP jest aktualna i wspierana
• Niebezpieczne funkcje PHP wyłączone
• expose_php = Off
• display_errors = Off na produkcji
• allow_url_include = Off
• Ciasteczka sesji: HttpOnly, Secure, SameSite
• open_basedir ustawione
• System operacyjny, MySQL i serwer WWW zaktualizowane
• Uwierzytelnianie kluczem SSH włączone, hasło wyłączone
• Firewall skonfigurowany (tylko niezbędne porty otwarte)

System plików

• Katalogi: 755, Pliki: 644
• parameters.php: 400
• Żadne pliki nie mają uprawnień 777
• Wykonywanie PHP zablokowane w upload/, img/, download/
• Listowanie katalogów wyłączone
• Pliki .env, .git, YAML, konfiguracyjne zablokowane z poziomu sieci
• vendor/ i var/logs/ zablokowane z poziomu sieci

SSL i HTTPS

• Ważny certyfikat SSL z automatycznym odnawianiem
• Przekierowanie HTTP na HTTPS działa
• Nagłówek HSTS skonfigurowany
• SSL włączone w PrestaShop (wszystkie strony)
• Brak ostrzeżeń o mieszanej zawartości

Panel administracyjny

• Katalog admina ma losową nazwę
• Wszystkie hasła 16+ znaków z menedżera haseł
• 2FA włączone dla wszystkich kont
• Dostęp do panelu admina ograniczony po IP (jeśli to możliwe)
• Niepotrzebne konta usunięte
• Każdy pracownik ma minimalne wymagane uprawnienia
• Ochrona przed brute force (fail2ban lub odpowiednik)

Moduły

• Wszystkie moduły z zaufanych źródeł
• Żadnych nullowanych/pirackich modułów
• Wszystkie moduły zaktualizowane
• Nieużywane moduły usunięte (nie tylko wyłączone)
• Kod modułów sprawdzony pod kątem eval() i niezabezpieczonych zapytań SQL
• Subskrypcja biuletynów bezpieczeństwa

Baza danych

• Dedykowany użytkownik bazy danych (nie root)
• Przyznane minimalne uprawnienia
• Silne hasło do bazy danych (20+ znaków)
• MySQL nasłuchuje tylko na localhost
• phpMyAdmin usunięty lub ograniczony po IP
• Prefiks tabel zmieniony z domyślnego ps_

Kopie zapasowe

• Zautomatyzowane codzienne kopie bazy danych
• Zautomatyzowane codzienne kopie plików
• Kopie przechowywane poza serwerem
• Kopie szyfrowane przed transferem
• Retencja ponad 30 dni
• Przywracanie przetestowane w ciągu ostatnich 30 dni

Monitorowanie

• Monitorowanie integralności plików aktywne
• Logi dostępu monitorowane pod kątem wzorców ataków
• Monitorowanie dostępności ze sprawdzaniem treści
• Alerty o logowaniu do panelu admina włączone
• Nagłówki bezpieczeństwa na swoim miejscu

Gotowość na incydenty

• Plan reakcji na incydenty udokumentowany
• Kontakty do hostingu i operatora płatności dostępne
• Proces powiadamiania RODO udokumentowany
• Strona konserwacyjna gotowa do wdrożenia
• Wszystkie krytyczne hasła w menedżerze haseł

Bezpieczeństwo to ciągły proces, nie jednorazowa konfiguracja. Zaplanuj przegląd kwartalny. Czas, który zainwestujesz teraz, jest nieznaczący w porównaniu z kosztem odzyskiwania po włamaniu. Zacznij od elementów o największym wpływie: zaktualizuj wszystko, włącz 2FA, usuń nieużywane moduły i skonfiguruj kopie zapasowe. Następnie przejdź przez resztę.

Twoi klienci powierzają Ci swoje dane osobowe. Uszanuj to zaufanie.