一開始，有單體式網(wǎng)絡(luò)應(yīng)用程序。然后，隨著應(yīng)用程序的增長和擴展變得越來越困難，各個部分開始拆分為單獨的服務(wù)。微服務(wù)已成為一種越來越流行的架構(gòu)選擇，用于分離關(guān)注點，同時加快開發(fā)和部署。然而，安全性仍然是一個關(guān)鍵但很少被談?wù)摰牟糠帧Ｎ⒎?wù)顯著增加了攻擊面，因為這些服務(wù)通過網(wǎng)絡(luò)來回發(fā)送消息，而不僅僅是在一臺計算機上進(jìn)行進(jìn)程。微服務(wù)或任何面向服務(wù)/網(wǎng)絡(luò)的體系結(jié)構(gòu)的安全性包括兩個組件：傳輸層和應(yīng)用程序?qū)印?/p>

傳輸層

強化傳輸層至關(guān)重要，尤其是在 AWS 或 Rackspace 等共享環(huán)境中，您無法準(zhǔn)確確定網(wǎng)絡(luò)流量的去向或誰可能正在監(jiān)聽。傳輸層安全性 （TLS），有時仍被錯誤地稱為 SSL（TLS 的前身），仍然是加密和驗證連接的基石之一。即使您的服務(wù)不與 HTTP（S） 或 RESTful API 通信，您仍然可以使用 TLS 包裝網(wǎng)絡(luò)套接字。

使用TLS保護(hù)所有網(wǎng)絡(luò)流量通常是謹(jǐn)慎的，盡管工程師似乎經(jīng)常對這樣做有疑慮。如果您擔(dān)心 TLS 會降低性能，負(fù)載均衡器可以提供專用硬件來有效地終止客戶端 TLS 連接，同時保持對后端服務(wù)的持久 TLS 連接處于打開狀態(tài)。這種持久的后端連接減少了與每個請求握手的新 TLS 連接的開銷。

TLS 的一個經(jīng)常被忽視的功能是身份驗證。雖然 TLS 可以保證在數(shù)據(jù)在網(wǎng)絡(luò)中移動時對其進(jìn)行加密，但它也提供了一種機制來強制客戶端和服務(wù)器沒有中間人監(jiān)聽。對于面向公眾的服務(wù)，您必須始終依賴公共（付費）證書頒發(fā)機構(gòu)。如果您有幸同時控制服務(wù)器和每個客戶端，則可以滾動自己的證書頒發(fā)機構(gòu)來簽署證書。

在典型的TLS握手期間，客戶端和服務(wù)器交換寒暄，并小心翼翼地開始設(shè)置安全隧道。在此過程中，客戶端應(yīng)檢查服務(wù)器提供的證書是否由受信任的頒發(fā)機構(gòu)（或頒發(fā)機構(gòu)鏈）簽名。此外，許多 TLS 庫允許客戶端驗證證書的公用名是否與其嘗試連接到的主機名匹配。這兩種檢查都允許客戶端斷言服務(wù)器實際上是客戶端認(rèn)為它的身份，并且通信沒有被攔截。

應(yīng)用層

除了傳輸安全之外，服務(wù)還需要驗證誰在撥打電話，并確保他們有權(quán)這樣做。方便的是，TLS 也提供了一種機制來執(zhí)行此操作：客戶端不僅可以驗證服務(wù)器的證書在加密上是否有效，服務(wù)器也可以類似地對客戶端進(jìn)行身份驗證。在握手期間，服務(wù)器從客戶端請求證書，它可以提供該證書。通過鏡像客戶端，服務(wù)器根據(jù)受信任的證書頒發(fā)機構(gòu)檢查證書的有效性。但是，服務(wù)器隨后可以從證書中提取客戶端的詳細(xì)信息，例如公用名，而不是檢查主機名，而是使用應(yīng)用層邏輯來驗證客戶端是否經(jīng)過身份驗證并被授權(quán)執(zhí)行它們正在嘗試執(zhí)行的操作。這種雙向 TLS 身份驗證允許連接的雙方斷言他們正在與期望的另一方連接。

雙向 TLS 不經(jīng)常使用，可能是由于創(chuàng)建和管理許多證書以及關(guān)聯(lián)的吊銷列表的痛點。但是，管理一組允許的證書與管理一組允許的 API 密鑰非常相似。一種方法是管理一組特定的吊銷證書，充當(dāng)排除列表。但是，如果客戶端證書被視為 API 密鑰，則可以通過已知的白名單管理允許的客戶端。您可以獲得加密保證，即您的客戶就是他們所說的人，同時還確保您的通信是加密的。

結(jié)論

雙向TLS可能并不適合所有情況，但它是一個有用的工具，可以在一個人的工具箱中擁有，并且可能有助于利用您已經(jīng)在使用的技術(shù)。Tinfoil的掃描儀通過雙向TLS進(jìn)行身份驗證，以及其他網(wǎng)絡(luò)層和應(yīng)用層身份驗證方法。正如您不希望應(yīng)用程序出現(xiàn)單點故障一樣，您也不想依賴單一的安全方法。

審核編輯：郭婷