行和列安全

行和列安全性允许您为不同的人群授予细粒度的权限。您可以更改一个群组可以查看的数据，以及一个群组可以使用查询构建器查询的数据。

您可以使用行和列安全性来设置自助式分析，这样您的每个客户就只能查看与其客户 ID 匹配的行。例如，如果您有一个包含客户信息的“Accounts”表，您可以为该表添加权限，以便每个客户只能看到与他们相关的数据。

行和列安全以前称为数据沙盒。这是同一个功能，只是现在有了更具描述性的名称。

行和列安全示例

您可以跳过理论，直接查看行和列安全性的示例。

行和列安全性的工作原理

您可以将行和列安全性视为一捆权限，其中包括

• 表的筛选版本，它将在 Metabase 中所有使用原始表的地方替换原始表。
• 应该看到该表筛选版本的人员群组。

您可以为 Metabase 中的每个表/群组组合定义最多一个行和列安全策略。这意味着您可以为不同的群组显示不同版本的表，例如向您的销售人员显示“销售人员的账户”，向销售经理显示“经理的账户”。

行和列安全性的类型

行和列安全性根据每个人的用户属性向其显示特定数据。您可以：

• 限制行
• 为特定人员限制列和行。

行级安全性：按表中的列筛选

您可以通过使用用户属性值筛选列来限制行。

例如，您可以为某个群组筛选“Accounts”表，使得：

• 用户属性值为“Basic”的人将看到Plan = "Basic"的行（即 Plan 列匹配值“Basic”的行）。
• 用户属性值为“Premium”的人将看到Plan = "Premium"的行（即 Plan 列匹配值“Premium”的行）。

自定义行和列安全性：使用 SQL 问题创建表的自定义“视图”

要限制行和列，您可以使用 SQL 问题来筛选表。当有人查看该表时，他们将看到问题的结果，而不是原始表。

例如，假设您的原始 Accounts 表包括以下列：ID、Email、Plan 和 Created At。如果您想隐藏 Email 列，可以创建一个“受限账户”SQL 问题，其中包含以下列：ID、Plan 和 Created At。

您可以使用问题来筛选表以：

• 显示编辑后的列，而不是隐藏该列.
• 将用户属性传递给 SQL 参数.

行安全性的先决条件

• 一个要添加行安全性的人员群组。
• 群组中每个人的用户属性。

行安全性将一个筛选过的表显示给特定群组，以代替原始表。Metabase 如何筛选该表取决于每个人的用户属性中的值。

例如，您可以设置行级安全性，以便

• 具有键为“plan”、值为“Basic”的用户属性的人将看到一个带有 Plan = "Basic" 筛选器的 Accounts 表版本（即，只有 Plan 列匹配值“Basic”的行）。
• “plan”用户属性设置为“Premium”的人将看到应用了 Plan = "Premium" 筛选器的 Accounts 表的另一个版本。

为行和列安全性选择用户属性

用户属性是行安全性所必需的，对于列安全性则是可选的。在添加新用户属性时，您需要为每个人设置一个键值对。

Metabase 使用用户属性键来查找特定人员的用户属性值。用户属性键可以映射到 Metabase 中的参数。

用户属性值必须与筛选器值完全匹配，且区分大小写。例如，如果您为“Accounts”表添加了行安全性，并使用筛选器 Plan = "Basic"，请确保输入“Basic”作为用户属性值。如果您将用户属性值设置为小写的“basic”（一个在“Accounts”表的“Plan”列中不存在的值），那么该用户将得到一个空结果而不是该表。

用户属性使用示例

• 行安全性
• 限制行和列

添加行级安全性

1. 请务必先完成行安全性的先决条件。
2. 前往 管理设置 > 权限。
3. 选择您想要保护的数据库和表。
4. 找到您想要进行安全设置的群组。
5. 点击该群组下查看数据的下拉菜单。
6. 选择“行和列安全性”。
7. 点击列下的下拉菜单，并输入用于筛选表的列，例如“Plan”。
8. 点击用户属性下的下拉菜单，并输入用户属性的键，例如“Plan”。

