はじめに

DifyをAWS上にセルフホストすることで、AIアプリケーション開発の柔軟性とスケーラビリティを享受できます。しかし、ユーザーの機密データやナレッジデータがシステム内でどのように扱われ、どのようなセキュリティ対策が施されているのかを理解することは、非常に重要です。本記事では、添付のアーキテクチャ図に基づき、Dify on AWSにおけるデータの所在、セキュリティ対策、そして潜在的なリスクについて深掘りします。

AWS各サービスの基本情報

AWSのサービスについて基本的な役割を表としてまとめました。すでにご存じの方は読み飛ばして頂ければと思います。

サービス名	基本情報
Application Load Balancer (ALB)	Webトラフィックを複数のサーバー（この場合はDifyの各種サービス）に効率的に分散させるサービスです。これにより、アプリケーションのスケーラビリティと可用性が向上します。
AWS Certificate Manager (ACM)	SSL/TLS証明書を簡単にプロビジョニング、管理、デプロイできるサービスです。Webサイトやアプリケーションの通信を暗号化するために使用します。
Amazon Elastic Container Service (ECS) Fargate	サーバーのプロビジョニングや管理をすることなく、コンテナアプリケーション（DifyのWeb、API、Workerサービスなど）を実行できるコンテナオーケストレーションサービスです。
Amazon Simple Storage Service (S3) Bucket	高い耐久性、可用性、拡張性を誇るオブジェクトストレージサービスです。画像、動画、ドキュメントなど、あらゆる種類のデータを保存できます。Difyではナレッジベースの元ファイルなどに使われます。
Amazon Relational Database Service (RDS) Aurora Postgres Cluster	PostgreSQLと互換性のある、高性能でスケーラブルなリレーショナルデータベースサービスです。Difyの会話履歴やアプリケーション設定、ベクトルデータなどの永続的な保存に使われます。
Amazon ElastiCache for Redis	インメモリデータストアサービスで、高速なデータアクセスを提供します。セッション情報や一時的なキャッシュデータなど、頻繁にアクセスされるデータをメモリ上に保存することで、アプリケーションのパフォーマンスを向上させます。
AWS Secrets Manager	データベースの認証情報、APIキー、その他の機密情報を安全に保存、管理、取得できるサービスです。Difyが外部LLMプロバイダーなどにアクセスする際のAPIキーの管理に利用されます。
NAT Gateway	VPC内のプライベートサブネットに配置されたインスタンスが、インターネットへのアウトバウンド接続のみを可能にするためのサービスです。これにより、プライベートサブネットのリソースは外部から直接アクセスされることなく、必要なインターネット上のサービスと通信できます。
AWS Key Management Service (KMS)	暗号化キーを簡単に作成および管理できるサービスです。AWSの他のサービス（S3、RDS、Secrets Managerなど）と統合されており、データの保管時および転送時の暗号化に利用されます。
AWS Identity and Access Management (IAM)	AWSリソースへのアクセスを安全に管理するためのサービスです。誰がどのAWSリソースにアクセスできるかを細かく制御するポリシーを作成し、最小権限の原則を適用するために使用されます。

Dify on AWS アーキテクチャの概要

引用) https://github.com/aws-samples/dify-self-hosted-on-aws/blob/main/imgs/architecture.png

上記のアーキテクチャは、AWS JAPANがサンプルとして公開している、AWS上にセルフホストされたDifyのアーキテクチャです。参考としてLanggenius社が公開しているDify on AWSの一般的なアーキテクチャも以下に示します。

引用）https://github.com/langgenius/aws-cdk-for-dify

1. フロントエンドとロードバランシング

• ユーザーからのリクエストはまずALB (Application Load Balancer)（複数のサーバーにトラフィックを分散させるサービス）を通じてDifyの各サービスにルーティングされます。例えば、ユーザーがWebブラウザでDifyのURLにアクセスすると、ALBがそのリクエストを受け取り、適切なDifyサービスへ振り分けます。 オプションでACM (AWS Certificate Manager)（SSL/TLS証明書を管理するサービス）を利用してTLS通信を暗号化します。（図中の「Application Load Balancer」を参照）

