Dify セキュリティとデプロイ SKILL
概要
本 SKILL は、Dify プラットフォームのセキュリティ実践とデプロイ運用に関する完全ガイドを提供し、開発者や運用担当者が安全で安定した高性能な本番環境を構築できるようにします。
トリガーシナリオ
以下のような場合に本 SKILL を使用してください:
- 🚀 Dify を本番環境にデプロイする (Docker / Kubernetes)
- 🔒 セキュリティ対策を設定する (SSRF、サンドボックス、暗号化)
- 🔧 デプロイ時の問題を解決する (コンテナ起動失敗、ネットワーク設定、パフォーマンスボトルネック)
- 📊 本番環境を最適化する (監視アラート、高可用性、障害復旧)
- ✅ セキュリティ監査と設定検証を行う
コア機能
- セキュリティ対策: SSRF 対策、コードサンドボックス、データ暗号化、権限管理
- Docker デプロイ: 高速デプロイ、本番設定、ネットワークアーキテクチャ、リソース最適化
- Kubernetes デプロイ: 高可用性アーキテクチャ、自動スケーリング、Helm デプロイ
- 監視とアラート: OpenTelemetry、Sentry、ログ集約、パフォーマンス監視
- 障害復旧: 問題診断、復旧手順、バックアップ戦略
クイックスタート
最小デプロイ設定
# 1. リポジトリのクローン
git clone https://github.com/langgenius/dify.git
cd dify/docker
# 2. 環境変数ファイルのコピー
cp .env.example .env
# 3. 重要なセキュリティ設定の変更
# .env ファイルを編集:
SECRET_KEY=$(openssl rand -base64 42)
DB_PASSWORD=your-strong-password
REDIS_PASSWORD=your-redis-password
SANDBOX_API_KEY=$(openssl rand -base64 32)
# 4. サービスの起動
docker compose up -d
# 5. デプロイの確認
docker compose ps
curl http://localhost/health
セキュリティチェックリスト
デプロイ前のチェック
- SECRET_KEY が強力なキーに変更されている (
openssl rand -base64 42を使用) - データベースパスワード がデフォルトから変更されている
- Redis パスワード が設定されている
- SSRF Proxy が設定され、内部ネットワークへのアクセスがブロックされている
- Sandbox でネットワークプロキシが有効になっている
- HTTPS/TLS 証明書が設定されている (本番環境)
- API Key 管理 メカニズムが有効になっている
- ファイルアップロード制限 が設定されている (UPLOAD_FILE_SIZE_LIMIT)
- 機密性の高い環境変数 が暗号化されて保存されている
実行時のチェック
- コンテナの権限 が non-root ユーザーで実行されている
- ネットワーク分離 ssrf_proxy_network が正常に機能している
- ヘルスチェック すべてのサービスの健全性が正常である
- ログ記録 が有効で正常に出力されている
- 監視アラート が設定されている (OpenTelemetry / Sentry)
- バックアップ戦略 が実装されている (データベース、ファイルストレージ)
- リソース制限 CPU / メモリ制限が設定されている
- SSL 証明書 の有効期限チェックと自動更新が設定されている
ディレクトリ構成
04-security/
├── SKILL.md # このファイル - セキュリティとデプロイの概要
├── security/ # セキュリティ実践
│ ├── ssrf-protection.md # SSRF 対策設定
│ ├── sandbox.md # コードサンドボックス分離
│ ├── encryption.md # データ暗号化と TLS
│ └── auth.md # 認証と権限管理
├── deployment/ # デプロイガイド
│ ├── docker-compose.md # Docker Compose デプロイ
│ ├── kubernetes.md # Kubernetes デプロイ
│ ├── serverless.md # Serverless デプロイ
│ └── high-availability.md # 高可用性アーキテクチャ
├── operations/ # 運用実践
│ ├── monitoring.md # 監視とアラート
│ ├── logging.md # ログ管理
│ ├── backup.md # バックアップと復旧
│ └── troubleshooting.md # トラブルシューティング
└── best-practices.md # ベストプラクティスまとめ
一、セキュリティ対策
1.1 SSRF 対策
Dify は Squid プロキシを使用して SSRF (Server-Side Request Forgery) 対策を実装し、内部ネットワークアドレスへのアクセスをブロックします。
コア設定:
# squid.conf - 内部ネットワークアドレスのブラックリスト
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
# 内部ネットワークへのアクセスを拒否
http_access deny localnet
# 許可するポート
acl Safe_ports port 80 443 1025-65535
http_access deny !Safe_ports
検証方法:
# 内部ネットワークへのアクセスがブロックされることを確認
docker compose exec api curl -x http://ssrf_proxy:3128 http://127.0.0.1
# 403 Forbidden が返されるべき
# 外部アクセスが正常に行えることを確認
docker compose exec api curl -x http://ssrf_proxy:3128 https://api.openai.com
# 正常に応答が返されるべき
📖 詳細ドキュメント: security/ssrf-protection.md
1.2 コードサンドボックス
Sandbox サービスは安全なコード実行環境を提供し、ユーザーコードを隔離します。
コア設定:
# config.yaml
app:
key: dify-sandbox # 強力なキーに変更
max_workers: 4
worker_timeout: 15
enable_network: true # SSRF Proxy 経由で外部にアクセス
proxy:
http: 'http://ssrf_proxy:3128'
https: 'http://ssrf_proxy:3128'
セキュリティ機能:
- ✅ システムコールのホワイトリスト制限
- ✅ リソースクォータ管理 (CPU、メモリ、タイムアウト)
- ✅ ネットワークアクセスは SSRF Proxy 経由
- ✅ ファイルシステムの分離
📖 詳細ドキュメント: security/sandbox.md
1.3 データ暗号化
転送暗号化 (TLS / HTTPS):
# .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
データベース接続の暗号化:
# PostgreSQL SSL
DB_HOST=db_postgres
POSTGRES_SSL_MODE=require
# Redis SSL
REDIS_USE_SSL=true
REDIS_SSL_CERT_REQS=CERT_REQUIRED
📖 詳細ドキュメント: security/encryption.md
1.4 権限管理
API Key 管理:
# 強力なキーの生成
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 統合:
- サードパーティサービス認証をサポート
- アクセストークンの自動更新
- 権限スコープの制御
📖 詳細ドキュメント: security/auth.md
二、Docker デプロイ
2.1 クイックデプロイ
ワンクリック起動:
cd dify/docker
cp .env.example .env
# .env を編集し、パスワードとキーを変更
docker compose up -d
サービス構成:
nginx (80/443)
├── web (3000) - フロントエンド UI
├── api (5001) - ビジネスロジック
├── worker - バックグラウンドタスク
├── beat - 定期タスク
├── plugin_daemon (5002) - プラグイン管理
└── sandbox (8194) - コード実行
基盤サービス:
├── db_postgres (5432) - メインデータベース
├── redis (6379) - キャッシュとキュー
├── weaviate (8080) - ベクトルデータベース
└── ssrf_proxy (3128) - SSRF 対策
📖 詳細ドキュメント: deployment/docker-compose.md
2.2 本番環境設定
リソース制限:
# docker-compose.yaml
services:
api:
deploy:
resources:
limits:
cpus: '2'
memory: 4G
reservations:
cpus: '1'
memory: 2G
ヘルスチェック:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5001/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
ログ管理:
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
📖 詳細ドキュメント: deployment/docker-compose.md
2.3 ネットワーク構成
ネットワーク分離:
networks:
# 内部ネットワーク - 外部にアクセス不可
ssrf_proxy_network:
driver: bridge
internal: true
# デフォルトネットワーク - 外部にアクセス可能
default:
driver: bridge
サービス間通信:
- API / Worker / Sandbox → ssrf_proxy → 外部 API
- Nginx → API / Web (リバースプロキシ)
- API → Database / Redis (内部通信)
📖 詳細ドキュメント: deployment/docker-compose.md
三、Kubernetes デプロイ
3.1 Helm によるクイックデプロイ
# Helm リポジトリの追加
helm repo add dify https://borispolonsky.github.io/dify-helm
helm repo update
# Dify のインストール
helm install my-dify dify/dify \
--set postgresql.enabled=true \
--set redis.enabled=true \
--set weaviate.enabled=true
# 状態の確認
kubectl get pods -l app.kubernetes.io/name=dify
3.2 高可用性構成
マルチレプリカデプロイ:
# 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 アンチアフィニティ:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- dify-api
topologyKey: kubernetes.io/hostname
📖 詳細ドキュメント: deployment/kubernetes.md
3.3 マネージドサービス統合
クラウドプロバイダーのマネージドサービスを使用:
# RDS PostgreSQL を使用
postgresql:
enabled: false
externalDatabase:
host: your-rds-endpoint.rds.amazonaws.com
port: 5432
database: dify
username: dify
password: your-password
# ElastiCache Redis を使用
redis:
enabled: false
externalRedis:
host: your-redis.cache.amazonaws.com
port: 6379
password: your-password
利点:
- ✅ 自動バックアップと復旧
- ✅ 高可用性とフェイルオーバー
- ✅ パフォーマンス監視と最適化
- ✅ 運用負荷の軽減
📖 詳細ドキュメント: deployment/high-availability.md
四、監視とアラート
4.1 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
監視指標:
- リクエストレイテンシとスループット
- エラー率と成功率
- リソース使用量 (CPU、メモリ、ディスク)
- データベースコネクションプールの状態
- キューの深さと処理速度
4.2 Sentry エラートラッキング
# .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_LEVEL=INFO
LOG_OUTPUT_FORMAT=json
LOG_FILE=/app/logs/server.log
LOG_FILE_MAX_SIZE=20
LOG_FILE_BACKUP_COUNT=5
ログの確認:
# 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
📖 詳細ドキュメント: operations/monitoring.md
4.4 キューモニタリング
# .env
QUEUE_MONITOR_THRESHOLD=200
[email protected],[email protected]
QUEUE_MONITOR_INTERVAL=30
ENABLE_DATASETS_QUEUE_MONITOR=true
五、トラブルシューティング
5.1 よくある問題
コンテナ起動失敗
症状: コンテナが再起動を繰り返す、または起動できない
診断:
# コンテナの状態を確認
docker compose ps
# ログを確認
docker compose logs api
# ヘルス状態を確認
docker compose exec api curl http://localhost:5001/health
よくある原因:
-
データベース接続失敗
# データベースを確認 docker compose exec db_postgres pg_isready # 接続を検証 docker compose exec api env | grep DB_ -
依存サービスの準備未完了
# depends_on 設定を確認 depends_on: db_postgres: condition: service_healthy -
環境変数の設定ミス
# 必須変数を検証 docker compose config | grep -E "SECRET_KEY|DB_PASSWORD"
ネットワーク接続問題
症状: 外部 API や内部サービスにアクセスできない
診断:
# SSRF Proxy をテスト
docker compose exec api curl -x http://ssrf_proxy:3128 https://api.openai.com
# 内部サービスをテスト
docker compose exec api curl http://redis:6379
docker compose exec api curl http://db_postgres:5432
パフォーマンス問題
症状: 応答が遅い、タイムアウト、リソース枯渇
診断:
# リソース使用量を確認
docker stats
# データベース接続を確認
docker compose exec db_postgres psql -U postgres -d dify -c "SELECT count(*) FROM pg_stat_activity;"
# Redis メモリを確認
docker compose exec redis redis-cli INFO memory
📖 詳細ドキュメント: operations/troubleshooting.md
5.2 障害復旧手順
データベース障害
# 1. 状態を確認
docker compose ps db_postgres
# 2. ログを確認
docker compose logs db_postgres
# 3. サービスを再起動
docker compose restart db_postgres
# 4. 接続を確認
docker compose exec db_postgres pg_isready
# 5. データ整合性を確認
docker compose exec db_postgres psql -U postgres -d dify -c "SELECT count(*) FROM accounts;"
サービス再起動の順序
# 1. 基盤サービス
docker compose restart db_postgres redis
# 2. コアサービス
docker compose restart api worker beat
# 3. フロントエンドサービス
docker compose restart web nginx
# 4. 確認
docker compose ps
curl http://localhost/health
📖 詳細ドキュメント: operations/backup.md
六、ベストプラクティス
6.1 セキュリティベストプラクティス
-
定期的にキーを更新する
- SECRET_KEY は 90 日ごとにローテーション
- キー管理サービスを使用 (AWS KMS, HashiCorp Vault)
-
最小権限の原則
- コンテナは non-root ユーザーで実行
- データベースユーザーには必要最小限の権限のみ付与
-
ネットワーク分離
- 内部ネットワークを使用して機密サービスを分離
- SSRF Proxy 経由で外部アクセスを制御
-
監査ログ
- 詳細なログ記録を有効にする
- アクセスログとエラーログを定期的にレビュー
6.2 デプロイベストプラクティス
-
環境の分離
- 開発、テスト、本番環境を独立させる
- 異なる設定とキーを使用する
-
自動化デプロイ
- CI / CD パイプラインを使用
- 自動テストと検証
-
バージョン管理
- 設定ファイルをバージョン管理 (機密情報は除外)
- Git でインフラストラクチャコードを管理
-
監視とアラート
- 包括的な監視指標を設定
- 適切なアラートしきい値を設定
6.3 運用ベストプラクティス
-
バックアップ戦略
- データベースを毎日自動バックアップ
- 定期的に復旧手順をテスト
-
キャパシティプランニング
- リソース使用傾向を監視
- パフォーマンス問題を回避するために事前にスケールアップ
-
ドキュメント管理
- 設定変更を記録
- 運用マニュアルを維持
-
インシデント対応
- 障害対応手順を確立
- 復旧シナリオを定期的に訓練
📖 詳細ドキュメント: best-practices.md
七、設定テンプレート
7.1 開発環境テンプレート
# .env.development
DEBUG=true
LOG_LEVEL=DEBUG
MIGRATION_ENABLED=true
# デフォルトパスワードを使用 (開発環境のみ)
DB_PASSWORD=difyai123456
REDIS_PASSWORD=difyai123456
# HTTPS を無効化
NGINX_HTTPS_ENABLED=false
7.2 本番環境テンプレート
# .env.production
DEBUG=false
LOG_LEVEL=INFO
DEPLOY_ENV=PRODUCTION
# 強力なキー (必ず変更)
SECRET_KEY=$(openssl rand -base64 42)
DB_PASSWORD=<strong-password>
REDIS_PASSWORD=<strong-password>
# HTTPS を有効化
NGINX_HTTPS_ENABLED=true
NGINX_SSL_CERT_FILENAME=fullchain.pem
NGINX_SSL_CERT_KEY_FILENAME=privkey.pem
# 監視を有効化
ENABLE_OTEL=true
API_SENTRY_DSN=<your-sentry-dsn>
7.3 高可用性テンプレート
# 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
八、参考資料
公式ドキュメント
コミュニティリソース
関連 SKILL
- 01-workflow - ワークフロー設計
- 02-plugin - プラグイン開発
- 03-performance - パフォーマンス最適化
クイックコマンドリファレンス
# Docker デプロイ
docker compose up -d # 全サービスを起動
docker compose ps # サービス状態を確認
docker compose logs -f api # API ログを確認
docker compose restart api # API サービスを再起動
docker compose down # 全サービスを停止
# ヘルスチェック
curl http://localhost/health # サービスの健全性を確認
docker compose exec db_postgres pg_isready # データベースを確認
docker compose exec redis redis-cli ping # Redis を確認
# ログ確認
docker compose logs --tail=100 api # 最新 100 行のログを表示
docker compose logs -f worker # worker ログをリアルタイム表示
# データベース操作
docker compose exec db_postgres psql -U postgres -d dify # データベースに接続
docker compose exec db_postgres pg_dump -U postgres dify > backup.sql # バックアップ
# Kubernetes
kubectl get pods -l app=dify # Pod 状態を確認
kubectl logs -f deployment/dify-api # ログを確認
kubectl describe pod <pod-name> # Pod 詳細を確認
kubectl exec -it <pod-name> -- /bin/bash # コンテナに入る
バージョン: 1.0.0 最終更新日: 2026-03-04 メンテナー: Dify SKILL Team