Wdrożenia Serwerów WWW

Wdrożenie serwerów WWW dla firm — Nginx, Apache, IIS zgodne z NIS2 i ISO 27001

Serwer WWW to fundament każdej obecności firmy w internecie — od korporacyjnej strony, przez aplikacje SaaS, sklepy e-commerce, panele klienta, po API udostępniane partnerom B2B. Źle skonfigurowany serwer WWW to nie tylko wolne ładowanie i tracone konwersje, ale realna powierzchnia ataku: ekspozycja wewnętrznych usług, podatność na OWASP Top 10, brak ochrony przed botami i scrapingiem, kompromitacja łańcucha CI/CD przy źle dobranych uprawnieniach do reverse proxy. Z perspektywy NIS2 (art. 21 ust. 2 lit. d, e, h — ochrona ciągłości działania, kryptografia, kontrola dostępu) i ISO/IEC 27001:2023 (Annex A.5.23, A.8.20, A.8.23, A.8.24) serwer WWW jest jednym z najważniejszych komponentów do audytu.

Virtline projektuje i wdraża serwery WWW na produkcję dla firm 20-2000+ użytkowników i aplikacji z obsługą tysięcy zapytań na sekundę: Nginx 1.27 OSS i Plus, Apache HTTPD 2.4, Microsoft IIS 10 dla stacków .NET, HAProxy 3.0 i Traefik 3 jako load balancery Layer 7, Caddy z automatycznym Let’s Encrypt, OpenResty z Lua dla zaawansowanej logiki edge. Wdrażamy HTTP/2 RFC 7540, HTTP/3 QUIC RFC 9114, TLS 1.3 RFC 8446 z PFS i 0-RTT, ModSecurity 3 z OWASP CRS 4.x jako WAF, fail2ban i CrowdSec przeciwko brute force, OCSP stapling, HSTS z preload, hardening zgodny z CIS Benchmark i Mozilla Server Side TLS (Modern/Intermediate).

Integrujemy z CDN (Cloudflare, Akamai, BunnyCDN) tam, gdzie ma to sens, oraz z platformami obserwowalności (Prometheus, Grafana, Loki, ELK).

Co obejmuje wdrożenie serwera WWW w Virtline

Realizujemy pełen stos warstwy edge — od silnika HTTP, przez TLS, WAF, reverse proxy, po monitoring i hardening:

Nginx 1.27 (OSS / Nginx Plus) — referencyjny serwer dla nowych wdrożeń, oparty na event loop, obsługujący 10k+ równoczesnych połączeń na jednym workerze.

Konfigurujemy upstream pools, keepalive, gzip/brotli compression, gzip_static dla pre-kompresowanych assetów, cache (proxy_cache, fastcgi_cache), rate limiting (limit_req_zone), connection limiting (limit_conn). Nginx Plus dodaje active health checks, session persistence (sticky cookie), dynamic upstream API, JWT validation, dashboardy NGX Plus.

Apache HTTPD 2.4 z mod_http2, mod_md, mod_security — wciąż domyślny wybór dla aplikacji LAMP, PHP-FPM, mod_perl, WebDAV, integracji z CPanel/Plesk.

Wykorzystujemy MPM event (~3-4× wyższa przepustowość vs prefork), mod_http2 dla HTTP/2, mod_md (ACMEv2/Let’s Encrypt natywnie), mod_security 2.9 z OWASP CRS, mod_evasive przeciwko DoS, mod_remoteip dla X-Forwarded-For przy reverse proxy. .htaccess wyłączamy globalnie (AllowOverride None) dla wydajności.

Microsoft IIS 10 dla .NET i Windows-centric stacków — natywny serwer dla ASP.NET Core, WCF, BizTalk, SharePoint, Exchange OWA, Dynamics 365 on-prem.

Konfigurujemy ARR (Application Request Routing) jako reverse proxy, URL Rewrite module, Dynamic IP Restrictions, Request Filtering, IIS Compression (dynamic + static). Hardening: usunięcie Server header (URLScan), wyłączenie OPTIONS/TRACE/HEAD methods, TLS 1.3 dostępne w Windows Server 2022.

HAProxy 3.0 i Traefik 3 jako load balancer Layer 4/7 — HAProxy dla wysokowydajnych load balancerów L4/L7 (100k+ rps na pojedynczym węźle), TLS termination, stick tables, ACL routing, peers protocol dla replikacji sesji.

Traefik 3 dla środowisk dynamicznych (Docker, Kubernetes, Consul) z auto-discovery, natywnym Let’s Encrypt, dashboardem i middlewarami (rate limit, IP whitelist, headers manipulation). Wybór zależy od architektury — statyczna vs cloud-native.

HTTP/2 (RFC 7540) i HTTP/3 QUIC (RFC 9114) — HTTP/2 wymusza multiplexing, header compression (HPACK), server push (deprecated w Chrome — pomijamy), priorytetyzację strumieni.

HTTP/3 nad QUIC eliminuje head-of-line blocking, obsługuje 0-RTT, lepiej radzi sobie na sieciach mobilnych i pakietowych stratach. Wdrażamy HTTP/3 selektywnie tam, gdzie ma realny ROI (publiczne strony content-heavy, aplikacje mobile-first); dla API B2B HTTP/2 zwykle wystarczy.

TLS 1.3 (RFC 8446) z Perfect Forward Secrecy — TLS 1.3 obowiązkowo, TLS 1.2 z PFS dopuszczalny dla legacy.

Cipher suites Mozilla Modern (TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256), ECDHE_RSA / ECDHE_ECDSA dla TLS 1.2. Wyłączamy TLS 1.0/1.1, SSLv2/v3, RC4, 3DES, MD5, eksportowe ciphers. Certyfikaty ECDSA P-256 + RSA 2048 (dual cert) dla maksymalnej kompatybilności i wydajności.

