🔸 DefectDojo Pro(オンプレミス) on DefectDojo Documentation

セルフホスト型 DefectDojo Pro のハードウェアサイジング

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojo デプロイのサイジングは、突き詰めると2つの問いに集約されます。どれだけのデータを保持しているか、そして同時に何人がその中で作業しているか、です。このページでは、その両方について出発点となる目安を示します。

以下の内容は仕様ではなく、一般的なガイダンスとして扱ってください。数値は意図的に保守的に見積もっており、日常的なトリアージと定期的なスキャンインポートを並行して行うデプロイを想定しています。実際の数値は製品の使い方によって変わりますので、何かを準備する前に、表の下にある注記を読んでください。

スペックは、どのクラウドプロバイダーやオンプレミスのハードウェアにも当てはまるよう、汎用的な vCPU とメモリの数値で示しています。アプリケーションノードのガイダンスは Kubernetes を前提としています。単一ホストで Docker Compose を実行する場合は、同じ合計値を使用してください。

サイジング表

検出事項	同時ユーザー数	データベース	アプリケーションノード
10万件まで	約25人まで	2–4 vCPU / 16–32 GB	2 × (2–4 vCPU / 8–16 GB)
10万〜50万件	約25〜50人	4–8 vCPU / 32–64 GB	2–3 × (4 vCPU / 16 GB)
50万〜100万件	約50〜100人	8 vCPU / 64–96 GB	2–3 × (8 vCPU / 32 GB)
100万〜500万件	約100〜250人	8–16 vCPU / 96–128 GB	5–6 × (8 vCPU / 32 GB)
500万〜1,000万件	約250〜500人	16–32 vCPU / 128–192 GB	9–10 × (8 vCPU / 32 GB)
5億件	500人以上	192 vCPU / 768 GB 以上	50 台以上 × (8 vCPU / 32 GB)

範囲のどのあたりに位置するかは、ワークロードによって異なります。どのような場合に上位のティアが必要になるかに該当する項目がある場合は、範囲の上限側から始めてください。

DefectDojo Proのセルフホスティング

Tue, 02 Feb 2021 20:46:29 +0100

DefectDojo Proは、お客様自身の環境に完全にセルフホストでき、インフラ、データ、セキュリティ体制を自社で管理できます。ホスト型デプロイを除外するコンプライアンス、データレジデンシー、社内セキュリティ要件を持つ組織に適しており、クラウドホスト版の製品と同じ機能を提供します。

このページでは、利用可能なデプロイモデル、開始前に必要なもの、このセクションの他のページとの関係について説明します。

二つのデプロイモデル

単一ホスト上のDocker Composeは、二つのうちよりシンプルな方法です。アプリケーション、非同期ワーカー、キャッシュはすべて一台のマシン上で動作し、弊社が提供するコマンドラインツールで管理します。この構成はスケールアウトしないため、ホストは平均値ではなくピーク値に合わせてサイズを決める必要があり、多くのデプロイではそのピークはUIで作業しているユーザーがいる最中に大規模なスキャンインポートが到着する場合です。

Helmチャートを使用したKubernetesは、同じコンポーネントを個別のワークロードとして実行します。これにより定常状態に合わせてプロビジョニングし、負荷が来たときにレプリカを追加でき、マシン全体ではなく実際にビジーな部分だけをスケールできます。

どちらのモデルもPostgreSQLを使用します。本番環境では、Helmチャートがデフォルトで想定している外部の管理型データベースを推奨します。Composeツールはアプリケーションと並んでコンテナ内でPostgreSQLを実行することもでき、これは評価用には便利ですが、本番データには適していません。

すでにKubernetesを運用しているなら、それを使ってください。単一ホストでも問題なく動作し、多くのデプロイがその方式で運用されていますが、再配分できない余剰キャパシティを購入することになります。Kubernetesを運用しておらず、導入したくもない場合、Composeは妥協案ではなく正当な選択肢です。

開始前に

まずデプロイのサイズを決めてください。どちらのモデルも、保持を見込む検出事項の件数と、同時に製品を利用する人数のおおよその見当が必要で、この二つの数値がデプロイの異なる部分を左右します。このセクションのハードウェアサイジングのガイダンスでは、両方について説明しています。

