A folyamatautomatizálás biztonsága: webhookok, hozzáférések és API-kulcsok kézben tartva

Az aláírás-ellenőrzés nélküli webhook bárkinek elindítja az automatizálását, aki ismeri a címét. A Stripe a dokumentációjában kifejezetten leírja, hogy egy támadó így hamis eseményeket küldhet, és elindíthatja egy rendelés teljesítését, hozzáférést adhat egy fiókhoz vagy módosíthat rekordokat. A folyamatautomatizálás biztonsága ezért arról szól, ki indíthatja el a folyamatot, milyen fiók nevében működik, és meddig érvényes a kulcs, amellyel más szolgáltatásokhoz kapcsolódik. A platformok 2026-ban új eszközöket adtak ehhez. Az n8n újabb trigger node-okban ellenőrzi a webhookok aláírását, a Make e-mailt küld, ha valaki az Ön kapcsolatát használja, az OpenAI pedig lejárati dátumot enged beállítani az API-kulcsokhoz.

Ez a cikk az AI folyamatautomatizálásról szóló útmutatónkra épül, amely azt tárgyalja, mit érdemes automatizálni. Ha n8n-ben vagy Make-ben épít folyamatokat, a platformok alapvető összehasonlítását a kisvállalkozások n8n és Make alapú automatizálásáról szóló cikkünkben találja. Ha a folyamatait olyanokkal építtetné meg vagy ellenőriztetné, akik ezzel nap mint nap dolgoznak, nézze meg folyamatautomatizálási szolgáltatásunkat.

A folyamatautomatizálás biztonsága: hol szivárog leggyakrabban egy folyamat

Egy automatizálás legsebezhetőbb pontjai a webhook címe, a céges fiókokhoz mentett kapcsolatok, a fizetős szolgáltatások API-kulcsai és maga a platformfiók.

Egy n8n-, Make- vagy Zapier-folyamat egyszerre több rendszerhez fér hozzá. Egyetlen forgatókönyv beolvassa a webáruház rendeléseit, ír a számlázóba, e-mailt küld az ügyfeleknek és meghív egy AI modellt. Aki átveszi az irányítást a folyamat felett, egyszerre jut be minden alkalmazásba, amelyet a folyamat összeköt. Egy weboldalnál főként az adminisztrációs belépést védi. Egy automatizálásnál a belépési pontok szét vannak szórva az egyes node-ok beállításaiban, és együtt gyakran senki sem látja őket. Ha WordPresst is üzemeltet, annak oldalát a 10 pontos WordPress biztonsági ellenőrzőlistánk fedi le. Itt a rajta kívül futó folyamatokkal foglalkozunk.

Belépési pont	Mi történik visszaélés esetén	Első ellenőrzés
Webhook (cím, amelyet egy másik szolgáltatás hív meg)	Bárki, aki ismeri a címet, kitalált adatokat küld és elindítja a folyamatot	Aláírás vagy titkos fejléc ellenőrzése, engedélyezett IP-címek listája
Kapcsolat (connection, hitelesítő adatok)	Egy kolléga vagy idegen folyamat az Ön fiókja nevében működik	Kié a kapcsolat, kivel van megosztva, ki kap értesítést a használatáról
API-kulcs AI- vagy fizetési szolgáltatáshoz	Idegen hívások mennek az Ön fiókjára és számlájára	Lejárati dátum, folyamatonként egy kulcs, a felhasználás figyelése
Fiók az automatizálási platformon	Hozzáférés az összes folyamathoz és mentett kapcsolathoz egyszerre	Kétlépcsős azonosítás, szerepkörök aszerint, ki mit csinál

Nézze végig a táblázatot minden olyan folyamatnál, amely pénzzel, személyes adatokkal vagy ügyfeleknek szóló e-mailekkel dolgozik. Ott kezdje, ahol az utolsó oszlopra nincs válasza.

Webhookok: ellenőrizze, ki hívja meg az automatizálását

A webhook bárkitől elfogad egy kérést, aki ismeri a címét, ezért ellenőriznie kell egy aláírást, egy titkos fejlécet vagy legalább a küldő IP-címét.

