امنیت و Self-hosting در n8n؛ چک‌لیست اجرای Workflowهای Production

وقتی n8n فقط یک Demo داخلی است، Restart شدن Container مزاحمت کوچکی است. وقتی همان Instance به CRM، Payment، فایل مشتری و پیام‌رسان متصل می‌شود، از دست‌رفتن Credential یا اجرای دوباره Workflow یک Incident واقعی است. Self-hosting یعنی کنترل بیشتر؛ و هم‌زمان پذیرش مسئولیت Patch، Backup، Restore، Network، Monitoring و پاسخ به Incident.

Threat model را قبل از Compose بنویسید

دارایی‌ها را مشخص کنید: Credentialها، Workflow definition، Execution data، PII، Webhook URL و دسترسی Editor. سپس Actorها و مسیرها را فهرست کنید: Internet، کاربر داخلی، Community Node، Code Node، Database، Redis و API مقصد. بدون Threat model، Checklist امنیتی به مجموعه تنظیمات پراکنده تبدیل می‌شود.

معماری پایه Production

یک استقرار رایج شامل Load balancer/Reverse proxy، Main n8n، PostgreSQL، Storage/Backup و Monitoring است. برای بار بیشتر، Queue Mode، Redis و Workerها اضافه می‌شوند. Database و Redis نباید Public باشند؛ فقط سرویس‌های لازم در شبکه خصوصی به آن‌ها دسترسی داشته باشند.

Reverse proxy و TLS

• HTTPS اجباری و Redirect HTTP.
• HSTS پس از اطمینان از TLS و Subdomainها.
• محدودیت Body size و Timeout براساس Webhook واقعی.
• ثبت Real client IP با Trust proxy صحیح؛ نه اعتماد کور به Header اینترنتی.
• Rate limit در Gateway و کنترل جدا برای Webhookهای حساس.

Editor UI در صورت امکان پشت VPN، Zero Trust access یا IP policy قرار گیرد. URL مخفی کنترل امنیتی نیست.

Identity و دسترسی

حساب مشترک تیمی نسازید. MFA/SSO در Plan و معماری قابل استفاده، Offboarding و Role حداقلی اهمیت دارد. حساب Owner روزمره استفاده نشود. دسترسی Deploy، Editor، Credential و Log باید جدا باشد.

Credential هر Integration باید Scope حداقلی داشته باشد. Token گزارش‌گیری نباید Permission حذف مشتری داشته باشد. برای Production و Staging Credential جدا و Rotation plan تعریف کنید.

Encryption key؛ وابستگی حیاتی

n8n Credentialها را با Encryption key محافظت می‌کند. اگر Key گم شود، Backup Database به‌تنهایی قابل استفاده نیست؛ اگر Key همراه Backup بدون کنترل ذخیره شود، مهاجم هر دو را دارد. Key را در Secret manager نگه دارید، دسترسی و Rotation/Recovery را مستند و Restore test را با همان وابستگی اجرا کنید.

Webhook Security

Webhook عمومی باید فرض کند ورودی مخرب و تکراری است:

• Signature/HMAC یا Authentication متناسب با Provider.
• Replay protection با Timestamp/Nonce در صورت امکان.
• Idempotency key برای Write.
• Schema و Size validation پیش از Parse/Processing سنگین.
• Allowlist فقط اگر IPهای Provider پایدار و رسمی‌اند؛ به‌عنوان لایه مکمل.
• پاسخ سریع و انتقال پردازش طولانی به Queue.
• عدم نمایش Stack trace یا Secret در پاسخ.

Code Node، Community Node و Task Runner

Code اجراشده می‌تواند مرز مهمی باشد. n8n برای Task Runner و Hardening مستندات جدا دارد؛ Runner خارجی و محدودسازی Environment/File access برای محیط حساس مهم است. Community Node در عمل Dependency با Supply-chain risk است: Publisher، Source، Update و Permission آن را بررسی کنید و Node غیرضروری نصب نکنید.

هرگز Secret را داخل Code یا Workflow JSON Hard-code نکنید. Export و Git history می‌تواند آن را ماندگار کند.

Queue Mode و Scaling

Queue Mode با Redis، Main و Workerها Execution را توزیع می‌کند. این معماری Availability را خودکار تضمین نمی‌کند؛ Dependencyهای بیشتری اضافه می‌کند.

