Metabase 的权限方法

最初，一切都充满和平与爱。
然后，野蛮人出现在门前
于是我们建造了围栏
但我们仍希望围栏内充满和平与爱

Metabase 项目在权限和访问控制方面有着有趣的关系。我们同时倡导完全透明，同时对我们内部运行的实例实行极其严格的访问控制限制。

首先回顾一下历史——Metabase 最初是 Expa (www.expa.com) 的内部分析系统。在那段时间里，Metabase 面临着相互冲突的需求。一方面，我们希望每家公司都能深度数据驱动，并提倡公司范围内的信息访问、分析和自下而上的发现。另一方面，我们有各种业务截然不同、公共形象迥异的公司，因此安全威胁模型也各不相同。起初，我们走了寻常路线，采用了相当通用的权限模型。我们将每家公司划分为自己的独立组，并授予该组访问其公司在我们集中式数据仓库中数据的权限。如果您倾向于源代码取证，可以在我们最初的公共提交中找到各种有趣的遗留痕迹。随着我们逐步收紧控制，最终决定在不同公司的数据之间创建硬分区会更有意义。用户账户、应用程序数据以及底层数据仓库都被拆分并存储在独立的虚拟机上，应用程序也随之缓慢演变。

当我们开源 Metabase 时，我们保留了这种相当二元的世界观，期望 Metabase 的主要用途是在小型公司或大型公司内部相对同质的团队中。然而，随着我们发现其在规模更大、更异构的公司中获得采用，我们收到了反馈，认为这种世界划分方式有点……怎么说呢，天真？我们与所有交流过的人都提到，控制访问权限的方式一直是最受关注的反馈之一。在 GitHub 上有大量与访问控制相关的、获得广泛投票的问题。人们甚至直接打电话给我们来提出这个请求。

与此同时，团队对于简单地“草率地加上一个糟糕的 LDAP 版本”一直有些犹豫。从项目伊始，我们就强烈希望发布一个简单、优雅且易于使用、安装和管理的应用程序。为了使我们最终的权限系统能够满足这些目标，我们决定尽可能多地收集用户在需要访问控制方面的各种场景信息。我们在 GitHub 上以及面对面进行了大量讨论，并一直在缓慢地综合出解决这些根本问题的方案。

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

其核心是，我们在 0.20 版本中推出的权限框架很简单——您可以将用户分配到组，并授予组访问数据的权限。组可以对数据库、表和原始 SQL 访问施加限制。Metabase 将根据用户组的数据访问权限来判断给定用户可以看到哪些仪表板、问题和脉冲。简而言之，我们将您的注意力集中在用户有权访问哪些数据上，而不是他们可以查看哪些仪表板。我们为什么这样做，而不是直接让您直接控制谁可以查看哪个仪表板或问题？

锁定 Metabase 安装时，我们认为您应该添加最少的必要控制，以保护您希望受控的数据，同时让您的最终用户仍能提出（并回答！）自己的问题。

那些专注于控制对特定构件访问的应用程序，往往会导致公司中 99% 的报告由少数能够访问生成任何有用内容所需底层数据的分析师创建。虽然这对于公司内部自上而下的信息分发效果尚可，但它扼杀了自下而上的发现。它还带来了一个不愉快的副作用，即用临时的数据提取和报告请求淹没分析师团队。

在 Metabase，我们坚信建设性的懒惰。通过提前花费一些时间，为公司内的各个团队划分并准备好数据，您可以让您的最终用户回答大量原本会占用您的工程师和分析师的临时性问题。这让您的分析师、数据科学家和工程师可以自由地做更有价值的事情——例如构建抢票机器人获取《汉密尔顿》的票、与家人共度时光，或者在极端情况下，甚至对您的业务进行深入、富有洞察力的分析。

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