幾種微服務安全機制

banq發表於2016-12-08
微服務
在微服務架構中，一組細粒度微服務透過相互互動以構建應用或實現業務功能。每個細粒度的服務是實現單個功能或透過網路訪問實現幾個相關功能。這導致被攻擊機會增加，尤其顯得微服務架構的安全性非常重要。

保護微服務安全的一些常見技術如下：
1.邊界安全。
2.使用者名稱和密碼。
3.雙向SSL。
4.OAuth 2.0和OpenID Connect。
5.自包含的JWT令牌。

讓我們深入瞭解每一個利弊。

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

對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

相關文章