ModSecurity 3 + OWASP Core Rule Set 4.x jako WAF — Web Application Firewall blokujący ataki z OWASP Top 10 (SQL injection, XSS, RCE, LFI/RFI, command injection), bota scrapy, scan toolingu (sqlmap, nikto, dirbuster).

ModSecurity 3 to nowa implementacja (libmodsecurity) zintegrowana z Nginx i Apache. OWASP CRS 4.x z paranoia level 1-4 i anomaly scoring. Tuning false-positives na bazie audit log, lista wyjątków per aplikacja, blokowanie po przekroczeniu progu (zwykle 5).

fail2ban + CrowdSec — ochrona przed brute force i botami — fail2ban (klasyczny) skanuje logi Nginx/Apache/sshd i blokuje IP po N nieudanych próbach (login, 401/403, 404 flood).

CrowdSec (nowoczesny) — collaborative threat intelligence: zbiorowo dzielimy się zablokowanymi IP z globalną społecznością. Integracja z iptables, nftables, ipset, Nginx (allow/deny), Cloudflare (API blocklist). Ban czasowy (15 min – 24 h) z whitelistą stałych IP klienta.

OCSP stapling, HSTS preload, security headers — OCSP stapling (RFC 6066) eliminuje round-trip do CA przy weryfikacji certyfikatu — zysk 100-300 ms pierwszy load.

HSTS (Strict-Transport-Security max-age=63072000; includeSubDomains; preload) wymusza HTTPS i blokuje SSL stripping. Preload list HSTS Chrome/Firefox (zgłoszenie domeny). Headers: Content-Security-Policy z nonce/hash dla scriptów, X-Frame-Options DENY/SAMEORIGIN, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy, X-Content-Type-Options nosniff.

Hardening i compliance — CIS Benchmark, Mozilla SSL Config — pełen hardening systemu pod web serverem: minimalny system (Ubuntu Server LTS, Rocky Linux, Debian stable), AppArmor/SELinux profiles dla nginx/apache, unattended-upgrades dla CVE patching, fail-secure default (drop everything, allow listed), separacja użytkowników (nginx/www-data nie root), chroot dla legacy aplikacji.

Audyt zgodności: SSL Labs A+, Mozilla Observatory A+, securityheaders.com A+, Internet.nl 100%, CIS Benchmark Level 1/2.

Korzyści z profesjonalnie wdrożonego serwera WWW

Dobrze zaprojektowana warstwa edge to mierzalne efekty performance, compliance i odporności na ataki:

Wydajność i Core Web Vitals — szybsza strona, lepsze SEO — Nginx z brotli, gzip_static, properly tuned proxy_cache, HTTP/2/3 i optymalnym TLS handshake potrafi obciąć Largest Contentful Paint o 30-60% względem domyślnej konfiguracji Apache prefork bez cache.

Lepsze CWV → wyższy ranking Google, niższy bounce rate, wyższa konwersja (każde 100 ms LCP poprawy = ~1% wzrost konwersji według Amazon i Walmart studies).

NIS2 art. 21 ust. 2 lit. d, e, h — ciągłość, kryptografia, kontrola dostępu — dyrektywa NIS2 wymaga środków zarządzania incydentami, ciągłości działania, kryptografii i kontroli dostępu.

Profesjonalny serwer WWW z load balancerem, HA, WAF, fail2ban, TLS 1.3 i audytem dostępu administratorów spełnia wprost te wymogi. Dokumentacja: konfiguracja zarządzana w git (Infrastructure as Code), runbook awaryjny, SLA, raporty z testów penetracyjnych.

ISO/IEC 27001:2023 Annex A.5.23, A.8.20, A.8.23, A.8.24 — bezpieczeństwo w usługach chmurowych, bezpieczeństwo sieci, filtrowanie sieci, używanie kryptografii.

Audytowalne wdrożenie web servera z TLS 1.3, WAF, segmentacją (reverse proxy w DMZ, app servers w wewnętrznej VLAN), centralnym logowaniem do SIEM i regularnym audytem konfiguracji to gotowa implementacja kontroli A.5/A.8 dla powierzchni HTTP.

Ochrona przed OWASP Top 10 i botami — ModSecurity z OWASP CRS 4.x blokuje typowe ataki webowe: SQL injection (CRS 942), XSS (941), RCE/LFI (931, 932), HTTP protocol violations (920, 921), scanner detection (913), automation/bots (910).

CrowdSec dodaje warstwę threat intelligence (~1M IP w globalnej blocklist). Realne dane z naszych wdrożeń: 70-95% ruchu od botów odrzucane na warstwie edge zanim dotrze do aplikacji.

Wysoka dostępność (HA) i transparent failover — load balancer (HAProxy/Nginx Plus) z active health checks usuwa padnięty backend z puli w 5-15 sekund.

Konfiguracja active-active z floating IP (keepalived, VRRP), session persistence dla stateful aplikacji, drain mode dla rolling deploy bez przerwy. RTO < 30 s dla awarii pojedynczego backendu, RPO 0 dla stateless aplikacji. Klient nie zauważa wymiany serwera w trakcie pracy.

Odporność na DDoS warstwy 7 — wielowarstwowo: rate limiting w Nginx (limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s), connection limiting (limit_conn), tarpit dla wykrytych ataków (delay zamiast 503 — zżera zasoby atakującego), CrowdSec scenarios dla wykrycia rozproszonych ataków, opcjonalnie CDN przed (Cloudflare Pro / Business / Enterprise dla L7 DDoS protection).

