網絡安全已成為每個企業都面臨的關鍵問題。幾乎每天都有關于黑客如何竊取公司數據的頭條新聞。

為了開發安全的軟件并遠離頭條新聞，企業需要解決各種安全問題，包括硬件的物理安全性、傳輸和靜態數據加密、身份驗證、訪問授權以及修補軟件漏洞的策略，等等。

無論你使用的是單體還是微服務架構，大多數問題都是相同的。本文重點介紹微服務架構如何影響應用程序級別的安全性。

應用程序開發人員主要負責實現安全性的四個不同方面：

1、身份驗證

驗證嘗試訪問應用程序的應用程序或人員（安全的術語叫主體）的身份。例如，應用程序通常會驗證訪問的憑據，例如用戶的?ID?和密碼，或應用程序的?API?密鑰。

2、訪問授權

驗證是否允許訪問主體對指定數據完成請求的操作。應用程序通常使用基于角色的安全性和訪問控制列表（ACL）的組合。基于角色的安全性為每個用戶分配一個或多個角色，授予他們調用特定操作的權限。ACL?授予用戶或角色對特定業務對象或聚合執行操作的權限。

3、審計

跟蹤用戶在應用中執行的所有操作，以便檢測安全問題，幫助客戶實現并強制執行合規性。

4、安全的進程間通信

理想情況下，所有進出服務的通信都應該采用傳輸層安全性（TLS）加密。服務間通信甚至可能需要使用身份驗證。

下面將重點介紹如何實現身份驗證和訪問授權。審計和安全的進程間通信的更多詳細介紹請參閱Chris Richardson的《微服務架構設計模式》。

我首先描述如何在FTGO單體應用程序中實現安全性。然后介紹在微服務架構中實現安全性所面臨的挑戰，以及為何在單體架構中運行良好的技術不能在微服務架構中使用。之后，我將介紹如何在微服務架構中實現安全性。

讓我們首先回顧一下FTGO單體應用程序如何處理安全性。

一、傳統單體應用程序的安全性

FTGO應用程序有多種用戶，包括消費者、送餐員和餐館員工。他們使用基于瀏覽器的Web?應用程序和移動應用程序訪問FTGO。所有?FTGO?用戶都必須登錄才能訪問該應用程序。圖?1顯示了單體FTGO?應用程序的客戶端如何驗證和發出請求。

圖1??FTGO?應用程序的客戶首先登錄以獲取會話令牌，該令牌通常是?cookie。客戶在向FTGO?應用程序發出的每個后續請求中都會包括會話令牌

當用戶使用其用戶ID和密碼登錄時，客戶端會向FTGO應用程序發出包含用戶憑據的POST?請求。FTGO?應用程序驗證憑據并將會話令牌返回給客戶端。客戶端在?FTGO?應用程序的每個后續請求中包含會話令牌。

圖2顯示了FTGO應用程序如何實現安全性。FTGO?應用程序是用?Java?編寫的，并使用?Spring Security?框架，但我將使用同樣也適用于其他框架（例如?Passport for Node.js）的一般性術語來描述這個設計。

圖2　當?FTGO?應用程序的客戶端發出登錄請求時，登錄處理程序會對用戶進行身份驗證，初始化會話用戶信息，并返回會話令牌?cookie，以便安全地識別會話。接下來，當客戶端發出包含會話令牌的請求時，SessionBasedSecurityInterceptor?從指定的會話中檢索用戶信息并建立安全上下文。請求處理程序（如OrderDetailsRequestHandler）從安全上下文中檢索用戶信息

使用安全框架

正確實現身份驗證和訪問授權具有挑戰性。最好使用經過驗證的安全框架。使用哪個框架取決于你的應用程序的技術棧。流行的框架包括以下幾個：

1、SpringSecurity

適用于Java應用程序的流行框架。它是一個復雜的框架，可以處理身份驗證和訪問授權。

2、ApacheShiro

另一個?Java?安全框架。

3、Passport

在Node.js應用程序流行的一個專注于身份驗證的安全框架。

