Stronę małej firmy rzadko atakuje ktoś, kto wie, czym ta firma się zajmuje. Atakuje ją automat, który przechodzi po milionach adresów i sprawdza znane luki w popularnych wtyczkach, zostawione na serwerze pliki konfiguracyjne i hasła z cudzych wycieków. Bezpieczeństwo strony firmowej nie zależy więc od tego, czy firma jest "wystarczająco ciekawa", tylko od tego, czy przejdzie ten sam test, który automat robi każdej stronie.
Poniżej przechodzimy przez siedem obszarów: aktualizacje, kopie zapasowe, HTTPS, nagłówki bezpieczeństwa, formularze, dostęp do kont i konfigurację serwera. Przy każdym piszemy, co powinno być zrobione i jak to sprawdzić bez pytania wykonawcy. Na końcu jest plan pierwszych godzin po włamaniu, razem z obowiązkami z RODO.
- Najważniejsze są aktualizacje: system, wtyczki, motywy i wersja PHP. PHP 8.1 nie dostaje już poprawek bezpieczeństwa, a 8.2 dostaje je tylko do końca 2026 roku.
- Kopia zapasowa musi leżeć poza serwerem i poza zasięgiem kogoś, kto przejmie serwer, a do tego sięgać dalej wstecz niż moment włamania.
- Od 15 marca 2026 roku certyfikat TLS może być ważny najwyżej 200 dni, a od 2029 roku 47 dni. Odnowienie musi działać automatycznie i być monitorowane.
- Kilka nagłówków HTTP zamyka całe klasy ataków. Sprawdzisz je w minutę w MDN HTTP Observatory.
- Po włamaniu najpierw zabezpiecz ślady i zmień wszystkie hasła, potem sprzątaj. Jeśli wyciekły dane osobowe, masz co do zasady 72 godziny na zgłoszenie do Prezesa UODO.
Kto atakuje stronę firmową i czego szuka
Przejęta strona firmowa jest dla atakującego zasobem: ma domenę z historią, zaufanie wyszukiwarki i opłacony serwer. Na stronie pojawiają się setki ukrytych podstron ze spamem SEO, odwiedzający z wyników Google są przekierowywani na oszustwa, w podkatalogu ląduje fałszywa strona logowania do banku, w sklepie skrypt kopiuje dane kart z formularza płatności, a serwer wysyła spam albo kopie kryptowaluty.
Właściciel dowiaduje się o tym zwykle ostatni, bo przekierowania bywają ustawione tylko dla ruchu z wyszukiwarki albo z telefonów, a ktoś, kto wpisuje adres ręcznie na komputerze w biurze, widzi normalną stronę. Pierwszym sygnałem bywa wiadomość od klienta, blokada konta u hostingu albo ostrzeżenie Google. Strony z wykrytym problemem mogą dostać etykietę ostrzegawczą w wynikach wyszukiwania albo pełnoekranowe ostrzeżenie w przeglądarce, co zatrzymuje ruch z dnia na dzień.
Dobrze widać to w zestawieniu OWASP Top 10:2025, gdzie na pierwszych trzech miejscach są błędy kontroli dostępu, błędy konfiguracji i problemy z łańcuchem dostaw oprogramowania, czyli z zależnościami i komponentami pochodzącymi od innych. Na stronie firmowej przekłada się to na konta z za szerokimi uprawnieniami, pliki widoczne publicznie przez pomyłkę i wtyczki, których nikt nie aktualizuje.
Aktualizacje: system, wtyczki i wersja PHP
Aktualizacje to pozycja, która zamyka największą część ryzyka najmniejszym kosztem. W ekosystemie WordPressa, na którym działa duża część stron firmowych, raport Patchstack za 2025 rok przypisuje 91% z 11 334 nowych podatności wtyczkom, a rdzeniowi tylko 6. Szerzej opisaliśmy to w porównaniu WordPressa z headless CMS. Z tego samego raportu wynika rzecz mniej oczywista: dla 46% luk w chwili ujawnienia nie było poprawki. Wtedy nie pomaga przycisk "aktualizuj", tylko wyłączenie wtyczki albo reguła zapory, czyli ktoś musi czytać komunikaty o lukach.
Drugie piętro aktualizacji to środowisko serwera. Każda wersja PHP dostaje dwa lata aktywnego wsparcia i dwa lata wyłącznie poprawek bezpieczeństwa, a potem przestaje być łatana. Stan według oficjalnego harmonogramu PHP wygląda tak:
Wsparcie wersji PHP
| Wersja | Poprawki bezpieczeństwa do | Stan we wrześniu 2026 |
|---|---|---|
| 8.1 i starsze | 31 grudnia 2025 | Bez wsparcia, pilna aktualizacja |
| 8.2 | 31 grudnia 2026 | Tylko poprawki bezpieczeństwa, przejście w tym roku |
| 8.3 | 31 grudnia 2027 | Tylko poprawki bezpieczeństwa |
| 8.4 | 31 grudnia 2028 | Pełne wsparcie |
| 8.5 | 31 grudnia 2029 | Pełne wsparcie |
Wersję PHP sprawdzisz w panelu hostingu. Zmiana to zwykle jedno kliknięcie, ale stara wtyczka albo motyw mogą na nowej wersji przestać działać, dlatego najpierw sprawdza się stronę na kopii testowej.
Trzecie piętro to zależności poza CMS-em: biblioteki JavaScript w nowocześniejszych projektach, obraz systemu na VPS, panel hostingu. Jak przeglądać i aktualizować zależności w projekcie po wdrożeniu, opisaliśmy w tekście o monitoringu i utrzymaniu.
Jest też kategoria, o której zapomina prawie każdy: stare kopie strony. Katalog /stara-strona/ po przeprowadzce, subdomena test. z wersją sprzed dwóch lat, instalacja WordPressa założona "na chwilę" do sprawdzenia motywu. Nikt ich nie aktualizuje, bo nikt o nich nie pamięta, a włamanie przez nie daje dostęp do tego samego serwera co główna strona. Jeśli czegoś nie używasz, usuń to, zamiast chować.
Kopie zapasowe, które przetrwają włamanie
Kopia zapasowa chroni przed awarią dysku, błędem przy aktualizacji i pomyłką redaktora. Przed włamaniem chroni tylko wtedy, gdy spełnia trzy dodatkowe warunki, o których zwykle się nie myśli.
Pierwszy: atakujący nie może jej skasować. Wytyczne CISA dotyczące ransomware wprost ostrzegają, że złośliwe oprogramowanie szuka dostępnych kopii i usuwa je albo szyfruje. Kopia na tym samym serwerze, w katalogu obok strony, znika razem ze stroną. Kopia w zewnętrznym magazynie, do którego serwer ma pełne prawa zapisu i usuwania, też, bo dane dostępowe leżą na serwerze. Serwer powinien móc kopie dopisywać, ale nie kasować, a usuwanie starych kopii powinno odbywać się po stronie magazynu, według reguł ustawionych z innego konta.
Drugi: kopia musi sięgać dalej wstecz niż moment włamania. Między przejęciem strony a jego wykryciem mogą minąć tygodnie. Jeśli trzymasz tylko siedem dziennych kopii, wszystkie mogą zawierać już zainfekowaną stronę. Rozsądny układ to kopie dzienne z ostatnich tygodni plus tygodniowe albo miesięczne z kilku miesięcy wstecz.
Trzeci: kopia u dostawcy hostingu to nie to samo co Twoja kopia. Jest wygodna, ale leży w tej samej infrastrukturze i jest dostępna z tego samego konta. Jeśli przejęte zostanie konto w panelu hostingu, atakujący ma dostęp i do strony, i do jej kopii.
Zasadę 3-2-1 i test odtworzenia bazy opisaliśmy w tekście o utrzymaniu po wdrożeniu. Odtworzenie trzeba przećwiczyć, zanim będzie potrzebne, bo po włamaniu nie ma czasu na naukę narzędzia do kopii.
HTTPS i certyfikat, który odnawia się sam
Certyfikat TLS jest dziś standardem, ale problemy z nim nie zniknęły, tylko zmieniły przyczynę: certyfikat nie jest już kupowany raz na rok, lecz odnawiany automatycznie, a automat potrafi przestać działać po cichu.
Okres ważności certyfikatów skraca się według harmonogramu przyjętego przez CA/Browser Forum w głosowaniu SC-081 w kwietniu 2025 roku. Od 15 marca 2026 roku publicznie zaufany certyfikat TLS może być ważny najwyżej 200 dni, od 15 marca 2027 roku 100 dni, a od 15 marca 2029 roku 47 dni. Ręczne odnawianie certyfikatu przestaje być realną opcją.
Let's Encrypt, bezpłatny urząd certyfikacji, wydaje certyfikaty ważne 90 dni i skraca je dalej: od 13 maja 2026 roku profil tlsserver wydaje certyfikaty 45-dniowe, a domyślny profil przejdzie na 64 dni 10 lutego 2027 roku i na 45 dni 16 lutego 2028 roku. Ważniejsza dla właściciela strony jest inna zmiana: od czerwca 2025 roku Let's Encrypt nie wysyła już maili o wygasających certyfikatach. Jeśli odnawianie przestanie działać, pierwszym sygnałem będzie ostrzeżenie w przeglądarce klienta, chyba że masz własny monitoring.
Datę wygaśnięcia certyfikatu sprawdzisz z terminala jednym poleceniem (zamień firma.pl na swoją domenę):
Wynik ma postać notAfter= i datę. Let's Encrypt zaleca odnawianie po upływie około dwóch trzecich okresu ważności, więc jeśli do wygaśnięcia została wyraźnie mniej niż jedna trzecia tego okresu, odnawianie prawdopodobnie nie działa. To samo sprawdzenie warto wpiąć w monitoring, który ostrzeże z wyprzedzeniem.
Samo HTTPS to nie wszystko. Wejście przez http:// powinno kończyć się przekierowaniem 301 na wersję szyfrowaną, a strona nie powinna ładować żadnych zasobów przez HTTP, bo przeglądarka je zablokuje albo oznaczy stronę jako niezabezpieczoną. Kolejnym krokiem jest nagłówek HSTS, opisany niżej.
Nagłówki bezpieczeństwa: kilka linijek konfiguracji
Nagłówki HTTP to instrukcje, które serwer wysyła przeglądarce razem ze stroną: "łącz się ze mną tylko przez HTTPS", "nie osadzaj mnie w ramce", "nie wykonuj skryptów spoza tej listy". Nie naprawiają błędów w kodzie, ale utrudniają ich wykorzystanie.
Nagłówki, od których warto zacząć
| Nagłówek | Przed czym chroni | Rozsądny start |
|---|---|---|
| Strict-Transport-Security (HSTS) | Połączeniem przez nieszyfrowane HTTP i podsłuchem w publicznej sieci | max-age=31536000; includeSubDomains |
| Content-Security-Policy | Wstrzykniętymi skryptami (XSS), osadzaniem strony w ramkach | Najpierw tryb Report-Only, potem lista dozwolonych źródeł |
| X-Content-Type-Options | Interpretowaniem plików jako innego typu, na przykład obrazka jako skryptu | nosniff |
| Referrer-Policy | Wysyłaniem pełnych adresów podstron do innych serwisów | strict-origin-when-cross-origin |
| Permissions-Policy | Dostępem skryptów do kamery, mikrofonu i lokalizacji | camera=(), microphone=(), geolocation=() |
| X-Frame-Options | Osadzaniem strony w ramce w starszych przeglądarkach | SAMEORIGIN |
Dwie uwagi do tabeli. HSTS działa dopiero po pierwszej wizycie przez HTTPS, bo przeglądarki ignorują ten nagłówek wysłany przez HTTP. Lukę pierwszej wizyty zamyka wpis na listę HSTS preload, ale wymaga to HTTPS na wszystkich subdomenach, a wycofanie się z listy jest powolne i trudne. Na listę zgłaszaj domenę dopiero wtedy, gdy masz pewność, że żadna subdomena, łącznie z tymi od poczty czy starego sklepu, nie potrzebuje HTTP.
Druga uwaga dotyczy nagłówka, którego w tabeli nie ma. X-XSS-Protection nadal pojawia się w poradnikach, ale MDN oznacza go jako przestarzały i ostrzega, że w niektórych przypadkach może sam tworzyć podatności. Zamiast niego stosuje się Content-Security-Policy.
Tak wygląda przykładowa konfiguracja dla nginx:
Parametr always sprawia, że nginx dołącza nagłówek także do stron błędów, a nie tylko do odpowiedzi z kodami sukcesu i przekierowań. Jest też pułapka, która regularnie zostawia strony bez nagłówków: według dokumentacji nginx dyrektywy add_header są dziedziczone z wyższego poziomu konfiguracji tylko wtedy, gdy na bieżącym poziomie nie ma żadnej własnej. Wystarczy, że blok location dla plików statycznych doda nagłówek Cache-Control, a wszystkie nagłówki bezpieczeństwa z poziomu server znikają dla tych plików. Rozwiązaniem jest wspólny plik dołączany przez include w każdym bloku, który ma własne add_header.
Content-Security-Policy wymaga najwięcej pracy, bo musi wymienić wszystkie źródła skryptów, stylów, fontów i ramek, z których korzysta strona, łącznie z analityką i narzędziami marketingowymi. Dlatego zaczyna się od nagłówka Content-Security-Policy-Report-Only: przeglądarka nic nie blokuje, tylko zgłasza naruszenia w konsoli, a z dyrektywą report-to także na wskazany adres. Po kilku dniach z listy naruszeń widać, czego brakuje w polityce, i można przełączyć ją w tryb blokujący.
Efekt sprawdzisz w MDN HTTP Observatory: po wpisaniu adresu dostajesz ocenę i listę brakujących nagłówków z wyjaśnieniem każdego. Na hostingu współdzielonym bez dostępu do konfiguracji nginx część nagłówków ustawia się w pliku .htaccess albo w panelu hostingu.
Formularze: spam, nadużycia i poczta
Przez formularz kontaktowy boty wysyłają spam, testują, czy da się nim rozsyłać maile do dowolnych adresów, i próbują wgrać pliki tam, gdzie formularz przyjmuje załączniki.
Ochronę przed spamem najlepiej budować warstwami, od najmniej uciążliwych dla człowieka:
- Ukryte pole (honeypot). Pole niewidoczne dla człowieka, które boty wypełniają, bo wypełniają wszystko. Wiadomość z wypełnionym polem jest odrzucana.
- Minimalny czas wypełnienia. Formularz wysłany dwie sekundy po załadowaniu strony nie został wypełniony przez człowieka.
- Limit liczby wysłań. Kilka wiadomości z jednego adresu IP w krótkim czasie to sygnał do blokady.
- Walidacja po stronie serwera. Sprawdzanie pól w przeglądarce jest dla wygody użytkownika, a nie dla bezpieczeństwa, bo bot wysyła dane z pominięciem formularza.
- CAPTCHA jako ostatnia warstwa. Cloudflare Turnstile działa bez pokazywania zagadek i nie wymaga przepuszczania ruchu strony przez Cloudflare. reCAPTCHA od Google w darmowym planie Essentials obejmuje do 10 000 weryfikacji miesięcznie na organizację, a po przekroczeniu limitu bez włączonych płatności zwraca błąd. Kod formularza musi mieć na tę sytuację zaplanowane zachowanie, inaczej pod koniec miesiąca formularz przestanie działać albo zacznie przepuszczać wszystko.
Skrypt usługi CAPTCHA przetwarza dane odwiedzających po stronie dostawcy, więc powinien być opisany w polityce prywatności strony.
Druga grupa problemów dotyczy wysyłki maili. Formularz, który wstawia adres podany przez użytkownika do nagłówków wiadomości bez sprawdzenia, pozwala dopisać do niej dodatkowych odbiorców i używać strony jako bramki do spamu. Adres nadawcy powinien być zawsze adresem Twojej domeny, a adres użytkownika może trafić najwyżej do pola "odpowiedz do" po walidacji. Sprawdzone biblioteki pocztowe, takie jak PHPMailer, przez który wysyła maile między innymi WordPress, walidują adresy i chronią przed wstrzykiwaniem nagłówków, więc lepiej z nich korzystać niż składać wiadomość ręcznie.
Wysyłka z formularza musi też przejść przez filtry odbiorcy. Od 1 lutego 2024 roku Gmail wymaga od wszystkich nadawców uwierzytelnienia SPF lub DKIM, a od wysyłających więcej niż 5000 wiadomości dziennie także DMARC. Rekordy SPF, DKIM i DMARC chronią przy okazji Twoją domenę przed podszywaniem się pod nią w mailach phishingowych do Twoich klientów. Bez nich wiadomości wysyłane z formularza mogą trafiać do spamu albo być odrzucane.
Jeśli formularz przyjmuje załączniki, ogranicz typy i rozmiar plików, sprawdzaj typ po zawartości, a nie po rozszerzeniu, i zapisuj pliki poza katalogiem publicznym.
Dostęp do panelu, hostingu i domeny
Najprostsza droga do przejęcia strony nie wymaga żadnej luki, wystarczy hasło.
Każda osoba powinna mieć własne konto, a nie wspólny login "admin" z hasłem przekazywanym w mailach. Pozwala to nadać uprawnienia według potrzeb, sprawdzić, kto co zmienił, i odebrać dostęp jednej osobie. WordPress ma do tego role: redaktor publikuje i edytuje treści, ale nie instaluje wtyczek i nie zmienia ustawień. Konto administratora powinny mieć jedna lub dwie osoby.
Najczęściej zaniedbana czynność to odbieranie dostępu. Były pracownik, poprzednia agencja, freelancer, który dwa lata temu poprawiał formularz: każde z tych kont to otwarte drzwi, a im starsze konto, tym większa szansa, że jego hasło jest w którymś wycieku.
Hasła powinny być długie, a nie skomplikowane. Wytyczne NIST SP 800-63B w wersji z sierpnia 2025 roku wymagają co najmniej 15 znaków dla hasła używanego jako jedyny składnik logowania, zakazują wymuszania kombinacji typów znaków i okresowej zmiany hasła bez powodu, a nakazują sprawdzanie haseł z listą znanych i wyciekłych. W praktyce oznacza to menedżer haseł, unikalne hasło do każdej usługi i logowanie dwuskładnikowe wszędzie, gdzie jest dostępne.
W WordPressie oficjalny poradnik zabezpieczania zaleca dodatkowo wyłączenie edycji plików z panelu stałą DISALLOW_FILE_EDIT, dodatkową ochronę katalogu /wp-admin/ po stronie serwera i ograniczenie uprawnień użytkownika bazy danych do odczytu i zapisu danych.
Panel strony to jednak nie najważniejsze konto. Wyżej stoją te, które pozwalają przejąć wszystko naraz:
- Rejestrator domeny. Kto przejmie domenę, przekieruje stronę i pocztę, gdzie chce.
- DNS. Zmiana jednego rekordu wystarczy, żeby ruch trafiał na cudzy serwer.
- Panel hostingu lub konto w chmurze. Pełny dostęp do plików, bazy i kopii zapasowych.
- Poczta firmowa. Przez reset hasła daje dostęp do wszystkich pozostałych kont.
- Repozytorium kodu, jeśli strona wdraża się z niego automatycznie.
Każde z tych kont powinno być zarejestrowane na firmę, a nie na wykonawcę, mieć logowanie dwuskładnikowe i krótką, znaną listę osób z dostępem. O tym, dlaczego domena i konta muszą być Twoje, pisaliśmy też w tekście o czytaniu wyceny software house'u.
Konfiguracja serwera: pliki, których nikt nie powinien zobaczyć
Błędy konfiguracji z listy OWASP mają na stronach firmowych konkretną postać: pliki, które trafiły do katalogu publicznego przez pomyłkę. Katalog .git z pełną historią kodu, czasem z hasłami zapisanymi w starych wersjach. Plik .env z danymi dostępowymi do bazy i kluczami API. Archiwum backup.zip albo zrzut bazy baza.sql zostawiony po przeprowadzce. Plik phpinfo.php dodany kiedyś do diagnostyki. Kopia wp-config.php.bak po ręcznej edycji.
Automaty sprawdzają te ścieżki na każdej stronie, na którą trafią. Możesz zrobić to samo:
Przy każdej ścieżce powinien pojawić się kod 404 albo 403. Kod 200 oznacza, że plik jest dostępny dla każdego, choć zdarzają się serwery, które na nieistniejące adresy odpowiadają kodem 200 z własną stroną błędu. Jeśli widzisz 200, otwórz adres w przeglądarce i sprawdź, co faktycznie się wyświetla.
Na tej samej liście są listowanie katalogów, czyli serwer pokazujący spis plików w folderze bez strony głównej, oraz komunikaty błędów z pełną ścieżką do plików i fragmentami zapytań do bazy. Jedno i drugie wyłącza się w konfiguracji serwera i aplikacji.
Warto też dodać plik security.txt opisany w RFC 9116. Leży pod adresem /.well-known/security.txt i mówi osobom, które znalazły lukę na Twojej stronie, jak ją zgłosić. Wymagane są dwa pola, a datę w polu Expires RFC zaleca ustawiać na mniej niż rok w przód:
Monitoring: dowiedz się pierwszy
Im dłużej włamanie pozostaje niezauważone, tym więcej kosztuje. Kilka darmowych narzędzi pozwala dowiedzieć się o nim wcześniej niż klienci.
Google Search Console ma raport "Problemy dotyczące bezpieczeństwa", który informuje o wykrytych przejęciach, złośliwym oprogramowaniu i socjotechnice. Działa tylko wtedy, gdy domena jest dodana do Search Console, a powiadomienia trafiają na adres, który ktoś czyta, a nie na skrzynkę wykonawcy sprzed trzech lat.
Monitoring dostępności z zewnątrz powinien sprawdzać nie tylko kod odpowiedzi, ale też obecność konkretnego tekstu na stronie, bo przejęta strona często odpowiada poprawnie, tylko pokazuje coś innego. Do tego monitoring certyfikatu, opisany wyżej, i powiadomienie o każdym nowym koncie administratora w CMS-ie.
Co robić po włamaniu: pierwsze godziny
Pierwszy odruch po odkryciu włamania to sprzątanie: skasować podejrzane pliki, przywrócić kopię i zapomnieć. To błąd, bo bez wiedzy, którędy atakujący wszedł, może wrócić tą samą drogą. Kolejność ma znaczenie:
Zanim cokolwiek usuniesz, zrób kopię obecnego stanu: plików, bazy i logów serwera. Logi są rotowane i po kilku dniach mogą zniknąć, a tylko z nich wynika, którędy przyszedł atak.
Jeśli strona rozsyła złośliwe oprogramowanie albo przekierowuje klientów na oszustwa, włącz stronę serwisową albo zablokuj ruch. Powiadom dostawcę hostingu, bo przejęty serwer mógł atakować też innych.
Z czystego urządzenia: konta w CMS-ie, panel hostingu, FTP, SSH, hasło do bazy, klucze API do płatności i wysyłki maili, rejestrator domeny, poczta. W WordPressie wygeneruj też nowe klucze i sole w wp-config.php, co wyloguje wszystkie sesje.
Przejrzyj logi pod kątem nietypowych żądań do plików PHP, daty modyfikacji plików i listę wtyczek pod kątem znanych luk. Bez tego kroku sprzątanie jest tymczasowe.
Przywróć kopię sprzed włamania albo zainstaluj system i wtyczki od nowa z oficjalnych źródeł, przenosząc tylko sprawdzoną treść. Ręczne czyszczenie pojedynczych plików rzadko znajduje wszystko.
Nowe konta administratorów, zadania cykliczne, pliki PHP w katalogu z obrazami, zmiany w .htaccess, przekierowania działające tylko dla ruchu z Google albo z telefonów.
Zaktualizuj albo usuń podatny element, a potem przywróć stronę. W Search Console użyj przycisku "Poproś o sprawdzenie" i opisz, co zrobiłeś. Według Google weryfikacja trwa od kilku dni do kilku tygodni.
Przy sklepie albo stronie z kontami klientów warto od razu zaangażować kogoś, kto robił to wcześniej. Incydent można też zgłosić do CERT Polska przez incydent.cert.pl.
Wyciek danych osobowych: obowiązki z RODO
Formularz kontaktowy, konta klientów, zamówienia, lista subskrybentów newslettera: prawie każda strona firmowa przetwarza dane osobowe, a firma jest ich administratorem. Włamanie, w którym atakujący mógł te dane odczytać, zmienić albo usunąć, jest naruszeniem ochrony danych osobowych w rozumieniu RODO.
Zgodnie z art. 33 RODO administrator zgłasza naruszenie organowi nadzorczemu, w Polsce Prezesowi UODO, bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny po jego stwierdzeniu. Zgłoszenia nie trzeba składać, jeśli jest mało prawdopodobne, by naruszenie powodowało ryzyko dla praw lub wolności osób, których dane dotyczą. Każde naruszenie, także niezgłoszone, administrator dokumentuje. Jeśli ryzyko jest wysokie, art. 34 nakazuje zawiadomić także same osoby, których dane wyciekły.
Termin 72 godzin biegnie od stwierdzenia naruszenia, a nie od jego wystąpienia. Zgłoszenie po terminie jest możliwe, ale trzeba do niego dołączyć wyjaśnienie przyczyn opóźnienia. UODO przyjmuje zgłoszenia elektronicznie przez formularz na platformie biznes.gov.pl. Jeśli stronę utrzymuje zewnętrzna firma, która przetwarza dane w Twoim imieniu, ma ona obowiązek bez zbędnej zwłoki powiadomić Ciebie, gdy dowie się o naruszeniu, ale zgłoszenie do UODO pozostaje Twoim obowiązkiem.
Art. 32 wymaga z kolei środków bezpieczeństwa dobranych do ryzyka, w tym zdolności do szybkiego przywrócenia dostępności danych po incydencie i regularnego testowania zabezpieczeń. Przetestowana kopia zapasowa i aktualizowany system są więc także wymogiem prawnym. Ta sekcja nie zastępuje porady prawnej, a przy poważnym wycieku warto ją uzyskać od razu.
Bezpieczeństwo strony firmowej: lista kontrolna na jedno popołudnie
Większość punktów z tego tekstu sprawdzisz sam, bez dostępu do kodu. Tabela zbiera je w kolejności od najważniejszych:
Lista kontrolna bezpieczeństwa strony
| Co sprawdzić | Jak | Jak często |
|---|---|---|
| Wersja PHP i aktualizacje CMS-a oraz wtyczek | Panel hostingu i panel CMS-a | Co miesiąc |
| Nieużywane wtyczki, motywy i stare kopie strony | Lista wtyczek, katalogi i subdomeny na serwerze | Co kwartał |
| Kopia zapasowa poza serwerem | Ostatnia data kopii i próba odtworzenia | Odtworzenie co kwartał |
| Data wygaśnięcia certyfikatu | Polecenie openssl albo monitoring | Automatycznie, codziennie |
| Przekierowanie z HTTP na HTTPS | Wejście na adres z http:// | Po każdej zmianie serwera |
| Nagłówki bezpieczeństwa | MDN HTTP Observatory | Po każdej zmianie konfiguracji |
| Pliki widoczne publicznie | Skrypt z curl | Co kwartał |
| Lista kont z dostępem do CMS-a, hostingu, domeny i DNS | Przegląd kont w każdej usłudze | Co kwartał i przy każdej zmianie w zespole |
| Logowanie dwuskładnikowe na kluczowych kontach | Ustawienia bezpieczeństwa każdego konta | Raz, potem przy nowych kontach |
| SPF, DKIM i DMARC dla domeny | Nagłówki wiadomości z formularza w skrzynce odbiorcy | Po każdej zmianie poczty |
| Powiadomienia z Search Console | Kto je dostaje i czy je czyta | Raz w roku |
Najczęściej zadawane pytania
Czy mała strona firmowa naprawdę może zostać zhakowana?
Tak. Automaty nie wybierają firm, tylko sprawdzają wszystkie adresy po kolei pod kątem znanych luk, a małe strony są rzadziej aktualizowane. Dla atakującego liczy się domena i serwer, a nie liczba odwiedzin.
Jak sprawdzić, czy moja strona została zhakowana?
Sprawdź raport "Problemy dotyczące bezpieczeństwa" w Google Search Console, wyszukaj w Google site:twojadomena.pl i poszukaj podstron, których nie tworzyłeś, otwórz stronę z telefonu przez wynik wyszukiwania, a nie wpisując adres, i przejrzyj listę kont administratorów w CMS-ie. Nieznane konto administratora to niemal pewny sygnał włamania.
Czy darmowy certyfikat SSL jest gorszy od płatnego?
Nie pod względem szyfrowania, które jest takie samo. Płatne certyfikaty typu OV i EV dodatkowo potwierdzają dane firmy, ale współczesne przeglądarki nie wyróżniają ich w pasku adresu. Dla typowej strony firmowej darmowy certyfikat z automatycznym odnawianiem jest właściwym wyborem.
Czy wtyczka bezpieczeństwa wystarczy?
Nie. Wtyczka może ograniczać próby logowania, skanować pliki i blokować część znanych ataków, ale nie zrobi kopii zapasowej poza serwerem, nie zaktualizuje PHP, nie odbierze dostępu byłemu pracownikowi i nie zabezpieczy konta u rejestratora domeny. Jest jedną z warstw, a nie zamiennikiem pozostałych.
Czy po włamaniu zawsze trzeba zgłaszać naruszenie do UODO?
Nie zawsze. Obowiązek nie powstaje, jeśli jest mało prawdopodobne, by naruszenie powodowało ryzyko dla praw lub wolności osób, na przykład gdy atakujący nie miał dostępu do żadnych danych osobowych. Decyzję i jej uzasadnienie trzeba jednak udokumentować, a przy wątpliwościach lepiej skonsultować ją z prawnikiem w ciągu tych 72 godzin, a nie po nich.
Zacznij od listy, nie od narzędzia
Bezpieczeństwo strony firmowej rzadko wymaga drogiego oprogramowania, za to wymaga osoby odpowiedzialnej za listę kontrolną z tego tekstu. Jeśli w firmie jej nie ma, najważniejszą decyzją jest ustalenie, kto nią będzie: pracownik, wykonawca strony czy firma zajmująca się utrzymaniem.
Jeśli chcesz, żebyśmy przeszli tę listę na Twojej stronie albo zaplanowali zabezpieczenia nowego projektu od początku, napisz przez formularz kontaktowy. Wycena jest bezpłatna. Nasze podejście do jakości kodu widać też w projektach open source, do których kontrybuujemy, w tym w PHPMailerze; opisaliśmy je na stronie o open source. Zakres naszych usług znajdziesz na stronie z ofertami.
