行级安全或多个表

Joh*_*han 5 security database-design row-level-security

我正在寻找有关以下场景的最佳实践的文档。

托管应用程序包含一些“全局”数据和一些“每租户”数据。“租户”不应该访问另一个租户的表,我希望在 DBMS 级别强制执行此操作(除了强制执行到应用程序级别)。

因此,作为示例,该应用程序可以向视频租赁商店提供管理系统。

店主和员工以及与租借电影的人有关的信息是全球性的。一旦客户注册,他们就无需再次注册从另一家商店租用。

商店(租户)有自己的数据库(客户列表、库存、当前预订的电影等)。因此,当店主登录应用程序时,只显示他自己的数据,我对此没有意见。

系统是否应该为每个租户/商店创建一组新表?

或者系统是否应该使用 DBMS 安全/授权...换句话说,在后端,商店 1 的库存与商店 2 的库存在同一表中,但通过 DBMS 安全性,视图只允许为谁选择该商店的行用户已登录应用程序。

我不确定我的问题是否足够清楚?

Jus*_*ave 6

我的偏见是使用具有适当行级安全性的单个表。

单组表具有潜在的巨大维护优势。如果最终n得到每个表的副本,则意味着n每次要进行更改时都必须运行每个脚本的副本。通常,这意味着您最终会同时运行至少几个略有不同的应用程序版本,因为有人忘记将每月构建的 23 个脚本中的第 7 个应用于一组表,而其他人在其中创建了索引一组表来解决一个客户的问题,而无需将其添加到每个客户,这使得调试变得更加困难。

一组表具有显着的可扩展性优势。添加新客户只需要向客户表添加新行,而不是使用新客户的表副本部署新模式/数据库。添加新客户也不会直接为 DBA 添加正在进行的工作。如果您有单独的表副本,则需要有人来部署表以创建新客户,而每个新客户都意味着 DBA 至少要在每次发生更改时多运行一次脚本的额外工作。

一组表也可以提供性能优势。如果您使用一组单独的表,则每个客户实际上都需要在中间层有一个单独的连接池。毕竟,如果您的中间层以可以查看每个租户数据的用户身份进行连接,这将违背拥有单独表的目的,因为那样您将在中间层实施行级安全性并处理所有复杂性后端的多组表。这使得跨服务器扩展变得困难——您是否为每台服务器上的每个客户端创建一个连接池?您是否将某些客户端发送到某些服务器?您是否没有预先分配连接并承担更频繁地等待连接建立的成本?

话虽如此,在某些情况下可能更喜欢单独的表。例如,如果您的客户通常是大型机构,那么如果客户想要升级到专用硬件,那么单独的表可以更轻松地执行诸如将客户移动到专用框(或至少是专用 VM)之类的操作' 不冒业绩受到其他客户影响的风险。那些大型机构可能希望更好地控制中断和升级,因此拥有单独的表以允许不同的客户在不同的时间进行升级以配合该客户的时间表可能是有意义的。这些机构可能会发现,告诉审计员他们的数据与所有其他客户在物理上是分开的,而不是解释数据在物理上是混合的,但安全控制已经到位,以保证行级安全,这更容易。如果您将拥有相对较少的相对较大的客户,考虑到每个客户可能需要的一般日常维护任务,您通过拥有单独的表引入的维护开销可能不会特别大。在那种环境中,不同的客户端通常有足够不同的配置,即使它们运行的​​软件版本完全相同,他们遇到的问题也是相对独特的。考虑到每个客户端可能需要的一般日常维护任务,通过使用单独的表引入的维护开销可能不是特别大。在那种环境中,不同的客户端通常有足够不同的配置,即使它们运行的​​软件版本完全相同,他们遇到的问题也是相对独特的。考虑到每个客户端可能需要的一般日常维护任务,通过使用单独的表引入的维护开销可能不是特别大。在那种环境中,不同的客户端通常有足够不同的配置,即使它们运行的​​软件版本完全相同,他们遇到的问题也是相对独特的。