Dify 安全加固方案｜附源码

适用对象：使用 Docker / Docker Compose 部署 Dify 的团队、企业内网知识库系统、AI 应用平台运维人员。
目标：从网络、认证、数据、容器、日志、备份、权限、供应链等多个维度，对 Dify 进行系统性安全加固，降低未授权访问、数据泄露、接口滥用、容器逃逸、配置误用等风险。

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

Dify 是一个非常流行的开源 LLMOps 平台，常用于构建 AI 应用、企业知识库、智能客服、Agent 工作流等。由于 Dify 往往会连接大模型 API、企业内部文档、向量数据库、业务系统接口，因此它不只是一个普通 Web 服务，而是一个可能承载敏感数据和业务能力的 AI 中台。

如果 Dify 部署不当，可能带来以下风险：

1. 后台管理页面暴露在公网
   • 攻击者可能通过弱口令、撞库、漏洞扫描等方式尝试登录。
2. API Token 泄露
   • Dify 中通常会配置 OpenAI、Azure OpenAI、Claude、通义千问、DeepSeek 等模型供应商 Key，一旦泄露会造成经济损失。
3. 知识库文档泄露
   • 企业内部文档、合同、技术资料、客户信息可能被索引到知识库中。
4. 工作流接口被滥用
   • 如果应用 API 没有限流和鉴权，可能被恶意调用，导致 Token 消耗异常。
5. 容器权限过高
   • 默认 Docker 部署如果没有限制容器权限，存在被进一步利用的风险。
6. 缺少备份和审计
   • 一旦数据库损坏、误删、勒索攻击，恢复成本极高。
7. 反向代理配置不安全
   • 缺少 HTTPS、HSTS、安全响应头等配置，会增加中间人攻击和 XSS 风险。

因此，Dify 安全加固应当作为上线前的标准步骤，而不是上线后的补救措施。

二、整体安全架构建议

推荐采用如下部署架构：

用户
 |
 | HTTPS
 v
Nginx / OpenResty / Ingress
 |
 | 内网访问
 v
Dify Web / API
 |
 | 内部网络
 +--> PostgreSQL
 +--> Redis
 +--> Weaviate / Qdrant / Milvus
 +--> Worker
 +--> Sandbox
 |
 +--> 外部 LLM API

安全原则如下：

三、基础环境安全加固

1. 操作系统加固

建议使用 Ubuntu Server 22.04 LTS 或 Debian 12，并保持系统更新：

sudo apt update
sudo apt upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades curl wget vim git htop

开启自动安全更新：

sudo dpkg-reconfigure --priority=low unattended-upgrades

2. 防火墙配置

如果 Dify 通过 Nginx 暴露服务，只需要开放 SSH、HTTP、HTTPS：

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

如果 SSH 只允许公司出口 IP 登录，可以进一步限制：

sudo ufw delete allow 22/tcp
sudo ufw allow from 你的公司公网IP to any port 22 proto tcp

3. SSH 安全配置

编辑 SSH 配置：

sudo vim /etc/ssh/sshd_config

建议修改：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 22222
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

重启 SSH：

sudo systemctl restart ssh

注意：修改 SSH 端口前，请确认防火墙已放行新端口，并确保你已经配置好密钥登录，否则可能把自己锁在服务器外。

四、Dify 配置文件安全加固

Dify 通常使用 .env 文件保存关键配置。该文件包含数据库密码、Redis 密码、Secret Key、模型供应商 Key 等敏感信息，必须严格保护。

1. .env 权限设置

chmod 600 .env
chown root:root .env

2. 使用强随机密钥

生成强随机密钥：

openssl rand -base64 48

建议至少修改以下配置：

SECRET_KEY=请使用openssl生成的强随机字符串
CONSOLE_API_URL=https://dify.example.com
CONSOLE_WEB_URL=https://dify.example.com
SERVICE_API_URL=https://dify.example.com
APP_API_URL=https://dify.example.com
APP_WEB_URL=https://dify.example.com

