Zanim zapłacisz za jakikolwiek plan bezpieczeństwa — sprawdź, co już masz. Darmowy Cloudflare to nie jest „byle co na start”. Przy odpowiedniej konfiguracji daje Twojemu SaaS ochronę, za którą duże firmy płacą setki dolarów miesięcznie.
W tym artykule tłumaczę bez technicznego żargonu, z czego się ta ochrona składa i dlaczego kolejność, w jakiej ją wdrażasz, ma większe znaczenie niż sama lista funkcji.
Najważniejsze wnioski
- Darmowy Cloudflare zawiera SSL/TLS, DNSSEC, WAF (zaporę sieciową) i Rate Limiting (ogranicznik ruchu) — wystarczy na wczesny etap SaaS.
- Każda warstwa chroni następną. Zły porządek wdrożenia to dziury, których nie widać.
- Największe ryzyko nie leży w braku płatnych funkcji, lecz w błędach konfiguracyjnych — szczególnie w niezabezpieczonym serwerze źródłowym.
- Cała konfiguracja może być wersjonowana jako kod — pełna historia zmian i możliwość natychmiastowego cofnięcia.
Co właściwie dostajesz za zero złotych?
Zacznijmy od tego, co Cloudflare daje w darmowym planie. Nie będę cytować marketingu — poniżej to, co realnie przekłada się na bezpieczeństwo:
| Co dostajesz | Co to robi dla Ciebie |
|---|---|
| Szyfrowanie SSL/TLS | Dane między użytkownikiem a serwerem są nieczytelne dla podsłuchujących |
| DNSSEC (Ochrona DNS) | Nikt nie może przekierować Twoich użytkowników na fałszywą stronę |
| WAF (Zapora sieciowa) | 5 darmowych reguł (Custom Rules). Blokujesz konkretne typy ataków zanim dotrą do aplikacji |
| Rate Limiting (Ogranicznik ruchu) | 1 reguła. Chronisz formularze logowania przed zautomatyzowanymi atakami (brute-force) |
| Globalny CDN | Twoja strona jest serwowana z serwera najbliższego użytkownikowi |
| Nieograniczone strony statyczne | Możesz hostować landing page i dokumentację bez limitu |
Pięć reguł WAF i jedna reguła Rate Limitingu brzmią jak mało. Ale każda precyzyjnie skonfigurowana reguła blokuje całą klasę ataków — i to wystarczy.
Dlaczego kolejność wdrożenia ma znaczenie
Wyobraź sobie, że budujesz dom. Nie zaczynasz od malowania ścian — najpierw fundamenty, potem konstrukcja, potem instalacje. Bezpieczeństwo działa tak samo: każda warstwa chroni tę następną.
Jeśli najpierw skonfigurujesz zaporę, ale zapomnisz o szyfrowaniu połączenia z serwerem — zapobiegasz atakom od frontu, ale zostawiasz otwarte tylne drzwi.
Warstwa 1 — SSL/TLS: fundamenty szyfrowania
Pierwsza i najważniejsza decyzja: czy dane między Cloudflare a Twoim serwerem są szyfrowane?
Domyślnie Cloudflare szyfruje połączenie od użytkownika do swojej sieci (tzw. Flexible lub Full). Ale od swojej sieci do Twojego serwera — tylko jeśli to skonfigurujesz. Tryb Full (Strict) oznacza, że Cloudflare weryfikuje certyfikat Twojego serwera i w pełni szyfruje to połączenie (End-to-End). To różnica między zamkniętym sejfem a pudełkiem po butach z kłódką od frontu.
Do tego ustawiasz, że połączenia HTTP są automatycznie przekierowywane na HTTPS, a minimalna wersja protokołu szyfrującego to TLS 1.2 (starsze wersje mają znane luki).
Warstwa 2 — DNSSEC: żeby nikt nie podszył się pod Ciebie
Wyobraź sobie, że ktoś zmienia tabliczkę z numerem domu na Twojej ulicy. Twoi goście trafiają do sąsiada, który udaje, że to Ty.
DNS Cache Poisoning działa dokładnie tak — atakujący podmienia adres IP Twojej domeny w odpowiedziach serwera DNS, żeby użytkownicy lądowali na fałszywej stronie i tam wpisywali swoje hasła.
DNSSEC to kryptograficzny podpis każdej odpowiedzi DNS. Żaden serwer bez właściwego klucza nie może udawać, że jest Twoją domeną. Aktywacja w Cloudflare zajmuje kilka kliknięć — jeśli masz domenę u zewnętrznego rejestratora, musisz przekopiować jeden rekord DS (tzw. Delegation Signer).
Warstwa 3 — WAF (Web Application Firewall): 5 precyzyjnych reguł
Zapora sieciowa (WAF) to bramkarz przed wejściem do Twojej aplikacji. Na darmowym planie masz pięć miejsc na własne reguły (Custom Rules). Oto jak je optymalnie zagospodarować:
Reguła 1 — Blokada nieoczekiwanych metod HTTP i portów. Normalni użytkownicy korzystają z kilku standardowych sposobów komunikacji z serwerem (pobieranie stron GET, wysyłanie formularzy POST). Boty i skanery próbują metod niszowych i niestandardowych portów. Ta reguła blokuje wszystkich, którzy „pukają do tylnych drzwi”.
Reguła 2 — Ochrona autoryzacji (Managed Challenge). Endpointy logowania i rejestracji są najczęściej atakowane. Cloudflare wyświetla tu interaktywne wyzwanie (Managed Challenge) — prawdziwi użytkownicy przechodzą je często niewidzialnie, boty są zatrzymywane.
Reguła 3 — Blokada znanych wektorów ataku. Każdego dnia Twoja aplikacja jest skanowana w poszukiwaniu znanych luk: paneli WordPress (/wp-admin), plików konfiguracyjnych (.env), narzędzi bazodanowych. Żadna z tych ścieżek nie powinna istnieć w Twojej aplikacji — blokujesz je hurtowo w jednej regule po URI path.
Reguła 4 — Ukrycie środowisk stagingowych. Panel administracyjny powinien być dostępny tylko dla Twojego firmowego IP. Subdomeny testowe (preview, stage) też nie powinny być publicznie dostępne dla całego internetu.
Reguła 5 — Tarcza awaryjna (Emergency Shield). Ta reguła leży gotowa na wypadek ataku DDoS. Gdy coś złego się dzieje — jeden przełącznik włącza dodatkową weryfikację (Managed Challenge) dla całego ruchu do API. Na co dzień wyłączona, żeby nie opóźniać odpowiedzi dla użytkowników.
Warstwa 4 — Rate Limiting (ogranicznik ruchu): jedna reguła
Wyobraź sobie, że ktoś próbuje odgadnąć Twoje hasło, wpisując tysiąc kombinacji na minutę (atak brute-force). Rate Limiting mówi: „po 15 zapytaniach w 10 sekund z jednego adresu IP — stop, zablokowane”.
Masz jedną regułę. Skieruj ją tam, gdzie ataki bolą najbardziej: formularz logowania, rejestracji i resetowania hasła.
Warstwa 5 — Security Headers (nagłówki bezpieczeństwa)
Przeglądarka użytkownika może być Twoim sojusznikiem albo wektorem ataku — zależy, co jej powiesz. Security Headers to zestaw instrukcji wysyłanych przeglądarce przy każdej stronie (np. przez Transform Rules w Cloudflare).
Przykładowo: możesz powiedzieć przeglądarce, że Twoja strona nigdy nie powinna być wyświetlana wewnątrz innej strony (ochrona przed Clickjackingiem). Albo że wolno jej ładować skrypty tylko z Twojej domeny (ochrona przed XSS). Te instrukcje możesz ustawić centralnie przez Cloudflare — zamiast konfigurować je w każdej aplikacji osobno.
Największa dziura, o której nikt nie myśli
Możesz mieć idealnie skonfigurowany Cloudflare — i nadal mieć poważny problem. Jeśli atakujący pozna adres IP Twojego serwera, może ominąć Cloudflare całkowicie i uderzyć bezpośrednio.
Skąd może znać ten adres? Z historycznych rekordów DNS (platformy archiwizują stare adresy IP), z logów certyfikatów TLS albo przez zmuszenie Twojej aplikacji do wykonania połączenia wychodzącego.
Rozwiązanie to Cloudflare Tunnel (niegdyś Argo Tunnel) — mały program (demon cloudflared) instalowany na serwerze, który sam nawiązuje połączenie do sieci Cloudflare od wewnątrz. Twój serwer nie potrzebuje żadnych otwartych portów przychodzących. Nawet jeśli ktoś zna Twój adres IP — nie ma jak się podłączyć.
Infrastruktura jako kod — dlaczego warto
Każda zmiana konfiguracji zrobiona ręcznie w panelu to zmiana, której nie ma w historii Git. Nie wiesz, kto ją zrobił, kiedy i po co. Przy incydencie bezpieczeństwa to poważny problem.
Terraform pozwala zapisać całą konfigurację Cloudflare (Infrastructure as Code) w plikach tekstowych .tf, wersjonować je razem z kodem aplikacji i wdrażać przez CI/CD. Rollback do poprzedniej konfiguracji to jedna komenda.
To nie jest konieczne od pierwszego dnia — ale im wcześniej zaczniesz, tym mniej bólu przy skalowaniu.
Kiedy darmowy plan przestaje wystarczać?
Nie zaczynaj od płatnego planu. Wdróż darmową konfigurację, obserwuj przez kilka tygodni, co i jak atakuje Twój system. Dopiero wtedy będziesz wiedzieć, czego faktycznie potrzebujesz.
Sygnały, że czas na upgrade:
- Pięć reguł WAF to za mało i musisz wybierać, których klas ataków nie blokujesz
- Chcesz limitować ruch osobno dla każdego zalogowanego użytkownika, nie tylko globalnie
- Potrzebujesz gotowego zestawu reguł OWASP (baza znanych ataków, aktualizowana na bieżąco)
- Chcesz analizy botów opartej na uczeniu maszynowym
FAQ
Czy muszę umieć programować, żeby to skonfigurować?
Podstawowe ustawienia — SSL, DNSSEC, proste reguły WAF — można wyklikać w panelu Cloudflare bez pisania kodu. Jeśli chcesz zarządzać konfiguracją jako kodem (Terraform), potrzebujesz kogoś technicznego lub agenta AI. Do tego właśnie służy plik implementacyjny poniżej.
Czy Cloudflare spowalnia moją stronę?
Nie — przyspiesza. Cloudflare cachuje zasoby statyczne i serwuje je z węzła sieci najbliższego użytkownikowi. Pierwsze połączenie jest minimalnie wolniejsze z powodu warstwy proxy, ale każde kolejne jest szybsze.
Co się stanie, jeśli Cloudflare zablokuje prawdziwego użytkownika?
Cloudflare Managed Challenge (niewidzialna weryfikacja) rozwiązuje to lepiej niż klasyczne CAPTCHA. Prawdziwi użytkownicy przechodzą automatycznie, boty są blokowane. Przy dobrze skonfigurowanych regułach fałszywe alarmy są rzadkie.
Plik implementacyjny dla agenta
Jeśli masz agenta AI lub dewelopera, który ma wdrożyć tę konfigurację — poniżej jest gotowa checklista z dokładnymi poleceniami. Zawiera kompletny kod Terraform, skrypty weryfikacyjne i opis każdego kroku w kolejności wdrożenia.