天天看點

資料隔離、通路授權,用好大資料為什麼這麼難?

摘要:如何保證企業大資料在滿足各業務部門資料通路需求的同時又能精細化保障資料通路安全、避免資料洩露是每個企業大資料資産管理者必須關注的話題。

如今,企業大資料資産在企業輔助決策、使用者畫像、推薦系統等諸多業務流程中扮演着越來越重要的作用,如何保證企業大資料在滿足各業務部門資料通路需求的同時又能精細化保障資料通路安全、避免資料洩露是每個企業大資料資産管理者必須關注的話題。

筆者結合在華為雲資料湖探索服務中的技術沉澱與豐富的企業資料安全管理經驗,從以下幾點來探讨如何精細化保障企業大資料安全。

1、企業大資料的安全挑戰

2、資料資産權限管理的通用做法

3、以華為雲DLI為例,對資料資産管理的實踐&案例分析

4、未來展望

資料隔離、分層通路、授權,難題多多

企業大資料的日積月累,自然面臨着大資料安全的挑戰:資料來源廣泛,來源于不同的業務單元,又要服務于各種業務單元,還需要對不同層級的員工設定不一樣的權限。如何防範企業資料不被未經授權的使用者通路,管理資料在不同業務單元的共享,隔離企業敏感資料……企業可能面臨着以下的挑戰:

1.1 資料隔離

不同的項目業務資料需要隔離,如遊戲營運資料,企業在設計大資料分析平台時可能期望A遊戲産生的業務資料用來支撐A遊戲營運分析,B遊戲産生的業務資料是支撐B遊戲營運分析,那麼需要對業務資料按項目進行隔離,A遊戲營運部門員工隻可通路A遊戲營運資料,B遊戲營運部門員工隻可通路B遊戲營運資料

資料隔離、通路授權,用好大資料為什麼這麼難?

1.2 資料分層通路

不同層級業務部門對資料具備不同的通路權限,高層級部門可以通路底層級部門的資料,而低層級部門不可通路高層級部門的資料。如省級部門可以通路地市級資料,而地市級部門隻可通路本地市資料,不可通路跨區資料,也不可通路省級部門資料。這就要求對資料的權限管理需要具備分層管理能力,能夠分層級授予不同的權限。

資料隔離、通路授權,用好大資料為什麼這麼難?

1.3 列級資料授權

不同業務部門對同一份資料的通路權限要求不同,是以要求能夠對資料進行精細化授權。如銀行系統中,使用者表中的身份證号資訊是敏感資訊,櫃台系統可以查詢使用者的身份證号,但推薦系統就不需要身份證資訊,隻需要使用者ID就可以了。這種場景下需要對使用者表能夠分列授權,對不同的業務單元不同的權限。

1.4 批量授權

随着企業規模的增大,企業員工可能非常龐大,分部門授權,批量授權也是很常見的業務場景。例如銷售部門下面員工很多,如果單個單個的給銷售人員授權,會非常麻煩,人員流動時取消授權也很複雜,這時就需要能夠批量授權或者基本角色的授權模型,來實作一次授權,部門内員工均可使用的目的。

四種權限模型,孰優孰劣?

目前比較流行的大資料分析平台的有Hadoop,Hive,Spark等,它們使用的權限模型有POSIX模型、ACL模型、SQL Standard模型和RBAC模型。其中Hadoop大資料平台使用了POSIX和ACL權限模型來管理資料,HIVE和Spark使用了ACL和RBAC權限模型來管理資料。

POSIX權限模型是基于檔案的權限模型,與Linux系統的檔案系統權限類似。即一個檔案有相應的OWNER和GROUP,隻能支援設定OWNER,、GROUP和其他使用者的權限,可授權限也隻有讀寫執行權限。

這種模型不适用于企業使用者,有一個明顯的缺點就是它隻有一個GROUP,不能實作不同的GROUP有不同的權限,也無法實作精細化的權限管理,隻能在檔案級授權,所授權限也隻有讀寫與執行權限。

ACL即Access Control List,ACL權限模型可以彌補POSIX權限模型的不足,可以實作比較精細化的權限管理。通過設定通路控制清單,我們可以授予某一個使用者多個權限,也可以授予不同使用者不同的權限。但ACL也有明顯的缺點,當使用者數較大時,ACL清單會變得龐大而難以維護,這在大企業中問題尤其明顯。

RBAC(Role-Based Access Control)模型也是業界常用的一種權限模型。是基于使用者角色的權限管理模型,其首先将一個或多個權限授權某一個角色,再把角色與使用者綁定,也實作了對使用者的授權。一個使用者可以綁定一個或多個角色,使用者具備的權限為所綁定角色權限的并集。RBAC可以實作批量授權,可以靈活維護使用者的權限,是目前比較流行的權限管理模型。

