セキュリティ

Jinba Flowのセキュリティ方針と対策

​

概要

• データセンターの物理的または運用上のセキュリティーはAWS/GCPに準拠します
• ネットワーク通信はTLSプロトコルによる暗号化を実施し、DoS攻撃対策としてIDS/IPS、ファイアウォール、通信負荷分散を行っています
• 仮想化により、利用者間の情報を分離しています
• サービス利用者にはID/PW認証を実施しています
• ログは半年以上保持しています
• 年に一回以上の脆弱性診断を実施しています
• SOC2 Type1の監査を完了しています

​

システム構成

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月更新。