Dla 99% scenariuszy małe-średnie ataki Nginx z fail2ban radzi sobie sam.

SLA, audit log i transparencja operacyjna — access log w formacie JSON z polami: timestamp, remote_addr, request, status, body_bytes, request_time, upstream_response_time, user_agent, http_x_forwarded_for.

Spływa do Loki/ELK z retencją 12-24 mc. Każda akcja administratora (deploy, restart, zmiana konfiguracji) logowana przez auditd lub Ansible/Terraform run history. Klient widzi co dzieje się na jego serwerze w czasie rzeczywistym przez Grafana dashboard.

Bezpieczne deployments — blue/green, canary, rolling — load balancer wspiera odpinanie backendów przez API (Nginx Plus, HAProxy stats socket) lub plik konfiguracji (Nginx reload).

Blue/green deployment: dwa zestawy backendów, przełączamy traffic atomicznie. Canary: 5%/25%/50%/100% rampa nowej wersji z automatic rollback przy wzroście błędów. Rolling: po jednym węźle, drain → update → health check → in service. Zero downtime jako standard.

Skalowanie horyzontalne — od 1 do 100+ backendów — load balancer pozwala dodawać kolejne backendy w miarę wzrostu ruchu bez zmian po stronie klienta.

Sticky sessions (cookie-based) dla aplikacji stateful, plain round-robin lub least_conn dla stateless. Auto-scaling z Terraform/Ansible (lokalne VM-y) lub Kubernetes HPA (cloud). Realnie obsługujemy aplikacje 100-100k rps na klastrze 2-16 web serverów.

TCO niższe niż managed hosting / cloud PaaS dla średniego ruchu — własna farma 2 Nginx + 4 backend app servers (16 vCPU, 32 GB RAM każdy) kosztuje ~12-15 tys. zł/mc w kolokacji lub ~3 tys. zł/mc w cenniku VPS, vs.

AWS ALB + 4× t3.xlarge + RDS = ~6-8 tys. USD/mc dla podobnej wydajności. Dla aplikacji obsługujących > 1k rps i przewidywalnego ruchu on-prem / kolokacja zwykle wychodzi 30-60% taniej.

Modele wdrożenia — od pojedynczego Nginx do CDN-fronted klastra

Architektura serwera WWW zależy od skali ruchu, charakteru aplikacji (stateful vs stateless), wymogu HA i geografii użytkowników. Dobieramy model adekwatny do potrzeb:

Single Nginx / Apache — strona firmowa, blog, prosty SaaS — najczęstszy scenariusz dla firm z ruchem do 1-2k rps i pojedynczą aplikacją (WordPress, statyczna strona, korporacyjna witryna).

Nginx jako reverse proxy do PHP-FPM (WordPress, Laravel, Symfony) lub do backendu Node.js/Python/Go, TLS termination, cache statycznych assetów, gzip/brotli compression. Najtańszy w utrzymaniu — to domyślny wybór, jeśli nie wymagamy HA.

Multi-tier — reverse proxy DMZ + app servers w wewnętrznej VLAN — separacja warstw: 1-2 Nginx w DMZ (segment publiczny, TLS termination, WAF, rate limiting), 2-N application servers w prywatnej VLAN (PHP-FPM, Node, Python, .NET, Java), 1-2 database servers w osobnej VLAN bez routingu z DMZ.

Komunikacja edge → app przez HTTPS lub plain HTTP w wewnętrznej sieci z dedykowanym firewallem. Standard dla aplikacji enterprise i regulowanych branż.

Load-balanced cluster — HAProxy / Nginx Plus + N backendów — load balancer (HAProxy 3.0 lub Nginx Plus) z floating IP (keepalived) dystrybuuje ruch między N backendami (zwykle 2-8).

Health checks, drain mode, session persistence, stick tables. Backendy zwykle za reverse proxy dla cachingu i kompresji. Konfiguracja active-active z VRRP lub anycast IP. Wybór dla aplikacji wymagających > 5k rps i HA z RTO < 30 s.

Containerized — Docker / Kubernetes z Ingress Controller — dla aplikacji cloud-native. Nginx Ingress Controller, Traefik 3, HAProxy Kubernetes Ingress, Istio Gateway lub Cilium Ingress dla service mesh.

Auto-discovery backendów przez Kubernetes API, dynamic config bez restartu, integracja z cert-manager (Let’s Encrypt automated), Prometheus metrics, OpenTelemetry tracing. Wybór dla nowoczesnych aplikacji microservices i scenariuszy DevOps.

CDN-fronted — Cloudflare / Akamai / BunnyCDN przed origin — globalna sieć edge przed naszym serwerem WWW: Cloudflare (najczęściej w PL — od free dla małych stron do Enterprise z Bot Management i Magic Transit), Akamai (enterprise), BunnyCDN (budżetowy, EU-based).

Korzyści: globalne cache statycznych assetów (TTFB 20-50 ms vs 200-400 ms dla origin w PL), L7 DDoS protection w cenie, hide origin IP. Stosujemy selektywnie — dla startupów i firm globalnych daje znaczącą wartość; dla lokalnych firm B2B obsługujących polski rynek często nie ma uzasadnienia.

Hybrid — origin on-prem + cache na edge cloud — origin web server pozostaje on-prem (kontrola, compliance, niskie koszty), cache na Cloudflare lub BunnyCDN dla publicznych assetów.

Dla aplikacji z dużą ilością statycznych zasobów (e-commerce z 10k+ zdjęciami produktów, portal informacyjny) cache na edge daje 80-95% redukcję ruchu do origin. Pełna kontrola nad krytycznymi danymi (zostają on-prem), CDN tylko dla cacheowalnych zasobów.