2. Difyサービス群

• Dify Web Service: ユーザーインターフェースを提供します。
• Dify API / Sandbox Service: Difyアプリケーションの主要なAPIロジック、プロンプト処理、外部LLMとの連携などを担当します。ユーザーがメッセージを送信したり、ナレッジベースから情報を検索したりする際に、このサービスが中核的な処理を行います。
• Dify Worker Service: バックグラウンド処理や非同期タスクを実行します。例えば、ナレッジベースに大量のドキュメントをアップロードした際、そのエンベディング処理をこのサービスが非同期で担当します。 これらのサービスは ECS Fargate（サーバーの管理なしでコンテナアプリケーションを実行できるサービス）上で稼働します。

3. ストレージとキュー

• S3 Bucket: ナレッジベースの元ファイルや静的アセットを保存します。ユーザーがPDFやテキストファイルをナレッジベースとしてDifyにアップロードすると、それらのファイルがS3に格納されます。
• RDS Aurora Postgres Cluster: ユーザーの会話履歴、アプリケーション設定、エンべディング化されたナレッジデータなどを保存します。
• ElastiCache Redis: セッション情報や一時的なキャッシュデータを保存します。

ユーザー入力データ（チャットメッセージ）の追跡とデータの所在

ユーザーがDifyアプリケーションにチャットメッセージを入力した際に、そのデータがどのようにシステムを通過し、どこに存在するのかを順を追って説明いたします。表の後にダイアグラムを示しました。具体的なフローのイメージはそちらをご覧ください。また、利用するサービスは要件次第で異なります。あくまで一例ですので、ご注意ください。

順番	サービス名	データの所在	セキュリティ	VPC（内/外）
1	ユーザーのブラウザ	ユーザーのローカルデバイスのブラウザ	HTTPS(TLS/SSL)	外
2	ALB	VPC内のパブリックサブネットに配置されたALBのメモリ上で、バックエンドへルーティングされるまでの間、一時的に存在します。	HTTPSリスナーを設定し、通信を暗号化。セキュリティグループでアクセスを制御。	内
3	Amazon EKS	VPC内のプライベートサブネットにデプロイされたEKSクラスター上のPod内で、アプリケーションデータはメモリおよび一時ストレージに保持されます。永続データはRDSやS3へ接続されます。	セキュリティグループとIAMロール（IRSA）でアクセス制御。KubernetesのRBACで権限を管理し、Pod間通信はNetworkPolicyで制限可能。	内
4	ElastiCache for Redis	VPC内のプライベートサブネットに配置されたRedisクラスターのメモリ上。セッション情報や、チャットの文脈情報、プロンプトテンプレート、頻繁にアクセスする中間データなど、一時的なキャッシュデータが保存される可能性があります。ユーザーの入力データそのものが永続的に保存されることはありません。	プライベートサブネットに配置。保管時の暗号化 (Encryption at Rest) および転送時の暗号化 (Encryption in Transit) をサポート。	内
5	RDS Aurora Postgres Cluster	VPC内のプライベートサブネットに配置されたAuroraデータベースクラスターの永続ストレージ上。	プライベートサブネットに配置。IAMデータベース認証の利用。保管時の暗号化 (AWS KMSを利用した透過的データ暗号化)。転送時の暗号化 (SSL/TLS)。	内
6	Secrets Manager	AWSによって管理されるセキュアなストレージ上。外部LLMプロバイダーやエンベディングAPIのAPIキーなどの機密情報が保存されます。ユーザーの入力データはここには保存されません。	保管時の暗号化 (AWS KMSを利用)。IAMによるアクセス制御。	外
7	NAT Gateway	プライベートサブネットのECS Fargateタスクが外部API（エンベディングAPI、LLMプロバイダー）にアクセスする際、ユーザー入力データ（またはそれを含むプロンプト）が一時的にNAT Gatewayを通過します。NAT Gateway自体はデータを保持しません。	プライベートサブネットのリソースがインターネットへアウトバウンド通信する際の出口となり、外部からの直接的なインバウンドアクセスを防ぎます。	内
8	外部LLMプロバイダー / エンベディングAPI	各プロバイダーのサーバー上。ユーザーの入力データ（またはそれを含むプロンプト、エンベディング対象のテキスト）がAPIリクエストとして送信され、処理されます。	HTTPS(TLS/SSL)。各プロバイダーのセキュリティポリシーと契約条件に従います。データの取り扱いについては、利用するプロバイダーのドキュメントを確認することが重要です。	外
9	S3	AWSによって管理されるオブジェクトストレージ上。アップロードされたドキュメント (ナレッジベース用)	バケットポリシーやIAMポリシーによるアクセス制御。保管時の暗号化 (SSE-S3, SSE-KMSなど)。転送時の暗号化 (HTTPS)。バージョニングやアクセスログ。	外

