Bezpečnost webu v roce 2026: HTTPS, 2FA, WAF, zálohy 3-2-1 — kompletní průvodce

Jak ochránit web před hackery: 7 kroků, které opravdu fungují

Podle našeho názoru lze klidně říct, že nezabezpečený web v roce 2026 žije přesně do okamžiku, kdy ho najde první automatický skener. A najdou každého — protože boti procházejí celý internet a hledají dvě věci: otevřené administrace a zastaralé CMS. Velký portál s inženýrským týmem a malý WordPress blog jsou pro ně stejný cíl, protože útok je hromadný a nepersonalizovaný.

Paradox je v tom, že 90 % skutečných incidentů nejsou složité cílené útoky, ale elementární věci: slabé heslo administrátora, plugin, který nebyl aktualizován rok a půl, nebo otevřený 22. port s root loginem. Hackeři web „nehackují" — vstupují tam přes to, co majitel sám nechal otevřené.

Níže jsme pro vás připravili 7 kroků, které opravdu fungují. Bez vaty o „hrozbách digitální éry" — konkrétní nastavení, která dáváme klientům po incidentech a která by stálo za to nasadit před nimi.

Co byznys po napadení skutečně ztrácí

Mnoho lidí přemýšlí v kategoriích „ukradnou data" nebo „zašifrují soubory". Skutečné dopady jsou složitější a finanční ztráty často nepřicházejí ze samotného útoku, ale z toho, co se děje potom.

1. Vypadnutí z vyhledávání Google

Pokud Google Safe Browsing odhalí na webu škodlivý kód, web dostane ve výsledcích vyhledávání označení „Tento web může poškodit váš počítač" a uživatelé místo obsahu uvidí červenou obrazovku. Návrat do indexu po vyčištění trvá od několika dní do několika týdnů — a celou tu dobu je organická návštěvnost prakticky nulová.

2. Blokace na úrovni prohlížečů

Chrome, Safari i Firefox se synchronizují se seznamy škodlivých webů. To znamená, že i když má někdo přímý odkaz, prohlížeč ho prostě nepustí bez extra kliknutí „Pokračovat přesto". Konverze takové „návštěvnosti" se blíží nule.

3. Právní následky

Únik osobních údajů (e-maily, telefony, historie objednávek) spadá pod GDPR v Evropě nebo příslušný zákon o ochraně osobních údajů v konkrétní jurisdikci. Pokuty se počítají z obratu firmy a oznámit dotčeným zákazníkům je zákonná povinnost — což je samostatná reputační krize.

4. Těžba a spam ve vašem jménu

Napadený web zřídka stojí nečinně, protože nejčastěji je zapojen do takzvaného botnetu — začne rozesílat spam, těžit kryptoměny, útočit na jiné weby. Majitel se o tom dozví z účtu za přenesená data nebo od hostingového poskytovatele, který server zablokuje za zneužívání.

Krok 1. HTTPS + HSTS — základní minimum

HTTPS v roce 2026 už není ani otázka bezpečnosti, ale technická hygiena. Bez něj moderní prohlížeče zobrazují varování, přihlašovací formuláře jsou označeny jako nebezpečné a Google web ve výsledcích snižuje. Jakákoli Wi-Fi v kavárně je potenciální místo odposlechu provozu, pokud web jede přes čisté HTTP.

Jaký certifikát vybrat

HSTS — druhá vrstva nad HTTPS

Samotné HTTPS nezachrání před downgrade útokem, kdy útočník donutí prohlížeč otevřít web přes HTTP při prvním spojení. HSTS hlavička říká prohlížeči: „s touto doménou jezdi výhradně přes HTTPS, bez výjimek".

Pro Nginx se přidává jedním řádkem do server bloku:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Krok 2. Aktualizace CMS, pluginů a knihoven

Zastaralý software je hlavní příčinou napadení ve statistikách CVE. WordPress, který obsluhuje zhruba 43 % všech webů na světě, vede ne proto, že by byl nebezpečný z principu, ale proto, že je masový. Samotný CMS se aktualizuje rychle — problémy začínají na straně pluginů a šablon.

Co dělat s jádrem CMS

• Zapnout automatické minor aktualizace — to jsou bezpečnostní záplaty, neporušují kompatibilitu.
• Major aktualizace (5.x → 6.x) instalovat ručně po testu na staging kopii webu.
• Přihlásit se k odběru bezpečnostního newsletteru vývojáře CMS — kritické díry se často zavírají nouzovými záplatami.

Co dělat s pluginy a šablonami

• Jednou měsíčně provádět audit: smazat vše, co nepoužíváte. Méně kódu znamená menší útočnou plochu.
• Kontrolovat datum poslední aktualizace pluginu. Pokud vývojář nevydal opravy déle než 12 měsíců — to je červený praporek, plugin je fakticky opuštěný.
• Nikdy neinstalujte „nulled" placené šablony z torrentů. V 99 % případů je tam zašitý backdoor, který bude tiše pracovat, dokud web nezneužijí na spam.

