Metabase 的权限管理方法

最初，一切都是和平与爱。
然后，野蛮人来到了城门
所以我们筑起了围栏
但我们仍然希望围栏内是和平与爱

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

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

当我们开源 Metabase 时，我们延续了这种相当二元的世界观，期望 Metabase 的主要用途是在小型公司或大型公司中相对同质的团队。随着我们发现它在更大、更异构的公司中得到采用，我们收到的反馈是，这种世界划分有点……怎么说呢，有点天真？控制访问权限的方法一直是我们与所有交谈过的人的反馈中排名靠前的需求。在 GitHub 上有大量与访问控制相关的、获得广泛投票的问题。人们甚至直接打电话给我们请求这个功能。

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

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

其核心是，我们将在 0.20 中发布的权限框架很简单——您可以将用户分配到组，并授予组数据访问权限。组可以对数据库、表格和原始 SQL 访问进行限制。Metabase 将根据用户的组数据访问权限，确定给定用户可以看到哪些仪表盘、问题和脉冲。简而言之，我们关注用户可以访问哪些数据，而不是他们可以直接查看哪些仪表盘。我们为什么这样做，而不是直接让您控制谁可以看到哪个仪表盘或问题？

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

侧重于控制对特定人工制品访问的应用程序，最终往往会导致公司中 99% 的报告由少数分析师构建，这些分析师拥有生成任何有用报告所需的底层数据访问权限。虽然这对于公司自上而下的信息分发效果良好，但它扼杀了自下而上的发现。它还带来了一个令人不快的副作用，即大量向分析师池提交临时数据提取和报告请求。

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

在接下来的几个版本中，我们将添加其他方法来进一步锁定您的实例。我们将扩展用户组的功能并提供更强大的权限工具。我们还将引入方法来帮助您锁定特定的问题/仪表盘，尽管我们强烈建议您尽力给最终用户留出空间来发现、提问和互相帮助。