n8n Журнали аудиту: який план показує, хто змінив робочий процес
Журнали аудиту n8n: що записується, як RBAC пов'язує зміни з особою, і який enterprise-план дає команді повний облік змін.
Перевірено за документацією n8n .
Практичне питання: що потрапляє в журнал і хто це бачить
Коли робочий процес ламається у продакшені або зникають облікові дані, перше запитання, яке ставить operations-команда: що змінилося і хто це зробив? Журнали аудиту n8n мають відповідати саме на це, але чесна відповідь така: «журнали аудиту» в n8n насправді охоплюють кілька окремих функцій з окремими вимогами до ліцензування, і розуміння цієї різниці визначає, який enterprise-план n8n вам справді потрібен, перш ніж довіряти відповіді.
Цей гід розглядає, що n8n записує сьогодні, які ролі несуть у собі особу, що стоїть за дією, і яка редакція відкриває повну картину — корисний контекст незалежно від того, чи ви оцінюєте n8n для enterprise-впровадження, чи пояснюєте перевіряючому з безпеки, чому саме Community-редакція не дасть журналу змін.
Що журнали аудиту n8n записують сьогодні: події Audit та Log Streaming
Структурований журнал аудиту n8n створюється функцією під назвою Log Streaming, яка генерує потік подій Audit щоразу, коли з робочим процесом або MCP-сервером відбувається щось важливе, згідно з документацією n8n.
- Події робочого процесу, такі як створення, оновлення, видалення, архівування, активація та деактивація
- Події MCP-сервера, доступні починаючи з n8n 2.34.0 на self-hosted інстансах
Log Streaming, а отже й журнали аудиту n8n, які він створює, доступний лише в рівні Enterprise — як у n8n Cloud, так і в self-hosted версії. Community-редакція включає базове логування, але явно виключає Log Streaming, тож нижче рівня Enterprise немає структурованого журналу аудиту, на який можна покладатися для відстеження змін.
Перш ніж вмикати цю функцію, варто знати одну деталь налаштування: якщо для призначення увімкнено anonymizeAuditMessages, у згенерованій події видаляються email і відображуване ім'я користувача, але userId і authType залишаються незмінними, тож дії залишаються прив'язаними до конкретного облікового запису навіть з прихованими іменами. Команди на self-hosted, що використовують n8n 2.34.0 або новіше, також отримують специфічні для MCP події аудиту, які охоплюють завершення OAuth, виклики інструментів і перемикання доступу для MCP-серверів на рівні інстансу; попередні версії таких подій не генерують.
Sources: Stream logs to external systems | Administer | n8n Docs, Compare editions | Deploy | n8n Docs
Хто це зробив: ролі RBAC за кожною дією
Подія аудиту корисна, лише якщо вона прив'язана до реальної особи, а це залежить від контролю доступу на основі ролей (RBAC) у n8n. Контроль доступу на рівні проєкту — визначення того, хто може переглядати чи редагувати які робочі процеси — доступний широко: його підтримують усі плани n8n Cloud, а також self-hosted редакції Registered Community, Business та Enterprise.
Тонше налаштування потребує вищого рівня. Роль Project Editor, яка дозволяє створювати, редагувати та видаляти робочі процеси всередині проєкту, вимагає Cloud Pro або self-hosted Enterprise. Роль Project Viewer лише для читання, корисна для надання аудитору видимості без прав на редагування, вимагає Cloud Enterprise або self-hosted Enterprise. Користувацькі ролі інстансу та проєкту, окрім вбудованого набору Admin, Editor і Viewer, доступні лише в Enterprise — як у Cloud, так і в self-hosted.
| Роль або контроль | n8n Cloud | Self-hosted | Що це дає команді |
|---|---|---|---|
| Контроль доступу до проєкту | Усі плани | Registered Community, Business, Enterprise | Обмежити, хто може переглядати чи редагувати робочий процес |
| Project Editor | Pro | Enterprise | Створювати, редагувати та видаляти робочі процеси в проєкті |
| Project Viewer | Enterprise | Enterprise | Доступ лише для читання, корисний для аудитора |
| Користувацькі ролі інстансу/проєкту | Enterprise | Enterprise | Точніше керування, ніж стандартні ролі |
У незареєстрованій self-hosted Community-редакції моделі спільного доступу взагалі немає: доступ мають лише власник інстансу та той, хто спочатку створив робочий процес або обліковий запис. Це обмежує доступ за замовчуванням, але не створює жодного запису про те, що змінилося і ким.
Sources: Set permissions and roles (RBAC) | Administer | n8n Docs, See available roles | Administer | n8n Docs, Compare editions | Deploy | n8n Docs
Історія робочого процесу проти журналу аудиту
Окрема функція — повна історія версій робочого процесу — показує, що змінилося всередині визначення робочого процесу, і дозволяє відновити попередню версію. Як і Log Streaming, вона доступна лише в Enterprise — як у n8n Cloud, так і в self-hosted.
Ці два журнали не повністю перетинаються. Історія робочого процесу фіксує повні зміни визначення — редагування вузлів і параметрів, відновлення, Git-пули — але зміна лише налаштувань робочого процесу не створює нової версії, яку можна відстежити. Документація n8n не вказує, чи з'являється зміна лише налаштувань натомість у потоці подій Audit, тож ставтеся до цього як до відкритого питання, а не як до припущення, коли покладаєтесь на будь-який із цих журналів для перевірки відповідності вимогам.
Sources: View change history | Build | n8n Docs
Який план відкриває повну видимість
Загалом, можливість побачити, хто змінив робочий процес у n8n, — це не одна функція, а їхній комплект, і більша частина цього комплекту — та, що фактично створює журнали аудиту n8n та історію з можливістю відновлення — розташована на верхівці цінової драбини як у n8n Cloud, так і в self-hosted. Таблиця нижче зводить воєдино розглянуті елементи.
| Функція | n8n Cloud | Self-hosted |
|---|---|---|
| Log Streaming / події Audit | Enterprise | Enterprise |
| Повна історія версій робочого процесу | Enterprise | Enterprise |
| Контроль доступу до проєкту | Усі плани | Registered Community, Business, Enterprise |
| Project Viewer (лише читання) | Enterprise | Enterprise |
| Користувацькі ролі інстансу/проєкту | Enterprise | Enterprise |
Практичний висновок для будь-кого, хто зважує enterprise-сценарії використання n8n проти дешевшого рівня, такий: Business або Cloud Pro дають контроль доступу, але не журнал аудиту чи історію версій, яких зазвичай очікує перевірка на відповідність вимогам.
Sources: Stream logs to external systems | Administer | n8n Docs, View change history | Build | n8n Docs, Set permissions and roles (RBAC) | Administer | n8n Docs, See available roles | Administer | n8n Docs, Compare editions | Deploy | n8n Docs
Практична рекомендація для команди, що зростає
З огляду на наведену вище відповідність, сприймайте «можливість бачити, хто до чого торкався» як дві окремі покупки, а не один пункт: потік подій Audit і повна історія робочого процесу обидва доступні лише в Enterprise на Cloud і self-hosted, тож самого плану Business недостатньо, щоб закрити цю прогалину.
Тим часом кілька конкретних кроків дозволяють знизити ризик, не чекаючи на рішення щодо ліцензування.
Sources: Stream logs to external systems | Administer | n8n Docs, View change history | Build | n8n Docs, Set permissions and roles (RBAC) | Administer | n8n Docs, Compare editions | Deploy | n8n Docs
Обмеження та відкриті питання
Варто чітко зазначити кілька прогалин. Жодна з використаних тут документацій n8n не описує порівняння змін на рівні окремих полів усередині події аудиту — ви дізнаєтесь, що робочий процес було оновлено, але не точно, який саме параметр змінився. Точні періоди зберігання історії робочого процесу для рівнів нижче Enterprise також існують у документації n8n, але тут не деталізовані; перевіряйте актуальні цифри безпосередньо в документації n8n.
Документація щодо Log Streaming, на яку посилаємось вище, також є частковим витягом, тож можуть існувати додаткові деталі налаштування, не охоплені цим підсумком.