Reverse proxy bridge — wystawienie aplikacji legacy w internet — Nginx jako reverse proxy stojący przed wewnętrzną aplikacją legacy (stary system ERP, panel klienta), która sama nie wspiera HTTPS, nowoczesnych ciphers ani modern security headers.

Nginx dodaje warstwę TLS, WAF, rate limiting, authentication (basic auth, OAuth2 Proxy, Authelia, Keycloak). Często stosowane przy wdrożeniach NIS2 dla firm z legacy IT, które nie mogą zmodernizować backendów.

Technologie, licencjonowanie i ekosystem

Dobór silnika, load balancera, WAF i CDN to integralna część projektu warstwy edge:

Nginx OSS vs Nginx Plus — Nginx OSS (open-source, BSD license, zero cost) wystarcza w 80% scenariuszy dla SMB i mid-market. Nginx Plus (subskrypcja, ~3-5 tys.

USD/instance/rok) dodaje: active health checks (zamiast pasywnych w OSS), session persistence (sticky cookies), dynamic upstream reconfig przez API bez reload, JWT validation, mod_session, dashboard NGX Plus, dedykowane wsparcie F5 24/7. Dla aplikacji finansowych i mission-critical Plus zwykle się opłaca.

Apache HTTPD 2.4 — kiedy nadal ma sens — Apache pozostaje preferowany dla: 1) WordPress hosting z .htaccess (chociaż Nginx też potrafi obsłużyć WP), 2) klasycznego LAMP z mod_php (Nginx wymaga PHP-FPM), 3) hostingu współdzielonego (cPanel/Plesk natywnie wspierają Apache), 4) integracji z mod_perl, mod_python, WebDAV.

MPM event w 2.4 znacząco zniwelował przewagę Nginx pod kątem wydajności — różnica < 20% dla typowych workloads, znika przy odpowiednim tuningu.

HAProxy 3.0 vs Nginx Plus jako load balancer — HAProxy 3.0 (OSS) — najszybszy load balancer L4/L7 (100k+ rps na pojedynczym węźle przy single core), zaawansowane ACL, stick tables, peers protocol dla replikacji sesji między instancjami, runtime API.

Nginx Plus — gorszy raw performance, ale jeden produkt dla reverse proxy + load balancer + cache + WAF + API gateway. Dla pure load balancera HAProxy; dla połączonej funkcji Nginx Plus. HAProxy Enterprise (~5-10 tys. USD/instance/rok) dla wsparcia komercyjnego.

Traefik 3 i Caddy — dla cloud-native i automation-first — Traefik 3 (OSS, MIT) — Edge Router dla Docker, Kubernetes, Consul, Nomad z auto-discovery, dashboardem, natywnym Let’s Encrypt, middlewarami (rate limit, IP whitelist, headers).

Caddy 2 (OSS, Apache 2) — serwer z domyślnym HTTPS (automatic Let’s Encrypt), prosta konfiguracja (Caddyfile), HTTP/3 by default, pluginy (caddy-security, caddy-l4). Caddy świetny dla małych projektów i developerów; Traefik dla Kubernetes-first organizacji.

OpenResty i Lua dla zaawansowanej logiki edge — OpenResty (fork Nginx z LuaJIT) pozwala na pisanie złożonej logiki w fazach HTTP request lifecycle (rewrite, access, content, log) bez wywoływania backendu.

Real-world: dynamic routing per tenant, A/B testing na edge, request signing, custom rate limiting per użytkownik, edge authentication (JWT verify), API monetization (token bucket per API key). Używamy gdy klient ma zaawansowane wymagania edge logiki niedostępne w standardowym Nginx.

WAF — ModSecurity vs F5 Advanced WAF vs Cloudflare WAF — ModSecurity 3 + OWASP CRS 4.x (free, open-source) — standard dla on-prem, ~80-90% pokrycia OWASP Top 10 po tuningu. F5 Advanced WAF (~10-50 tys.

USD/instance/rok) — enterprise, behavioral analytics, bot protection, L7 DDoS, dedykowane wsparcie. Cloudflare WAF (od $20/mc Pro do Enterprise) — managed rulesets, AI-based bot detection, free Tier dla podstawowych reguł. Dla 90% klientów ModSecurity wystarcza; dla finansów i regulowanych branż F5 lub Cloudflare Enterprise.

Certyfikaty SSL/TLS — Let’s Encrypt vs commercial CA — Let’s Encrypt (free, automated ACMEv2, 90-day cert, certbot/acme.sh) — domyślny wybór dla 95% scenariuszy.

Commercial CA (DigiCert, Sectigo, GlobalSign, ~500-3000 zł/rok) — kiedy potrzeba EV (zielony pasek został usunięty z przeglądarek, ale niektóre firmy wciąż chcą), wildcard z manualnym DNS validation, wsparcie dla bardzo starych klientów (Android 4.x), certyfikaty dla intranetu z prywatnym CA. Wildcard Let’s Encrypt też jest dostępny (DNS-01 challenge).

CDN — Cloudflare vs Akamai vs BunnyCDN vs Fastly — Cloudflare (najpopularniejszy globalnie, free / Pro / Business / Enterprise, świetne dla SMB) — anti-DDoS, WAF, CDN, DNS, Workers (edge compute).

Akamai (enterprise, drogie ale najbardziej dojrzałe) — sektor finansowy, media. BunnyCDN (budżetowy, EU-based, ~$10-50/mc) — świetny dla małych firm. Fastly (real-time purging, programmable edge) — gaming, media. Dla virtline.com nie używamy CDN (on-prem); dla klientów stosujemy selektywnie.

