Aktualizacje bezpieczeństwa serwera: ile kosztuje ich brak

Atak nie potrzebuje nowej dziury, wystarczy stara

Amerykańska agencja CISA prowadzi publiczny katalog luk wykorzystywanych w rzeczywistych atakach (Known Exploited Vulnerabilities), z ponad 1700 pozycjami i osobnym oznaczeniem tych używanych w kampaniach ransomware. Każda z tych luk ma dostępną poprawkę, często od miesięcy albo lat: katalog opisuje nie nieznane dziury, ale te, które producent już naprawił, a mimo to wciąż skutecznie się nimi atakuje serwery, które poprawki nie dostały.

Dla małej firmy to oznacza, że serwer nie musi być celowo wybranym celem, żeby ucierpieć. Wystarczy, że jest widoczny w internecie i ma nieaktualizowaną usługę, którą skanowanie znajdzie przy przeszukiwaniu całej sieci adresów IP, niezależnie od tego, czy atakujący w ogóle wie, że ta firma istnieje.

RODO liczy czas w godzinach, nie w dniach

Konsekwencja rzadko ogranicza się do samego ataku. Ransomware, który szyfruje bazę danych i pliki, zatrzymuje sklep albo system rezerwacji na czas, zanim ktoś odtworzy dane z kopii zapasowej, a godzina przestoju sklepu internetowego kosztuje inaczej niż godzina przestoju wewnętrznego narzędzia firmy. Do tego dochodzi czas na zgłoszenia i wyjaśnienia wobec klientów, których dane mogły wyciekić, niezależnie od tego, czy ostatecznie doszło do nadużycia.

Jeśli do wycieku dojdzie, a serwer przetwarza dane osobowe klientów, pracowników albo zamówień, art. 33 RODO każe zgłosić naruszenie do UODO bez zbędnej zwłoki, a jeśli to możliwe, w ciągu 72 godzin od jego stwierdzenia. Zgłoszenie po tym terminie wymaga dodatkowo wyjaśnienia przyczyn zwłoki. Jeśli naruszenie może powodować wysokie ryzyko dla osób, których dane wyciekły, art. 34 nakłada obowiązek poinformowania ich samych, nie tylko urzędu.

72 godziny liczy się od chwili, w której firma dowiedziała się o wycieku, nie od chwili samego ataku. Serwer bez monitoringu, na którym nikt nie przegląda logów, bywa źródłem tej różnicy: włamanie trwające tygodniami wykrywa się dopiero wtedy, gdy ktoś zgłosi podejrzaną aktywność z zewnątrz, a to nie zwalnia z liczenia terminu od dnia faktycznego wykrycia.

Oprogramowanie bez wsparcia nie ostrzega przed sobą

Systemy operacyjne i biblioteki mają daty końca wsparcia, po których producent przestaje wydawać poprawki bezpieczeństwa, nawet jeśli nowe luki są odkrywane dalej. Ubuntu 20.04 LTS, popularny wybór dla serwerów stawianych kilka lat temu, przestał otrzymywać standardowe wsparcie bezpieczeństwa 31 maja 2025 roku. Serwer, który od tego dnia nie przeszedł aktualizacji systemu, działa już ponad rok na fundamencie, którego nikt nie naprawia, nawet jeśli nowe luki w tym czasie się znalazły.

Przejście na nowszą wersję systemu rzadko jest jedną czynnością wykonaną od ręki: zależy od zgodności wszystkich usług na serwerze i wymaga testu przed przełączeniem produkcji, nie w trakcie niego. Im dłużej serwer stoi na wersji po końcu wsparcia, tym większy staje się ten krok i tym trudniej zaplanować go bez przestoju.

Aktualizacja bez planu powrotu bywa gorsza niż jej brak

Świadomość, że trzeba aktualizować, nie wystarcza. Aktualizacja wykonana na produkcyjnym serwerze bez wcześniejszego testu i bez możliwości powrotu do poprzedniej wersji potrafi wywołać przestój dłuższy niż ten, przed którym miała chronić. Baza danych, która nie podnosi się po aktualizacji silnika, albo usługa, która przestaje działać po uaktualnieniu zależności, kosztują firmę tyle samo niezależnie od tego, czy przyczyną był atak czy własna łatka.

Aktualizacje bezpieczeństwa mają sens tylko razem z kopią poprzedniej wersji i sposobem na szybki do niej powrót: inaczej firma zamienia jedno ryzyko, znaną lukę, na drugie, nieprzewidzianą awarię własnej aktualizacji. O tym, co musi działać w samych kopiach zapasowych, piszemy w osobnym artykule.

Sprawdź swój serwer

• Czy ktoś wie, jaką wersję systemu operacyjnego i jakie wersje kluczowych usług ma serwer, i kiedy kończy się dla nich wsparcie bezpieczeństwa.
• Czy aktualizacje bezpieczeństwa trafiają na serwer regularnie, nie tylko wtedy, gdy coś już nie działa.
• Czy każda aktualizacja jest wcześniej testowana poza produkcją i ma zaplanowaną drogę powrotu, jeśli coś pójdzie nie tak.
• Czy ktoś monitoruje logi i dostępność serwera na bieżąco, żeby wykryć atak w godzinach, nie po tygodniach.
• Czy firma wie, kogo i w jakim terminie trzeba poinformować, jeśli faktycznie dojdzie do wycieku danych.

Co przejmujemy

Aktualizacje bezpieczeństwa przejmujemy w ramach utrzymania serwerów: śledzimy, kiedy kończy się wsparcie dla systemu i usług na serwerze, testujemy aktualizacje poza produkcją i wdrażamy je z możliwością powrotu do poprzedniej wersji, razem z monitoringiem dostępności, który pokazuje awarię, zanim zgłosi ją klient. Zadzwoń pod 697 004 905 albo napisz na kontakt@apkarze.pl. Sprawdzimy, jak aktualny jest Twój serwer.