Metabase 的权限方法

起初，万物和谐且充满爱。
然后，野蛮人出现在城门外
所以我们建了一道篱笆
但我们仍然希望篱笆内保持和谐与爱

Metabase 项目在权限和访问控制方面有着有趣的历程。我们一方面倡导完全透明，另一方面对我们内部运行的实例实施了极其严格的访问控制限制。

首先，简单回顾一下历史——Metabase 最初是 Expa (www.expa.com) 的内部分析系统。在此期间，Metabase 存在着矛盾的需求。一方面，我们希望每个公司都深入地以数据为驱动，并推广公司上下广泛访问信息、分析和自下而上探索。另一方面，我们有各种各样有着截然不同业务、公开形象以及安全威胁模型的公司。最初，我们采用了常规方法，建立了一个相当通用的权限模型。我们将每个公司划分到一个独立的组，并赋予该组访问我们集中式数据仓库中公司数据的权限。如果您热衷于源代码的取证，您可以在我们最初的公开提交记录中找到各种有趣的痕迹。在逐步加强安全性的过程中，我们最终决定在不同公司的数据之间创建硬分区会更有意义。用户账户、应用程序数据以及底层数据仓库都被分开存储在独立的虚拟机上，应用程序也随之慢慢演变。

当我们开源 Metabase 时，我们沿用了这种相当二元的视角，并期望 Metabase 的主要用途是小型公司或大型公司内相对同质化的团队。随着我们在更大、更多元化的公司中获得采用，我们收到了反馈，认为这种世界观划分有些……怎么说呢，天真？控制访问权限的方法一直是大家反馈列表中的重中之重。GitHub 上有许多被广泛投票的关于访问控制的问题。人们甚至亲自打电话要求我们实现这一功能。

同时，团队一直有些犹豫，不想只是“随意地在其上添加一个糟糕的 LDAP 版本”。从项目开始，我们就强烈希望交付一个简单、优雅且易于使用、安装和管理的应用程序。为了使我们最终的权限系统能够实现这些目标，我们决定收集尽可能多的信息，了解用户在访问控制方面的各种场景。我们在 GitHub 和面对面进行了大量对话，并一直在慢慢地整合这些基本问题的解决方案。

我们很高兴地宣布，从我们最新的版本 (0.20) 开始，我们将推出一个权限框架，用于提供对数据的受控访问。

本质上，我们在 0.20 版本中推出的权限框架很简单——您可以将用户分配到组，并将组分配到数据访问权限。组可以对数据库、表和原始 SQL 访问进行限制。Metabase 将根据给定用户的组数据访问权限来确定他们可以看到哪些仪表板、问题和通知。简而言之，我们侧重于用户可以访问的数据，而不是他们可以看到哪些仪表板。为什么我们这样做，而不是直接控制谁可以看到哪个仪表板或问题？

我们认为，在锁定 Metabase 安装时，您应该添加最少的控制措施，以确保您想要控制的数据安全，同时仍然允许您的终端用户提出（并回答！）他们自己的问题。

专注于控制对特定工件访问的应用程序，总是会不可避免地导致公司中 99% 的报告是由少数几个分析师构建的，而这些分析师拥有生成任何有用信息所需的底层数据访问权限。虽然这对于公司中的自上而下的信息分发来说效果相当不错，但它扼杀了自下而上的探索。它还有一个令人不愉快的副作用，即数据提取和报告的临时请求充斥着分析师团队。

在 Metabase，我们是建设性懒惰的坚定信徒。通过在前期投入一些时间，为公司内各组数据进行划分和准备，您可以让您的终端用户回答大量可能否则会占用您工程师和分析师时间的临时问题。这将使您的分析师、数据科学家和工程师能够去做更有价值的事情——构建抢票机器人来获取《汉密尔顿》的门票，与家人共度时光，或者在极端情况下甚至进行深入、有见地的业务分析。

在接下来的几个版本中，我们将添加更多锁定您实例的方法。我们将扩展用户组的功能并提供更强大的权限工具。我们将引入帮助您锁定特定问题/仪表板的方法，尽管我们强烈建议您尽力为您的终端用户提供探索、提问和互相帮助的空间。