Dla kogo wdrażamy serwery WWW — segmenty i scenariusze

Skalę, architekturę i stos technologiczny dopasowujemy do organizacji, profilu aplikacji i wymogów branżowych:

Małe firmy (SMB) — strona firmowa, blog, prosty SaaS — pojedynczy Nginx 1.27 na Ubuntu Server LTS lub Rocky Linux, TLS 1.3 z Let’s Encrypt (auto-renew), gzip/brotli, podstawowy WAF (ModSecurity z core rules), fail2ban, monitoring przez Zabbix lub Uptime Kuma.

Czas wdrożenia: 3-5 dni, koszt: 5-15 tys. zł netto z konfiguracją i hardening.

Średnie firmy — multi-tier z reverse proxy + 2-4 backendami — 2 Nginx w DMZ (active-active z keepalived + floating IP) + 2-4 application servers + 1-2 database servers w wewnętrznej VLAN, ModSecurity z OWASP CRS 4.x, CrowdSec, monitoring Prometheus + Grafana, log aggregation Loki/ELK, blue/green deployment.

Wdrożenie: 3-6 tygodni, koszt 30-80 tys. zł netto.

Enterprise — load-balanced cluster z WAF i SIEM integration — HAProxy 3.0 lub Nginx Plus jako load balancer (active-active z VRRP), 4-16 web/app servers, dedykowany WAF (F5 Advanced lub ModSecurity tuned + commercial threat intel), SIEM integration (Splunk, Sentinel, Wazuh), red team / blue team exercises kwartalnie.

Wdrożenia 3-9 miesięcy z dedykowanym project managerem i security architectem.

E-commerce z wymogiem HA i obsługą peak traffic — cluster Nginx + Varnish lub Nginx z proxy_cache dla statycznych assetów + dynamiczny content cache (TTL 1-5 min z PURGE API), CDN przed (Cloudflare/BunnyCDN) dla obrazów produktów, WAF blokujący scraping cen i botów scalperów, rate limiting per IP/user, auto-scaling backendów.

Pre-Black-Friday testy obciążeniowe k6 / Locust dla 5-10× normalnego ruchu.

Branże regulowane — finanse, healthcare, sektor publiczny, energetyka — wzmocniony hardening (CIS Level 2, FIPS 140-2 mode), enterprise WAF (F5 Advanced lub Imperva), HSM dla kluczy prywatnych TLS (Thales nShield, AWS CloudHSM), 4-eye principle dla deploymentów, immutable infrastructure (Terraform/Ansible w git, peer review), pentesty kwartalnie, audyt zgodności NIS2/DORA/KNF co 6 miesięcy.

API B2B z autoryzacją OAuth2/JWT/mTLS — Nginx Plus lub Traefik 3 z natywną JWT validation (weryfikacja podpisu na edge bez wywołania backendu), mTLS dla partnerów B2B (klient prezentuje certyfikat z CA klienta), rate limiting per API key, quota enforcement, API monetization.

Integracja z Keycloak / Auth0 / Okta jako Authorization Server.

Aplikacje SaaS z multi-tenancy — Nginx z dynamic routing per tenant (host header lub URL prefix), OpenResty + Lua dla tenant-aware logic (osobne limity, osobne cache, tenant isolation w logach), wildcard TLS + per-tenant SAN cert, izolacja CSP per aplikacja.

Skalowanie horyzontalne — backendy łączą się z dedykowanymi schematami DB per tenant.

Modernizacja legacy — wystawienie starych aplikacji w internet — reverse proxy bridge dla stacków, które same nie wspierają TLS 1.3 lub modern security: stary system ERP na Windows Server 2008, panel kliencki w PHP 5.x, aplikacja Java z stary Tomcat.

Nginx jako edge dodaje TLS, WAF, modern security headers, opcjonalnie SSO przez OAuth2 Proxy / Authelia. Klient nie musi przepisywać backendu — bridge w 2-4 tygodnie.

Etapy współpracy — od audytu architektury do SLA

Każde wdrożenie serwera WWW prowadzimy w 5 udokumentowanych etapach z punktami akceptacji klienta:

1.

Audyt architektury i wymagań — analiza obecnego stacku (jeśli istnieje), profilu ruchu (rps średnio i w peak, geografia użytkowników, typ contentu — statyczny vs dynamiczny, cacheowalny vs personalizowany), aplikacji backendowych i ich limitów, wymogów compliance (NIS2, ISO 27001, RODO, branżowych regulacji KNF/UKE), budżetu CAPEX/OPEX. Skanowanie podatności obecnej konfiguracji (testssl.sh, nikto, nmap, sslyze, Mozilla Observatory, SSL Labs).

2.

Projekt architektury — diagramy, capacity planning, HA design — diagram L3/L4/L7 (firewall → DMZ → reverse proxy → VLAN app → VLAN DB), wybór technologii (Nginx vs Apache vs IIS, HAProxy vs Nginx Plus, ModSecurity vs commercial WAF), capacity planning (rps przepustowość, latency budget, storage dla logów i cache), strategia HA (active-active vs active-passive, RTO/RPO targets), strategia certyfikatów TLS, strategia CI/CD i deploymentów.

3.

Instalacja, konfiguracja, hardening i testy laboratoryjne — instalacja minimalnego systemu (Ubuntu Server LTS, Rocky Linux, Debian stable), hardening zgodny z CIS Benchmark Level 1/2, instalacja Nginx/Apache/IIS z minimalnymi modułami, konfiguracja TLS 1.3 z Mozilla Modern, ModSecurity z OWASP CRS 4.x, fail2ban/CrowdSec, monitoring Prometheus exporters, log shipping do Loki/ELK. Testy w środowisku stagingowym: SSL Labs A+, Mozilla Observatory A+, securityheaders.com A+, testy obciążeniowe k6/wrk (target rps verification).