如果您有查询具有行级安全性数据的 SQL 问题，请确保将所有这些问题移动到仅管理员可见的集合中。更多信息，请参阅您无法保护 SQL 结果的行或列。

查看行和列安全性示例。

列级安全性的先决条件

• 一个人员群组。
• 一个仅限管理员的集合，其集合权限应设置为除管理员外所有群组均为无访问权限。
• 一个SQL 问题，包含要向群组中的人员显示的行和列，并存储在仅限管理员的集合中。
• 可选：如果您也想限制行，请为群组中的每个人设置用户属性。

创建一个 SQL 问题供 Metabase 显示，以代替一个表

Metabase 将把该问题的结果显示给特定群组，以代替原始表。

使用 SQL 问题来定义要包含在自定义视图中的确切行和列。避免使用查询构建器（GUI）问题，因为您可能会意外暴露额外的数据，因为 GUI 问题可以包含来自其他问题或模型的数据。

请确保将 SQL 问题保存在仅限管理员的集合中（集合权限设置为除管理员外的所有组都为无访问权限）。更多信息，请参阅您无法保护 SQL 结果的行或列。

显示编辑过的列

除了排除行和列，您还可以显示编辑过的列（而无需更改数据库中的列）。

例如，您可以创建一个“已编辑账户”的 SQL 问题，该问题会截断“Email”列以显示用户名而不是完整的电子邮件地址。

如果您编辑了一个列，SQL 问题的模式（您想用来代替表显示的问题）必须与原始表的模式匹配。这意味着“已编辑账户”SQL 问题必须返回与原始“账户”表相同数量的列和相应的数据类型。

您不能添加列。

设置列安全性

1. 请确保先完成先决条件。
2. 前往 管理设置 > 权限。
3. 选择您想要保护的数据库和表。
4. 找到要限制的群组。
5. 点击该群组下数据访问的下拉菜单。
6. 选择“行和列安全性”。
7. 选择“使用已保存的问题为此表创建自定义视图”。
8. 选择您保存的问题。该问题应该用 SQL 编写。如果问题包含参数，那些参数必须是必需的（它们不能是可选的）。
9. 可选：根据人员的用户属性限制行。

您可以在行和列安全性示例中找到示例设置。

使用 SQL 变量根据用户属性限制行

如果您设置了列安全性，您还可以根据每个人的用户属性为他们限制不同的行。例如，您可以为一组显示带有筛选条件 Plan = "Basic" 的“Accounts”问题，为另一组显示带有筛选条件 Plan = "Premium" 的问题。

1. 确保您已完成所有列级安全性的先决条件。
2. 转到将替代表显示给人们的 SQL 问题。
3. 在您的 SQL 查询中添加一个参数化的 WHERE 子句，例如 WHERE plan = {{ plan_variable }} 。
4. 保存 SQL 问题。
5. 前往 管理设置 > 权限。
6. 找到您想要保护的群组和表。
7. 打开查看数据下的下拉菜单。
8. 点击编辑行和列安全性。
9. 向下滚动并将参数或变量设置为您 SQL 问题中参数的名称（例如，“Plan Variable”）。
10. 将用户属性设置为用户属性键（例如，键“User's Plan”，而不是值“Basic”）。
11. 点击保存。

有关 SQL 变量和用户属性设置的示例，请参阅行和列安全性示例。

行限制如何与列安全性协同工作

一个标准的 WHERE 子句通过将一列设置为固定值来筛选一个表。

WHERE column_name = column_value

在上述行限制设置的第 2 步中，您将添加一个 SQL 变量，以便 WHERE 子句可以接受一个动态值。SQL 变量类型必须是文本、数字或日期。

WHERE plan = {{ plan_variable }}

