امنیت n8n: اعتبارنامه، وب‌هوک و SSRF

n8n به اعتبارنامه‌های همهٔ سیستم‌های شما (CRM، ایمیل، انبار، درگاه) دسترسی دارد و یک آدرس عمومی برای وب‌هوک باز می‌کند. یعنی یک خطای کوچک پیکربندی، دروازه‌ای به بقیهٔ زیرساخت است. این مقاله لایه‌های امنیتی n8n را بر پایهٔ مستندات رسمی مرتب می‌کند: اعتبارنامه و کلید رمزنگاری، وب‌هوک، دسترسی خروجی (SSRF)، کاهش سطح حمله، دسترسی کاربران و داده اجرا.

مرجع و نسخه: مستندات رسمی n8n در ۱۹ اکتبر ۲۰۲۶ خوانده شد؛ «نسخهٔ پایدار ۲٫۴۳٫۷ و بتای ۲٫۴۴٫۳». چند قابلیت در نسخه‌های مشخص آمده‌اند (محافظت SSRF از ۲٫۱۲٫۰، پنهان‌سازی اجرا از ۲٫۱۶٫۰ و ۲٫۲۶٫۰، چرخش کلید از ۳٫۰ پیش‌فرض) و چند قابلیت فقط در نسخهٔ Enterprise‌اند؛ پیش از اتکا، نسخه و ویرایش خودتان را با مستندات بسنجید. ما ادعای «ایمن‌سازی کامل» نداریم؛ این مقاله فهرست کنترل‌هاست، نه تضمین. همهٔ مقادیر در مثال‌ها ساختگی‌اند. برای مفهوم HTTPS SSL و HTTPS چیست و برای نگه‌داری کلیدها در مخزن محافظت از Secretها و API Keyها را ببینید.

مدل تهدید ساده

اعتبارنامه و کلید رمزنگاری

مستندات چرخش کلید یک مدل دولایه را شرح می‌دهد: کلید نمونه (N8N_ENCRYPTION_KEY) که در زمان استقرار تعیین می‌شود و تغییر نمی‌کند، و کلید رمزنگاری داده که مستقیماً اعتبارنامه‌ها را رمز می‌کند و همان است که می‌چرخانید. هنگام چرخش، کلید جدید برای نوشتن‌های بعدی به‌کار می‌رود و داده قدیمی خوانا می‌ماند و در به‌روزرسانی بعدی هر رکورد دوباره رمز می‌شود. نکات مهم:

• در 2.x برای فعال‌سازی، متغیر N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true را روی همهٔ نمونه‌ها (اصلی و worker) بگذارید و راه‌اندازی دوباره کنید؛ از 3.0 پیش‌فرض روشن است.
• پیش از فعال‌سازی پشتیبان کامل بگیرید؛ پس از نوشتن داده با قالب جدید، نسخه‌های قدیمی‌تر n8n آن را نمی‌خوانند و downgrade نکنید.
• خاموش‌کردن چرخش از 2.40.3 امن است؛ در نسخه‌های قبلی داده‌های رمز‌شده پس از فعال‌سازی را غیرقابل‌دسترس می‌کند.
• همهٔ نمونه‌ها باید کلید نمونهٔ یکسان داشته باشند.

برای اسرار سازمانی، external secrets گزینه است (Enterprise): مقدارها در گاوصندوق بیرونی می‌مانند و n8n آن‌ها را هنگام نیاز می‌خواند. ارائه‌دهندگان پشتیبانی‌شده 1Password Connect، AWS Secrets Manager، Azure Key Vault، GCP Secrets Manager، HashiCorp Vault و Infisical‌اند؛ فقط متن ساده و فقط در فیلد اعتبارنامه حل می‌شوند، نه هر فیلد عبارت‌پذیر.

وب‌هوک: احراز هویت و محدودیت

گرهٔ Webhook سه روش احراز هویت دارد (Basic، Header، JWT) یا هیچ. گزینهٔ «IP(s) Allowlist» دسترسی از IPهای بیرون فهرست را با ۴۰۳ رد می‌کند و «Only Run If» عبارتی است که پس از احراز هویت و فهرست IP روی درخواست ارزیابی می‌شود (درخواست‌های نامطابق ۲۰۰ می‌گیرند ولی اجرایی ساخته نمی‌شود). پیش‌فرض CORS «همهٔ مبداها» (*) است. توصیه‌ها (نویسنده، سازگار با مستندات):

1. هیچ وب‌هوک تولیدی بدون احراز هویت نداشته باشید؛ ممیزی امنیتی n8n «وب‌هوک‌های محافظت‌نشده» را گزارش می‌دهد.
2. برای سرویسی که از IPهای ثابت تماس می‌گیرد، فهرست IP بگذارید.
3. اگر امضای وب‌هوک را فروشنده تعیین می‌کند (مثل درگاه‌ها)، امضا را در گردش‌کار خودتان راستی‌آزمایی کنید؛ احراز هویت ساده کافی نیست.
4. CORS را از * به دامنهٔ مشخص محدود کنید.
5. آدرس آزمایشی را در محیط واقعی به‌کار نبرید.

دسترسی خروجی و SSRF