A webhookot küldő szolgáltatás egy aláírást csatol hozzá, amelyet egy közös titokból és az üzenet tartalmából számít ki. A Stripe ehhez SHA-256 alapú HMAC-ot használ, és az aláírást a Stripe-Signature fejlécben küldi. A fogadó oldal újra kiszámítja és összeveti az aláírást. Ha nem egyezik, elutasítja a kérést. A Stripe a webhookokról szóló dokumentációjában olyan szabályokat is megad, amelyek bármilyen saját integrációra érvényesek:

• az aláírásokat állandó idejű összehasonlítással kell összevetni, hogy a támadó ne találgathassa az aláírást abból, milyen gyorsan válaszol a szerver,
• ellenőrizni kell az üzenet időbélyegét, a Stripe könyvtárainak alapértelmezett tűrése 5 perc, a 0 érték pedig teljesen kikapcsolja az ellenőrzést,
• számolni kell azzal, hogy ugyanaz az esemény többször is megérkezik, és el kell tárolni a már feldolgozott események azonosítóit,
• az aláíró titkot rendszeresen cserélni kell, és azonnal le kell cserélni, ha kiszivárgás gyanúja merül fel.

Webhookok az n8n-ben

Az n8n 2026. május 12-én megjelent 2.21-es verziója egyszerre több trigger node-ba építette be az aláírás-ellenőrzést, például a Calendly, a MailerLite, a Customer.io, a Twilio és az Acuity Scheduling esetében. A hiányzó vagy érvénytelen aláírású kérést a node 401-es válasszal elutasítja. Az n8n kiadási jegyzetei szerint azonban a régi webhookok ellenőrzés nélkül futnak tovább, hogy a meglévő folyamatok ne álljanak le. Egyes node-oknál az aláíró kulcs csak a webhook újbóli létrehozásakor jön létre, a Customer.io esetében pedig a kulcsot a hitelesítő adatokhoz kell hozzáadni. A frissítés önmagában tehát nem teszi biztonságossá a régi folyamatokat.

Az általános Webhook node, amelyen a saját integrációk futnak, az n8n dokumentációja szerint Basic auth, Header auth, JWT auth vagy None hitelesítést kínál, valamint opcionális IP-engedélylistát. Más címről érkező kérést 403-as hibával utasít el. None beállításnál bárki elindíthatja a folyamatot, aki ismeri a címet. A teszt URL akkor regisztrálódik, amikor a szerkesztőben a Listen for Test Event vagy az Execute workflow lehetőséget választja, az éles URL pedig csak a folyamat közzététele után.

Webhookok a Make-ben

A Make egyéni webhookjának beállításaiban három védelem található. Az IP-korlátozás csak a megadott címekről érkező kéréseket dolgozza fel. Az adatstruktúra a neki meg nem felelő kérést 400-as kóddal elutasítja. Az opcionális API-kulcsot az x-make-apikey fejléc viszi, és a Make létrehozás után már nem mutatja meg újra, ezért azonnal mentse el egy jelszókezelőbe. Azt a webhookot, amely 5 napnál (120 óránál) hosszabb ideje nincs egyetlen forgatókönyvhöz sem kapcsolva, a Make magától inaktiválja.

Az a webhook, amelyen ezek közül egyik védelem sincs, olyan, mint egy nyilvános nyomógomb. Aki egy régi e-mailben, egy naplóban vagy egy űrlap kódjában megtalálja a címét, tetszőleges, általa kitalált adatokkal indíthatja el a folyamatot.

Kapcsolatok és hozzáférések: milyen fiók nevében működik a folyamat

Az automatizálás minden kapcsolata egy konkrét fiók nevében működik, ezért tudnia kell, kié, kivel van megosztva, és ki értesül, ha valaki használja.

