數據加密：開發人員必須知道的關鍵術語

隨著世界變得越來越受數據驅動，用戶數據的安全處理比以往任何時候都更加重要。

作為開發人員，我們的工作已經足夠艱鉅：處理具有多個故障點的高度複雜和脆弱的系統，同時將人類的願望轉化為 UI 和後端。 添加到任務中的是一個新興且必不可少的考慮因素：數據安全。 並且有一個很好的理由：如果我們的數據被濫用，我們作為客戶會被激怒（因此，我們為用戶提供安全和愉快的體驗是公平的），並且政府和企業要求遵守。

數據安全是推卸責任

讓安全變得更難的是它有幾個層次，並成為每個人的責任，沒有人的責任。 在現代云團隊中，多個團隊直接控制數據的入口/出口：開發人員、數據庫管理員、系統管理員（DevOps 人員，如果您願意）、特權後台用戶等。 這些角色/團隊可以迅速閉上眼睛，將數據安全視為其他人的問題。 儘管如此，現實情況是他們有自己的世界需要照顧，因為數據庫管理員無法控制應用程序方面的安全性，DevOps 人員對後台訪問完全無能為力，等等。

開發人員和數據安全

儘管如此，開發人員在數據方面擁有最大的訪問範圍：他們構建應用程序的每個部分； 它們連接到各種後端服務； 來回渡輪訪問令牌； 他們有整個數據庫集群可以按照他們的命令讀/寫； 他們編寫的應用程序可以毫無疑問地訪問系統的所有部分（例如，生產中的 Django 應用程序擁有轉儲或擦除過去十年的整個 S3 集合的所有權限），等等。 因此，在安全性方面的草率或疏忽的最大可能性存在於源代碼級別，並且是開發人員的直接責任。

現在，數據安全是一個無底洞，我什至無法在一個帖子中觸及表面。 但是，我想介紹開發人員必須知道的基本術語，以確保他們的應用程序安全。 將其視為應用數據安全 101。

讓我們開始吧！

散列

如果你想要一個高度嚴格的定義，總有維基百科，但簡單來說，散列是將數據轉換為另一種形式的過程，其中信息是不可讀的。 例如，使用眾所周知（並且非常不安全）的 Base64 編碼過程，字符串“我的秘密對你安全嗎？” 可以轉換（“散列”）為“SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”。 例如，如果您開始以 Base64 格式編寫個人日記，您的家人將無法讀取您的秘密（除非他們知道如何從 Base64 解碼）！

在網絡應用程序中存儲密碼、信用卡號等時使用這種加擾數據的想法（實際上，它應該用於所有類型的應用程序）。 當然，這個想法是在發生數據洩露的情況下，攻擊者不應該能夠使用密碼、信用卡號等來造成實際損害。 高度健壯和復雜的算法用於執行此散列； 像 Base64 這樣的東西將是一個笑話，任何攻擊者都會立即破解。

密碼散列使用一種稱為單向散列的加密技術，這意味著雖然可以對數據進行加擾，但無法對其進行解擾。 那麼當您登錄時，該應用程序如何知道這是您的密碼？ 嗯，它使用相同的過程並將您剛剛輸入的密碼的加擾形式與存儲在數據庫中的加擾形式進行比較； 如果它們匹配，您就可以登錄！

當我們討論哈希的主題時，這裡有一些有趣的事情。 如果您曾經從 Internet 下載過軟件或文件，您可能會被告知在使用這些文件之前對其進行驗證。 例如，如果您想下載 Ubuntu Linux ISO，下載頁面將顯示一個選項來驗證您的下載； 如果單擊它，將打開一個彈出窗口：

彈出窗口會告訴您運行一個命令，該命令實際上將對您剛剛下載的整個文件進行散列，並將結果與您在下載頁面上看到的散列字符串進行比較： 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 。 此轉換使用 SHA256 算法執行，您可以在命令的最後部分看到該算法的提及： shasum -a 256 --check 。

這個想法是，如果通過您的支票生成的哈希不同，這意味著有人干預了您的下載並為您提供了一個受損的文件。