ダイアグラム

改めて、本ダイアグラムは この特定のサービス構成に基づいたものであることを明記しておきます。この構成では Amazon EKS（Elastic Kubernetes Service） を使用していますが、Amazon ECS（Elastic Container Service） や EC2（Elastic Compute Cloud）でも構成できます。それぞれの特徴は以下の通りです。

• Amazon EKS
  • EKSは、KubernetesをAWS上でマネージドで運用できるサービスで、柔軟な構成やマルチコンテナ環境に対応できます。Kubernetes標準に従っているため、他クラウドやオンプレからの移行性にも優れています。
• Amazon ECS
  • ECSは、AWS独自のコンテナオーケストレーションサービスで、Dockerコンテナを簡単にデプロイ・管理できます。Fargateと組み合わせればインフラ管理不要で運用できますが、Kubernetesのような標準的なツールとの互換性はありません。
• Amazon EC2
  • EC2は、仮想サーバー（インスタンス）を自由に構築・管理できるサービスで、OS・ミドルウェア・アプリケーションまでフルカスタマイズが可能です。柔軟性が高い反面、サーバーの起動・監視・スケーリングなどを自前で管理する必要があります。

それぞれのサービスには異なる特徴と利点があり、どれが最適かはシステムの用途や運用体制、セキュリティ要件、スケーラビリティのニーズによって異なります。構築にあたっては、それぞれの特性を理解したうえで、サービスの性質やセキュリティ要件と照らし合わせて柔軟に選択・設計することが重要です。

データの所在とセキュリティのポイント（まとめ）

Dify on AWSにおけるデータセキュリティは、以下の主要なポイントで強化されています。

• VPC内での処理: ユーザー入力データの主要な処理（APIロジック、RAG処理、データベースへの保存）は、セキュリティグループやNACLで保護されたVPC内のプライベートサブネットで行われます。これにより、インターネットからの直接的な脅威を大幅に軽減します。
• 外部との通信の保護:
  • ユーザーとの通信は HTTPS で暗号化され、CloudFrontとWAFによって保護されます。
  • 外部API（LLMプロバイダーなど）との通信も、NAT Gateway経由でセキュアなHTTPSで行われます。NAT Gatewayはプライベートサブネットのリソースを保護しつつ、必要なアウトバウンド通信のみを許可します。
• データの永続化と暗号化: 会話履歴やベクトルデータは、VPC内の RDS Aurora Postgres Cluster に暗号化されて保存されます。ナレッジベース用のドキュメントは S3 に暗号化されて保存できます。
• 機密情報の安全な管理: APIキーなどの認証情報は Secrets Manager で安全に管理・利用されます。
• 厳格なアクセス制御: 各AWSサービスへのアクセスは IAMロール や ポリシー、セキュリティグループ によって最小権限の原則に基づいて厳密に制御されます。

利用ログの確認

Difyアプリケーションの利用状況やデータの流れを確認するためのログは、以下の方法で参照できます。

• RDS Aurora Postgres Cluster: SQLクエリを実行することで会話履歴を参照できます。
• Amazon CloudWatch Logs: ECS Fargateで稼働するDifyアプリケーションのログや、ALBのアクセスログなどを集約・分析できます。
• Difyアプリケーション内のログコンソール: Dify自体が提供する管理画面から、アプリケーションレベルのログを確認できる場合があります。

