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

傳輸層

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

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

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

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

應用層

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

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

結論

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

審核編輯：郭婷