SSRF یعنی گره‌ای مثل HTTP Request به آدرس داخلی یا متادیتای ابری وصل شود. از نسخهٔ 2.12.0 می‌توان N8N_SSRF_PROTECTION_ENABLED=true گذاشت؛ بازه‌های خصوصی (RFC 1918)، loopback، link-local، IPv6 محلی و بازه‌های رزرو پیش‌فرض بسته می‌شوند و ریدایرکت و DNS هم بررسی می‌شود. فهرست مجاز (hostname و IP) بر فهرست مسدود مقدم است و فقط hostnameهایی را مجاز کنید که زیر کنترل خودتان است. مستندات صریحاً می‌گوید این یک دفاع تکمیلی است و خط اول باید فایروال و سیاست شبکه باشد.

کاهش سطح حمله

• گره‌های خطرناک: با NODES_EXCLUDE گره‌هایی مثل Execute Command و Read/Write Files from Disk را مسدود کنید (بعضی پیش‌فرض بسته‌اند).
• API عمومی: اگر استفاده نمی‌کنید، N8N_PUBLIC_API_DISABLED=true؛ playground هم جدا قابل غیرفعال‌سازی است.
• دسترسی فایل: N8N_RESTRICT_FILE_ACCESS_TO و N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES (پیش‌فرض true).
• متغیرهای محیطی در عبارت‌ها: N8N_BLOCK_ENV_ACCESS_IN_NODE پیش‌فرض false است؛ اگر کاربران همه قابل‌اعتماد نیستند true کنید.
• کوکی: N8N_SECURE_COOKIE پیش‌فرض true است؛ آن را خاموش نکنید.

دسترسی کاربران

مستندات متغیر N8N_MFA_ENFORCED_ENABLED را برای اجبار احراز هویت دومرحله‌ای معرفی می‌کند و از SSO (SAML یا OIDC) هم سخن می‌گوید. اصل حداقل دسترسی: همه ادمین نباشند، اعتبارنامه‌ها فقط در پروژه‌ای که لازم است اشتراک شوند، و حساب‌های سرویس برای اتصال به سیستم‌های دیگر دسترسی حداقلی داشته باشند.

داده اجرا

اجراها ورودی و خروجی هر گره را نگه می‌دارند و ممکن است شامل داده شخصی یا توکن باشند. دو لایه: (۱) نگه‌داری کمتر (ذخیرهٔ فقط اجراهای ناموفق، حذف خودکار)، (۲) پنهان‌سازی داده اجرا که فقط در Enterprise است (per-workflow از 2.16.0 و اجبار سراسری از 2.26.0) و ورودی/خروجی گره‌ها را پنهان می‌کند، اما فراداده (وضعیت، زمان، نام گره) دیده می‌شود. مقررات داده شخصی ایران بررسی نشده؛ از منبع رسمی و مشاور حقوقی بپرسید.

ممیزی منظم

ممیزی امنیتی n8n پنج گزارش می‌دهد: اعتبارنامه‌های بلااستفاده، موارد پایگاه داده (عبارت در Execute Query)، گره‌های فایل‌سیستم، گره‌های پرخطر/سفارشی/جامعه، و مسائل نمونه (وب‌هوک محافظت‌نشده، تنظیمات ناقص، قدیمی بودن). آن را با CLI (n8n audit)، API یا گرهٔ n8n اجرا کنید و برنامهٔ ماهانه بگذارید. اعتبارنامه‌های بلااستفاده را حذف کنید. پایش و هشدار را با پایش سیستم کامل کنید.

TLS

مستندات پروکسی معکوس (Traefik یا NLB) را توصیه می‌کند؛ گزینهٔ دیگر دادن مستقیم گواهی با N8N_SSL_CERT و N8N_SSL_KEY است که نوسازی آن با شماست.

اشتباهات رایج

• وب‌هوک بدون احراز هویت و با CORS باز.
• کلید رمزنگاری فقط روی همان سرور.
• فعال‌سازی چرخش کلید بدون پشتیبان و بدون در نظر گرفتن بازگشت.
• اتکا به SSRF protection به‌جای فایروال.
• همهٔ کاربران ادمین و اعتبارنامه‌های مشترک.
• نگه‌داری همهٔ اجراها با داده شخصی.

چک‌لیست

1. نسخه و ویرایش n8n با قابلیت‌های لازم (SSRF، چرخش کلید، پنهان‌سازی) سنجیده شده است.
2. پشتیبان کامل و کلید نمونه جدا نگه‌داری می‌شود.
3. همهٔ وب‌هوک‌های تولیدی احراز هویت دارند؛ فهرست IP و CORS محدود شده‌اند.
4. SSRF protection فعال و فایروال شبکه پیکربندی شده است.
5. گره‌های پرخطر مسدود و API عمومی در صورت عدم نیاز غیرفعال است.
6. MFA/SSO و حداقل دسترسی برقرار است.
7. سیاست نگه‌داری و پنهان‌سازی داده اجرا تعیین شده است.
8. ممیزی ماهانه و حذف اعتبارنامه‌های بلااستفاده برنامه‌ریزی شده است.

منابع و مراجع

• Rotate encryption keys — n8n Docs، 2026-10-19.
• External secrets — n8n Docs، 2026-10-19.
• Webhook node — n8n Docs، 2026-10-19.
• Enable SSRF protection — n8n Docs، 2026-10-19.
• Run security audits — n8n Docs، 2026-10-19.
• Block specific nodes — n8n Docs، 2026-10-19.
• Disable the public API — n8n Docs، 2026-10-19.
• Security environment variables — n8n Docs، 2026-10-19.
• Redact execution data — n8n Docs، 2026-10-19.
• Securing n8n overview — n8n Docs، 2026-10-19.
• Set up SSL — n8n Docs، 2026-10-19.