Rozšířili jsme web a přibylo nám 3,7 krát více škodlivého provozu

Při rozšiřování webu firmy obvykle řeší hlavně funkcionalitu, přínos pro zákazníka a návaznost na interní procesy.

Méně viditelná je druhá stránka každé změny, její dopad na bezpečnost.

Na web Noxurionu jsme přidali nové online školení kybernetické bezpečnosti. To vám pomůže splnit zákonnou povinnost rozvoje bezpečnostního povědomí zaměstnanců a po absolvování získáte certifikát.

Součástí řešení byla také integrace se Zoho Campaigns.

Pokud chce návštěvník po absolvování školení zůstat v kontaktu, může o to požádat. Jeho kontaktní údaj pak potřebujeme bezpečně uložit a využít pro komunikaci, o kterou projevil zájem. Právě k tomu slouží propojení se Zoho Campaigns.

Z pohledu byznysu jde o běžnou a relativně malou funkcionalitu. Propojit web s nástrojem, který nám umožní evidovat kontakt a navazující komunikaci.

Z pohledu bezpečnosti se ale změnila architektura aplikace. Přibylo nové propojení se službou třetí strany, nový datový tok a nová veřejně dostupná část aplikace.

Krátce poté jsme v bezpečnostních statistikách zaznamenali výraznou změnu.

Co ukázala data

Na webu používáme ochrannou vrstvu, která filtruje škodlivé a podezřelé požadavky ještě předtím, než dorazí k samotné aplikaci.

Před změnou a po změně

Sledované období	Reportované dny	Blokované škodlivé požadavky	Průměr za reportovaný den
Data před 6. 8. 2026	22 dní	19 718	896
6. 8. až 20. 8. 2026	15 dní	49 416	3 294

V období od 6. do 20. srpna tak byl průměrný počet blokovaných škodlivých požadavků přibližně 3,7krát vyšší než v dostupných datech před touto změnou.

Ukazatel od 6. 8. do 20. 8.	Hodnota
Blokované škodlivé požadavky	49 416
Průměr za den	3 294
Nejvyšší počet za den	16 516
Unikátní IP adresy	1 699

Samotný růst objemu je zajímavý. Ještě důležitější ale je, kam část tohoto provozu směřovala.

Nejčastěji detekovaným cílem v období od 6. do 20. srpna byla cesta související s nově přidanou Zoho integrací.

Na tento endpoint směřovalo 8 834 požadavků, tedy téměř 18 procent všech blokovaných škodlivých požadavků v daném období.

Právě kombinace těchto dvou údajů je pro nás zajímavá. Po změně aplikace výrazně vzrostl objem škodlivého provozu a současně se nově přidaná integrační cesta stala jeho nejčastěji detekovaným cílem.

Interpretace dat

Za prvé, výrazný nárůst škodlivého provozu časově následoval po změně aplikace.

Za druhé, významná část následného provozu směřovala právě na cestu související s novou integrací.

Jak automatizované útoky skutečně fungují

Velká část škodlivého provozu na internetu není vedena člověkem, který si vybere konkrétní firmu a začne její web ručně analyzovat.

Jde o automatizované systémy, které průběžně skenují veřejně dostupné servery a zkoušejí známé cesty, soubory, technologie a konfigurace.

V našich datech se například objevily pokusy o přístup k cestám jako:

• /.env
• /firebase.json
• /config.toml
• /awsConfig.js
• /debug/pprof/

To neznamená, že tyto technologie nebo soubory skutečně používáme.

Automatizovaný skener to předem neví. Jednoduše testuje, zda daná cesta existuje a zda neobsahuje něco využitelného.

Stejný princip platí pro nové integrační endpointy.

Jakmile je určitá část aplikace dostupná z internetu, může být objevena automatizovaným skenováním, procházením webu, analýzou odpovědí serveru nebo testováním známých struktur.

Není tedy nutné novou funkcionalitu aktivně propagovat, aby se stala předmětem automatizovaného útoku.

