如何在B2B SaaS应用程序中启用用户数据主权？

Question

我们开发了一个处理客户ERP数据并在前端提供分析的SaaS解决方案。该软件是一个标准的解决方案，应该要求尽可能少的定制各自的客户。不幸的是，ERP数据是业务关键数据(不是法律保护的数据，例如个人数据，而不是企业机密数据)，因此在我们的云上处理数据不是客户的选择。

因此，我们考虑了三种选择，并询问是否有其他选择，或在这种情况下最佳做法是什么。

1. 在前提下，即每个客户都在自己的服务器上承载自己的实例。
2. 客户站点分析:我们为每个客户提供准备数据的分析器服务。应用程序的其余部分由我们托管。如果客户请求我们的应用程序，前端将通过来自我们的服务器和客户服务器的REST调用收集数据。
3. 匿名-去匿名数据:我们提供匿名服务，该服务将客户端的数据匿名，然后再发送给我们。在接下来的步骤中，我们将执行分析并将结果发送回客户。在最后一步中，数据被客户重新去匿名，并存储在他的站点的本地数据库中。如果客户请求我们的应用程序，前端将通过来自我们的服务器和客户服务器的REST调用收集数据。

您知道其他方法/最佳实践吗?这些策略有名称吗？

Answer 1

和你的顾客谈谈。弄清楚他们到底需要什么。

通常情况下，法律保护就足够了，即一份合同规定，你将只为客户的目的使用数据，你不会将数据用于任何其他目的，你不会将不同客户的数据组合在一起，并且你不会与其他人共享数据。这类合同也是技术解决办法的基础。例如，如果您足够值得信任来匿名化这些数据，那么您可能也可以直接处理这些数据(无论在哪种情况下，您开发的系统都必须访问非匿名数据)。

请注意，如果您的公司是一家真正的公司，与客户在同一管辖范围内注册，即不仅仅是一家不能被合理起诉的离岸空壳公司，合同就更有说服力。企业B2B空间中的供应商也可以根据ISO/IEC 27001认证，以显示他们以安全和兼容的方式提供服务的意图。

我不太喜欢“信任”这样的社会问题的技术解决方案。然而，技术解决方案可以帮助促进信任。让我们来看看你提出的想法：

• 前提处理:这可能是一种很好的方法，因为它让客户感觉到他们控制了软件--即使这通常不是这样的。预先处理也可以避开一些实际的合规问题。On部署继续在企业空间中流行。从软件工程的角度来看，为on部署开发与构建SaaS解决方案非常不同。你不能连续送货。您不能使用任意的编排技术。您可能必须发布带有明确支持期的清晰版本，并在需要升级版本时提供迁移支持。现在，将应用程序作为一组容器映像或单个容器提供可能是明智的。
• 将应用程序拆分为on和SaaS部件:如果处理管道的某些方面是特别敏感的，这是有意义的。然而，它通常会将on解决方案的缺点与云解决方案的缺点结合起来，并且可能会使您的体系结构复杂化。这也会使部署复杂化:如果您的服务器要从客户的服务器中获取数据，这就要求可以从您的网络访问客户的服务器。虽然这并非不可能(例如，通过配置合适的防火墙规则或VPN桥)，但它要复杂得多。复杂的部署可能是摩擦，这使得销售变得更加困难(如果来自客户的技术人员参与了收购过程)。
• 化名:是的，在处理敏感细节之前移除敏感细节是明智的.但是，这是一种在销售报告中看起来很好的东西，而不一定会提高安全性。
  • 这一化名需要一定程度的预处理，引起上述所有问题。
  • 客户可能担心第三方能够从他们的数据中得出敏感的结论。根据定义，从化名数据中仍然可以得出这样的结论，因为您的非现场处理步骤似乎提供了这样的价值。从明显不确定的数据中得出关于组织的统计推论的一个典型例子是德国坦克问题。
  • 可用的化名技术往往相当薄弱，特别是如果它们被认为是可逆的(匿名化技术提供的隐私/安全性与匿名数据集的效用之间存在着根本的权衡)。虽然差异隐私匿名化技术得到了深入的研究，可以提供强有力的保证，但由于在数据中添加噪声，它们本身就具有破坏性，而它们的概率、面向查询的模型可能需要一种不同的方法来分析数据。

Answer 2

我确实认为阿蒙的回答很好，我也会添加一些想法。

我的经验告诉我，根据标准进行的第三方审计，加上合同义务，通常足以证明数据的保护。ISO/IEC 27001就是这样的标准之一，但它既昂贵又费时.虽然您可能最终需要类似于ISO/IEC 27001证书或SOC 2类型的审计报告，但我建议组织从云安全联盟云控制矩阵与共识评估倡议问卷开始。它与这些标准和其他一些标准保持一致，在引入审计人员之前，你可以通过它进行自我评估。您甚至可以使用这些自我评估与客户和潜在客户一起工作，以了解您当前的状况以及他们希望看到的改进计划。

如果经过更多讨论后，不处理“您”云上的数据的要求不是一种选择，我建议您更仔细地考虑您的产品体系结构。这将排除使用多租户SaaS模型。

一种选择是继续采用SaaS模型，但采用单租户解决方案。也就是说，您将为每个客户实例化一个新的、完全隔离的云实例，而不需要混合数据。在这种模式下，拟订可接受的协议可能更容易。您提供基础设施和软件，并同时维护两者，而客户则提供服务所需的数据。由于您同时维护软件和基础设施，所以您可以向客户推出更新，但我建议您注意不要陷入客户可以拒绝更新的情况，而您只能为不同的客户维护许多不同版本的基础设施和软件。

另一个选择是沿着自我托管的路线走下去。将您的系统打包成客户可以在自己的基础设施上安装并管理它的方式。

我不确定我是否会考虑其他的选择。关于将应用程序拆分为就地和SaaS片段的选项存在一些问题，我怀疑这些问题会导致比它们解决的问题更多的问题。

任何时候，当你有一个预先的解决方案，你需要依赖第三方，以保持他们的组件最新。他们可能有自己的时间表和预算，并以自己的速度推出更新。最后，您可能会支持不同的客户，使用不同版本的on部件，或者冒着向付费客户提供破坏功能的风险。这似乎是您在系统设计中需要考虑的不必要的复杂性。

我同意化名在纸面上比实际安全更好。它将需要为您的客户提供某种on解决方案，这带来了与上面相同的问题，但也增加了重要的、可能的自定义安全功能，在这些功能中，错误最终可能会暴露您最初想要保护的数据。