在行限制设置的第 9-10 步中，您正在告诉 Metabase 将 SQL 变量 plan_variable 映射到一个用户属性键（例如“User's Plan”）。Metabase 将使用该键来查找与某人 Metabase 账户关联的特定用户属性值（例如“Basic”）。当该人登录 Metabase 并使用受保护的表时，他们将看到基于以下条件筛选的查询结果：

WHERE plan = "Basic"

请注意，用于创建自定义视图的 SQL 问题中的参数必须是必需的。例如，您不能使用可选参数；以下内容将不起作用：

[[WHERE plan = {{ plan_variable }}]]

了解更多关于SQL 参数的信息

防止行和列安全性权限冲突

某些 Metabase 权限可能与行和列安全性冲突，从而导致数据访问权限比您预期的更宽松或更严格。

假设您已经为某个特定群组设置了列安全性，隐藏了“Accounts”表中的“Email”列。

Email 列可能会暴露给某人，如果：

• 该人员属于多个行和列安全策略。
• 在非安全群组中的其他人从以下来源分享了 Email 列：
  • 一个SQL 问题。
  • 一个公开链接
  • 一个警报或仪表盘订阅

多个行和列安全性权限

对同一张表设置多个行和列安全策略可能会导致权限冲突。您最多可以将一个人（通过其所属群组）添加到每个表的一个行和列安全策略中。

例如，如果您有：

• 为“Basic Accounts”群组设置了安全性，该群组将 Accounts 表筛选为 Plan = "Basic"。
• 为“Converted Accounts”群组设置了另一个筛选，该群组将 Accounts 表筛选为 Trial Converted = true。

如果您将 Vincent Accountman 同时放在这两个组中，他将对“Accounts”表拥有冲突的权限，并且每当他尝试在 Metabase 中使用“Accounts”时都会收到错误消息。

要解决行和列安全性权限冲突：

• 将该人员从除一个之外的所有群组中移除。
• 将除一个之外的所有群组对该数据库的查看数据权限设置为“已阻止”。

您无法保护 SQL 结果的行或列

行和列安全性权限不适用于 SQL 问题的结果。也就是说，SQL 问题将始终显示来自原始表的结果，而不是受保护的表。

假设您已经在“Accounts”表上设置了列安全性以隐藏“Email”列。如果有人创建了一个包含“Email”列的 SQL 问题，任何有集合权限查看该 SQL 问题的人都将能够：

• 在 SQL 问题结果中看到“Email”列。
• 使用该 SQL 问题开始一个包含“Email”列的新问题（如果他们有查询权限）。

为防止通过 SQL 问题暴露“Email”列：

• 将任何包含“Email”列的 SQL 问题放入一个单独的集合中。
• 对于设置了行和列安全性以隐藏“Email”列的群组，将其集合权限设置为无访问权限。

必须使用集合权限来防止受保护的群组查看引用受保护表的 SQL 问题。

公开分享

行和列安全性权限不适用于公开问题或公开仪表盘。如果某个非安全群组中的人使用原始表创建了一个公开链接，那么任何拥有该公开链接 URL 的人都可以看到原始表。

为防止这种情况发生，您必须为您的 Metabase 禁用公开分享。

Metabase 只能使用已登录人员的群组成员资格或用户属性来创建行和列安全性。由于公开链接不需要登录，Metabase 将没有足够的信息来应用权限。

限制

行和列安全性仅限于使用查询构建器构建的问题。

拥有原生查询权限（访问 SQL 编辑器）的群组可以绕过行和列安全性

您不能为具有行和列安全性的群组设置原生查询权限。

要使用原生查询编辑器强制执行行级权限，请查看模拟。

您不能将行和列安全性应用于 SQL 问题

由于 Metabase 无法解析 SQL 查询，SQL 问题的结果将始终使用原始表。

使用集合权限来防止群组查看包含受限数据的已保存 SQL 问题。

非 SQL 数据库的行和列安全性有限

MongoDB 仅支持行级安全性。行和列安全性权限不适用于 Apache Druid。

延伸阅读

• 行和列安全示例
• 权限策略
• 配置嵌入权限
• 保护嵌入式 Metabase