Bezpečnost webu

Začít řešit zabezpečení až ve chvíli, kdy je web napadený, bývá pozdě a obvykle i výrazně dražší. Dobře zabezpečený web nevzniká instalací jediného pluginu. Je to soustava pravidelných opatření: aktualizací, kvalitního hostingu, řízení přístupů, záloh, monitoringu a rozumné reakce na incident.

Tento článek je určen především pro majitele webů na WordPressu a PrestaShopu, ale stejné principy platí pro každý redakční systém, e-shop i webovou aplikaci. Bezpečnost není jednorázový úkon. Je to průběžná péče o web, jeho data i přístupy lidí, kteří jej spravují.

Nejdůležitější pravidlo: Nečekejte na problém. Pravidelná prevence stojí zlomek částky, kterou může stát odstranění škod po napadení, obnova e-shopu, výpadek objednávek, ztráta dat nebo poškození důvěry zákazníků.

Jaké hrozby dnes na weby nejčastěji cílí?

Útočníci zpravidla nehledají pouze „velké firmy“. Automatizované roboty zkoušejí tisíce webů denně a hledají známé chyby, slabá hesla, staré pluginy nebo špatně nastavené přístupy. Napaden může být malý firemní web, blog, e-shop i jednoduchá prezentační stránka.

• Malware a zadní vrátka – škodlivý kód, který může přesměrovávat návštěvníky, rozesílat spam, krást údaje nebo umožnit útočníkovi opakovaný přístup.
• Útoky na přihlášení – automatizované zkoušení hesel, zneužití uniklých hesel a přihlašovacích údajů používaných na více službách.
• Zranitelné pluginy, šablony a moduly – častý vstupní bod u neaktualizovaných nebo nekvalitních doplňků.
• SQL injection, XSS a CSRF – útoky proti chybně naprogramovanému webu nebo nezabezpečenému rozšíření, které mohou vést ke krádeži dat či spuštění cizího kódu.
• DDoS a bot traffic – zahlcení webu velkým množstvím požadavků, které zpomalí nebo zcela vyřadí provoz.
• Phishing a zneužití značky – podvodné stránky nebo e-maily, které se vydávají za váš web a snaží se získat údaje zákazníků.
• Ransomware – zašifrování nebo zničení dat s následným požadavkem na výkupné.
• Útok na dodavatelský řetězec – problém v použitém pluginu, modulu, šabloně, externím skriptu nebo účtu dodavatele.

Aktuální přehled nejzávažnějších rizik pro webové aplikace zveřejňuje projekt OWASP Top 10. Pro majitele webu z něj plyne jednoduchý závěr: největší riziko nevzniká jednou konkrétní chybou, ale kombinací neaktuálního systému, příliš širokých oprávnění, slabých přístupů a chybějících záloh.

Základní bezpečnostní pravidla pro každý web

1. Aktualizujte systém, šablony, pluginy, moduly a PHP

Pravidelná aktualizace je nejdůležitější technické opatření. Aktualizujte nejen WordPress nebo PrestaShop, ale také všechny aktivní pluginy, šablony, moduly, používanou verzi PHP a serverové komponenty spravované hostingem. Zvláštní pozornost věnujte bezpečnostním aktualizacím.

Nepoužívané pluginy, šablony a moduly nestačí pouze deaktivovat. Pokud je již nepotřebujete, odinstalujte je. Každá další komponenta zvětšuje takzvanou útočnou plochu webu. Instalujte pouze rozšíření z oficiálních zdrojů nebo od ověřených výrobců, kteří doplněk aktivně udržují.

Před větší aktualizací vždy vytvořte zálohu a u důležitých webů proveďte nejprve test na testovací kopii webu, tzv. stagingu. Aktualizace provedená bez zálohy může sice vyřešit bezpečnostní problém, ale současně nechtěně způsobit technickou chybu nebo nekompatibilitu.

2. Vyberte kvalitní hosting a ověřte jeho bezpečnostní standard

