Dify 私有化部署安全加固实战：从 HTTPS、容器隔离到备份恢复配置指南

发布人：慈云数据-客服中心发布时间：3小时前阅读量：3

Dify 安全加固方案｜附配置文件

Dify 是一款开源的 LLMOps 平台，常用于构建 AI 应用、知识库问答、工作流编排以及智能体系统。由于 Dify 往往需要接入大模型 API、向量数据库、对象存储、数据库、Redis 等多个基础组件，一旦暴露在公网环境中，如果缺少必要的安全加固，可能会面临账号暴力破解、密钥泄露、接口滥用、容器逃逸、数据库未授权访问、供应链风险等问题。

本文将从部署架构、网络访问、反向代理、HTTPS、认证授权、密钥管理、容器安全、数据库安全、日志审计、备份恢复、监控告警等多个角度，给出一套相对完整的 Dify 安全加固方案，并附上可直接参考的配置文件。

说明：本文以 Docker Compose 部署方式为例，适用于中小规模私有化部署场景。生产环境中仍建议结合企业现有的云安全、堡垒机、WAF、零信任网关、Kubernetes 安全策略等能力进一步增强。

一、Dify 部署安全目标

在正式加固之前，首先需要明确 Dify 平台的安全目标。一个较为合理的安全目标应包括：

仅开放必要端口
- 公网仅开放 80/443；
- PostgreSQL、Redis、向量数据库、Sandbox 等组件不得直接暴露公网。
强制使用 HTTPS
- 所有 Web 控制台和 API 请求必须通过 TLS 加密；
- 禁止明文 HTTP 访问。
限制管理入口
- Dify 管理后台尽量只允许办公网、VPN 或零信任网关访问；
- 避免管理后台直接暴露给整个互联网。
保护敏感密钥
- OpenAI Key、Claude Key、Embedding API Key、数据库密码、JWT Secret 等必须妥善存储；
- 避免写入 Git 仓库。
容器最小权限运行
- 禁止不必要的特权容器；
- 限制容器能力、文件系统写入权限、资源使用上限。
具备审计和追踪能力
- 保存访问日志、错误日志、应用日志；
- 对登录失败、接口异常调用、服务异常重启等行为进行告警。
可恢复
- 定期备份数据库、对象存储、向量数据库和关键配置；
- 定期验证备份可用性。

二、推荐安全部署架构

生产环境建议采用如下结构：

Internet
   |
   | 443/HTTPS
   v
[WAF / CDN / SLB]
   |
   v
[Nginx Reverse Proxy]
   |
   | internal docker network
   v
[Dify Web / API / Worker]
   |
   +--> PostgreSQL
   +--> Redis
   +--> Vector Database
   +--> Object Storage
   +--> Sandbox

核心原则：

Nginx 是唯一直接面对公网的入口；
Dify API、Web、Worker、PostgreSQL、Redis、向量数据库全部在内网网络中；
数据库不映射公网端口；
如果使用云数据库，应限制来源 IP；
如果使用对象存储，应启用私有 Bucket 和最小权限访问策略；
如有条件，在 Nginx 前增加 WAF 或 CDN，缓解恶意扫描与 CC 攻击。

三、操作系统基础加固

以下示例以 Ubuntu Server 为例。

1. 创建普通运维用户

不要直接使用 root 长期登录服务器。

adduser deploy
usermod -aG sudo deploy

修改 SSH 配置：

sudo vim /etc/ssh/sshd_config

建议配置如下：

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

重启 SSH：

sudo systemctl restart ssh

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

2. 配置防火墙

使用 UFW 限制入站访问：

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow 22222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

如果 Dify 管理入口只允许固定办公 IP 访问，可以进一步限制：

sudo ufw allow from 203.0.113.10 to any port 443 proto tcp

但这通常需要结合 Nginx 层路径限制或独立管理域名来实现更细粒度控制。

四、Docker Compose 安全加固

很多默认 Docker Compose 配置为了方便调试，会将 PostgreSQL、Redis、Weaviate、Qdrant 等组件端口映射到宿主机。生产环境中应避免这种做法。

下面给出一个安全化的 docker-compose.override.yml 示例。

