近一年來從事金融資料安全架構方面工作，對大資料平臺安全重要性有了一些新的思考。最近看了Steve Loughran先生寫的本書《Hadoop and Kerberos: The Madness Beyond the Gate》，寫作風格幽默風趣，但是國內對大資料平臺的安全考慮的文章的確較少，今年6月1號的網路安全法頒佈之後，中小型公司不得不開始重視資料安全。順便吐槽一下，看了他在youtobe上面的視訊演講，真是人不可貌像、海水不可斗量，當然比好多人知道鄙人真名後，對我呵呵兩聲好多了。本系列文章主要是分析Hadoop安全現狀和原始碼，個人能力有限，麻煩各位大神及時斧正。

• 很多公司都採用了kerberos作為Hadoop的安全基石，但是keberos本身的缺陷我們需要了解，接下來內容會結合Steve的觀點，來分析kerberos的不足。
• Kerberos 被認為是在安全的分散式系統方面是最好的。設計tickets去限制KDC的負載，當principal需要一個ticket的時候才會與其通訊，而不是每次請求都必須驗證其合法性。
• Hadoop 程序間可以使用代理tokens 保證了使用原始principal得以傳遞認證。Hadoop 核心服務使用代理tokens
  作為認證使用者，並准許這個使用者釋出的服務。如果不瞭解Hadoop的代理token，建議使用者詳細閱讀：“Hadoop Security Design” Owen O’Malley, Kan Zhang, Sanjay Radia, Ram Marti, and Christopher Harrell。
• tickets和tokens具有時效性，這意味著即使被盜取，被盜用使用的時間只限制在tokens的壽命之內。kerberos客戶端可以部署到Window、Linux，OS/X和java runtime，這意味著kerberos使用比較廣泛，安全風險也大。kerberos只是三頭狗，不是萬能的神，已知的缺陷如下：
  

1、KDC 有單點風險，除非設定HA系統(Aictive Directory 可以做到這一點，目前apache directoryserver 也可以做到這一點)；

2、訪問壓力可能使KDC過載；分散式服務使用Kerberos 必須做到這一點，KDC無法承受高負載請求；為什麼Hadoop 要使用代理tokens的原因也是如此；

3、服務之間的通訊通道也需要安全認證，kerberos不保證資料加密；如果通訊通道不安全，tickets 可能會被攔截或者通訊偽造；

4、機器之前需要保證時間的精確一致性，不然具備時限的tockens不會正常工作；這個在分散式領域是一個典型的問題，Paxos &Raft協議也必須保證時間的一致性；

5、如果機器間的時間沒有被安全管理，理論上可能延長被盜token的使用時間；

6、被盜用的token可以拿來直接訪問服務，在KDC是沒有訪問日誌的。每一個application需要擁有自己的以使用者為單位的審計日誌，這樣才能保證被盜的ticket可被追蹤，比如在Hadoop裡面HDFS審計日誌；

7、這是一個僅僅認證服務：驗證caller的合法性並准許給caller傳遞認證資訊，他不處理任何授權資訊；

如果需要關注更多kerberos細節問題，可以參考： Kerberos in the Crosshairs: Golden Tickets,Silver Tickets, MITM, and More

參考文章：

1)https://steveloughran.gitbooks.io/kerberos_and_hadoop/content/sections/what_is_kerberos.html
2)“Hadoop Security Design” Owen O’Malley, Kan Zhang, Sanjay Radia, Ram Marti, and Christopher Harrell。