Bezpečnost automatizací: webhooky, přístupy a API klíče pod kontrolou

Webhook bez ověření podpisu spustí vaši automatizaci komukoli, kdo zná jeho adresu. Stripe ve své dokumentaci výslovně píše, že útočník tak může poslat falešné události a spustit vyřízení objednávky, udělení přístupu k účtu nebo změnu záznamů. Bezpečnost automatizací se proto točí kolem otázky, kdo smí tok spustit, pod jakým účtem přitom jedná a jak dlouho platí klíč, kterým se připojuje k dalším službám. Platformy k tomu v roce 2026 přidaly nové nástroje. Platforma n8n ověřuje podpisy webhooků v dalších trigger uzlech, Make posílá e-mail, když někdo použije vaše propojení, a OpenAI umožňuje nastavit API klíči datum expirace.

Tento článek navazuje na našeho průvodce AI automatizací firemních procesů, který řeší, co se vyplatí automatizovat. Pokud toky stavíte v n8n nebo Make, základní srovnání platforem najdete v článku automatizace pro malé firmy přes n8n a Make. Když chcete toky nechat postavit nebo zkontrolovat někým, kdo je dělá denně, podívejte se na naši službu automatizace firemních procesů.

Bezpečnost automatizací: kde tok nejčastěji prosakuje

Nejzranitelnější místa automatizace jsou adresa webhooku, uložená propojení na firemní účty, API klíče k placeným službám a účet na samotné platformě.

Automatizační tok v n8n, Make nebo Zapieru drží přístupy k více systémům najednou. Jeden scénář čte objednávky z e-shopu, zapisuje do fakturace, posílá e-maily zákazníkům a volá AI model. Kdo ovládne tok, dostane se najednou do všech aplikací, které tok propojuje. U webu hlídáte hlavně přihlášení do administrace. U automatizace jsou vstupy rozházené po nastaveních jednotlivých uzlů a pohromadě je často nevidí nikdo. Pokud spravujete i WordPress, jeho stranu pokrývá náš 10bodový checklist bezpečnosti WordPress webu. Tady řešíme toky, které běží mimo něj.

Vstupní bod	Co se stane při zneužití	První kontrola
Webhook (adresa, kterou volá jiná služba)	Kdokoli s adresou pošle vymyšlená data a spustí tok	Ověření podpisu nebo tajné hlavičky, seznam povolených IP adres
Propojení (connection, credential)	Kolega nebo cizí tok jedná pod vaším účtem	Kdo propojení vlastní, s kým je sdílené, kdo dostane upozornění na jeho použití
API klíč k AI nebo platební službě	Cizí volání jdou na váš účet a vaši fakturu	Datum expirace, jeden klíč na jeden tok, sledování spotřeby
Účet na automatizační platformě	Přístup ke všem tokům a uloženým propojením najednou	Dvoufázové ověření, role podle toho, kdo co dělá

Projděte si tabulku u každého toku, který pracuje s penězi, osobními údaji nebo e-maily zákazníkům. Začněte tam, kde v posledním sloupci nemáte odpověď.

Webhooky: ověřte, kdo vaši automatizaci volá

Webhook přijme požadavek od každého, kdo zná jeho adresu, proto musí ověřit podpis, tajnou hlavičku nebo aspoň IP adresu odesílatele.

Služba, která webhook posílá, k němu připojí podpis vypočítaný ze sdíleného tajemství a z obsahu zprávy. Stripe k tomu používá HMAC se SHA-256 a podpis posílá v hlavičce Stripe-Signature. Přijímající strana podpis vypočítá znovu a porovná. Když se neshoduje, požadavek odmítne. Stripe ve své dokumentaci k webhookům k tomu přidává pravidla, která platí pro jakoukoli vlastní integraci:

• podpisy porovnávat v konstantním čase, aby útočník nemohl podpis odhadovat podle toho, jak rychle server odpovídá,
• kontrolovat časové razítko zprávy, přičemž knihovny Stripe mají výchozí toleranci 5 minut a hodnota 0 kontrolu úplně vypne,
• počítat s tím, že stejná událost přijde vícekrát, a ukládat si ID již zpracovaných událostí,
• podpisové tajemství pravidelně měnit a vyměnit ho hned, když máte podezření na únik.