安全架構的一個關鍵部分是會話，它存儲主體的?ID?和角色。FTGO?應用程序是傳統的Java EE?應用程序，因此會話是?HttpSession?內存中會話。會話令牌代表著每一個具體的會話，客戶端在每個請求中包含會話令牌。

它通常是一串無法讀懂的數字標記，例如經過加密的強隨機數。FTGO?應用程序的會話令牌是一個名為JSESSIONID的HTTP cookie。

實現安全性的另一個關鍵是安全上下文，它存儲有關發出當前請求的用戶的信息。Spring Security?框架使用標準的?Java EE?方法將安全上下文存儲在靜態的線程局部變量中，任何被調用以處理請求的代碼都可以訪問該變量。

請求處理程序可以調用?SecurityContextHolder. getContext().getAuthentication()?獲取有關當前用戶的信息，例如他們的身份和角色。相反，Passport框架將安全上下文存儲為request對象的user屬性。

圖2?中顯示的事件序列如下：

1．客戶端向?FTGO?應用程序發出登錄請求。

2．登錄請求由?LoginHandler?處理，LoginHandler?驗證憑據，創建會話，并在會話中存儲有關主體的信息。

3．Login Handler?將會話令牌返回給客戶端。

4．客戶端在后續每次調用請求中都包含會話令牌。

5．這些請求首先由?SessionBasedSecurityInterceptor?處理。攔截器通過驗證會話令牌來驗證每個請求并建立安全上下文。安全上下文描述了主體及其角色。

6．請求處理程序使用安全上下文來獲取其身份，并借此確定是否允許用戶執行請求的操作。

FTGO?應用程序使用基于角色的授權。它定義了與不同類型用戶相對應的幾個角色，包括?CONSUMER、RESTAURANT、COURIER和ADMIN。它使用Spring Security的聲明性安全機制來限制對特定角色的?URL?和服務方法的訪問。角色也與業務邏輯交織在一起。例如，消費者只能訪問自己的訂單，而管理員可以訪問所有訂單。

單體FTGO應用程序使用的安全設計只是實現安全性的一種可能方式。例如，使用內存中會話的一個缺點是，它必須把特定會話的所有請求路由到同一個應用程序實例。這個要求使負載均衡和操作變復雜了。

例如，你必須實現會話耗盡機制，該機制在關閉應用程序實例之前等待所有會話到期（以免丟失內存中已有的會話）。避免這些問題的另一種方法是將會話存儲在數據庫中。

開發者可以完全不保存服務器端會話。例如，許多應用程序都有?API?客戶端，可以在每個請求中提供其憑據，例如?API?密鑰和私鑰。因此，無須維護服務器端會話。

或者，應用程序可以將會話狀態存儲在會話令牌中。在本文的后面，我將介紹一種使用會話令牌存儲會話狀態的方法。但讓我們首先看一下在微服務架構中實現安全性的挑戰。

二、在微服務架構中實現安全性

微服務架構是分布式架構。每個外部請求都由API Gateway和至少一個服務處理。例如，考慮getOrderDetails()查詢。API Gateway?通過調用多個服務來處理此查詢，包括Order Service、Kitchen Service?和?Accounting Service。每項服務都必須實現安全性的某些方面。

例如，Order Service必須只允許消費者查看他們自己的訂單，這需要結合身份驗證和訪問授權。為了在微服務架構中實現安全性，我們需要確定誰負責驗證用戶身份以及誰負責訪問授權。

在微服務應用程序中實現安全性的一個挑戰是我們不能僅僅從單體應用程序借鑒設計思路。這是因為單體應用程序的安全架構的一些方面對微服務架構來說是不可用的，例如：

1、內存中的安全上下文

使用內存中的安全上下文（如ThreadLocal）來傳遞用戶身份。服務無法共享內存，因此它們無法使用內存中的安全上下文（如ThreadLocal）來傳遞用戶身份。在微服務架構中，我們需要一種不同的機制來將用戶身份從一個服務傳遞到另一個服務。

