你的安全团队会问到的问题,简短而诚实的回答。
我们公开我们做的, , 以及同样重要的, , 我们不做的。不对扫描者进行再营销,不使用第三方像素,数据库中从不存储原始 IP 或用户代理,永远如此。更深入的数据驻留说明见 /security/;实时正常运行时间见 /status/。
1. 隐私优先分析
根据 ADR-0004,扫描管道从不记录 IP 地址或原始 User-Agent。在接收时,我们读取 CF-IPCountry(国家),将 UA 通过设备类型正则(mobile / tablet / desktop / unknown)分类,然后丢弃原始字符串。城市级数据是从 request.cf.city 填充的聚合汇总, , 无单次扫描行,无可关联标识符。少于 5 次扫描的国家聚合归入"其他"以防止重新识别。
2. 加密备份
每晚 03:00 UTC,一个独立 Worker 将 D1 快照到 R2。备份使用 BACKUP_ENCRYPTION_KEY 包装的 KDF 轮换数据密钥进行 AES-GCM 加密。每个包都携带 SHA-256 摘要 + 清单用于篡改检测(见 backups 表)。Pro 租户保留期:7 年。加密密钥保存在三个独立副本中(Worker 密钥、1Password 保险库、密封离线), , 丢失全部三份将使历史备份无法恢复,因此我们将其视为单一运营信任点。
3. API Shield + 严格 CSP
我们的公开 OpenAPI 3.1 规范已上传到 Cloudflare API Shield,所有对 /api/* 的请求均按规范验证。通过每次生产部署时重新上传规范的 post_deploy 钩子消除了规范漂移。在前端,严格的内容安全策略禁止任何地方的内联脚本, , 每个页面都通过 <script src> 引用其 JS,我们的预部署 make check 拒绝发布违反该规则的页面。
4. 审计日志 + GDPR 台账
每次修改操作(码创建/修改/删除,团队邀请,密钥签发,套餐变更,Webhook 编辑)都以操作者、范围和时间戳向 audit_log 写入追加式行, , 保留 180 天,由 sweeper 清理。GDPR 请求台账(gdpr_requests)追踪每次导出/删除/恢复;行在账户删除后仍然存在(FK ON DELETE SET NULL,邮件地址保留),这样即使账户已消失多年,我们也能证明及时处理了每个法定请求。
5. 认证保护
认证委托给共享的 abundera.ai 身份层(EdDSA JWT via JWKS)。Pro 客户可用:
- 2FA(TOTP), , RFC 6238 基于时间的一次性密码,任何标准身份验证器应用,注册时签发备用码。
- SAML 2.0 SSO, , Okta、Entra ID、JumpCloud、Google Workspace、自定义 IdP。在 Team+(Agency/Enterprise 捆绑)上可用。
- SCIM 2.0 供应, , RFC 7643/7644 用户 + 群组生命周期,每 token 限速,写入审计日志。默认关闭;按客户启用。
- API 密钥, , Business+,存储为
sha256(raw);原始abnd_qrpro_...值仅在创建时返回,之后不再显示。
6. 子处理商
简短列表:Cloudflare(托管、D1、KV、R2、API Shield),Stripe(支付),Zoho / ZeptoMail(事务性邮件),Twilio(手机验证 + SMS)。包含区域、数据类别和我们 30 天变更通知承诺的权威列表见 /trust/subprocessors/。
7. 数据处理协议
我们符合 GDPR 的 DPA(欧盟 SCC、英国附录、瑞士 FADP 附录)可在 abundera.ai/legal/dpa/ 下载。适用于所有付费套餐,无需单独反签, , 除非你的采购流程需要(可按需签署,联系 legal@abundera.ai)。
8. SOC 2
SOC 2 Type II, , 进行中,目标 Q3 2026。我们正与一家与四大会计师事务所相邻的审计机构进行范围确定/观察窗口规划。在报告发布前,我们不会展示 SOC 2 徽章。如果 SOC 2 完成是你今天的硬性采购要求,请发邮件至 enterprise@abundera.ai, , 我们可以在保密协议下分享当前控制证据、系统描述草案和预计认证日期。
9. 从不使用第三方像素
这是一个承重承诺和产品边界,不是可以悄悄改变的默认设置。我们不注入 Google Analytics、Google Tag Manager、Meta Pixel、TikTok Pixel、LinkedIn Insight、Hotjar、FullStory 或任何其他第三方追踪器, , 不在我们的重定向响应中,不在我们托管的落地页中,也不在扫描者看到的控制台界面中。你的扫描者永远不会被再营销。如果你需要在自己的目标页面上进行基于像素的归因,请在目标 URL 中附加你自己的 UTM(或像素)参数;我们置身事外。重定向本身是从我们的 Worker 到你的 URL 的 302, , 没有其他任何东西运行。
10. 负责任披露
发现问题了?从 /.well-known/security.txt 获取当前联系方式、PGP 密钥和范围。发邮件至 security@abundera.ai, , 我们在 24 小时内(工作日)确认,72 小时内分类,并与你协调修复 + 披露。善意披露的研究人员在修复发布后可在 abundera.ai/security/thanks/ 获得公开致谢。
11. 状态与正常运行时间
实时状态、组件健康和事故历史见 /status/。重定向热路径由外部 Worker 每 5 分钟监控一次;降级或宕机的组件在一个轮询周期内反映在状态页上。