Webhooky v n8n

Verze n8n 2.21 z 12. května 2026 přidala ověřování podpisů do více trigger uzlů najednou, například pro Calendly, MailerLite, Customer.io, Twilio a Acuity Scheduling. Požadavek s chybějícím nebo neplatným podpisem uzel odmítne s odpovědí 401. Podle poznámek k vydání n8n však staré webhooky běží dál bez ověření, aby existující toky nespadly. U některých uzlů vznikne podpisový klíč až při novém vytvoření webhooku, u Customer.io je třeba klíč doplnit do přihlašovacích údajů. Samotná aktualizace proto staré toky nezabezpečí.

Obecný uzel Webhook, přes který jdou vlastní integrace, nabízí podle dokumentace n8n autentizaci Basic auth, Header auth, JWT auth nebo None a volitelný seznam povolených IP adres. Požadavek z jiné adresy odmítne s chybou 403. Při volbě None tok spustí každý, kdo adresu zná. Testovací adresa se zaregistruje, když v editoru spustíte Listen for Test Event nebo Execute workflow, produkční až po publikování toku.

Webhooky v Make

Vlastní webhook v Make má v nastavení tři ochrany. Omezení IP adres zpracuje jen požadavky z uvedených adres. Datová struktura odmítne požadavek, který jí neodpovídá, s kódem 400. Volitelný API klíč se posílá v hlavičce x-make-apikey a Make ho po vytvoření už znovu neukáže, takže ho hned uložte do správce hesel. Webhook, který není déle než 5 dní (120 hodin) připojený k žádnému scénáři, Make sám deaktivuje.

Webhook bez kterékoli z těchto ochran funguje jako veřejné tlačítko. Kdo jeho adresu najde ve starém e-mailu, v logu nebo v kódu formuláře, spustí tok s daty, jaká si sám vymyslí.

Propojení a přístupy: pod jakým účtem váš tok jedná

Každé propojení v automatizaci jedná pod konkrétním účtem, proto musíte vědět, kdo ho vlastní, s kým je sdílené a kdo se dozví, když ho někdo použije.

Zapier od května 2026 při zapnutí nebo publikování Zapu kontroluje, zda má jeho vlastník přístup ke každému propojení, které Zap používá. Pokud propojení s vlastníkem sdílené není, Zap nezapne a editor ukáže krok i propojení, které je třeba sdílet. Píše to Zapier v oznámení o povinném přístupu vlastníka k propojením. Sdílení propojení je dostupné v tarifech Team a Enterprise. Kolega, se kterým propojení sdílíte, ho může použít ve vlastních Zapech a vidí i testovací data.

Make od 12. srpna 2026 posílá e-mail, když váš klíč nebo propojení poprvé přidá do scénáře jiný člen týmu. Upozornění jsou podle nápovědy Make zapnutá ve výchozím stavu a vlastník je může vypnout u každého propojení zvlášť. Nechte je zapnutá, jinak se o scénáři postaveném nad vaším přístupem do fakturace nedozvíte. Role v týmu Make rozlišují plný přístup (Team Admin), operátora, který scénáře jen zapíná, vypíná a plánuje (Team Operator), a monitorování s přístupem jen pro čtení (Team Monitoring). Od 12. února 2026 můžete v Make vynutit dvoufázové ověření pro celou organizaci.

V n8n kolega sdílené přihlašovací údaje použije, ale jejich detaily neuvidí ani neupraví. Sdílení má podle dokumentace n8n cloud ve všech plánech, self-hosted instalace v plánech Business a Enterprise.

Propojení na fakturaci, banku a e-shop by z našeho pohledu měla patřit firemnímu servisnímu účtu místo osobního účtu zaměstnance. Když člověk z firmy odejde a jeho účet se zruší, toky postavené na jeho propojeních přestanou fungovat. U každého propojení si proto rozhodněte, zda patří člověku, nebo firmě, a podle toho ho převeďte.