2、集中會話

因為內存中的安全上下文沒有意義，內存會話也沒有意義。從理論上講，多種服務可以訪問基于數據庫的會話，但它會違反松耦合的原則。我們需要在微服務架構中使用不同的會話機制。

讓我們通過研究如何處理身份驗證來開始探索微服務架構中的安全性。

由?API Gateway?處理身份驗證

處理身份驗證有兩種不同的方法。一種選擇是讓各個服務分別對用戶進行身份驗證。這種方法的問題在于它允許未經身份驗證的請求進入內部網絡。它依賴于每個開發團隊在所有服務中正確實現安全性。因此，出現安全漏洞的風險和概率都很大。

在服務中實現身份驗證的另一個問題是不同的客戶端以不同的方式進行身份驗證。純API客戶端使用基本身份驗證為每個請求提供憑據。其他客戶端可能首先登錄，然后為每個請求提供會話令牌。但我們要避免在服務中處理多種不同的身份驗證機制。

更好的方法是讓API Gateway在將請求轉發給服務之前對其進行身份驗證。在API Gateway?中進行集中API身份驗證的優勢在于只需要確保這里的驗證是正確的。因此，出現安全漏洞的可能性要小得多。另一個好處是只有API Gateway需要處理各種不同的身份驗證機制。這使得其他服務的實現變得簡單了。

圖3?顯示了這種方法的工作原理。客戶端使用?API Gateway進行身份驗證。API?客戶端在每個請求中包含憑據。基于登錄的客戶端將用戶的憑據發送到API Gateway進行身份驗證，并接收會話令牌。一旦API Gateway驗證了請求，它就會調用一個或多個服務。

圖3 API Gateway?對來自客戶端的請求進行身份驗證，并在其對服務的請求中包含安全令牌。服務使用令牌獲取有關主體的信息。API Gateway?還可以將安全令牌用作會話令牌

模式：訪問令牌

API Gateway?將包含用戶信息（例如其身份和角色）的令牌傳遞給它調用的服務。請參閱：http://microservices.io/patterns/security/access-token.html。

API Gateway?調用的服務需要知道發出請求的主體（用戶的身份）。它還必須驗證請求是否已經過通過身份驗證。解決方案是讓?API Gateway?在每個服務請求中包含一個令牌。服務使用令牌驗證請求，并獲取有關主體的信息。API Gateway?還可以為面向會話的客戶端提供相同的令牌，以用作會話令牌。

客戶端的事件序列如下：

1．?客戶端發出包含憑據的請求給?API Gateway。

2．?API Gateway?對憑據進行身份驗證，創建安全令牌，并將其傳遞給服務。

基于登錄的客戶端的事件序列如下：

1．客戶端發出包含憑據的登錄請求。

2．API Gateway?返回安全令牌。

3．客戶端在調用操作的請求中包含安全令牌。

4．API Gateway?驗證安全令牌并將其轉發給服務。

讓我們首先看一下安全性的另一個主要方面：訪問授權。

處理訪問授權

驗證客戶端的憑據很重要，但這還不夠。應用程序還必須實現訪問授權機制，以驗證是否允許客戶端執行所請求的操作。例如，在FTGO應用程序中，getOrderDetails()查詢只能由下此?Order?的消費者（基于實例的安全性的一個示例）和為所有消費者提供服務的客戶服務代表調用。

實現訪問授權的一個位置是?API Gateway。例如，它可以將對?GET/orders/{orderId}的訪問限制為消費者和客戶服務代表。如果不允許用戶訪問特定路徑，則API Gateway可以在將請求轉發到服務之前拒絕該請求。

與身份驗證一樣，在API Gateway中集中實現訪問授權可降低安全漏洞的風險。你可以使用安全框架（如?Spring Security）在API Gateway中實現訪問授權。

在?API Gateway?中實現訪問授權的一個弊端是，它有可能產生API Gateway與服務之間的耦合，要求它們以同步的方式進行代碼更新。而且，API Gateway通常只能實現對URL路徑的基于角色的訪問。由?API Gateway?實現對單個領域對象的訪問授權通常是不實際的，因為這需要詳細了解服務的領域邏輯。