Hosting je součástí zabezpečení webu. Levný hosting bez kvalitní podpory, záloh a ochrany proti útokům může být ve výsledku dražší než kvalitnější služba. U poskytovatele ověřte zejména:

• automatické obnovování SSL/TLS certifikátu a správné HTTPS nastavení,
• pravidelné zálohy souborů i databáze s rozumnou historií obnovení,
• možnost obnovit web ze zálohy rychle a samostatně,
• ochranu proti útokům, firewall nebo možnost napojení na WAF/CDN,
• aktuálně podporované verze PHP, databáze a serverového software,
• rychlou technickou podporu a přístup k logům nebo alespoň pomoc při jejich vyhodnocení,
• oddělené účty a bezpečný přístup přes SFTP nebo SSH.

Garance dostupnosti je důležitá, ale sama o sobě neříká, zda je hosting bezpečný. Rozhodující je především kvalita zálohování, reakce podpory, způsob izolace zákaznických účtů a technická úroveň správy serveru.

3. Používejte HTTPS všude, ale nepovažujte jej za kompletní ochranu

HTTPS šifruje komunikaci mezi prohlížečem návštěvníka a serverem. Chrání například přihlašovací údaje, formuláře, objednávky a data odesílaná přes web před snadným odposlechem nebo podvržením při přenosu. Každý web by měl fungovat výhradně na HTTPS a adresa bez HTTPS by měla být trvale přesměrována na zabezpečenou variantu.

HTTPS však samo o sobě neznamená, že je web bezpečný. Web s platným certifikátem může stále obsahovat malware, zranitelný plugin nebo špatně zabezpečenou administraci. HTTPS chrání přenos dat, nikoli chyby v aplikaci nebo ukradené přístupové údaje.

4. Nepřipojujte se na server nezabezpečeným FTP

Běžné FTP může přenášet uživatelské jméno a heslo nešifrovaně. Pro přístup na web používejte přednostně SFTP přes SSH, případně FTPS, pokud jej hosting podporuje. Správné připojení nastavíte například ve FileZille nebo jiném kvalitním FTP/SFTP klientovi.

Přístupové údaje k hostingu, databázi a administraci webu nikdy neposílejte nešifrovaně e-mailem ani běžnou zprávou. Pro sdílení přístupů používejte správce hesel nebo bezpečný způsob předání. Každému správci webu vytvořte vlastní účet; nesdílejte jeden společný přístup pro více lidí.

5. Silná hesla a dvoufázové ověření jsou povinnost, ne nadstandard

Každý účet s přístupem k webu musí mít jedinečné a dlouhé heslo. Stejné heslo nikdy nepoužívejte pro e-mail, WordPress, PrestaShop, hosting, doménový registr, databázi ani sociální sítě. Únik hesla z jedné služby by jinak mohl otevřít cestu ke všem ostatním účtům.

Nejpraktičtější řešení je správce hesel, který generuje dlouhá náhodná hesla a bezpečně je ukládá. U administrace webu, hostingu, e-mailu a registrátora domény zapněte dvoufázové ověření (MFA/2FA). I kdyby útočník heslo získal, bez druhého ověřovacího kroku by se do účtu neměl dostat.

Dvoufázové ověření je vhodné zejména pro administrátory. Připravte si také záložní obnovovací kódy a uložte je mimo počítač, do kterého se běžně přihlašujete.

6. Omezte počet administrátorů a používejte nejnižší nutná oprávnění

Administrátorský účet má plnou kontrolu nad webem. Vytvářejte jej proto pouze lidem, kteří jej skutečně potřebují. Redaktor obvykle nepotřebuje práva administrátora, účetní nepotřebuje přístup k šablonám a externí programátor nemusí mít trvalý přístup po dokončení práce.