API klíče k AI službám: expirace, vlastník a jeden klíč na tok

API klíč k AI modelu nebo platební službě má mít vlastníka, datum expirace a co nejužší rozsah, aby jeho únik zasáhl jen jeden tok.

OpenAI od 10. září 2026 umožňuje při vytváření projektového API klíče nastavit datum expirace. Správci mohou na úrovni organizace nebo projektu vynutit maximální životnost klíčů. Od 15. září 2026 přibyly podle changelogu OpenAI API i ovládací prvky, kterými organizace a projekt řídí vytváření klíčů. Ve svých doporučeních pro produkční nasazení OpenAI radí nedávat klíče do kódu ani do veřejných repozitářů, zpřístupnit je aplikaci přes proměnné prostředí nebo správce tajemství a sledovat jejich spotřebu na stránce Usage.

Pro automatizace z toho plyne několik pravidel, která doporučujeme dodržovat u každé platformy:

• jeden klíč na jeden tok nebo jednu službu, pojmenovaný podle toku, abyste při úniku věděli, co vypnout,
• klíč patří projektu nebo servisnímu účtu firmy, nikdy soukromému účtu zaměstnance,
• expirace s připomínkou v kalendáři před termínem, jinak se tok v den expirace zastaví,
• klíč vložený do přihlašovacích údajů platformy, ne do textu uzlu, HTTP hlavičky nebo poznámky, které se exportují spolu s tokem.

Stejná logika platí pro klíče k databázi v aplikacích z AI nástrojů, které jsme rozebírali u změny přístupů v Supabase Data API. U starého klíče bez expirace stačí vytvořit nový s datem platnosti, přepnout na něj tok a starý klíč smazat.

Self-hosted n8n: co zabezpečujete sami

Na vlastním serveru n8n odpovídáte sami za šifrovací klíč, aktualizace, veřejné API i způsob přihlašování.

Platforma n8n při prvním spuštění vygeneruje náhodný šifrovací klíč, kterým šifruje uložené přihlašovací údaje, a uloží ho do složky ~/.n8n. Kdo při stěhování na nový server nebo při obnově ze zálohy tento klíč ztratí, uložené přihlašovací údaje bez něj nepoužije. V režimu queue mode je podle dokumentace třeba nastavit proměnnou N8N_ENCRYPTION_KEY pro všechny workery. Dokumentace n8n k zabezpečení instalace dále uvádí tyto kroky:

• nastavit SSL a přihlašování přes SSO (SAML nebo OIDC),
• vynutit dvoufázové ověření a spustit bezpečnostní audit instalace,
• pravidelně měnit klíč, kterým se šifrují přihlašovací údaje,
• vypnout veřejné API, zablokovat uzly, které nepoužíváte, zapnout ochranu před SSRF a skrýt citlivá data z běhů toků.

Veřejné API vypnete proměnnými N8N_PUBLIC_API_DISABLED=true a N8N_PUBLIC_API_SWAGGERUI_DISABLED=true, pokud ho žádná integrace nepotřebuje. Pokud tyto kroky nemá nikdo na starosti, server běží ve stavu ze dne instalace a každá chyba, kterou n8n mezitím opravil, na něm zůstává otevřená.

Bezpečnost automatizací v praxi: kontrola za jedno odpoledne

Malou firmu s několika toky projdete podle naší zkušenosti orientačně za jedno odpoledne, pokud začnete toky, které pracují s penězi a osobními údaji.

U menších firem v praxi vidíme hlavně toky, které vznikly jako rychlý pokus a zůstaly běžet. Kdo je postavil a jaké přístupy používají, pak nemusí ve firmě vědět nikdo. Kontrolu dělejte v tomto pořadí:

1. Sepište všechny toky na všech platformách a ke každému vlastníka. Tok bez vlastníka vypněte nebo ho někomu přiřaďte.
2. U každého webhooku zjistěte, zda ověřuje podpis, hlavičku nebo IP adresu. Staré trigger uzly v n8n po aktualizaci zkontrolujte zvlášť.
3. Projděte propojení: komu patří, s kým jsou sdílená a zda některé neběží na osobním účtu bývalého zaměstnance.
4. Zapněte dvoufázové ověření pro všechny lidi na platformě, v Make ho můžete vynutit pro celou organizaci.
5. Nechte zapnutá upozornění na použití propojení v Make a ověřte, komu chodí.
6. API klíče k AI službám vyměňte za nové s expirací, jeden na tok, a zapněte sledování spotřeby.
7. U self-hosted n8n ověřte zálohu šifrovacího klíče, aktuální verzi a vypnuté veřejné API, pokud ho nepoužíváte.

Jak to řešíme v Denvě: automatizace napojujeme přes oficiální rozhraní nástrojů a přístupy držíme na nezbytném minimu. Toky stavíme sledovatelně, takže kritický krok při selhání upozorní hned, a předáváme je zdokumentované, abyste jim rozuměli a nebyli na nás navázaní.

Kdy to zvládnete sami a kdy s námi

Zvládnete sami, pokud:

• máte pár toků na jedné platformě a víte, kdo je postavil,
• používáte cloudovou verzi n8n, Make nebo Zapier a nespravujete vlastní server,
• vaše webhooky volají služby, u kterých n8n nebo Make ověření nabízí přímo v nastavení.

Vyplatí se přizvat nás, pokud:

• toky postavil někdo, kdo už ve firmě není, a nikdo neví, jaká propojení používají,
• provozujete self-hosted n8n bez zálohy šifrovacího klíče nebo bez pravidelných aktualizací,
• webhook přijímá objednávky, platby nebo osobní údaje a potřebuje vlastní ověření podpisu.

Závěr

Pokud vaše toky jen rozesílají interní notifikace, stačí zapnout dvoufázové ověření, uklidit propojení a seznam toků pravidelně procházet. Pokud přijímají objednávky, platby nebo osobní údaje, ověření webhooků a klíče s expirací patří mezi první úkoly, u vlastního serveru n8n spolu se zálohou šifrovacího klíče. Když nikdo ve firmě neumí říct, kdo který tok postavil a pod jakým účtem běží, doporučujeme obrátit se na odborníky a nechat toky nejdřív zmapovat. Pokud chcete, projdeme je s vámi na nezávazné konzultaci.

FAQ

Časté otázky.

Co je ověření podpisu webhooku?

Je to kontrola, že požadavek poslala služba, za kterou se vydává, a nikdo ho cestou nezměnil. Odesílatel vypočítá ze sdíleného tajemství a obsahu zprávy podpis, například HMAC se SHA-256, a pošle ho v hlavičce. Přijímající strana ho vypočítá znovu a při neshodě požadavek odmítne.

Stačí, že adresu webhooku nikdo nezná?

Nestačí. Adresa se může objevit v lozích, e-mailech, exportu toku nebo v kódu webu a pak ji zavolá kdokoli. Doplňte ji proto o ověření podpisu, tajnou hlavičku nebo seznam povolených IP adres, které n8n i Make nabízejí v nastavení webhooku.

Jak často měnit API klíče v automatizacích?

Pravidelně a vždy hned při podezření na únik, jak to Stripe doporučuje u podpisových tajemství webhooků. U OpenAI můžete od 10. září 2026 nastavit projektovému klíči datum expirace, takže starý klíč po termínu přestane platit a výměnu nemůžete odkládat donekonečna.

Je cloudová verze n8n bezpečnější než self-hosted?

Záleží na tom, kdo server spravuje. U self-hosted n8n odpovídáte sami za aktualizace, SSL, zálohu šifrovacího klíče a vypnutí veřejného API, pokud ho nepotřebujete. Webhooky, propojení a API klíče musíte zabezpečit v obou případech.

Dozvím se, když někdo použije moje propojení v Make?

Ano, od 12. srpna 2026 vám Make pošle e-mail, když váš klíč nebo propojení poprvé přidá do scénáře jiný člen týmu. Upozornění jsou zapnutá ve výchozím stavu a vlastník je může vypnout u každého propojení zvlášť, což nedoporučujeme.