Proč 2FA neřeší největší riziko: ztrátu dat

Dvoufaktorová autentizace chrání přístup k účtu, ale nechrání data před situací, kdy je útočník už uvnitř, nebo kdy selže infrastruktura. V praxi se často stává, že správce má silné heslo, MFA na administraci hostingu i WordPressu, ale zálohy běží na stejném serveru, v té samé síti nebo u stejného poskytovatele bez oddělených práv. Jakmile dojde k napadení, škodlivý skript nebo admin účet s přístupem k souborům smaže nejen web, ale i poslední kopii zálohy.

Ransomware útoky nejsou problém jen velkých firem. Podle dlouhodobých reportů bezpečnostních firem je většina incidentů stále založená na kombinaci slabého hesla, zneužitého pluginu, phishingu nebo kompromitovaného přístupu k hostingu. Z pohledu provozu webu je klíčové jednoduché pravidlo: záloha, kterou umí napadnout stejný útočník jako produkci, není skutečná záloha.

Nejčastější chyba: backup na stejném serveru, stejném účtu nebo ve stejné zóně

V praxi potkávám tři opakující se scénáře. První je WordPress web, který ukládá zálohy do složky na stejném FTP/SFTP účtu. Druhý je VPS, kde běží produkce i cron pro export databáze a archiv se ukládá na lokální disk. Třetí je cloudové řešení, kde jsou zálohy sice off-site, ale pod stejným administračním účtem bez oddělených oprávnění a bez immutable režimu.

Problém je v tom, že útočník nepotřebuje složitý postup. Často mu stačí přístup k administračnímu rozhraní nebo k souborovému systému. Pokud zálohy leží vedle webu, jsou první na řadě. U menších webů navíc bývá zálohování nastavené „na pocit“: jednou týdně export, žádný monitoring, žádná retence, žádný test obnovy.

• Lokální backup = rychlý, ale zranitelný při útoku na server.
• Backup ve stejné cloudové organizaci = lepší, ale stále risk při kompromitaci účtu.
• Oddělený off-site backup = výrazně bezpečnější, zejména s immutable úložištěm.

Jak má vypadat zálohování, které přežije incident

Nejspolehlivější přístup vychází z pravidla 3-2-1: mít tři kopie dat, na dvou různých typech médií a jednu kopii mimo primární infrastrukturu. V roce 2026 se k tomu běžně přidává ještě „immutable“ vrstva, tedy záloha, kterou nelze po stanovenou dobu smazat ani upravit. To je důležité hlavně proti ransomwaru a proti chybné administraci.

Pro menší a střední weby doporučuji tento model: produkce běží na hostingu nebo VPS, denní inkrementální zálohy míří do odděleného cloudového úložiště, například Amazon S3 s Object Lock, Backblaze B2 s verzováním, případně do samostatného účtu u jiného poskytovatele. Záloha musí mít vlastní přístupové klíče a ideálně i vlastní organizační účet, ne jen jinou složku v tom samém prostředí.

U WordPressu je dobré rozlišit databázi a soubory. Databáze se mění často, soubory méně. U e-shopu s WooCommerce je vhodné zálohovat databázi klidně každé 2 až 4 hodiny a soubory jednou denně, podle objemu objednávek. U firemního webu s nízkou frekvencí změn stačí denní záloha, ale s retencí alespoň 14 až 30 dní, aby šlo vrátit i starší, neúplně poškozenou verzi.

Praktické nástroje podle typu webu

• WordPress: UpdraftPlus, BlogVault, Jetpack Backup, Duplicator Pro.
• VPS a vlastní server: restic, borgbackup, duplicity, rsync v kombinaci s šifrováním.
• Cloud a moderní stack: snapshoty databází, object storage, CI/CD pipeline s odděleným backup jobem.
• Hosting s managed službou: ověřit, zda backup není jen interní snapshot bez exportu mimo infrastrukturu.

Důležité je nevybírat nástroj jen podle pohodlí. Sledujte, zda umí šifrování, verzování, retenční politiku, obnovu na kliknutí a export mimo účet. Bez těchto funkcí je záloha spíš pohodlný archiv než bezpečnostní pojistka.