• Concurrency براساس Rate limit و ماهیت Job تنظیم شود.
• Workerهای Task سنگین از Workflow کم‌هزینه جدا شوند.
• Redis durability و Recovery متناسب با نقش Queue بررسی شود.
• Binary data strategy در معماری چند Worker مشخص باشد.
• Graceful shutdown و Drain هنگام Deploy تست شود.
• Retry budget مانع فشار مضاعف بر Provider خراب شود.

افزایش Worker بدون Backpressure می‌تواند API مقصد را از کار بیندازد.

PostgreSQL، Execution Data و Retention

Database بخشی از محصول عملیاتی است. Connection، Encryption، Backup و Upgrade باید مدیریت شود. ذخیره همه Executionها برای همیشه هم هزینه و هم ریسک PII را بالا می‌برد. Retention براساس نیاز Audit، Debug و قانون تعیین و Pruning مانیتور شود.

Log و Execution data نباید Token، Password، متن حساس یا فایل کامل مشتری را بی‌دلیل ذخیره کنند. Redaction در Design Workflow انجام شود.

Backup کافی نیست؛ Restore معیار است

Backup set باید حداقل Database، Encryption key، تنظیمات لازم، Workflow export کنترل‌شده و مستندات Infrastructure را پوشش دهد. RPO و RTO تعریف کنید:

• RPO: چه مقدار داده قابل از دست‌رفتن است؟
• RTO: سرویس در چه مدت باید برگردد؟

Restore را در محیط جدا تمرین کنید و پس از بازیابی یک Workflow آزمایشی را End-to-end اجرا کنید. Backup خراب یا Key ناموجود در روز Incident کشف نشود.

Monitoring و Alerting

چهار سطح را ببینید:

1. Infrastructure: CPU، Memory، Disk، Container restart.
2. Platform: Queue depth، Worker availability، DB connection.
3. Workflow: Failure rate، Duration، Retry، Stuck execution.
4. Business: تعداد Lead ثبت‌شده، Invoice پردازش‌شده یا اختلاف Source/Destination.

سلامت Container به معنای صحت کسب‌وکار نیست. Reconciliation job اختلاف سیستم‌ها را پیدا می‌کند.

Alert باید Severity، Owner و Runbook داشته باشد. ارسال همه خطاها به یک Channel نتیجه‌ای جز Alert fatigue ندارد.

Update و Rollback

• Release note و Breaking change را بخوانید.
• Version image را Pin کنید؛ از Latest برای Production اجتناب کنید.
• Backup و Restore readiness را قبل از Upgrade تأیید کنید.
• Workflowهای حیاتی را در Staging با داده نماینده تست کنید.
• Migration Database و سازگاری Worker/Main را بررسی کنید.
• Rollback واقعی را بدانید؛ Downgrade پس از Migration همیشه ساده نیست.

Incidentهای محتمل و Runbook

• Credential لو رفته: Revoke، Rotate، Audit execution و مقصد.
• Webhook abuse: Rate limit/block، حفظ Evidence، بررسی Side effect.
• Queue backlog: توقف Ingress غیرضروری، بررسی Provider/Worker، Replay کنترل‌شده.
• Database restore: Freeze write، بازیابی، Reconciliation و اعلام Gap.
• Workflow خراب پس از Deploy: Disable، Rollback version و بررسی Executionهای نیمه‌کاره.

چک‌لیست Go-live

• [ ] Threat model و Data classification
• [ ] TLS، Network private و Editor access محدود
• [ ] حساب فردی، MFA/SSO و Least privilege
• [ ] Encryption key در Secret manager
• [ ] Webhook authentication، validation و idempotency
• [ ] PostgreSQL backup + Restore test
• [ ] Retention و Redaction Execution data
• [ ] Monitoring زیرساخت، Workflow و Business outcome
• [ ] Version pin، Staging و Rollback plan
• [ ] Runbook و Owner on-call

جمع‌بندی

Self-hosted n8n زمانی Production-ready است که Failure قابل مشاهده، داده قابل بازیابی، دسترسی محدود و تغییرات قابل Rollback باشند. Docker فقط روش بسته‌بندی است؛ امنیت و Reliability از کل چرخه عملیات می‌آیند.