クラウドアーキテクチャ (Pro)
DefectDojo Cloud は、Google Cloud 上の Google Kubernetes Engine（GKE） で稼働するマルチテナント SaaS プラットフォームです。このページでは、 プラットフォームの構成と、顧客環境がどのように分離されているかについて説明します。
リクエストの流れ
- 顧客のトラフィック（ブラウザ、API、または CI）は HTTPS 経由で Google Cloud Load Balancing に到達し、そこで Google 管理の証明書を使用して TLS が 終端されます。
- ロードバランサーは、リクエストをリージョンごとの GKE クラスター内にある 顧客の環境にルーティングし、そこで web/API 層（django、nginx と uWSGI に よって配信）が処理します。
- web 層は、顧客の専用 PostgreSQL データベースと専用 Cloud Storage バケットの読み書きを行い、セッション管理とタスクブローカーとして ネームスペース内キャッシュ（Redis/Valkey）を使用します。
- スキャンのインポート、重複排除、通知といった時間のかかる処理は、リクエストの 応答性を保つために非同期ワーカー（Celery）に引き渡されます。
テナントの分離
すべての顧客は独自の Kubernetes ネームスペースで実行され、各顧客が保存する データが他の顧客とストアを共有することはありません。
- 専用データベース: 顧客ごとに独立した PostgreSQL データベース（Cloud SQL）。
- 専用オブジェクトストレージ: アップロードされたスキャンやメディア用に、 顧客ごとに独立した Cloud Storage バケットがあり、GCS FUSE CSI ドライバー 経由でワークロードにマウントされます。
- 専用キャッシュ: 各ネームスペースは独自の Redis/Valkey インスタンスを 実行します。
- 顧客ごとの認証情報: 各環境は、それぞれ独自のシークレット、TLS 証明書、 ホスト名を持ちます。
顧客間でアプリケーションデータプレーンが共有されることはありません。データは、 転送時（TLS）および保存時（Google Cloud のデフォルト暗号化）に暗号化されます。
リージョンとデータレジデンシー
このプラットフォームは、複数の地域にまたがるリージョンごとの GKE クラスター （たとえば北米、欧州、アジア太平洋）で稼働しています。顧客環境は、そのデータ ベースやストレージバケットとともに、その顧客のために選択されたリージョンに 配置されるため、データレジデンシー要件に対応できます。
顧客環境内のワークロード
各ネームスペースには、DefectDojo Pro をエンドツーエンドで実行するために必要な コンポーネントがすべて含まれています。
| グループ | 役割 |
|---|---|
| Web & API | UI と REST API を提供します（django・nginx + uWSGI）。 |
| 非同期処理 | バックグラウンドジョブとスケジューリング（Celery ワーカー + beat）。 |
| オーケストレーション | プラットフォーム全体にまたがる複数ステップのワークフローを調整します。 |
| インテグレーション | コネクターおよびチケッティング連携。 |
| MCP サーバー | 独自の AI ツールと連携するための AI インターフェース。 |
| Sensei | Google の Vertex Platform を通じた AI による修復。 |
| ネームスペース内キャッシュ | セッションおよびタスクブローカー用の Redis/Valkey。 |
各デプロイでは、短時間だけ存在するinitializer ジョブが、新しいバージョンが トラフィックを処理し始める前にデータベースマイグレーションを実行します。
Sensei と AI の分離
DefectDojo の AI による修復機能である Sensei は、Google の Vertex Platform を通じて稼働しており、データプレーンの他の部分と同様に顧客ごとに分離されて います。
- 各顧客の Sensei へのリクエストは、その顧客専用の GCP プロジェクト内で 実行され、顧客ごとの認証情報によって認証されます。
- AI テナンシーが共有されることはありません。ある顧客のプロンプト、検出事項、 結果が他の顧客の環境を経由することはありません。
- 外部の AI プロバイダーは、顧客が設定した場合にのみ使用されます （たとえば MCP サーバー経由、または顧客自身が用意した AI インテグレーション 経由など）。
プラットフォームサービスと運用
Google が管理する共有サービスが、テナント間で顧客データを持ち越すことなく、 すべての環境を支えています。
- Artifact Registry: 署名済みのコンテナイメージ。
- Secret Manager: シークレットおよび鍵材料。
- Cloud Monitoring & Logging: オンコールチームが使用するメトリクス、ログ、 アラート。ノードプールは負荷を吸収するためにオートスケールします。
顧客をまたいで共有されるデータは、公開されている脆弱性エンリッチメント情報 （EPSS および KEV）のみです。
インテグレーションはアウトバウンドのみ
メール（SMTP）、チケッティング（Jira、ServiceNow など）、セキュリティスキャナー、 エラーモニタリングといった外部システムへの接続は、顧客によって設定され、 顧客の環境からアウトバウンドで開始されます。
ティアごとの分離
| ティア | コンピュート | データベース | ネットワーク境界 | Sensei |
|---|---|---|---|---|
| Standard | 共有クラスター上の分離されたネームスペース | 共有 PostgreSQL インスタンス上の独自の論理データベースと認証情報 | 共有 VPC、テナントごとのホスト名 + TLS、任意の IP 許可リスト | 含まれる |
| Pay-as-you-go (近日提供予定) | 共有クラスター上の分離されたネームスペース | 共有 PostgreSQL インスタンス上の独自の論理データベースと認証情報 | 共有 VPC、テナントごとのホスト名 + TLS、任意の IP 許可リスト | 含まれる |
| Premium | 共有クラスター上の分離されたネームスペース | 顧客ごとの専用 PostgreSQL データベース | 共有 VPC、テナントごとのホスト名 + TLS、任意の IP 許可リスト | 含まれる |
| Dedicated | 独自の GKE クラスター | 顧客独自の VPC 内の専用 PostgreSQL データベース | 独自の GCP プロジェクトと VPC、顧客の IP 範囲に制限された ingress | 含まれる |
Sensei はすべてのティアに含まれており、いずれのティアでも、顧客自身の GCP プロジェクト内で Google の Vertex Platform を通じて、顧客ごとの認証情報を使って 稼働します。
このページで解決しないご質問がありますか？DefectDojo の担当者までお問い合わせ ください。