Dify 安全加固方案｜一键部署

在企业级 AI 应用快速落地的过程中，Dify 作为一款开源的大模型应用开发平台，凭借可视化编排、知识库、Agent、工作流、API 发布等能力，已经被越来越多团队用于构建智能客服、企业知识助手、自动化运营工具以及内部 Copilot 系统。

然而，Dify 一旦部署到生产环境，就不再只是一个“应用平台”，而是连接了大模型、数据库、向量库、对象存储、API 密钥、用户数据、知识库文档和业务系统的核心入口。如果安全配置不到位，可能面临账号被撞库、接口被滥用、数据泄露、模型调用成本失控、内部知识库被非法访问等风险。

本文将围绕 Dify 私有化部署后的安全加固 展开，提供一套适用于生产环境的安全方案，并给出“一键部署/加固”的思路与脚本示例，帮助企业在上线前快速完成基础安全治理。

一、为什么 Dify 需要安全加固？

很多团队在部署 Dify 时，通常会采用官方 Docker Compose 方式快速启动服务。这种方式非常适合测试和验证，但如果直接暴露到公网生产环境，往往会存在以下问题：

1. 默认端口直接暴露

   • Web 服务、API 服务、数据库、Redis、向量库等端口如果未做限制，可能被公网扫描。
   • 一旦数据库或 Redis 端口暴露，风险极高。

2. 弱口令或默认密钥

   • 部署时如果未修改 .env 中的密钥、数据库密码、Redis 密码，容易被攻击者利用。
   • JWT、Session、API Secret 等配置如果过于简单，可能导致身份伪造或接口滥用。

3. 缺少 HTTPS

   • 如果后台登录、API 调用、用户会话通过 HTTP 明文传输，存在被中间人窃听的风险。
   • 企业知识库、用户 Prompt、模型响应内容都可能泄露。

4. 缺少访问控制

   • 管理后台如果暴露给公网，容易遭受爆破、扫描、自动化攻击。
   • 内部系统应优先限制来源 IP，或放置于 VPN / 零信任网关后方。

5. 日志与审计不足

   • 如果没有对登录、接口调用、异常请求进行记录，发生安全事件后难以溯源。
   • 企业在合规要求下通常需要保留访问日志与操作记录。

6. 模型接口成本风险

   • Dify 通常会连接 OpenAI、Azure OpenAI、Anthropic、通义千问、文心一言、DeepSeek、私有大模型等。
   • 一旦应用 API 被滥用，可能造成大量 Token 消耗和费用损失。

7. 知识库数据泄露

   • Dify 知识库中可能存放合同、制度、代码文档、客户资料、财务数据等敏感内容。
   • 如果权限隔离不到位，将产生严重的数据泄露风险。

因此，Dify 的安全加固不应只停留在“能跑起来”，而应覆盖 网络、账号、密钥、容器、数据库、HTTPS、权限、日志、备份、监控 等多个方面。

二、Dify 生产环境安全目标

在设计加固方案之前，我们需要明确生产环境的安全目标：

三、推荐部署架构

生产环境推荐采用如下架构：

用户 / 企业员工
        |
        v
  HTTPS / WAF / CDN
        |
        v
 Nginx / Traefik 反向代理
        |
        v
 Dify Web / API / Worker
        |
        +-------------------+
        |                   |
        v                   v
 PostgreSQL              Redis
        |
        v
 向量数据库 / 对象存储

核心原则

• 公网只暴露 Nginx 的 80/443 端口
• Dify 内部服务端口不直接暴露公网
• PostgreSQL、Redis、向量数据库仅允许容器网络访问
• 通过 HTTPS 统一入口访问
• 使用防火墙限制 SSH 端口来源
• 管理后台建议放置在 VPN、堡垒机或零信任网关后方

四、系统层安全加固

1. 创建专用部署用户

不要长期使用 root 用户运行部署和维护任务，建议创建专用用户：

adduser dify
usermod -aG docker dify

然后使用该用户进行日常运维。

2. 配置 SSH 安全策略

修改 SSH 配置：

vim /etc/ssh/sshd_config

建议配置：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 22222

重启 SSH：

systemctl restart sshd