To je dnes běžná realita veřejně dostupných aplikací.

Malá změna ve funkcionalitě může znamenat větší změnu v bezpečnosti

Z pohledu byznysu může integrace s CRM, marketingovým nástrojem nebo jiným externím systémem působit jako drobný projekt.

Technicky se ale může změnit několik věcí současně.

Vzniknou nové datové toky, aplikace začne komunikovat s dalším systémem, přibudou nové přístupové údaje nebo tokeny a mohou vzniknout další veřejně dostupné endpointy.

Tím se mění i prostor, který je potřeba chránit.

Neznamená to, že externí integrace představují problém.

Znamená to, že jejich bezpečnostní dopad musí být součástí návrhu změny.

Co kontrolovat při každé nové integraci

Při podobné změně dává smysl ověřit především:

• jaké nové části aplikace budou veřejně dostupné,
• jaká data mezi systémy proudí,
• kdo má k nové funkcionalitě přístup,
• jak jsou chráněny přístupové údaje, tokeny a další citlivé hodnoty,
• zda existuje omezení počtu požadavků,
• co aplikace loguje a co lze po nasazení sledovat,
• co se stane při výpadku nebo chybné odpovědi externí služby,
• zda má integrace pouze oprávnění, která skutečně potřebuje.

Tyto otázky nejsou relevantní jen pro velké technologické projekty.

Stejný princip platí při nasazení CRM, zákaznického portálu, platební brány, marketingové automatizace nebo nového interního nástroje.

Nasazením změny bezpečnostní práce nekončí

Bezpečnostní kontrola před spuštěním je důležitá, ale reálné chování systému ukáže až provoz.

Právě proto má smysl sledovat období před změnou a po změně.

Samotná dostupnost webu by nám přitom změnu bezpečnostního provozu neukázala.

Web fungoval. Uživatelé mohli službu používat. Z business pohledu nebyl důvod předpokládat problém.

Bez bezpečnostního monitoringu bychom ale neviděli, že se na pozadí změnil charakter provozu.

To je jedna z hlavních hodnot monitoringu.

Neříká pouze, zda služba funguje.

Ukazuje také, jak na změnu reaguje okolní prostředí.

Ochrana není jen otázkou úniku dat

Během nejsilnějšího sledovaného období ochranná vrstva odklonila 83,3 procenta provozu.

Velká část nežádoucích požadavků se tak vůbec nedostala k serveru.

To je důležité nejen kvůli ochraně dat.

Automatizovaný provoz může spotřebovávat výkon serveru, zatěžovat aplikaci, databázi nebo služby třetích stran.

U některých integrací může každý požadavek navíc spouštět další operace, komunikaci s API nebo výpočetně náročné procesy.

Bezpečnost webové aplikace je proto zároveň otázkou dostupnosti, stability a v některých případech i provozních nákladů.

Co si z toho odnášíme

Na začátku byl jednoduchý business požadavek.

Rozšířit naši nabídku o online školení kybernetické bezpečnosti a umožnit uživatelům, kteří o to sami projeví zájem, zůstat s námi v kontaktu prostřednictvím integrace se Zoho Campaigns.

Výsledkem nebyla jen nová funkcionalita.

Změnila se také architektura aplikace a následně jsme zaznamenali výraznou změnu bezpečnostního provozu.

Data ukazují velmi konkrétně, proč by bezpečnost měla být součástí každé změny digitální služby.

Pokud se mění systém, mění se také jeho bezpečnostní kontext.

Proto při změně nestačí ověřit pouze to, zda nová funkcionalita funguje.

Má smysl znovu se podívat na to, co je nově dostupné z internetu, jaká data systém zpracovává, jak jsou chráněna nová propojení a zda máme dostatek informací na to, abychom změnu chování systému vůbec zaznamenali.

Bezpečnost není jednorázová kontrola. Je to součást řízení změny.