自托管工作流的必修课凭证管理、权限控制与公网暴露n8n 安全清单一次讲清【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400 integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n把 n8n 跑起来只需要一行docker run但把它安全地跑在生产环境里是另一门功课。作为一款支持自托管的工作流自动化平台n8n 的价值恰恰在于「数据不出自己的服务器」——这也意味着所有责任都落在你身上数据库里躺着明文可解的凭证密文公网挂着可被任意调用的 Webhook工作流节点能读写本地文件、访问内网 IP。任何一环失守攻击者拿到的可能不只是你的流程编排而是整套自动化体系里所有第三方服务的密钥。本文基于 n8n 仓库的真实源码从凭证加密、权限隔离、公网加固三个维度整理一份可直接落地的安全清单。凭证存储与加密从单密钥到分层密钥体系自托管 n8n 最容易踩的坑是「部署完就忘了密钥」。凭证加密的根基是N8N_ENCRYPTION_KEY实例加密密钥它在 packages/core/src/encryption/cipher.ts 中扮演核心角色。理解 n8n 的加密设计先要看懂它的两层结构第一层DEK 包装n8n 用encryptDEKWithInstanceKey将数据加密密钥DEK用实例密钥通过 AES-256-GCM 包装存储见 packages/core/src/encryption/cipher.ts 中的dekWrappingKey实现对实例密钥做 SHA-256 派生第二层数据加密凭证数据本身用 DEK 加密。新版输出带密钥 ID 前缀keyId:ciphertext旧版则是无前缀的 AES-256-CBC 密文解密时自动识别见decryptV2的KEY_ID_PATTERN分支。这套分层体系在 packages/cli/src/encryption/key-manager.service.ts 中落地为KeyManagerServiceDEK 记录持久化在deployment_key表中密钥只能「停用」不能删除且写入时强制「必须用实例密钥包装 DEK、绝不能用当前活跃 DEK 包装新 DEK」。启动时 packages/cli/src/encryption/encryption-bootstrap.service.ts 会完成三件事修复历史遗留格式的 DEK、回填旧版 CBC 密钥、播种一个新的 AES-256-GCM 活跃密钥。由此可以推导出几条硬性实践密钥必须显式设置并妥善备份。未设置N8N_ENCRYPTION_KEY时实例会自生成一旦容器重建、卷丢失数据库里所有凭证将永久无法解密——getData()只会抛CREDENTIAL_ERRORS.DECRYPTION_FAILED见 packages/core/src/credentials.ts。支持密钥轮换。KeyManagerService.rotateKey()生成新的 256 位 DEK 并原子地停用旧活跃密钥见 packages/cli/src/encryption/key-manager.service.ts密钥按 ID 索引、带 5 秒 TTL 的活跃密钥缓存保证多实例分布式场景下轮换能在一段窗口内收敛。管理入口是GlobalScope(encryptionKey:manage)保护的 REST 控制器 packages/cli/src/modules/encryption-key-manager/encryption-key.controller.ts。不要外泄实例密钥。它是所有 DEK 的根落入他人之手等同于凭证全量泄露。官方镜像默认以USER node非 root 运行见 docker/images/n8n/Dockerfile密钥则应通过环境变量或 secret 注入避免写死在镜像里。权限与隔离RBAC、项目与最小授权n8n 的权限体系在 packages/n8n/permissions/src/constants.ee.ts 中定义得非常细资源workflow、credential、project、user、variable……乘操作create、read、update、delete、list、share、execute、activate……构成 scope 矩阵。几个值得注意的设计credential:use是全局级权限语义是「可以使用实例上任意凭证、而不必属于其所在项目」——它被刻意排除在所有项目级 scope 之外源码注释明确说明。这意味着把credential:use授予某用户等于允许其在工作流中调用全量凭证授出时必须清醒project:manageMembers与project:update分离能编辑项目详情不等于能发放入会角色避免角色升级路径workflow资源上有enableRedaction/disableRedaction这类面向执行的细粒度控制。配合Projects项目n8n 提供了接近多租户的隔离凭证、工作流、变量都可以归属项目成员按项目获得限定 scope。自托管团队应默认「不共享、按项目分配」把高风险凭证数据库连接串、云厂商密钥圈在最小项目内而不是放进全局共享空间。文件与系统访问同样是隔离重点。packages/n8n/config/src/configs/security.config.ts 提供了一组生产必配项N8N_RESTRICT_FILE_ACCESS_TO限制ReadWriteFile、ReadBinaryFiles节点的读写目录默认~/.n8n-filesN8N_BLOCK_FILE_ACCESS_TO_N8N_FILES默认开启禁止节点访问 n8n 内部目录~/.n8n、二进制数据目录、模板目录等N8N_BLOCK_FILE_PATTERNS默认拦截.git目录访问N8N_AWS_SYSTEM_CREDENTIALS_ACCESS_ENABLED默认关闭禁止工作流通过 AWS AssumeRole 拉取系统级临时凭证防止容器元数据端点被滥用。公网部署的加固清单把 Webhook、表单端点暴露到公网是自托管 n8n 的常态需求这一节按风险优先级给出清单。第一优先SSRF 防护。HTTP Request 节点、从 URL 导入的工作流都可能让服务端向攻击者指定的地址发起请求。packages/n8n/config/src/configs/ssrf-protection.config.ts 定义了完整的策略配置要点如下N8N_SSRF_PROTECTION_ENABLED默认关闭为兼容存量自托管环境生产环境应显式开启内置阻塞列表SSRF_DEFAULT_BLOCKED_IP_RANGES覆盖 RFC 1918 私网段、loopback、链路本地含云厂商 metadata 端点169.254.0.0/16、IPv6 唯一本地地址等关键词default会自动展开为该内置列表可再追加如100.64.0.0/10运营商级共享地址空间最新版本已将此类范围纳入默认防护见 packages/cli/src/modules/breaking-changes/rules/v3/ssrf-default-blocked-ranges.rule.ts校验顺序是「允许主机名 → 阻塞主机名 → 允许 IP 段 → 阻塞 IP 段」且检查发生在预解析 DNS、连接建立、每个重定向跳转等多个阶段用于对抗 DNS rebindingTOCTOU内网服务需按白名单放行N8N_SSRF_ALLOWED_IP_RANGES或N8N_SSRF_ALLOWED_HOSTNAMES支持*.internal.example.com通配子域而N8N_SSRF_BLOCKED_HOSTNAMES仅适合做名称级的出口管控源码注释明确提示它可被 IP 字面量绕过不可替代 IP 段阻塞。第二优先认证与 Cookie。packages/n8n/config/src/configs/auth.config.ts 显示 n8n 认证 Cookie 默认带Secure标志N8N_SECURE_COOKIE默认 true与SameSitelax。这要求你的站点必须启用 HTTPS否则登录态将无法维持同源部署下切勿把 SameSite 改为none。若通过反向代理终结 TLS需确认代理正确透传并强制 HTTPS。第三优先Webhook 与表单的暴露面收敛。Webhook 端点路径段可用N8N_ENDPOINT_WEBHOOK等变量调整见 packages/n8n/config/src/configs/endpoints.config.ts配合带签名的 Webhook URL 使用表单页面依赖 CSP sandbox 约束脚本执行security 配置中N8N_INSECURE_DISABLE_WEBHOOK_IFRAME_SANDBOX、N8N_INSECURE_DISABLE_FORM_HTML_SANDBOX两个变量名称里的INSECURE_前缀已经把风险写在了脸上——源码注释警告禁用 form 的 CSP sandbox 会让恶意用户构建工作流、冒用其他用户的凭证发起请求。非必要不关闭且官方建议将表单服务到独立子域名而非关掉沙箱。第四优先纵深防御。N8N_CONTENT_SECURITY_POLICY支持自定义 CSP可用N8N_CONTENT_SECURITY_POLICY_REPORT_ONLY先灰度观察默认即提供一份 Level 3 策略N8N_POSTMESSAGE_ALLOWED_ORIGINS可限制外部页面驱动内嵌编辑器的 postMessage 通道默认接受任意来源生产建议显式收紧N8N_PAYLOAD_SIZE_MAX限制 API 载荷大小。若使用 metrics 端点确认N8N_METRICS仅在内网开启避免执行数据与 SSRF 命中数据暴露。最后一道防线内置安全审计。n8n 自带安全审计能力packages/cli/src/security-audit/security-audit.service.ts 中的SecurityAuditService.run()会扫描全部工作流的节点与连接按RISK_CATEGORIES生成风险报告对应 CLI 命令 packages/cli/src/commands/audit.ts。报告覆盖凭证风险如把 secrets 硬编码在工作流 JSON 中、数据库风险、文件系统访问风险等维度可作为每次大版本升级前后的例行体检。配合N8N_SECURITY_AUDIT_DAYS_ABANDONED_WORKFLOW默认 90 天圈定「僵尸工作流」清理掉那些无人维护却仍持有高权限凭证的流程——它们往往是攻破后的横向移动跳板。收尾把安全变成部署流程的一部分自托管工作流平台的悖论在于它赋予你完全的数据控制权同时把原本由 SaaS 厂商承担的安全责任移交给你。好在 n8n 的安全机制足够体系化——从分层的 DEK 加密与密钥轮换到按 scope 细分的 RBAC 与项目隔离再到面向公网场景的 SSRF 多阶段校验、CSP 沙箱与安全审计每一层都有对应的配置项和源码实现可查。与其在事故后补救不如把上面的清单固化进部署流程显式设置并备份加密密钥、按项目分配最小权限、开启 SSRF 防护并白名单内网、强制 HTTPS 与安全 Cookie、升级后跑一遍安全审计。做到这五条你的自托管 n8n 才真正配得上「数据不出服务器」这句承诺。【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400 integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考