A Zapier 2026 májusa óta egy Zap bekapcsolásakor vagy közzétételekor ellenőrzi, hogy a tulajdonosa hozzáfér-e a Zap által használt minden kapcsolathoz. Ha egy kapcsolat nincs megosztva a tulajdonossal, a Zap nem kapcsol be, a szerkesztő pedig megmutatja, melyik lépést és kapcsolatot kell megosztani. Ezt a Zapier a tulajdonosi hozzáférésről szóló közleményében írja le. A kapcsolatok megosztása a Team és az Enterprise csomagban érhető el. Az a kolléga, akivel megoszt egy kapcsolatot, a saját Zapjeiben is használhatja, és a tesztadatokat is látja.

A Make 2026. augusztus 12. óta e-mailt küld, amikor egy másik csapattag először ad hozzá egy forgatókönyvhöz egy Önhöz tartozó kulcsot vagy kapcsolatot. A Make súgója szerint ezek az értesítések alapértelmezés szerint be vannak kapcsolva, és a tulajdonos kapcsolatonként külön kikapcsolhatja őket. Hagyja őket bekapcsolva, különben nem tud arról a forgatókönyvről, amelyet valaki az Ön számlázási hozzáférésére épített. A Make csapatszerepkörei megkülönböztetik a teljes hozzáférést (Team Admin), az operátort, aki a forgatókönyveket csak be- és kikapcsolja, valamint ütemezi (Team Operator), és a csak olvasási jogú megfigyelést (Team Monitoring). 2026. február 12. óta a Make-ben az egész szervezetre kötelezővé teheti a kétlépcsős azonosítást.

Az n8n-ben a kolléga használhatja a megosztott hitelesítő adatokat, de a részleteiket nem látja és nem módosíthatja. A megosztás az n8n dokumentációja szerint a felhőben minden csomagban, a self-hosted telepítéseknél a Business és az Enterprise csomagban érhető el.

Véleményünk szerint a számlázáshoz, a bankhoz és a webáruházhoz tartozó kapcsolatoknak egy céges szolgáltatásfiókhoz kell tartozniuk, nem egy munkatárs személyes fiókjához. Amikor valaki kilép a cégtől, és a fiókját törlik, az ő kapcsolataira épülő folyamatok leállnak. Minden kapcsolatnál döntse el, hogy egy személyhez vagy a céghez tartozik, és ennek megfelelően helyezze át.

API-kulcsok AI-szolgáltatásokhoz: lejárat, tulajdonos és folyamatonként egy kulcs

Egy AI-modell vagy fizetési szolgáltatás API-kulcsának legyen tulajdonosa, lejárati dátuma és a lehető legszűkebb jogosultsága, hogy egy kiszivárgás csak egyetlen folyamatot érintsen.

Az OpenAI 2026. szeptember 10. óta lehetővé teszi, hogy projekt API-kulcs létrehozásakor lejárati dátumot állítson be. A rendszergazdák szervezeti vagy projektszinten maximális kulcsélettartamot írhatnak elő. 2026. szeptember 15. óta az OpenAI API changelogja szerint olyan beállítások is elérhetők, amelyekkel a szervezet és a projekt szabályozza a kulcsok létrehozását. Az éles üzemre vonatkozó ajánlásaiban az OpenAI azt tanácsolja, hogy a kulcsok ne kerüljenek a kódba és nyilvános repozitóriumokba, az alkalmazás környezeti változókon vagy titokkezelő szolgáltatáson keresztül kapja meg őket, a felhasználásukat pedig a Usage oldalon kövesse.

Az automatizálásokra ebből néhány szabály következik, amelyet minden platformon javaslunk:

• folyamatonként vagy szolgáltatásonként egy kulcs, a folyamatról elnevezve, hogy kiszivárgáskor tudja, mit kell leállítani,
• a kulcs egy projekthez vagy a cég szolgáltatásfiókjához tartozik, soha nem egy munkatárs magánfiókjához,
• lejárat a határidő előtti naptári emlékeztetővel, különben a folyamat a lejárat napján leáll,
• a kulcs a platform hitelesítő adatai közé kerül, nem a node szövegébe, HTTP-fejlécbe vagy olyan megjegyzésbe, amely a folyamattal együtt exportálódik.

