> ## Documentation Index > Fetch the complete documentation index at: https://docs.jinba.io/llms.txt > Use this file to discover all available pages before exploring further. # セキュリティ > Jinba Flowのセキュリティ方針と対策 ## 概要 * データセンターの物理的または運用上のセキュリティーはAWS/GCPに準拠します * ネットワーク通信はTLSプロトコルによる暗号化を実施し、DoS攻撃対策としてIDS/IPS、ファイアウォール、通信負荷分散を行っています * 仮想化により、利用者間の情報を分離しています * サービス利用者にはID/PW認証を実施しています * ログは半年以上保持しています * 年に一回以上の脆弱性診断を実施しています * SOC2 Type2の監査を完了しています ## システム構成 Jinba Flow と Jinba App はパブリッククラウド上（以下の例では AWS を使用。GCP・Azure もサポート）に、構造的には共通だが互いに独立した環境として展開されています。両プロダクトは以下のセキュリティパターンに従います： * **公開トラフィック**は Application Load Balancer（**ALB**）で TLS 終端され、その背後にあるアプリケーションコンテナが **ECS** 上で稼働します。Jinba Flow は API と Web を別コンテナとして運用し、Jinba App は両者を 1 つのコンテナに統合してデプロイします。 * **コンテナイメージ**はプライベートな **ECR** から取得します。API キーや OAuth トークンなどの機密情報はイメージに同梱されず、起動時に **AWS Secrets Manager** から取得されます。 * **永続データ**は **Amazon RDS**（リレーショナルデータ）と **Amazon S3**（ファイルストレージ）に保管されます。いずれも VPC 内のプライベートリソースで、アプリケーション層からのみアクセス可能です。 * **非同期・スケジュール実行**（Webhook や cron による Flow 実行など）は **Qstash** のバックグラウンドジョブキューを介して ALB にコールバックされます。 * 各コンテナの**監査ログ・運用ログ**は **CloudWatch** に集約され、保持・アラート・インシデント調査に利用されます。 ここで示している AWS 構成は代表的な一例です。同じアーキテクチャは **Google Cloud（GCP）** および **Microsoft Azure** でも、各クラウドのマネージドサービスを用いて構築できます。たとえば ECS は Cloud Run / GKE もしくは Container Apps / AKS、ECR は Artifact Registry もしくは Azure Container Registry、RDS は Cloud SQL もしくは Azure Database for PostgreSQL、S3 は Google Cloud Storage もしくは Azure Blob Storage、AWS Secrets Manager は Secret Manager もしくは Azure Key Vault、CloudWatch は Cloud Logging もしくは Azure Monitor で置き換えられます。プライベートネットワーク・実行時のみのシークレット取得・アプリケーション層からのみのデータアクセスといったセキュリティ境界は、いずれのクラウドでも同様に維持されます。 下の図は、両プロダクトの構成を並べて示したものです： システム構成図 > **注意**: この図は代表例として AWS 構成を示したものです。GCP・Azure 上での構成も同じパターンに従います。2025年8月更新。