選択したモデル用のライセンスファイルとデプロイツールが必要です。DefectDojoはサブスクリプション開始時に両方を提供します。お持ちでない場合、または再発行が必要な場合は、アカウント担当者またはまでご連絡ください。

また、実行する場所、到達可能なPostgreSQLデータベース、デプロイ先を解決するホスト名も必要です。個々のインストールページで、各モデルの詳細を説明しています。

このセクションのその他の内容

このページに関連するページでは、ライフサイクルの残りの部分を扱っています。ハードウェア選定のためのサイジングガイダンス、既存のオープンソースインスタンスをセルフホスト型Proデプロイに移行する手順、対象ホストがインターネットに接続できない環境でのインストール手順があります。

FIPS 140-3 モード

Mon, 27 Jul 2026 00:00:00 +0000

DefectDojo Pro は、FedRAMP の統制SC-13または同様の要件が適用される環境向けに、FIPS 140-3 で検証された暗号技術を用いてデプロイできます。

FIPS モードは、-fips というタグサフィックスで識別される別のコンテナイメージ一式として提供されます。標準イメージは変更されません。FIPS の有効化は明示的な選択であり、暗黙のデフォルトになることはありません。

FIPS イメージへのアクセスについては、までお問い合わせください。

FIPS イメージが提供するもの

すべての暗号処理は、FIPS 140-3 のもとで NIST CMVP 証明書**#4985を保持するOpenSSL FIPS Provider 3.1.2によって実行されます。Go 製のサービスは、CMVP 証明書#5247を持つGo Cryptographic Module v1.0.0**を使用します。

オープンソースからセルフホスト型DefectDojo Proへの移行

Mon, 01 Jan 0001 00:00:00 +0000

このページでは、オープンソース版DefectDojoインスタンスのデータをセルフホスト型DefectDojo Proのデプロイメントに移行する方法について説明します。

以下の例では、Amazon Web Servicesを使用し、EC2上のDocker ComposeまたはEKS上のKubernetesのいずれかと、Amazon RDS for PostgreSQLのデータベースを組み合わせています。この手順は、この組み合わせに対して検証されています。マネージドPostgreSQLと同等のコンピューティングを提供する他のプロバイダーや、オンプレミスのハードウェアにも、プロバイダー固有のコマンドを適宜変更すれば同じ手順を適用できます。

デプロイメントはお客様自身がホストするため、移行作業全体を通してデータはお客様自身の環境内にとどまります。エクスポートとリストアはお客様自身が実行しますが、DefectDojoサポートはどのステップでも支援できます。DefectDojo Proインスタンスがセルフホストではなく、DefectDojoによってクラウドホストされている場合は、代わりにまでご連絡ください。その場合はDefectDojoチームがリストアを代行します。

大まかな流れとしては、オープンソースインスタンスからデータベースとメディアファイルをエクスポートし、Proデプロイメントが使用するデータベースとストレージにリストアし、Proをリストア済みのデータベースに向けて設定した後、結果を検証します。

開始前に

エクスポートを行う前に、以下の点を確認してください。

データベースエンジン。DefectDojoはPostgreSQLをサポートしています。MySQLのサポートは非推奨となった後、2.37.0で削除されました。そのため、MySQLで稼働している古いインスタンスは、移行前にPostgreSQLへ変換する必要があります。該当する場合はサポートにお問い合わせください。

DefectDojo Pro(オンプレミス)のアップグレード

Mon, 01 Jan 0001 00:00:00 +0000

このページでは、DefectDojo Pro Helmチャートを使用するセルフホスト型DefectDojo Proデプロイメントのサポートされるアップグレード手順について説明します。

すべてを一つの単位としてアップグレードする

各DefectDojo Proリリースは、Helmチャートのバージョン、コンテナイメージのバージョン、Pro設定ファイルで構成されています。これらは一緒にビルド・テストされているため、一つの単位として一緒にアップグレードする必要があります。

