Metabase 權限方法

起初，一切和平美好。
接著野蠻人出現在門口
所以我們築起了圍牆
但我們仍然希望圍牆內和平美好

Metabase 專案在權限與存取控制方面，有著一段有趣的關係。我們一方面提倡完全透明化，另一方面又對我們內部運行的實例，施加極其嚴格的存取控制限制。

首先，簡述一下歷史背景 — Metabase 最初是 Expa (www.expa.com) 內部分析系統。在那段時期，Metabase 有著相互衝突的需求。一方面，我們希望每間公司都由數據深度驅動，並提倡公司範圍內的信息、分析和由下而上的探索權限。另一方面，我們擁有多家業務、公開形象，以及隨之而來的安全威脅模型都截然不同的公司。一開始，我們採取了慣常的做法，並採用了相當通用的權限模型。我們將每間公司劃分到各自的群組中，並授予該群組在我們集中式數據倉儲中存取公司數據的權限。如果您傾向於原始碼鑑識，您可以在我們最初的公開提交中找到各種有趣的殘餘。隨著我們逐步鎖定各項事物，我們最終決定，在不同公司的數據之間建立硬分割更有意義。用戶帳戶、應用程式數據和底層數據倉儲都被分割開來，並儲存在不同的虛擬機器上，而應用程式也逐漸演變以響應這種情況。

當我們將 Metabase 開源時，我們延續了這種相當二元的觀點，並期望 Metabase 的主要用途將會是在小型公司或大型公司內相對同質的團隊中。隨著我們發現它在規模更大、異質性更高的公司中被採用，我們收到了回饋，認為這種世界劃分方式有點…可以說是很天真嗎？控制存取權限的方式一直是我們與之交談過的每個人的回饋重點。在 github 上有許多與存取控制相關、廣泛投票的問題。人們甚至直接打電話給我們要求此功能。

與此同時，團隊一直不願意只是「隨便套用一個糟糕的 LDAP 版本」。從專案一開始，我們就強烈希望交付一個簡單、優雅且易於使用、安裝和管理的應用程式。為了最終使我們的權限系統滿足這些目標，我們決定盡可能收集更多關於用戶需要存取控制的各種情境的信息。我們在 github 上以及面對面進行了許多對話，並一直在慢慢綜合解決這些根本問題的方案。

我們很高興地宣布，從我們的最新版本 (0.20) 開始，我們將推出一個權限框架，可用於提供對數據的受控存取。

在核心方面，我們在 0.20 中發布的權限框架很簡單 — 您可以將用戶分配到群組，並且可以授予群組存取數據的權限。群組可以對資料庫、表格和原始 SQL 存取設定限制。Metabase 將根據用戶的群組數據存取權限，判斷給定用戶可以看到哪些儀表板、問題和 Pulse。簡而言之，我們將您的注意力集中在用戶可以存取哪些數據，而不是他們可以直接查看哪些儀表板。我們為何要這樣做，而不是讓您直接控制誰可以直接查看哪些儀表板或問題？

在鎖定 Metabase 安裝時，我們認為您應該新增最少數量的控制項，以保護您想要控制的數據，同時讓您的最終用戶仍然可以提出（和回答！）他們自己的問題。

專注於控制對特定成品存取的應用程式，總是容易導致公司中 99% 的報表都是由少數有權存取產生任何有用內容所需底層數據的分析師建立。雖然這對於公司中由上而下的資訊發布來說效果相當好，但它扼殺了由下而上的探索。它還會產生令人不快的副作用，即分析師群體會被臨時的數據提取和報告請求淹沒。

在 Metabase，我們堅信建設性的懶惰。通過預先花費一些時間，為您公司中的各個群組劃分和準備數據，您可以讓您的最終用戶回答大量臨時問題，否則這些問題會讓您的工程師和分析師忙得不可開交。這讓您的分析師、數據科學家和工程師可以自由地做更有價值的事情 — 建立搶票機器人來購買漢密爾頓歌劇的門票、陪伴家人，或者在極端情況下，甚至對您的業務進行深入、有見地的分析。

在接下來的幾個版本中，我們將新增其他進一步鎖定您實例的方法。我們將擴展用戶群組的功能，並提供更強大的權限工具。我們也將推出協助您鎖定特定問題/儀表板的方法，儘管我們強烈建議您盡可能讓您的最終用戶有空間去探索、提出問題並互相幫助。