微服務架構下訪問安全性問題的研究獲獎科研報告摘

要：近年來，微服務的應用開發架構越來越受到軟件開發人員的關注和青睞，很多公司都已經開始使用微服務架構來進行應用程序的開發。但是微服務架構的應用，也引入了很多對應的安全問題。本文主要從微服務架構核心安全問題，從用戶訪問微服務的身份認證和鑒權、微服務與微服務之間的通信時身份認證與鑒權，微服務與第三方通信的邊界三個方面進行分析，并對目前針對這些問題常用的解決方案和技術進行研究和探索。

微服務架構的引入為軟件的開發帶了諸多好處，比如開發語言選擇的靈活性，縮短軟件的開發周期，減少小團隊軟件開發成本，增強應用服務的伸縮能力等等。微服務架構在帶來各種開發優勢的同時，也帶了分布式系統的很多安全問題，微服務架構在帶來各種開發優勢的同時，也帶了分布式系統的很多安全問題。對于微服務的安全性問題來說，其應用層的訪問權限和鑒權的安全性問題是整個安全體系中占據著至關重要的地位。

1微服務架構下安全問題簡述

微服務架構是一種將單個應用程序作為一套小型服務開發的方法，每種應用服務程序都可以獨立在自己的進程中運行，并且相互之間可以使用輕量級機制來進行通信。這些服務程序主要圍繞業務進行構建，每個應用程序都可以部署到獨立的服務器上，因此其可以使用自動部署機制進行獨立部署，而且每個應用服務都可以使用不同的編程語言進行編寫，也可以使用不同數據管理技術，

傳統的單體應用時，通常所有的服務都是部署在同一臺服務器上的，各應用接口之間的調用通常是屬于本地調用方式，而且每項服務（或者組件）不需要對用戶進行驗證。驗證工作主要集中由攔截器（如JavaEE的servlet）處理，攔截器對訪問身份和全向進行驗證審查其是否允許訪問。驗證完成之后，在不同平臺上的不同服務（或者組件）間發送用戶登錄憑證。而微服務模式下，不同的服務是分別部署在不同的服務器上的，因此每個服務器上都需要進行用戶身份驗證和鑒權信息。

基于以上現象，微服務架構的身份認證和鑒權問題是影響整個微服務架構安全的核心問題，其對微服務架構的推廣和應用起著關鍵性的作用。

2微服務架構的身份認證與鑒權問題

2.1用戶訪問微服務的身份認證和鑒權

用戶訪問微服務時，主要是用戶身份信息傳遞的安全性問題，其包含用戶身份信息的認證信息和對應身份和權限信息的管理問題。對于用戶訪問微服務的身份認證與鑒權的方法，

第一種現有的方法就是使用單點登錄（SSO），但是在這種方案中，每個面向用戶的服務都必須與認證服務交互，這會產生大量非常瑣碎的網絡流量和重復的工作，當動輒數十個微應用時，這種方案的弊端會更加明顯。

第二種是分布式的Session，這種方案的原理主要是將關于用戶認證的信息存儲在共享存儲中，且通常由用戶會話作為key來實現的簡單分布式哈希映射。當用戶訪問微服務時，用戶數據可以從共享存儲中獲取。在某些場景下，這種方案很不錯，用戶登錄狀態是不透明的。同時也是一個高可用且可擴展的解決方案。這種方案的缺點在于共享存儲需要一定保護機制，因此需要通過安全鏈接來訪問，這時解決方案的實現就通常具有相當高的復雜性了。第三種方法就是客戶端Token方案，這種方案里令牌在客戶端生成，由身份驗證服務進行簽名，并且必須包含足夠的信息，以便可以在所有微服務中建立用戶身份。令牌會附加到每個請求上，為微服務提供用戶身份驗證，這種解決方案的安全性相對較好，但身份驗證注銷是一個大問題，緩解這種情況的方法可以使用短期令牌和頻繁檢查認證服務等。對于客戶端令牌的編碼方案，Borsos更喜歡使用JSONWebTokens（JWT），它足夠簡單且庫支持程度也比較好。目前還有一種解決方案是客戶端Token與API網關結合，這個方案里所有請求都通過網關，從而可以有效地隱藏了微服務。在請求時，網關將原始用戶令牌轉換為內部會話ID令牌。這種方案的出現主要是為了解決第三種方案中撤銷服務難的問題。

2.2微服務與微服務之間的通信時身份認證與鑒權

微服務之間的產生通信的場景主要包括用戶間接觸發的微服務之間的相互訪問和非用戶觸發的微服務之間的相互訪問兩種，針對這兩種情況，根據應用系統的數據敏感程度的不同，對于系統內微服務的相互訪問可能有不同的安全要求充分考慮，對于微服務之間通信時的身份認證和鑒權問題，目前常用的方式有采用ServiceAccount（服務賬號）進行安全控制，這種方法是使用用戶賬號（UserAccount）來標識一個系統用戶，并對其進行身份認證和操作鑒權。類似地，可以為系統中每一個服務也創建一個賬號，稱為服務賬號（ServiceAccout）。該服務賬號表示了微服務的身份，以用于控制該微服務對系統中其它微服務的訪問權限。當一個微服務訪問另一個微服務時，被訪問的微服務需要驗證訪問者的服務賬號，以確定其身份和資源操作權限。另一種方法是采用服務之間相互進行身份識別的SPIFEE標準。

2.3微服務與第三方通信的邊界安全問題

除用戶訪問和微服務之間的相互訪問外，外部的第三方系統也可能需要訪問系統內部的微服務。對于微服務集與外部世界的通信，一般由API網關模式實現。利用API網關模式，需要進行聲明的微服務能夠在該網關內獲得對應的API。當然，并不是所有微服務都需要立足于API網關實現聲明。而且最終用戶對微服務的訪問（通過API實現）應當在邊界或者API網關處進行驗證。對目前最為常見的API安全保護模式為OAuth2.0方式進行研究和驗證。

對于微服務與第三方應用的身份認證與鑒權問題，目前也有了一些解決方案，第一種就是使用APIToken，由微服務應用提供一個APIToken的生成界面，用戶登錄后可以生成自己的APIToken，并在第三方應用使用該APIToken訪問微服務的API。這樣就只允許第三方應用訪問該Token所屬用戶自身的數據，而不能訪問其他用戶的敏感私有數據。但是某些第三方應用需要訪問不同用戶的數據，或者對多個用戶的數據進行整合處理，就出現了使用OAuth來進行權限控制的操作。這種方式在當第三方應用訪問服務時，應用會提示用戶授權第三方應用相應的訪問權限，根據用戶的授權操作結果生成用于訪問的Token，以對第三方應用的操作請求進行訪問控制。