执行摘要

PulseCargo为每个客户租户配置一个单独的SQL Server数据库。这在运营上比大多数多租户SaaS使用的行级过滤模式更昂贵，对于货运代理商的采购和合规环境来说，这是正确的权衡。

本文描述隔离在实践中如何工作、它缓解的行级过滤不缓解的威胁，以及它产生的审计证据。

1 — 大多数SaaS使用的模式，以及为什么它不够

主导的多租户SaaS模式是具有租户ID的共享架构。一个数据库。所有租户在相同表中的行。每一行上的tenant_id列。应用代码将WHERE tenant_id = @currentTenant添加到每个查询。

这个模式便宜运行。它在规模上起作用。它也是一个开发者错误离一个跨租户数据泄露，而这个错误已经公开发生给足够多的供应商，采购团队现在明确询问它。

故障模式文档记录得很好：

忘记的WHERE子句。 一个新查询、一个重构、一个存储过程迁移。一个缺失的谓词将一个租户的数据暴露给另一个。
ORM过滤绕过。 EF Core、Hibernate、ActiveRecord中的查询过滤可以通过原始SQL、动态查询或框架转义舱口绕过。
缓存键重用。 从缓存键中丢弃的租户ID返回另一个租户的缓存结果。
后台任务上下文丧失。 后台工作者拉取”所有行”而不租户上下文。
报告层。 直接连接到数据库的BI工具经常完全绕过应用层过滤。

这些故障模式不是假设的。OWASP API前10（BOLA — 破坏的对象级授权）是过去三年中报告最多的API漏洞，在大多数情况下，根本原因正是这个模式。

PulseCargo选择了不同的模式。

2 — PulseCargo做什么代替

PulseCargo为每个租户配置一个单独的SQL Server数据库。命名约定是：

PulseCargoDb — 门户数据库，保存租户身份、计费计划、服务协议、门户管理员账户以及跨租户基础设施。
PulseCargo__<tenant-slug> — 每个客户租户一个，保存所有该租户的客户数据：货运、订单、容器、海关条目、发票、文件、审计日志、AI查询日志。

Web层、API层和后台工作者通过TenantResolutionMiddleware在每个请求中接收一个租户标识符。中间件查找租户段，计算该租户数据库的连接字符串，并将该连接绑定到请求范围。请求中的每个数据库调用 — 无论通过Entity Framework Core、Dapper还是直接ADO — 使用该绑定的连接。

没有租户范围的查询无法连接到租户数据库，因为没有租户数据库连接到没有租户标识符。忘记WHERE子句的故障模式不存在；没有共享表来遗忘WHERE子句。

3 — 这保护什么不是行级隔离

威胁	行级隔离	按租户数据库隔离
忘记WHERE子句暴露其他租户的行	可能 — 取决于每个查询正确	不可能 — 单独的数据库
ORM查询过滤绕过通过原始SQL	可能	不可能
后台任务拉取所有行而不租户上下文	可能	不可能 — 任务必须指定租户以获得连接
缓存键重用返回错误的租户数据	可能	缓存键本身是租户范围的，因为连接字符串
BI工具直接连接并读取跨租户	可能 — 必须添加额外的安全	不可能 — BI工具凭据是按租户的
备份恢复到错误的地方暴露其他租户	可能	不可能 — 每个租户有自己的备份；恢复只能到那个租户
合规审计官问”向我显示跨租户访问控制”	多层答案（过滤、RLS、应用代码、审计）	单层答案（单独的连接字符串）

最后一行不相称地重要。SOC 2类型II评审、ISO 27001审计和财富500采购安全问卷都询问”一个客户的数据如何与另一个的分离？“的某个变体。答案越短越强，审查结束得越快。

4 — 运营成本

这个模式并不免费。权衡：

4.1 更高的按客户存储成本

每个租户数据库都有自己的索引、事务日志、统计数据和开销。小租户的边际存储成本比在共享架构模型中更高。

我们接受这个成本。它在物质上小于跨租户数据泄露的成本，并且线性缩放而不是灾难性地。

4.2 更昂贵的跨租户分析

汇总分析 — PulseCargo作为Professional层的选择功能提供的跨租户行业基准 — 需要从每个参与租户数据库收集数据并单独计算基准。这是大多数共享架构供应商获得便宜汇总查询的地方。