イメージタグのみをアップグレードすることはサポートされておらず、デプロイメントが破損します。

設定ファイルとアップグレード

DefectDojo Proは、すべてのリリースにpro_settings.pyファイルを同梱しており、このファイルはほぼすべてのバージョンで変更されます。アップグレード時にpro_settings.pyの以前のコピーを引き継いだり、古いコピーを手動でパッチしたりしないでください。アプリケーションは、常にそのバージョンに対応するpro_settings.pyを実行する必要があります。

独自のカスタマイズは、pro_settings.pyではなく必ずlocal_settings.pyに記述してください。local_settings.pyはアップグレード時にも保持されます。

Helmチャートは、対応するpro_settings.pyとお客様のlocal_settings.pyを同梱し、自動的にマウントします。チャートを使用してアップグレードする場合、手動でコピーや移行を行う必要はありません。

サポートされるアップグレード手順

移行先のバージョンだけでなく、現在のバージョンから移行先のバージョンまでの間にあるすべてのバージョンのリリースノートを確認してください。DefectDojo Pro変更履歴およびバージョン別のアップグレードノートを参照してください。
データベースをバックアップします。
既存の値ファイルを再利用しながら、移行先のアプリケーションバージョンに対応するHelmチャートのリリースにアップグレードします。チャートのバージョンとは無関係にイメージタグを変更しないでください。

オンプレミスデプロイメントのアップグレードについてご質問がある場合は、までご連絡ください。

OpenShiftへのDefectDojo Proのデプロイ

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojo Proは、OpenShift Container Platform、ROSA、OKDを含むOpenShift 4.x上で動作します。

このページは、DefectDojo Proのライセンスに付属するインストールガイドを補足するものです。インストールガイドには、OpenShift専用のセクションを含む完全な手順が記載されています。このページでは、OpenShiftに特有の相違点を説明し、開始前に準備すべきものと、プラットフォーム固有の設定に関して何を期待すべきかを示します。

ライセンス資料には、OpenShiftブートストラップスクリプトが同梱されています。このスクリプトは既存のクラスターにインストールを行い、ストレージ、fsGroupの値、Route、インストール自体など、このページで説明する内容の大部分を処理します。冪等性があるため、再実行してもすでに作成済みのものが再利用され、また実際には何も変更せずに実行内容を表示するドライランにも対応しています。このページの残りの内容は、このスクリプトを使用する場合でも、ご自身でインストールを実行する場合でも当てはまります。

セキュリティコンテキスト制約

DefectDojo Proは、デフォルトのrestricted-v2 SCCの下で動作します。サービスアカウントにanyuid、privileged、その他の昇格されたSCCを付与する必要はありません。

OpenShift向けに構成すると、DefectDojo Proは全体を通して非特権のセキュリティコンテキストで動作します。コンテナは特権なしで実行され、権限昇格はできず、すべてのcapabilityがドロップされます。ユーザーIDは、SCCが拒否するような固定UIDに固定するのではなく、名前空間に割り当てられた範囲からOpenShiftが割り当てるようになっています。

ポッドがSCC検証に失敗して拒否される場合、通常の原因は制約の付与が必要なことではなく、デプロイメントがOpenShift向けに構成されていないことです。

ストレージはReadWriteManyである必要がある

DjangoポッドとCeleryワーカーポッドは、アップロードされたスキャン結果、スクリーンショット、生成されたレポートといった同じメディアファイルを読み書きします。これらには共有ボリュームが必要なため、マルチノードデプロイメントではReadWriteOnceストレージでは不十分です。

OpenShiftのデフォルトは、クラスターのデフォルトStorageClassに対するPersistentVolumeClaimです。デフォルトのクラスがReadWriteManyをプロビジョニングする場合はこれで機能します。これはOpenShift Data FoundationまたはNFSを基盤とするクラスターでは一般的です。デフォルトのクラスがReadWriteOnceであるマルチノードデプロイメントでは、代わりにNFSベースのストレージを構成してください。

エアギャップ環境への DefectDojo Pro のインストール

Mon, 01 Jan 0001 00:00:00 +0000

