Wiele ofert hostingowych wykorzystuje hasła takie jak:
- bezpieczny serwer,
- ochrona przed atakami,
- automatyczny SSL,
- zaawansowane zabezpieczenia.
Dla właściciela firmy może to brzmieć jak gwarancja, że strona jest chroniona od momentu uruchomienia hostingu.
W praktyce bezpieczeństwo strony nie zależy od jednej funkcji ani pojedynczej wtyczki.
Składają się na nie:
- konfiguracja serwera,
- aktualizacje systemu,
- aktualność strony,
- bezpieczne logowanie,
- ograniczone uprawnienia,
- regularne kopie,
- monitoring,
- szybka reakcja na podejrzane zdarzenia.
Hosting może zabezpieczać infrastrukturę, a jednocześnie strona może posiadać podatną wtyczkę, słabe hasło albo publicznie dostępny panel administracyjny.
Dlatego bezpieczny hosting dla firmy powinien być traktowany jako część całego systemu ochrony strony.
Czy hosting może całkowicie zabezpieczyć stronę?
Nie.
Dobry operator może chronić serwer fizyczny, system i część usług. Może stosować zapory, izolację kont, aktualizacje oraz mechanizmy ograniczające ataki.
Nie ma jednak pełnej kontroli nad:
- hasłami użytkowników,
- zainstalowanymi wtyczkami,
- kodem aplikacji,
- konfiguracją formularzy,
- kontami administratorów,
- sposobem przesyłania danych,
- błędami wykonawcy.
Jeżeli strona WordPress posiada nieaktualną wtyczkę z podatnością, sam hosting nie zawsze będzie w stanie zatrzymać jej wykorzystanie.
Jeżeli administrator używa hasła `admin123`, nawet najlepsza infrastruktura nie zastąpi prawidłowego zarządzania dostępem.
Bezpieczeństwo powinno działać warstwowo.
Awaria albo błąd jednej warstwy nie powinny od razu prowadzić do przejęcia całej strony.
Co może grozić stronie firmowej?
Najczęstsze zagrożenia to:
- przejęcie konta administratora,
- wykorzystanie podatnej wtyczki,
- infekcja złośliwym kodem,
- podmiana treści,
- wysyłka spamu,
- kradzież danych,
- przeciążenie strony,
- usunięcie plików,
- zaszyfrowanie danych,
- przejęcie domeny,
- błędna konfiguracja serwera.
Ataki nie dotyczą wyłącznie dużych sklepów i znanych marek.
Automatyczne boty skanują tysiące stron, szukając:
- popularnych paneli logowania,
- przestarzałych systemów,
- otwartych portów,
- publicznych baz danych,
- słabych haseł,
- znanych podatności.
Mała strona lokalnej firmy może zostać zaatakowana nie dlatego, że ktoś specjalnie ją wybrał, ale dlatego, że automat wykrył łatwy cel.
Certyfikat SSL to podstawa, ale nie pełne zabezpieczenie
SSL szyfruje połączenie pomiędzy użytkownikiem a stroną.
Chroni przesyłane dane przed prostym podsłuchaniem podczas transmisji.
Jest niezbędny przy:
- formularzach,
- logowaniu,
- płatnościach,
- panelach klientów,
- przesyłaniu danych osobowych.
Certyfikat nie chroni jednak przed:
- błędami w kodzie,
- nieaktualną wtyczką,
- słabym hasłem,
- infekcją plików,
- przejęciem konta,
- nieprawidłowymi uprawnieniami.
Strona może posiadać zieloną kłódkę i jednocześnie być zainfekowana.
SSL potwierdza bezpieczne połączenie z serwerem. Nie potwierdza, że sama aplikacja jest wolna od zagrożeń.
Regularne aktualizacje
Jednym z najważniejszych elementów bezpieczeństwa są aktualizacje.
Dotyczą one:
- systemu operacyjnego,
- serwera WWW,
- PHP,
- Node.js,
- WordPressa,
- WooCommerce,
- wtyczek,
- motywów,
- bibliotek aplikacji.
Aktualizacje często usuwają znane podatności.
Jeżeli poprawka została opublikowana, informacje o wcześniejszym błędzie mogą stać się powszechnie dostępne. Automatyczne narzędzia zaczynają wtedy szukać stron, które nadal korzystają ze starej wersji.
Nie oznacza to jednak, że należy bez kontroli aktualizować wszystko na aktywnej stronie.
Bezpieczny proces powinien obejmować:
1. wykonanie kopii,
2. sprawdzenie zakresu aktualizacji,
3. wdrożenie zmiany,
4. test strony,
5. sprawdzenie formularzy, sklepu lub aplikacji,
6. możliwość wycofania aktualizacji.
Więcej o bezpiecznym utrzymaniu WordPressa opisaliśmy w artykule [hosting WordPress z opieką – co powinien obejmować](/blog/hosting-wordpress-z-opieka-co-powinien-obejmowac).
Usuń nieużywane wtyczki i moduły
Nieużywany komponent nadal może stanowić zagrożenie.
Dotyczy to szczególnie:
- starych wtyczek WordPressa,
- nieaktywnych motywów,
- paneli testowych,
- porzuconych aplikacji,
- nieużywanych kont FTP,
- pozostawionych kopii strony.
Każdy dodatkowy moduł zwiększa powierzchnię ataku.
Jeżeli strona nie korzysta z określonej wtyczki, lepiej ją usunąć niż pozostawić wyłączoną przez kilka lat.
Trzeba również kontrolować, czy używane dodatki:
- są nadal rozwijane,
- otrzymują aktualizacje,
- pochodzą z zaufanego źródła,
- są rzeczywiście potrzebne.
Bezpieczeństwo często poprawia się poprzez uproszczenie systemu.
Bezpieczne hasła
Hasło powinno być:
- długie,
- unikalne,
- trudne do odgadnięcia,
- nieużywane w innych usługach.
Nie powinno zawierać:
- nazwy firmy,
- prostego ciągu liczb,
- roku urodzenia,
- nazwy domeny,
- oczywistych słów.
Przejęcie jednego hasła może dać atakującemu dostęp do:
- panelu strony,
- hostingu,
- poczty,
- domeny,
- kopii,
- serwera.
Dlatego każdy system powinien posiadać inne dane logowania.
Warto korzystać z menedżera haseł zamiast przechowywania danych w pliku tekstowym, wiadomości e-mail albo arkuszu dostępnym całej firmie.
Uwierzytelnianie dwuskładnikowe
Uwierzytelnianie dwuskładnikowe wymaga potwierdzenia logowania dodatkowym elementem.
Może to być:
- kod z aplikacji,
- klucz bezpieczeństwa,
- jednorazowy kod.
Jeżeli atakujący pozna hasło, nadal nie powinien uzyskać dostępu bez drugiego składnika.
2FA warto włączyć przynajmniej dla:
- hostingu,
- domeny,
- panelu administratora,
- poczty,
- repozytorium kodu,
- kont chmurowych.
Szczególnie ważne jest zabezpieczenie kont, które pozwalają zresetować hasła do pozostałych usług.
Przejęcie skrzynki e-mail może umożliwić przejęcie hostingu, domeny i strony.
Ograniczone uprawnienia użytkowników
Nie każdy użytkownik strony powinien posiadać rolę administratora.
Osoba publikująca artykuły zwykle nie potrzebuje dostępu do:
- instalowania wtyczek,
- edycji kodu,
- zarządzania kontami,
- zmiany ustawień bezpieczeństwa.
W sklepie pracownik obsługujący zamówienia nie musi mieć możliwości modyfikowania całej infrastruktury.
Zasada minimalnych uprawnień ogranicza skutki:
- przejęcia konta,
- błędu użytkownika,
- przypadkowego usunięcia danych.
Należy regularnie sprawdzać:
- aktywne konta,
- ich role,
- ostatnie logowania,
- konta byłych pracowników,
- konta wykonawców.
Dostęp powinien zostać odebrany, gdy przestaje być potrzebny.
Zabezpieczenie panelu logowania WordPress
Panel WordPressa jest regularnie atakowany przez boty próbujące odgadnąć dane logowania.
Ochrona może obejmować:
- ograniczenie liczby prób,
- 2FA,
- silne hasła,
- blokowanie podejrzanych adresów,
- wyłączenie nieużywanych metod logowania,
- alerty o nowych administratorach,
- kontrolę logów.
Zmiana samego adresu logowania może ograniczyć część automatycznego ruchu, ale nie powinna być traktowana jako główne zabezpieczenie.
Najważniejsze są:
- aktualność systemu,
- bezpieczne konta,
- ograniczone próby,
- monitoring.
Ochrona przed próbami brute force
Atak brute force polega na wielokrotnych próbach odgadnięcia hasła.
Może dotyczyć:
- WordPressa,
- SSH,
- poczty,
- panelu hostingu,
- aplikacji.
Ochrona może wykorzystywać:
- blokowanie po wielu błędach,
- opóźnianie kolejnych prób,
- CAPTCHA,
- 2FA,
- blokady adresów IP,
- analizę podejrzanego ruchu.
Na VPS warto stosować mechanizmy automatycznie blokujące powtarzające się próby logowania.
Nie należy jednak blokować całych zakresów bez analizy, ponieważ może to odciąć prawdziwych użytkowników.
Firewall
Firewall kontroluje ruch sieciowy i pozwala ograniczyć dostęp do usług.
Na serwerze publiczne powinny być tylko potrzebne porty.
Najczęściej będą to:
- HTTP,
- HTTPS,
- odpowiednio zabezpieczony dostęp administracyjny.
Nie powinny być publicznie dostępne bez potrzeby:
- baza danych,
- Redis,
- wewnętrzne API,
- panele techniczne,
- narzędzia administracyjne.
W przypadku VPS podstawowa konfiguracja zapory powinna zostać wykonana przed uruchomieniem aplikacji.
Sam fakt, że usługa jest chroniona hasłem, nie zawsze oznacza, że powinna być dostępna z całego internetu.
Zabezpieczenie SSH
Dostęp SSH pozwala zarządzać serwerem.
Przejęcie takiego dostępu może dać kontrolę nad całą infrastrukturą.
Bezpieczna konfiguracja powinna obejmować:
- logowanie kluczami,
- wyłączenie logowania prostym hasłem,
- ograniczenie konta root,
- aktualizacje systemu,
- blokowanie wielokrotnych prób,
- kontrolę aktywnych kluczy.
Klucze osób, które nie współpracują już z firmą, powinny zostać usunięte.
Warto również prowadzić dokumentację, kto posiada dostęp do środowiska produkcyjnego.
Baza danych nie powinna być publiczna
Baza danych powinna być dostępna wyłącznie dla:
- aplikacji,
- administratora z określonego adresu,
- bezpiecznego tunelu.
Publiczne wystawienie PostgreSQL, MySQL lub Redis zwiększa ryzyko skanowania, prób logowania i wykorzystania błędnej konfiguracji.
Dane dostępowe do bazy powinny być:
- silne,
- unikalne,
- przechowywane poza kodem,
- regularnie kontrolowane.
Aplikacja nie zawsze potrzebuje użytkownika bazy z pełnymi uprawnieniami administracyjnymi.
Powinna otrzymać wyłącznie uprawnienia potrzebne do działania.
Zmienne środowiskowe i klucze API
Aplikacja może przechowywać:
- hasła do bazy,
- klucze płatności,
- dane SMTP,
- sekrety JWT,
- klucze usług zewnętrznych.
Nie powinny trafiać do:
- publicznego repozytorium,
- kodu frontendowego,
- logów,
- zrzutów ekranu,
- ogólnodostępnych plików.
Trzeba również rozdzielić klucze:
- testowe,
- produkcyjne,
- administracyjne.
Jeżeli klucz zostanie ujawniony, powinien zostać unieważniony i zastąpiony nowym.
Samo usunięcie go z najnowszej wersji kodu może nie wystarczyć, ponieważ nadal pozostaje w historii repozytorium.
Bezpieczeństwo uploadu plików
Formularze pozwalające przesyłać pliki są wygodne, ale wymagają kontroli.
Należy ograniczyć:
- typy plików,
- rozmiar,
- miejsce zapisu,
- sposób późniejszego udostępniania.
Przesłany plik nie powinien automatycznie uzyskiwać możliwości wykonania na serwerze.
Warto stosować:
- zmianę nazw,
- kontrolę rozszerzenia,
- analizę typu MIME,
- skanowanie,
- przechowywanie poza katalogiem wykonywalnym.
Błędnie skonfigurowany upload może umożliwić przesłanie złośliwego skryptu.
Formularze i spam
Formularz kontaktowy może zostać wykorzystany do:
- masowej wysyłki,
- przeciążenia serwera,
- spamowania odbiorców,
- testowania podatności.
Ochrona powinna obejmować:
- ograniczenie częstotliwości,
- mechanizmy antybotowe,
- ukryte pola,
- walidację danych,
- rejestrowanie błędów,
- blokowanie podejrzanych żądań.
Nie należy polegać wyłącznie na prostym polu CAPTCHA.
Najlepsze zabezpieczenie łączy kilka metod i nie utrudnia kontaktu prawdziwym klientom.
Bezpieczeństwo poczty i domeny
Bezpieczeństwo strony jest powiązane z bezpieczeństwem domeny oraz poczty.
Przejęcie domeny może umożliwić:
- przekierowanie strony,
- zmianę poczty,
- podszywanie się pod firmę,
- wystawienie nowego certyfikatu.
Warto zabezpieczyć:
- konto operatora domeny,
- transfer domeny,
- 2FA,
- dane kontaktowe,
- terminy odnowienia.
Dla poczty należy skonfigurować odpowiednie rekordy:
- SPF,
- DKIM,
- DMARC.
Nie zabezpieczają one samej strony, ale ograniczają możliwość podszywania się pod domenę w wiadomościach.
Regularne kopie bezpieczeństwa
Nawet najlepiej zabezpieczony system może ulec awarii lub zostać zaatakowany.
Backup pozwala ograniczyć skutki:
- infekcji,
- usunięcia danych,
- błędnej aktualizacji,
- awarii serwera,
- błędu administratora.
Kopia powinna obejmować:
- pliki,
- bazę,
- konfigurację,
- dane użytkowników,
- najważniejsze ustawienia.
Przynajmniej jedna wersja powinna znajdować się poza głównym serwerem.
Dokładne zasady opisaliśmy w artykule [kopie zapasowe strony – jak często je wykonywać i gdzie przechowywać](/blog/kopie-zapasowe-strony-jak-czesto-i-gdzie-przechowywac).
Backup nie powinien być dostępny publicznie.
Plik zawierający bazę, konfigurację i hasła może być cenniejszy dla atakującego niż dostęp do samej strony.
Kopia nie zastępuje zabezpieczeń
Backup pozwala odtworzyć stronę, ale nie usuwa przyczyny włamania.
Jeżeli strona zostanie przywrócona bez:
- aktualizacji podatnej wtyczki,
- zmiany haseł,
- usunięcia złośliwego konta,
- zamknięcia błędnej konfiguracji,
problem może szybko powrócić.
Po incydencie trzeba:
1. zabezpieczyć dowody i logi,
2. ustalić zakres problemu,
3. znaleźć sposób wejścia,
4. usunąć złośliwe zmiany,
5. zamknąć podatność,
6. zmienić dostępy,
7. przywrócić czyste dane,
8. monitorować stronę.
Monitoring dostępności
Monitoring pozwala szybko zauważyć, że strona przestała działać.
Może sprawdzać:
- kody odpowiedzi,
- czas odpowiedzi,
- SSL,
- API,
- serwer,
- procesy,
- bazę.
Zakres monitoringu opisaliśmy szerzej w poradniku [monitoring strony internetowej 24/7 – co naprawdę powinien sprawdzać](/blog/monitoring-strony-internetowej-24-7-co-powinien-sprawdzac).
Awaria może być skutkiem ataku, ale również błędu, braku pamięci albo problemu z bazą.
Szybkie wykrycie skraca czas niedostępności i ogranicza możliwe straty.
Monitoring bezpieczeństwa
Poza dostępnością warto kontrolować:
- nieudane logowania,
- nowe konta administratorów,
- zmiany plików,
- nietypowe żądania,
- wzrost ruchu,
- błędy autoryzacji,
- zmiany konfiguracji.
Nie każdy alert oznacza włamanie.
Duża liczba błędnych logowań może pochodzić od automatycznych botów, które nie uzyskały dostępu.
Ważny jest jednak trend oraz możliwość szybkiej analizy.
Logi serwera i aplikacji
Logi mogą pokazać:
- próby logowania,
- błędy aplikacji,
- nietypowe adresy,
- wywoływane endpointy,
- moment wystąpienia problemu,
- działania użytkownika.
Powinny być:
- przechowywane przez określony czas,
- zabezpieczone przed modyfikacją,
- regularnie rotowane,
- dostępne osobom technicznym.
Nie powinny przechowywać pełnych haseł, tokenów ani nadmiarowych danych osobowych.
Brak logów utrudnia ustalenie, co wydarzyło się podczas incydentu.
Aktualizacje systemu VPS
Własny VPS wymaga aktualizacji systemu i usług.
Nieaktualne mogą być:
- system operacyjny,
- Nginx,
- Apache,
- PHP,
- Node.js,
- baza danych,
- biblioteki.
Aktualizacje należy planować.
Niektóre mogą wymagać restartu usług, dlatego najlepiej wykonywać je:
- po kopii,
- w czasie mniejszego ruchu,
- z monitoringiem,
- z możliwością wycofania.
Samodzielny VPS bez administratora może być większym ryzykiem niż dobrze utrzymany hosting współdzielony.
Porównanie środowisk opisaliśmy w artykule [VPS czy hosting współdzielony – co wybrać dla firmy](/blog/vps-czy-hosting-wspoldzielony-co-wybrac-dla-firmy).
Izolacja stron na serwerze
Jeżeli na jednym serwerze działa wiele stron, ważna jest ich izolacja.
Infekcja jednego serwisu nie powinna automatycznie dawać dostępu do pozostałych.
Warto stosować:
- osobnych użytkowników systemowych,
- oddzielne bazy,
- osobne dane dostępowe,
- ograniczone uprawnienia,
- izolowane procesy.
Umieszczanie wszystkich stron pod jednym użytkownikiem z pełnymi prawami zwiększa skalę możliwej awarii.
Hosting współdzielony a bezpieczeństwo
Na hostingu współdzielonym część obowiązków przejmuje operator.
Może on odpowiadać za:
- system serwera,
- aktualizacje infrastruktury,
- izolację kont,
- zaporę,
- podstawowe skanowanie,
- ochronę usług.
Klient nadal odpowiada jednak za:
- swoją stronę,
- hasła,
- wtyczki,
- konta,
- kopie niezależne,
- konfigurację aplikacji.
Dobry hosting współdzielony może być bezpiecznym rozwiązaniem dla małej firmy, jeżeli strona jest regularnie aktualizowana i nadzorowana.
VPS a bezpieczeństwo
VPS daje większą kontrolę, ale również większą odpowiedzialność.
Trzeba zabezpieczyć:
- system,
- porty,
- SSH,
- usługi,
- bazę,
- procesy,
- backupy,
- monitoring.
Serwer VPS nie staje się bezpieczny tylko dlatego, że jest prywatny.
Błędna konfiguracja może wystawić do internetu usługę, która na hostingu współdzielonym w ogóle nie byłaby dostępna.
Dlatego firmy bez administratora powinny rozważyć VPS zarządzany.
Bezpieczeństwo aplikacji Next.js i Node.js
Aplikacje Node.js wymagają ochrony zarówno serwera, jak i kodu.
Trzeba zadbać o:
- aktualne zależności,
- bezpieczne zmienne środowiskowe,
- walidację danych,
- limity żądań,
- prawidłową autoryzację,
- bezpieczne API,
- ochronę przed ujawnianiem błędów.
Środowisko powinno również posiadać monitoring procesów, bazy i backupów.
Więcej o wymaganiach takich aplikacji przeczytasz w artykule [hosting dla Next.js i Node.js – czego potrzebuje aplikacja firmowa](/blog/hosting-dla-nextjs-nodejs-czego-potrzebuje-aplikacja-firmowa).
Ochrona przed przeciążeniem
Strona może zostać przeciążona przez:
- prawdziwy wzrost ruchu,
- boty,
- atak,
- błędną integrację,
- zbyt wiele zapytań API.
Ochrona może obejmować:
- rate limiting,
- cache,
- CDN,
- blokowanie podejrzanego ruchu,
- limity na endpointach,
- skalowanie zasobów.
Nie każda awaria pod dużym ruchem jest atakiem.
Przyczyną może być po prostu brak optymalizacji albo zbyt małe środowisko.
Analizę wydajności opisaliśmy w artykule [jak sprawdzić, czy hosting spowalnia stronę](/blog/jak-sprawdzic-czy-hosting-spowalnia-strone).
Błędy 500 i 502 po ataku lub zmianie
Po infekcji albo nieudanej zmianie strona może zacząć zwracać błędy serwera.
Przyczyną mogą być:
- uszkodzone pliki,
- zmieniona konfiguracja,
- niedziałający proces,
- przeciążenie,
- problem z bazą.
Przypadkowe restartowanie usług lub usuwanie plików może utrudnić późniejszą analizę.
Sposoby diagnozy opisaliśmy w poradniku [błąd 500 lub 502 na stronie – co oznacza i jak go naprawić](/blog/blad-500-lub-502-na-stronie-co-oznacza-i-jak-naprawic).
Migracja z zainfekowanego hostingu
Samo przeniesienie strony na nowy serwer nie usuwa infekcji.
Jeżeli zostaną skopiowane złośliwe pliki, problem trafi razem z projektem do nowego środowiska.
Przed migracją trzeba:
- sprawdzić pliki,
- zidentyfikować zmiany,
- zaktualizować komponenty,
- zmienić dane dostępowe,
- przygotować czysty backup,
- przetestować stronę.
Bezpieczny proces przenoszenia opisaliśmy w artykule [jak przenieść stronę na inny hosting bez przestoju](/blog/jak-przeniesc-strone-na-inny-hosting-bez-przestoju).
Co zrobić po wykryciu infekcji?
Podstawowa kolejność działań:
1. ograniczyć dostęp do strony, jeśli jest to konieczne,
2. wykonać kopię obecnego stanu,
3. zabezpieczyć logi,
4. sprawdzić użytkowników i dostępy,
5. znaleźć zmienione pliki,
6. ustalić sposób wejścia,
7. usunąć złośliwy kod,
8. zaktualizować system,
9. zmienić hasła i klucze,
10. uruchomić monitoring.
Nie należy od razu kasować wszystkich podejrzanych danych.
Część plików i logów może być potrzebna do ustalenia przyczyny.
Jak rozpoznać zainfekowaną stronę?
Objawy mogą obejmować:
- przekierowania na obce strony,
- nowe konta administratorów,
- nieznane pliki,
- wysyłkę spamu,
- ostrzeżenia przeglądarki,
- nagłe spowolnienie,
- obcy tekst w wynikach Google,
- błędy serwera,
- wzrost wykorzystania procesora.
Infekcja może również działać bez widocznych objawów.
Atakujący może wykorzystywać stronę do:
- wysyłki wiadomości,
- pozycjonowania spamu,
- przekierowywania części użytkowników,
- dalszych ataków.
Dlatego regularna kontrola jest ważna nawet wtedy, gdy strona pozornie działa poprawnie.
Czy wtyczka bezpieczeństwa wystarczy?
Nie.
Wtyczka może pomagać w:
- ograniczaniu logowań,
- skanowaniu plików,
- wykrywaniu zmian,
- blokowaniu części ruchu.
Nie zastąpi jednak:
- aktualizacji,
- kopii,
- bezpiecznego serwera,
- silnych haseł,
- ograniczonych dostępów,
- monitoringu.
Zbyt ciężka wtyczka może również spowalniać stronę.
Bezpieczeństwo powinno opierać się na kilku warstwach, a nie jednym dodatku.
Jak wybrać bezpieczny hosting?
Przed zakupem warto zapytać:
- czy konta są izolowane,
- jak często aktualizowany jest serwer,
- czy dostępne są kopie,
- jak długo są przechowywane,
- czy backup znajduje się poza serwerem,
- czy działa monitoring,
- czy dostępne jest 2FA,
- jak wygląda ochrona przed próbami logowania,
- kto reaguje na awarie,
- czy pomoc obejmuje samą stronę.
Pomocne będzie również sprawdzenie, [jak wybrać hosting dla strony firmowej](/blog/jak-wybrac-hosting-dla-strony-firmowej).
Najlepszy hosting nie jest tym, który posiada najwięcej funkcji w tabeli.
Jest nim środowisko dopasowane do projektu i objęte realnym nadzorem.
Ile kosztuje bezpieczne utrzymanie strony?
Koszt zależy od:
- rodzaju strony,
- częstotliwości zmian,
- wartości danych,
- technologii,
- wymaganego czasu reakcji,
- zakresu monitoringu,
- częstotliwości backupów.
Prosta strona firmowa będzie wymagała mniej działań niż sklep, system rezerwacji lub aplikacja SaaS.
Koszty poszczególnych elementów opisaliśmy w artykule [ile kosztuje utrzymanie strony internetowej miesięcznie](/blog/ile-kosztuje-utrzymanie-strony-internetowej-miesiecznie).
Najtańszy wariant często oznacza, że właściciel sam odpowiada za aktualizacje i awarie.
Bezpieczny hosting z opieką HeatLogic
W HeatLogic bezpieczeństwo hostingu łączymy z utrzymaniem konkretnej strony lub aplikacji.
Zakres może obejmować:
- konfigurację hostingu lub VPS,
- aktualizacje,
- SSL,
- monitoring,
- regularne kopie,
- ograniczenie dostępów,
- zabezpieczenie SSH,
- firewall,
- kontrolę procesów,
- reakcję na awarie,
- migrację.
Usługa może być połączona z [hostingiem i opieką techniczną HeatLogic](/hosting-i-opieka).
Nie obiecujemy, że żadna awaria ani próba ataku nigdy się nie wydarzy.
Celem jest zmniejszenie ryzyka, szybkie wykrycie problemu i możliwość sprawnego odtworzenia strony.
Lista kontrolna bezpieczeństwa hostingu
Sprawdź:
1. Czy strona działa przez HTTPS?
2. Czy certyfikat odnawia się automatycznie?
3. Czy system jest aktualny?
4. Czy WordPress i wtyczki są aktualne?
5. Czy usunięto nieużywane dodatki?
6. Czy hasła są unikalne?
7. Czy działa 2FA?
8. Czy użytkownicy mają ograniczone role?
9. Czy dostęp byłych pracowników został usunięty?
10. Czy panel logowania posiada ochronę?
11. Czy SSH wykorzystuje klucze?
12. Czy konto root jest ograniczone?
13. Czy działa firewall?
14. Czy baza nie jest publicznie dostępna?
15. Czy zmienne środowiskowe są chronione?
16. Czy uploady są walidowane?
17. Czy formularze posiadają ochronę przed spamem?
18. Czy backup znajduje się poza serwerem?
19. Czy kopie są testowane?
20. Czy działa monitoring i procedura reakcji?
Podsumowanie
Bezpieczny hosting dla firmy nie oznacza wyłącznie certyfikatu SSL.
Skuteczna ochrona wymaga:
- aktualizacji,
- mocnych haseł,
- 2FA,
- ograniczonych uprawnień,
- zabezpieczenia serwera,
- regularnych kopii,
- monitoringu,
- planu reakcji.
Hosting powinien chronić infrastrukturę, a opieka techniczna powinna obejmować również stronę, aplikację i dane.
Największym zagrożeniem często nie jest jeden zaawansowany atak.
Jest nim połączenie kilku zaniedbań:
- starej wtyczki,
- słabego hasła,
- braku kopii,
- braku monitoringu.
Nie masz pewności, czy hosting i strona są prawidłowo zabezpieczone?
Skontaktuj się z HeatLogic. Sprawdzimy konfigurację, aktualizacje, dostęp, kopie i monitoring oraz wskażemy elementy wymagające poprawy.
Najczęściej zadawane pytania
Czy certyfikat SSL wystarczy do zabezpieczenia strony?
Nie. SSL szyfruje połączenie, ale nie chroni przed podatnościami, przejęciem konta, infekcją lub błędną konfiguracją.
Czy WordPress jest bezpieczny?
Może być bezpiecznym systemem, jeżeli jest regularnie aktualizowany, korzysta ze sprawdzonych wtyczek i posiada właściwie zabezpieczone konta.
Czy VPS jest bezpieczniejszy od hostingu współdzielonego?
Nie automatycznie. VPS daje większą kontrolę, ale wymaga samodzielnej konfiguracji, aktualizacji, zapory, backupów i monitoringu.
Jak często wykonywać kopie strony?
Zależy to od częstotliwości zmian. Prosta strona może posiadać kopię dobową, a aktywny sklep lub system rezerwacji wymagać częstszych backupów bazy.
Czy wtyczka bezpieczeństwa ochroni stronę?
Może być jedną z warstw ochrony, ale nie zastąpi aktualizacji, zabezpieczonego serwera, kopii i monitoringu.
Co zrobić po włamaniu na stronę?
Należy zabezpieczyć obecny stan i logi, ustalić drogę wejścia, usunąć infekcję, zamknąć podatność, zmienić dostępy oraz przywrócić czyste dane.
Czy hosting z opieką jest bezpieczniejszy?
Może być, ponieważ ktoś regularnie kontroluje aktualizacje, kopie, monitoring i stan strony. Zakres odpowiedzialności powinien być jednak jasno opisany.