![]()
桔妹導讀：在滴滴，數據是非常重要的資產，基於數據的數倉建設，數據分析、數據挖掘、數據科學等構建了滴滴的數據體系，支撐着滴滴的業務快速發展。在這個背景下，如何保障用戶獲取數據的易用性的同時可以更加安全，是對我們大數據平臺提出來的非常大的挑戰，本文將介紹下我們在面對挑戰下，在大數據權限安全建設上實踐。
提到安全，首先要面對的就是用戶認證，Hadoop 社區版本是沒有安全認證的，因此只要隨意 export HADOOP_USER_NAME=Anyone，就可以僞裝爲任意用戶操作集羣上的數據了，存在非常大的安全隱患。爲了解決用戶安全認證的問題，Hadoop 社區方案主要是基於 Kerberos，Kerberos 提供了比較完善安全認證的能力，但是運維成本比較高，而且 KDC 容易成爲性能瓶頸，綜合考慮下，我們基於 Hadoop 自研了一套易於運維管理的賬號密碼認證機制，流程交互大致如下圖：
![]()
1.2 Beeline/JDBC：
密碼驗證 我們在 Server.java 增加了密碼校驗功能，代碼如下：
密碼更新 密碼配置是以本地文件存在 Namenode 本地，然後定時進行刷新到 namenode 內存中
使用了 hive 提供的用戶自定義安全驗證，其中密碼校驗模塊是我們自己實現的類似上述 Namenode 機制，具體如下配置：
這裏主要是基於滴滴的數夢用戶管理平臺，主要是用來管理多租戶的，維護着用戶的數據資產信息，包括密碼信息管理；涉及到密碼管理，主要提供了3個功能，密碼生成，密碼維護，密碼同步到服務端（Namenode和Hive server）。
通過上面的各模塊落地，當前我們是建設了一套相對比較完善的賬號認證機制，通過賬號和密碼實現了用戶身份的安全認證，但是僅有用戶認證是不夠的，同時最複雜的其實是權限鑑權體系，下面我將介紹下我們的權限鑑權是怎麼做的。
說起滴滴的大數據權限機制，我們其實是經歷了從0到1，又從1到2的過程，最早我們是基於 Hive SQL Standard-based+ HDFS UGO 機制構建了一套基於 hive 表粒度的權限體系，但是隨着業務的發展和數據安全的訴求，我們在2018年對權限體系進行了重構 ，基於 Ranger 建設了基於列級別鑑權的數據權限體系，下面將具體說下，我會先講下滴滴的數據權限的模型，以及我們是怎麼實現的。
我們是設計了一套基於字段策略的 RBCA 的權限體系，下面具體展開說下。
首先需要說下滴滴的數據分級，爲了保障數據安全，在滴滴數據是做了非常嚴格的安全級別劃分，依據數據的價值和敏感程度，從低到高劃分爲4個安全級別：公開數據(C1)、內部數據(C2)、祕密數據(C3)、機密數據(C4)，基於安全等級不同，也指定了不同數據的訪問權限審批模型，比如 C3及以下降低一些審覈門檻；C4則需要更加嚴格審批流程才能使用。
我們是基於 RBCA 權限模型設計的權限體系，因此我們主要涉及到用戶，角色，權限三個實體
爲什麼要做基於字段的權限控制呢，主要是因爲數據分級是按照具體數據內容來定義的，即是按照具體字段的數據來定義數據的安全等級，而不是按照表級別，很多情況下一張 Hive 表往往包括了好多字段數據，安全等級也是不一樣，如果不支持字段級別鑑權，往往會有大量的表成爲 C4表，這樣一來一方面對安全的挑戰是比較大的，另一方面也提高了用戶使用數據的門檻，因爲用戶往往的需求是訪問這個表的非 C4字段就夠了。因此支持字段級別鑑權是勢在必行，爲了把權限細化到字段，我們在ranger裏面配置的權限策略也細化到了字段級別，比如策略會配置爲 db.db.table.$column.c4。
爲了提升易用性，降低大家使用數據的門檻，我們通過不同的安全等級分成了不同的角色包，比如對於 C1,C2 的字段可高效低門檻訪問，這樣對用戶來說易用性大大的增強，對於我們來說也做到了字段級別的權限控制，保障了 C3,C4 數據的安全性，大致如下：
談到實現，先給給大家展示下我們目前權限體系大致系統交互流程，如下圖：
是不是有點小複雜，下面具體介紹各自模塊的作用以及權限體系是怎麼工作起來的！
主要是由滴滴安全部門負責進行對數據進行打標籤，通過實時訂閱 Kakfa 中的 DDL 事件獲取到數據的元數據信息和數據內容，通過安全算法，定義出數據的具體安全等級，將具體到表的字段級別，再把分級好的數據發送到 DDMQ（滴滴自研的消息隊列）。
面向用戶提供統一的元數據查詢管理服務，同時將實時訂閱 DDMQ 中的數據分級信息，及時更新數據的分級信。
用於人工進行表數據的分級設定或者修正，經過審覈，系統也將也將實時更新發布到 DDMQ 中。
用於提供表的樣例數據查詢，目前是基於 presto 隨機查詢10條樣例數據。
權限申請主要分爲 Hive 表權限的申請和 HDFS 權限的申請，大概如下圖：
用於爲數據查詢平臺類似數易報表，提取工具等服務提供基於 Restfull API 的 SQL 鑑權功能。值得說明的是，SQL 鑑權服務是獨立於 ranger 體系的，數夢平臺申請和維護權限的同時也將權限信息維護在數夢平臺的 mysql 中，獨立的提供了一套面向數據產品權限的鑑權服務。
基於數據分級信息，生成對應的 ranger 權限策略，並通過 Ranger admin 的 api 更新策略數據，關於 api 可以參考：
https://cwiki.apache.org/confluence/display/RANGER/REST+APIs+for+Service+Definition%2C+Service+and+Policy+Management
作用：用於維護着所有的權限策略，可以通過 Ranger Admin 進行權限的增刪改查，我們當前用的社區的0.6版本，更多信息可以參考
https://cwiki.apache.org/confluence/display/RANGER/0.6+Release+-+Apache+Ranger
高可用：目前我們是基於 LVS 做的負載均衡，後面部署着多臺 Ranger Admin 服務
作用：用於提供權限的查詢的 Thrift Server。需要說明的是 Ranger 原生鑑權架構是客戶端插件定時從 Ranger Admin 拉取所有的策略到本地，然後在本地進行的權限校驗，這個機制會導致3個問題：1，在策略很多的時候，會造成拉取變慢，影響 SQL 執行引擎的整體性能；2.客戶端比較多的情況下，客戶端插件同時拉取的時候，對 Ranger Admin 的壓力也會很大，機器帶寬也會成爲瓶頸；3，無法進行實時鑑權，比如用戶申請權限後還需要等幾分鐘纔可以生效，體驗非常不好。因此爲了解決上述痛點，我們基於 hive metastore 自研了中心化的實時鑑權方式。
架構：
拓展 Hive Metastore 的 thrift 接口，定義鑑權請求的各個參數
將 Ranger 插件的功能移植到 Metastore 上
實現 thrift 客戶端，增加 check_privilege 的 RPC
取消週期性的全量策略拉取，將創建 Evaluator 的邏輯從 Refresher 移到了 RangerHiveAuthorizer 調用 checkPrivileges 地方，從而直接從 Ranger Admin獲取策略，這樣實現了實時的鑑權
引擎客戶端鑑權插件，用於查詢 Ranger metastore 的權限策略信息，並判斷用戶是否擁有權限。我們也是基於 Ranger metastore 自研了一套，具體實現方式如下：
1.引擎依賴配置包含 ranger 鑑權接口的 hive 版本依賴
3.引擎側構造 RangerMetastoreClient，請求 checkPrivilege 方法即可。如果能夠正常的返回 true，說明鑑權通過，否則會收到異常信息。
前面說的基於 ranger 的鑑權，主要是針對 hive 元數據層面，然後涉及到 HDFS 權限，我們提供了一種基於大賬戶的機制，即當元數據權限鑑權通過後，將不進行 HDFS 鑑權，這樣可以屏蔽掉 HDFS 權限，從而實現 hive 權限和 hdfs 權限的解耦，同時也可以比較好的支持視圖權限：
1.用戶涉及到 hive 表操作，只要 ranger 權限校驗通過，HDFS 將直接不鑑權
2.涉及到直接 HDFS 路徑操作（非 SQL 查詢），將基於 HDFS UGO 權限機制進行鑑權通過上面介紹這些模塊和組件，我們實現了比較成熟的基於字段級別的權限體系，目前已經落地並且運行倆年的時間，已經支持了超過數百萬的安全權限策略，極大的提升了滴滴數據數據權限的安全性。
本文總結了我們在滴滴大數據安全權限方面的工作，從用戶認證講到了權限鑑權模塊的實現，其實在安全權限實際推動落地的過程中遠遠要比文章寫的要複雜，有興趣的同學歡迎一起討論，也歡迎大家加入我們，解決世界級的技術難題。
團隊招聘
▬
滴滴大數據架構離線引擎&HBase 團隊主要負責滴滴集團大數據離線存儲、離線計算、NoSQL 等引擎的開發與運維工作，通過持續應用和研發新一代大數據技術，構建穩定可靠、低成本、高性能的大數據基礎設施，更多賦能業務，創造更多價值。
團隊持續招聘 HDFS,YARN，Spark，HBase 等領域專家，參與滴滴大數據架構的建設工作，歡迎加入。
可投遞簡歷到 [email protected]，郵件主題請命名爲「姓名-應聘部門-應聘方向」。
掃碼瞭解更多崗位
本文分享自微信公衆號 - 滴滴技術（didi_tech）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
