說到桑同學，那比我牛出不止一個數量級了。俄亥俄州立大學畢業的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 到加密服務里也是一個非常有意思和挑戰的問題。
總的來說，數據加密不是一件神秘的事情，但要做好非常不容易，需要一定的技術積累和資源的投入。做任何一個安全系統，風險都不小。圈內人第一反應是懷疑，因為職業病;圈外人很多也覺得重要，但不關心，或者說不知道怎么關心。但不管如何，無論是因為潛在的法律風險還是用戶的信任風險，這種安全上的投入從長期來說一定是值得的。
京公網安備 11010502049343號