配置多租户数据权限
学习如何限制客户对行、列或模式的访问,以进行安全自助式分析。
单一模式与多个客户(混合数据)
如果所有客户数据都在同一个模式中,并且位于同一个表(通常称为“数据混合”)
租户ID | 列1 | 列2 |
---|---|---|
A | … | … |
B | … | … |
C | … | … |
数据沙箱 是最佳选择。大多数使用 Metabase 提供多租户分析的组织都会使用
您还可以配置带有数据沙箱权限的 SSO,以便人们从第一次登录开始就获得正确的行和列访问级别。有关多租户权限和嵌入如何协同工作的更多信息,请参阅 使用 SSO 和数据沙箱保护数据。
基于租户ID限制行
假设您有一个名为 Data 的表,其外观如下
租户ID | 惊人的度量 | 疯狂洞察 |
---|---|---|
A | … | … |
B | … | … |
C | … | … |
您可以为基于租户ID的不同租户创建一个 基本沙箱,以显示 Data 的筛选版本。这意味着租户A将看到“租户ID”列具有“A”值的行,而租户B将看到“租户ID”列具有“B”值的行,依此类推。
以下是基本沙箱的工作方式
- 您将创建一个组,例如“沙箱租户”,并将人们的 Metabase 账户添加到该组。
- 对于每个账户,您将在账户中添加一个 用户属性,例如“租户ID”,并将用户属性值设置为“A”、“B”或“C”。
- 一旦您设置了带有用户属性的组,就从您的 管理员设置 > 权限 创建一个基本沙箱。
基本沙箱将显示具有对 Tenant ID 列应用筛选的 Data 表。筛选值将根据每个人的登录动态设置。例如,将“租户ID”用户属性设置为“A”的账户将看到筛选为 Tenant ID = A
的 Data 表。
基于租户限制列
现在,假设您的 Insane Insights 列是高级功能,而租户B是唯一支付查看这些 Insane Insights 的客户。租户A和C正在省钱,因此他们只能看到 Marvelous Metrics。
租户ID | 惊人的度量 | 疯狂洞察 |
---|---|---|
A | … | |
B | … | … |
C | … |
在这种情况下,您可以将租户A留在 行限制示例的基本沙箱 中。但您需要将租户A和C移到 自定义沙箱 中——这将允许您限制列,而不仅仅是行。
以下是您如何设置自定义沙箱以选择性地隐藏列(除了将租户限制在其自己的行之外)
- 创建一个名为“仅度量租户”的组。
- 将来自承租方A和承租方C的人员移至“仅指标承租方”组。
当您以不同的方式为不同的组沙盒化《数据》表时,请确保每个Metabase账户只属于一个组——要么是“沙盒化承租方”要么是“仅指标承租方”。
- 对于每个人的Metabase账户,您需要添加一个用户属性,例如“承租方ID”,并将用户属性值设置为“A”、“B”或“C”。
-
接下来,您将使用如下所示的《数据》表创建一个SQL问题
SELECT marvelous_metrics FROM tenants WHERE tenant_id = {{ tenant_user_attribute }}
- 将SQL问题保存为“奇妙指标”。
- 使用“仅指标承租方”组和“奇妙指标”SQL问题创建一个自定义沙盒。
自定义沙盒将向“仅指标承租方”组的人显示“奇妙指标”SQL问题(代替原始的《数据》表)。
例如,如果某个人的用户属性“承租方ID”设置为“A”,那么他们将只能看到《数据》表中的“奇妙指标”列,并筛选出“承租方ID”列值为A的行。
多个模式(每个客户一个模式)
如果您的客户数据存储在同一模式中的单独表中或在一个数据库中的不同模式中,如下所示
承租方A的模式
承租方A | 列1 | 列2 |
---|---|---|
行1 | … | … |
行2 | … | … |
行3 | … | … |
承租方B的模式
承租方B | 列1 | 列2 |
---|---|---|
行1 | … | … |
行2 | … | … |
行3 | .. | … |
您可以选择以下选项
与混合数据不同,每个客户一个模式(社交不友好)的数据与沙盒不兼容,因为沙盒只能在行和列级别分配权限,而不能在模式级别分配。
授予客户对其模式的自助或仅查看访问权限
假设您有一个包含十个不同表的单个数据库,并且这些表中的每一个都对应一个客户(在这种情况下,不同的公司)。我们的目标是确保每个客户只能访问包含他们自己信息的表。
注意:以下方法假定您的客户不需要访问Metabase的原生SQL编辑器,而将使用查询构建器来提出问题。
-
如果您还没有做,请将您的数据源连接到Metabase。
-
在<强>管理员设置强>> <强>权限强>> <强>数据强>,阻止所有用户组对数据库的访问。
-
在<强>管理员设置强>> <强>人员强>,为您第一个客户创建一个组。您可能只需要每个公司一个组,但如果您的客户希望他们的某些员工能够提出问题而其他人只能查看,您将需要为每个客户创建多个组,以便可以设置不同的权限级别。根据一些定义的约定命名您的组可以帮助您保持组织——考虑像<强>公司A(自助服务)强>和<强>公司A(仅查看)强>这样的命名。
-
返回到<强>权限强>> <强>数据强>> <强>数据库强>页面,然后授予您新创建的组访问与正确客户对应的表的权限。如果您希望您的客户能够在他们的表中提出问题并创建仪表板,将他们的<强>创建查询强>权限更改为<强>查询构建器强>。在此上下文中,创建查询的访问权限是指表,而不是整个数据库。
如果您的客户中有一些员工只能查看数据(而不是自助访问),则需要创建集合来存储这些特定的问题和仪表板。请参阅集合权限。
避免授予您的组访问原生的SQL编辑器权限,因为这个原生的查询编辑功能允许人们查询他们在Metabase中看不到的表,而且不应该有权访问。
-
重复步骤3-5以添加您十个客户中的每个用户的账户。
如果您授予一个组访问数据库中所有表的权限,后来又修改了数据库以包含新表,Metabase将默认授予该组访问新表的权限。但是,如果您像我们上面做的那样,将每个组的权限限制在单个表上——Metabase将默认隐藏您添加的任何新表。
授予客户对数据库模式的原生SQL访问权限
由于Metabase的SQL编辑器需要对整个数据库拥有无限制的访问权限,因此使用上述方法启用它将允许您的客户查询不属于他们的表。如果原生SQL查询对您的客户是必需的
-
在数据库级别——而不是在Metabase中——为您的第一个客户创建一个用户账户。此用户账户应只具有访问数据库中特定表或模式的权限。例如,如果您有一个Postgres数据库,您需要通过psql将用户添加到您的数据库中。然后,在Postgres中,您将只授予他们查看您希望客户看到的表(的)的权限。
-
在Metabase中,使用您在数据库中刚刚创建的用户账户添加数据库连接。
-
在Metabase中创建一个新的组。授予该组访问您新添加的数据库——即与该客户模式对应的连接。由于数据库级别的用户角色决定了您的客户可以查看什么,因此您可以授予该组对数据库的可查看访问权限,以及与其一起的查询构建器和原生访问权限。
属于该组的用户将能够看到Metabase中所有表,这些表是在Postgres用户(或您正在使用的任何数据库)中可访问的。如果您以后想隐藏一个表,您需要更改数据库本身的权限,而不是在Metabase中更改。即使您在Metabase中隐藏了一个表,具有原生访问权限的人仍然可以查询它们。
-
邀请第一个用户,在此过程中将其添加到适当的组中。如果您使用SSO来处理账户创建,则无需手动邀请用户。
-
为您的其他客户重复步骤1-4。在Metabase中,它将看起来像您为您的客户添加了与客户数量一样多的数据库。
以编程方式创建沙盒权限
如果您为数百或数千个客户提供支持,请考虑使用Metabase API编写脚本来处理权限过程。如果您需要设置新的Metabase实例或希望为每个客户复制相同的仪表板和保存的问题,序列化功能(在Pro和Enterprise计划中可用)可以帮助您加快速度。请注意,序列化不包括权限设置,因此您需要编写脚本或手动配置哪些组可以访问每个表。
进一步阅读
下一节:如何跟踪您的数据
设置使用分析用法的警报以接收有关人们更改设置、下载数据或公开数据的通知。