Databasus 如何保障安全？

Databasus 打交道的都是敏感数据：

  • 它访问你的数据库；
  • 它执行备份（也就是复制一份数据）；
  • 它保存凭据，以便定期访问你的数据库；
  • 它把备份存入你的 S3 或其他云存储（如果你启用了）；

因此，达到企业级的安全性和可靠性是 Databasus 的头号任务。

为了确保：

  • 敏感数据绝不外泄，且始终加密；
  • 备份是加密的，即使有人在云存储里看到它们也毫无用处；
  • Databasus 根本不会获得数据库的写入或修改权限；
  • 所有操作都被记录，可供审计；

这些措施共同保护你的数据。众所周知，不存在 100% 安全的系统，但我们尽最大努力让它足够安全。即使遭到入侵， 也没有人能破坏你的数据。

Databasus 在三个层面保障安全：

  1. 敏感数据加密；
  2. 备份加密；
  3. 数据库只读访问。

第 1 层：敏感数据加密

Databasus 内部使用 PostgreSQL 数据库保存连接信息、配置， 以及通知渠道和存储（S3、Google Drive、Dropbox 等）的设置。

所有敏感数据都会加密。例如：

  • 密码
  • 令牌
  • 带密钥的 webhook

因此，Databasus 的数据库里只存哈希或加密后的值。加密使用 AES-256-GCM 算法。此外，即便已经加密， 这些值也从不通过 API 或界面暴露。

用于加密的密钥保存在本地存储（默认是 ./databasus-data/secret.key），不会出现在 数据库中。所以就算数据库被攻破，也拿不到敏感数据。

第 2 层：备份加密

每个备份文件在创建过程中即时加密。Databasus 使用 AES-256-GCM 加密算法，没有加密密钥就无法读取备份数据，任何篡改都会在 解密时被发现。

备份经过这条流水线：

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

每个备份都有独立的加密密钥，由以下部分派生：

  • 主密钥（保存在 ./databasus-data/secret.key）
  • 备份 ID
  • 随机盐（每个备份唯一）

结果：即使有人拿到了你的云存储（S3、Google Drive 等）的访问权限，没有你的主密钥也读不了备份。

第 3 层：数据库只读访问

Databasus 贯彻最小权限原则：创建备份只需要读权限， 永远不需要写权限。这样即使经由备份工具，你的数据库也不会 被意外或恶意地破坏。

接受数据库凭据之前，Databasus 会做三个层面的检查：

  1. 角色层面：确认该用户不是 superuser，也不能创建角色或数据库
  2. 数据库层面：确保没有 CREATE 或 TEMP 权限
  3. 表层面：确认没有任何写权限（INSERT、 UPDATE、DELETE、TRUNCATE 等）

三项检查全部通过，数据库用户才被认定为只读。只要发现任何 写权限，Databasus 都会警告你。

Databasus 还会帮你生成权限正确的只读用户：

  • 授予对当前及未来所有表的 SELECT 权限
  • 授予模式的 USAGE 权限（但不授予 CREATE）
  • 显式收回所有写权限

结果：即便 Databasus 被攻破、服务器被入侵、 密钥被盗、凭据被解密，攻击者也破坏不了你的数据库。

🛡️ 安全与可靠性工程

Databasus 处理敏感数据，所以防范漏洞、越权访问和数据泄露是 首要关注点。我们在系统的两侧都投入这方面的工作：代码本身 （权限检查、加密、谨慎处理机密）和围绕代码的基础设施 （依赖分析、CVE 响应、DevSecOps 实践）。下面这条流水线在 每次提交和 PR 上自动运行。任何单独一层都不够，但它们叠加 起来，能降低有漏洞的代码、不安全的依赖、损坏的镜像或无法 恢复的备份混进发布版本的概率。

静态分析

静态分析分几个独立环节运行。CodeQL 扫描整个代码库的安全 问题。CodeRabbit 审查每个 PR，并内联运行 gitleaks 扫描机密、运行 semgrep 检查安全规则。Dockerfile 和 CI 工作流还有额外的专属规则（固定 action 引用、最小权限、 可疑基础镜像），不安全的写法在合并之前就会被标记出来。

在这些逐 PR 的检查之上，OpenAI 的 Codex Security 会定期对整个代码库做更深入的审计。它是一个独立的程序， 能发现架构性和跨模块的问题，而这些是聚焦单个 PR 的扫描 会漏掉的。

依赖管理

Dependabot 对照 GitHub Advisory Database 监控我们所有的 依赖，CVE 公布后几分钟内就会浮出水面。更新要经过一段冷却期， 让刚发布的版本先经受住考验再被采用，这是针对供应链攻击等 恶意包事件的有意防御。

Dependency Review Action 会直接拦下任何引入 新的 HIGH 或 CRITICAL CVE 的 PR。

容器与 CI 加固

  • 每次构建都用 Trivy 扫描容器镜像。
  • 另有一轮 Trivy 检查 Dockerfile，把配置错误挡在镜像 之外。
  • 所有 GitHub Actions 都固定到完整的 commit SHA，而不是 @v4 或 @main 这类浮动标签，后者在 2025 年是活跃的攻击途径。
  • 工作流默认最小权限，只在确有必要时按任务提升。

测试与验证

关键路径同时有单元测试和集成测试覆盖，针对每个受支持的 数据库引擎和主版本，在真实的数据库容器上运行。

对备份工具来说，恢复是最要紧的路径，所以我们对它做显式 测试：每个 PR 都会在同样的真实容器上跑完整的 备份加恢复流程，验证备份端到端真的能恢复出来，而不只是 写入成功。

CI/CD 流水线的其余部分在每个 PR 上运行 lint、类型检查、 完整测试套件、镜像冒烟测试和多架构构建。全部通过，版本 才会发布。

报告漏洞

发现漏洞？请通过 GitHub 的 Security 标签页报告，详见 SECURITY.md。安全报告是优先级最高的工作队列。