一開始，有單體式網絡應用程序。然后，隨著應用程序的增長和擴展變得越來越困難，各個部分開始拆分為單獨的服務。微服務已成為一種越來越流行的架構選擇，用于分離關注點，同時加快開發和部署。然而，安全性仍然是一個關鍵但很少被談論的部分。微服務顯著增加了攻擊面，因為這些服務通過網絡來回發送消息，而不僅僅是在一臺計算機上進行進程。微服務或任何面向服務/網絡的體系結構的安全性包括兩個組件：傳輸層和應用程序層。

傳輸層

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

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

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

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

應用層

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

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

結論

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

審核編輯：郭婷