Databunker 0.8.37 介绍与选型指南

Databunker 是一个用 Go 编写的自托管个人数据（PII）保险库：应用把用户姓名、邮箱、电话、地址等敏感字段整条 JSON 记录交给它加密存储，自己的主库只保留一个 UUID 令牌。它内置了 GDPR/CCPA 合规所需的同意管理、审计留痕、被遗忘权与到期删除等工作流，并提供内置 Web 自助门户。本文基于官方仓库、官方文档与 Docker Hub 发布信息（查询日期 2026-11-03）梳理其定位、架构与选型边界，所有版本与量化数据均逐条溯源。

一、环境信息

二、软件概述

官方 README 对项目的定义原文（查询日期 2026-11-03）：

"Databunker is a self-hosted, GDPR compliant vault for personal data. Built in Go with privacy by design, it enables developers to securely store personal data, manage user consent and preferences for compliance with GDPR & CCPA."

仓库描述则更直白：Secure Vault for Customer PII/PHI/PCI/KYC Records——面向客户个人身份信息、健康信息、支付卡信息、KYC 记录的安全保险库。

与 HashiCorp Vault、AWS Secrets Manager 这类"存二进制机密"的保险库不同，Databunker 存的是整条个人记录（JSON）。官方架构文档（databunker.org/doc/architecture/）对此有明确区分：传统 vault 保管数据库密码、私钥、API 令牌等秘密值；Databunker 保管用户姓名、IP、密码、信用卡、健康信息等个人数据记录，并在加密前自动抽取 email、phone、login 字段构建哈希检索索引——即使攻击者拿到后端数据库，记录密文与检索索引都不可逆读。

项目现状有两个必须知道的事实：

1. 组织更名：仓库从 securityfirst/databunker 迁移到 securitybunker/databunker（README 首行徽章 renamed-by-github 为证），旧地址与旧 Docker Hub 路径已失效，选型与拉取都应使用新路径。
2. GitHub 无 Releases：releases 订阅源为空，官方以 Docker Hub 标签作为版本发布渠道，本批文档以 0.8.37（2026-10-30）为准。

产品线分两版：社区版（CE，Apache-2.0，本文主题） 与 Pro 版（在 CE 之上增加 PCI 卡号令牌化、加密文件存储、Shamir 密钥分片、作用域角色令牌、多租户等能力，文档见 docs.databunker.org/pro）。CE 版功能完整可独立生产使用，Pro 为商业增强。

三、核心架构

以下架构事实逐条核对自 0.8.37 源码（src/ 目录）与部署实测。

3.1 进程与接口

• Go 单进程 HTTP 服务，路由基于 julienschmidt/httprouter，默认监听 0.0.0.0:3000。
• 内置 Web 自助门户（GET / 返回登录页），业务全部走 REST API（/v1/...），认证头为 X-Bunker-Token。
• 二进制无 CLI 子命令体系，仅有启动/初始化参数：-init（建表并生成主密钥/根令牌）、-demoinit、-start、-db、-conf、-masterkey、-roottoken、-version。

3.2 存储后端三选一

选择逻辑在 src/storage.go 的 initStorage()：先判 MYSQL_HOST，再判 PGSQL_HOST，都没有则回落 SQLite。

3.3 加密设计（源码级）

• 记录数据列为 AES-256-GCM 密文（base64 存储）。密钥由两部分拼接：24 字节主密钥（DATABUNKER_MASTERKEY，48 个 hex 字符，缺失时 -init 自动生成并打印）+ 每条记录独立的 8 字节记录密钥（创建时随机生成，存于 users.key 列）。即 key = masterKey(24B) || recordKey(8B)，12 字节 nonce 附在密文尾部（src/utils/cryptor.go）。
• 检索索引列（loginidx/emailidx/phoneidx/customidx）为 base64(SHA-256(salt + 归一化值))，salt 由主密钥派生（src/utils/utils.go 的 HashString()），数据库层面不可逆。
• md5 列仅作数据一致性校验，源码注释明确标注 non-cryptographic checksum，不承担安全职能。
• 登录验证码（captcha）同样以主密钥派生的 AES-GCM 加密随机 6 位数字，有效期 120 秒。

3.4 数据模型

初始化建 10 张业务表（实测 \dt）：users（主记录）、userapps（应用数据域）、sessions（会话）、agreements/legalbasis（同意与法律依据）、processingactivities（处理活动）、requests（GDPR 请求工作流）、sharedrecords（可分享记录）、audit（审计）、xtokens（临时访问令牌）。

3.5 访问控制与登录流

• 根令牌（root token）：-init 时由 DATABUNKER_ROOTTOKEN 提供或自动生成，是管理面 API 的凭据，官方 Compose 将其存于 .env/databunker-root.env。
• xtoken：用户经"验证码登录"流程换取的临时令牌，作用域仅限本人记录（实测用 xtoken 读他人记录返回 Access denied）。
• 登录链路：GET / 签发 captcha 串 → GET /v1/captcha/:code 渲染验证码图 → GET /v1/prelogin/:mode/:identity/:code/:captcha → 邮件/短信下发一次性验证码 → GET /v1/login/:mode/:identity/:tmp 换取 xtoken。邮件/短信依赖外部 SMTP/SMS 网关，未配置时仅演示账号可用（固定验证码 4444）。

四、功能特性

