Automatyzacja może działać poprawnie i jednocześnie przechowywać znacznie więcej informacji, niż zakłada jej autor. W n8n problemem nie są wyłącznie hasła oraz tokeny API. W bazie, historii wykonań, logach i plikach roboczych mogą pozostać dane klientów, treści wiadomości, dokumenty, wyniki zapytań SQL, odpowiedzi modeli AI oraz kompletne payloady webhooków.
Najważniejsze rozróżnienie jest proste: n8n szyfruje poświadczenia zapisane jako credentials, ale nie szyfruje automatycznie każdego fragmentu danych przepływającego przez workflow. Sam fakt użycia bezpiecznego magazynu poświadczeń nie oznacza więc, że cała automatyzacja spełnia wymagania bezpieczeństwa lub RODO.
Co n8n zapisuje i gdzie faktycznie trafiają dane
W instalacji self-hosted n8n przechowuje w bazie między innymi definicje workflowów, konta użytkowników, konfigurację poświadczeń, dane projektów oraz informacje o wykonaniach. Domyślną bazą w prostych instalacjach jest SQLite, natomiast w środowiskach produkcyjnych najczęściej stosuje się PostgreSQL.
SQLite wystarcza do testów, pracy jednej osoby i niewielkich automatyzacji. Przy większej liczbie równoległych wykonań, wielu użytkownikach albo pracy w queue mode lepszym wyborem jest PostgreSQL. Nie jest to jednak automatyczna poprawa bezpieczeństwa. Źle zabezpieczony serwer PostgreSQL może być większym ryzykiem niż lokalny plik SQLite.
Dane w n8n trzeba podzielić na trzy grupy.
Poświadczenia, czyli credentials, obejmują między innymi:
- klucze API;
- hasła do baz danych;
- dane dostępowe SMTP;
- tokeny OAuth;
- sekrety webhooków;
- klucze usług chmurowych;
- dane logowania do CRM, systemów księgowych i platform marketingowych.
n8n szyfruje credentials przed zapisaniem ich w bazie. Do odszyfrowania używa klucza instancji. Przy pierwszym uruchomieniu może wygenerować go automatycznie i zapisać w katalogu użytkownika n8n, ale w środowisku produkcyjnym należy ustawić własną wartość zmiennej N8N_ENCRYPTION_KEY.
To jeden z najważniejszych sekretów całego wdrożenia. Jeżeli ktoś zdobędzie bazę danych bez klucza, odczyt credentials będzie utrudniony. Jeżeli zdobędzie bazę razem z kluczem, ta warstwa ochrony praktycznie przestaje mieć znaczenie.
Utrata klucza również jest poważnym problemem. Po odtworzeniu bazy na nowej instancji n8n może nie być w stanie odszyfrować dotychczasowych poświadczeń. Wtedy trzeba ponownie skonfigurować tokeny, hasła i połączenia OAuth, a produkcyjne workflowy przestają działać.
Dlatego N8N_ENCRYPTION_KEY powinien:
- zostać ustawiony przed uruchomieniem produkcji;
- mieć postać długiego, losowego ciągu;
- znajdować się poza repozytorium kodu;
- być dostępny tylko dla osób i procesów, które rzeczywiście go potrzebują;
- mieć osobną, kontrolowaną kopię zapasową;
- być taki sam na wszystkich workerach korzystających z jednej instancji w queue mode.
Drugą grupą są dane wykonania, czyli execution data. To właśnie tutaj najczęściej znajduje się więcej informacji wrażliwych niż w samych credentials.
Przykładowy workflow pobierający zgłoszenie z formularza może zapisać w historii:
- imię i nazwisko;
- adres e-mail i numer telefonu;
- adres IP;
- treść zgłoszenia;
- identyfikator klienta;
- odpowiedź CRM;
- rezultat klasyfikacji wykonanej przez model AI;
- treść błędu zwróconego przez zewnętrzne API.
Jeżeli workflow przetwarza fakturę, historię zamówień albo dokument kadrowy, cały dokument lub jego zawartość może pojawić się w danych wejściowych i wyjściowych poszczególnych node’ów. Administrator otwierający wykonanie w panelu n8n często widzi kompletny przebieg danych krok po kroku.
Trzecia grupa to dane binarne: pliki PDF, zdjęcia, nagrania, załączniki wiadomości oraz dokumenty pobierane z dysków i skrzynek pocztowych. Sposób ich przechowywania zależy od konfiguracji. Mogą być obsługiwane w pamięci, na lokalnym systemie plików albo w magazynie zgodnym z S3.
To ważny szczegół przy backupie. Kopia samej bazy nie zawsze zawiera wszystkie pliki przetwarzane przez workflow. Z drugiej strony usunięcie wpisu wykonania z bazy nie powinno być automatycznie utożsamiane z potwierdzonym usunięciem każdej kopii pliku z zewnętrznego magazynu, backupu czy systemu logowania.
Historia wykonań jest największym źródłem niepotrzebnego ryzyka
Najczęstszy błąd wygląda niewinnie: podczas tworzenia workflowu autor zapisuje wszystkie udane wykonania, ponieważ łatwiej wtedy analizować dane między node’ami. Po kilku miesiącach baza zawiera tysiące kompletnych payloadów, mimo że większość z nich nie jest już potrzebna.
To szczególnie ryzykowne w automatyzacjach dotyczących:
- HR i rekrutacji;
- księgowości;
- obsługi pacjentów;
- sklepów internetowych;
- CRM i sprzedaży;
- reklamacji;
- korespondencji e-mail;
- analizy dokumentów przez modele AI;
- formularzy zbierających dane klientów.
n8n pozwala sterować zapisywaniem danych wykonania. Można osobno podejść do wykonań zakończonych sukcesem, błędów oraz uruchomień ręcznych. Z perspektywy bezpieczeństwa dobra zasada brzmi: nie zapisuj danych tylko dlatego, że n8n potrafi je zapisać.
Udane wykonania są zwykle najmniej wartościowe diagnostycznie. Jeżeli workflow wykonuje się kilkadziesiąt tysięcy razy miesięcznie, przechowywanie pełnego wyniku każdego sukcesu zwiększa rozmiar bazy, wydłuża backupy i tworzy ogromny zbiór danych osobowych.
Błędy warto zachowywać dłużej, ale również nie bez ograniczeń. Komunikat błędu z API może zawierać fragment żądania, nagłówki, adres e-mail, identyfikator rekordu, a czasem nawet token. Zdarza się, że zewnętrzny system odsyła w błędzie cały przesłany payload.
W self-hosted n8n automatyczne czyszczenie historii kontrolują między innymi ustawienia:
- EXECUTIONS_DATA_PRUNE – włącza usuwanie starych wykonań;
- EXECUTIONS_DATA_MAX_AGE – określa maksymalny wiek danych w godzinach;
- EXECUTIONS_DATA_PRUNE_MAX_COUNT – ogranicza liczbę zachowywanych wykonań;
- EXECUTIONS_DATA_SAVE_ON_SUCCESS – określa sposób zapisywania udanych wykonań;
- EXECUTIONS_DATA_SAVE_ON_ERROR – steruje zapisywaniem wykonań zakończonych błędem.
Retencji nie należy ustalać według jednej wartości dla całej firmy. Workflow sprawdzający dostępność serwera może zachowywać dane dłużej niż automatyzacja obsługująca dokumenty rekrutacyjne. Praktyczny punkt wyjścia to 7–14 dni dla danych diagnostycznych, a następnie skrócenie tego okresu tam, gdzie przetwarzane są dane szczególnych kategorii, dokumenty finansowe albo pełna korespondencja klientów.
Nie jest to uniwersalny termin zgodności z RODO. Okres retencji musi wynikać z celu przetwarzania, obowiązków prawnych i procedur organizacji. n8n jest jedynie miejscem technicznego przechowywania danych, a nie źródłem podstawy prawnej.
Istotnym mechanizmem jest również redakcja danych wykonania. Pozwala ona ograniczyć widoczność danych wejściowych i wyjściowych w panelu. Ma to sens zwłaszcza wtedy, gdy zespół potrzebuje informacji, że workflow się wykonał, ale nie powinien oglądać treści przesyłanych rekordów.
Redakcja nie rozwiązuje jednak wszystkich problemów. Nie zastępuje:
- ograniczenia retencji;
- kontroli dostępu do panelu;
- czyszczenia logów;
- minimalizacji payloadów;
- zabezpieczenia bazy;
- poprawnej konfiguracji backupów;
- kontroli danych wysyłanych do usług zewnętrznych.
Trzeba również uważać na pinned data, ręczne dane testowe i payloady wklejane do Code node’a. Dane przypięte podczas projektowania workflowu mogą pozostać w jego konfiguracji znacznie dłużej niż historia wykonania. Kopiowanie prawdziwego rekordu klienta jako danych testowych jest wygodne, ale złe. Do testów należy używać rekordów syntetycznych albo trwale zanonimizowanych.
Bezpieczne uruchomienie wymaga ograniczenia dostępu i przepływu danych
Najbezpieczniejszy workflow nie jest tym, który ma najwięcej zabezpieczeń. Jest nim workflow, który otrzymuje tylko dane niezbędne do wykonania konkretnego zadania.
Jeżeli automatyzacja ma wysłać klientowi przypomnienie, zazwyczaj nie potrzebuje całej historii zakupów, adresu zamieszkania i notatek handlowca. Jeżeli model AI ma przypisać kategorię zgłoszenia, nie zawsze musi dostać nazwisko, telefon, numer umowy i podpis wiadomości.
Każde zbędne pole zwiększa liczbę miejsc, w których dane mogą zostać zapisane. Przechodzi przez kolejne node’y, pojawia się w podglądzie wykonania, może trafić do logów, zewnętrznego API albo komunikatu błędu.
Dlatego przed pierwszym uruchomieniem produkcyjnym należy przejrzeć workflow node po nodzie i zadać cztery pytania:
- Jakie dane wchodzą do tego node’a?
- Które pola są faktycznie potrzebne?
- Gdzie trafia wynik?
- Czy treść wejścia lub wyjścia zostanie zachowana po wykonaniu?
Pola zbędne należy usuwać możliwie wcześnie, najlepiej zaraz po webhooku, triggerze formularza lub pobraniu rekordu z systemu źródłowego. Przesyłanie kompletnego obiektu przez kilkanaście node’ów „na wszelki wypadek” utrudnia później zarówno audyt, jak i obsługę żądań usunięcia danych.
Sekrety powinny trafiać wyłącznie do credentials albo do zewnętrznego magazynu sekretów. Wpisanie tokenu bezpośrednio w polu HTTP Request, wyrażeniu, skrypcie JavaScript lub zmiennej testowej jest szybsze tylko do pierwszego incydentu.
Zewnętrzne magazyny sekretów, takie jak AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, HashiCorp Vault czy 1Password, sprawdzają się w organizacjach, które mają wiele środowisk, centralną rotację kluczy i wymagania audytowe. Integracja External Secrets jest funkcją przeznaczoną dla planów Enterprise.
Mała firma nie musi od razu wdrażać Vaulta. Źle utrzymywany system sekretów dokłada kolejną usługę, uprawnienia i punkt awarii. Przy kilku workflowach większy efekt da poprawne ustawienie klucza szyfrowania, ograniczenie historii wykonań i odebranie administratorom niepotrzebnych uprawnień.
Dostęp do panelu n8n także wymaga podziału. Wspólne konto administratora używane przez kilka osób uniemożliwia wiarygodne ustalenie, kto zmienił workflow, ujawnił dane albo podmienił poświadczenia. Każda osoba powinna korzystać z własnego konta, a workflowy i credentials należy przypisywać do odpowiednich projektów oraz ról.
Produkcja powinna mieć przynajmniej:
- HTTPS dla panelu i webhooków;
- panel administracyjny niewystawiony publicznie bez potrzeby;
- osobne konta użytkowników;
- uwierzytelnianie dwuskładnikowe lub SSO, jeżeli pozwala na to używany plan;
- bazę dostępną wyłącznie z wymaganej sieci;
- regularne aktualizacje n8n;
- kontrolę instalowanych community nodes;
- ograniczenie node’ów zdolnych do uruchamiania poleceń systemowych lub odczytu plików;
- backup bazy, klucza szyfrowania i używanych magazynów plików;
- okresowy test odtworzenia środowiska.
Community nodes są wygodne, ale wykonują kod wewnątrz instancji. Node pochodzący z niezweryfikowanego pakietu może uzyskać dostęp do danych workflowu, systemu plików i sieci. Instalowanie dodatku tylko dlatego, że ma odpowiednią nazwę w npm, jest ryzykiem nieproporcjonalnym do oszczędzonych kilku minut.
W przypadku n8n Cloud część odpowiedzialności za serwery, aktualizacje i infrastrukturę przejmuje operator usługi. Nadal jednak użytkownik odpowiada za konstrukcję workflowu, zakres przesyłanych danych, konfigurację integracji, uprawnienia członków zespołu oraz wybór usług zewnętrznych. Przed przetwarzaniem danych osobowych trzeba sprawdzić aktualne warunki umowy powierzenia, lokalizację przetwarzania, listę podprocesorów i wymagania własnej organizacji.
Szczególnej kontroli wymagają automatyzacje AI. Treść przekazana do node’a obsługującego model trafia do zewnętrznego dostawcy zgodnie z jego zasadami. Usunięcie wykonania z n8n nie usuwa automatycznie danych po stronie dostawcy modelu. Przed wysłaniem dokumentu należy więc usunąć niepotrzebne dane osobowe, sprawdzić warunki retencji API i ustalić, czy dany dostawca może być używany do określonej kategorii informacji.
FAQ: najważniejsze pytania przed uruchomieniem
Czy n8n przechowuje tokeny i hasła jako zwykły tekst?
Credentials są szyfrowane przed zapisaniem w bazie. Token wpisany ręcznie do node’a, skryptu, payloadu lub danych testowych może jednak zostać zapisany i wyświetlony bez tej ochrony.
Czy sama kopia bazy wystarczy do odczytania credentials?
Nie powinna wystarczyć bez właściwego klucza szyfrowania. Dlatego baza i N8N_ENCRYPTION_KEY nie powinny znajdować się w jednym łatwo dostępnym backupie.
Co się stanie po utracie N8N_ENCRYPTION_KEY?
Odtworzona instancja może nie odszyfrować zapisanych credentials. Konsekwencją jest zatrzymanie integracji i konieczność ponownego skonfigurowania dostępów.
Czy wyłączenie historii udanych wykonań wystarczy?
Nie. Dane mogą pozostać w błędach, logach, pinned data, plikach binarnych, backupach oraz systemach zewnętrznych.
Czy administrator może zobaczyć dane klientów?
W zależności od roli i konfiguracji może mieć dostęp do workflowów, credetials oraz szczegółów wykonań. Wspólne konto administratora należy usunąć w pierwszej kolejności.
Czy self-hosted n8n jest automatycznie bezpieczniejszy od n8n Cloud?
Nie. Self-hosting daje większą kontrolę, ale przenosi na firmę odpowiedzialność za TLS, bazę, aktualizacje, backupy, sieć, logi i reagowanie na incydenty.
Jak długo przechowywać execution data?
Tylko tak długo, jak wymaga diagnostyka lub obowiązek prawny. Dla wielu workflowów rozsądnym punktem startowym jest 7–14 dni, ale procesy HR, medyczne lub finansowe wymagają osobnej analizy.
Czy zewnętrzny vault jest konieczny?
Nie przy każdej instalacji. Najpierw trzeba poprawnie używać credentials, zabezpieczyć klucz szyfrowania i ograniczyć retencję. Vault staje się priorytetem przy wielu środowiskach, częstej rotacji sekretów i wymaganiach audytowych.
Pierwszy audyt powinien objąć jeden aktywny workflow, nie całą platformę naraz. Najpierw znajdź hasła, tokeny i klucze wpisane bezpośrednio w node’ach i przenieś je do credentials. Następnie sprawdź historię ostatnich wykonań: jeżeli panel pokazuje pełne dane klientów, dokumenty albo treść korespondencji, ogranicz zapisywanie oraz retencję przed uruchomieniem kolejnej automatyzacji. Dopiero po usunięciu tych dwóch błędów ma sens wdrażanie vaultów, rozbudowanych ról i dodatkowych systemów audytowych.
