• 深度
  • 行業
  • 行業
  • 互動

華為云數據湖探索服務DLI,精細化保障企業大數據安全

隨著企業業務的不斷發展,企業大數據資產在企業輔助決策、用戶畫像、推薦系統等諸多業務流程中扮演著越來越重要的作用,如何保證企業大數據在滿足各業務部門數據訪問需求的同時又能精細化保障數據訪問安全、避免數據泄露是每個企業大數據資產管理者必須關注的話題。

結合在華為云數據湖探索服務(DLI)中的技術沉淀與豐富的企業數據安全管理經驗,本文從以下幾點來探討如何精細化保障企業大數據安全。

1、企業大數據的安全挑戰;2、數據資產權限管理的通用做法;3、以華為云數據湖探索服務(DLI)為例,對數據資產管理的實踐&案例分析;4、未來展望。

企業大數據的安全挑戰

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

  數據隔離:不同的項目業務數據需要隔離,如游戲運營數據,企業在設計大數據分析平臺時可能期望A游戲產生的業務數據用來支撐A游戲運營分析,B游戲產生的業務數據是支撐B游戲運營分析,那么需要對業務數據按項目進行隔離,A游戲運營部門員工只可訪問A游戲運營數據,B游戲運營部門員工只可訪問B游戲運營數據。

  數據分層訪問:不同層級業務部門對數據具備不同的訪問權限,高層級部門可以訪問底層級部門的數據,而低層級部門不可訪問高層級部門的數據。如省級部門可以訪問地市級數據,而地市級部門只可訪問本地市數據,不可訪問跨區數據,也不可訪問省級部門數據。這就要求對數據的權限管理需要具備分層管理能力,能夠分層級授予不同的權限。

  列級數據授權:不同業務部門對同一份數據的訪問權限要求不同,所以要求能夠對數據進行精細化授權。如銀行系統中,用戶表中的身份證號信息是敏感信息,柜臺系統可以查詢用戶的身份證號,但推薦系統就不需要身份證信息,只需要用戶ID就可以了。這種場景下需要對用戶表能夠分列授權,對不同的業務單元不同的權限。

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

數據資產權限管理的通用做法

目前比較流行的大數據分析平臺的有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為例,對數據資產管理

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探索的一個方向。

(免責聲明:本網站內容主要來自原創、合作媒體供稿和第三方自媒體作者投稿,凡在本網站出現的信息,均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性,但不保證有關資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏,概不負任何法律責任。
任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時,應及時向本網站提出書面權利通知或不實情況說明,并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后,將會依法盡快聯系相關文章源頭核實,溝通刪除相關內容或斷開相關鏈接。 )