• GDPR/CCPA 合规工作流：同意管理（接受/撤回/定时撤回）、DPO/管理员审批工作流（requests）、被遗忘权（forget me）、记录到期自动删除（exp 倒计时）、审计留痕（每次 API 操作落 audit 表，可用 disable_audit 关闭）。
• 多域数据模型：一条用户主记录之外，可按应用维度挂 userapps 数据域（如 webshop 的地址簿），会话与设备指纹入 sessions，可生成匿名可分享的 sharedrecords 链接。
• 令牌化检索：按 token/login/email/phone/custom 五种方式定位记录，主库无需保存任何 PII 明文。
• 内置 Web 门户：登录、自助改密、GDPR 请求提交开箱即用，支持自定义 logo/条款链接/CSS。
• 官方性能数据（databunker.org/doc/benchmark/，查询日期 2026-11-03）：AWS EKS t3.xlarge + RDS db.t3.xlarge 单节点组合稳定 347 请求/秒（100 并发线程写入 100 万条记录耗时 48 分钟）；t3.medium 组合 280 请求/秒；DigitalOcean 1 GB RAM/1 vCPU 全栈单机（含 Node.js 应用层）155 请求/秒。
• 运维接口：GET /v1/status 健康检查（官方 Dockerfile HEALTHCHECK 即用此端点）、GET /v1/metrics Prometheus 指标、GET /v1/sys/backup 备份导出（仅 SQLite 后端有内容，见第七节限制）。

五、快速开始（官方文档口径）

官方安装指南给出四种方法（databunker.org/doc/install/，查询日期 2026-11-03）。最简体验形态为单条命令拉起内置 SQLite 的演示实例：

DATABUNKER_MASTERKEY=`< /dev/urandom LC_CTYPE=C tr -dc 'a-f0-9' | head -c${1:-48};`
echo "DATABUNKER_MASTERKEY value is $DATABUNKER_MASTERKEY"
docker run -p 3000:3000 -d -e DATABUNKER_MASTERKEY=$DATABUNKER_MASTERKEY --name databunker securitybunker/databunker demo

官方明确标注该形态仅供体验（使用 DEMO 作为根令牌、数据落本地 SQLite），生产环境应使用 MySQL/PostgreSQL 后端，官方推荐 Docker Compose 一键编排（docker-compose-pgsql.yml + 密钥生成脚本），完整实测步骤见本专栏部署指南。

六、适用场景与限制

适合：

1. SaaS/用户系统想把 PII 从业务主库剥离——主表只存 user_token（UUID），数据泄露面骤减；
2. 需要 PCI DSS/GDPR 审计时缩小数据范围——支付链路只接触令牌；
3. 需要开箱即用的同意管理、被遗忘权、审计留痕等工作流，不想自研合规后台；
4. 多语言技术栈——纯 HTTP API，官方提供 Node.js/Python 集成示例。

限制（实测与官方口径）：

1. 单实例架构：无内建集群/高可用，扩展依赖前置负载均衡与后端数据库能力；
2. CE 与 Pro 边界：加密文件存储、PCI 卡号令牌化、Shamir 密钥分片、作用域角色令牌、多租户为 Pro 功能；
3. 备份端点仅 SQLite 有效：实测 PostgreSQL 后端 GET /v1/sys/backup 返回 HTTP 200 且 0 字节，PostgreSQL/MySQL 的备份需直接用数据库工具（pg_dump 等）；
4. 批量导出接口默认关闭且非加密：list_users 默认 false；实测开启后 POST /v1/users 返回的 private 字段为 base64 编码明文（base64 只是编码不是加密），该接口应视为数据导出通道，生产环境慎用；
5. 登录验证码依赖外部网关：不配 SMTP/SMS 就只有演示账号可登录（Web 门户场景）；纯 API 场景用根令牌不受影响；
6. 版本跟踪渠道特殊：GitHub 无 Releases，需盯 Docker Hub 标签页。

七、同类选型对比

"隐私数据方案"是个宽泛的词，先把四个常被放在一起讨论的组件的定位摆清楚——它们解决的是四个不同层面的问题：

取舍结论：

• 要管密码：选 《Vaultwarden 介绍与选型指南》，Databunker 不是密码管理器；
• 要加密网盘文件：选 Cryptomator，它是终端侧工具，没有服务端 API；
• 要在既有 SQL 查询里透明加密字段：选 《Acra 介绍与选型指南》，应用代码几乎不改；但合规工作流（同意、被遗忘、审计）仍需自研；
• 要把 PII 整体搬出业务主库、用令牌引用，并自带 GDPR 工作流：Databunker 是四者中唯一对准这个场景的，也是本专栏的主题。

八、参考链接

• GitHub 仓库（定位、徽章、语言统计、许可证）：https://github.com/securitybunker/databunker （查询日期 2026-11-03）
• Docker Hub 发布标签（0.8.37，2026-10-30）：https://hub.docker.com/r/securitybunker/databunker/tags （查询日期 2026-11-03）
• 官方安装指南（四种部署方法、demo 命令原文）：https://databunker.org/doc/install/ （查询日期 2026-11-03）
• 官方架构文档（vault 定位区分、创建记录八步流程）：https://databunker.org/doc/architecture/ （查询日期 2026-11-03）
• 官方基准测试（347/280/155 req/s 数据）：https://databunker.org/doc/benchmark/ （查询日期 2026-11-03）
• Pro 版功能页（PCI 令牌化、文件存储、Shamir 密钥、作用域令牌）：https://databunker.org/sandbox/ 与 https://docs.databunker.org/pro/ （查询日期 2026-11-03）
• 星标与许可证徽章：https://img.shields.io/github/stars/securitybunker/databunker 、https://img.shields.io/github/stars/cryptomator/cryptomator 、https://img.shields.io/github/license/cryptomator/cryptomator （查询日期 2026-11-03）
• 官方安全评审：https://databunker.org/doc/security/ （查询日期 2026-11-03）