HDFS encryption 實戰之背景和架構介紹

1、HDFS encryption背景

在全世界,爲零滿足隱私和其他安全需求,很多政府部門、金融部門和管理單位強制要求數據加密。例如 銀行支付行業爲零滿足信息安全必須滿足支付卡行業數據安全標準 Payment Card Industry Data Security Standard (PCI DSS)。其他一些例子,美國聯邦政府信息安全管理法案 United States government’s Federal Information Security Management Act (FISMA) 、醫療保險可攜性和責任法案Health Insurance Portability and Accountability Act (HIPAA)。對HDFS裏面的數據進行加密可以幫助你的組織應對這些規定。
HDFS encryption 實現了在集羣中讀寫HDFS Block時透明的、端到端的數據加密。透明加密意味着終端用戶無需感知encryption/decryption 過程,而端到端意味數據在靜態和傳輸過程中都是加密的。

2、HDFS encryption 具備的能力

HDFS encryption 具備下面一些能力:

  • 只有HDFS client才能夠加解密 ● 爲了區分開HDFS administrator, Key
    Administrator這兩個用戶,必須要將Administration of HDFS and administration of
    keys分成兩個獨立的功能,這樣可以保證沒有一個獨立的用戶可以同時擁有data和keys。
  • 操作系統級別和HDFS交互僅使用加密數據,減輕了os和文件系統成的威脅 ● HDFS使用的是高級加密標準模式(AES-CTR)加密算法。 AES-CTR默認支持128-bit 加密key,或者在 Java Cryptography Extension (JCE) unlimited strength JCE 安裝情況下,可以支持128-bit 加密key
  • HDFS encryption 在設計的時候充分利用了Intel® Advanced Encryption Standard
    Instructions (AES-NI)指令集,一種基於硬件的加密加速技術,所以你的集羣性能在配置encryption後沒有明顯的性能消耗(AES-NI指令集相比於硬件實現的AES,可以提高一個數量級)。但是你需要更新HDFS和MAPREDUCE的cryptography(密碼學)庫才能使用加速機制。

3、主要架構

3.1 Keystores 和 the Hadoop Key Management Server

許多keystores 沒有滿足HDFS加解密的性能,這就需要重新設計一個新的服務,叫做 Hadoop Key Management Server (KMS)。KMS作爲一個代理實現連接HDFS client和後端的keystore。keystore和HADOOP KMS 相互交互和HDFS clients交互過程中 都必須使用 Hadoop’s KeyProvider API。
當然HDFS encryption可以使用一個本地的java Keystore 作爲key 管理器,Cloudera在生產環境不推薦使用本地java keystore,而是一個更健壯和安全的key 管理方案。 Cloudera Navigator Key Trustee Server 是一個管理加密key 的key store,同時具有其它一些安全特性。爲了集成Cloudera Navigator Key Trustee Server,Cloudera提供了一個通用的KMS 服務,叫做Key Trustee KMS。
下面這張圖解釋了HDFSclients 和 NAMENODE怎麼樣一個企業級keystore交互。
這裏寫圖片描述
怎樣安裝Navigator Key Trustee和 Hadoop Key Management Server,我會在後面詳細參數。

3.2、Encryption Zones and Keys

Encryption Zones(EZ) 是HDFS 上面的一個需要加密的目錄。開始是一個空木了,可以使用一些工具比如distcp 將數據添加到Zones裏面。拷貝到這個目錄的文件和子目錄都會被加密,只要添加到這個目錄下面了就不可以對文件和目錄進行命名。需要注意一點是不能在已經有的目錄上面創建Encryption zones。

名詞解釋:
- 每一個EZ對應有一個 EZ key,這個key是有key administrator 在創建zone的時候指定的,EZ key存儲在後端的keystore的,獨立於HDFS存在的
- 在EZ裏面的每一個文件 擁有自己的encryption key,叫做Data Encryption Key (DEK)
- 這些DEKS 使用了自己的EK key進行加密,然後了Encrypted Data Encryption Key (EDEK)
下面的這張圖解釋了怎麼樣使用encryption zone keys (EZ keys), data encryption keys (DEKs), 和encrypted data encryption keys (EDEKs)去解密和加密文件。
這裏寫圖片描述

EDEKS 持久化存儲在Namenode裏面,作爲一個文件的屬性,使用了HDFS 可擴展屬性。NameNode可以安全存儲和處理EDEKS,因爲HDFS 用戶 沒有權限獲取EDEK’s encryption keys (EZ keys)。即使HDFS 妥協(比如獲取到HDFS超級用戶),這個惡意用戶也只能獲取到加密文件和EDEKS。EZ keys 在KMS和keystore被單獨的權限管理。

一個EZ key 可以擁有多個版本,每個key version擁有自己不同key 實體(也就說, encryption and decryption使用的內容是不一樣的)。key 的旋轉 是通過翻滾EZ key實現的。每個文件 key的旋轉是通過新的EZ可以重新加密文件的DEK ,獲取到一個新的EDEK的。HDFS 可以識別一個 encrytion key主要兩個途徑:1)key name 最新的key version,2)指定的key version。
這個地方需要測試一下,不同的key version 是否可以 加密和解密同一份數據?

3.3 操作文件流程

爲了解密一個新文件,需要如下流程

  • HDFS需要從Namenode獲取一個新的EDEK
  • NameNode 請求KMS 使用這個文件對應encryption zone 的EZ key 解密 EDE
  • client 使用這個DEK去解密這個新文件
    這裏寫圖片描述

4、參考文檔

https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_sg_hdfs_encryption.html#concept_z2d_1vz_np

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章