`docker-compose.override.yml`

version: "3.8"

services:
  api:
    restart: unless-stopped
    networks:
      - dify_internal
    expose:
      - "5001"
    ports: []
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: false
    tmpfs:
      - /tmp:size=256m,noexec,nosuid,nodev
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

  web:
    restart: unless-stopped
    networks:
      - dify_internal
    expose:
      - "3000"
    ports: []
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "5"

  worker:
    restart: unless-stopped
    networks:
      - dify_internal
    ports: []
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

  db:
    restart: unless-stopped
    networks:
      - dify_internal
    ports: []
    expose:
      - "5432"
    security_opt:
      - no-new-privileges:true
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

  redis:
    restart: unless-stopped
    networks:
      - dify_internal
    ports: []
    expose:
      - "6379"
    command: redis-server --requirepass ${REDIS_PASSWORD} --appendonly yes
    security_opt:
      - no-new-privileges:true
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

  nginx:
    restart: unless-stopped
    networks:
      - dify_internal
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - api
      - web
    security_opt:
      - no-new-privileges:true
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

networks:
  dify_internal:
    driver: bridge
    internal: false

加固说明

ports: []：避免业务容器直接将端口映射到宿主机；
expose：仅允许容器网络内部访问；
no-new-privileges:true：防止进程获取额外权限；
cap_drop: ALL：移除 Linux capabilities，减少攻击面；
logging：限制日志大小，防止磁盘被打满；
Redis 增加密码；
所有服务通过内部网络通信。

注意：部分服务在极端场景下可能需要特定 capability 或写入权限，实际配置应结合 Dify 官方版本进行验证，避免因过度限制导致服务不可用。

五、环境变量安全配置

Dify 的 .env 文件中包含大量敏感信息，例如数据库密码、Redis 密码、SECRET_KEY、大模型供应商密钥等。生产环境应保证 .env 文件权限严格。

`.env` 示例

# 基础环境
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

# 强随机密钥，建议使用 openssl rand -base64 42 生成
SECRET_KEY=replace_with_a_strong_random_secret

# 数据库配置
DB_USERNAME=dify
DB_PASSWORD=replace_with_strong_db_password
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify

# Redis 配置
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=replace_with_strong_redis_password
REDIS_DB=0

# Cookie 安全
COOKIE_SECURE=true
COOKIE_HTTPONLY=true
COOKIE_SAMESITE=Lax

# 文件上传限制
UPLOAD_FILE_SIZE_LIMIT=15
UPLOAD_FILE_BATCH_LIMIT=5

# 推荐关闭调试
DEBUG=false
FLASK_DEBUG=false

# 日志等级
LOG_LEVEL=INFO

# 向量数据库示例
VECTOR_STORE=qdrant
QDRANT_URL=http://qdrant:6333
QDRANT_API_KEY=replace_with_qdrant_api_key

# Sandbox
CODE_EXECUTION_ENDPOINT=http://sandbox:8194
CODE_EXECUTION_API_KEY=replace_with_sandbox_api_key

文件权限设置

sudo chown root:docker .env
sudo chmod 640 .env

密钥生成命令

openssl rand -base64 42

建议至少为以下项目使用强随机值：

SECRET_KEY
DB_PASSWORD
REDIS_PASSWORD
QDRANT_API_KEY
CODE_EXECUTION_API_KEY
对象存储 Access Key / Secret Key
大模型供应商 API Key

不要将 .env 提交到 Git 仓库。应在 .gitignore 中加入：

.env
.env.*
*.pem
*.key
backup/

六、Nginx 反向代理安全配置

Dify 默认包含 Nginx，也可以在外部再部署一层 Nginx。生产环境建议统一由 Nginx 处理 HTTPS、限流、安全头、访问日志等。

下面是一份可参考的 Nginx 配置。

`/etc/nginx/conf.d/dify.conf`

limit_req_zone $binary_remote_addr zone=dify_api_limit:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=dify_login_limit:10m rate=3r/m;
limit_conn_zone $binary_remote_addr zone=dify_conn_limit:10m;