Pravidlo před aktualizacemi

Před jakoukoli major aktualizací — záloha. Před aktualizací velkého e-commerce pluginu (WooCommerce, Magento moduly) — záloha a staging test. Záloha udělaná „až potom" nepomůže s ničím.

Krok 3. Hesla a dvoufaktorová autentizace

Většina vážných napadení administrací není „hackerství", ale banální brute-force nebo credential stuffing (zkoušení hesel uniklých z jiných míst). Boti zkoušejí 24/7, a pokud je heslo admin / 123456 / qwerty — je to otázka pár minut.

Jak vypadá normální heslo v roce 2026

• Délka — od 16 znaků. Složitost je důležitější méně než délka: correct horse battery staple se prolomí hůř než P@ss1!
• Unikátní pro každou službu. Pokud je heslo jedno na 10 účtů — po prvním úniku je všech 10 v rizikové zóně.
• Vygenerované, ne vymyšlené v hlavě. Náhodný řetězec 20–30 znaků se nedá zapamatovat — a není to třeba, od toho jsou manažery.
• Neukládá se v textovém souboru, v prohlížeči bez master hesla nebo v messengeru. Pouze ve specializovaném manažeru: Bitwarden, 1Password, KeePassXC (které mají stejně vestavěný generátor).

2FA — to, co zastaví 99 % automatických útoků

Dvoufaktorová autentizace přidává druhou vrstvu nad heslo: jednorázový kód z mobilní aplikace. I když heslo zcela unikne, bez přístupu k telefonu se útočník dovnitř nedostane. Není to marketing — je to základní standard, který by měl být zapnutý všude, kde jsou byť trochu citlivá data.

Krok 4. Ochrana na úrovni serveru

Hosting je základ. Pokud je server špatně nakonfigurován, i dokonale chráněný web bude zranitelný: útočí se na operační systém, síťovou vrstvu nebo sousední weby na stejném serveru. Klíčová otázka pro poskytovatele tedy není „kolik CPU", ale „jak izolujete projekty a co se síťovou ochranou".

Základní stack serverové ochrany

1. Web Application Firewall (WAF)

WAF analyzuje HTTP provoz dřív, než dorazí na web, a blokuje typické vzory útoků: SQL injekce, XSS, pokusy o path traversal, exploity konkrétních CVE. Na úrovni serveru to může být ModSecurity s pravidly OWASP CRS, na úrovni CMS — Wordfence nebo Sucuri.

2. Ochrana proti DDoS

Volumetrické útoky (silné toky odpadního provozu) se v roce 2026 měří v desítkách a stovkách Gbit/s. Samostatně z jednoho serveru se proti nim ubránit nelze — potřebujete infrastrukturu s filtry na úrovni datového centra. Útoky na aplikační vrstvě (pomalé požadavky vypadající jako legitimní) chytá už WAF.

3. Izolace projektů

Na kvalitním VPS hostingu sedí každý klient ve vlastním KVM kontejneru s vyhrazenými prostředky — útok na souseda se vašeho serveru fyzicky nemůže dotknout, protože izolace je zajištěna na úrovni hypervisoru. Máte vlastní jádro OS, vlastní firewall, vlastní logy — nic z toho „neprosakuje" mezi klienty. Pokud někomu na stejném železe napadnou projekt, ten váš stojí stranou.

4. Fail2ban proti brute-force

Utilita, která monitoruje logy (auth.log, nginx access.log) a automaticky banuje IP adresy po N neúspěšných pokusech. Základní konfigurace pro SSH:

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600

3 neúspěšné pokusy za 10 minut — ban na hodinu. Pro administrace CMS se píše samostatný filtr pro /wp-login.php nebo /administrator.

💡 Jednoduchý dodatečný trik: změňte výchozí SSH port z 22 na něco nestandardního (například z rozsahu 49152+). Nezastaví to cílený útok — pokud se na váš server někdo zaměří konkrétně, skener portů nový stejně najde. Ale drtivá většina automatického brute-force buší jen na port 22, takže tato změna okamžitě odřízne hlavní masu šumu v logech.

5. Omezení přístupu do administrace podle IP

Pokud chodíte do administrace z několika stálých lokací (kancelář, domov, VPN), má smysl ji uzavřít zcela na úrovni nginx:

    location /wp-admin {
    allow 198.51.100.42;   # kancelář
    allow 203.0.113.0/24;  # pracovní VPN
    deny all;
}

6. Security Headers

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' https:; script-src 'self'" always;

CSP je nejsložitější z nich — musí se ladit pro konkrétní web, jinak rozbije analytiku a externí skripty. Úroveň své ochrany můžete ověřit na securityheaders.com.