3. 禁止开放注册

企业内部使用时，不建议开放用户自助注册。应由管理员手动创建账号，或者接入统一身份认证。

ALLOW_REGISTER=false

4. Cookie 安全配置

如果部署在 HTTPS 下，应启用安全 Cookie：

COOKIE_SECURE=true
COOKIE_HTTPONLY=true
COOKIE_SAMESITE=Lax

5. 数据库密码加固

不要使用默认密码。示例：

DB_USERNAME=postgres
DB_PASSWORD=请替换为高强度数据库密码
REDIS_PASSWORD=请替换为高强度Redis密码

强密码建议：

• 长度不少于 24 位；
• 包含大小写字母、数字和特殊字符；
• 不要复用其他系统密码；
• 定期轮换。

五、Docker Compose 安全加固示例

以下示例为一个安全加固版的 docker-compose.override.yml，用于在官方 Dify Compose 基础上增加安全限制。

说明：不同版本 Dify 的服务名可能略有不同，请根据实际 docker-compose.yml 调整。

version: "3.8"

services:
  api:
    restart: always
    read_only: false
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 512
    mem_limit: 2g
    cpus: "2.0"
    networks:
      - dify_internal

  worker:
    restart: always
    read_only: false
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 512
    mem_limit: 2g
    cpus: "2.0"
    networks:
      - dify_internal

  web:
    restart: always
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 256
    mem_limit: 1g
    cpus: "1.0"
    networks:
      - dify_internal

  db:
    restart: always
    ports: []
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 256
    mem_limit: 2g
    cpus: "1.0"
    networks:
      - dify_internal

  redis:
    restart: always
    ports: []
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 256
    mem_limit: 1g
    cpus: "1.0"
    networks:
      - dify_internal

networks:
  dify_internal:
    driver: bridge
    internal: false

这里重点做了几件事：

1. 移除不必要的 Linux Capability
   • 使用 cap_drop: ALL 降低容器权限。
2. 禁止权限提升
   • no-new-privileges:true 可以防止进程通过 setuid 等方式提升权限。
3. 限制资源
   • 通过 mem_limit、cpus、pids_limit 限制容器资源，防止异常任务拖垮服务器。
4. 数据库和 Redis 不映射端口
   • 避免 PostgreSQL、Redis 暴露到公网。
5. 容器自动重启
   • 提升服务可用性。

启动方式：

docker compose -f docker-compose.yml -f docker-compose.override.yml up -d

六、Nginx 反向代理安全配置源码

Dify 推荐放在 Nginx 后面，通过 HTTPS 统一暴露。以下是一个相对完整的 Nginx 安全配置示例。

假设域名为：

dify.example.com

1. 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/letsencrypt/live/dify.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dify.example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    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 Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # 基础限流，防止接口被刷
    limit_req_zone $binary_remote_addr zone=dify_api:10m rate=10r/s;
    limit_req zone=dify_api burst=30 nodelay;

    # 可选：限制后台访问 IP
    # 如果 Dify 只供公司内网使用，可取消注释
    # allow 你的公司公网IP;
    # deny all;

    location / {
        proxy_pass http://127.0.0.1:8080;

        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header Scheme $scheme;
        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 $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_connect_timeout 60s;
        proxy_send_timeout 120s;
        proxy_read_timeout 120s;
    }

    access_log /var/log/nginx/dify_access.log;
    error_log /var/log/nginx/dify_error.log;
}

2. 配置限流区域的正确写法

需要注意，limit_req_zone 一般应放在 http 块中，而不是 server 块中。如果你的 Nginx 不允许在 server 内定义，可以在 /etc/nginx/nginx.conf 的 http 段加入：

