我正在为我的公司规划一个 Web 应用程序的架构，该公司正在为其合作伙伴推出金融服务，我的主要问题是 - 将每个合作伙伴放在不同的服务器（甚至服务器组 web/db）上是否有意义？
该应用程序在某种意义上类似于https://www.wealthfront.com/ - 合作伙伴信任我们的资产并向我们提供数据，我们使用这些数据来自动化投资。每个合作伙伴都有一个我们的帐户、登录名/密码对和一个他可以登录的网址。登录后，他可以访问仪表板，其中包含他在表格中的图表中显示的所有数据。
合作伙伴及其数据彼此完全独立。我们还有一些管理界面来预处理他们的数据和管理他们的帐户，但是有一个单独的 web/db/workers adm 服务器，合作伙伴通过只写服务将他们的数据提供给主数据库（他们不能查询任何任意信息）。
合作伙伴数据非常敏感，如果其中任何一个落入坏人之手 - 对我们破产的影响可能非常严重。
关于如何组织此类服务的架构，我有两种方法：
分组，其中每个角色都有一台服务器，所有合作伙伴都坐在每台服务器上
隔离，其中我们也为每个角色拥有一个服务器，但每个合作伙伴为每个角色获得一组服务器
我看到两种可能发生未经授权访问数据的场景：
- 攻击者：有人入侵了某些服务器并获得了某种访问权限。可能是简单的错误配置（没有密码从公共网络留下的 ssh 访问、类似心脏出血的漏洞......）。这太模糊了，隔离肯定不能从所有场景中拯救出来，但我仍然觉得在所有其他条件相同的情况下，隔离架构更安全，因为它会产生更多障碍。
- 人为错误：工程师忘记添加一些安全检查或无意中删除了一些或赋予每个人超级管理员查看所有内容的权限，它进入生产阶段，每个人都不满意。这当然应该通过各种规则、审查、约束和流程来防止，但错误总是会在生产中找到。我有一种感觉，如果发生类似的事情，物理隔离也有助于缓解（即使初级合伙人员工可以访问仅限高级合伙人的信息，如果他能访问其他合伙人的仅限高级信息，那会好得多！）
我看到的分组优点/缺点：
- [+] 更容易缩放
- [+] 更便宜（更少的服务器，可以更有效地分散负载）
- [+] 少配置（虽然我们使用的是配置管理工具和云环境中的主机，所以这不是什么大问题）
- [-] 每次访问检查失败都会导致所有数据数据暴露给用户
- [-] 入侵 web/db 服务器让您可以访问所有内容（例如，如果某个合作伙伴决定探索并以某种方式成功地在我们的系统中找到了他的方式）
- [-] 如果一个合作伙伴造成了很大的负载，它会伤害到每个人（尽管通过一些简单的扩展来减轻）
- [-] 无法有效使用基于ip的限制（我认为）
我看到的隔离优点/缺点：
- [+] 每次访问检查失败都会导致用户自己的数据暴露给自己
- [+] 入侵 web/db 服务器只给你这个服务器数据（例如，如果某个合作伙伴决定探索并以某种方式成功地在我们的系统中找到了他的方式）
- [+] 将一个合作伙伴的系统负载与其他合作伙伴分开
- [+] 可以更精细地调整防火墙规则（我们可以限制仅来自合作伙伴 ip 的访问，这对于分组架构来说不是这种情况）
- [-] 不太容易扩展（虽然这绝对不是一个高负载项目，所以它不是那么令人担忧）
- [-] 更贵
- [-] 更多配置（虽然我们在云环境中使用配置管理工具和主机，所以问题不大）
到目前为止，我可以看到隔离的许多优点和一些小缺点，但有一个很大的问题：由于我们使用配置管理工具，每台服务器将具有相同的操作系统、相同的软件和配置、相同的代码库以及所有内容。这样，如果我们有任何漏洞，没有什么可以阻止攻击者在所有服务器上使用它们，无论是否隔离。也许还有其他我现在看不到的缺陷会破坏整个想法。
因此，鉴于所有这些信息：
- 您认为隔离架构比分组架构提供更多的安全性吗？
- 对于我没有想到的孤立架构，是否有任何严重的权衡/阻碍？
- 你认为这个问题有一些常见的替代解决方案吗（不是分组或隔离，而是别的）？
- 如果隔离架构很好，那么拆分 Web 和数据库服务器（安全方面）是否有任何意义，因为它们已经与其他一切隔离，并且拆分它们不会增加更多安全性？