<mark id="oztn4"></mark>
0
| 本文作者： 朱赟 | 2017-02-07 14:50 |
雷鋒網按：本文作者為Airbnb的數據加密的大牛桑立鋒，來自朱赟美女程序媛的公號“嘀嘀嗒嗒”。
說到桑同學，那比我牛出不止一個數量級了。俄亥俄州立大學畢業的PhD，曾在Yahoo!、LinkedIn等多家公司擔任技術骨干。在過去三四年間獲各種數據加密相關的專利達五項之多。
除了技術扎實，桑同學平時也是極好相處，又特別愿意幫助別人。在我過去和他不多的幾次合作中，也不時又機會請教一二。雖然對于數據加密仍然是個門外漢，但是桑同學解釋問題總能聽得懂。因此在我的再三請求下，有了這篇科普性的文章。
雖然我們都就職于Airbnb，但是這篇文章和 Airbnb 現在使用的技術沒有直接關聯。下面是正文。
數據加密是一個古老的問題，但又是一個無法做到完美的問題，尤其在一個復雜的大型系統中需要考慮方方面面的問題，包括 security， availability， usability， consistentcy， performance，extensibility 等等。除了那些完全不做的，大部分公司都會根據自身的需求、環境、資源以及工程師的能力等，設計和開發適合公司實際情況的解決方案。有做得好的，也有坦誠做得不好的，還有自己認為做得好的但其實經不起真正考驗的。
就算在同一個公司，很多也會有不同的解決方案并存。有些是因為歷史原因，比方說早期用方案A，后來開發了更牛逼的方案B，但沒有把A完全干掉；或者擴張原因，比方說兼并了一個用不同方案的別家公司；又或者是政治原因，不同部門誰都不屌誰，各自用自認為合適的方案。無論公司選擇什么方案，因為話題的敏感性（法律原因，或者圈內的潛規則，或者僅僅是不想當出頭鳥而被黑客們盯上），絕大部分都不會公開數據加密的細節。同樣原因，這篇文章也不會涉及筆者公司怎么做數據加密的具體細節。想到哪兒寫到哪兒吧。
一、為什么要做數據加密？
先說為什么要做數據加密。越來越多的數據泄露事件，比方說 Yahoo 2013年被盜超過10億用戶信息，Yahoo 2014年又被盜超過5億用戶信息，LinkedIn 被盜一億多用戶密碼，Ashley Madison 被盜三千多萬用戶數據以及大量支付信息，Target 被盜近七千萬用戶數據和銀行賬號，Adobe 被盜三千八百萬用戶數據等等，以及由此導致的大量法律糾紛和巨額賠償，還有很多很多大大小小沒有被公布的安全事件，都說明了數據加密和保護的重要性。
說到這些安全事件中用戶密碼的保護，插個題外話。筆者曾經跟很多工程師（包括很多應用領域專家）聊天的時候，都會被問到，為什么筆者認為僅僅 Hash 用戶密碼是不夠的。很多人（包括網上的很多文章）都誤認為用戶密碼只要 Hash了，就安全了，其實不然。不說 weak Hash 函數諸如 RC4、MD5，就算用 Bcrypt、KDF等運算復雜的Hash函數，雖然能防 Rainbow Table Attack，但對 Dictionary Attack 卻是無效的。當然這不是 Hash 函數本身的錯，而是很多人會選一個容易記的密碼，而這類密碼往往 entropy 不夠，很容易被解密。對用戶密碼而言，筆者一直建議不僅需要Hash，還要加密（比方說用 keyed hash function，or MAC）。
還有很多公司要做加密不僅僅是因為保護用戶隱私，更是法律法規的要求，不得不做。有些涉及特殊數據，如信用卡號碼，那就要做 PCI （The Payment Card Industry Data Security Standard ）；如用戶健康信息，那就要做 HIPAA （The Health Insurance Portability and Accountability Act）等等。
在筆者看來，任何一個收集以及存儲客戶數據的公司，就算是初創公司，都應該認真對待這個問題。在圈內我們常說，不是系統會不會黑，數據會不會被盜，而是何時被黑被盜的問題。也許有人會說，就算偷了，盜了，那又如何？這種事可大可小，筆者私下就知道有公司被黑后，被迫關門了的。所以安全領域內的及時投資，對公司長期來講都是非常有益的。對重要數據（包括系統密碼，用戶信息等）進行有效保護，數據被黑被盜的門檻就高了；就算有一天系統被黑了，數據被盜了，也能把損失降到最小。
二、怎么做數據加密？
你說數據加密這么重要，怎么做呢？如果把加密這個問題抽象出來，其實就是要計算一個加密函數：
encrypt（data， key）
（當然還有一個函數就是解密，跟加密類似道理，暫且不論）。看上去似乎是一個非常簡單的問題，但要把它做好非常不容易。尤其是在一個系統復雜的公司，要考慮的問題很多很多。比方說，密碼界有很多算法，應該用什么加密算法，對稱的還是非對稱的？具體選哪個，AES，DES，RSA，ECC等等，各有什么特點？題外話，筆者在曾經工作過的公司見過很多有趣的例子，比方說有些早期開發人員用 XOR 來加密，或者做點簡單的迭代替換，或者自創所謂的加密算法（有點掩耳盜鈴的感覺）等等，這些最后都變成 technical debt，需要花很大力氣去清理。
每個算法也有不同的變種和模式，各有什么特點，性能如何？如果某個算法被宣布不安全了，如何快速迭代？這個 key 怎么來？多長才是安全的？怎么啟動？怎么保存？怎么傳播？怎么控制訪問權限？怎么知道誰訪問了什么？怎么來監控？怎么來預警？怎么來系統性的更新這些 key？key 能不能丟，丟了怎么辦？不同的應用可能是用不同的語言寫的，怎么兼容？怎么支持大流量等等，等等。還有更加不近人情的要求，比方說如何保證被加密的數據能夠 preserve 原始數據的順序，支持搜索，但又不犧牲安全性等（這方面 MIT 有學者在研究，有興趣的朋友可以看看他們的論文）。
一個好的加密設計方案，不僅僅方案本身要滿足安全上嚴格的要求，解決上面提到的很多問題，還需要實用，容易擴展和維護。在數據加密變得越來越重要，系統越來越復雜的年代，如果資源允許，應該把加密服務獨立出來，然后提供高性能，統一，簡單又容易理解的接口來進行數據加密，讓應用開發人員很方便的使用，這樣他們只需要專注他／她所擅長的領域，而不需要去思考怎么解決安全問題，因為術業有專攻。好的加密方案應該把數據和秘鑰的存儲分開，并且把存儲和運算分開，尤其在 SOA 架構下， 這可能跟很多傳統的數據加密方法（比方說直接實用某個語言的內置庫加密解密）非常不一樣。很多解決方案往往密鑰和被加密的數據同時存在一個服務中，結果就是如果那個服務被黑了，那就整個被黑了。下面就撿幾個要點簡略講講。
（1）為什么要把運算和存儲的分離？很多需要被加密的數據，往往和具體商業邏輯數據一起，屬于不同的服務，比方說支付信息屬于支付服務，護照號碼屬于用戶服務等。把運算和存儲分離可以帶來很多好處，比方說：
加密服務變得簡單和高效。因為不需要存儲那些被加密的數據，加密服務系統不會很復雜，也不需要負責存儲系統所帶來的維護，擴展等諸多問題；
加密服務的安全性能提高很多。因為運算和存儲的分離，如果僅僅是被加密的數據泄露（比方說數據庫被盜），那些數據就沒法被解密，因為黑客沒法從外部訪問加密服務。如果僅僅是客戶服務被黑，想要盜取大量數據并且通過加密服務來解密而不被發現也很難。如果僅僅是加密服務服務被黑，因為加密服務本身并不擁有數據，被泄露的數據也不會很多。只有當加密服務和客戶服務同時被黑，才會泄露大量數據，而同時能夠侵入加密服務和客戶服務的難度要高很多很多；
靈動性。因為數據屬于客戶服務，不同的客戶可以對數據進行不同的處理，比方說不同的有效性規則，數據交易完整性等等。
（2）其次是 granular control。假設支付服務要求加密/解密信用卡號碼，用戶服務要求加密/解密護照號碼，如何能保證用戶服務不能加密/解密信用卡號碼。這就需要解決兩個基本問題：客戶認證（authentication）和權限控制（authorization）。怎么做客戶認證（authentication）？客戶認證要知道每一個請求是誰發出的。因為只有知道客戶是誰才可以進行權限檢查。常用的有基于客戶證書的（如 client certificate over TLS），基于 OAuth（開放授權）的，或者各種各樣定制的方案，如基于 Curve25519 等等。筆者一般遵循兩個原則：
是不是業界公認的。如果不是，最好避免。業界公認的解決方案往往經過過嚴格的檢驗， 評價，批評，經得起考驗；
有沒有廣泛的類庫支持，以及多語言的支持。如果有，可以節省大量的開發以及維護的時間和精力。
（3）數據監控和預警。為了審計以及安全的需求，一般要對加密服務做很多的數據監控，預警的工作。這樣可以知道誰在訪問這些數據，何時訪問的，怎么訪問的，訪問的模式是怎么樣的。監控系統還需要偵測異常的流量變化，進行流量控制以及快速的反攻擊保護。
（4）最后，重中之重，怎么保護 root key？無論是用哪種 envelope encryption的變種，都會涉及到怎么保護 root key。這是一個很有意思的話題，但篇幅關系就不展開來講了。常見的有用 secret sharing的一些變種方式，也有通過公證人公證整個過程藏在銀行保險箱的，也有藏在創始人地下室的：）怎么來 bootstrap 和 deploy 這個 root key 到加密服務里也是一個非常有意思和挑戰的問題。
總的來說，數據加密不是一件神秘的事情，但要做好非常不容易，需要一定的技術積累和資源的投入。做任何一個安全系統，風險都不小。圈內人第一反應是懷疑，因為職業病；圈外人很多也覺得重要，但不關心，或者說不知道怎么關心。但不管如何，無論是因為潛在的法律風險還是用戶的信任風險，這種安全上的投入從長期來說一定是值得的。
傳送門：
4：Ashley Madison 被盜三千多萬用戶數據以及大量支付信息
7：RC4
8：MD5
9：Bcrypt
10：KDF
13：Message authentication code
14：Curve25519