server {
    listen 80;
    server_name dify.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        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 off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    client_max_body_size 20m;

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

    # 安全响应头
    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;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

    # 基础连接限制
    limit_conn dify_conn_limit 30;

    # 禁止访问隐藏文件
    location ~ /\.(?!well-known) {
        deny all;
    }

    # 登录接口限流，路径需根据实际版本确认
    location ~* ^/(console/api/login|console/api/account/login) {
        limit_req zone=dify_login_limit burst=5 nodelay;

        proxy_pass http://127.0.0.1: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;
    }

    # API 限流
    location /api/ {
        limit_req zone=dify_api_limit burst=30 nodelay;

        proxy_pass http://127.0.0.1:5001;
        proxy_http_version 1.1;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;

        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;
    }

    # 控制台 API
    location /console/api/ {
        limit_req zone=dify_api_limit burst=30 nodelay;

        proxy_pass http://127.0.0.1:5001;
        proxy_http_version 1.1;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;

        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;
    }

    # Web 前端
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        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;
    }
}

如果 Nginx 与 Dify 在同一个 Docker 网络内，可以将 proxy_pass 改成容器服务名：

proxy_pass http://api:5001;
proxy_pass http://web:3000;

七、HTTPS 证书配置

推荐使用 Let's Encrypt 免费证书。

安装 Certbot：

sudo apt update
sudo apt install -y certbot python3-certbot-nginx

申请证书：

sudo certbot --nginx -d dify.example.com

查看自动续期：

sudo systemctl list-timers | grep certbot

测试续期：

sudo certbot renew --dry-run

生产环境中必须保证：

禁止长期使用自签名证书；
TLS 证书自动续期正常；
过期证书需要提前告警；
不要将私钥文件复制到不可信环境。

八、管理后台访问控制

如果 Dify 管理后台用于内部应用管理，不建议完全暴露公网。可以使用以下几种方式加固。

方案一：Nginx IP 白名单

location /console {
    allow 203.0.113.10;
    allow 198.51.100.0/24;
    deny all;

    proxy_pass http://127.0.0.1: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;
}

方案二：Basic Auth 二次认证

安装工具：

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.dify_htpasswd admin

Nginx 配置：

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

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

方案三：接入零信任网关

更推荐的方式是将 Dify 管理后台放到企业零信任网关后面，例如：

Cloudflare Access；
Tailscale；
Teleport；
企业自建 SSO 网关；
VPN + 内网域名访问。

这样可以将身份认证前置到 Dify 之前，即使 Dify 本身存在弱密码或未修复漏洞，也能增加一层防护。

九、Dify 账号与权限策略

Dify 自身也需要进行账号安全管理。

建议：

禁用共享管理员账号
- 每位管理员使用独立账号；
- 账号离职后及时禁用。
启用强密码策略
- 密码不少于 12 位；
- 包含大小写字母、数字和特殊字符；
- 禁止使用公司名、项目名、手机号等弱口令。
最小权限原则
- 普通应用开发者不应拥有全局管理员权限；
- 仅给必要成员授权对应 Workspace。
定期清理成员
- 每月检查一次 Workspace 成员；
- 删除无业务需要的账号。
API Key 分应用管理
- 每个应用使用独立 Key；
- 不要多个系统共用一个 API Key；
- 发现泄露后立即轮换。
限制公开应用
- 对外公开的聊天应用要增加访问控制；
- 避免内部知识库被无意公开。

十、Redis 安全加固

Redis 如果被公网访问，风险非常高。生产环境中 Redis 必须满足：

不映射公网端口；
启用密码；
禁止危险命令；
开启持久化；
限制最大内存。

`redis.conf` 示例

bind 0.0.0.0
protected-mode yes
port 6379

requirepass replace_with_strong_redis_password

appendonly yes
appendfsync everysec

maxmemory 1gb
maxmemory-policy allkeys-lru

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

如果 Redis 只在容器网络内部使用，bind 0.0.0.0 可以接受，但前提是宿主机没有映射 6379 到公网。如果是物理机或云主机直接部署，建议绑定内网地址：

bind 127.0.0.1 10.0.0.5

十一、PostgreSQL 安全加固

PostgreSQL 是 Dify 的核心数据存储，必须重点保护。