• Každý člověk má mít vlastní účet, nikdy ne společný účet „admin“ pro celý tým.
• Nepoužívejte přihlašovací jméno admin, jméno firmy ani snadno odhadnutelnou variantu.
• Pravidelně kontrolujte seznam uživatelů a odstraňte účty bývalých zaměstnanců, dodavatelů nebo testovací účty.
• Dočasným dodavatelům zrušte přístup ihned po dokončení práce.
• Pro integrace používejte samostatné API klíče nebo aplikační hesla s omezeným rozsahem oprávnění, pokud to systém umožňuje.

7. Zálohujte podle pravidla 3–2–1 a obnovu pravidelně testujte

Záloha není jen soubor uložený na stejném hostingu. Smyslem zálohování je možnost obnovit funkční web i v případě smazání dat, havárie serveru, chyby při aktualizaci nebo útoku ransomwarem.

Praktické pravidlo 3–2–1 znamená: mít alespoň tři kopie důležitých dat, uložené na dvou různých typech úložiště a alespoň jednu kopii mimo hlavní hosting. U e-shopu nebo často měněného webu by měla být záloha automatická a častější než jednou týdně.

• Zálohujte vždy soubory webu i databázi.
• Uchovávejte více verzí záloh, ne pouze poslední kopii.
• Zálohu ukládejte mimo produkční server, například do odděleného cloudového úložiště.
• Po větším zásahu nebo aktualizaci vytvořte mimořádnou zálohu.
• Nejméně občas proveďte testovací obnovu na testovacím prostředí. Neotestovaná záloha nemusí být použitelná.

Národní úřad pro kybernetickou a informační bezpečnost doporučuje pravidelné a otestované zálohy; právě funkční záloha bývá rozhodující při řešení útoku ransomwarem.

WordPress: praktické kroky pro bezpečnější provoz

8. Zabezpečte přihlašování do WordPressu

Přihlašovací stránka WordPressu je častým cílem automatizovaných útoků. Účinná ochrana stojí na kombinaci více opatření:

• silná a unikátní hesla,
• dvoufázové ověření pro všechny administrátory,
• omezení počtu neúspěšných pokusů o přihlášení,
• dočasná blokace podezřelých IP adres,
• ochrana na úrovni WAF nebo CDN před tím, než škodlivý provoz dorazí na server,
• upozornění na nové administrátory, neobvyklé přihlášení nebo změny souborů.

Bezpečnostní plugin může být vhodným pomocníkem, nikoli však náhradou za aktualizace a správně nastavený hosting. Při výběru se zaměřte na funkce, jako jsou MFA, ochrana proti útokům na přihlášení, kontrola integrity souborů, bezpečnostní protokol a pravidelné aktualizace. Mezi známá řešení patří například Wordfence nebo Kadence Security, které bylo dříve známé jako iThemes Security.

Změna adresy přihlášení z wp-login.php může omezit část automatizovaného provozu, ale není to samostatné bezpečnostní opatření. Skrytí adresy není náhradou za MFA, silné heslo, ochranu proti pokusům o přihlášení a pravidelné aktualizace.

9. Bezpečnostní klíče WordPressu

WordPress používá bezpečnostní klíče a tzv. salts pro zabezpečení cookies a přihlašovacích relací. U běžné nové instalace se generují automaticky. V souboru wp-config.php proto ověřte, že nejsou ponechány výchozí texty typu put your unique phrase here a že obsahují skutečně náhodné hodnoty.

Klíče není nutné měnit bezdůvodně každý týden. Je vhodné je vyměnit zejména po podezření na únik přístupů, po kompromitaci webu nebo při předání správy. Po změně budou odhlášeni všichni přihlášení uživatelé, což je při incidentu žádoucí.

Více informací najdete v oficiální dokumentaci WordPressu k funkci wp_salt().

10. Vypněte editor šablon a pluginů v administraci

WordPress umožňuje administrátorovi upravovat soubory šablon a pluginů přímo v administraci. Tato funkce může způsobit chybu i při nechtěné úpravě a po kompromitaci administrátorského účtu dává útočníkovi snadnou cestu ke spuštění škodlivého kódu.

