Vlastní n8n bez otevřených dveří: HTTPS nestačí jako jediná ochrana

Vlastní n8n nasadíte bezpečněji, když veřejné HTTPS ukončíte na reverzní proxy, aplikační port zpřístupníte pouze místně a budete zálohovat databázi spolu se šifrovacím klíčem. Doporučení n8n pro TLS počítá s reverzní proxy také kvůli obnovování certifikátů. HTTPS chrání přenos, samo však neomezuje přímý přístup k aplikaci ani neurčuje, kdo smí volat veřejný webhook.

Pro základní instalaci si připravte doménu, server s Dockerem, reverzní proxy a trvalé úložiště n8n. Už před spuštěním rozhodněte, zda editor potřebuje přístup z internetu a které webhooky musí přijímat externí služby. Od toho se odvíjí pravidla proxy; záloha a zkouška obnovy řeší další riziko, totiž ztrátu workflow nebo nepoužitelná uložená přihlašovací údaje.

Doména a reverzní proxy: omezte veřejný vstup

DNS záznam zvolené domény nasměrujte na server a požadavky z internetu přijímejte na reverzní proxy. Ta obstará certifikát, přesměrování na HTTPS a předání provozu aplikaci. Ve firewallu ponechte veřejně dostupné pouze služby, které tento provoz skutečně potřebují; správcovský přístup k serveru vyhraďte oprávněným osobám. Samotný certifikát neřeší, zda se někdo dostane k editoru nebo obejde proxy přímým spojením na port n8n.

Pokud editor používá jen váš tým, omezte k němu přístup například přes VPN nebo pravidlo na proxy. Veřejně pak ponechte cesty nutné pro používané webhooky a případné návraty z přihlašování externích služeb. Pravidla nastavujte podle konkrétních integrací: plošné zablokování všech cest mimo editor může vyřadit webhook, příliš široké povolení zase vystaví rozhraní, které mělo zůstat soukromé. Úvodní založení účtu vlastníka proveďte při už omezeném přístupu k editoru.

Docker Compose: aplikační port nepatří na veřejnou adresu

V Compose připojte trvalý svazek k /home/node/.n8n a při proxy běžící přímo na hostiteli zveřejněte port zápisem 127.0.0.1:5678:5678. Postup TechRadaru pro Docker Compose používá právě tuto vazbu a svazek pro workflow, přihlašovací údaje a šifrovací klíč. Bez místní adresy může Docker port publikovat na všech rozhraních hostitele, takže návštěvník obejde přístupová pravidla proxy.

Po spuštění ověřte veřejnou doménu přes HTTPS a z jiné sítě zkuste přímé spojení na aplikační port veřejné adresy serveru: to má selhat. Zkontrolujte také skutečnou vazbu portu v běžící konfiguraci Dockeru a pravidla firewallu. Zelený symbol v prohlížeči potvrzuje šifrované spojení přes proxy, nikoli uzavření jiné cesty k témuž kontejneru. Je-li proxy v samostatném kontejneru, její localhost označuje ji samotnou; propojte kontejnery interní sítí Dockeru a port n8n na hostiteli vůbec nepublikujte.

Pro veřejnou adresu instance nastavte N8N_HOST a N8N_PROTOCOL; proměnná WEBHOOK_URL má obsahovat skutečnou HTTPS adresu, například https://n8n.example.cz/. Jinak může n8n nabídnout externím službám interní adresu nebo nesprávný port. Při provozu za proxy zajistěte také předání informací o původním požadavku a odpovídající nastavení důvěryhodných proxy. Je to důležité zejména tehdy, když chcete webhook omezovat podle IP adresy: aplikace musí znát adresu volajícího, nikoli jen adresu proxy.

Webhook zůstává veřejným vstupem do workflow

Uzel Webhook může přijmout požadavek a spustit workflow bez přihlášení do editoru. Dokumentace uzlu Webhook uvádí ověřování Basic, Header a JWT i seznam povolených IP adres. U každého veřejného webhooku vyberte ověření, které podporuje odesílající služba; u odesílatelů se stálými adresami můžete přidat také omezení podle IP. Náhodně vytvořená cesta snižuje pravděpodobnost náhodného volání, ale nenahrazuje ověření původu požadavku.

Rozlišujte testovací a produkční URL. Produkční webhook se používá po publikování workflow, proto po nasazení vyzkoušejte právě tuto adresu a ověřte, že dorazí očekávaná data. Pokud následné uzly mění záznamy, rozesílají zprávy nebo volají další služby, nepouštějte takovou akci jen na základě neověřeného obsahu požadavku. Omezení editoru chrání správu automatizací, nikoli samo o sobě jejich veřejné spouštěče.

Zálohujte databázi i původní šifrovací klíč

Ve výchozím nasazení s SQLite jsou workflow a uložená přihlašovací údaje v databázi v trvalém svazku n8n. Automaticky vytvořený šifrovací klíč je v konfiguraci téhož datového adresáře. Kopie samotné databáze tedy nestačí: obnovená instance potřebuje původní klíč, aby mohla uložené přihlašovací údaje přečíst. Jestliže klíč zadáváte proměnnou N8N_ENCRYPTION_KEY, uchovejte bezpečně její přesnou hodnotu mimo server spolu s postupem, jak ji při obnově znovu nastavit.

Zálohu SQLite pořizujte jako konzistentní kopii, například při zastavené aplikaci nebo nástrojem určeným pro zálohování SQLite. Průběžné prosté kopírování databázového souboru může zachytit neúplný stav. U externí databáze zálohujte také ji; svazek n8n sám potom celé workflow nepokrývá. Přibalte konfiguraci Compose a potřebná nastavení proxy, abyste mohli instanci na novém serveru spustit stejným způsobem.

Kopii ukládejte odděleně od serveru a omezte k ní přístup: záloha obsahuje provozní data a původní klíč umožňuje použít uložené přihlašovací údaje. Obnovu vyzkoušejte na oddělené instanci bez produkčních webhooků a aktivních automatizací. Po nahrání dat a nastavení původního klíče ověřte, že lze otevřít workflow a použít uložená přihlašovací údaje. Tím prověříte nejen existenci záložního souboru, ale i to, zda obsahuje části potřebné k návratu do provozu.

Aktualizujte s možností bezpečné obnovy

V Compose určete konkrétní verzi obrazu n8n, abyste věděli, jaké vydání běží a kdy se mění. Před aktualizací pořiďte konzistentní zálohu databáze, datového svazku a klíče, potom stáhněte zvolený obraz a znovu vytvořte kontejner. Po spuštění zkontrolujte přihlášení, běh používaného workflow a doručení produkčního webhooku. Samotný stav „běží“ neříká, zda automatizace fungují.

Průběžně sledujte nová vydání a bezpečnostní upozornění pro n8n i Docker. Návrat ke staršímu obrazu nemusí stačit, pokud novější vydání mezitím změnilo databázi; proto před změnou uchovejte obnovitelnou kopii celého potřebného stavu. Po úpravě proxy zopakujte kontrolu přímého přístupu na aplikační port a po změně úložiště zkoušku obnovy. Každá z těchto kontrol míří na konkrétní selhání: otevřený vstup, přerušenou integraci nebo zálohu bez použitelných přihlašovacích údajů.

Přečtěte si také:

• Passkey, nebo heslo: ochranu může zrušit slabá obnova účtu
• Dovednosti místo diplomu: bez praktické zkoušky se nábor nezmění