为什么您的办公场所数据需要独立数据库

当 IT 或安全团队评估一款办公场所预订工具时，问卷通常会问到加密、单点登录和服务器所在地。它很少问到对这类数据最重要的那个问题：我们组织的数据是与其他所有客户的数据物理隔离的，还是只是共享表中的一列？

工位预订看起来像是低风险数据，直到您列出它包含的内容：谁在哪一天在哪栋楼、坐在哪张工位、旁边是谁、带了哪些访客，以及车停在哪里。这是您员工队伍的一份行动日志。它值得获得您对 HR 或薪酬数据所要求的同等隔离。

本文解释 SaaS 供应商存储多租户数据的两种方式，为什么 Desk & Park 为每个组织提供自己的独立数据库，以及这一决定对负责安全、隐私和合规审批的人意味着什么。

两种架构，一种取舍

几乎每款 SaaS 产品都是多租户的：一个应用服务许多客户。问题在于客户之间的边界在哪里。

共享数据库，租户列

这是常见的做法。所有客户的数据行位于同一批表中，每一行带有一个 tenant_id。每个查询都必须按它过滤。负责把客户隔开的是应用，而不是数据库。

它之所以流行，是因为运维成本低：一个数据库、一套模式、一次迁移。它也是一整类安全事件的来源。成千上万个查询中只要有一个漏掉了 WHERE tenant_id = ?，一份报表在跨表关联时没加过滤条件，或者一个缓存错误，客户 A 就会看到客户 B 的数据。这些错误不是假设，而是已披露 SaaS 数据泄露事件中反复出现的一类，而且很难发现，因为每一个查询单独看都是正确的。

每个组织独立数据库

每个客户都有自己的数据库，拥有自己的表、自己的凭据和自己的备份。应用为发起请求的组织连接到正确的数据库。没有会被遗忘的 tenant_id 过滤条件，因为数据库里没有其他租户可供泄露。

这要求供应商付出更多的运维纪律：配置、迁移和监控成百上千个数据库，而不是一个。这项成本正是关键所在。它由供应商在工程阶段一次性支付，而不是由客户在日后的安全事件中支付。

Desk & Park 如何构建

Desk & Park 采用每组织一个数据库的架构。具体而言：

控制平面只保存路由和计费所需的信息：组织名称、方案、组织到其数据库的映射，以及平台自身的审计记录。它不包含任何预订、平面图或员工目录。
每个组织一个 PostgreSQL 数据库，保存该组织的一切：用户、角色、地点、地图、工位、车位、会议室、预订、签到、访客、通知以及该组织的审计日志。
按组织划分的凭据。 应用使用仅限于该数据库的凭据打开与某个组织数据库的连接。来自组织 A 的请求即便出错也不可能在组织 B 的数据库上执行，因为它从未持有到该数据库的连接。
按组织备份、恢复和擦除。 备份按数据库进行。把一个组织恢复到昨天的状态不会影响任何其他组织。合同结束时删除一个组织，意味着删除它的数据库——这是一次可验证的、完整的擦除，而不是一条寄希望于找齐了每一行的 DELETE WHERE tenant_id。

应用代码是共享的，数据不是。这就是审计员可以明确指出的边界。

隔离为审批者带来什么

对 CISO：更小的影响范围

多租户查询层的一个漏洞会同时暴露所有客户。有了独立数据库，同类错误无法跨越组织边界，因为边界由数据库引擎和连接凭据强制执行，而不是由应用逻辑。隔离并不能让应用对错误免疫；它让某一处的错误成为单个客户的问题，而不是全平台的问题。

对 DPO：GDPR 问题的清晰答案

数据保护审查会问一些可以预见的问题，而每组织独立数据库给出的是简短的答案。

问题	独立数据库的答案
我们的数据在哪里？	在您自己的数据库中，位于平台的欧盟区域，与所有其他客户分开。
谁能访问？	使用仅限于您的数据库的凭据的应用，以及按照书面访问流程操作的运营方值班人员。
你们能证明删除吗？	能：您的数据库被删除，删除操作记录在平台审计记录中。
你们能只恢复我们的数据吗？	能：备份是按组织进行的。
你们能导出全部数据吗？	能：导出就是一个数据库的转储，而不是经过过滤的提取。

被遗忘权和限制处理的义务成为范围明确的数据库操作，而不是必须测试其完整性的应用功能。

对合规负责人：可辩护的控制措施

ISO 27001 和 SOC 2 等框架要求供应商证明客户之间的逻辑隔离。"每个查询都按租户过滤"是一项必须为每个新查询重新验证的控制措施。"每个客户都有自己的数据库和凭据"是一项只需在结构上验证一次、并随产品增长持续有效的控制措施。后者更容易举证，无论对供应商还是对客户自身的审计都是如此。

对 CIO：可预测的性能和生命周期

一个组织的重型报表不会拖慢另一个组织的早高峰签到，因为它们不共享表或索引。迁移按数据库逐一推出，因此问题可以在一个组织上被发现，而不会波及下一个。下线就是一次删除，而不是一个清理项目。

安全故事的其余部分

隔离是地基，不是整栋建筑。IT 团队期望的控制措施建立在它之上，值得一一列出，因为架构再好、认证薄弱，仍然是薄弱的：

通过 OpenID Connect 与您的身份提供商实现单点登录，以及 SCIM 自动配置，让入职和离职人员从您的目录中自动创建和停用，而不是手工操作。
双因素认证（TOTP）和通行密钥（WebAuthn），并可在组织层面强制要求 MFA。
按组织设置安全策略：会话超时、密码规则、IP 白名单。
活动会话管理，管理员可以查看并撤销会话。
按组织的审计日志，记录谁更改了什么，存放在该组织自己的数据库中。
通过 Stripe 支付，银行卡数据完全不会进入平台。
基于角色的访问控制：员工查看和预订；管理员进行配置；董事会成员和经理获得限定在其团队范围内的报表。

这些在企业级 SaaS 中都不罕见。不寻常的是把它们与一个客户边界是物理隔离的数据层结合在一起。

向任何办公场所供应商提出的问题

如果您正在比较工具，以下五个问题能把营销话术和真实架构区分开来：

我们的数据是在专用数据库中，还是在带租户列的共享表中？
备份、恢复和删除是按客户执行的吗？
应用使用什么凭据访问我们的数据，这些凭据是否仅限于我们？
你们如何向审计员证明客户之间的隔离？
报表或导出中的一个错误是否可能返回其他客户的数据行？

拥有独立数据库的供应商每个问题都能用一句话回答。使用共享数据库的供应商则必须描述一套测试流程。

隔离应当是默认选项

办公场所数据是关于员工物理在场的个人数据。对供应商最便宜的架构把这些数据与其他所有客户的数据放在一起，并信任应用把它们隔开。Desk & Park 选择了更昂贵的那一种，让组织之间的边界是一个数据库，而不是一个过滤条件。

您可以在工作原理页面的架构摘要和平台的隐私政策中阅读技术细节。如需带单点登录、SCIM 和安全审查的企业级部署，定价页面提供了企业版的联系方式。