Pokud soubory neupravujete přímo v administraci, vložte do souboru wp-config.php tento řádek:

define( 'DISALLOW_FILE_EDIT', true );

Změnu provádějte pouze v textovém editoru a předem vytvořte zálohu souboru. Toto nastavení vypne editor souborů v administraci, ale neblokuje běžné aktualizace pluginů a šablon.

11. Nezobrazujte návštěvníkům technické chybové výpisy

Výpisy PHP chyb mohou prozradit cesty na serveru, názvy souborů, verze komponent nebo jiné informace užitečné pro útočníka. Produkční web nemá návštěvníkům zobrazovat technické chyby.

Ve WordPressu ověřte, že v souboru wp-config.php není zapnutý veřejný debug režim:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

Při vývoji lze logování dočasně používat, ale po dokončení úprav musí být výpis chyb pro návštěvníky vypnutý. Chybu je vhodné zapisovat do neveřejného logu, nikoli zobrazovat přímo na stránce.

12. XML-RPC, REST API a další rozhraní vypínejte pouze promyšleně

Soubor xmlrpc.php a rozhraní REST API mohou být legitimně potřeba pro mobilní aplikace, vzdálené publikování, integrace, formuláře nebo jiné služby. Není proto správné je plošně vypínat bez ověření dopadů.

Pokud XML-RPC nepoužíváte, lze jej omezit nebo vypnout. Pokud jej používáte, chraňte jej omezením rychlosti požadavků, WAF pravidly a silným přihlášením. Totéž platí pro API klíče: vytvářejte je samostatně pro jednotlivé integrace, dávejte jim jen nutná oprávnění a nepoužívané klíče rušte.

13. Co nepřeceňovat: prefix databáze, skrytí verze a „tajná“ URL

Změna prefixu databázových tabulek, skrytí verze WordPressu nebo přejmenování přihlašovací URL mohou mírně snížit množství automatizovaných pokusů. Neřeší ale skutečnou zranitelnost, ukradené heslo ani neaktuální plugin.

U již běžícího webu neměňte prefix tabulek bez přesného postupu a zálohy. Neodborná změna může poškodit databázové vazby a znefunkčnit web. Tato opatření mají nízkou prioritu; nejprve zajistěte aktualizace, MFA, zálohy, správu oprávnění a WAF.

14. Oprávnění k souborům a citlivé konfigurační údaje

Oprávnění souborů a složek musí být nastavena tak, aby web fungoval, ale aby nemohl soubory měnit kdokoli. Často se používá nastavení 755 pro složky a 644 pro soubory; konkrétní hodnoty však závisejí na konfiguraci hostingu a uživateli, pod kterým běží PHP. Soubor wp-config.php s přístupem k databázi může vyžadovat přísnější oprávnění, například 640 nebo 600, pokud je server podporuje.

Nastavení oprávnění neprovádějte naslepo. Příliš přísná oprávnění mohou znemožnit aktualizace nebo nahrávání souborů, příliš volná naopak zbytečně zvyšují riziko. Správné nastavení ověřte s technickou podporou hostingu.

PrestaShop: na co nezapomenout u e-shopu

15. Aktualizace, moduly a zabezpečení administrace PrestaShopu

U e-shopu je bezpečnost zvlášť důležitá, protože web obvykle pracuje s objednávkami, kontaktními údaji zákazníků, fakturačními daty a napojením na platební či dopravní služby. Udržujte aktuální samotný PrestaShop, šablonu i všechny moduly. Staré, neudržované nebo neověřené moduly odinstalujte.

• Po instalaci PrestaShopu zkontrolujte, že byl odstraněn instalační adresář /install.
• Administraci provozujte na jedinečné, automaticky vygenerované adrese; nepojmenovávejte ji předvídatelně.
• Zapněte HTTPS na celém e-shopu, nejen při objednávce nebo přihlášení.
• Každému správci vytvořte samostatný účet a zapněte MFA, pokud jej řešení nebo použitý modul podporuje.
• Webservice/API ponechte vypnutou, pokud ji nepotřebujete; při použití omezte přístupová práva API klíčů na nezbytné minimum.
• Pravidelně testujte objednávkový proces, e-maily, platby i přenos dat do účetnictví nebo dopravcům.

