Dify 安全加固方案｜生产环境实测

面向生产环境部署的 Dify 安全加固实践方案。本文基于真实生产场景，从网络边界、身份认证、密钥管理、容器安全、数据库与存储、模型调用、日志审计、漏洞治理、备份恢复等多个维度，系统梳理 Dify 上线前与运行中的安全加固要点。

一、背景：为什么 Dify 生产环境必须做安全加固？

Dify 是当前非常流行的开源 LLMOps 平台，能够帮助企业快速构建 AI 应用、智能体、知识库问答、工作流编排以及模型调用网关。由于它天然会接入大语言模型、知识库文档、API Key、用户输入数据、企业内部接口等敏感资源，一旦直接以默认配置暴露到公网，安全风险会非常高。

在测试环境中，很多团队通常会使用 Docker Compose 快速启动 Dify，几分钟内即可完成部署。但生产环境与测试环境完全不同，生产环境至少需要考虑以下问题：

• Dify 控制台是否暴露在公网？
• 管理员账号是否开启强密码策略和多因素认证？
• SECRET_KEY、数据库密码、模型 API Key 是否安全保存？
• Redis、PostgreSQL、向量数据库是否存在未授权访问风险？
• 用户上传的文件是否存在恶意内容或越权访问风险？
• 应用日志中是否泄露 prompt、token、密钥或用户隐私？
• AI 应用调用外部工具时是否可能触发 SSRF、命令注入、数据外传？
• 容器镜像、依赖组件是否存在已知漏洞？
• 发生误删、入侵、勒索或配置损坏时，是否可以快速恢复？

本文将围绕这些问题，给出一套适用于生产环境的 Dify 安全加固方案。

二、部署架构建议：不要让 Dify 裸奔在公网

生产环境部署 Dify，首先要明确一个原则：

Dify 不应直接以默认端口暴露到公网，必须放在受控网络边界之后。

推荐架构如下：

用户 / 企业员工
        |
        v
WAF / CDN / SLB / Nginx 网关
        |
        v
Dify Web / API 服务
        |
        +---- PostgreSQL
        |
        +---- Redis
        |
        +---- 向量数据库
        |
        +---- 对象存储
        |
        +---- Sandbox / Worker
        |
        +---- 外部模型服务

在生产中，可以采用以下隔离方式：

1. 公网只暴露 HTTPS 入口

   • 仅开放 443 端口；
   • 80 端口只用于跳转 HTTPS；
   • 不直接暴露 Dify API、数据库、Redis、向量库端口。

2. 管理后台限制访问来源

   • Dify 控制台建议仅允许办公网、VPN、堡垒机或零信任网关访问；
   • 如果确实需要公网访问，必须叠加 MFA、WAF、访问频率限制和审计。

3. 服务分层部署

   • Web/API 服务与数据库服务分离；
   • Worker 与 Sandbox 独立部署；
   • 对象存储、向量数据库与业务服务之间使用内网访问。

4. 安全组最小开放

   • PostgreSQL 仅允许 Dify API 服务访问；
   • Redis 仅允许 Dify 内部组件访问；
   • 向量数据库仅允许知识库服务访问；
   • 禁止将中间件端口直接开放到互联网。

三、HTTPS 与反向代理加固

Dify 上线生产环境时，建议统一通过 Nginx、Traefik、Ingress Controller 或云负载均衡器接入。

1. 强制启用 HTTPS

所有管理后台、API 调用和应用访问都应启用 HTTPS。避免用户登录凭据、会话 Cookie、知识库内容、Prompt 或 API Key 在传输过程中被窃听。

Nginx 示例配置：

