跳至主要内容
Rosecraft Studios

你的应用能服务第一位客户,第二位呢?

把内部工具变成 SaaS 产品之前,先确认不同客户的数据如何隔离。登录、附件、导出和后台任务,都需要明确的规则。

Corey Rosamond · 2026/10/1 · 约 5 分钟阅读

本文为英文原文的简体中文译文。资料和事件日期保留原文发表时的语境;代码示例保持原样。 Read in English

你的应用能服务第一位客户,第二位呢?

第一位客户可能会让应用显得比实际更完善。他们登录、上传文件、运行报表,得到正确的结果。大家都很满意。

接着,你加入了第二家公司。现在需要回答的是:同一份报表,会不会混进别人的信息?

如果你打算把内部工具变成商业产品,就应该在开始销售之前,为这项工作安排预算。增加一家客户公司,会改变软件必须保证的事情。导航栏里多一个公司切换菜单,并不能解决这个问题。

9 月 24 日,Cloudflare 披露了影响 Containers 和 Sandboxes 的存储隔离漏洞。研究人员恢复出了其他工作负载留下的残余数据。Cloudflare 表示,问题已修复,而且在可用的遥测记录中,没有发现恶意利用的证据。

那是基础设施层的问题,与业务应用中遗漏权限检查不同。我并不是说你的应用存在同样的漏洞。它只是一个及时的提醒:客户之间的隔离,究竟在哪一层得到执行?

每条记录都需要明确归属

设想一个为装修公司开发的报价工具。它保存客户地址、房间尺寸、报价和照片。老板觉得很好用,于是想把同一套软件提供给其他装修公司。这是一个虚构的例子。

在最初的工具里,‘显示所有报价’可能完全合理,因为系统只服务一家公司。加入其他公司后,它必须变成‘显示这个人有权查看、且属于这家公司的报价’。一份报价还可能关联附件、明细和存储在文件系统里的 PDF。这些内容也必须有一致的归属。

开发者通常把每个客户组织称为租户。一个人可能属于多个租户,一个租户也可能有很多用户。如何表达这种关系,是产品设计的一部分。

AWS 的租户隔离指南提出了一个有用的区别:通过应用入口处的登录和访问检查,并不意味着整个系统已经实现了租户隔离。

回到装修公司的例子,成功登录只能告诉我们是谁在提出请求。接下来还要判断,这个人能否读取或修改这一份报价。‘他是付费客户’这个答案,范围太宽了。

跟着一份报价走出仪表盘

我会请团队展示一份虚构报价的完整流程:创建草稿、添加照片、生成 PDF、发送给房主,再进入月度报表。这样讨论就有了可以实际追踪的对象。

假设仪表盘已经正确地只显示第一家装修公司的报价,但独立的报表生成程序仍然沿用最初的逻辑,收集全部报价。此时,仪表盘看起来没问题,月度下载文件却可能出错。这是用于说明机制的假设,不是对真实客户系统的发现。

工程审查需要检查客户看不到的路径。OWASP 的多租户安全指南涵盖了在服务器端验证组织成员资格,以及把已经验证的范围传递给存储、缓存和后台任务。在浏览器里选择一家公司,只是提出在该公司范围内操作的请求;服务器仍然需要核实权限。

对于创始人,有用的交付物应该解释这些规则如何覆盖产品的实际功能。画两个分别标有‘客户 A’和‘客户 B’的方框,无法说明夜间生成的报表是否读取了正确的记录。

准备两个普通测试客户

在验收这部分工作之前,我希望看到两个虚构公司、明显不同的样例记录,以及普通客户账号。两家公司都应该能完成自己的工作。团队还应证明,其中一家不能读取或修改另一家的私有记录,包括下载文件和导出数据。

请使用你有权控制的测试组织,并在获得授权的测试环境中进行检查。这个过程不需要真实客户的信息。

给两家装修公司设置容易区分的样例项目:一家为蓝色厨房报价,另一家为绿色走廊报价。出现 PDF、搜索结果或定时报表时,评审者就更容易发现混淆。然后,再问团队:下一次发布后,哪些自动化检查会继续覆盖这些情况?

这是对明确需求的审查,不是完整的安全评估。通过这项检查,不能证明每个功能或部署都是安全的。但相比看开发者用一个拥有全部权限的管理员账号来回切换公司,它能提供更有价值的证据。

也要记录有意允许的共享。比如,一名会计可能受邀加入两家公司,其访问权限应来自这些邀请;而装修公司的前台人员,仍应只访问雇用自己的公司。有用的审查既包含应被拒绝的访问,也包含应该被允许的访问。

先定义隔离规则,再为扩展定价

我不会默认每增加一家公司,都要增加一台服务器。AWS 同时介绍了使用独立资源,以及在共享资源内部实施隔离的方式。如何选择,取决于产品及其要求。基础设施更多,本身并不能证明设计更好。

我会要求一份简短的工作范围,写清哪些记录属于客户、哪些共享是允许的、要检查哪些功能,以及最终会提供什么证据。这样才能为明确的工作定价。‘改成多租户’这几个字,给买方和开发者留下了太多不同的想象空间。

对这个装修报价工具来说,初期版本可以支持多家公司的报价和 PDF,同时明确不包含复杂的跨公司报表。创始人可以主动做出这样的取舍。默默假定全部现有功能都已经适合多家公司使用,则很难让人放心。

如果你正处于这个阶段,Rosecraft 的技术评估与策略服务可以帮助你在委托扩展开发之前,明确需要检查什么。告诉我们应用目前能做什么,以及下一步需要谁来使用。把这两件事说清楚,就是一个有用的起点。

封面:使用虚构客户文件制作的 AI 生成插图。

作者:Corey Rosamond,Rosecraft 创始人兼首席工程师

继续阅读

订阅工作室邮件

留下邮箱以接收工作室更新。订阅后请检查确认邮件;确认邮件目前使用英文。

了解隐私政策

下一步,从交流开始

把您的问题,变成清晰的下一步。

告诉我们您想开发或改进什么。我们会一起梳理范围、限制和合适的工程方案。

聊聊项目