數據平台許可權的幾個層次

幾乎每家公司都有自己的大數據平台, 數據平台的許可權管理是個要想清楚的事情, 在確定好許可權管理的策略前, 可以先聊聊許可權管理可以從哪裡入手, 這個東西也是分成幾個層的.

文件系統層面

類似 Hive 這樣的數據平台, 所有的數據都存儲在分散式文件系統上(例如 HDFS 或者 類似 AWS S3 的對象存儲系統), 那麼我們就可以在這個層面進行許可權的控制, 例如使用 HDFS 的文件許可權模型, 或者使用 AWS IAM 的許可權進行控制. 但這種方式有幾點不足:

許可權只有在執行數據讀取或者寫入的階段才會告知用戶沒有許可權而報錯, 用戶體驗不好

用戶是可以看到數據的 Meta 信息的, 例如 Table 的 column 信息等.

AWS EMR 中不支持一個 EMR cluster 中使用多個 InstanceProfile, 因此無法做到一個集群中執行計算的不同用戶能夠使用不同的 AWS Credential, 進而無法從這個層面控制許可權. 一種解決方案是針對不同的用戶使用不同的 EMR 集群提交計算任務, 這種方式會導致集群利用率低; 另一種解決方式就是在 EMR 中使用自己開發的 CredentialProvider 調用 AWS 的 STS 服務獲取不同的 Credential 實現許可權控制. 這個一句話兩句話說不清楚, 改天可以單獨寫一篇: 如何在一個 EMR 集群中實現多租戶的許可權控制

資料庫層面

文件系統之上就是資料庫層面. 幾乎所有的資料庫都有自己的許可權控制系統, Hive 也不例外. 業界可選的方案也很多. 基本上是可以控制表級別的許可權: 用戶對某個表是否有 CRUD 的許可權.

如果覺得現有的方案不能滿足需求, 定製化開發也相對容易, 只需要通過解析 SQL 獲取到 SQL 代碼中想要 CRUD 操作的 Table 的列表, 再請求許可權系統看用戶是否有對應的許可權即可.

圖片來自 Apache Sentry 官放文檔

在資料庫層面控制許可權也有缺點: 太粗獷. 例如 SELECT 許可權僅僅限制到 Table 一層, 用戶一旦有了許可權就可以查詢全表數據, 就要求 Table 中的數據必須是嚴格控制的; 如果想控制用戶僅僅查詢 Table 中數據的子集, 最簡單的解決辦法是通過 View 的方式實現, 但如果用戶多了這個方案就不現實. 業界已有的方案例如 Apache Sentry 和 Apache Ranger 也非常值得考慮或者借鑒.

應用層面

還好, 我們還有應用層. 應用層是指在資料庫層面之上構建的數據應用, 最直觀的例子就是報表. 在應用層面我們就可以更精細化的控制許可權, 例如一個用戶僅僅能查詢到自己所在部門的業績, 只需做一個他們部門的報表即可, 查詢中寫死了他所所在部門的 ID 就控制好許可權.

三個層面的許可權控制對比如下:

選擇原則

總結幾個原則, 歡迎吐槽:

Least Privilege Principle

許可權一律給到最小, 最容易犯的錯誤就是只讀許可權: 如果只有隻讀許可權, 那就一定不會給寫許可權, 避免誤操作的發生.

只讀許可權盡量貫徹到文件系統層

一般數據平台都會有隻讀許可權的需求, 例如 Presto 集群作為 ad-hoc 查詢, 基本上不會寫 ETL 後的資料庫, 那麼從文件系統上限制 Presto 集群只有隻讀許可權就非常合適, 確保一定不會有人寫入數據到線上庫

保留所有的訪問日誌

無論哪種方式的訪問, 必須保留訪問日誌, 方便後續定位問題. 這一點在 AWS S3 上就很容實現, 直接通過 Access Log 功能即可保留訪問日誌.

— EOF —

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！