Metabase 权限方法

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

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

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

当我们开源 Metabase 时，我们沿用了这种相当二元的看待世界的方式，并期望 Metabase 的主要用途将是在小公司或大公司内相对同质化的团队中。随着我们在更大、更多异构的公司中发现采用，我们收到了反馈，即这种世界划分有点……我们是否应该说幼稚？某种控制访问权限的方式一直是我们在与每个人交谈中收到的反馈列表中的首位。github 上有许多与访问控制相关的、广泛投票的问题。人们甚至直接打电话给我们来请求这个功能。

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

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

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

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

专注于控制对特定工件的访问的应用程序，总是会导致一家公司中 99% 的报告由少数可以访问生成任何有用内容所需的基础数据的分析师构建。虽然这对于公司中自上而下的信息分发效果相当好，但它扼杀了自下而上的发现。它还会产生令人不快的副作用，即大量的临时数据提取和报告请求涌入分析师池。

在 Metabase，我们坚信建设性的懒惰。通过预先花一点时间，为公司中的各个组划分和准备数据，您可以使您的最终用户回答大量临时问题，否则这些问题会束缚您的工程师和分析师。这使您的分析师、数据科学家和工程师可以自由地做更有价值的事情——构建抢票机器人来获取 Hamilton 的门票，与家人共度时光，或者在极端情况下甚至对您的业务进行深入、富有洞察力的分析。

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