如何在微服務架構中實現安全性——閱讀筆記15

原文連接：https://mp.weixin.qq.com/s/jZ0wi_xDZPge5nXBjzJHKg

 

微服務架構是分佈式架構。每一個外部請求都由 API Gateway 和至少一個服務處理。例如，考慮 getOrderDetails() 查詢。API Gateway 經過調用多個服務來處理此查詢，包括 Order Service、Kitchen Service 和 Accounting Service。每項服務都必須實現安全性的某些方面。例如，Order Service 必須只容許消費者查看他們本身的訂單，這須要結合身份驗證和訪問受權。爲了在微服務架構中實現安全性，咱們須要肯定誰負責驗證用戶身份以及誰負責訪問受權。

在微服務應用程序中實現安全性的一個挑戰是咱們不能僅僅從單體應用程序借鑑設計思路。這是由於單體應用程序的安全架構的一些方面對微服務架構來講是不可用的

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

在服務中實現身份驗證的另外一個問題是不一樣的客戶端以不一樣的方式進行身份驗證。純 API 客戶端使用基自己份驗證爲每一個請求提供憑據。其餘客戶端可能首先登陸，而後爲每一個請求提供會話令牌。但咱們要避免在服務中處理多種不一樣的身份驗證機制。

更好的方法是讓 API Gateway 在將請求轉發給服務以前對其進行身份驗證。在 API Gateway 中進行集中 API 身份驗證的優點在於只須要確保這裏的驗證是正確的。所以，出現安全漏洞的可能性要小得多。另外一個好處是隻有 API Gateway 須要處理各類不一樣的身份驗證機制。這使得其餘服務的實現變得簡單了。

在微服務架構中實現安全性時，你須要肯定 API Gateway 應使用哪一種類型的令牌來將用戶信息傳遞給服務。有兩種類型的令牌可供選擇。一種選擇是使用不透明（無可讀性）的令牌，它們一般是一串 UUID。不透明令牌的缺點是它們會下降性能和可用性，並增長延遲。由於這種令牌的接收方必須對安全服務發起同步 RPC 調用，以驗證令牌並檢索用戶信息。

另外一種消除對安全服務調用的方法是使用包含有關用戶信息的透明令牌。透明令牌的一個流行的標準是 JSON Web 令牌（JWT）。JWT 是在訪問雙方之間安全地傳遞信息（例如用戶身份和角色）的標準方式。JWT 的內容包含一個 JSON 對象，其中有用戶的信息，例如其身份和角色，以及其餘元數據，如到期日期等。它使用僅爲 JWT 的建立者所知的數字簽名，例如 API Gateway 和 JWT 的接收者（服務）。該簽名確保惡意第三方不能僞造或篡改 JWT。