SKILL Sécurité et Déploiement Dify

Aperçu

Ce SKILL fournit un guide complet sur les bonnes pratiques de sécurité et l'exploitation de la plateforme Dify, aidant les développeurs et les opérateurs à construire un environnement de production sécurisé, stable et performant.

Scénarios d'utilisation

Utilisez ce SKILL lorsque vous avez besoin de :

🚀 Déployer Dify en production (Docker/Kubernetes)
🔒 Configurer des mécanismes de protection (SSRF, bac à sable, chiffrement)
🔧 Résoudre des problèmes de déploiement (échec de démarrage des conteneurs, configuration réseau, goulots d'étranglement de performance)
📊 Optimiser l'environnement de production (surveillance, alertes, haute disponibilité, reprise après incident)
✅ Effectuer un audit de sécurité et une validation de configuration

Capacités principales

Protection de sécurité : Protection SSRF, bac à sable pour le code, chiffrement des données, gestion des autorisations
Déploiement Docker : Déploiement rapide, configuration de production, architecture réseau, optimisation des ressources
Déploiement Kubernetes : Architecture haute disponibilité, mise à l'échelle automatique, déploiement Helm
Surveillance et alertes : OpenTelemetry, Sentry, agrégation de logs, surveillance des performances
Reprise après incident : Diagnostic des problèmes, processus de restauration, stratégies de sauvegarde

Démarrage rapide

Configuration de déploiement minimale

# 1. Cloner le dépôt
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 2. Copier les variables d'environnement
cp .env.example .env

# 3. Modifier les configurations de sécurité clés
# Modifier le fichier .env :
SECRET_KEY=$(openssl rand -base64 42)
DB_PASSWORD=votre-mot-de-passe-fort
REDIS_PASSWORD=votre-mot-de-passe-redis
SANDBOX_API_KEY=$(openssl rand -base64 32)

# 4. Démarrer les services
docker compose up -d

# 5. Vérifier le déploiement
docker compose ps
curl http://localhost/health

Checklist de sécurité

Vérifications avant déploiement

SECRET_KEY a été remplacée par une clé forte (utiliser openssl rand -base64 42)
Mot de passe de la base de données a été modifié par rapport à la valeur par défaut
Mot de passe Redis a été défini
Proxy SSRF a été configuré pour bloquer les accès au réseau interne
Bac à sable (Sandbox) a été activé avec un proxy réseau
Certificat HTTPS/TLS a été configuré (environnement de production)
Mécanisme de gestion des clés API a été activé
Limite de taille des fichiers téléchargés a été définie (UPLOAD_FILE_SIZE_LIMIT)
Variables d'environnement sensibles sont stockées de manière chiffrée

Vérifications en cours d'exécution

Permissions des conteneurs : exécution avec un utilisateur non-root
Isolement réseau : le réseau ssrf_proxy_network fonctionne correctement
Vérifications de santé : tous les services sont en bonne santé
Journalisation : activée et produisant des sorties normales
Surveillance et alertes : configurées (OpenTelemetry/Sentry)
Stratégie de sauvegarde : mise en œuvre (base de données, stockage de fichiers)
Limites de ressources : limites CPU/mémoire configurées
Certificat SSL : vérification de validité et renouvellement automatique

Structure des répertoires

04-security/
├── SKILL.md                    # Ce fichier - Vue d'ensemble de la sécurité et du déploiement
├── security/                   # Bonnes pratiques de sécurité
│   ├── ssrf-protection.md     # Configuration de la protection SSRF
│   ├── sandbox.md             # Isolation du code via bac à sable
│   ├── encryption.md          # Chiffrement des données et TLS
│   └── auth.md                # Authentification et gestion des autorisations
├── deployment/                 # Guides de déploiement
│   ├── docker-compose.md      # Déploiement Docker Compose
│   ├── kubernetes.md          # Déploiement Kubernetes
│   ├── serverless.md          # Déploiement Serverless
│   └── high-availability.md   # Architecture haute disponibilité
├── operations/                 # Pratiques d'exploitation
│   ├── monitoring.md          # Surveillance et alertes
│   ├── logging.md             # Gestion des logs
│   ├── backup.md              # Sauvegarde et restauration
│   └── troubleshooting.md     # Dépannage
└── best-practices.md           # Résumé des bonnes pratiques

1. Mécanismes de protection de sécurité

1.1 Protection SSRF

Dify utilise un proxy Squid pour implémenter la protection SSRF (Server-Side Request Forgery), empêchant l'accès aux adresses internes.

Configuration principale :

# squid.conf - Liste noire des adresses internes
acl localnet src 10.0.0.0/8
acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16
acl localnet src 127.0.0.0/8

# Refuser l'accès au réseau interne
http_access deny localnet

# Ports autorisés
acl Safe_ports port 80 443 1025-65535
http_access deny !Safe_ports

Méthode de vérification :

# Tester que l'accès au réseau interne est bloqué
docker compose exec api curl -x http://ssrf_proxy:3128 http://127.0.0.1
# Doit retourner 403 Forbidden

# Tester que l'accès externe fonctionne
docker compose exec api curl -x http://ssrf_proxy:3128 https://api.openai.com
# Doit retourner une réponse normale

📖 Documentation détaillée : security/ssrf-protection.md

1.2 Bac à sable pour le code

Le service Sandbox fournit un environnement d'exécution de code sécurisé, isolant le code utilisateur.

Configuration principale :

# config.yaml
app:
  key: dify-sandbox  # Modifier avec une clé forte
max_workers: 4
worker_timeout: 15
enable_network: true  # Accès externe via le proxy SSRF
proxy:
  http: 'http://ssrf_proxy:3128'
  https: 'http://ssrf_proxy:3128'

Caractéristiques de sécurité :

✅ Liste blanche des appels système limitée
✅ Gestion des quotas de ressources (CPU, mémoire, timeout)
✅ Accès réseau via le proxy SSRF
✅ Isolation du système de fichiers

📖 Documentation détaillée : security/sandbox.md

1.3 Chiffrement des données

Chiffrement en transit (TLS/HTTPS) :

# Configuration .env
NGINX_HTTPS_ENABLED=true
NGINX_SSL_CERT_FILENAME=fullchain.pem
NGINX_SSL_CERT_KEY_FILENAME=privkey.pem
NGINX_SSL_PROTOCOLS=TLSv1.2 TLSv1.3

Chiffrement des connexions à la base de données :

# SSL PostgreSQL
DB_HOST=db_postgres
POSTGRES_SSL_MODE=require

# SSL Redis
REDIS_USE_SSL=true
REDIS_SSL_CERT_REQS=CERT_REQUIRED

📖 Documentation détaillée : security/encryption.md

1.4 Gestion des autorisations

Gestion des clés API :

# Générer des clés fortes
SECRET_KEY=$(openssl rand -base64 42)
PLUGIN_DAEMON_KEY=$(openssl rand -base64 42)
PLUGIN_DIFY_INNER_API_KEY=$(openssl rand -base64 42)

Intégration OAuth 2.0 :

Prise en charge de l'autorisation de services tiers
Rafraîchissement automatique des jetons d'accès
Contrôle des périmètres d'autorisation

📖 Documentation détaillée : security/auth.md

2. Déploiement Docker

2.1 Déploiement rapide

Démarrage en une commande :

cd dify/docker
cp .env.example .env
# Modifier les mots de passe et les clés dans .env
docker compose up -d

Architecture des services :

nginx (80/443)
  ├── web (3000) - Interface utilisateur
  ├── api (5001) - Logique métier
  ├── worker - Tâches en arrière-plan
  ├── beat - Tâches planifiées
  ├── plugin_daemon (5002) - Gestion des plugins
  └── sandbox (8194) - Exécution de code

Services de base :
  ├── db_postgres (5432) - Base de données principale
  ├── redis (6379) - Cache et files d'attente
  ├── weaviate (8080) - Base de données vectorielle
  └── ssrf_proxy (3128) - Protection SSRF

📖 Documentation détaillée : deployment/docker-compose.md

2.2 Configuration de production

Limitation des ressources :

# docker-compose.yaml
services:
  api:
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 4G
        reservations:
          cpus: '1'
          memory: 2G

Vérifications de santé :

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:5001/health"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

Gestion des logs :

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

📖 Documentation détaillée : deployment/docker-compose.md

2.3 Architecture réseau

Isolement réseau :

networks:
  # Réseau interne - impossible d'accéder à l'extérieur
  ssrf_proxy_network:
    driver: bridge
    internal: true

  # Réseau par défaut - accès externe possible
  default:
    driver: bridge

Communication entre services :

API/Worker/Sandbox → ssrf_proxy → API externes
Nginx → API/Web (proxy inverse)
API → Database/Redis (communication interne)

📖 Documentation détaillée : deployment/docker-compose.md

3. Déploiement Kubernetes

3.1 Déploiement rapide avec Helm

# Ajouter le dépôt Helm
helm repo add dify https://borispolonsky.github.io/dify-helm
helm repo update

# Installer Dify
helm install my-dify dify/dify \
  --set postgresql.enabled=true \
  --set redis.enabled=true \
  --set weaviate.enabled=true

# Voir l'état
kubectl get pods -l app.kubernetes.io/name=dify

3.2 Architecture haute disponibilité

Déploiement multi-réplicas :

# values.yaml
api:
  replicaCount: 3
  resources:
    limits:
      cpu: 2000m
      memory: 4Gi
    requests:
      cpu: 1000m
      memory: 2Gi

worker:
  replicaCount: 2
  autoscaling:
    enabled: true
    minReplicas: 2
    maxReplicas: 10
    targetCPUUtilizationPercentage: 80

Anti-affinité des Pods :

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - dify-api
        topologyKey: kubernetes.io/hostname

📖 Documentation détaillée : deployment/kubernetes.md

3.3 Intégration de services managés

Utilisation des services managés des fournisseurs cloud :

# Utiliser RDS PostgreSQL
postgresql:
  enabled: false
externalDatabase:
  host: votre-endpoint-rds.rds.amazonaws.com
  port: 5432
  database: dify
  username: dify
  password: votre-mot-de-passe

# Utiliser ElastiCache Redis
redis:
  enabled: false
externalRedis:
  host: votre-redis.cache.amazonaws.com
  port: 6379
  password: votre-mot-de-passe

Avantages :

✅ Sauvegarde et restauration automatiques
✅ Haute disponibilité et basculement
✅ Surveillance et optimisation des performances
✅ Réduction de la charge d'exploitation

📖 Documentation détaillée : deployment/high-availability.md

4. Surveillance et alertes

4.1 Configuration OpenTelemetry

# .env
ENABLE_OTEL=true
OTLP_BASE_ENDPOINT=http://otel-collector:4318
OTEL_SAMPLING_RATE=0.1
OTEL_BATCH_EXPORT_SCHEDULE_DELAY=5000
OTEL_MAX_QUEUE_SIZE=2048
OTEL_METRIC_EXPORT_INTERVAL=60000

Indicateurs de surveillance :

Latence et débit des requêtes
Taux d'erreur et de succès
Utilisation des ressources (CPU, mémoire, disque)
État du pool de connexions à la base de données
Profondeur et vitesse de traitement des files d'attente

4.2 Suivi des erreurs avec Sentry

# .env
API_SENTRY_DSN=https://votre-cl@ sentry.io/project-id
API_SENTRY_TRACES_SAMPLE_RATE=1.0
WEB_SENTRY_DSN=https://[email protected]/project-id
PLUGIN_SENTRY_ENABLED=true

4.3 Agrégation de logs

# Configuration des logs
LOG_LEVEL=INFO
LOG_OUTPUT_FORMAT=json
LOG_FILE=/app/logs/server.log
LOG_FILE_MAX_SIZE=20
LOG_FILE_BACKUP_COUNT=5

Consultation des logs :

# Docker
docker compose logs -f api
docker compose logs --tail=100 worker

# Kubernetes
kubectl logs -f deployment/dify-api
kubectl logs -l app=dify-worker --tail=100

📖 Documentation détaillée : operations/monitoring.md

4.4 Surveillance des files d'attente

# .env
QUEUE_MONITOR_THRESHOLD=200
[email protected],[email protected]
QUEUE_MONITOR_INTERVAL=30
ENABLE_DATASETS_QUEUE_MONITOR=true

5. Dépannage

5.1 Problèmes courants

Échec de démarrage des conteneurs

Symptôme : Les conteneurs redémarrent en boucle ou ne peuvent pas démarrer

Diagnostic :

# Voir l'état des conteneurs
docker compose ps

# Voir les logs
docker compose logs api

# Vérifier l'état de santé
docker compose exec api curl http://localhost:5001/health

Causes courantes :

Échec de connexion à la base de données

# Vérifier la base de données
docker compose exec db_postgres pg_isready
# Vérifier la connexion
docker compose exec api env | grep DB_

Service de dépendance non prêt

# Vérifier la configuration depends_on
depends_on:
  db_postgres:
    condition: service_healthy

Erreur de configuration des variables d'environnement

# Vérifier les variables requises
docker compose config | grep -E "SECRET_KEY|DB_PASSWORD"

Problèmes de connexion réseau

Symptôme : Impossible d'accéder aux API externes ou aux services internes

Diagnostic :

# Tester le proxy SSRF
docker compose exec api curl -x http://ssrf_proxy:3128 https://api.openai.com

# Tester les services internes
docker compose exec api curl http://redis:6379
docker compose exec api curl http://db_postgres:5432

Problèmes de performance

Symptôme : Réponses lentes, timeouts, épuisement des ressources

Diagnostic :

# Voir l'utilisation des ressources
docker stats

# Voir les connexions à la base de données
docker compose exec db_postgres psql -U postgres -d dify -c "SELECT count(*) FROM pg_stat_activity;"

# Voir la mémoire Redis
docker compose exec redis redis-cli INFO memory

📖 Documentation détaillée : operations/troubleshooting.md

5.2 Processus de reprise après incident

Panne de base de données

# 1. Vérifier l'état
docker compose ps db_postgres

# 2. Voir les logs
docker compose logs db_postgres

# 3. Redémarrer le service
docker compose restart db_postgres

# 4. Vérifier la connexion
docker compose exec db_postgres pg_isready

# 5. Vérifier l'intégrité des données
docker compose exec db_postgres psql -U postgres -d dify -c "SELECT count(*) FROM accounts;"

Ordre de redémarrage des services

# 1. Services de base
docker compose restart db_postgres redis

# 2. Services principaux
docker compose restart api worker beat

# 3. Services frontend
docker compose restart web nginx

# 4. Vérification
docker compose ps
curl http://localhost/health

📖 Documentation détaillée : operations/backup.md

6. Bonnes pratiques

6.1 Bonnes pratiques de sécurité

Mise à jour régulière des clés
- Rotation de SECRET_KEY tous les 90 jours
- Utilisation d'un service de gestion des clés (AWS KMS, HashiCorp Vault)
Principe du moindre privilège
- Conteneurs exécutés avec un utilisateur non-root
- Utilisateurs de base de données avec uniquement les privilèges nécessaires
Isolement réseau
- Utilisation d'un réseau interne pour isoler les services sensibles
- Contrôle de l'accès externe via le proxy SSRF
Journaux d'audit
- Activation de la journalisation détaillée
- Revue régulière des logs d'accès et d'erreurs

6.2 Bonnes pratiques de déploiement

Séparation des environnements
- Environnements de développement, test et production indépendants
- Utilisation de configurations et de clés différentes
Déploiement automatisé
- Utilisation de pipelines CI/CD
- Tests et validation automatisés
Contrôle de version
- Versionnement des fichiers de configuration (à l'exclusion des informations sensibles)
- Utilisation de Git pour gérer le code d'infrastructure
Surveillance et alertes
- Configuration d'indicateurs de surveillance complets
- Définition de seuils d'alerte raisonnables

6.3 Bonnes pratiques d'exploitation

Stratégie de sauvegarde
- Sauvegarde automatique quotidienne de la base de données
- Test régulier du processus de restauration
Planification de capacité
- Surveillance des tendances d'utilisation des ressources
- Mise à l'échelle anticipée pour éviter les problèmes de performance
Maintenance de la documentation
- Enregistrement des modifications de configuration
- Tenue d'un manuel d'exploitation
Réponse aux incidents
- Établissement d'un processus de réponse aux incidents
- Exercices réguliers de scénarios de reprise

📖 Documentation détaillée : best-practices.md

7. Modèles de configuration

7.1 Modèle pour l'environnement de développement

# .env.development
DEBUG=true
LOG_LEVEL=DEBUG
MIGRATION_ENABLED=true

# Utiliser les mots de passe par défaut (environnement de développement uniquement)
DB_PASSWORD=difyai123456
REDIS_PASSWORD=difyai123456

# Désactiver HTTPS
NGINX_HTTPS_ENABLED=false

7.2 Modèle pour l'environnement de production

# .env.production
DEBUG=false
LOG_LEVEL=INFO
DEPLOY_ENV=PRODUCTION

# Clés fortes (doivent être modifiées)
SECRET_KEY=$(openssl rand -base64 42)
DB_PASSWORD=<mot-de-passe-fort>
REDIS_PASSWORD=<mot-de-passe-fort>

# Activer HTTPS
NGINX_HTTPS_ENABLED=true
NGINX_SSL_CERT_FILENAME=fullchain.pem
NGINX_SSL_CERT_KEY_FILENAME=privkey.pem

# Activer la surveillance
ENABLE_OTEL=true
API_SENTRY_DSN=<votre-sentry-dsn>

7.3 Modèle pour la haute disponibilité

# docker-compose.ha.yaml
services:
  api:
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: '2'
          memory: 4G
      restart_policy:
        condition: on-failure
        max_attempts: 3

  worker:
    deploy:
      replicas: 2
      resources:
        limits:
          cpus: '4'
          memory: 8G

8. Références

Documentation officielle

Ressources communautaires

SKILLs associés

01-workflow - Conception de workflows
02-plugin - Développement de plugins
03-performance - Optimisation des performances

Référence rapide des commandes

# Déploiement Docker
docker compose up -d                    # Démarrer tous les services
docker compose ps                       # Voir l'état des services
docker compose logs -f api              # Voir les logs de l'API
docker compose restart api              # Redémarrer le service API
docker compose down                     # Arrêter tous les services

# Vérifications de santé
curl http://localhost/health            # Vérifier la santé du service
docker compose exec db_postgres pg_isready  # Vérifier la base de données
docker compose exec redis redis-cli ping    # Vérifier Redis

# Consultation des logs
docker compose logs --tail=100 api      # Voir les 100 dernières lignes de logs
docker compose logs -f worker           # Voir les logs du worker en temps réel

# Opérations sur la base de données
docker compose exec db_postgres psql -U postgres -d dify  # Se connecter à la base de données
docker compose exec db_postgres pg_dump -U postgres dify > backup.sql  # Sauvegarder

# Kubernetes
kubectl get pods -l app=dify            # Voir l'état des Pods
kubectl logs -f deployment/dify-api     # Voir les logs
kubectl describe pod <nom-du-pod>       # Voir les détails du Pod
kubectl exec -it <nom-du-pod> -- /bin/bash  # Entrer dans le conteneur

Version : 1.0.0 Dernière mise à jour : 2026-03-04 Mainteneur : Dify SKILL Team

Demander à votre IA préférée

Documentation

SKILL Sécurité et Déploiement Dify

Aperçu

Scénarios d'utilisation

Capacités principales

Démarrage rapide

Configuration de déploiement minimale

Checklist de sécurité

Vérifications avant déploiement

Vérifications en cours d'exécution

Structure des répertoires

1. Mécanismes de protection de sécurité

1.1 Protection SSRF

1.2 Bac à sable pour le code

1.3 Chiffrement des données

1.4 Gestion des autorisations

2. Déploiement Docker

2.1 Déploiement rapide

2.2 Configuration de production

2.3 Architecture réseau

3. Déploiement Kubernetes

3.1 Déploiement rapide avec Helm

3.2 Architecture haute disponibilité

3.3 Intégration de services managés

4. Surveillance et alertes

4.1 Configuration OpenTelemetry

4.2 Suivi des erreurs avec Sentry

4.3 Agrégation de logs

4.4 Surveillance des files d'attente

5. Dépannage

5.1 Problèmes courants

Échec de démarrage des conteneurs

Problèmes de connexion réseau

Problèmes de performance

5.2 Processus de reprise après incident

Panne de base de données

Ordre de redémarrage des services

6. Bonnes pratiques

6.1 Bonnes pratiques de sécurité

6.2 Bonnes pratiques de déploiement

6.3 Bonnes pratiques d'exploitation

7. Modèles de configuration

7.1 Modèle pour l'environnement de développement

7.2 Modèle pour l'environnement de production

7.3 Modèle pour la haute disponibilité

8. Références

Documentation officielle

Ressources communautaires

SKILLs associés

Référence rapide des commandes

Individual skills in this repo

SystemTce/dify-skills

SystemTce/dify-skills

SystemTce/dify-skills

SystemTce/dify-skills

SystemTce/dify-skills

Skills associés

steipete/bluebubbles

steipete/eightctl

steipete/blucli

steipete/bear-notes

steipete/camsnap

steipete/gifgrep