http {
    limit_req_zone $binary_remote_addr zone=dify_api:10m rate=10r/s;

    include /etc/nginx/conf.d/*.conf;
}

然后在站点配置中使用：

limit_req zone=dify_api burst=30 nodelay;

3. HTTPS 证书申请

使用 Certbot 申请证书：

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d dify.example.com

测试自动续期：

sudo certbot renew --dry-run

七、后台访问控制策略

如果 Dify 是企业内部系统，强烈建议不要直接暴露给整个公网。可以使用以下方式限制访问：

方案一：公司出口 IP 白名单

适合员工都通过固定办公网络访问的场景。

location / {
    allow 1.2.3.4;
    allow 5.6.7.8;
    deny all;

    proxy_pass http://127.0.0.1:8080;
}

方案二：VPN 访问

将 Dify 部署到内网，仅允许通过 VPN 访问，例如：

• WireGuard；
• OpenVPN；
• Tailscale；
• ZeroTier；
• 企业 SD-WAN。

这种方式安全性更高，尤其适合承载敏感知识库的系统。

方案三：增加 Basic Auth 二次认证

如果暂时没有统一身份认证，可使用 Nginx Basic Auth 增加一层保护。

安装工具：

sudo apt install -y apache2-utils

创建账号：

sudo htpasswd -c /etc/nginx/.dify_htpasswd admin

Nginx 配置：

location / {
    auth_basic "Dify Protected";
    auth_basic_user_file /etc/nginx/.dify_htpasswd;

    proxy_pass http://127.0.0.1:8080;
}

注意：Basic Auth 不能替代 Dify 自身账号体系，但可以有效减少扫描器和自动化攻击。

八、API 调用安全加固

Dify 应用通常会对外提供 API，如果接口直接暴露，容易被刷接口、撞 Token、消耗模型额度。

建议采用以下措施：

1. 为不同应用创建独立 API Key

不要多个系统共用同一个 API Key。每个业务系统应创建独立 Key，便于审计和吊销。

2. 设置网关限流

可以在 Nginx 中针对 API 路径做更严格的限流：

location /v1/ {
    limit_req zone=dify_api burst=10 nodelay;

    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

3. 增加来源校验

对于后端服务调用，可以限制来源 IP：

location /v1/ {
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    allow 192.168.0.0/16;
    deny all;

    proxy_pass http://127.0.0.1:8080;
}

4. 对外接口增加签名

如果业务方通过公网访问 Dify API，可以在前置网关增加签名校验。下面提供一个简单的 Python 签名校验示例。

客户端签名：

import time
import hmac
import hashlib
import requests

SECRET = "your-shared-secret"
URL = "https://dify.example.com/v1/chat-messages"

timestamp = str(int(time.time()))
body = '{"query":"你好","user":"user-001"}'

signature = hmac.new(
    SECRET.encode("utf-8"),
    (timestamp + body).encode("utf-8"),
    hashlib.sha256
).hexdigest()

headers = {
    "Authorization": "Bearer your-dify-api-key",
    "X-Timestamp": timestamp,
    "X-Signature": signature,
    "Content-Type": "application/json"
}

resp = requests.post(URL, headers=headers, data=body)
print(resp.text)

服务端可在 API 网关或自定义代理层验证 X-Timestamp 和 X-Signature，防止请求被篡改或重放。

九、数据库安全加固

1. PostgreSQL 不暴露公网

Docker Compose 中不要写：

ports:
  - "5432:5432"

除非有非常明确的运维需求。即使需要远程连接，也建议通过 SSH Tunnel：

ssh -L 5432:127.0.0.1:5432 user@server

2. 定期备份 PostgreSQL

创建备份脚本：

#!/usr/bin/env bash

set -e

BACKUP_DIR="/opt/backups/dify/postgres"
DATE=$(date +"%Y%m%d_%H%M%S")
CONTAINER_NAME="dify-db-1"
DB_USER="postgres"
DB_NAME="dify"

mkdir -p "$BACKUP_DIR"

docker exec "$CONTAINER_NAME" pg_dump -U "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_DIR/dify_pg_$DATE.sql.gz"

find "$BACKUP_DIR" -type f -name "*.gz" -mtime +30 -delete

echo "PostgreSQL backup completed: $BACKUP_DIR/dify_pg_$DATE.sql.gz"

保存为：

/opt/scripts/backup_dify_postgres.sh

赋予执行权限：

chmod +x /opt/scripts/backup_dify_postgres.sh

配置定时任务：

crontab -e

添加：

0 2 * * * /opt/scripts/backup_dify_postgres.sh >> /var/log/dify_backup.log 2>&1

3. 备份文件加密

如果备份中包含知识库、用户信息、应用配置，应加密存储：

gpg -c /opt/backups/dify/postgres/dify_pg_20250101_020000.sql.gz

也可以使用 OpenSSL：

openssl enc -aes-256-cbc -salt \
  -in dify_pg.sql.gz \
  -out dify_pg.sql.gz.enc \
  -pass pass:'你的强密码'

十、Redis 安全加固

Redis 应只允许 Dify 内部访问，不能暴露公网。配置上需要确保设置密码：

REDIS_PASSWORD=请替换为强密码

如果 Redis 配置文件可控，建议设置：

protected-mode yes
requirepass your-strong-redis-password
appendonly yes

另外，Redis 不建议开放危险命令。如果是独立部署 Redis，可以考虑重命名或禁用以下命令：

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command SHUTDOWN ""

十一、向量数据库安全加固

Dify 可能使用 Weaviate、Qdrant、Milvus 等向量数据库。向量库中可能存储文档切片、语义向量和元数据，因此同样需要保护。

建议：

1. 不开放公网端口；
2. 使用内部 Docker 网络；
3. 开启认证；
4. 对数据目录定期备份；
5. 不同环境使用不同实例；
6. 避免测试数据和生产数据混用。

以 Qdrant 为例，不建议暴露：

ports:
  - "6333:6333"

如确需远程访问，应通过 VPN 或 SSH Tunnel。

十二、日志与审计

1. Nginx 日志

通过 Nginx 访问日志可以发现异常 IP、高频请求、爬虫扫描等行为：

tail -f /var/log/nginx/dify_access.log

统计访问最多的 IP：

awk '{print $1}' /var/log/nginx/dify_access.log | sort | uniq -c | sort -nr | head

2. Dify 容器日志

查看 API 日志：

docker compose logs -f api

查看 worker 日志：

docker compose logs -f worker

3. 审计重点

应重点关注：

• 管理员登录行为；
• API Key 创建和删除；
• 应用发布行为；
• 知识库上传、删除、重建索引；
• 工作流修改；
• 模型供应商配置变更；
• 异常高频 API 调用；
• 大量失败登录尝试。

如果企业有日志平台，可以将日志接入：

• ELK；
• Loki + Grafana；
• Splunk；
• 阿里云 SLS；
• 腾讯云 CLS；
• 华为云 LTS。

十三、Fail2ban 防暴力破解

可以使用 Fail2ban 监控 Nginx 日志，对异常访问进行封禁。

安装：

sudo apt install -y fail2ban

创建规则：

sudo vim /etc/fail2ban/filter.d/dify-nginx.conf

内容：

[Definition]
failregex = ^ .* "(GET|POST).*" (401|403|404|429) .*
ignoreregex =

创建 jail：

sudo vim /etc/fail2ban/jail.d/dify-nginx.local

内容：

[dify-nginx]
enabled = true
filter = dify-nginx
logpath = /var/log/nginx/dify_access.log
maxretry = 30
findtime = 300
bantime = 3600

重启：

sudo systemctl restart fail2ban
sudo fail2ban-client status dify-nginx

十四、敏感信息保护

Dify 中常见敏感信息包括：

• 模型供应商 API Key；
• 数据库密码；
• Redis 密码；
• 知识库文档；
• 工作流中的业务接口地址；
• 插件配置；
• 用户会话信息；
• 应用 API Key。

安全建议：

1. 不要把 .env 提交到 Git 仓库

   .gitignore 示例：

   .env
   *.key
   *.pem
   backups/
   logs/

2. 密钥分环境管理

   • 开发、测试、生产环境使用不同 Key；
   • 生产 Key 不允许在本地开发机使用。

3. 定期轮换 Key

   • 例如每 90 天轮换一次；
   • 发现泄露后立即吊销。

4. 最小权限原则

   • 不同应用使用不同模型 Key；
   • 能限制额度的供应商应设置预算上限。

5. 避免在提示词中写入敏感密钥

   • Prompt 中不要写数据库密码、API Token、内部鉴权信息。

十五、Sandbox 安全注意事项

Dify 中的 Sandbox 通常用于执行代码或工具调用相关能力。该模块一定要重点关注，因为代码执行类能力天然风险较高。

建议：

1. Sandbox 容器不映射公网端口；
2. 禁止特权模式；
3. 禁止挂载宿主机敏感目录；
4. 设置 CPU、内存、进程数限制；
5. 禁止访问 Docker Socket；
6. 如无必要，不允许访问内网敏感网段；
7. 定期更新 Sandbox 镜像；
8. 对工作流中的代码节点进行权限审查。

危险配置示例：

volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  - /:/host
privileged: true

以上配置应避免使用。

十六、供应链与镜像安全

1. 固定镜像版本

不要长期使用 latest 标签。推荐固定版本：

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

这样可以避免因为上游镜像自动变化导致不可控问题。

2. 镜像漏洞扫描

可以使用 Trivy 扫描镜像：

sudo apt install -y wget apt-transport-https gnupg lsb-release

wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo gpg --dearmor -o /usr/share/keyrings/trivy.gpg

echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/trivy.list

sudo apt update
sudo apt install -y trivy

扫描镜像：

trivy image langgenius/dify-api:latest

扫描本地文件系统：

trivy fs /opt/dify

3. 定期更新

建议每月至少检查一次：

docker compose pull
docker compose up -d
docker image prune -f

更新前应先备份数据库和配置文件。

十七、一键安全巡检脚本源码

下面提供一个简单的 Dify 安全巡检脚本，可检查防火墙、Docker 容器、敏感端口、.env 权限、磁盘空间等。

保存为：

/opt/scripts/dify_security_check.sh

源码如下：

#!/usr/bin/env bash

set -e

DIFY_DIR="/opt/dify"
ENV_FILE="$DIFY_DIR/.env"

echo "=============================="
echo " Dify Security Check"
echo "=============================="
echo ""

echo "[1] Check current user"
whoami
echo ""

echo "[2] Check UFW status"
if command -v ufw >/dev/null 2>&1; then
    sudo ufw status verbose
else
    echo "ufw not installed"
fi
echo ""

echo "[3] Check listening ports"
sudo ss -tulnp
echo ""

echo "[4] Check Docker containers"
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}\t{{.Status}}"
echo ""

echo "[5] Check .env permission"
if [ -f "$ENV_FILE" ]; then
    ls -l "$ENV_FILE"
    PERM=$(stat -c "%a" "$ENV_FILE")
    if [ "$PERM" != "600" ]; then
        echo "WARNING: .env permission is $PERM, recommended: 600"
    else
        echo ".env permission OK"
    fi
else
    echo ".env not found: $ENV_FILE"
fi
echo ""

echo "[6] Check exposed dangerous ports"
DANGEROUS_PORTS=("5432" "6379" "6333" "19530" "8080")
for PORT in "${DANGEROUS_PORTS[@]}"; do
    if sudo ss -tulnp | grep -q ":$PORT "; then
        echo "WARNING: Port $PORT is listening. Please confirm it is not exposed to public network."
    fi
done
echo ""

echo "[7] Check disk usage"
df -h
echo ""

echo "[8] Check memory usage"
free -h
echo ""

echo "[9] Check recent docker logs errors"
docker ps --format "{{.Names}}" | while read -r cname; do
    echo "---- $cname ----"
    docker logs --since 1h "$cname" 2>&1 | grep -iE "error|fail|exception|traceback" | tail -20 || true
done

echo ""
echo "Security check completed."

赋予权限：

chmod +x /opt/scripts/dify_security_check.sh

执行：

sudo /opt/scripts/dify_security_check.sh

十八、安全上线检查清单

上线前建议逐项确认：

• [ ] 已启用 HTTPS；
• [ ] HTTP 自动跳转 HTTPS；
• [ ] Dify 后台没有裸露公网，或已配置 IP 白名单 / VPN / Basic Auth；
• [ ] .env 权限为 600；
• [ ] SECRET_KEY 已替换为强随机值；
• [ ] 数据库密码、Redis 密码均为强密码；
• [ ] PostgreSQL 未暴露公网；
• [ ] Redis 未暴露公网；
• [ ] 向量数据库未暴露公网；
• [ ] 已关闭用户自助注册；
• [ ] 管理员账号使用强密码；
• [ ] 不同应用使用独立 API Key；
• [ ] 已配置 Nginx 限流；
• [ ] 已配置定期备份；
• [ ] 备份文件已加密；
• [ ] 已测试备份恢复；
• [ ] 容器未使用 privileged: true；
• [ ] 未挂载 Docker Socket；
• [ ] 已配置日志留存；
• [ ] 已安装 Fail2ban 或其他防护；
• [ ] 已制定密钥轮换机制；
• [ ] 已固定 Docker 镜像版本；
• [ ] 已完成镜像漏洞扫描。

十九、应急处理建议

如果怀疑 Dify 被入侵或密钥泄露，应立即执行以下操作：

1. 临时关闭公网访问

sudo ufw deny 443/tcp

或停掉 Nginx：

sudo systemctl stop nginx

2. 吊销模型供应商 API Key

登录对应供应商控制台，立即删除可疑 Key。

3. 修改 Dify 管理员密码

禁用异常账号，排查新增用户。

4. 轮换 .env 中所有密钥

包括：

• SECRET_KEY；
• 数据库密码；
• Redis 密码；
• 模型供应商 Key；
• 应用 API Key。

5. 导出日志分析

cp /var/log/nginx/dify_access.log /opt/incident/
cp /var/log/nginx/dify_error.log /opt/incident/
docker compose logs > /opt/incident/dify_docker_logs.txt

6. 检查异常容器和进程

docker ps -a
ps aux
sudo ss -tulnp

7. 从可信备份恢复

如果确认数据被篡改，应从最近的可信备份恢复。

二十、总结

Dify 的安全加固并不是单点配置，而是一套完整的体系。对于个人测试环境，可能只需要 HTTPS、强密码、关闭数据库公网端口；但对于企业生产环境，必须进一步考虑网络隔离、身份认证、访问审计、API 限流、容器最小权限、备份加密、密钥轮换和供应链安全。

推荐的最低安全基线是：

1. Dify 必须使用 HTTPS；
2. 后台不直接裸露公网；
3. 数据库、Redis、向量库不暴露公网；
4. 关闭开放注册；
5. 使用强随机密钥和强密码；
6. 对 API 做限流和来源控制；
7. 定期备份并测试恢复；
8. 容器禁止特权模式；
9. 日志可追溯；
10. 上线前执行安全检查清单。

如果 Dify 承载企业知识库、客户数据或内部业务接口，建议将其纳入企业整体安全治理体系，与堡垒机、VPN、WAF、日志平台、漏洞扫描、密钥管理平台配合使用。只有这样，Dify 才能从“能用”走向“可控、可审计、可恢复、可长期运营”。