注意：修改 SSH 端口和禁用密码登录前，请确保密钥登录已经测试成功，否则可能导致无法登录服务器。

3. 配置防火墙

Ubuntu 可使用 ufw：

ufw default deny incoming
ufw default allow outgoing

ufw allow 80/tcp
ufw allow 443/tcp

# 仅允许指定 IP 访问 SSH
ufw allow from 你的办公IP to any port 22222 proto tcp

ufw enable
ufw status

如果你的 Dify 仅供企业内部使用，可以进一步限制 80/443 访问来源，只允许公司出口 IP 或 VPN 网段访问。

五、Docker 与容器安全加固

Dify 通常通过 Docker Compose 部署。容器安全的关键是：不暴露不必要端口、不使用高权限容器、不挂载敏感目录、不使用默认密码。

1. 不将数据库端口暴露到公网

错误示例：

ports:
  - "5432:5432"

生产环境不建议这样配置。应改为仅在内部网络通信：

services:
  db:
    image: postgres:15
    networks:
      - dify_internal

应用服务通过 Docker 网络访问数据库即可。

2. Redis 不允许公网访问

Redis 一旦暴露公网且无强认证，风险非常高。建议：

• 不映射 6379 到宿主机
• 设置强密码
• 关闭危险命令或限制访问
• 仅允许容器内部访问

示例：

redis:
  image: redis:6-alpine
  command: redis-server --requirepass ${REDIS_PASSWORD}
  networks:
    - dify_internal

3. 使用独立 Docker 网络

networks:
  dify_internal:
    driver: bridge
  dify_public:
    driver: bridge

• Nginx 连接 dify_public
• Dify API/Web 同时连接 dify_public 和 dify_internal
• 数据库、Redis、向量库只连接 dify_internal

这样可以显著减少横向攻击面。

六、环境变量与密钥加固

Dify 的 .env 文件中通常包含大量敏感配置，例如：

• 数据库账号密码
• Redis 密码
• Secret Key
• API Key
• 对象存储密钥
• 模型供应商 Key
• 邮件服务密码

1. 使用高强度随机密钥

可以使用如下命令生成随机字符串：

openssl rand -base64 48

对于关键配置，建议至少使用 32 位以上随机字符串。

2. 限制 .env 文件权限

chown dify:dify .env
chmod 600 .env

确保只有部署用户可读取。

3. 不要将 .env 提交到 Git

在 .gitignore 中加入：

.env
*.env
.env.*

如果团队使用 GitOps 或 CI/CD，建议使用：

• GitHub Actions Secrets
• GitLab CI Variables
• Vault
• 1Password
• AWS Secrets Manager
• 阿里云 KMS
• 腾讯云 KMS

七、HTTPS 与反向代理加固

生产环境必须启用 HTTPS。可以使用 Nginx + Let’s Encrypt，也可以使用云厂商证书。

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;

    client_max_body_size 100M;

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

    location / {
        proxy_pass http://web:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header Real-IP $remote_addr;
        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 /api/ {
        proxy_pass http://api:5001;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header Real-IP $remote_addr;
        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;
    }
}

八、限流与防爆破

为了防止登录接口、API 接口被暴力请求，可以在 Nginx 中配置限流。

Nginx 限流示例

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

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

    location /console/api/login {
        limit_req zone=login_limit burst=5 nodelay;
        proxy_pass http://api:5001;
    }

    location /api/ {
        limit_req zone=api_limit burst=30 nodelay;
        proxy_pass http://api:5001;
    }
}

建议策略：

• 登录接口：每个 IP 每分钟 5 次左右
• API 接口：根据业务设置调用频率
• 管理后台：限制办公 IP 或 VPN IP
• 高价值接口：增加应用层鉴权、签名校验或网关策略

九、Dify 应用层安全配置

1. 管理员账号安全

上线前应完成以下动作：

• 修改默认管理员账号
• 使用高强度密码
• 禁止多人共用管理员账号
• 定期轮换管理员密码
• 离职人员及时移除权限
• 如支持 SSO，优先接入企业身份源

2. API Key 管理

Dify 发布应用后，通常会生成 API Key。API Key 应遵循：