Krok 5. Pravidelné skenování škodlivého kódu

I při dokonalém nastavení může web dostat malware jiným vektorem: virus na pracovní stanici administrátora ukradl FTP přístupy, nebo jeden z vývojářů omylem commitnul do repozitáře klíče od produkce. Proto pravidlo „důvěřuj, ale prověřuj" není fráze, ale pracovní princip.

Co skenovat a čím

• Souborový systém: ClamAV, maldet (Linux Malware Detect), Imunify360. Spouštět přes cron minimálně jednou denně pro aktivní projekty.
• Integrita systémových souborů CMS: Wordfence pro WordPress porovnává soubory s referencemi z oficiálního repozitáře — jakákoli změna vyvolá alert.
• Externí skenování: Sucuri SiteCheck, VirusTotal — kontrolují web z pohledu návštěvníka, chytají přesměrování na phishing a vložené JS.
• Databáze: ve WordPressu útočníci často přidávají falešné adminy nebo vkládají spam do wp_options. Jednou měsíčně stojí za to projít tabulku users a podívat se na post_content na výskyt podivných <script>.

Co dělat, když něco najdete

Krok 6. Princip minimálních oprávnění

Majitelé webů často rozdávají přístupy s logikou „ať má všechno, kdyby náhodou". To je z hlediska bezpečnosti nejhorší přístup. Čím víc lidí má Admin práva, tím víc útočných vektorů na tyto účty a tím těžší je vyšetřit incident.

Rozdělení rolí v CMS

• Administrátor — minimum lidí, ideálně 1–2. Přístup k pluginům, uživatelům, nastavení.
• Editor — pro obsahové manažery. Může publikovat cokoli, ale do pluginů nesahá.
• Autor — pro externí copywritery. Publikuje pouze své materiály.
• SEO / analytika — samostatná role přes plugin typu User Role Editor, přístup pouze k relevantním sekcím.

Přístupy pro vývojáře a dodavatele

• Samostatný SSH klíč pro každého vývojáře. Root přístup nikomu — pro konkrétní příkazy psát pravidla do sudoers.
• SSH pouze přes klíče, autentizace heslem vypnutá (PasswordAuthentication no v sshd_config).
• Přístupy freelancerům — vytvářejte rovnou s nastaveným datem expirace (např. přes chage -E v Linuxu). Pak si nemusíte pamatovat na jejich odstranění po skončení projektu — účet expiruje sám.
• Pro jednorázové úkoly — sudo s logováním místo přímého rootu.

Krok 7. Zálohy podle pravidla 3-2-1

To je poslední linie obrany. Pokud ransomware zašifroval soubory nebo vývojář omylem dropnul produkční databázi — bez zálohy může být ztráta totální a nevratná. Pravidlo 3-2-1 je oborový standard, který vznikl ještě před érou cloudu, a stále platí.

Co znamená „3-2-1"

• 3 kopie dat — originál plus dvě zálohy. Ne jedna, ne „někdy bude potřeba".
• 2 různé typy médií nebo systémů — například záloha na stejném serveru plus záloha ve vzdáleném úložišti. Pokud obě kopie leží na stejném disku, nejsou to dvě kopie.
• 1 kopie zcela oddělená — v cloudu, na jiném kontinentu, offline. Pokud se ransomware dostane na server a zničí lokální zálohy, tahle kopie je to, co zachrání byznys.

Jak často zálohovat

Top 5 chyb, které dělá skoro každý

1. „Můj web je moc malý, koho bych zajímal." Boti nevybírají oběti podle velikosti byznysu. Skenují /16 a /24 podsítě po řadě a hledají známé díry. Malý web je zajímavý právě tím, že ho nikdo nehlídá.
2. Jedno heslo na hosting, doménu a poštu. Pokud heslo unikne z kteréhokoli ze tří, útočník získává kontrolu nad vším. Včetně možnosti převést doménu k jinému registrátorovi.
3. „Zálohu má hosting, proč bych ji měl mít vlastní." Zálohy na stejném serveru, kde běží web, nejsou zálohy, ale iluze. Při kompromitaci serveru nebo ransomwaru jdou ke dnu spolu s produkcí.
4. Přihlašování do administrace z veřejné Wi-Fi bez VPN. I s HTTPS existují vektory, které fungují na úrovni DNS a ARP spoofingu. Buď VPN, nebo se z kavárny do kritických služeb nelogujte.
5. Ignorování logů. V access.log a auth.log lze útok často vidět den nebo dva před tím, než se podaří. Ale nikdo se tam nedívá, dokud web nepadne. Základní monitoring (Fail2ban + notifikace do Telegramu nebo na e-mail) — to je hodina nastavení a měsíce klidu.

Časté dotazy