在大數據時(shí)代，數據已經成為(wèi)公司的核心競争力。主要是通過各種數據分(fēn)析挖掘手段，為(wèi)公司發展決策和業務(wù)開展提供數據支持。業内數據安全事(shì)件頻發，給相關(guān)企業造成了(le)無可挽回的損失，更為(wèi)數據安全防護意識薄弱的企業敲響了(le)警鍾。如(rú)何對公司内部數據最為(wèi)集中的數據分(fēn)析、數據服務(wù)、數據治理(lǐ)等各種數據類産品進行權限管控，已經成為(wèi)數據安全建設中最為(wèi)重要的任務(wù)。如(rú)果從控制力的角度來(lái)進行劃分(fēn)的話(huà)，權限管控可以分(fēn)為(wèi)功能(néng)級權限管控和數據級權限管控。早期的數據安全産品大多使用傳統的權限模型，隻能(néng)實現(xiàn)功能(néng)級權限管控，無法進行數據級權限管控。基于數據類産品更高的安全要求，我們需要構建一(yī)個(gè)同時(shí)滿足各類産品數據安全的我們需要構建一(yī)個(gè)同時(shí)滿足各類産品數據安全的平台。為(wèi)此，騰軟技術不僅設計了(le)能(néng)表達和管控各種複雜關(guān)系的權限模型，還針對事(shì)前、事(shì)中、事(shì)後等三個(gè)場(chǎng)景，分(fēn)别設計了(le)審批、權限、審計三個(gè)子(zǐ)系統以保障數據安全的完整閉環，進而滿足數據安全的各種要求。
圖1 權限背景
功能(néng)應用類産品的權限表達，一(yī)般為(wèi)“是否有權限”，而數據類産品權限表達的關(guān)系更加複雜。例如(rú)數據類産品的報(bào)表，不僅需要表達出用戶能(néng)否訪問這(zhè)個(gè)報(bào)表，而且需要表達出用戶能(néng)訪問報(bào)表中的哪些(xiē)維度、指标以及維值的範圍。還需要告知這(zhè)些(xiē)維度指标來(lái)自于哪些(xiē)庫表模型，是否有權限訪問以及創建報(bào)表。
權限模型
傳統的權限模型有ACL（Access Control List）訪問控制列表，RBAC（Role-Based Access Control）基于角色的訪問控制等。以上(shàng)模型比較适用于應用類型産品的權限管控，而數據類型的産品對信息安全的要求更高，而且各類資源間(jiān)的關(guān)系也(yě)更複雜，使用傳統的模型難以将内部關(guān)系進行清晰的表達，所以我們在RBAC權限模型的基礎上(shàng)，擴展設計了(le)新(xīn)的權限模型。
圖2 傳統權限模型
如(rú)圖2所示，傳統的權限模型：
•ACL訪問控制列表，用戶與權限直接關(guān)聯，直接維護用戶與列表中資源的關(guān)系從而達到權限管控的目的。
•RBAC模型則是角色與權限進行關(guān)聯，用戶成為(wèi)相應的角色而獲得對應的權限。
為(wèi)什(shén)麽要設計新(xīn)的權限模型？
1ACL模型是用戶與資源直接建立關(guān)系，沒有角色的概念。當某些(xiē)用戶需要一(yī)批同樣資源的權限時(shí)，賦權操作(zuò)就(jiù)變得很複雜，此時(shí)這(zhè)種模型就(jiù)不太适應了(le)。
2RBAC模型引入了(le)角色的概念，角色與資源建立關(guān)系。當某些(xiē)用戶需要一(yī)批同樣資源的權限時(shí)，隻需要構建一(yī)個(gè)角色并賦予使用這(zhè)批資源的權限。當用戶加入這(zhè)個(gè)角色時(shí)，則擁有該角色的所有權限。解決了(le)賦權操作(zuò)複雜的問題。
不過ACL模型和RBAC模型，都存在以下(xià)幾個(gè)問題：
1數據類産品資源之間(jiān)關(guān)系複雜，不能(néng)很好(hǎo)地表達這(zhè)種複雜的關(guān)系。例如(rú)：一(yī)個(gè)報(bào)表下(xià)有多個(gè)标簽頁，一(yī)個(gè)标簽頁下(xià)有多個(gè)組件，一(yī)個(gè)組件下(xià)有多個(gè)維度、指标等。同時(shí)維度、指标又來(lái)自不同的數據模型、庫表等。資源與資源之間(jiān)存在關(guān)系，當管理(lǐ)員(yuán)給一(yī)個(gè)用戶賦予報(bào)表的全部或部分(fēn)權限時(shí)，報(bào)表下(xià)的子(zǐ)資源需要同時(shí)獲得對應的權限。
2RBAC模型中角色與角色之間(jiān)沒有對應的關(guān)系。例如(rú)：組織架構中，員(yuán)工所在的組織架構如(rú)下(xià)：華東區/銷售一(yī)區/銷售一(yī)組，員(yuán)工擁有的角色是銷售一(yī)組的角色。當角色之間(jiān)沒有關(guān)系時(shí)，員(yuán)工如(rú)果需要華東區角色的權限時(shí)，需要添加到華東區的角色中。而如(rú)果角色與角色之間(jiān)具有從屬關(guān)系時(shí)，則能(néng)很好(hǎo)地解決這(zhè)個(gè)問題。
新(xīn)的權限模型是如(rú)何解決上(shàng)面這(zhè)些(xiē)問題的：
1設計資源模型時(shí)，資源與資源之間(jiān)具有從屬關(guān)系，并且資源允許多層級，以樹形結構展示。例如(rú)報(bào)表是一(yī)個(gè)父資源，标簽、組件、維度指标都是報(bào)表下(xià)的子(zǐ)資源，這(zhè)樣賦權時(shí)能(néng)清晰地展示出報(bào)表資源與下(xià)面的子(zǐ)資源的關(guān)系，賦權和鑒權時(shí)才能(néng)滿足各種權限控制的要求。
2角色與角色之間(jiān)具有從屬關(guān)系，例如(rú)員(yuán)工在華東區/銷售一(yī)區/銷售一(yī)組的組織架構中，華東區/銷售一(yī)區/銷售一(yī)組這(zhè)3個(gè)角色之間(jiān)分(fēn)别具有父子(zǐ)級的從屬關(guān)系，當員(yuán)工在銷售一(yī)組部門下(xià)，則擁有華東區、銷售一(yī)區、銷售一(yī)組的所有權限。當權限不沖突時(shí)則直接合并所有權限，沖突時(shí)則以“就(jiù)近原則”進行覆蓋。
圖3權限模型
如(rú)圖3所示，新(xīn)的權限模型包含3個(gè)部分(fēn)，用戶中心、資源中心、權限中心。
用戶中心：用戶管理(lǐ)、角色管理(lǐ)
•角色分(fēn)為(wèi)個(gè)人(rén)、組織、自定義3種，一(yī)個(gè)用戶可以同時(shí)擁有多個(gè)角色，比如(rú)用戶默認對應一(yī)個(gè)個(gè)人(rén)角色，又可同時(shí)擁有在公司組織架構中組織角色、在自定義組織的自定義角色。
•角色支持多層級，滿足角色間(jiān)權限繼承的表達方式。
•用戶、部門信息實時(shí)更新(xīn)，每天ETL定時(shí)同步，保證人(rén)員(yuán)入職、轉崗、調離權限實時(shí)同步。
圖4 用戶中心
資源中心：資源管理(lǐ)
•資源類型支持自定義，在通用資源類型的基礎上(shàng)支持自定義的資源接入，滿足各個(gè)系統不同資源的統一(yī)管控。
•資源支持多層級，樹形結構的資源展示方式便于資源的統一(yī)賦權鑒權；給一(yī)個(gè)報(bào)表資源賦權時(shí)，挂在報(bào)表下(xià)的維度、指标等資源能(néng)統一(yī)獲得權限。
•支持資源打包簡化(huà)賦權流程。
•資源安全密級、資源負責人(rén)，支持按照資源配置不同的審批模闆進行權限自助申請。
圖5 資源中心
權限中心：角色與資源的關(guān)系的多種策略表達
•範圍策略：例如(rú)報(bào)表中的平台維度的維值包括和，賦權時(shí)，支持按要求給用戶賦予部分(fēn)或全部權限；鑒權時(shí)，按照規則解析為(wèi)某人(rén)擁有某維度的部分(fēn)或全部權限。
•表達式策略：當把報(bào)表給用戶賦權時(shí)，設置表達式為(wèi)limit 10，表示當前用戶在該報(bào)表其他權限的基礎上(shàng)再進行限制，隻能(néng)返回前10條記錄。
•權限自動合并：一(yī)個(gè)用戶擁有多個(gè)角色，多角色的同一(yī)資源的權限鑒權時(shí)按照規則自動合并；規則解析時(shí)，權限數據不沖突時(shí)取合集，沖突時(shí)按照優先級取對應的值。
•黑白名單：支持按照特定的規則，對某人(rén)針對某資源全面開發和封禁，黑白名單策略的優先級最高，其中黑名單高于白名單。
圖6 權限中心
挑戰
在建設數據安全平台的過程中，主要面臨以下(xià)幾點挑戰：
•随着支持的業務(wù)線增加，通用平台的不能(néng)滿足各個(gè)業務(wù)線的定制需求時(shí)，需要保證系統的靈活可擴展。
•提供一(yī)個(gè)通用的數據安全平台，滿足大部分(fēn)的數據安全的要求，保證系統的通用性。
•權限系統作(zuò)為(wèi)一(yī)個(gè)高QPS訪問的系統，如(rú)何保證系統的高可用。
解決思路(lù)
1提供靈活可插拔的Plugin服務(wù)，在通用權限基礎上(shàng)，滿足各個(gè)業務(wù)線靈活的權限管控要求。
2提供一(yī)個(gè)通用的數據安全平台，滿足基本的權限、審批、審計的基礎功能(néng)。
3微服務(wù)架構、核心與非核心服務(wù)分(fēn)離、數據緩存降級滿足系統高可用。
解決方案
圖7 整體(tǐ)架構
如(rú)圖7所示，分(fēn)3塊，數據内容權限平台、審批流平台、審計日志平台：
•提供各種靈活可插拔的Plugin服務(wù)，支持在通用服務(wù)的基礎基礎上(shàng)進行定制開發。
•提供基礎服務(wù)，滿足各種通用的數據安全要求。
•提供管理(lǐ)工作(zuò)台，支持管理(lǐ)員(yuán)對各種數據和規則進行頁面管理(lǐ)和配置。
具體(tǐ)方案
Plugin服務(wù)層，保證系統靈活可擴展
在滿足通用權限的基礎上(shàng)，各個(gè)業務(wù)線難免會有定制的權限管控需求，于是設計了(le)權限Plugin模塊。通用服務(wù)提供用戶管理(lǐ)、資源管理(lǐ)、鑒權授權的服務(wù)，Plugin調用基礎服務(wù)實現(xiàn)特殊的權限管控。Plugin模塊的應用和數據各自單獨管理(lǐ)，通過RPC方式調用通用服務(wù)實現(xiàn)靈活可插拔。後續Plugin模塊的服務(wù)支持各個(gè)接入的應用單獨定制開發。
圖8 Plugin服務(wù)
如(rú)圖8所示，通用權限的服務(wù)與Plugin的服務(wù)是分(fēn)離的，支持多個(gè)Plugin服務(wù)靈活可插拔：
•通用服務(wù)提供用戶、資源、鑒權授權等通用服務(wù)，大部分(fēn)的系統基于通用服務(wù)即可實現(xiàn)權限管控要求。
•Plugin服務(wù)基于通用服務(wù)對外提供的SDK進行拓展，各個(gè)Plugin服務(wù)單獨部署，保證系統之間(jiān)互相獨立。
最終的權限實現(xiàn)分(fēn)層管控，分(fēn)為(wèi)核心數據層（用戶、資源、權限數據）和應用層。核心數據層的數據由通用服務(wù)進行管理(lǐ)，達到權限數據統一(yī)管控的要求。應用層以Plugin服務(wù)方式接入，Plugin通過通用服務(wù)層對外的SDK進行權限數據讀寫，達到定制的管控要求。應用層的數據各自存儲，可以自定義管控規則。接口之間(jiān)的調用通過BA認證鑒權，保證服務(wù)之間(jiān)調用的安全性。
基礎服務(wù)層，保證系統通用性
通用權限系統架構
使用微服務(wù)架構設計，系統分(fēn)為(wèi)接入層、服務(wù)層、數據庫層、以及外部服務(wù)層。主要包含以下(xià)幾個(gè)核心服務(wù)：
•用戶服務(wù)：主要包含用戶和部門信息同步、角色管理(lǐ)。
•資源服務(wù)：包含資源注冊、資源定時(shí)同步、資源密級及管理(lǐ)員(yuán)管理(lǐ)、資源包管理(lǐ)。
•賦權服務(wù)：權限自助申請、管理(lǐ)員(yuán)賦權。
•鑒權服務(wù)：提供各種鑒權的SDK供使用方調用。
圖9 權限系統架構
如(rú)圖9所示：
•接入層：對外所有系統通過統一(yī)的SDK調用服務(wù)。
•服務(wù)層：微服務(wù)架構，各個(gè)服務(wù)之間(jiān)互相之間(jiān)提供服務(wù)。
•數據庫層：合理(lǐ)利用緩存、數據降級，保證服務(wù)高可用。
•集成公司公共服務(wù)，保證系統穩健運行。
審批系統架構
提供通用的審批服務(wù)，提供多級審批模闆，使用時(shí)選擇模闆啓動審批流，審批系統按照啓動的參數進行規則解析，自動适配對應的審批流程。縮減接入流程支持一(yī)鍵接入。
圖10 審批系統架構
如(rú)圖10所示：優化(huà)審批接入流程，提供通用的審批服務(wù)，減少系統接入開發成本：
•前期開發一(yī)個(gè)審批功能(néng)需要6個(gè)步驟，繪制流程圖，配置審批的組和成員(yuán)，配置通知的消息，配置事(shì)件映射，啓動審批流，開發回調接口改狀态。
•而我們在平台的審批服務(wù)基礎上(shàng)進行封裝，提供通用的審批模闆，接入審批系統隻需要選擇模闆啓動審批流，并提供回調接口即可。能(néng)滿足大部分(fēn)的審批功能(néng)。
提供通用的規則解析引擎，支持審批人(rén)、審批條件、審批通知按照規則動态解析匹配。靈活實現(xiàn)自動審批、多人(rén)多級審批、定時(shí)催辦等多種通用功能(néng)。對接權限和審計系統，保證審批系統數據安全：
•對接權限系統，提供管理(lǐ)員(yuán)權限管控。
•對接審計系統，操作(zuò)數據落到審計系統便于後續的數據審計。
審計系統架構
提供通用的數據審計服務(wù)，客戶端日志埋點上(shàng)報(bào)，審計日志按類型落到Elasticsearch中存儲。對接如(rú)意可視(shì)化(huà)報(bào)表出審計報(bào)告，對接權限系統管控數據權限。
圖11 審計系統架構
如(rú)圖11所示：審計數據模型層支持自動擴展：
•每個(gè)應用對應一(yī)個(gè)appkey，每個(gè)appkey按照模闆分(fēn)日期自動創建一(yī)個(gè)索引，支持自動擴展。
•每種類型的審計日志對應Elasticsearch索引中的一(yī)個(gè)type，新(xīn)增一(yī)種操作(zuò)日志時(shí)，type自動創建。
•審計日志中的字段對應type中的字段，新(xīn)增字段時(shí)自動擴展。
保證系統高可用微服務(wù)架構服務(wù)分(fēn)離
随着系統的模塊功能(néng)越來(lái)越多，單一(yī)架構模式已不再适合敏捷開發，模塊越來(lái)越大系統啓動則越慢(màn)，任一(yī)模塊出錯則整個(gè)系統的服務(wù)都不可用。為(wèi)了(le)保證服務(wù)的高可用和擴展性，于是以微服務(wù)架構把模塊進行拆分(fēn)，并把核心與非核心服務(wù)進行分(fēn)離。
圖12 微服務(wù)架構
如(rú)圖12所示：
•前端接入層通過HTTP接入，BA認證校(xiào)驗請求合法性，通過Nginx負載均衡。
•管理(lǐ)控制台，通過調用服務(wù)層的各個(gè)服務(wù)實現(xiàn)統一(yī)管理(lǐ)。
•服務(wù)層，抽象系統各個(gè)模塊，每個(gè)模塊都是一(yī)個(gè)微服務(wù)，每一(yī)個(gè)微服務(wù)都獨立部署，可以根據每個(gè)服務(wù)的規模按需部署。
•Client層，對外提供統一(yī)的Pigeon（内部分(fēn)布式服務(wù)RPC通信框架）接口，通過POM引入調用服務(wù)層各個(gè)服務(wù)。
權限繼承
由于資源支持多層級，設計權限模型時(shí)支持權限繼承，當賦權時(shí)開啓繼承，則用戶默認擁有該資源以及下(xià)面所有資源的全部權限，數據存儲時(shí)隻需要存儲祖先資源與用戶之間(jiān)的關(guān)系。大大減少了(le)權限矩陣大小。
圖13 權限繼承
權限數據存儲
接入的系統越多，則資源和用戶就(jiù)越多。随着系統運行越久，對應的權限數據也(yě)會随之快(kuài)速增長。如(rú)何在數據增長的同時(shí)保證接口的性能(néng)和高可用。
權限備份與恢複
參照HBase的版本号和MySQL的Binlog的設計思路(lù)，賦權時(shí)權限隻存儲當前用戶最新(xīn)權限數據，曆史權限數據和操作(zuò)記錄用版本号的方式存儲到Elasticsearch中。用戶鑒權時(shí)隻需要查詢MySQL的權限數據即可，保證鑒權接口的高效性。
圖14 權限備份與恢複
如(rú)圖14所示：
•賦權操作(zuò)時(shí)，通過版本号管理(lǐ)權限數據，每次操作(zuò)後版本号加1，MySQL和Redis中隻存儲最新(xīn)的權限數據。
•曆史權限數據通過版本号的方式存儲到Elasticsearch中，每次查看曆史操作(zuò)記錄或恢複權限數據時(shí)，根據版本号回溯即可。
權限過期清理(lǐ)
•通過Crane定時(shí)調度，根據配置的通知規則，掃描即将過期的權限數據，發送消息通知用戶進行權限續期。
•掃描已過期的權限數據，清理(lǐ)MySQL和Redis中的過期權限數據，并轉儲到Elasticsearch中保存，已備後續的權限審計。
數據讀寫分(fēn)離、緩存、備份以及服務(wù)熔斷降級
各個(gè)服務(wù)使用MySQL分(fēn)庫存儲，使用Zebra（數據庫訪問層中間(jiān)件）進行讀寫分(fēn)離；合理(lǐ)使用數據緩存與備份，并支持服務(wù)的熔斷降級，以保證服務(wù)的高可用。
圖15 數據讀寫分(fēn)離、緩存、備份以及服務(wù)熔斷降級
如(rú)圖15所示：
•各個(gè)服務(wù)使用MySQL分(fēn)庫存儲；核心服務(wù)與非核心服務(wù)分(fēn)離，服務(wù)和數據庫支持按需彈性拓展。
•角色、資源等熱點數據使用Redis做緩存，并在Redis緩存不可用時(shí)自動下(xià)沉到MySQL進行查詢。
•操作(zuò)記錄和曆史數據等不活躍數據落地到Elasticsearch，以便審計和數據恢複。
•服務(wù)不可用時(shí)支持熔斷降級，以保證核心服務(wù)的可用性。
合理(lǐ)使用消息隊列、任務(wù)調度、線程池、分(fēn)布式鎖
使用消息隊列、任務(wù)調度、線程池進行異步、削峰、解耦合，減少服務(wù)響應時(shí)間(jiān)，提升用戶體(tǐ)驗。并使用分(fēn)布式鎖保證數據一(yī)緻性。
圖16 提高服務(wù)響應速度
如(rú)圖16所示：
•使用消息隊列處理(lǐ)用戶請求，實時(shí)返回操作(zuò)成功，後台根據接受到的MQ消息異步進行處理(lǐ)并修改狀态，頁面輪詢狀态展示最終結果或發送大象（内部通訊工具）消息進行最終結果推送。
•需要定時(shí)同步的任務(wù)通過Crane分(fēn)布式任務(wù)調度平台進行定時(shí)調度執行。
•審批回調時(shí)使用線程池處理(lǐ)審批結果回調與失敗重試，較少創建銷毀線程的開銷。
•分(fēn)布式鎖，保證同一(yī)個(gè)方法在同一(yī)操作(zuò)上(shàng)隻能(néng)被一(yī)台機器(qì)上(shàng)的一(yī)個(gè)線程執行，避免用戶重複提交或者多機器(qì)重複處理(lǐ)導緻的數據不一(yī)緻。