4.

Migracja, cutover i testy akceptacyjne (UAT) — migracja konfiguracji ze starego stacka (jeśli istniał), test pre-cutover na stagingu, DNS lowering TTL 24 h przed cutover, cutover w oknie serwisowym (zwykle 23:00-03:00) z możliwością instant rollback (przywrócenie DNS lub keepalived priority), monitoring real-time przez 24 h po cutover, regression testing (testy automatyczne wszystkich endpointów), pomiar CWV przed/po.

5.

SLA, monitoring i ciągłe doskonalenie — outsourcing administracji web servera z SLA (15-minutowy czas reakcji dla awarii krytycznej P1), monitoring automatyczny w trybie ciągłym (Prometheus + Alertmanager + PagerDuty, Grafana dashboards, Loki dla logów), tygodniowy raport stanu (rps, error rate, latency p50/p95/p99, blocked attacks WAF), kwartalny audyt konfiguracji (CIS, Mozilla, SSL Labs), roczny pentest, ciągłe doskonalenie (tuning WAF false-positives, optimisation cache hit ratio).

Dlaczego serwer WWW z Virtline

Łączymy 15+ lat wdrożeń webowych z odpowiedzialnością za dostępność i bezpieczeństwo Twoich aplikacji:

Certyfikat ISO/IEC 27001:2023 — wystawiony przez TÜV NORD, nr AC090 121/2469/6137/2026 (ważny do 02.2029).

Wdrażamy serwery WWW zgodnie z udokumentowanym Systemem Zarządzania Bezpieczeństwem Informacji — administratorzy mają NDA, procedury zmian, regularne szkolenia, audyty wewnętrzne. Dla klienta to gwarancja, że pracujemy zgodnie z normą, nie ad hoc.

Certyfikowani inżynierowie Nginx, F5, AWS i Cloudflare — Nginx Certified Engineer, F5 BIG-IP Administrator, AWS Solutions Architect Professional (SAP-C02), Cloudflare Accredited Engineer, RHCE / LFCE dla warstwy systemowej.

Realne wdrożenia produkcji dla aplikacji obsługujących 100-100k rps w finansach, e-commerce, mediach, sektorze publicznym i SaaS.

Doświadczenie z hardeningiem i pentestami — każdy nasz web server kończy się: SSL Labs A+ (minimum), Mozilla Observatory A+, securityheaders.com A+, Internet.nl 100%, CIS Benchmark Level 1 minimum (Level 2 dla regulowanych).

Współpracujemy ze stałymi partnerami pentestowymi (TestArmy, Securitum) — każda nowa konfiguracja przechodzi black-box i white-box test przed produkcją.

Ochrona przed OWASP Top 10 i botami w standardzie — każde wdrożenie zawiera ModSecurity 3 z OWASP CRS 4.x tuned, fail2ban + CrowdSec, rate limiting, security headers A+, audyt nadmiarowych portów i metod HTTP.

Klienci z naszymi web serverami nie tracą dostępności przy typowych atakach automated scanning, brute force i scraping — 70-95% złego ruchu odrzucane na edge.

SLA 24/7 z gwarantowanym czasem reakcji — monitoring web servera, certyfikatów (expiry alerty 30/14/7/1 dni przed), upstream backendów, WAF event count, error rate.

Reakcja na alert P1 (web server down, certyfikat wygasł, error rate > 5%) w 15 minut, eskalacja do inżyniera dyżurnego w 30 minut, helpdesk po polsku. Tygodniowy raport stanu, kwartalny audyt zgodności, roczny pentest.

FAQ: Wdrożenie serwera WWW — najczęstsze pytania

Nginx vs Apache — który wybrać do nowego projektu?

Dla nowych wdrożeń preferujemy Nginx 1.27, zwłaszcza dla: 1) aplikacji wymagających wysokiej współbieżności (event loop, 10k+ równoczesnych połączeń na worker), 2) reverse proxy do backendów Node.js, Python, Go, Java, .NET Core, 3) cachingu statycznych assetów, 4) load balancera dla wielu backendów. Apache HTTPD 2.4 z MPM event pozostaje wyborem, gdy: 1) hostujemy klasyczne aplikacje LAMP z mod_php, 2) wymagamy .htaccess (override per katalog), 3) używamy mod_perl, mod_python, WebDAV, 4) integrujemy z cPanel/Plesk. Realnie różnica wydajności po prawidłowym tuningu jest mniejsza niż 20% — kluczowy jest stack aplikacji, doświadczenie zespołu i compatibility.

Niektóre korporacje mają ścisłe standardy IIS (.NET) lub Apache (legacy LAMP) i to też wpływa na wybór.

HTTP/2 vs HTTP/3 — kiedy migracja na QUIC ma sens?

HTTP/2 (RFC 7540) jest dziś defaultem dla 99% publicznych stron — multiplexing eliminuje head-of-line blocking warstwy aplikacji, HPACK kompresuje nagłówki, jeden TCP connection per origin. Wsparcie 95%+ przeglądarek od 2019. HTTP/3 nad QUIC (RFC 9114) dodatkowo eliminuje HoL blocking warstwy transportu (każdy stream niezależny), wsparcie 0-RTT (faster reconnect), lepsze zachowanie na sieciach z packet loss (3G/4G/5G, WiFi w ruchu). Migracja HTTP/3 ma realny ROI dla: 1) publicznych stron content-heavy odwiedzanych przez mobile (e-commerce, news), 2) globalnej publiczności (różne sieci, dystans od origin), 3) aplikacji z high concurrent connections.

