🔸 DefectDojo Pro(本地部署) on DefectDojo Documentation

自托管 DefectDojo Pro 的硬件规模规划

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

为 DefectDojo 部署确定规模，归根结底取决于两个问题：您要保存多少数据，以及同时有多少人在使用它。本页针对这两个问题给出了起点建议。

请将以下内容视为一般性指导，而非规格说明。这些数字有意偏向保守，并假设该部署在进行日常分诊的同时，还会定期导入扫描结果。您自己的数字会随着产品使用方式的不同而变化，因此在配置任何资源之前，请先阅读表格下方的说明。

规格以通用的 vCPU 和内存数字给出，因此适用于任何云服务商或本地硬件。应用节点方面的建议假设使用 Kubernetes。如果您在单台主机上运行 Docker Compose，请使用相同的总量。

规模规划表

Findings	Concurrent users	Database	Application nodes
最多 100K	最多约 25	2–4 vCPU / 16–32 GB	2 × (2–4 vCPU / 8–16 GB)
100K–500K	约 25–50	4–8 vCPU / 32–64 GB	2–3 × (4 vCPU / 16 GB)
500K–1M	约 50–100	8 vCPU / 64–96 GB	2–3 × (8 vCPU / 32 GB)
1M–5M	约 100–250	8–16 vCPU / 96–128 GB	5–6 × (8 vCPU / 32 GB)
5M–10M	约 250–500	16–32 vCPU / 128–192 GB	9–10 × (8 vCPU / 32 GB)
500M	500+	192 vCPU / 768 GB+	50+ × (8 vCPU / 32 GB)

您在某个区间内具体落在哪个位置，取决于您的工作负载。如果有哪些因素会让您升到更高档位中的任何一项适用于您，请从该区间的较高端开始考虑。

自托管 DefectDojo Pro

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

DefectDojo Pro 可以完全自托管在您自己的环境中，让您掌控自己的基础设施、数据和安全态势。它适用于因合规性、数据驻留或内部安全要求而无法使用托管部署的组织，并且提供与云托管产品相同的功能。

本页介绍可用的部署模式、开始之前您需要准备的内容，以及本节其余部分的组织方式。

两种部署模式

在单台主机上使用 Docker Compose 是两种模式中较为简单的一种。应用程序、异步工作进程和缓存都运行在同一台机器上，由我们提供的命令行工具进行管理。由于这种方式中没有任何组件可以横向扩展，主机的规格必须按照峰值而非平均负载来配置，而对于大多数部署而言，峰值出现在有人正在使用界面的同时导入了大型扫描结果的时候。

使用我们的 Helm chart 部署 Kubernetes，会将这些相同的组件作为独立的工作负载运行。这样您就可以按稳定状态进行配置，并在负载到来时增加副本，还可以只扩展实际繁忙的部分，而不必扩展整台机器。

两种模式都使用 PostgreSQL。对于生产环境，我们建议使用外部托管数据库，这也是 Helm chart 默认的假设方式。Compose 工具也可以在容器中与应用程序一起运行 PostgreSQL，这对评估而言很方便，但不适合用于生产数据。

FIPS 140-3 模式

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

DefectDojo Pro 可以部署为使用经 FIPS 140-3 验证的加密技术，适用于受 FedRAMP 控制项 SC-13 或类似要求约束的环境。

FIPS 模式以一套独立的容器镜像形式发布，通过 -fips 标签后缀加以标识。标准镜像保持不变：启用 FIPS 是一项显式选择，绝不会成为静默的默认设置。

如需获取 FIPS 镜像，请通过联系我们。

从开源版迁移到自托管 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 Pro(本地部署)

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

本页介绍使用 DefectDojo Pro Helm chart 的自托管 DefectDojo Pro 部署所支持的升级流程。

将所有内容作为一个整体升级

每个 DefectDojo Pro 发行版都由 Helm chart 版本、容器镜像版本以及 Pro 设置文件组成。这些内容是一起构建和测试的,因此必须作为一个整体一起升级。

仅升级镜像标签是不受支持的,这样做会破坏您的部署。

在 OpenShift 上部署 DefectDojo Pro

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

DefectDojo Pro 可在 OpenShift 4.x 上运行,包括 OpenShift Container Platform、ROSA 和 OKD。

本页是对随 DefectDojo Pro 许可证提供的安装指南的补充。该指南包含完整的安装流程,其中有专门的 OpenShift 章节。本页介绍 OpenShift 特有的不同之处,以便您了解开始之前需要准备什么,以及这些平台特定设置会带来怎样的效果。