1. 不开放公网端口

Docker Compose 中不要写：

ports:
  - "5432:5432"

应使用：

expose:
  - "5432"

2. 强密码与独立账号

不要使用默认密码，不要与其他系统共用数据库账号。

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

3. 限制连接来源

pg_hba.conf 示例：

# TYPE  DATABASE  USER  ADDRESS        METHOD
local   all       all                  scram-sha-256
host    dify      dify  172.18.0.0/16  scram-sha-256
host    all       all   0.0.0.0/0      reject

4. 开启日志审计

postgresql.conf 示例：

listen_addresses = '*'
password_encryption = scram-sha-256

log_connections = on
log_disconnections = on
log_min_duration_statement = 1000
log_line_prefix = '%m [%p] %u@%d %r '

这样可以记录慢 SQL 和连接信息，便于排查异常访问。

十二、Sandbox 安全加固

Dify 的代码执行 Sandbox 是高风险组件，因为它可能执行由用户输入触发的代码逻辑。生产环境中必须特别谨慎。

建议：

Sandbox 不要暴露公网
- 仅允许 Dify API 服务访问；
- 不映射宿主机端口。
使用强 API Key
- CODE_EXECUTION_API_KEY 必须使用强随机值；
- 定期轮换。
限制资源
- 限制 CPU、内存、进程数；
- 防止恶意代码导致宿主机资源耗尽。

Compose 资源限制示例

services:
  sandbox:
    restart: unless-stopped
    expose:
      - "8194"
    ports: []
    environment:
      API_KEY: ${CODE_EXECUTION_API_KEY}
    security_opt:
      - no-new-privileges:true
    pids_limit: 256
    mem_limit: 1g
    cpus: "1.0"
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

如果业务不需要代码执行能力，建议关闭 Sandbox 相关功能或限制仅管理员可使用。

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

Dify 通常会处理知识库文档、用户上传文件、图片等内容。文件上传是常见攻击面。

建议：

限制上传大小
- 避免超大文件导致磁盘或对象存储成本失控；
- 示例中已经设置 UPLOAD_FILE_SIZE_LIMIT=15。
限制文件类型
- 仅允许业务需要的格式；
- 对可执行文件、脚本文件、HTML 文件谨慎处理。
私有 Bucket
- 不要将对象存储 Bucket 设置为公共读写；
- 通过签名 URL 或后端代理访问。
对象存储账号最小权限
- 只允许访问 Dify 所需 Bucket；
- 不要使用云账号主密钥。
病毒扫描
- 对企业内部知识库文件，建议接入杀毒扫描流程；
- 尤其是来自外部用户上传的文件。

十四、Fail2ban 防暴力破解

可以通过 Fail2ban 对 Nginx 日志进行分析，阻止频繁登录失败或异常请求的 IP。

安装 Fail2ban

sudo apt install -y fail2ban

`/etc/fail2ban/jail.d/dify.conf`

[dify-nginx-4xx]
enabled = true
port = http,https
filter = dify-nginx-4xx
logpath = /var/log/nginx/dify_access.log
maxretry = 50
findtime = 300
bantime = 3600
action = iptables-multiport[name=dify-nginx-4xx, port="http,https"]

[dify-login]
enabled = true
port = http,https
filter = dify-login
logpath = /var/log/nginx/dify_access.log
maxretry = 8
findtime = 300
bantime = 7200
action = iptables-multiport[name=dify-login, port="http,https"]

`/etc/fail2ban/filter.d/dify-nginx-4xx.conf`

[Definition]
failregex = ^ - .* "(GET|POST|PUT|DELETE|PATCH) .*" (401|403|404) .*
ignoreregex =

`/etc/fail2ban/filter.d/dify-login.conf`

[Definition]
failregex = ^ - .* "POST /(console/api/login|console/api/account/login).*" (401|403) .*
ignoreregex =

重启服务：

sudo systemctl restart fail2ban
sudo fail2ban-client status

十五、日志审计与监控告警

安全加固不只是“拦截攻击”，还需要能够及时发现异常。

建议采集以下日志：

