Podstawowe zabezpieczenia — SSL, aktualizacje, kopie zapasowe — to punkt wyjścia, nie cel sam w sobie. Dla strony czy aplikacji firmowej klasy enterprise to za mało. Prawdziwe ryzyko leży gdzie indziej: w niezaktualizowanych zależnościach w kodzie, w brakującej kontroli dostępu, w braku planu na wypadek incydentu. Poniżej checklist, który faktycznie odpowiada realnym zagrożeniom, nie tylko podstawom.
Warstwa infrastruktury
- Certyfikat SSL/TLS na całej domenie, nie tylko na stronie logowania. Sprawdźcie, czy żadna podstrona nie ładuje się po HTTP.
- Web Application Firewall (WAF) przed aplikacją. Filtruje najbardziej oczywiste ataki, zanim dotrą do samej aplikacji.
- Ochrona przed atakami DDoS na poziomie dostawcy hostingu lub CDN. Dla firmy, dla której strona generuje realny biznes, przestój z powodu ataku to bezpośrednia strata.
- Nagłówek Content Security Policy (CSP) skonfigurowany na serwerze. Określa, skąd przeglądarka może pobierać skrypty i zasoby — utrudnia ataki typu XSS.
Warstwa aplikacji i kodu
- Regularny audyt zależności (npm audit, Dependabot lub podobne narzędzie). Aplikacja webowa opiera się na dziesiątkach zewnętrznych bibliotek. Każda z nich to potencjalna luka, jeśli nie jest aktualizowana.
- Walidacja i filtrowanie każdego pola wejściowego, które użytkownik wypełnia. To podstawa ochrony przed SQL injection i XSS, ale wciąż jedna z najczęściej pomijanych rzeczy.
- Zgodność z OWASP Top 10 jako minimalny standard. Pisaliśmy już o metodyce OWASP przy okazji zabezpieczania WordPressa — te same zasady dotyczą każdej aplikacji, nie tylko WordPressa.
- Architektura headless jako dodatkowa warstwa ochrony, jeśli to możliwe. Rozdzielenie frontendu od backendu i bazy danych zmniejsza powierzchnię ataku — pisaliśmy o tym szerzej w artykule o headless commerce.
Kontrola dostępu
- Uwierzytelnianie dwuskładnikowe (2FA) dla każdego konta z dostępem administracyjnym. Bez wyjątków, nawet dla kont używanych rzadko.
- Zasada minimalnych uprawnień. Każdy pracownik i każdy system zewnętrzny dostaje tylko taki dostęp, jaki faktycznie potrzebuje — nie więcej.
- Regularny przegląd aktywnych kont. Konto byłego pracownika lub nieużywanej integracji to otwarta furtka, o której łatwo zapomnieć.
- Ograniczenie adresów IP przy dostępie do panelu administracyjnego i serwera, tam gdzie to możliwe.
Monitoring i reakcja na incydenty
- Automatyczne kopie zapasowe, testowane regularnie pod kątem realnego przywrócenia — nie tylko samego istnienia pliku backupu.
- Monitoring nietypowej aktywności na serwerze i w aplikacji, z alertami w czasie rzeczywistym.
- Spisany plan reakcji na incydent, znany zespołowi zanim będzie potrzebny. Kto zmienia hasła, kto zgłasza incydent, kto informuje klientów — to musi być ustalone wcześniej, nie improwizowane w kryzysie.
- Kontakt do CERT Polska (cert@cert.pl) przygotowany na wypadek poważnego ataku.
Zgodność z przepisami
- Znajomość obowiązku zgłoszenia naruszenia danych osobowych do UODO w ciągu 72 godzin od wykrycia incydentu, zgodnie z RODO.
- Regularny audyt bezpieczeństwa, najlepiej przez zewnętrzny zespół, niezależny od tego, kto na co dzień rozwija aplikację. Świeże spojrzenie wychwytuje rzeczy, które łatwo przeoczyć przy codziennej pracy nad tym samym kodem.
Dlaczego sama checklista nie wystarczy
Każdy z powyższych punktów da się wdrożyć osobno. Prawdziwe bezpieczeństwo wymaga jednak czegoś więcej — traktowania go jako proces ciągły, nie jednorazowy projekt. Zagrożenia zmieniają się co miesiąc. Nowe luki w popularnych bibliotekach pojawiają się regularnie. Checklist wykonany raz, przy starcie projektu, traci wartość po kilku miesiącach, jeśli nikt go nie powtarza.
Przykład z praktyki (Klient S, portal B2B dla branży dystrybucyjnej — przykład poglądowy, dane uśrednione dla tej skali projektu)
Firma miała wdrożone podstawowe zabezpieczenia — SSL, regularne kopie zapasowe, aktualny CMS. Mimo to doszło do próby ataku przez nieaktualną zależność w jednej z bibliotek frontendowych, która nie była częścią rutynowego audytu. Atak został wykryty dzięki monitoringowi nietypowej aktywności, zanim doszło do wycieku danych.
Po incydencie firma wdrożyła regularny, zautomatyzowany audyt zależności oraz spisany plan reakcji na incydent. Koszt wdrożenia tych dwóch elementów był niewielki w porównaniu do potencjalnych strat, jakie mógłby wygenerować udany atak na system przechowujący dane kontrahentów.
FAQ
Czy sam certyfikat SSL wystarczy do zabezpieczenia strony firmowej? Nie. SSL szyfruje połączenie, ale nie chroni przed lukami w kodzie, atakami DDoS, ani nieautoryzowanym dostępem. To jeden z wielu elementów, nie kompletne rozwiązanie.
Jak często należy przeprowadzać audyt bezpieczeństwa strony? Regularnie, najlepiej co najmniej raz w roku, oraz dodatkowo po każdej większej zmianie w aplikacji (nowa integracja, migracja, przebudowa). Zagrożenia i zależności zmieniają się szybciej niż większość firm aktualizuje swoje procedury.
Czym różni się zwykła aktualizacja wtyczek od pełnego audytu bezpieczeństwa? Aktualizacja wtyczek to jeden, wąski element. Pełny audyt obejmuje też kontrolę dostępu, konfigurację serwera, plan reakcji na incydent i zgodność z RODO — czyli znacznie szerszy zakres niż sama warstwa oprogramowania.
Ile czasu firma ma na zgłoszenie naruszenia danych osobowych? 72 godziny od momentu wykrycia incydentu, zgodnie z RODO. Zgłoszenie kieruje się do UODO, a w przypadku naruszenia praw osób, których dane dotyczą, trzeba poinformować też te osoby.
Czy architektura headless jest bezpieczniejsza niż tradycyjny CMS? Może być, bo rozdziela frontend od backendu i bazy danych, co zmniejsza powierzchnię ataku. To jednak jeden element większej układanki, nie samodzielne rozwiązanie problemu bezpieczeństwa.
Nie macie pewności, czy Wasza strona lub aplikacja jest zabezpieczona zgodnie z aktualnymi standardami? Umówcie bezpłatną konsultację przez formularz szybkiej wyceny — sprawdzimy Waszą obecną konfigurację względem tej checklisty i pokażemy, co wymaga uwagi.