您將在密碼散列領域聽到的一些熟悉名稱是 MD5（不安全且現已失效）、SHA-1 和 SHA-2（算法家族，SHA-256 是其中的成員，SHA-512 也是如此）， SCRYPT、BCRYPT 等

鹽

所有類型的安全都是一場貓捉老鼠的遊戲：小偷學習當前的系統並想出一個新穎的破解方法，引起注意，鎖匠改進他們的遊戲，等等。 密碼學也不例外。 雖然將哈希值轉換回密碼已變得不可能，但隨著時間的推移，攻擊者已經開發出將智能猜測與純粹的計算能力相結合的複雜技術； 結果，十之八九，他們可以預測正確的密碼，只要給出哈希值。

因此，鹽漬技術得到了發展。 這意味著密碼（或任何數據）的哈希計算將基於兩件事的組合來完成：數據本身，以及攻擊者無法猜測的新隨機字符串。 因此，通過加鹽，如果我們想對密碼superman009進行散列，我們首先選擇一個隨機字符串作為“salt”， bCQC6Z2LlbAsqj77 ，然後對superman009-bCQC6Z2LlbAsqj77執行散列計算。 生成的散列將偏離算法生成的通常結構，大大減少了智能逆向工程或猜測的範圍。

Hashing 和 Salting 都是極其複雜的領域，並且都在不斷發展。 因此，作為應用程序開發人員，我們永遠不會直接與他們打交道。 但是，如果我們知道這些並且可以做出更好的決定，那將對我們有很大幫助。 例如，如果您維護一個舊的 PHP 框架並且碰巧看到它使用 MD5 哈希作為密碼，那麼您就知道是時候在用戶帳戶創建過程中插入另一個密碼庫了。

鑰匙

在加密的上下文中，您經常會遇到術語“密鑰”。 到目前為止，我們一直在討論密碼散列或單向加密，其中我們不可逆地轉換數據並破壞原始形式。 這對於日常實際使用來說是個壞主意——一個寫得如此安全並通過電子郵件發送到永遠無法閱讀的文檔是沒有用的！ 因此，我們想要加密數據，以便我們希望信息對發送方和接收方公開，但在傳輸或存儲時，它應該是不可讀的。

為此，密碼學中存在“密鑰”的概念。 這正是它聽起來的樣子：鎖的鑰匙。 擁有信息的人使用一些稱為密鑰的秘密對其進行加密。 除非接收者/攻擊者擁有這個密鑰，否則無論他們的算法多麼複雜，都無法解密數據。

旋轉鍵

雖然密鑰使加密成為可能且可靠，但它們也帶來密碼的風險：一旦有人知道密鑰，整個遊戲就結束了。 想像一個場景，有人入侵了像 GitHub 這樣的服務的某些部分（即使只有幾秒鐘），並且可以獲得 20 年前的代碼。 在代碼中，他們還發現了用於加密公司數據的加密密鑰（將密鑰與源代碼一起存儲的可怕做法，但您會驚訝地發現這種情況發生的頻率如此之高！）。 如果公司沒有費心更改其密鑰（就像密碼一樣），則可以使用相同的密鑰造成嚴重破壞。

因此，頻繁更改密鑰的做法得到了發展。 這稱為密鑰輪換，如果您使用的是任何受人尊敬的雲 PaaS 提供商，它應該可以作為自動化服務使用。

例如，AWS 有專門的服務，稱為 AWS 密鑰管理服務 (KMS)。 自動化服務可以為您省去在所有服務器之間更改和分配密鑰的麻煩，並且在如今的大型部署中是一件輕而易舉的事情。

公鑰密碼學

如果之前所有關於加密和密鑰的討論讓您認為它非常麻煩，那麼您是對的。 保持密鑰安全並傳遞它們，以便只有接收者可以看到數據，這會導致今天的安全通信無法繁榮的後勤問題。 但全都歸功於公鑰密碼學，我們可以安全地在線交流或購物。

這種類型的密碼學是一項重大的數學突破，也是互聯網不會因恐懼和不信任而崩潰的唯一原因。 該算法的細節複雜且高度數學化，因此我在這裡只能從概念上解釋它。

