Jak postavit základní bezpečnostní architekturu webu bez enterprise řešení

Malé a střední weby dnes čelí stejným útokům jako velké portály, ale obvykle bez bezpečnostního týmu a bez drahých nástrojů. Přesto lze postavit funkční a realistickou bezpečnostní architekturu i na běžném hostingu nebo cloudu. Jaké vrstvy by tedy měly mít základní ochranu webu, co řešit na úrovni infrastruktury, aplikace i provozu a kde se dělají nejčastěji chyby, které vedou k reálným incidentům?

1) Architektura, ne seznam nástrojů

Nejčastější chyba menších webů je snaha nakoupit bezpečnost. Nainstalovat pár pluginů, zapnout firewall a považovat tím téma za vyřešené. Skutečná bezpečnost ale nevzniká součtem nástrojů, ale jasným rozdělením rolí jednotlivých vrstev – perimetr, aplikace, infrastruktura, přístupy, zálohy a dohled, píše bezpečnostní organizace Owasp.

Dobrá architektura se proto neptá, jaký nástroj použít, ale:

• odkud se lze k aplikaci připojit,
• co je veřejné a co ne,
• kdo má jaká oprávnění,
• co se stane, když jedna vrstva selže.

Teprve na základě těchto hranic dává smysl vybírat konkrétní technologie.

2) Perimetr – oddělit web od přímého internetu

Perimetr je první a nejdůležitější obranná linie. Jeho cílem není zabezpečit aplikaci, ale zajistit, aby se k ní vůbec dostal jen filtrovaný a kontrolovaný provoz. V praxi to znamená, že web neběží přímo na veřejné IP adrese serveru, ale je schovaný za reverzní proxy nebo CDN s WAF.

Základní perimetr by měl řešit hlavně tyto věci:

• filtrování známých útoků (SQLi, XSS, path traversal, pokusy o zneužití CMS),
• základní ochranu proti botům a skenování,
• omezení počtu požadavků (rate limiting),
• centrální bod pro TLS a bezpečnostní hlavičky.

Zvláštní pozornost patří administračním rozhraním. Ta by neměla být volně dostupná z celého internetu, ale alespoň omezená podle IP nebo přístupná jen přes VPN. Právě útoky na přihlašování a veřejně vystavené administrace patří mezi nejčastější vstupní body.

Perimetr sám o sobě aplikaci nezabezpečí, ale výrazně zmenšuje útočnou plochu a zachytí většinu triviálních a automatizovaných útoků ještě před serverem.

3) Šifrování a důvěryhodná komunikace jako standard

V základní bezpečnostní architektuře už dnes šifrování nepatří mezi pokročilá opatření, ale mezi nezbytný standard provozu. Web musí běžet výhradně přes HTTPS a veškerá komunikace mezi prohlížečem a serverem má být chráněná pomocí TLS certifikátů.

Nejde přitom jen o ochranu obsahu přenosu. Správně nastavené HTTPS je nutné také pro:

• bezpečné používání cookies (Secure, SameSite),
• ochranu přihlašovacích relací,
• omezení rizika odposlechu a manipulace s provozem,
• fungování moderních bezpečnostních mechanismů v prohlížečích.

Součástí architektury by proto mělo být automatické vystavování a obnova TLS certifikátů, vynucení HTTPS na všech URL a zapnutí HSTS, aby prohlížeč nikdy nepřistupoval k webu přes nešifrované spojení.

Důležité je chápat, že šifrování není jen ochrana proti Wi-Fi útokům, ale základní stavební kámen důvěryhodné komunikace celé aplikace.

Na závěr lze tuto vrstvu v praxi jednoduše postavit i na lokálních nástrojích. Například kombinací služby SSLMarketu pro centrální správu a automatizaci TLS certifikátů a infrastruktury ZonerCloudu, která umožňuje provozovat weby s automatickým HTTPS, obnovou certifikátů a bezpečným síťovým perimetrem přímo na úrovni platformy.

4) Aplikace – minimalismus a aktualizace

U běžných webů a CMS není bezpečnost primárně otázkou složité architektury, ale disciplíny v provozu aplikace. Největší riziko dnes nepředstavují nové typy útoků, ale starý kód, neudržovaná rozšíření a zbytečně velká útočná plocha.

Základní architektura aplikace by proto měla stát na jednoduchém principu:

• používat jen funkce a pluginy, které web skutečně potřebuje,
• provozovat pouze aktivně udržované komponenty,
• pravidelně aktualizovat jádro i rozšíření,
• provozovat aplikaci na plně podporované verzi PHP.

Právě zastaralé komponenty patří mezi nejčastější příčiny napadení. Z pohledu architektury je proto klíčové, aby šla aplikace bezpečně a rychle aktualizovat. Jinak vzniká provozní bezpečnostní dluh.

5) Infrastruktura a přístupy

Infrastruktura je vrstva, která drží celý web pohromadě, a zároveň rozhoduje o tom, jak snadno se případný problém rozšíří dál. Základní architektura proto musí počítat s tím, že servery, databáze i přístupy jsou oddělené a řízené, nikoli řešené jedním univerzálním účtem.

V praxi to znamená hlavně:

• oddělit přístupy k serveru, aplikaci a databázi,
• nepoužívat sdílené administrátorské účty,
• přistupovat k serverům přes klíče (ne přes hesla),
• omezit oprávnění podle role a skutečné potřeby (princip nejmenších oprávnění).

Velmi důležité je i základní síťové oddělení. Webový server, databáze a administrační rozhraní by neměly být vystavené stejným způsobem do internetu. Čím menší je počet otevřených služeb a portů, tím menší je reálná útočná plocha.

Z pohledu menších projektů je klíčové, aby infrastruktura sama pomáhala držet bezpečnostní standard. Tedy aby řešila aktualizace systému, firewall a základní dohled. Jinak se velmi rychle vytváří provozní bezpečnostní dluh, který se v praxi projeví ve chvíli prvního incidentu.

6) Zálohování a obnova jako součást architektury

Zálohování není provozní doplněk, ale bezpečnostní vrstva. Ve chvíli, kdy řešíte napadení webu, chybnou aktualizaci, smazaná data nebo ransomware, často už nejde o to, jak útoku zabránit, ale jak rychle a čistě obnovit provoz.

Aby byly zálohy součástí bezpečnostní architektury, musí splňovat několik podmínek:

• automatizace – záloha nesmí záviset na ručním klikání,
• oddělení od produkce – zálohy nemají být na stejném serveru nebo pod stejnými přístupy,
• pokrytí dat i souborů – databáze a souborový systém jsou dvě různé věci,
• verzování a historie – potřebujete se umět vrátit o dny zpět, nejen poslední stav,
• test obnovy – mít zálohu nestačí, musíte umět web reálně obnovit.

Z pohledu architektury je často nejlepší mít zálohy ve dvou rovinách – rychlé lokální snapshoty pro rychlou obnovu po chybě a oddělené off-site zálohy pro situace typu kompromitace serveru nebo účtu.

7) Monitoring a logy – bez nich bezpečnost neexistuje

Bez monitoringu a logů ve skutečnosti neprovozujete bezpečný web, jen web, u kterého nepoznáte, že se něco děje. U menších projektů se většina incidentů neodhalí přímo při útoku, ale až podle jejich následků – například když přestane fungovat web, začne se z něj rozesílat spam nebo se nečekaně změní jeho obsah.

Základní architektura by proto měla počítat minimálně s tím, že máte:

• logy přístupů k webu a administraci,
• aplikační a chybové logy,
• upozornění na výpadek nebo výrazné anomálie,
• základní přehled o zátěži a chování aplikace.

Smyslem není budovat SIEM ani bezpečnostní dohledové centrum. Pro menší a střední weby je klíčové mít především dostatek provozních informací, které umožní rychle poznat, že se na webu něco změnilo nebo se začalo chovat nestandardně.

Bez základního přehledu o provozu totiž nelze včas reagovat a problém se často projeví až ve chvíli, kdy má dopad na uživatele nebo byznys.

Cílem monitoringu a logů je proto hlavně schopnost dohledat, odkud problém vznikl, a správně rozhodnout, zda jde o běžnou provozní chybu, nebo už o bezpečnostní incident, který vyžaduje jiný postup řešení.

8) Lidská vrstva – procesy a odpovědnost

Technická opatření sama o sobě nestačí. Ve většině reálných incidentů selže nakonec proces nebo odpovědnost, ne technologie. Proto musí být lidská vrstva součástí bezpečnostní architektury, stejně jako perimetr nebo zálohy.

V praxi to znamená mít jasně určeno: 

• kdo je odpovědný za aktualizace webu a jeho komponent,
• kdo řeší bezpečnostní incident a má právo zasahovat,
• kdo spravuje přístupy a rozhoduje o jejich odebrání,
• kdo provádí obnovu ze záloh a podle jakého postupu.

Zároveň by měl existovat jednoduchý, ale reálný postup pro mimořádné situace: co udělat při napadení webu, úniku přístupů nebo kompromitaci účtu. Nemusí jít o složitou dokumentaci. Důležité je, aby bylo jasné, kdo co dělá a v jakém pořadí.

Právě jasné rozdělení rolí, odpovědností a postupů patří mezi základní organizační bezpečnostní opatření doporučovaná i organizací National Institute of Standards and Technology v rámci jejich bezpečnostních rámců. Bez této vrstvy se i dobře navržená technická architektura velmi rychle stává neudržitelnou.

Bezpečnost jako provozní architektura, ne jako nákup nástrojů

Základní bezpečnost webu dnes nestojí na jednom správném řešení, ale na tom, zda máte pokryté všechny klíčové vrstvy – perimetr, aplikaci, infrastrukturu, přístupy, zálohy, monitoring i jasné procesy. Pokud některá z nich chybí, vzniká provozní bezpečnostní dluh, který se dříve nebo později projeví při prvním incidentu.

V praxi lze tuto architekturu velmi dobře postavit i bez enterprise platforem. Například kombinací infrastruktury ZonerCloudu, která řeší provoz, síťový perimetr, dostupnost a základní dohled, a služby SSLMarket pro centrální správu a automatizaci TLS certifikátů.

Díky tomu se i menší projekty mohou opřít o stabilní a bezpečný provozní základ a soustředit se na to podstatné – samotný web a jeho rozvoj.