このページは、DefectDojo Pro のライセンスに付属するインストール手順を補足するものです。対象ホストがインターネットに接続できない場合に変更が必要となる点のみを扱います。ホストの前提条件や PostgreSQL のセットアップを含め、それ以外はすべて標準の手順に従います。

この方法では、2 台のホストを使用します。通常どおりインターネットに接続できるステージングホストで、デプロイ用アーティファクトとコンテナイメージをダウンロードします。次に、環境で許可されている任意の転送方法でそれらのアーティファクトをエアギャップ環境のネットワークに移動し、DefectDojo へのネットワークアクセスがない対象ホスト上でインストールを完了します。

ステージングホストは後で再び使用できるように用意しておいてください。アップグレード時にも同じ転送作業を繰り返すため、残しておく価値があります。

必要なもの

ステージングホストには、インターネットに接続できる Linux ホスト、Docker のインストール、そしてデプロイディレクトリと圧縮されたコンテナイメージ用の十分な空きディスク容量が必要です。容量の大部分はイメージが占め、1 つあたり数百メガバイトになります。

エアギャップホストには、Docker がインストールされ正常に動作していること、そしてすでにプロビジョニングされ到達可能な PostgreSQL サーバーが必要です。いずれも標準のインストール手順に従ってください。

両方のホストに、DefectDojo から提供された dojo-compose-cli アーカイブとライセンスファイルのコピーが必要です。CLI バージョン 2.1.0 以降を使用してください。それより前のバージョンにはエアギャップモードがなく、これがないと CLI はコマンドを実行するたびにコンテナレジストリへの接続を試み、問題の内容を伝えることなく名前解決エラーで失敗します。

大きなスキャンファイルのアップロードサイズ制限

Mon, 01 Jan 0001 00:00:00 +0000

大きなスキャンファイルは、リクエスト経路上の複数の異なる箇所にある制限のいずれかによって拒否されることがあり、表示されるエラーによってどの制限に達したかがわかります。このページでは、それらの制限がどこにあるか、そしてセルフホスト型デプロイでそれらを引き上げる方法について説明します。

どの制限に達しているか

表示される内容	発生元
装飾のない、DefectDojo のページを伴わない単純な `413 Request Entity Too Large`	ingress コントローラーが、リクエストがアプリケーションに到達する前に拒否した
`Report file is too large. Maximum supported size is N MB`	DefectDojo 自身が報告するアプリケーション側の制限
アップロードがすぐに拒否されるのではなく、しばらく実行された後で失敗する	サイズ制限ではなくタイムアウト

外側から内側に向かって対応してください。ingress コントローラーが先にリクエストを拒否している場合、アプリケーション側の制限を引き上げても意味がありません。

アップロードファイル用のストレージの追加

Mon, 01 Jan 0001 00:00:00 +0000

アップロードされたファイルはホスト上のmediaディレクトリに保存され、Docker Composeデプロイメントでは、それらに利用できる容量はVMのディスクの残り容量に依存します。SBOMのような大きなアップロードは、そのディスクを満杯にしてしまうことがあります。このページでは、デプロイ自体を変更することなく容量を拡張する方法について説明します。

OSレベルで対応できる理由

Docker Composeデプロイメントは、ホストのmediaディレクトリを、それを必要とするコンテナ(アプリケーションコンテナと、アップロードされたファイルをユーザーに返すnginxの両方)にバインドマウントします。コンテナはホスト上のパスに対して読み書きを行うため、そのパスにマウントされているファイルシステムが実際に使用されるものになります。そこにより大きな容量をマウントしても、アプリケーションからは透過的です。

そのため、ここで紹介するアプローチはデプロイメントの変更ではなく、オペレーティングシステムの変更となります。リリースに同梱されているComposeファイルを変更しないままにしておくことで、インストールを他のオンプレミスデプロイメントと一貫性のある状態に保つことができ、アップグレードでそのファイルが置き換えられた際に変更が失われることも回避できます。

ブロックストレージ:シンプルな選択肢