Mniej istotna dla: 1) API B2B (przewidywalne klienty, wysokiej jakości sieć), 2) intranetów, 3) aplikacji wewnętrznych. Włączamy HTTP/3 selektywnie tam, gdzie ma znaczenie.

Reverse proxy vs forward proxy — co znaczy każdy termin?

Reverse proxy stoi po stronie serwera — przyjmuje połączenie od klienta z internetu i przekazuje je do wewnętrznego backendu. Klient nie wie, do którego backendu trafia. Przykłady: Nginx jako reverse proxy do PHP-FPM, Cloudflare jako reverse proxy przed origin. Funkcje: TLS termination, caching, WAF, load balancing, hiding internal infrastructure, kompresja, rate limiting. Forward proxy stoi po stronie klienta — przyjmuje wychodzące połączenia z wewnętrznej sieci i przekazuje je do internetu. Serwer docelowy nie wie, kto faktycznie wysłał request. Przykłady: Squid jako corporate proxy filtrujący ruch wychodzący z biura, Privoxy dla prywatności. Funkcje: content filtering, URL whitelisting, caching wychodzących requestów, anonymity.

Dla web servera 99% scenariuszy to reverse proxy.

ModSecurity vs Cloudflare WAF vs F5 Advanced WAF — który wybrać?

ModSecurity 3 + OWASP CRS 4.x (free, open-source, on-prem) — domyślny wybór dla SMB i mid-market: ~80-90% pokrycia OWASP Top 10 po tuningu, pełna kontrola nad regułami, brak vendor lock-in, integracja z Nginx i Apache. Wada: wymaga tuningu false-positives (zwykle 1-3 tygodnie dla średniej aplikacji). Cloudflare WAF (od $20/mc Pro do Enterprise) — managed rulesets aktualizowane automatycznie przez Cloudflare, AI-based bot detection, L7 DDoS w cenie. Wada: dane lecą przez Cloudflare (compliance issue dla niektórych branż). F5 Advanced WAF / Imperva (10-50 tys. USD/instance/rok) — enterprise, behavioral analytics, bot management, dedykowane wsparcie w godz. pn-pt 7-17 oraz monitoring automatyczny, zaawansowana detekcja API abuse.

Dla 90% klientów ModSecurity wystarcza; dla finansów i regulowanych branż z budżetem F5/Imperva.

Let’s Encrypt vs commercial CA — który certyfikat wybrać?

Let’s Encrypt (free, automated ACMEv2, 90-day validity, auto-renew przez certbot/acme.sh) — domyślny wybór dla 95% scenariuszy: strony korporacyjne, sklepy, SaaS, API B2B. Każda przeglądarka i klient go akceptuje, wsparcie wildcard (DNS-01 challenge). Commercial CA (DigiCert, Sectigo, GlobalSign, ~500-3000 zł/rok) ma sens dla: 1) wsparcia bardzo starych klientów (Android 4.x, Java 7 bez aktualnych root CA — coraz rzadszy scenariusz), 2) EV certificates (zielony pasek został usunięty przez Chrome/Firefox w 2019/2020, więc EV praktycznie stracił sens), 3) intranet z prywatnym CA (private PKI z Microsoft AD CS lub HashiCorp Vault), 4) compliance wymagający commercial CA (rzadko, ale niektóre branże).

Realnie: 95% naszych klientów na Let’s Encrypt, 5% na commercial dla legacy support.

Load balancer Layer 4 vs Layer 7 — czym się różnią?

Layer 4 (transport, TCP/UDP) — load balancer widzi tylko adres IP klienta, port, protocol. Decyzja routingu na podstawie connection-level metrics (least connections, round-robin). Plusy: bardzo wysoka wydajność (~milion connections/s na nowoczesnym hardware), niska latencja (~mikrosekundy), wsparcie dla protokołów innych niż HTTP (MySQL, Redis, SMTP). Minusy: brak inspekcji treści, brak TLS termination (lub przepuszczanie zaszyfrowanego ruchu), brak session affinity opartej o cookies/headers. Przykład: HAProxy w trybie mode tcp, AWS NLB. Layer 7 (aplikacja, HTTP/HTTPS) — load balancer rozumie HTTP, może podejmować decyzje na podstawie URL, Host header, cookies, user agent.

Plusy: TLS termination, content-based routing, session persistence (sticky cookies), WAF, caching, response manipulation. Minusy: niższa wydajność (~setki tysięcy rps), wyższa latencja (~milisekundy). Przykład: Nginx, HAProxy w mode http, AWS ALB. W praktyce większość aplikacji webowych potrzebuje L7.

Czy potrzebny jest CDN dla małej firmy obsługującej polski rynek?

Zwykle NIE — CDN ma realny ROI dla: 1) globalnej publiczności (użytkownicy w US, Azji — bez CDN ich TTFB to 200-400 ms, z CDN 20-50 ms), 2) content-heavy stron z dużą liczbą obrazów/wideo (cache na edge oszczędza 80-95% ruchu do origin), 3) ekspozycji na L7 DDoS (Cloudflare Pro/Business filtruje przed dotarciem do origin). Dla małej firmy B2B z origin w polskim DC i klientami w PL: bez CDN TTFB to 30-80 ms — już bardzo dobry. CDN dodałby latencji (Cloudflare ma PoP w Warszawie, ale i tak round-trip jest dodatkowy) plus koszt subskrypcji ($20-200/mc Cloudflare Pro/Business). Dodatkowo dla niektórych branż (sektor publiczny, niektóre części finansów) CDN to compliance issue — dane lecą przez third-party.

