权限的Metabase方法

起初，一切都很和平与爱。
然后野蛮人出现在大门前
所以我们建了一道篱笆
但我们仍然希望在篱笆内保持和平与爱

Metabase 项目在权限和访问控制方面有着有趣的关系。我们一方面推动了完全的透明度，另一方面对我们运行的内部实例实施了非常严格的访问控制限制。

首先简要回顾一下历史——Metabase 最初是内部 Expa (www.expa.com) 分析系统。在那个时期，Metabase 存在着冲突的需求。一方面，我们希望每个公司都能深度数据驱动，并推广公司范围内的信息、分析和自下而上的发现。另一方面，我们有着各种业务、公众形象截然不同的公司，因此存在不同的安全威胁模型。一开始，我们采取了通常的做法，并拥有相当通用的权限模型。我们将每个公司分离开来，将其作为独立组，并赋予该组访问公司数据在我们集中式数据仓库中的权限。如果你倾向于源代码取证，你可以在我们最初的公共提交中找到各种有趣的遗迹。随着我们逐步锁定系统，我们最终决定在各个公司的数据之间创建硬分区。用户帐户、应用程序数据和底层数据仓库都被分割，存储在不同的虚拟机上，应用程序也相应地慢慢转变。

当我们开源 Metabase 时，我们带着这种相当二元的世界观，预计 Metabase 的主要用途将是小型公司或在大型公司内相对同质化的团队中。随着我们在更大、更异质化的公司中的采用，我们收到了反馈，认为这种世界观的划分有点……我们可以说是幼稚的？控制访问权限是每个人反馈列表中的主要内容。GitHub 上有关访问控制的议题数量众多，投票广泛。人们甚至打电话给我们要求这一点。

与此同时，团队对只是“简单地将一个糟糕的LDAP版本应用上去”有些犹豫。从项目开始，我们就强烈希望发布一个简单、优雅、易于使用、安装和管理的应用程序。为了最终使我们的权限系统满足这些目标，我们决定尽可能收集用户在需要访问控制的各种场景下的信息。我们在github上以及面对面进行了很多讨论，并逐渐将这些潜在问题综合成一个解决方案。

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

在0.20版本中，我们提供的权限框架在核心上是简单的——您可以分配用户到组中，并可以为组提供对数据的访问权限。组可以对数据库、表和原始SQL访问进行限制。Metabase将根据用户的组数据访问权限确定用户可以看到哪些仪表板、问题和脉冲。简而言之，我们关注的是用户可以访问哪些数据，而不是他们可以查看哪些仪表板。

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

专注于控制对特定工件访问的应用程序，不可避免地会导致99%的报告都由少数有权访问所需数据的分析师构建的公司。虽然这在上行信息在公司中分布方面效果还不错，但扼杀了下行发现。它还带来了一个不愉快的副作用，那就是分析师池中充斥着即兴的数据提取和报告请求。

在Metabase，我们是积极懒惰的坚定支持者。通过在前端花点时间，为您的公司中的各个组分区和准备数据，您可以让最终用户回答许多其他情况下会占用您的工程师和分析师时间的即兴问题。这可以让您的分析师、数据科学家和工程师有更多的时间去做更有价值的事情——比如抢票、和家人共度时光，或者在极端情况下对业务进行深入、有洞察力的分析。

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