您的许可证材料中提供了一个 OpenShift 引导脚本。它会安装到现有集群中,并处理本页所述的大部分内容,包括存储、fsGroup 值、Route 以及安装本身。该脚本是幂等的,重复运行会复用其已创建的内容,并且支持演练模式,可打印将要执行的操作而不做任何实际更改。无论您使用该脚本还是自行执行安装,本页其余内容均适用。

在离线（气隙）环境中安装 DefectDojo Pro

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

本页是对 DefectDojo Pro 许可证随附的安装说明的补充。内容仅涉及目标主机无法访问互联网时需要更改的部分。其余部分，包括主机的前提条件和 PostgreSQL 设置，均遵循标准说明进行。

该方法使用两台主机。一台具备正常互联网访问权限的暂存主机（staging host）用于下载部署制品和容器镜像。随后，您通过环境所允许的任何传输方式，将这些制品转移到离线网络中，并在无法访问 DefectDojo 网络的目标主机上完成安装。

请规划让暂存主机日后仍可再次访问。升级过程会重复相同的传输流程，因此保留该主机是值得的。

What you need

在暂存主机上，需要一台具备互联网访问权限、已安装 Docker 的 Linux 主机，并具备足够的可用磁盘空间，用于存放部署目录以及压缩后的容器镜像。镜像占用了其中的大部分空间，每个镜像可达数百兆字节。

在离线（气隙）主机上，需要已安装并可正常运行的 Docker，以及一台已按标准安装说明预先配置好且可访问的 PostgreSQL 服务器。

大型扫描文件的上传大小限制

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

大型扫描文件可能会在请求路径的不同环节被多个限制中的任意一个拒绝，您收到的错误信息会告诉您具体触发了哪一个限制。本页说明这些限制分别位于何处，以及如何在自托管部署中调高它们。

我碰到的是哪个限制

您看到的现象	来源
纯粹的 `413 Request Entity Too Large`，没有任何样式，也没有 DefectDojo 页面包裹	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 部署中,可供这些文件使用的空间取决于虚拟机磁盘的剩余容量。诸如 SBOM 这类大型上传文件可能会占满该磁盘。本页介绍如何在不更改部署本身的情况下扩展该空间。

为何该方法在操作系统层面有效

Docker Compose 部署会将主机的 media 目录绑定挂载到需要它的容器中,包括应用程序容器以及负责向用户提供已上传文件的 nginx。这些容器读写的是主机上的一个路径,因此挂载在该路径上的任何文件系统都会被它们所使用。在该处挂载更多容量对应用程序而言是透明的。

这就是为什么此处采用的方法是操作系统层面的变更,而非部署层面的变更。保持随发行版附带的 Compose 文件不变,可以使您的安装与其他本地部署保持一致,并避免在升级替换该文件时丢失所做的更改。

块存储,最直接的选择

挂载额外的块设备是在 Linux 上处理磁盘已满问题的常见方式,也是应该首先考虑的选择。NAS 或 SAN 卷可以胜任,云服务提供商的块存储(如 Amazon EBS 卷)同样可以。

备份自托管部署

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

一个部署所包含的内容不仅仅是其数据库。如果备份只涵盖数据库，恢复后得到的系统虽然能够运行，却会缺少已上传的文件，并且无法解密其中保存的、用于连接其他工具的凭证。本页将介绍需要备份哪些内容、每部分内容分别位于何处，以及如何确认恢复结果是可用的。

The four things to capture

数据库中保存着您的组织、资产、测试活动（Engagements）、测试（Tests）、发现项（Findings）、用户以及各项配置。

已上传的文件保存在数据库之外。屏幕截图、威胁模型、风险接受（Risk Acceptance）文档等附件存储在文件系统中，数据库中只保存指向它们的路径。

部署配置决定了应用程序能否以相同方式重新启动，其中包括您自己的定制内容和 TLS 证书。

加密密钥是最容易被遗漏的一项内容。凭证加密密钥（credential encryption key）决定了您所连接工具的已存储凭证是否可读。如果在恢复数据库时缺少该密钥，这些凭证虽然完好无损，但无法解密，这意味着每一项集成都必须手动重新录入。

The database

大多数自托管部署都会指向一个托管型 PostgreSQL 服务，这也是 chart 的默认设置和推荐配置。在这种情况下，应使用服务提供方自带的自动备份和时间点恢复（point-in-time recovery）功能，而不是自行搭建备份方案。有两点值得实际核查，而不是想当然地假定：一是该实例是否确实已启用自动备份，因为如果托管数据库关闭了备份功能，就完全没有备份；二是备份保留期限是否符合您所在组织的要求。