server {
    listen 80;
    server_name dify.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name dify.example.com;

    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy strict-origin-when-cross-origin always;

    client_max_body_size 50m;

    location / {
        proxy_pass http://dify-web:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location /console/api {
        proxy_pass http://dify-api:5001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

2. 限制上传大小

Dify 常用于知识库构建，用户可能上传 PDF、Word、Excel、TXT 等文件。如果不限制上传大小，可能被恶意用户利用进行资源耗尽攻击。

建议根据业务情况配置：

client_max_body_size 50m;

如果知识库文档较大，可以适当提高，但不建议无限制。

3. 增加访问频率限制

对登录接口、API 调用接口、公开应用接口建议增加限流，例如：

limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=60r/m;

登录接口限流可以降低暴力破解风险，API 限流可以降低恶意调用导致的费用损失。

四、账号与权限安全

1. 禁用默认弱口令

Dify 初始化后，应立即修改管理员账号密码。生产环境建议密码符合以下要求：

• 长度不少于 12 位；
• 包含大小写字母、数字和特殊字符；
• 不使用公司名称、域名、手机号、生日等可猜测内容；
• 不与其他系统共用密码。

2. 开启企业统一身份认证

如果企业已有 IAM、LDAP、OIDC、SAML 或单点登录系统，建议将 Dify 接入统一身份认证体系，统一管理员工账号生命周期。

这样可以解决以下问题：

• 员工离职后账号及时禁用；
• 统一执行密码策略；
• 统一开启 MFA；
• 统一记录登录审计；
• 降低孤立账号和共享账号风险。

3. 管理员权限最小化

不要将所有使用者都设置为管理员。建议区分角色：

生产环境中尤其要避免“多人共用一个管理员账号”的情况，否则出现安全事件时无法追责。

五、环境变量与密钥管理

Dify 的生产配置中通常包含大量敏感信息，例如：

• SECRET_KEY
• 数据库用户名和密码
• Redis 密码
• 对象存储 AK/SK
• OpenAI、Azure OpenAI、Anthropic、通义千问、文心一言等模型 API Key
• 邮件服务密钥
• 第三方工具调用密钥

1. 不要使用默认 SECRET_KEY

SECRET_KEY 用于加密和签名相关数据，生产环境必须替换为高强度随机值。可以使用如下命令生成：

openssl rand -base64 42

生成后写入环境变量：

SECRET_KEY=your-random-secret-key

注意：
SECRET_KEY 一旦变更，可能影响已有加密数据的解密，因此生产环境上线前必须固定，后续更换要做好迁移和回滚方案。

2. 不要将 .env 提交到 Git

很多安全事故都源于 .env 文件被误提交到代码仓库。建议：

• .env 加入 .gitignore；
• 生产密钥使用 Kubernetes Secret、Docker Secret、Vault、云厂商 KMS 或密钥管理服务保存；
• 不在 IM、邮件、文档中明文传递密钥；
• 定期轮换模型 API Key 和对象存储密钥。

3. 密钥分级管理

建议将密钥按重要程度分级：

六、数据库安全加固

Dify 默认常用 PostgreSQL 作为关系数据库。生产环境数据库必须单独加固。

1. 禁止公网访问数据库

PostgreSQL 端口 5432 不应暴露到公网。安全组仅允许 Dify API 服务、备份服务器或堡垒机访问。

2. 使用强密码和独立账号

不要使用默认账号或弱密码。建议为 Dify 创建独立数据库账号：

CREATE USER dify_user WITH PASSWORD 'strong_password_here';
CREATE DATABASE dify OWNER dify_user;
GRANT ALL PRIVILEGES ON DATABASE dify TO dify_user;

不要直接使用数据库超级管理员账号连接应用。

3. 开启自动备份

数据库是 Dify 的核心资产之一，保存了应用配置、工作流、用户信息、知识库元数据、对话记录等重要内容。建议至少执行：

• 每日全量备份；
• 每小时或更短周期增量备份；
• 备份文件加密保存；
• 至少保留 7 天到 30 天；
• 定期做恢复演练。

4. 数据脱敏与最小保存

如果 Dify 中保存了用户对话内容、业务数据或个人信息，需根据合规要求进行脱敏、归档或清理。不要无限期保存所有对话日志。

七、Redis 安全加固

Redis 在 Dify 中通常用于缓存、队列或异步任务支持。Redis 一旦暴露公网，风险极高。

加固建议：

1. 禁止公网访问 Redis 6379 端口；
2. 设置 Redis 访问密码；
3. 禁用危险命令，例如 FLUSHALL、CONFIG、EVAL 等；
4. 开启持久化时注意权限控制；
5. 使用内网安全组限制来源 IP。

示例配置：

bind 0.0.0.0
requirepass strong_redis_password
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

如果 Redis 部署在云服务中，建议使用云厂商提供的访问控制、白名单、审计和备份能力。

八、向量数据库与知识库安全

Dify 的知识库通常会将企业文档切分、Embedding 后写入向量数据库。这里面可能包含大量内部知识、合同、制度、客户资料、研发文档等敏感信息。

1. 向量库不要暴露公网

无论使用 Weaviate、Qdrant、Milvus、PgVector，还是其他向量数据库，都应仅允许 Dify 内部服务访问。

2. 开启鉴权

部分向量数据库默认安全配置较弱，生产环境必须开启认证机制。例如：

• API Key；
• Token；
• 用户名密码；
• mTLS；
• 云服务 IAM 权限控制。

3. 知识库按业务隔离

不要把所有部门文档放在同一个知识库里。建议按业务线、部门、项目进行隔离，并控制应用访问范围。

例如：

• 人力制度知识库；
• 售后工单知识库；
• 研发规范知识库；
• 财务制度知识库；
• 客户合同知识库。

不同应用只能访问其业务需要的知识库，避免一个低权限应用检索到高敏感内容。

九、文件上传与对象存储安全

Dify 支持上传文件用于知识库解析或应用交互。文件上传是典型的攻击入口，必须重点加固。

1. 限制文件类型

建议仅允许业务需要的文件格式，例如：

• .pdf
• .docx
• .xlsx
• .txt
• .md
• .csv

不建议允许上传可执行文件、脚本文件或压缩包，例如：

• .exe
• .sh
• .bat
• .js
• .php
• .jar
• .zip
• .rar

2. 文件大小限制

需要在三层做限制：

• 前端上传限制；
• Dify 服务配置限制；
• Nginx / 网关限制。

这样可以避免攻击者绕过前端限制直接调用 API 上传大文件。

3. 对象存储权限最小化

如果使用 S3、MinIO、OSS、COS 等对象存储，建议：

• Bucket 不要公开读写；
• 使用专用账号访问；
• AK/SK 只授予必要权限；
• 开启服务端加密；
• 开启访问日志；
• 文件下载使用短时签名 URL。

十、Sandbox 与工具调用安全

Dify 支持工作流、工具调用、代码执行或外部 API 调用等能力。这些能力提升了应用灵活性，同时也带来了新的攻击面。

1. Sandbox 独立部署

代码执行类组件应与主服务隔离部署，避免代码执行风险影响核心数据库、密钥和控制台服务。

建议：

• 单独容器运行；
• 限制 CPU、内存和执行时间；
• 禁止挂载敏感目录；
• 不共享宿主机 Docker Socket；
• 限制外网访问；
• 禁止访问内网敏感地址。

2. 防止 SSRF

AI Agent 或工作流中如果允许用户输入 URL，再由系统访问，可能造成 SSRF 风险。攻击者可能诱导系统访问：

http://127.0.0.1:5001
http://localhost:6379
http://169.254.169.254/latest/meta-data/
http://internal-service.local

建议在网关或业务层加入 URL 访问控制：

• 禁止访问 127.0.0.1、localhost；
• 禁止访问内网地址段；
• 禁止访问云厂商元数据地址；
• 限制可访问域名白名单；
• 限制跳转次数；
• 禁止非 HTTP/HTTPS 协议。

3. 工具调用白名单

不要让应用随意调用所有内部系统 API。应基于业务需求配置工具白名单，例如：

• 查询订单状态；
• 创建客服工单；
• 检索公开知识库；
• 查询审批进度。

对于涉及写操作的工具，例如“退款”“删除数据”“修改权限”，必须增加二次确认、权限校验和审计记录。

十一、模型 API Key 与费用安全

Dify 通常会连接多个大模型供应商。模型 API Key 泄露不仅会造成数据风险，还可能导致高额费用损失。

1. API Key 专用化

不要多个系统共用同一个模型 API Key。建议为 Dify 单独创建 Key，便于统计、限额和吊销。

2. 设置调用限额

在模型供应商后台设置：

• 每日调用额度；
• 每分钟请求数；
• 单次最大 Token；
• 预算告警；
• 异常消费提醒。

3. 控制公开应用访问

如果将 Dify 应用发布为公开链接，应注意：

• 是否需要登录；
• 是否限制来源域名；
• 是否增加验证码；
• 是否配置调用频率限制；
• 是否限制单用户会话次数；
• 是否对异常请求自动封禁。

公开 AI 应用很容易被爬虫或脚本滥用，导致模型费用快速增长。

十二、日志审计与隐私保护

日志是安全运营的重要基础，但 AI 应用日志中也容易包含敏感信息。

1. 应记录的日志

建议记录：

• 用户登录、登出；
• 管理员配置变更；
• 应用创建、删除、发布；
• 知识库上传、删除、重建索引；
• 模型供应商配置变更；
• 工具调用记录；
• 异常请求与失败登录；
• API Key 创建和删除。

2. 不应明文记录的内容

日志中应避免直接记录：

• 用户密码；
• 完整 API Key；
• 数据库密码；
• 对象存储密钥；
• 身份证号、手机号、银行卡号；
• 高敏感业务数据；
• 完整 Prompt 中的机密信息。

如确需保留对话日志用于排障或效果评估，应进行脱敏处理。

3. 日志集中化

生产环境建议将日志接入：

• ELK / OpenSearch；
• Loki + Grafana；
• 云日志服务；
• SIEM 平台。

并配置告警规则，例如：

• 管理员异地登录；
• 登录失败次数异常；
• API 调用量突增；
• 模型费用异常增长；
• 大量知识库删除；
• 大量文件上传失败；
• 非工作时间频繁修改配置。

十三、容器与宿主机安全

Dify 常见部署方式是 Docker Compose 或 Kubernetes。生产环境必须关注容器运行安全。

1. 使用固定版本镜像

不要长期使用 latest 标签。建议固定版本，例如：

image: langgenius/dify-api:0.x.x

这样可以避免镜像自动升级导致不可控变更。

2. 定期扫描镜像漏洞

可以使用以下工具：

• Trivy；
• Grype；
• Clair；
• 云厂商镜像扫描服务。

扫描对象包括：

• Dify 镜像；
• PostgreSQL 镜像；
• Redis 镜像；
• Nginx 镜像；
• Sandbox 镜像；
• Worker 镜像。

3. 最小权限运行容器

建议：

• 非必要不使用 privileged: true；
• 不挂载 /var/run/docker.sock；
• 不挂载宿主机根目录；
• 限制容器 CPU 和内存；
• 使用只读文件系统；
• 限制 Linux capabilities；
• 配置健康检查。

4. 宿主机加固

宿主机也需要做基础安全：

• 关闭不必要端口；
• 禁止 root 密码登录；
• 使用 SSH Key 登录；
• 修改默认 SSH 端口或限制来源 IP；
• 定期安装安全补丁；
• 开启防火墙；
• 安装主机安全 Agent；
• 配置时间同步；
• 开启系统审计。

十四、备份与灾难恢复

安全加固不仅是防攻击，也包括在事故发生后快速恢复。

Dify 生产环境至少要备份以下内容：

1. 备份策略

推荐采用：

• 每日全量备份；
• 高频增量备份；
• 异地备份；
• 加密备份；
• 备份完整性校验；
• 定期恢复演练。

2. 恢复演练

很多团队有备份，但没有做恢复演练。真正事故发生时才发现：

• 备份文件损坏；
• 缺少向量库数据；
• 缺少对象存储文件；
• SECRET_KEY 丢失；
• 配置文件版本不匹配；
• 数据库版本不兼容。

因此建议至少每季度进行一次恢复演练，并记录 RTO 和 RPO。

十五、生产环境实测检查清单

下面是一份可直接用于上线前验收的 Dify 安全检查清单。

1. 网络与访问控制

• [ ] 仅开放 80/443 端口到公网；
• [ ] 80 自动跳转 HTTPS；
• [ ] PostgreSQL 未暴露公网；
• [ ] Redis 未暴露公网；
• [ ] 向量数据库未暴露公网；
• [ ] 管理后台限制办公网、VPN 或零信任访问；
• [ ] 网关启用访问限流；
• [ ] 配置上传大小限制。

2. 身份认证

• [ ] 管理员密码已更换为强密码；
• [ ] 禁止共享管理员账号；
• [ ] 已接入企业 SSO 或统一身份认证；
• [ ] 管理员开启 MFA；
• [ ] 离职账号可自动禁用；
• [ ] 权限按角色分配。

3. 密钥安全

• [ ] 已替换默认 SECRET_KEY；
• [ ] .env 未提交 Git；
• [ ] 模型 API Key 独立创建；
• [ ] 密钥保存在 Secret 或 KMS 中；
• [ ] 已配置密钥轮换机制；
• [ ] 日志中不打印完整密钥。

4. 数据与存储

• [ ] PostgreSQL 使用独立低权限账号；
• [ ] 数据库已开启自动备份；
• [ ] Redis 设置密码；
• [ ] 对象存储 Bucket 非公开；
• [ ] 向量库开启鉴权；
• [ ] 知识库按业务隔离；
• [ ] 文件上传限制类型和大小。

5. 容器与主机

• [ ] 镜像版本固定；
• [ ] 镜像已完成漏洞扫描；
• [ ] 容器未使用特权模式；
• [ ] 未挂载 Docker Socket；
• [ ] 配置资源限制；
• [ ] 宿主机已安装安全补丁；
• [ ] SSH 登录已加固。

6. 日志与审计

• [ ] 登录日志可追溯；
• [ ] 管理操作有审计记录；
• [ ] 工具调用有审计记录；
• [ ] 日志已接入集中平台；
• [ ] 敏感字段已脱敏；
• [ ] 异常调用和费用突增有告警。

7. 备份恢复

• [ ] 数据库定期备份；
• [ ] 向量数据库定期备份；
• [ ] 对象存储定期备份；
• [ ] 配置文件纳入备份；
• [ ] 备份文件加密保存；
• [ ] 已完成恢复演练。

十六、生产环境实测结论

在生产环境实测中，Dify 的主要安全风险并不来自单一组件，而是来自“默认配置直接上线”和“AI 应用能力扩展后缺乏边界控制”。

尤其需要关注以下几个高风险点：

1. 控制台公网暴露

   • 如果没有 MFA、限流和来源限制，容易遭遇撞库和暴力破解。

2. 中间件端口开放

   • Redis、PostgreSQL、向量数据库一旦暴露公网，风险极高。

3. 模型 API Key 泄露

   • 可能造成高额账单，也可能导致数据被第三方滥用。

4. 知识库数据越权

   • 不同部门、不同业务的数据如果混放，容易造成内部数据泄露。

5. Agent 工具调用失控

   • 如果缺少白名单、权限校验和二次确认，可能误触发高危操作。

6. 日志泄露敏感信息

   • AI 应用日志往往包含用户输入、业务上下文和 Prompt，需要脱敏和权限控制。

7. 缺少恢复演练

   • 一旦数据库或对象存储损坏，没有经过验证的备份方案很难快速恢复。

综合来看，Dify 可以安全地用于生产环境，但前提是必须按照生产系统标准进行部署和运营，而不是简单运行一份默认 Docker Compose 配置。

十七、推荐落地优先级

如果团队资源有限，可以按照以下优先级逐步落地：

P0：必须立即完成

• 启用 HTTPS；
• 替换默认密钥；
• 修改管理员强密码；
• 禁止数据库、Redis、向量库公网访问；
• .env 不入库；
• 配置数据库备份；
• 限制管理后台访问来源。

P1：上线前完成

• 接入 SSO / MFA；
• 配置 WAF 和限流；
• 对象存储私有化；
• 文件上传类型和大小限制；
• 向量库开启鉴权；
• 镜像漏洞扫描；
• 日志脱敏；
• 模型 API Key 限额。

P2：持续优化

• 工具调用白名单；
• SSRF 防护；
• 容器运行时安全；
• 集中日志审计；
• SIEM 告警；
• 备份恢复演练；
• 定期渗透测试；
• 安全基线自动化检查。

十八、结语

Dify 降低了企业构建 AI 应用的门槛，但也让 AI 应用更快进入真实业务流程。只要涉及真实用户、企业知识库、内部 API、模型密钥和业务数据，Dify 就不再只是一个“开发工具”，而是生产系统的一部分。

生产环境中的 Dify 安全加固，应遵循三个核心原则：

1. 最小暴露面：能不开放公网就不开放，能走内网就走内网；
2. 最小权限：账号、密钥、数据库、对象存储、工具调用都只授予必要权限；
3. 可审计可恢复：所有关键操作可追踪，所有核心数据可恢复。

按照本文方案完成加固后，Dify 在企业内部知识库、智能客服、流程自动化、研发助手、运营分析等场景中可以更加稳定、安全地运行。安全不是一次性配置，而是持续运营过程。建议团队将 Dify 纳入统一的安全管理体系，定期进行漏洞扫描、权限复核、日志审计和恢复演练，才能真正支撑长期生产使用。