Decyzja indywidualnie: jeśli klient nie ma globalnej publiczności i nie potrzebuje L7 DDoS protection > poziomu free, CDN to over-engineering.

HSTS preload list — warto włączać?

HSTS (Strict-Transport-Security) wymusza HTTPS i blokuje SSL stripping — header w odpowiedzi mówi przeglądarce „przez X sekund nigdy nie łącz się ze mną przez HTTP”. Preload list (zgłoszenie domeny do hstspreload.org) wpisuje domenę w hardcoded listę Chrome/Firefox/Safari — przeglądarka NIGDY nie próbuje HTTP nawet przy pierwszym wejściu, eliminuje window of opportunity dla MitM. Warto włączyć dla: 1) stron, które są wyłącznie HTTPS i taka pozostaną (włączenie preload to one-way decision — usunięcie z listy trwa miesiącami), 2) wszystkich subdomen z HTTPS (includeSubDomains required).

NIE włączać jeśli: 1) jakakolwiek subdomena ma legacy HTTP-only service, 2) jest ryzyko utraty certyfikatu (preload to lock-in na HTTPS — jeśli stracisz cert, klienci na preload list nie mogą wejść na stronę nawet po HTTP fallback). Dla 90% nowoczesnych webowych projektów warto włączyć — HSTS bez preload (max-age 1-2 lata + includeSubDomains) plus zgłoszenie preload po 6-12 miesiącach stabilnej konfiguracji.

DDoS protection — własna konfiguracja czy CDN?

Zależy od skali ataku i krytyczności biznesu. Małe ataki L7 (100-10000 rps z jednego/kilku IP) — bez problemu Nginx z rate_limit + fail2ban / CrowdSec dają sobie radę. Średnie ataki (10-100k rps, kilkadziesiąt IP) — wymagają tuning rate limit per IP / per region + CrowdSec collaborative blocklist, lub upgrade do większej maszyny z więcej CPU. Duże ataki L7 (100k-1M+ rps z botnetów, zaawansowane techniki jak slow Loris, RUDY, R-U-Dead-Yet) — własną infrastrukturą trudno obronić bez specjalistycznego sprzętu. CDN z anti-DDoS (Cloudflare Pro Business / Enterprise, Akamai Kona, AWS Shield Advanced) ma globalną sieć absorbującą 100+ Gbps ruchu z setek tysięcy IP.

Dla biznes-krytycznych aplikacji (e-commerce, fintech, healthcare) z realnym ryzykiem ataków zalecamy CDN-based DDoS protection. Dla typowego SMB B2B własna konfiguracja Nginx + fail2ban wystarcza w 95% przypadków.

Audyt bezpieczeństwa web servera — co konkretnie sprawdzamy?

Pełen audyt obejmuje: 1) Konfigurację TLS — testssl.sh, sslyze, SSL Labs (target A+), wykrycie obsolete ciphers, TLS 1.0/1.1, weak DH params, brak OCSP stapling. 2) Security headers — securityheaders.com, Mozilla Observatory (target A+) — HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy. 3) Konfigurację serwera HTTP — nikto, dirbuster — wykrycie default files, ekspozycji /server-status, /server-info, /phpinfo.php, /.git, /.env, /admin/, /backup/. 4) Listing katalogów (Indexes off w Apache, autoindex off w Nginx). 5) Metody HTTP — wyłączone OPTIONS, TRACE, HEAD, PUT, DELETE (jeśli nieużywane). 6) Server header — usunięty lub maskowany (server_tokens off w Nginx, ServerTokens Prod ServerSignature Off w Apache).

7) Konfiguracja WAF — testy z curated payload (sqlmap, XSS Hunter), false-positive rate na rzeczywistym ruchu. 8) Logi — kompletny access log, error log z odpowiednim level (notice/warn), shipping do SIEM. 9) System operacyjny — CIS Benchmark Level 1/2, AppArmor/SELinux enforcement, unattended-upgrades. 10) Penetration test (black-box i white-box) z certyfikowanym pentesterem (OSCP, OSWE).

---

Certyfikacja ISO/IEC 27001:2023

Serwery WWW wdrażamy zgodnie z normą ISO 27001

Virtline posiada certyfikat PN-EN ISO/IEC 27001:2023-08 wydany przez TÜV NORD. Numer certyfikatu: AC090 121/2469/6137/2026, ważny do 02.2029. Nasze wdrożenia serwerów WWW realizują wymagania Annex A.5.23 (bezpieczeństwo w usługach chmurowych), A.8.20 (bezpieczeństwo sieci), A.8.23 (filtrowanie sieci), A.8.24 (używanie kryptografii) oraz A.5.15-A.5.18 (kontrola dostępu), wspierają zgodność z dyrektywą NIS2, rozporządzeniem DORA i wymogami RODO oraz OWASP Top 10.

Sprawdź certyfikat ISO 27001 →

• Outsourcing IT — kompleksowa obsługa informatyczna
• Audyt sieci komputerowych — topologia, segmentacja, podatności
• Wdrożenie firewalla — NGFW, UTM, segmentacja
• Monitoring IT 24/7 — Zabbix, Prometheus, Grafana
• Dyrektywa NIS2 — zgodność dla podmiotów kluczowych
• EDR — Endpoint Detection and Response
• Wdrożenie Active Directory — domena Windows i hybrid identity
• Wdrożenie serwerów plików — SMB, DFS, S2D
• Kopia bezpieczeństwa danych — backup zgodny z 3-2-1-1-0

Polecane usługi i artykuły

• Audyt NIS2
• Audyt DORA
• Audyt TISAX
• Audyt AI Act
• Certyfikat ISO/IEC 27001