Jak odebrać zabezpieczenia strony internetowej? Checklista dla firmy
Zabezpieczeń strony nie da się odebrać jednym pytaniem: „czy witryna jest bezpieczna?”. Nie istnieje rozwiązanie gwarantujące brak incydentów. Można natomiast sprawdzić, czy ograniczono typowe ryzyka, ustalono odpowiedzialność i przygotowano sposób reakcji na awarię lub naruszenie.
Poniższa checklista jest przeznaczona dla właściciela firmy odbierającego nową stronę albo przejmującego istniejący serwis. Uzupełnia ogólny poradnik jak zabezpieczyć stronę przed atakami. Tutaj skupiamy się na dowodach, dostępach i dokumentach, które warto otrzymać od wykonawcy.
1. Lista systemów i osób odpowiedzialnych
Na początku trzeba wiedzieć, z jakich elementów składa się usługa i kto odpowiada za każdy z nich. Sama administracja WordPressem nie obejmuje automatycznie serwera, domeny, poczty, usług DNS, płatności, zewnętrznych integracji ani kont reklamowych.
Dokument odbiorowy powinien wskazywać co najmniej:
- operatora domeny, DNS i hostingu,
- system CMS, aktywny motyw oraz istotne wtyczki,
- usługi zewnętrzne połączone ze stroną,
- właściciela każdego konta i osobę odpowiedzialną za jego utrzymanie,
- licencje, terminy ich odnowienia i sposób rozliczania,
- zakres odpowiedzialności wykonawcy po publikacji.
Jeżeli odpowiedzialność jest podzielona między firmę, hosting i wykonawcę, warto zapisać również sposób zgłaszania problemów. Dzięki temu w sytuacji awaryjnej nie traci się czasu na ustalanie, kto ma dostęp do właściwego systemu.
2. Konta, role i uwierzytelnianie
Każda osoba administrująca stroną powinna mieć własne konto. Wspólne konto zespołowe utrudnia odebranie dostępu po zakończeniu współpracy i nie pozwala wiarygodnie ustalić autora zmiany.
Przy odbiorze sprawdź:
- czy konta mają tylko uprawnienia potrzebne do wykonywanej pracy,
- czy nie pozostały aktywne konta byłych wykonawców lub pracowników,
- czy administratorzy korzystają z unikalnych haseł przechowywanych w menedżerze haseł,
- czy włączono uwierzytelnianie dwuskładnikowe tam, gdzie jest dostępne — szczególnie dla hostingu, domeny, poczty i kont administratorów,
- czy sposób przekazania dostępów nie wymaga wysyłania haseł zwykłym formularzem lub w nieszyfrowanej wiadomości.
Po odbiorze strona powinna pozostać pod kontrolą firmy. Właściciel nie musi wykonywać codziennych prac technicznych, ale powinien mieć możliwość odzyskania dostępu do domeny, hostingu i strony.
3. Aktualizacje bez pracy bezpośrednio na produkcji
Aktualizowanie WordPressa, motywu i wtyczek ogranicza ryzyko związane ze znanymi podatnościami. Sama informacja „włączono aktualizacje” nie opisuje jednak całego procesu. Zmiana może wpłynąć na formularze, płatności, integracje lub wygląd strony.
Ustal z wykonawcą:
- kto śledzi dostępność aktualizacji i komunikaty bezpieczeństwa,
- które zmiany mogą być wykonywane automatycznie, a które wymagają testu,
- czy przed większą zmianą powstaje aktualna kopia,
- jak sprawdzane są kluczowe ścieżki po aktualizacji,
- jak wygląda powrót do poprzedniej wersji, jeśli zmiana spowoduje błąd.
Nieaktywne, niepotrzebne rozszerzenia powinny zostać usunięte po upewnieniu się, że nie są wykorzystywane. Nowe wtyczki należy dobierać ze znanych źródeł, sprawdzając ich utrzymanie, zgodność i rzeczywistą potrzebę instalacji.
4. Kopie zapasowe i test odtwarzania
Kopia zapasowa powinna obejmować bazę danych oraz pliki potrzebne do odtworzenia serwisu. Ważne są nie tylko częstotliwość i okres przechowywania, lecz także miejsce zapisu oraz możliwość przywrócenia.
Przy odbiorze poproś o odpowiedzi na pytania:
- co dokładnie jest kopiowane i jak często,
- jak długo przechowywane są kolejne wersje,
- czy co najmniej jedna kopia jest oddzielona od głównej instalacji,
- kto może rozpocząć odtwarzanie i jaki jest sposób autoryzacji,
- kiedy ostatnio wykonano kontrolny test odtworzenia.
Samo pojawienie się pliku kopii nie dowodzi, że można z niego skutecznie odtworzyć stronę. Test odtwarzania powinien odbywać się w kontrolowanym środowisku, bez nadpisywania działającej produkcji.
5. HTTPS, domena i warstwa serwerowa
Strona powinna działać przez HTTPS, a przekierowanie z HTTP prowadzić bezpośrednio do właściwego adresu. Certyfikat TLS chroni transmisję między przeglądarką a serwerem, ale nie usuwa błędów aplikacji i nie zastępuje aktualizacji.
Sprawdź również:
- kto odpowiada za automatyczne odnowienie certyfikatu,
- czy domena i hosting są przypisane do kont kontrolowanych przez firmę,
- czy serwer używa wspieranych wersji oprogramowania,
- czy dostęp do panelu hostingowego i DNS jest objęty dodatkowym uwierzytelnianiem,
- czy środowisko testowe nie jest indeksowane i nie udostępnia publicznie kopii danych produkcyjnych.
6. Formularze, dane i integracje
Formularz powinien zbierać tylko dane potrzebne do obsługi konkretnego celu. Trzeba sprawdzić zarówno komunikat dla użytkownika, jak i techniczne przekazanie zgłoszenia.
Odbiór formularza powinien obejmować:
- walidację wymaganych pól po stronie przeglądarki i serwera,
- ochronę przed automatycznym spamem bez blokowania zwykłego użytkownika,
- jednoznaczny komunikat po skutecznym zapisie,
- kontrolę, czy zgłoszenie trafia do właściwej skrzynki lub systemu,
- brak haseł, kluczy API i treści wiadomości w narzędziu analitycznym,
- ustalony okres przechowywania danych i zakres dostępu pracowników.
Jeżeli strona korzysta z płatności, systemu rezerwacji, CRM lub innych usług, każdą integrację trzeba odebrać oddzielnym scenariuszem. Samo załadowanie widżetu nie potwierdza poprawnego zakończenia procesu.
7. Monitoring, logi i procedura awaryjna
Monitoring powinien informować o istotnych problemach, takich jak brak dostępności strony, błędy kluczowych procesów lub wygaśnięcie certyfikatu. Logi pomagają ustalić, co się wydarzyło, ale nie powinny niepotrzebnie przechowywać haseł, tokenów, pełnych danych formularza ani identyfikatorów sesji.
Firma powinna znać odpowiedzi na cztery pytania:
- Gdzie zgłosić podejrzenie incydentu?
- Kto może odłączyć integrację, zablokować konto lub przełączyć stronę w tryb awaryjny?
- Gdzie znajdują się kopie oraz dane potrzebne do analizy?
- Kto podejmuje decyzję o ponownym uruchomieniu serwisu?
Po incydencie nie wystarczy przywrócić kopii. Trzeba także usunąć przyczynę naruszenia, zmienić zagrożone dane dostępowe i sprawdzić, czy nie utworzono nieautoryzowanych kont lub plików.
8. Dokument odbioru zabezpieczeń
Na zakończenie warto zebrać ustalenia w krótkim protokole. Nie musi to być rozbudowana dokumentacja techniczna. Powinien jednak wskazywać:
- datę i wersję odbieranej strony,
- listę sprawdzonych elementów i wynik testu,
- znane ograniczenia oraz ryzyka pozostawione świadomie,
- osoby odpowiedzialne za domenę, hosting, aplikację, kopie i aktualizacje,
- sposób zgłaszania awarii i krytycznych zmian,
- zakres dalszej opieki albo informację, że utrzymanie przejmuje klient.
Taki dokument nie jest gwarancją braku ataków. Jest dowodem, że ustalono kontrolę nad systemem, sposób ograniczania ryzyka oraz reakcję na problem.
Checklista do szybkiego odbioru
- Firma kontroluje domenę, hosting i główne konta.
- Każdy administrator ma własne konto oraz właściwą rolę.
- Włączono dodatkowe uwierzytelnianie tam, gdzie jest dostępne.
- Jest aktualna lista wtyczek, integracji i licencji.
- Ustalono proces aktualizacji, testów i wycofania zmiany.
- Kopie obejmują pliki i bazę, a odtworzenie zostało sprawdzone.
- HTTPS działa, a odpowiedzialność za certyfikat jest przypisana.
- Formularze i integracje przeszły scenariusz skuteczny oraz błędny.
- Monitoring i logi nie przechowują zbędnych danych wrażliwych.
- Istnieje kontakt i procedura na wypadek incydentu.
Jeżeli potrzebują Państwo stałego utrzymania działającej witryny, zakres aktualizacji, kopii, monitoringu i rozwoju opisujemy na stronie opieka WordPress i WooCommerce. Przed rozpoczęciem pracy ustalamy odpowiedzialność oraz sposób bezpiecznego przekazania dostępów. Haseł i kluczy API nie należy przesyłać przez formularz kontaktowy.