SQL Standard模型是Hive/Spark使用權限模型之一,本質是使用SQL方式的授權文法來管理權限。Hive中的權限模型也是基于ACL和RBAC模型,即可以給單獨的使用者直接授權,也可能通過角色進行授權。

資料湖探索怎麼做資料資産管理?

華為雲DLI結合了ACL和RBAC兩種權限模型來管理使用者權限。DLI中涉及到的概念有:

DLI使用者:DLI使用者為IAM賬号及其下的子使用者,下面通路權限說明的使用者均指IAM賬号及其下的子使用者。

DLI資源:DLI的資源分為資料庫(Database)、表(table)、視圖(View)、作業(Job)和隊列(Queue)。資源是按項目隔離的,不同項目的資源不可互相通路。表和視圖是資料庫(Database)下的子資源。

DLI權限:DLI權限為執行DLI相關操作所需要的權限。DLI中的權限比較細,每項操作對應的權限都不一樣,如建立表對應CREATE_TABLE權限,删除表對應DROP_TABLE權限, 查詢對應SELECT權限等等。

DLI使用統一身份認證(IAM)的政策和DLI的通路控制清單(ACL)來管理資源的通路權限。其中統一身份認證(IAM)的政策控制項目級資源的隔離,和定義使用者為項目的管理者還是普通使用者。通路控制清單(ACL)控制隊列,資料庫,表,視圖,列的通路權限和授權管理。

DLI使用統一身份認證來完成使用者認證和使用者角色管理。DLI在IAM中預定義了幾個角色:Tenant Administrator(租戶管理者),DLI Service Admin(DLI管理者),DLI Service User(DLI普通使用者)。其中具備租戶管理者或DLI管理者角色的使用者在DLI内是管理者,可以操作該項目的所有資源,包括建立資料庫,建立隊列,操作項目下的資料庫,表,視圖,隊列,作業。普通使用者不可建立資料庫,不可建立隊列,依賴管理者的授權,可以執行建立表,查詢表等操作。

DLI使用ACL和RBAC兩種模型來管理使用者權限。管理者或資源的所有者可以授予另外一個使用者單個或多個權限,也可能建立角色,授予權限給建立好的角色,然後綁定角色和使用者。

資料隔離、通路授權,用好大資料為什麼這麼難?

DLI提供了API和SQL語句兩種方式來實作以上權限管理,友善使用者靈活授權。具體使用方式可以參考DLI的權限管理。

案例分析

拿銀行的大資料實踐來分析下如何利用DLI來管理資料的權限。衆所周知,銀行積累了大量的使用者資料,包括使用者資訊,交易資訊,賬戶資訊等等數以億計的資料。而銀行業務也是非常的複雜,涉及到櫃員系統,監管部門,營運部門,營銷部門等等各個業務線,各業務線對資料的要求不同,通路的權限不同。我們拿反洗錢業務與畫像業務來簡單介紹下如何利用DLI平台實作大數分析和資料資産權限管理。

典型的反洗錢業務一般是大額預警和黑名單機制,需要從海量的交易資料中篩選出大額交易或者是黑名單人員交易資料,将這些資料回報給監管人員進行進一步分析,涉及到的資料是交易資料,賬戶資訊和黑名單資訊。

畫像一般會分析使用者的交易類型與交易資料,推斷出使用者的興趣愛好,給使用者畫像,标記使用者的興趣點在哪些地方。涉及交易資訊中的交易類型和賬号資訊。

這兩項業務中在DLI中,由資料管理者生成生成使用者資訊表,交易資料表,賬戶資訊表,黑名單資訊表,并導入相應的資料。

在檢討錢業務,授予反洗錢業務部門或人員賬戶資訊表的查詢權限,交易資料表的查詢權限,黑名單資訊的查詢權限,通過對賬戶資訊表和交易資料表和黑名單表的聯合查詢,可以查找出異常交易資訊及相關交易人員,回報給反洗錢監管人員。

在畫像業務中,由資料管理者授予畫像業務部門或人員使用者資訊表的查詢權限,交易資料表中交易金額和交易類型,交易商戶等列的查詢權限,賬戶資訊表中的賬戶ID和使用者ID列的查詢權限,經過這幾張表的聯合與聚合查詢,找出使用者常用交易資訊,包含交易類型,金額,及相關地點等資訊,描繪出使用者畫像資訊。

未來展望

傳統企業資料資産面臨着幾個難題。各業務部門均會産生資料,資料标準不一緻,維護複雜。各業務部門資料存在在不同的系統中,資料容易形成孤島,無法有效挖掘利用。部門間資料共享複雜,容易形成網狀授權網絡,維護成本巨大。

資料湖DLI方案可以解決這樣的難題,使用統一的資料管理平台、資料存儲、資料标準,進行統一的資料資産管理、授權管理。

華為雲828企業上雲節期間,資料湖探索DLI也在活動産品之列,有資料分析需求的企業趕緊趁着促銷入手試試。

點選關注,第一時間了解華為雲新鮮技術~

繼續閱讀