幾種微服務安全機制

邊界安全
執行邊界安全是保護微服務的一種非常傳統的方法。 這意味著單個微服務不安全;訪問微服務的層必須是受信任的。

對Web應用程式的訪問是安全的，並且Web應用程式自由地呼叫微服務層。各個微服務彼此自由互動。

有一些與微服務相關的特性和要求使得邊際的安全性不足。

1.由於各種原因，應在每個服務執行認證或授權。
2.每個細粒度的服務是一個小團隊的責任。 這可能意味著保證資料的安全性也是他們的責任。

使用者名稱和密碼
在這種方法中，每個微服務將使用BasicAuthentication進行保護。 有幾種方法來實現這一點。

1.終端使用者憑據。 在這種情況下，每個微服務需要終端使用者的使用者名稱和密碼來執行認證或授權。 當應用程式呼叫微服務或微服務呼叫另一個微服務時，它必須傳遞終端使用者的使用者名稱和密碼。 這種方法有很多安全隱患。

2.每個微服務都應該有權訪問終端使用者憑證儲存。

3.使用者名稱和密碼必須由每個服務被儲存在儲存器或會話，以便當一個微服務正在呼叫另一個微服務時使用。

4.受信任的子系統憑據。 使用者名稱和密碼用於受信任的子系統（例如，系統中的每個實體都有一個憑據集）。這種方法的缺點是終端使用者是未知的，因此不能執行授權。如果一個實體更新憑證，會發生什麼？ 如果憑據儲存在檔案中，則應在每個例項中更新此檔案。

雙向SSL
在此安全機制中，系統中的每個實體都有一個證書（公共和私有）金鑰對，並使用雙向SSL彼此通訊。在正常的SSL場景中，伺服器由客戶端進行身份驗證，但在雙向SSL中，雙方都彼此進行身份驗證。 與終端使用者使用者名稱和密碼方法相比，這是一個更好的方法，因為風險很小。

然而，這種方法的一些缺點在下面給出。

1.每個微服務都需要一個證書，所以當更新證書時，更新需要在所有例項中進行。
2.終端使用者不能在此模式下授權或認證。
3.它具有與可信子系統模式類似的優點和缺點。

OAuth 2.0和OpenID Connect
微服務可以使用OAuth 2.0以及OpenID連線來驗證和授權使用者。有一個IdP提供方向請求方提供OAuth 2.0令牌。 例如，應用程式獲得OAuth 2.0訪問令牌，並且訪問此令牌用於呼叫MSA中的所有服務。 它也可以用於微服務之間的通訊。 使用短壽命訪問，令牌簡化並提高整個系統的安全性。 使用OpenID連線，可以檢索終端使用者的身份，允許微服務執行授權本身。

然而，這種方法的缺點是對IdP額外方的呼叫。

自包含JWT令牌
自包含JWT令牌是在令牌本身內具有授權資訊，即令牌由發行者簽名，並且所有各方可以驗證令牌的有效性。 這意味著微服務不需要呼叫外部方來驗證訪問令牌並獲得JWT令牌。消除了驗證接入令牌並獲得承載令牌的附加呼叫。 它具有OAuth2.0的所有優點，但不具有短壽命標記的缺點。

這是一種最合適的微服務安全方式。

Securing Microservices: A Brief Look at Different