另一個實現訪問授權的位置是服務。服務可以對URL和服務方法實現基于角色的訪問授權。它還可以實現?ACL?來管理對聚合的訪問。例如，在Order Service中可以實現基于角色和基于ACL的授權機制，以控制對?Order的訪問。FTGO應用程序中的其他服務也可以實現類似的訪問授權邏輯。

使用?JWT?傳遞用戶身份和角色

在微服務架構中實現安全性時，你需要確定?API Gateway應使用哪種類型的令牌來將用戶信息傳遞給服務。有兩種類型的令牌可供選擇。一種選擇是使用不透明（無可讀性）的令牌，它們通常是一串UUID。

不透明令牌的缺點是它們會降低性能和可用性，并增加延遲。因為這種令牌的接收方必須對安全服務發起同步?RPC?調用，以驗證令牌并檢索用戶信息。

另一種消除對安全服務調用的方法是使用包含有關用戶信息的透明令牌。透明令牌的一個流行的標準是?JSON Web令牌（JWT）。JWT是在訪問雙方之間安全地傳遞信息（例如用戶身份和角色）的標準方式。

JWT?的內容包含一個JSON對象，其中有用戶的信息，例如其身份和角色，以及其他元數據，如到期日期等。它使用僅為JWT的創建者所知的數字簽名，例如?API Gateway和JWT的接收者（服務）。該簽名確保惡意第三方不能偽造或篡改JWT。

因為不需要再訪問安全服務進行驗證，JWT的一個問題是這個令牌是自包含的，也就是說它是不可撤消的。根據設計，服務將在驗證?JWT?的簽名和到期日期之后執行請求操作。

因此，沒有切實可行的方法來撤消落入惡意第三方手中的某個JWT令牌。解決方案是發布具有較短到期時間的?JWT，這可以限制惡意方。但是，短期JWT的一個缺點是應用程序必須以某種方式不斷重新發布JWT以保持會話活動。幸運的是，這是?OAuth 2.0?安全標準旨在解決的眾多問題之一。讓我們來看看它是如何工作的。

在微服務架構中使用OAuth 2.0

假設你要為FTGO應用程序實現一個User Service，該應用程序管理包含用戶信息（如憑據和角色）的數據庫。API Gateway?調用User Service?來驗證客戶端請求并獲取JWT。你可以設計User Service的API并使用你喜歡的Web框架實現它。但這不是FTGO應用程序特有的通用功能，自己開發此類服務往往是得不償失的。

幸運的是，你不需要開發這種安全基礎設施。你可以使用名為OAuth 2.0的標準的現成服務或框架。OAuth 2.0?是一種訪問授權協議，最初旨在使公共云服務（如GitHub或Google）的用戶能夠授予第三方應用程序訪問其信息的權限，而不必向第三方應用透露他們的密碼。例如，OAuth 2.0使你能夠安全地授予第三方基于云的持續集成（CI）服務，訪問你的GitHub存儲庫。

雖然?OAuth 2.0?最初的重點是授權訪問公共云服務，但你也可以將其用于應用程序中的身份驗證和訪問授權。讓我們快速了解一下微服務架構如何使用?OAuth 2.0。

OAuth 2.0?中的關鍵概念如下：

1、授權服務器：提供用于驗證用戶身份以及獲取訪問令牌和刷新令牌的?API。Spring OAuth是一個很好的用來構建OAuth 2.0授權服務器的框架。

2、訪問令牌：授予對資源服務器的訪問權限的令牌。訪問令牌的格式取決于具體的實現技術。Spring OAuth?的實現中采用了JWT格式的訪問令牌。

3、刷新令牌：客戶端用于獲取新的AccessToken的長效但同時也可被可撤消的令牌。

4、資源服務器：使用訪問令牌授權訪問的服務。在微服務架構中，服務是資源服務器。