Ugyanez a logika érvényes az AI-eszközökkel készült alkalmazások adatbázis-kulcsaira is, amelyeket a Supabase Data API hozzáférési változásáról szóló cikkünkben tárgyaltunk. Lejárat nélküli régi kulcs esetén elég létrehozni egy újat érvényességi dátummal, átállítani rá a folyamatot, és törölni a régi kulcsot.

Self-hosted n8n: amit Önnek kell biztosítania

Saját n8n-szerveren Ön felel a titkosítási kulcsért, a frissítésekért, a nyilvános API-ért és a bejelentkezés módjáért.

Az n8n az első indításkor véletlenszerű titkosítási kulcsot generál, amellyel a mentett hitelesítő adatokat titkosítja, és a ~/.n8n mappába menti. Aki új szerverre költöztetéskor vagy mentésből való visszaállításkor elveszíti ezt a kulcsot, nélküle nem tudja használni a mentett hitelesítő adatokat. Queue mode üzemmódban a dokumentáció szerint az N8N_ENCRYPTION_KEY változót minden workerre be kell állítani. Az n8n telepítés biztonságáról szóló dokumentációja további lépéseket is felsorol:

• SSL beállítása és SSO-n (SAML vagy OIDC) keresztüli bejelentkezés,
• a kétlépcsős azonosítás kötelezővé tétele és a telepítés biztonsági auditjának futtatása,
• a hitelesítő adatokat titkosító kulcs rendszeres cseréje,
• a nyilvános API kikapcsolása, a nem használt node-ok letiltása, az SSRF elleni védelem bekapcsolása és az érzékeny adatok elrejtése a folyamatfuttatásokból.

A nyilvános API-t az N8N_PUBLIC_API_DISABLED=true és az N8N_PUBLIC_API_SWAGGERUI_DISABLED=true változóval kapcsolhatja ki, ha egyetlen integrációnak sincs rá szüksége. Ha ezekért a lépésekért senki sem felel, a szerver a telepítés napjának állapotában fut tovább, és minden hiba, amelyet az n8n azóta javított, nyitva marad rajta.

A folyamatautomatizálás biztonsága a gyakorlatban: ellenőrzés egy délután alatt

Tapasztalataink alapján egy néhány folyamatot használó kis céget tájékoztató jelleggel egy délután alatt át lehet nézni, ha a pénzzel és személyes adatokkal dolgozó folyamatokkal kezdi.

A kisebb cégeknél a gyakorlatban főként olyan folyamatokkal találkozunk, amelyek gyors kísérletként indultak, és tovább futnak. Hogy ki építette őket, és milyen hozzáféréseket használnak, azt utána a cégben akár senki sem tudja. Az ellenőrzést ebben a sorrendben végezze:

1. Írja össze az összes platform összes folyamatát, és mindegyikhez egy felelőst. A felelős nélküli folyamatot kapcsolja ki, vagy rendelje hozzá valakihez.
2. Minden webhooknál nézze meg, hogy ellenőriz-e aláírást, fejlécet vagy IP-címet. A régi n8n trigger node-okat frissítés után külön ellenőrizze.
3. Nézze át a kapcsolatokat: kihez tartoznak, kivel vannak megosztva, és fut-e közülük valamelyik egy volt munkatárs személyes fiókján.
4. Kapcsolja be a kétlépcsős azonosítást a platform minden felhasználójának, a Make-ben az egész szervezetre kötelezővé teheti.
5. Hagyja bekapcsolva a kapcsolathasználati értesítéseket a Make-ben, és ellenőrizze, kinek mennek.
6. Az AI-szolgáltatások API-kulcsait cserélje le lejárattal rendelkező újakra, folyamatonként egyet, és kapcsolja be a felhasználás figyelését.
7. Self-hosted n8n esetén ellenőrizze a titkosítási kulcs mentését, az aktuális verziót, és hogy a nyilvános API ki van-e kapcsolva, ha nem használja.

Hogyan csináljuk a Denvánál: az automatizálásokat az eszközök hivatalos interfészein keresztül kötjük be, a hozzáféréseket pedig a szükséges minimumon tartjuk. A folyamatokat nyomon követhetően építjük, így egy kritikus lépés hiba esetén azonnal jelez, és dokumentálva adjuk át őket, hogy értse a működésüket, és ne függjön tőlünk.