Oficiální dokumentace PrestaShopu doporučuje pravidelně aktualizovat jádro systému i moduly. V aktuální dokumentaci je rovněž uvedeno, že po instalaci má být instalační adresář odstraněn a administrace používá unikátní název.

Ochrana na úrovni serveru: WAF, hlavičky a ochrana proti DDoS

16. Použijte WAF nebo CDN jako první obrannou vrstvu

Web Application Firewall (WAF) vyhodnocuje provoz před tím, než se dostane k vašemu webu. Umí blokovat známé škodlivé požadavky, automatizované útoky na přihlášení, podezřelé boty a část DDoS provozu. WAF může být součástí hostingu, bezpečnostní služby nebo CDN.

Pro malé firemní weby je vhodné začít alespoň s ochranou proti opakovaným pokusům o přihlášení a základním filtrováním botů. U e-shopu, webu s formuláři nebo webu s vyšší návštěvností má WAF a CDN ještě větší význam.

17. Nastavte bezpečnostní HTTP hlavičky, ale vždy je otestujte

Bezpečnostní HTTP hlavičky doplňují ochranu webu v prohlížeči. Podle konkrétního webu mohou být vhodné zejména Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy a Permissions-Policy.

Nastavení musí odpovídat tomu, jak web funguje. Například příliš přísná Content Security Policy může zablokovat formulář, analytiku, platební bránu nebo vložené mapy. Hlavičky proto nejprve ověřte na testovací verzi webu a po nasazení zkontrolujte v prohlížeči i pomocí online testu.

Monitoring, skenování a pravidelné kontroly

18. Sledujte, co se na webu skutečně děje

Bezpečnostní sken je užitečný, ale sám o sobě nenahradí dohled. Web by měl upozornit alespoň na důležité události: nový administrátorský účet, opakované neúspěšné přihlášení, změnu kritických souborů, podezřelý plugin, nečekané přesměrování nebo výpadek webu.

Pravidelně kontrolujte:

• zda jsou systém, pluginy, šablony a moduly aktualizované,
• zda existuje poslední úspěšná záloha a zda ji lze obnovit,
• seznam administrátorů a aktivních přístupů,
• chybové a přístupové logy hostingu, pokud jsou k dispozici,
• stav SSL certifikátu a automatického obnovování,
• výsledky bezpečnostního skenu a případné změny souborů,
• funkčnost objednávky, formulářů, e-mailů a platebních bran.

Pro základní orientační kontrolu lze použít například Google Safe Browsing Transparency Report, Security Headers a Mozilla Observatory. Výsledek těchto nástrojů je podnět k prověření, nikoli úplný bezpečnostní audit.

Osobní údaje, e-shop a GDPR

19. Za zabezpečení osobních údajů odpovídá správce webu

Jestliže web zpracovává osobní údaje zákazníků, poptávky, objednávky, e-mailové adresy nebo jiné identifikující údaje, je nutné zabezpečení řešit také z pohledu GDPR. Nejde pouze o techniku. Důležitá jsou i organizační pravidla: kdo má k údajům přístup, proč jej má, jak dlouho se údaje uchovávají a co se stane při incidentu.

Článek 32 GDPR vyžaduje přiměřená technická a organizační opatření podle konkrétního rizika. U e-shopu proto nestačí pouze SSL certifikát. Je potřeba řešit řízení přístupů, zálohy, aktualizace, smluvní vztahy s dodavateli, bezpečné napojení služeb a evidenci incidentů.

Při porušení zabezpečení osobních údajů je nutné incident vyhodnotit a zdokumentovat. Pokud jde o případ podléhající oznamovací povinnosti, správce jej podle pokynů Úřadu pro ochranu osobních údajů oznamuje bez zbytečného odkladu, pokud možno do 72 hodin od zjištění.