公鑰密碼術依賴於使用兩個密鑰來處理信息。 其中一把鑰匙稱為私鑰，應該對您保密，永遠不會與任何人共享； 另一個稱為公鑰（方法名稱的來源），應該公開發布。 如果我要向您發送數據，首先需要獲取您的公鑰並加密數據並發送給您； 最後，您可以使用您的私鑰和公鑰組合解密數據。 只要你不小心洩露你的私鑰，我可以把只有你能打開的加密數據發送給你。

該系統的美妙之處在於我不需要知道您的私鑰，任何攔截消息的人都無法讀取它，即使他們擁有您的公鑰。 如果你想知道這怎麼可能，最短和最非技術性的答案來自質數乘法的屬性：

計算機很難分解大素數。 因此，如果原始密鑰非常大，您可以確定即使數千年也無法解密該消息。

傳輸層安全 (TLS)

您現在知道公鑰密碼學的工作原理了。 這種機制（知道接收者的公鑰並向他們發送使用該公鑰加密的數據）是所有 HTTPS 流行背後的原因，也是導致 Chrome 說“這個網站是安全的”的原因。 發生的事情是服務器和瀏覽器正在使用彼此的公鑰加密 HTTP 流量（請記住，網頁是瀏覽器可以解釋的很長的文本字符串），從而產生安全 HTTP (HTTPS)。

圖片來源：Mozilla 有趣的是，加密不會發生在傳輸層上； OSI 模型沒有提及加密數據。 只是數據在傳輸到傳輸層之前由應用程序（在本例中為瀏覽器）加密，傳輸層稍後將其發送到目的地，並在那裡解密。 但是，該過程涉及傳輸層，歸根結底，這一切都會導致數據的安全傳輸，因此“傳輸”層安全性這個鬆散的術語一直存在。

在某些情況下，您甚至可能會遇到術語安全套接字層 (SSL)。 它與 TLS 的概念相同，只是 SSL 起源於很久以前，現在已被 TLS 取代。

全盤加密

有時，安全需求如此強烈，以至於不能有任何僥倖心理。 例如，存儲一個國家所有生物特徵數據的政府服務器不能像普通應用服務器一樣配置和運行，因為風險太高。 僅在傳輸時對數據進行加密不足以滿足這些需求； 它也必須在靜止時加密。 為此，全盤加密用於對整個硬盤進行加密，以確保數據即使在物理上遭到破壞時也是安全的。

需要注意的是，全盤加密必須在硬件級別完成。 之所以如此，是因為如果我們對整個磁盤進行加密，那麼操作系統也被加密，機器啟動時無法運行。 因此，硬件必須了解磁盤內容是加密的，並且必須在將請求的磁盤塊傳遞給操作系統時即時執行解密。 由於要完成這項額外工作，全盤加密會導致讀/寫速度變慢，此類系統的開發人員必須牢記這一點。

端到端加密

如今，隨著大型社交網絡的隱私和安全噩夢不斷，沒有人不知道“端到端加密”一詞，即使它們與製作或維護應用程序無關。

我們之前看到了全盤加密是如何提供終極防彈策略的，但是對於日常用戶來說，它並不方便。 我的意思是，想像一下 Facebook 希望它生成並存儲在您手機中的手機數據是安全的，但它無法訪問加密您的整個手機並在此過程中鎖定其他所有內容。

出於這個原因，這些公司已經開始端到端加密，這意味著數據在應用程序創建、存儲或傳輸時會被加密。 換句話說，即使數據到達接收者，它也是完全加密的，並且只能通過接收者的手機訪問。

請注意，端到端 (E2E) 加密不像公鑰加密那樣帶有任何數學保證； 它只是標準加密，其中密鑰與企業一起存儲，您的消息與企業決定的一樣安全。

結論

您可能已經聽說過這些術語中的大部分。 甚至可能是全部。 如果是這樣，我鼓勵您重新審視您對這些概念的理解，並評估您對它們的重視程度。 請記住，應用程序數據安全是一場您需要每次（而不僅僅是一次）贏得的戰爭，因為即使是一次違規也足以摧毀整個行業、職業甚至生活！