Bez oddělených práv je záloha jen další admin účet

Jedna z nejpodceňovanějších chyb je sdílení oprávnění. Zálohovací účet by neměl mít práva na mazání produkčních dat, a produkční účet by zase neměl mít právo mazat backup bucket nebo snapshoty. V cloudovém prostředí je vhodné použít samostatné IAM role, omezení podle IP a zapnout MFA i na účet, který spravuje zálohy. To platí i pro administraci hostingu, S3 bucketů, FTP/SFTP a panelů typu cPanel nebo Plesk.

Pokud používáte WordPress, zkontrolujte, zda plugin pro zálohování nemá přístup k celé instalaci. Ideální je, když umí ukládat do externího úložiště a neuchovává dlouhodobě kopie na serveru. Zároveň platí, že plugin nesmí být jediný mechanismus ochrany. U důležitých webů doporučuji kombinovat aplikační zálohu s nezávislým serverovým snapshotem nebo exportem databáze.

Praktická kontrola je jednoduchá: zkuste si odpovědět, co se stane, když někdo získá přístup k WordPress administraci, ke SFTP, k hostingu nebo ke cloudovému účtu. Pokud ve všech variantách umí smazat i zálohy, máte slabé místo. Bezpečnější model je takový, kde ke smazání záloh potřebujete jiný účet, jiné přihlašovací údaje a ideálně i časové zpoždění nebo schválení druhou osobou.

Obnova není hotová, dokud ji netestujete na ostrém scénáři

Největší iluze v backupu je představa, že „něco se přece ukládá“. V okamžiku incidentu ale rozhoduje, zda umíte obnovit celý web do funkčního stavu v rozumném čase. Doporučuji test obnovy minimálně jednou měsíčně u kritických projektů a jednou za čtvrtletí u menších webů. Testujte nejen databázi, ale i uploady, šablony, pluginy, konfigurace, cron úlohy, e-mailové formuláře a přihlášení do administrace.

V ideálním případě máte definované RPO a RTO. RPO určuje, o kolik dat můžete přijít, například 4 hodiny. RTO říká, za jak dlouho musí být web zpět, například 2 hodiny. Bez těchto čísel většina firem neví, zda je jejich zálohování dostatečné. Pro e-shop s obratem v řádu statisíců denně je rozdíl mezi obnovou za 30 minut a za 8 hodin zásadní finančně i reputačně.

Obnova by měla být otestovaná na odděleném stagingu nebo dočasné instanci. Sledujte, zda záloha není poškozená, zda obsahuje správnou verzi databáze a zda se po obnově nespustí staré pluginy s bezpečnostní chybou. U větších webů je dobré mít i dokumentovaný postup obnovy: kdo co dělá, v jakém pořadí, jaké jsou přístupy a kam se hlásí incident.

Co nastavit hned dnes, aby záloha nebyla jen formální položka

Pokud chcete zlepšit odolnost webu bez velké investice, začněte pěti kroky. První: přesuňte zálohy mimo stejný server i stejného uživatele. Druhý: zapněte retenci a verzování, minimálně 14 dní, u důležitých projektů 30 dní. Třetí: omezte práva zálohovacího účtu na minimum. Čtvrtý: nastavte automatické upozornění, když se záloha nevytvoří nebo selže obnovovací test. Pátý: jednou za měsíc proveďte ruční obnovu nanečisto.

• Kontrola 1: záloha je fyzicky nebo logicky oddělena od produkce.
• Kontrola 2: existuje immutable nebo verzovaná kopie.
• Kontrola 3: někdo pravidelně testuje obnovu.
• Kontrola 4: přístup k backupům má jen úzký okruh lidí.
• Kontrola 5: máte napsaný postup pro incident a obnovu.

Pokud je odpověď na některou z těchto kontrol nejasná, je to signál k úpravě architektury. Dvoufaktorová ochrana je důležitá, ale sama o sobě neřeší scénář, kdy se smaže celý server, poškodí databáze nebo útočník získá vyšší práva. Skutečná bezpečnost vzniká až tehdy, když je záloha oddělená, verzovaná, šifrovaná a ověřená obnovou v praxi.