Nginx access log；
Nginx error log；
Dify API 日志；
Worker 日志；
PostgreSQL 日志；
Redis 日志；
Docker 容器重启事件；
系统登录日志 /var/log/auth.log。

可以使用以下组合：

Prometheus + Grafana；
Loki + Promtail + Grafana；
ELK / OpenSearch；
云厂商日志服务；
Datadog / New Relic。

重点告警指标

建议配置以下告警：

5xx 错误率过高；
登录失败次数异常；
单 IP 请求量异常；
API Token 调用量突然增长；
PostgreSQL 连接数过高；
Redis 内存使用率过高；
Docker 容器频繁重启；
磁盘使用率超过 80%；
TLS 证书即将过期；
备份任务失败。

十六、备份与恢复方案

Dify 的关键数据通常包括：

PostgreSQL 数据库；
向量数据库数据；
对象存储文件；
.env 配置；
Nginx 配置；
自定义插件或扩展配置。

PostgreSQL 备份脚本

创建脚本：

sudo vim /opt/backup/backup_dify_postgres.sh

内容如下：

#!/bin/bash

set -e

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

mkdir -p ${BACKUP_DIR}

docker exec ${CONTAINER_NAME} pg_dump -U ${DB_USER} ${DB_NAME} | gzip > ${BACKUP_DIR}/dify_${DATE}.sql.gz

find ${BACKUP_DIR} -type f -name "*.sql.gz" -mtime +14 -delete

赋予执行权限：

sudo chmod +x /opt/backup/backup_dify_postgres.sh

配置定时任务：

sudo crontab -e

添加：

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

恢复示例

gunzip -c dify_20250101_020000.sql.gz | docker exec -i docker-db-1 psql -U dify -d dify

备份不是目的，能恢复才是目的。建议每月至少进行一次恢复演练。

十七、升级与漏洞管理

Dify 迭代速度较快，依赖组件也较多，应建立稳定的升级策略。

建议：

关注官方 Release
- 定期查看 Dify GitHub Release；
- 关注安全修复说明。
升级前备份
- 备份数据库；
- 备份 .env；
- 备份 Compose 文件和 Nginx 配置。
先测试后生产
- 在测试环境验证升级；
- 确认知识库、工作流、API 调用正常。
镜像版本固定
- 不建议生产环境使用 latest；
- 应固定到明确版本号。

示例：

services:
  api:
    image: langgenius/dify-api:0.15.3
  web:
    image: langgenius/dify-web:0.15.3

定期扫描镜像
- 可使用 Trivy 扫描容器镜像：

trivy image langgenius/dify-api:0.15.3

十八、生产环境安全检查清单

上线前建议逐项检查：

[ ] 公网仅开放 80/443/SSH 管理端口；
[ ] SSH 禁止 root 登录；
[ ] SSH 禁止密码登录；
[ ] HTTPS 已启用；
[ ] TLS 证书自动续期正常；
[ ] PostgreSQL 未暴露公网；
[ ] Redis 未暴露公网；
[ ] Redis 已设置强密码；
[ ] .env 未提交 Git；
[ ] .env 权限为 640 或更严格；
[ ] SECRET_KEY 为强随机值；
[ ] Dify 管理员使用强密码；
[ ] 管理后台已加 IP 白名单或零信任访问；
[ ] Nginx 已配置限流；
[ ] Nginx 已配置安全响应头；
[ ] Docker 容器启用日志轮转；
[ ] Sandbox 未暴露公网；
[ ] 文件上传大小已限制；
[ ] 已配置数据库定期备份；
[ ] 已验证备份恢复流程；
[ ] 已配置基础监控告警；
[ ] 镜像版本已固定；
[ ] 已建立升级与回滚流程。

十九、总结

Dify 作为 AI 应用开发平台，安全风险并不只来自传统 Web 攻击，还包括模型 API Key 泄露、Prompt 注入、知识库数据外泄、工作流误配置、Sandbox 执行风险、API 滥用等新型问题。因此，生产环境部署 Dify 时，不能只关注“能不能跑起来”，更要关注“是否安全、是否可控、是否可恢复”。

一套较为稳妥的 Dify 安全加固方案应至少做到：