追加のブロックデバイスをマウントすることは、Linuxでディスクの満杯に対処する一般的な方法であり、まず最初に検討すべき選択肢です。NASやSANのボリュームでも機能しますし、Amazon EBSボリュームのようなクラウドプロバイダーのブロックストレージでも機能します。

アプリケーションのストレージをオペレーティングシステムのディスクから分離することは、一般的には良い実践です。したがって、妥当な選択肢は2つあります。デバイスをmediaディレクトリにマウントして、アップロードファイル専用の容量を確保する方法と、1階層上のデプロイメントディレクトリにマウントして、すべてのアプリケーションデータをVMとは別のファイルシステム上に配置する方法です。

オブジェクトストレージ(注意点あり)

Amazon S3のようなオブジェクトストレージでアップロードを支えることは可能であり、容量の上限を完全に取り払うことができますが、ブロックデバイスほど自然な適合ではありません。選択する前に、以下の点を検討してください。

オブジェクトストレージはファイルシステムではありません。S3はランダムな書き込み、既存ファイルへの追記、ファイルロックをサポートしていません。FUSEレイヤーがそのギャップを覆い隠しますが、それは基盤となるストアが本来持っていないセマンティクスをエミュレートしているに過ぎません。

レイテンシはブロックデバイスよりも高くなります。これはアップロードに影響しますし、nginxが同じディレクトリからアップロードされたファイルを配信するため、ダウンロードにも影響します。

ネットワーク依存関係が追加されます。VMがネットワーク内のどこに位置するかによっては、バケットに到達するために追加のネットワーク経路が必要になる場合があり、アップロードを機能させるにはそのパスが利用可能である必要があります。

再起動には注意が必要です。バケットは起動時にマウントする必要があり、これによりマウントの完了とDefectDojoの起動との間にタイミングの依存関係が生じます。レイテンシによっては、再起動がハングしたり、マウントがまだ準備できていない状態で起動してしまったりする可能性があります。

権限を一致させる必要があります。バケットのIAM権限は、アプリケーションがアップロードを書き込むために必要とするファイルシステムの権限と整合させる必要があります。

オブジェクトストレージをマウントするためのツール

Linux上でS3をファイルシステムとしてマウントするために、一般的に3つのツールが使用されます。

セルフホスト環境のバックアップ

Mon, 01 Jan 0001 00:00:00 +0000

デプロイはデータベースだけで成り立っているわけではありません。データベースのみを取得したバックアップを復元すると、システム自体は動作するものの、アップロードされたファイルが欠けており、他のツール用に保持している認証情報を復号できない状態になります。このページでは、何を取得すべきか、それぞれがどこに存在するか、そして復元結果が正しいことをどのように確認するかを説明します。

取得すべき 4 つの要素

データベースには、組織、アセット、エンゲージメント、テスト、検出事項、ユーザー、そして設定が保存されています。

アップロードされたファイルはデータベースの外部に存在します。スクリーンショット、脅威モデル、リスク受容ドキュメントなどの添付ファイルはファイルシステム上にあり、データベースにはそれらへのパスのみが保存されています。

デプロイの設定は、独自のカスタマイズや TLS 証明書を含め、アプリケーションを同じ状態で再度起動できるようにするものです。

暗号化キーは、最も見落とされがちな要素です。認証情報暗号化キーは、連携しているツールの保存済み認証情報を読み取り可能にするものです。これがないままデータベースを復元すると、認証情報自体は残っていても復号できなくなり、すべての連携を手動で入力し直す必要が生じます。

データベース

ほとんどのセルフホストデプロイは、チャートのデフォルトかつ推奨構成であるマネージド PostgreSQL サービスを利用します。この場合、独自にバックアップを構築するのではなく、プロバイダー自身の自動バックアップとポイントインタイムリカバリを使用してください。決め打ちにせず確認すべき点が 2 つあります。1 つは、インスタンス上で自動バックアップが実際に有効になっているかどうかです。バックアップが無効になっているマネージドデータベースにはバックアップが存在しません。もう 1 つは、保持期間が組織の要件に合っているかどうかです。

PostgreSQL を自分で運用している場合は、圧縮されたカスタム形式のダンプを取得します。