• 不在前端代码中硬编码
• 不上传到公开 Git 仓库
• 不通过普通聊天工具明文发送
• 不同系统使用不同 API Key
• 定期轮换 Key
• 发现异常调用立即禁用
• 对 API 设置配额和限流

3. 知识库权限隔离

企业内部知识库应根据部门、项目、角色进行隔离。例如：

不要将所有文档都放入同一个知识库，也不要让所有应用都能访问全部知识库。

4. Prompt 与输出安全

Dify 应用面向外部用户时，需要注意 Prompt Injection 风险。建议：

• 在系统提示词中明确禁止泄露内部规则
• 不允许模型输出密钥、内部配置、系统提示词
• 对用户输入做长度限制
• 对高风险输出做人工审核
• 避免让模型直接执行高权限业务操作
• 对工具调用增加二次确认机制

例如，对于能够调用 CRM、ERP、工单系统的 Agent，不应让模型在未确认的情况下直接执行删除、转账、审批等高风险操作。

十、数据备份与恢复策略

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

1. PostgreSQL 数据库
2. 向量数据库数据
3. 对象存储中的文件
4. .env 配置文件
5. Docker Compose 文件
6. Nginx 配置和证书
7. 应用工作流、Prompt、知识库配置

PostgreSQL 备份示例

#!/bin/bash

BACKUP_DIR="/opt/backups/dify"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p $BACKUP_DIR

docker exec dify-db pg_dump -U postgres dify > $BACKUP_DIR/dify_db_$DATE.sql

find $BACKUP_DIR -type f -mtime +14 -delete

建议：

• 每日至少备份一次
• 关键业务可每 6 小时备份一次
• 备份文件应加密存储
• 定期做恢复演练
• 不要只备份到同一台服务器
• 至少保留一份异地备份

十一、日志审计与监控

安全不是“一次性配置”，而是持续运营。上线后应关注：

1. Nginx 访问日志

重点分析：

• 异常高频 IP
• 大量 401/403/404 请求
• 非正常 User-Agent
• 高频登录失败
• 异常 API 调用量

2. Dify 应用日志

关注：

• 认证失败
• API Key 调用异常
• 工作流执行失败
• 模型调用异常
• 工具调用异常
• 知识库检索异常

3. 资源监控

建议监控：

• CPU 使用率
• 内存使用率
• 磁盘空间
• PostgreSQL 连接数
• Redis 内存
• Worker 队列积压
• API 响应时间
• 模型 Token 消耗

可以使用 Prometheus、Grafana、Loki、ELK、云监控等工具。

十二、一键安全加固脚本示例

下面提供一个基础的一键加固脚本，用于初始化服务器安全策略、生成随机密钥、配置防火墙、设置文件权限等。

注意：脚本仅作为参考，生产环境执行前请根据自身服务器系统、端口、网络策略进行测试。

#!/bin/bash

set -e

echo "===================================="
echo " Dify 安全加固初始化脚本"
echo "===================================="

DEPLOY_USER="dify"
SSH_PORT="22222"
ALLOW_SSH_IP="你的办公公网IP"

echo "[1/8] 创建部署用户..."
if id "$DEPLOY_USER" >/dev/null 2>&1; then
  echo "用户 $DEPLOY_USER 已存在"
else
  adduser --disabled-password --gecos "" $DEPLOY_USER
  usermod -aG docker $DEPLOY_USER || true
fi

echo "[2/8] 生成安全密钥..."
mkdir -p /opt/dify-secure

cat > /opt/dify-secure/secrets.env < /etc/docker/daemon.json <

1. 检查系统环境
2. 安装 Docker 与 Docker Compose
3. 创建专用用户
4. 拉取 Dify 部署文件
5. 生成随机密钥并写入 .env
6. 修改 docker-compose.yml，隐藏内部端口
7. 配置 Nginx 反向代理
8. 申请并配置 HTTPS 证书
9. 配置防火墙
10. 启动 Dify 服务
11. 初始化管理员账号
12. 配置模型供应商
13. 配置备份任务
14. 配置日志与监控
15. 进行安全检查

docker compose ps
docker compose logs -f api
docker compose logs -f web
docker compose logs -f worker