5、客戶端：想要訪問資源服務器的客戶端。在微服務架構中，API Gateway?是OAuth 2.0客戶端。

首先，我們來談談如何驗證API客戶端，然后介紹如何支持基于登錄的客戶端。

圖?4?顯示了API Gateway如何驗證來自API客戶端的請求。API Gateway通過向OAuth 2.0授權服務器發出請求來驗證API客戶端，該服務器返回訪問令牌。然后，API Gateway將包含訪問令牌的一個或多個請求發送到服務。

圖4 API Gateway?通過向?OAuth 2.0?身份驗證服務器發出請求來驗證?API?客戶端。身份驗證服務器返回訪問令牌，API Gateway?將其傳遞給服務。服務驗證令牌的簽名，并提取有關用戶的信息，包括其身份和角色

圖4?所示的事件順序如下：

1、客戶端發出請求，使用基本身份驗證提供它的憑據。

2、API Gateway?向?OAuth 2.0?身份驗證服務器發出?OAuth 2.0?密碼授予（Password Grant）請求（www.oauth.com/oauth2-servers/access-tokens/password-grant/）。

3、身份驗證服務器驗證?API?客戶端的憑據，并返回訪問令牌和刷新令牌。

4、API Gateway?在其對服務的請求中包含訪問令牌。服務驗證訪問令牌并使用它來授權請求。

基于?OAuth 2.0?的API Gateway可以使用OAuth 2.0訪問令牌作為會話令牌來驗證面向會話的客戶端。而且，當訪問令牌到期時，它可以使用刷新令牌獲得新的訪問令牌。

圖5顯示了API Gateway如何使用OAuth 2.0來處理面向會話的客戶端。API客戶端通過將其憑據（發送?POST）到API Gateway的/login?端點來啟動會話。API Gateway?向客戶端返回訪問令牌和刷新令牌。然后，API客戶端在向API Gateway發出請求時提供這兩個令牌。

圖5　客戶端通過將其憑據發送到?API Gateway?來登錄。API Gateway?使用?OAuth 2.0?身份驗證服務器對憑據進行身份驗證，并將訪問令牌和刷新令牌作為?cookie?返回。客戶端在其對?API Gateway?的請求中包括這些令牌

事件順序如下：

1.?基于登錄的客戶端將其憑據發送到?API Gateway。

2. API Gateway的LoginHandler向OAuth 2.0身份驗證服務器發出密碼授予請求（www.?oauth.com/oauth2-servers/access-tokens/password-grant/）。

3.?身份驗證服務器驗證客戶端的憑據，并返回訪問令牌和刷新令牌。

4. API Gateway?將訪問令牌和刷新令牌返回給客戶端，通常是采用?cookie?的形式。

5.?客戶端在向?API Gateway?發出的請求中包含訪問令牌和刷新令牌。

6. API Gateway?的?Session Authentication Interceptor?驗證訪問令牌，并將其包含在對服務的請求中。

如果訪問令牌已經過期或即將過期，API Gateway?將通過發出?OAuth 2.0?刷新授權請求來獲取新的訪問令牌（www.oauth.com/oauth2-servers/access-tokens/refresh-access-tokens/），刷新授權請求發送給授權服務器，請求中包含刷新令牌。如果刷新令牌尚未過期或未被撤消，則授權服務器將返回新的訪問令牌。API Gateway?將新的訪問令牌傳遞給服務并將其返回給客戶端。

使用?OAuth 2.0?的一個重要好處是它是經過驗證的安全標準。使用現成的?OAuth 2.0?身份驗證服務器意味著你不必浪費時間重新發明輪子或者是沒有開發不安全的設計的風險。

但OAuth 2.0?不是在微服務架構中實現安全性的唯一方法。無論你使用哪種方法，三個關鍵思想如下：

1、API Gateway?負責驗證客戶端的身份。

2、API Gateway?和服務使用透明令牌（如?JWT）來傳遞有關主體的信息。

3、服務使用令牌獲取主體的身份和角色。

總結

以上是生活随笔為你收集整理的微服务架构如何保证安全性？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。