Mikor boldogul egyedül, és mikor velünk

Egyedül is boldogul, ha:

• néhány folyamata van egyetlen platformon, és tudja, ki építette őket,
• az n8n, a Make vagy a Zapier felhős változatát használja, és nem üzemeltet saját szervert,
• a webhookjait olyan szolgáltatások hívják, amelyekhez az n8n vagy a Make közvetlenül a beállításokban kínál ellenőrzést.

Érdemes minket bevonni, ha:

• a folyamatokat olyasvalaki építette, aki már nem dolgozik a cégnél, és senki sem tudja, milyen kapcsolatokat használnak,
• self-hosted n8n-t üzemeltet a titkosítási kulcs mentése vagy rendszeres frissítések nélkül,
• egy webhook rendeléseket, fizetéseket vagy személyes adatokat fogad, és egyedi aláírás-ellenőrzésre van szüksége.

Összegzés

Ha a folyamatai csak belső értesítéseket küldenek, elég bekapcsolni a kétlépcsős azonosítást, rendet tenni a kapcsolatok között, és rendszeresen átnézni a folyamatok listáját. Ha rendeléseket, fizetéseket vagy személyes adatokat fogadnak, a webhookok ellenőrzése és a lejáró kulcsok az első feladatok közé tartoznak, saját n8n-szerveren pedig a titkosítási kulcs mentése is. Ha a cégben senki sem tudja megmondani, ki melyik folyamatot építette, és milyen fiók alatt fut, javasoljuk, hogy forduljon szakemberhez, és először térképeztesse fel a folyamatokat. Ha szeretné, egy kötelezettség nélküli konzultáción együtt átnézzük őket.

GYIK

Gyakori kérdések.

Mi az a webhook-aláírás ellenőrzése?

Annak ellenőrzése, hogy a kérést valóban az a szolgáltatás küldte, amelynek mondja magát, és útközben senki sem módosította. A küldő egy közös titokból és az üzenet tartalmából aláírást számít ki, például SHA-256 alapú HMAC-kal, és fejlécben elküldi. A fogadó oldal újra kiszámítja, és eltérés esetén elutasítja a kérést.

Elég, ha senki sem ismeri a webhook címét?

Nem elég. A cím megjelenhet naplókban, e-mailekben, egy folyamat exportjában vagy a weboldal kódjában, és onnantól bárki meghívhatja. Ezért egészítse ki aláírás-ellenőrzéssel, titkos fejléccel vagy engedélyezett IP-címek listájával, amelyeket az n8n és a Make is kínál a webhook beállításaiban.

Milyen gyakran kell cserélni az automatizálások API-kulcsait?

Rendszeresen, és kiszivárgás gyanújakor mindig azonnal, ahogy a Stripe is javasolja a webhookok aláíró titkainál. Az OpenAI-nál 2026. szeptember 10. óta lejárati dátumot állíthat be a projektkulcshoz, így a régi kulcs a határidő után megszűnik érvényes lenni, és a csere nem halasztható a végtelenségig.

Biztonságosabb az n8n felhős változata, mint a self-hosted?

Attól függ, ki kezeli a szervert. Self-hosted n8n esetén Ön felel a frissítésekért, az SSL-ért, a titkosítási kulcs mentéséért és a nyilvános API kikapcsolásáért, ha nincs rá szüksége. A webhookokat, a kapcsolatokat és az API-kulcsokat mindkét esetben biztosítani kell.

Értesülök róla, ha valaki használja a kapcsolatomat a Make-ben?

Igen, 2026. augusztus 12. óta a Make e-mailt küld, amikor egy másik csapattag először ad hozzá egy forgatókönyvhöz egy Önhöz tartozó kulcsot vagy kapcsolatot. Az értesítések alapértelmezés szerint be vannak kapcsolva, és a tulajdonos kapcsolatonként kikapcsolhatja őket, amit nem javaslunk.