Was macht Dify Sicherheits- und Bereitstellungs-SKILL?
Überblick
Dieser SKILL bietet einen umfassenden Leitfaden für Sicherheitspraktiken und Deployment-Operationen der Dify-Plattform. Er hilft Entwicklern und Betriebsteams, eine sichere, stabile und leistungsstarke Produktionsumgebung aufzubauen.
Einsatzszenarien
Verwende diesen SKILL, wenn du:
- 🚀 Dify in der Produktion bereitstellen möchtest (Docker/Kubernetes)
- 🔒 Sicherheitsmechanismen konfigurieren möchtest (SSRF, Sandbox, Verschlüsselung)
- 🔧 Bereitstellungsprobleme lösen möchtest (Container-Startfehler, Netzwerkkonfiguration, Leistungsengpässe)
- 📊 Die Produktionsumgebung optimieren möchtest (Überwachung/Alarmierung, Hochverfügbarkeit, Fehlerbehebung)
- ✅ Sicherheitsaudits und Konfigurationsvalidierung durchführen möchtest
Kernfunktionen
- Sicherheit: SSRF-Schutz, Code-Sandbox, Datenverschlüsselung, Berechtigungsmanagement
- Docker-Bereitstellung: Schnelle Bereitstellung, Produktionskonfiguration, Netzwerkarchitektur, Ressourcenoptimierung
- Kubernetes-Bereitstellung: Hochverfügbarkeitsarchitektur, automatische Skalierung, Helm-Bereitstellung
- Überwachung & Alarmierung: OpenTelemetry, Sentry, Log-Aggregation, Leistungsüberwachung
- Fehlerbehebung: Problemdiagnose, Wiederherstellungsprozesse, Backup-Strategien
Schnellstart
Minimalkonfiguration für die Bereitstellung
# 1. Repository klonen
git clone https://github.com/langgenius/dify.git
cd dify/docker
# 2. Umgebungsvariablen kopieren
cp .env.example .env
# 3. Wichtige Sicherheitskonfigurationen ändern
# Bearbeite die .env-Datei:
SECRET_KEY=$(openssl rand -base64 42)
DB_PASSWORD=your-strong-password
REDIS_PASSWORD=your-redis-password
SANDBOX_API_KEY=$(openssl rand -base64 32)
# 4. Dienste starten
docker compose up -d
# 5. Bereitstellung überprüfen
docker compose ps
curl http://localhost/health
Sicherheits-Checkliste
Vor der Bereitstellung prüfen
- SECRET_KEY wurde in einen sicheren Schlüssel geändert (mit
openssl rand -base64 42) - Datenbankpasswort wurde vom Standardwert geändert
- Redis-Passwort wurde festgelegt
- SSRF Proxy wurde konfiguriert und blockiert den Zugriff auf interne Netzwerke
- Sandbox wurde mit Netzwerk-Proxy aktiviert
- HTTPS/TLS-Zertifikat wurde konfiguriert (Produktion)
- API-Key-Verwaltung ist aktiviert
- Datei-Upload-Limit wurde festgelegt (UPLOAD_FILE_SIZE_LIMIT)
- Sensible Umgebungsvariablen wurden verschlüsselt gespeichert
Laufzeitprüfungen
- Container-Berechtigungen: Ausführung als Nicht-Root-Benutzer
- Netzwerkisolierung: ssrf_proxy_network funktioniert korrekt
- Health Checks: Alle Dienste melden korrekten Gesundheitszustand
- Logging: Aktiviert und gibt korrekte Ausgaben
- Überwachung/Alarmierung: Konfiguriert (OpenTelemetry/Sentry)
- Backup-Strategie: Implementiert (Datenbank, Dateispeicher)
- Ressourcenlimits: CPU-/Speicherbegrenzungen konfiguriert
- SSL-Zertifikat: Gültigkeitsprüfung und automatische Verlängerung
Verzeichnisstruktur
04-security/
├── SKILL.md # Diese Datei - Sicherheits- und Bereitstellungs-Überblick
├── security/ # Sicherheitspraktiken
│ ├── ssrf-protection.md # SSRF-Schutz-Konfiguration
│ ├── sandbox.md # Code-Sandbox-Isolierung
│ ├── encryption.md # Datenverschlüsselung und TLS
│ └── auth.md # Authentifizierung und Berechtigungsmanagement
├── deployment/ # Bereitstellungsleitfäden
│ ├── docker-compose.md # Docker Compose-Bereitstellung
│ ├── kubernetes.md # Kubernetes-Bereitstellung
│ ├── serverless.md # Serverless-Bereitstellung
│ └── high-availability.md # Hochverfügbarkeitsarchitektur
├── operations/ # Betriebspraktiken
│ ├── monitoring.md # Überwachung und Alarmierung
│ ├── logging.md # Log-Management
│ ├── backup.md # Backup und Wiederherstellung
│ └── troubleshooting.md # Fehlerbehebung
└── best-practices.md # Zusammenfassung der Best Practices
1. Sicherheitsmechanismen
1.1 SSRF-Schutz
Dify verwendet einen Squid-Proxy, um SSRF (Server-Side Request Forgory) zu verhindern und den Zugriff auf interne Netzwerkadressen zu blockieren.
Kernkonfiguration:
# squid.conf - Interne IP-Blacklist
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
# Zugriff auf interne Netzwerke verweigern
http_access deny localnet
# Erlaubte Ports
acl Safe_ports port 80 443 1025-65535
http_access deny !Safe_ports
Überprüfungsmethode:
# Test, dass interner Zugriff blockiert wird
docker compose exec api curl -x http://ssrf_proxy:3128 http://127.0.0.1
# Sollte 403 Forbidden zurückgeben
# Test, dass externer Zugriff funktioniert
docker compose exec api curl -x http://ssrf_proxy:3128 https://api.openai.com
# Sollte normal antworten
📖 Details: security/ssrf-protection.md
1.2 Code-Sandbox
Der Sandbox-Dienst bietet eine sichere Umgebung für die Code-Ausführung und isoliert Benutzercode.
Kernkonfiguration:
# config.yaml
app:
key: dify-sandbox # In einen sicheren Schlüssel ändern
max_workers: 4
worker_timeout: 15
enable_network: true # Zugriff auf externe Dienste über SSRF Proxy
proxy:
http: 'http://ssrf_proxy:3128'
https: 'http://ssrf_proxy:3128'
Sicherheitsmerkmale:
- ✅ Whitelist für Systemaufrufe
- ✅ Ressourcenkontingentverwaltung (CPU, Speicher, Timeout)
- ✅ Netzwerkzugriff über SSRF Proxy
- ✅ Dateisystemisolierung
📖 Details: security/sandbox.md
1.3 Datenverschlüsselung
Transportverschlüsselung (TLS/HTTPS):
# .env-Konfiguration
NGINX_HTTPS_ENABLED=true
NGINX_SSL_CERT_FILENAME=fullchain.pem
NGINX_SSL_CERT_KEY_FILENAME=privkey.pem
NGINX_SSL_PROTOCOLS=TLSv1.2 TLSv1.3
Datenbank-Verbindungsverschlüsselung:
# PostgreSQL SSL
DB_HOST=db_postgres
POSTGRES_SSL_MODE=require
# Redis SSL
REDIS_USE_SSL=true
REDIS_SSL_CERT_REQS=CERT_REQUIRED
📖 Details: security/encryption.md
1.4 Berechtigungsmanagement
API-Key-Verwaltung:
# Sichere Schlüssel generieren
SECRET_KEY=$(openssl rand -base64 42)
PLUGIN_DAEMON_KEY=$(openssl rand -base64 42)
PLUGIN_DIFY_INNER_API_KEY=$(openssl rand -base64 42)
OAuth 2.0-Integration:
- Unterstützt Autorisierung von Drittanbieterdiensten
- Automatische Aktualisierung von Zugriffstoken
- Kontrolle des Berechtigungsumfangs
📖 Details: security/auth.md
2. Docker-Bereitstellung
2.1 Schnellbereitstellung
Ein-Befehl-Start:
cd dify/docker
cp .env.example .env
# Bearbeite .env, um Passwörter und Schlüssel zu ändern
docker compose up -d
Dienstarchitektur:
nginx (80/443)
├── web (3000) - Frontend UI
├── api (5001) - Geschäftslogik
├── worker - Hintergrundaufgaben
├── beat - Zeitgesteuerte Aufgaben
├── plugin_daemon (5002) - Plugin-Verwaltung
└── sandbox (8194) - Code-Ausführung
Basisdienste:
├── db_postgres (5432) - Hauptdatenbank
├── redis (6379) - Cache und Warteschlangen
├── weaviate (8080) - Vektordatenbank
└── ssrf_proxy (3128) - SSRF-Schutz
📖 Details: deployment/docker-compose.md
2.2 Produktionskonfiguration
Ressourcenlimits:
# docker-compose.yaml
services:
api:
deploy:
resources:
limits:
cpus: '2'
memory: 4G
reservations:
cpus: '1'
memory: 2G
Health Checks:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5001/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
Log-Management:
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
📖 Details: deployment/docker-compose.md
2.3 Netzwerkarchitektur
Netzwerkisolierung:
networks:
# Internes Netzwerk - kein Zugriff auf externe Netzwerke
ssrf_proxy_network:
driver: bridge
internal: true
# Standardnetzwerk - Zugriff auf externe Netzwerke
default:
driver: bridge
Dienstkommunikation:
- API/Worker/Sandbox → ssrf_proxy → Externe APIs
- Nginx → API/Web (Reverse Proxy)
- API → Datenbank/Redis (Interne Kommunikation)
📖 Details: deployment/docker-compose.md
3. Kubernetes-Bereitstellung
3.1 Schnelle Helm-Bereitstellung
# Helm-Repository hinzufügen
helm repo add dify https://borispolonsky.github.io/dify-helm
helm repo update
# Dify installieren
helm install my-dify dify/dify \
--set postgresql.enabled=true \
--set redis.enabled=true \
--set weaviate.enabled=true
# Status prüfen
kubectl get pods -l app.kubernetes.io/name=dify
3.2 Hochverfügbarkeitsarchitektur
Multi-Replica-Bereitstellung:
# 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
Pod Anti-Affinität:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- dify-api
topologyKey: kubernetes.io/hostname
📖 Details: deployment/kubernetes.md
3.3 Managed Service-Integration
Verwendung von Cloud-Managed-Diensten:
# RDS PostgreSQL verwenden
postgresql:
enabled: false
externalDatabase:
host: your-rds-endpoint.rds.amazonaws.com
port: 5432
database: dify
username: dify
password: your-password
# ElastiCache Redis verwenden
redis:
enabled: false
externalRedis:
host: your-redis.cache.amazonaws.com
port: 6379
password: your-password
Vorteile:
- ✅ Automatische Backups und Wiederherstellung
- ✅ Hochverfügbarkeit und Failover
- ✅ Leistungsüberwachung und -optimierung
- ✅ Reduzierter Betriebsaufwand
📖 Details: deployment/high-availability.md
4. Überwachung und Alarmierung
4.1 OpenTelemetry-Konfiguration
# .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
Überwachungsmetriken:
- Anforderungslatenz und -durchsatz
- Fehlerrate und Erfolgsrate
- Ressourcennutzung (CPU, Speicher, Festplatte)
- Datenbankverbindungspool-Status
- Warteschlangentiefe und Verarbeitungsgeschwindigkeit
4.2 Sentry-Fehlerverfolgung
# .env
API_SENTRY_DSN=https://[email protected]/project-id
API_SENTRY_TRACES_SAMPLE_RATE=1.0
WEB_SENTRY_DSN=https://[email protected]/project-id
PLUGIN_SENTRY_ENABLED=true
4.3 Log-Aggregation
# Log-Konfiguration
LOG_LEVEL=INFO
LOG_OUTPUT_FORMAT=json
LOG_FILE=/app/logs/server.log
LOG_FILE_MAX_SIZE=20
LOG_FILE_BACKUP_COUNT=5
Logs anzeigen:
# 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
📖 Details: operations/monitoring.md
4.4 Warteschlangen-Überwachung
# .env
QUEUE_MONITOR_THRESHOLD=200
[email protected],[email protected]
QUEUE_MONITOR_INTERVAL=30
ENABLE_DATASETS_QUEUE_MONITOR=true
5. Fehlerbehebung
5.1 Häufige Probleme
Container-Startfehler
Symptom: Container starten wiederholt neu oder können nicht gestartet werden
Diagnose:
# Container-Status prüfen
docker compose ps
# Logs anzeigen
docker compose logs api
# Gesundheitsstatus prüfen
docker compose exec api curl http://localhost:5001/health
Häufige Ursachen:
-
Datenbankverbindungsfehler
# Datenbank prüfen docker compose exec db_postgres pg_isready # Verbindung überprüfen docker compose exec api env | grep DB_ -
Abhängige Dienste nicht bereit
# depends_on-Konfiguration prüfen depends_on: db_postgres: condition: service_healthy -
Fehlerhafte Umgebungsvariablen
# Erforderliche Variablen überprüfen docker compose config | grep -E "SECRET_KEY|DB_PASSWORD"
Netzwerkverbindungsprobleme
Symptom: Zugriff auf externe APIs oder interne Dienste nicht möglich
Diagnose:
# SSRF Proxy testen
docker compose exec api curl -x http://ssrf_proxy:3128 https://api.openai.com
# Interne Dienste testen
docker compose exec api curl http://redis:6379
docker compose exec api curl http://db_postgres:5432
Leistungsprobleme
Symptom: Langsame Antwortzeiten, Timeouts, Ressourcenerschöpfung
Diagnose:
# Ressourcennutzung anzeigen
docker stats
# Datenbankverbindungen prüfen
docker compose exec db_postgres psql -U postgres -d dify -c "SELECT count(*) FROM pg_stat_activity;"
# Redis-Speicher prüfen
docker compose exec redis redis-cli INFO memory
📖 Details: operations/troubleshooting.md
5.2 Fehlerbehebungsprozesse
Datenbankfehler
# 1. Status prüfen
docker compose ps db_postgres
# 2. Logs anzeigen
docker compose logs db_postgres
# 3. Dienst neustarten
docker compose restart db_postgres
# 4. Verbindung überprüfen
docker compose exec db_postgres pg_isready
# 5. Datenintegrität prüfen
docker compose exec db_postgres psql -U postgres -d dify -c "SELECT count(*) FROM accounts;"
Dienst-Neustartreihenfolge
# 1. Basisdienste
docker compose restart db_postgres redis
# 2. Kerndienste
docker compose restart api worker beat
# 3. Frontend-Dienste
docker compose restart web nginx
# 4. Überprüfung
docker compose ps
curl http://localhost/health
📖 Details: operations/backup.md
6. Best Practices
6.1 Sicherheits-Best-Practices
-
Schlüssel regelmäßig aktualisieren
- SECRET_KEY alle 90 Tage rotieren
- Schlüsselverwaltungsdienste verwenden (AWS KMS, HashiCorp Vault)
-
Prinzip der minimalen Rechte
- Container als Nicht-Root-Benutzer ausführen
- Datenbankbenutzer nur die erforderlichen Berechtigungen erteilen
-
Netzwerkisolierung
- Interne Netzwerke zur Isolierung sensibler Dienste verwenden
- Externen Zugriff über SSRF Proxy kontrollieren
-
Audit-Logs
- Detaillierte Protokollierung aktivieren
- Zugriffs- und Fehlerprotokolle regelmäßig überprüfen
6.2 Bereitstellungs-Best-Practices
-
Umgebungstrennung
- Entwicklung, Test und Produktion getrennt halten
- Unterschiedliche Konfigurationen und Schlüssel verwenden
-
Automatisierte Bereitstellung
- CI/CD-Pipelines verwenden
- Automatisierte Tests und Validierungen
-
Versionskontrolle
- Konfigurationsdateien versionieren (sensible Informationen ausschließen)
- Git für Infrastruktur-Code verwenden
-
Überwachung und Alarmierung
- Umfassende Überwachungsmetriken konfigurieren
- Angemessene Alarmierungsschwellenwerte festlegen
6.3 Betriebs-Best-Practices
-
Backup-Strategie
- Tägliche automatische Datenbanksicherungen
- Wiederherstellungsprozesse regelmäßig testen
-
Kapazitätsplanung
- Ressourcennutzungstrends überwachen
- Frühzeitig skalieren, um Leistungsprobleme zu vermeiden
-
Dokumentationspflege
- Konfigurationsänderungen dokumentieren
- Betriebshandbücher pflegen
-
Notfallwiederherstellung
- Fehlerbehebungsprozesse etablieren
- Wiederherstellungsszenarien regelmäßig üben
📖 Details: best-practices.md
7. Konfigurationsvorlagen
7.1 Entwicklungsumgebungs-Vorlage
# .env.development
DEBUG=true
LOG_LEVEL=DEBUG
MIGRATION_ENABLED=true
# Standardpasswörter verwenden (nur Entwicklungsumgebung)
DB_PASSWORD=difyai123456
REDIS_PASSWORD=difyai123456
# HTTPS deaktivieren
NGINX_HTTPS_ENABLED=false
7.2 Produktionsumgebungs-Vorlage
# .env.production
DEBUG=false
LOG_LEVEL=INFO
DEPLOY_ENV=PRODUCTION
# Starke Schlüssel (müssen geändert werden)
SECRET_KEY=$(openssl rand -base64 42)
DB_PASSWORD=<starkes-passwort>
REDIS_PASSWORD=<starkes-passwort>
# HTTPS aktivieren
NGINX_HTTPS_ENABLED=true
NGINX_SSL_CERT_FILENAME=fullchain.pem
NGINX_SSL_CERT_KEY_FILENAME=privkey.pem
# Überwachung aktivieren
ENABLE_OTEL=true
API_SENTRY_DSN=<ihre-sentry-dsn>
7.3 Hochverfügbarkeits-Vorlage
# 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. Referenzen
Offizielle Dokumentation
Community-Ressourcen
Verwandte SKILLs
- 01-workflow - Workflow-Design
- 02-plugin - Plugin-Entwicklung
- 03-performance - Leistungsoptimierung
Kurzer Befehlsreferenz
# Docker-Bereitstellung
docker compose up -d # Alle Dienste starten
docker compose ps # Dienststatus anzeigen
docker compose logs -f api # API-Logs anzeigen
docker compose restart api # API-Dienst neustarten
docker compose down # Alle Dienste stoppen
# Health Checks
curl http://localhost/health # Dienstzustand prüfen
docker compose exec db_postgres pg_isready # Datenbank prüfen
docker compose exec redis redis-cli ping # Redis prüfen
# Logs anzeigen
docker compose logs --tail=100 api # Letzte 100 Log-Einträge anzeigen
docker compose logs -f worker # Worker-Logs live anzeigen
# Datenbankoperationen
docker compose exec db_postgres psql -U postgres -d dify # Mit Datenbank verbinden
docker compose exec db_postgres pg_dump -U postgres dify > backup.sql # Backup erstellen
# Kubernetes
kubectl get pods -l app=dify # Pod-Status anzeigen
kubectl logs -f deployment/dify-api # Logs anzeigen
kubectl describe pod <pod-name> # Pod-Details anzeigen
kubectl exec -it <pod-name> -- /bin/bash # In Container einsteigen
Version: 1.0.0 Letzte Aktualisierung: 2026-03-04 Betreuer: Dify SKILL Team