Co dělat, když máte podezření na napadení webu

20. Postup při bezpečnostním incidentu

Pokud se web přesměrovává na cizí stránky, zobrazuje reklamu, rozesílá spam, obsahuje neznámé účty, objeví se v něm cizí soubory nebo vás upozorní hosting či Google, postupujte systematicky:

1. Omezte další škodu. Pokud je to nutné, dočasně vypněte web, přístup do administrace nebo podezřelou integraci.
2. Nemazejte bez rozmyslu důkazy. Uložte logy, seznam změněných souborů, čas zjištění problému a snímky obrazovky.
3. Změňte přístupy. Změňte hesla k hostingu, e-mailu, registrátorovi domény, CMS, databázi a externím službám. Zrušte neznámé účty a API klíče.
4. Kontaktujte hosting a odborníka. Požádejte o kontrolu logů, dočasné omezení provozu a pomoc s nalezením vstupního bodu.
5. Vyčistěte příčinu, ne pouze následek. Nestačí smazat viditelný škodlivý soubor. Je třeba opravit zranitelný plugin, aktualizovat systém, odstranit zadní vrátka a prověřit účty.
6. Obnovte web z ověřené čisté zálohy. Před obnovením se ujistěte, že záloha nevznikla až po napadení.
7. Vyhodnoťte osobní údaje. U e-shopu a formulářů prověřte, zda incident nemohl zasáhnout údaje zákazníků a zda nevznikla oznamovací povinnost podle GDPR.
8. Zaveďte opatření proti opakování. Doplňte MFA, aktualizace, monitoring, WAF, zálohy a pravidla pro správu přístupů.

Praktický kontrolní seznam

21. Co zkontrolovat alespoň jednou měsíčně

• Jsou WordPress, PrestaShop, PHP, šablony, pluginy a moduly aktuální?
• Byla úspěšně vytvořena záloha souborů i databáze?
• Je záloha uložená i mimo hlavní hosting?
• Je zapnuté MFA pro administraci, e-mail, hosting a doménu?
• Neexistují neznámé nebo zbytečné administrátorské účty?
• Funguje HTTPS na všech stránkách a je certifikát platný?
• Je aktivní ochrana proti opakovaným pokusům o přihlášení?
• Neobjevila se varování bezpečnostního pluginu, hostingu nebo Google?
• Fungují formuláře, objednávky, odesílání e-mailů a platební brány?

22. Co provést alespoň jednou ročně

• Proveďte test obnovy zálohy na testovací kopii webu.
• Projděte všechny účty, přístupy, API klíče a oprávnění dodavatelů.
• Zkontrolujte používané pluginy, moduly a externí skripty; odstraňte vše nepotřebné.
• Prověřte bezpečnostní hlavičky, HTTPS konfiguraci a stav domény.
• Nechte provést odborný bezpečnostní audit, zejména u e-shopu nebo webu zpracovávajícího citlivější data.
• Aktualizujte interní postup pro řešení incidentu a kontakty na hosting, programátora a odpovědné osoby.

Další ověřené zdroje

Oficiální doporučení pro zabezpečení WordPressu
Oficiální dokumentace k souboru wp-config.php
OWASP Top 10 – nejzávažnější rizika webových aplikací
Oficiální dokumentace PrestaShopu
Úřad pro ochranu osobních údajů – porušení zabezpečení osobních údajů
NÚKIB – doporučení k ochraně před ransomwarem

Závěr: Bezpečný web není web, který „nikdo nenapadne“, ale web, u kterého je útok podstatně obtížnější, poškození omezené a obnova rychlá. Začněte tím nejdůležitějším: aktualizacemi, silnými a jedinečnými přístupy, MFA, funkčními zálohami mimo hosting, omezením oprávnění a pravidelnou kontrolou.

ZPĚT