我们通过将跨租户分析视为一个单独的过程来解决：一个后台任务迭代参与租户，计算按租户统计数据，并将汇总写入专用基准存储。成本是每日一次任务而不是即时查询；好处是汇总是k-anonymous的（k ≥ 5）通过构造，参与租户具有通过Tenants.EnableAggregatedAnalytics的显式选择加入。

4.3 配置时间更多的工作

新租户需要数据库创建、架构迁移、首发包导入和EF迁移历史回填。PulseCargo的scripts/backfill-tenant-ef-history.ps1和租户配置管道自动化这个；它大约是一个两分钟的配置步骤。

4.4 对架构迁移的更多关注

架构更改必须跨每个租户数据库应用，而不仅仅一个。PulseCargo使用在部署时应用的EF Core迁移每租户，带有回滚路径。纪律成本是真实的，但部署管道以透明方式处理它。

5 — 这如何与安全状态的其余部分合成

按租户数据库隔离是底层。安全模型的其余部分在顶部分层：

AES-256加密静态 通过SQL Server TDE和Azure Blob Storage加密。
TLS 1.3 对所有传输中的数据强制执行。
本机多因素认证 （TOTP）与可选Twilio SMS因素和Microsoft 365 / Google Workspace SSO联合在门户和租户范围。
基于角色的访问控制 与门户管理员、租户管理员、租户用户和按客户关联角色。
审计日志 在每个入站请求上通过AuditLoggingMiddleware、在每个CargoWise webhook、在每个合成智能查询上。
数据主体权利端点 对于GDPR Art. 5 / 32 / 33和CCPA / CPRA § 1798.100 / .105 / .150 — /request、/request-deletion、/export、/opt-out作为用户启动的提供；管理员启动的导出单独提供。
软件托管 通过NCC Group、Iron Mountain或EscrowTech与包括源代码、按租户插件、SQL备份和SHA-256清单的ZIP存款。重新渗透端到端测试 — 从不仅干运行。
多框架合规 跟踪 — SOC 2、ISO 27001、GDPR / CCPA、OWASP、NIST和额外的行业框架。SOC 2、ISO 27001、GDPR、CCPA和CTPAT有今天填充的控制库；额外框架用其他模板跟踪。完整框架清单可根据要求提供。

6 — 租户隔离审计结果

PulseCargo在2026-04-24进行了全面的租户隔离审计。审查了61个控制器和大约140个端点以进行跨租户数据暴露。零个严重级别问题。 完整的审计报告可根据要求与安全团队共享。

一个INFO级别的发现确定 — 对所有第三方服务（Stripe Connect、TMS提供商探针、AI提供商）尚未实现的出站集成审计日志 — 正在扩展以关闭SOC 2 CC4.1 / CC7.2证据差距。该模式对eAdaptor有所准备；剩余的服务在构建队列中。

7 — 这对采购评审意味着什么

如果您是一个根据供应商安全标准评估PulseCargo的货运代理商，推荐的问题模式是：

“你如何隔离租户数据？” 按租户SQL Server数据库隔离，在中间件层解析。不是行级过滤。
“如果开发者犯错会发生什么？” 没有租户上下文的查询无法连接到租户数据库。忘记WHERE子句的故障模式不存在。
“向我显示您上次跨租户审计。” 租户隔离审计，日期2026-04-24，61个控制器，约140个端点，零个严重级别问题。可根据要求提供。
“向我显示数据主体权利流程。” 自助服务端点在/api/me/privacy/*加上管理员启动的在/api/admin/users/{id}/privacy/*。两者今天提供。
“备份怎样？” 每个租户有自己的备份。恢复只能到那个租户的数据库。软件托管可通过NCC Group / Iron Mountain / EscrowTech，包括端到端测试的重新渗透。
“您的合规证书是什么？” SOC 2类型II在活跃的认证路径上。ISO 27001证据正在收集。GDPR / CCPA控制映射到今天的特定端点。合规框架平台是进行中证据收集的底层。

8 — 关于PulseCargo

PulseCargo是货运代理商的合成智能层，坐在现有TMS之上（CargoWise现在直播；Magaya、Descartes、GoFreight在产品路线图上）。按公司，不按座位。从Starter Lite（自助服务评估）到Enterprise+（多区域、专用基础设施）的五个层。与销售联系以了解层范围和定价。

要求完整的租户隔离审计报告、SOC 2准备包或安全团队简报：pulsecargo.ai/contact或security@pulsecargo.ai。

按租户数据库隔离架构