APIデータとプライバシー

ここでは外部プロバイダーを用いたAPI経由でのデータの送受信において、クラウドプロバイダー経由（AWS Bedrock）とLLM提供企業から直接やり取りする場合を比較して、データがどのように扱われるかを深堀ります。

比較項目	クラウドプロバイダー経由（Amazon Bedrock）	LLM提供企業から直接
入力データのモデル学習への利用	顧客のコンテンツは、基盤モデルの改善やトレーニングには使用されないことを明記。顧客は自身のデータを制御できる。	OpenAI API: 2023年3月1日以降、API経由で送信されたデータは、OpenAIのモデル学習には利用者から自身のデータの開示について明示的にオプトインされた場合以外デフォルトで使用されない。顧客は、データ保持ポリシー（デフォルトで30日間）を選択できる。 Anthropic API: API経由で送信された顧客データは、Anthropicのモデル学習には使用されない。
データの保存場所・期間	顧客が選択したリージョン内にデータが保存されることが基本。保存期間はサービスや設定により異なる。顧客側でデータのライフサイクル管理が可能。	サービス提供企業のポリシーに従う。データの処理・保存場所は限定される場合がある。OpenAI APIでは30日間のデータ保持がデフォルト（ゼロデータ保持をリクエスト可能）。Anthropicも同様に短期的な保持ポリシーを持つ。
データ暗号化	保存時および転送中のデータ暗号化をサポート（例: AWS KMS, Azure Key Vault, Google Cloud KMS）。顧客管理の暗号鍵（CMK）を利用できる場合が多い。	保存時および転送中のデータ暗号化（TLS、AES-256など）を実施。
データ処理契約 (DPA)	GDPRなどの規制に対応するため、標準的なデータ処理契約（DPA）を提供。	GDPRなどの規制に対応するため、標準的なデータ処理契約（DPA）を提供。

まとめ

本記事では、AWS上にセルフホストされたDifyのアーキテクチャに基づき、ユーザーの機密データやナレッジデータがシステム内でどのように扱われ、どのようなセキュリティ対策が講じられているかを詳細に掘り下げてきました。

AWSは「責任共有モデル」を掲げており、クラウド自体のセキュリティ（AWSのインフラ）はAWSが責任を負いますが、クラウド内のセキュリティ（AWSユーザーが構築・運用するリソース）は私たちAWSユーザー自身の責任となります。 Dify on AWS環境におけるVPC内のセキュリティグループ、ネットワークACL、IAMロールの設定などは、まさにこの「AWSユーザーの責任範囲」に該当します。

Dify on AWSの環境は、適切な設定と運用をしっかりと行えば、高度なセキュリティ対策が施された上でセキュアに運用できるように設計されています。本記事で解説したVPC内のセキュリティ対策については、十分注意を払い、常に最新のベストプラクティスに従って設定・運用することが不可欠です。

Dify on AWSは、AIアプリケーション開発に高い柔軟性を提供しますが、そのセキュリティは適切な設計と運用にかかっています。本記事で得た知識が、皆さんの安全でスケーラブルなAIアプリケーション運用の一助となれば幸いです。

参考

https://aws.amazon.com/jp/products/?aws-products-all.sort-by=item.additionalFields.productNameLowercase&aws-products-all.sort-order=asc&awsf.re%3AInvent=*all&awsf.Free Tier Type=*all&awsf.tech-category=*all
https://aws.amazon.com/compliance/data-privacy-faq/
https://openai.com/policies/api-data-usage-policies
https://privacy.anthropic.com/en/articles/7996868-is-my-data-used-for-model-training
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
dify on awsアーキテクチャ(AWS JAPAN)：https://github.com/aws-samples/dify-self-hosted-on-aws/blob/main/imgs/architecture.png

dify on awsアーキテクチャ(Langgenius)：https://github.com/langgenius/aws-cdk-for-dify

書籍「AWSで始めるインフラ構築入門 第2版 安全で堅牢な本番環境のつくり方」：https://www.amazon.co.jp