在您的多租户数据周围设置强边界

这是什么意思

在 Metabase 中定义规则，限制用户可以看到哪些行和列。基于用户 ID、组、区域等属性。应用于问题和仪表板，而非原生 SQL。

何时使用

• 您需要对每个人可以看到和使用的数据进行精细控制
• 您希望通过 UI 来控制访问
• 您需要针对每个组/组织进行灵活控制

示例用例

适用于内部商业智能：全国性物流公司西海岸车队经理只能看到与西海岸车队和交付相关的数据。

权衡/何时不适用

• 不适用于原生/SQL 查询
• 您正在使用非 SQL 数据库，如 Druid（尽管 Metabase 支持 MongoDB 的基本 RLS）

这是什么意思

Metabase 以实际用户（或角色）身份连接到数据库。您在数据库本身中定义 RLS 策略、角色和访问控制。Metabase 仅通过用户身份（例如，通过 SET ROLE 或代理用户）传递用户身份。

何时使用

• 您希望将访问逻辑集中在数据库中
• 原生查询必须遵守访问控制
• 您对用户属性配置错误有更高的担忧
• DBA 集中管理安全

示例用例

为您的 HR SaaS 应用用户设置基于角色的权限，以便经理只能看到其直接下属的数据。

权衡/何时不适用

• 并非所有数据库都支持
• 增加了复杂性（用户管理、设置）
• 在 Metabase 中缓存效果不佳
• 对小型团队或非 DBA 来说不太友好

这是什么意思

当您将租户数据存储在单独的数据库中时，数据库路由可确保每个租户只能看到其相应数据库的结果。管理员可以在主数据库中构建仪表板和问题，然后根据用户属性将查询路由到正确的数据库。

何时使用

• 您希望最强的隔离。最适合合规性或“邻里效应”，尤其是在多租户嵌入式分析上下文中
• 您对用户属性配置错误有更高的担忧
• 避免跨租户性能影响

示例用例

当 Acme 的查询通过 SaaS 应用中的嵌入式仪表板运行时，并且后端数据在数据库级别分开时，Acme 的查询将转到 Acme 的数据库。

权衡/何时不适用

• 如果您不需要在数据库级别上分离租户数据，则不是必需的
• 更高的运营复杂性 - 您更希望在 Metabase UI 中管理权限

这是什么意思

在显示之前嵌入具有过滤结果的仪表板（例如，org_id = 123）。这些过滤器不可见且防篡改。通过您的主机应用程序中的属性进行控制，例如用户名或 tenant_ID。

何时使用

• 嵌入式分析的轻量级租户隔离
• 简单但安全的访问控制
• 避免向最终用户暴露敏感过滤器

示例用例

在您的电子商务应用中嵌入仪表板时，使用您的主机应用程序传递的隐藏卖家 ID 显示每个卖家的销售额。

权衡/何时不适用

• 没有用户登录、SSO 或角色意识
• 不建议用于高风险数据