摘要：微服務能夠為應用程序設計提供一種更具針對性范圍性與模塊性的實現方案。安全微服務部署模式可謂多種多樣但其中使用最為廣泛的當數每主機服務模式。在微服務環境下，安全性往往成為最大的挑戰。不同微服務之間可通過多種方式建立受信關系。

每個人都在討論微服務，每個人也都希望能夠實現微服務架構，而微服務安全也日漸成為大家關注的重要問題。今天小數與大家分享的文章，就從應用層面深入探討了應對微服務安全挑戰的方案，為微服務安全提供了新的思路。

面向服務架構（簡稱SOA）引入了一類設計規范，其核心思路在于采用高度解耦式服務部署，其中各項服務可通過一套標準信息格式經由網絡實現彼此通信。這套方案與具體技術無關，即不考慮各項服務具體是如何實現的。每項服務都擁有一個明確定義，用于發布服務描述或者服務接口。在實踐當中，這類信息格式通過SOAP實現標準化——即由W3C于2000年初推出的一項標準——同時亦基于XML——其中服務描述由WSDL（另一項W3C標準）進行標準化，而服務發現標準由UDDI（同樣為W3C標準）實現。這一切正是基于SOAP的Web服務的實現基礎，甚至使得Web服務在一定程度上成了SOA的代名詞。不過這種實現方式在架構模式層面也有著自己的缺陷。SOA的基本原則正被時代所逐步淘汰，如今由OASIS提供的WS-*堆棧（包括WS-Security， WS-Policy， WS-Security Policy，WS-Trust, WS-Federation, WS-Secure Conversation, WS-Reliable Messaging, WS-Atomic Transactions, WS-BPEL等等）令SOA的復雜性不斷提高，這也直接導致很多普通開發者發現自己很難對其加以駕馭。

多年之后，如今我們得以再次開啟這段通往SOA基本原則的旅途——但這一次它有了新的名號，即微服務。微服務能夠為應用程序設計提供一種更具針對性、范圍性與模塊性的實現方案。

微服務可謂當下一大熱門詞匯之一，與之并駕齊驅的則包括物聯網、容器化與區塊鏈。“微服務”一詞最初于2011年5月亮相于威尼斯軟件架構師研討會。這個詞匯用于解釋一類常見的架構類型。

大家已經意識到微服務并不僅僅是做對了的SOA，它也不只是一種架構模式——而是一種圍繞架構模式展開的全新文化。其由主要目標作為驅動力，旨在實現快速部署與快速生產。

在保護微服務安全時，需要從以下幾個角度入手：

保護開發生命周期與測試自動化機制：微服務背后的核心驅動力在于提升投付生產的速度。我們需要向服務當中引入變更，加以測試而后立即將成果部署至生產環境。為了確保在代碼層面中不存在安全漏洞，我們需要制定規劃以進行靜態代碼分析與動態測試——更重要的是，這些測試應當成為持續交付流程的組成部分。任何安全漏洞都需要在早期開發周期內被發現，另外反饋周期也必須盡可能得到縮短。

DevOps安全：微服務部署模式可謂多種多樣——但其中使用最為廣泛的當數每主機服務模式。其中的主機指定的并不一定是物理設備——也很可能屬于容器（Docker）。我們需要對容器層面的安全進行關注。我們該如何確保各容器之間得到有效隔離，又該在容器與主機操作系統之間采取怎樣的隔離水平？

應用級別安全：我們該如何驗證用戶身份并對其微服務訪問操作進行控制，又要怎樣保障不同微服務之間的通信安全？

在今天的文章中，我們將提供一整套安全模式，旨在解決應用層級所面臨的各類微服務安全保護挑戰。

在整體型應用程序中，所有服務都被部署在同一應用服務器當中，而該應用服務器本身則提供會話管理功能。其中不同服務間的接口為本地調用，且全部服務皆可共享用戶的邏輯狀態。每項服務（或者組件）不需要對用戶進行驗證。驗證工作集中由攔截器處理，其攔截所有服務調用并審查其是否可以放行。驗證完成之后，其會在不同平臺上的不同服務（或者組件）間發送用戶登錄憑證。以下示意圖解釋了整體應用程序中各不同組件間的交互方式。

在Java EE環境下，攔截器可以由servlet過濾器充當。該servlet過濾器會攔截全部來自其已注冊上下文的請求，并強制進行驗證。該服務調用要么攜帶有效的憑證，要么擁有能夠映射至某個用戶的會話令牌。一旦servlet過濾器找到該用戶，則會創建登錄上下文，并將其傳遞給下游組件。每個下游組件都能夠從該登錄上下文內識別出用戶以完成授權。

在微服務環境下，安全性往往成為最大的挑戰。在微服務架構當中，各服務分布及部署在分布式設置當中的多套容器之內。各服務接口不再存在于本地，而是通過HTTP進行遠程接入。以下示意圖顯示了不同微服務之間的交互方式。

這里的挑戰在于，我們要如何驗證用戶并在不同微服務之間以對稱方式完成登錄上下文傳遞，隨后還要想辦法讓微服務完成對用戶的授權。

在今天的文章中，我們將探討兩套方案，旨在保護服務到服務通信。其一基于JWT，其二則基于TLS相互驗證。

JWT（即JSON Web令牌）負責定義一套容器，旨在完成各方之間的數據傳輸。其可用于：

在各方之間傳播其中一方的身份。

在各方之間傳播用戶權利。

通過非安全通道在各方之間安全實現數據傳輸。

根據JWT受信指標判斷用戶身份。

已簽名JWT被稱為JWS（即JSON Web簽名），而加密JWT則被稱為JWE（即JSON Web加密）。事實上，JWT并不會以自身原始方式存在——其要么作為JWS，要么作為JWE，它像是一種抽象類——JWS與JWE為其具體實現方式。

來自某一微服務并將被傳遞至另一微服務的用戶上下文可伴隨JWS一同傳遞。由于JWS由上游微服務的某一已知密鑰進行簽名，因此JWS會同時包含有最終用戶身份（在JWT中聲明）以及上游微服務身份（通過簽名實現）。為了接收JWS，下游微服務首先需要根據JWS本身中的嵌入公鑰對JWS的簽名進行驗證。這還不夠，我們還需要檢查該密鑰是否受信。不同微服務之間可通過多種方式建立受信關系。其一為由服務為各服務配置受信證書。很明顯，這種方式在規模化微服務部署環境中并不可行。因此我建議大家建立一套專有證書中心（簡稱CA），同時可以為不同微服務組設置中介證書中心。現在，相較于互相信任及各自分配不同的證書，下游微服務將只需要信任根證書授權或者中介機制即可。這能夠顯著降低證書配置所帶來的管理負擔。

每項微服務都需要承擔JWT驗證成本，其中還包含用于驗證令牌簽名的加密操作。微服務層級中的JWT會進行緩存，而非每次進行數據提取，這就降低了重復令牌驗證造成的性能影響。緩存過期時間必須與JWT的到期時間相匹配。正是由于利用這種機制，因此如果JWT的過期時間設定得太短，則會給緩存性能造成嚴重影響。

JWT在其聲明集中包含一項參數，名為sub，其代表擁有該JWT的主體或者用戶。JWT本身也可以包含各類用戶屬性，例如first_name、last_name、email等等。如果任何微服務需要在其操作過程中識別此用戶，則需要查看對應的屬性。Sub屬性的值對于給定發行者而言是惟一的。如果大家擁有一項微服務，其能夠從多個發行者處接收令牌，那么該用戶的惟一性應被認定為該發行者與sub屬性的結合體。

而aud參數同樣存在于JWT聲明集內，負責指定令牌的目標受眾。其可以是單個接收者或者是一組接收者。在執行任何驗證檢查之前，該令牌接收者都必須首先查看是否發布了特定JWT供其使用，如果沒有則立即拒絕。令牌發送方需要在發出令牌之前，確定該令牌實際接收者的身份，同時aud參數值必須屬于令牌發送方與接收方間預先約定的值。在微服務環境中，我們可以利用正規表達式來驗證令牌受眾。舉例來說，令牌中的aud值可以為*.facilelogin.com，意味著facilelogin.com域名下的每個接收方（例如foo.facilelogin.com,bar.facilelogin.com等）都能夠擁有自己的aud值。

在TLS相互驗證與JWT方法當中，每項微服務都需要擁有自己的證書。這兩種方法的區別在于，JWT驗證機制中JWS可同時攜帶最終用戶身份以及上游服務身份。而TLS相互驗證則只在應用層傳輸最終用戶身份。

在以上提到的兩種方案當中，證書吊銷都是項棘手的任務。證書吊銷盡管難以實現，但仍然存在多種選項供我們選擇：

CRL (證書吊銷列表 / RFC 2459)

OCSP (在線證書狀態協議 / RFC 2560)

OCSP Stapling (RFC 6066)

OCSP Stapling Required (尚處于草案階段)

CRL的使用頻率并不高。客戶端在發起TLS握手時，必須從對應的證書頒發中心處獲取一份長長的吊銷證書列表，而后檢查服務器證書是否被列入該列表。相較于每一次進行列表獲取，客戶端可以在本地對CRL進行緩存。在此之后，大家還需要考慮如何避免以陳舊數據為基礎做出判斷的問題。當TLS相互驗證機制被使用時，服務器也需要針對客戶端進行同樣的證書驗證。最終，人們發現CRL的實際效果其實并不理想，因此新的解決方案也應運而生——這就是OCSP。

在OCSP當中，一切元素的實際效果都要比CRL好上那么一點。TLS客戶端能夠檢查特定證書的狀態，且無需從證書中心處下載完整的吊銷證書列表。換句話來說，當客戶端每次與新的下游微服務進行通信時，其都必須同對應的OCSP響應方溝通以驗證當前服務器（或者服務）的證書狀態——而服務器則必須面向客戶端證書執行同樣的操作。如此一來，OCSP響應方同樣面臨著巨大的流量壓力。基于同樣的考慮，客戶端仍然可以對OCSP決策進行緩存，但這無疑繼續帶來同樣的、基于陳舊數據進行決策的可能性。

而OCSP stapling的出現令客戶端不再需要每次同下游微服務進行通信時，都與OCSP響應方“打招呼”。該下游微服務將從對應的OCSP響應方處獲取OCSP響應，以及staple，或者將響應附加到證書本身當中。由于OCSP響應得到了對應證書中心的簽名，因此該客戶端能夠驗證通過其簽名并接收此響應。這種方法令事情有了轉機，事實上如今是由服務而非客戶端與OCSP響應方進行通信。不過在TLS相互驗證模式下，OCSP stapling相較于原始OCSP無法帶來任何額外優勢。

由于OCPS必須配合stapling，該服務（即下游服務）需要向客戶端（即上游服務）提供保證，證明OCSP響應被附加到了該服務在TLS握手時接收到的證書中。如果OCSP響應未被附加至該證書中，那么結果并非出現軟錯誤，而是客戶端必須立即拒絕該連接。

從最終用戶的角度來看，臨時證書的效果與目前的常規證書并無區別，只不過暫時證書的過期時間非常之短。TLS客戶端并不需要針對臨時證書進行CRL或者OCSP驗證，而是堅持設定好的過期時間，并對證書本身進行時間戳加蓋。

臨時證書帶來的最大挑戰在于其部署與維護工作。自動則正是解決這些難題的靈丹妙藥。Netflix公司建議使用分層方案以構建臨時證書部署機制。大家可以在TPM（即受信平臺模塊）或者SGX（軟件保護擴展）當中獲得系統身份或者長期證書，從而顯著提升安全性。在此之后，再使用這些憑證作為臨時證書。最后，在微服務中使用臨時證書——這些證書亦可由其它微服務使用。每項微服務都能夠利用自身長期證書對臨時證書進行定期刷新。當然，僅僅擁有臨時證書還不夠——托管該服務（或者TLS終止器）的主機應當支持對服務器證書的動態更新。目前存在大量能夠運行服務器證書動態重載的TLS終止器，但其中大多數可能會導致短暫的服務停機。

微服務集與外部世界的連通一般經由API網關模式實現。利用API網關模式，需要進行聲明的微服務能夠在該網關內獲得對應的API。當然，并不是所有微服務都需要立足于API網關實現聲明。

最終用戶對微服務的訪問（通過API實現）應當在邊界或者API網關處進行驗證。目前最為常見的API安全保護模式為OAuth 2.0。

OAuth 2.0是一套作為訪問代表的框架。它允許某方對另一方進行某種操作。OAuth 2.0引入了一系列grant types。其中之一用于解釋協議，客戶端可利用此協議獲取資源擁有方的許可，從而代表擁有方進行資源訪問。另外，還有部分grant types可解釋用于獲取令牌的協議，且整個操作完全等同于由資源擁有方執行——換言之，該客戶在這種情況下即相當于資源擁有方。以下示意圖解釋了OAuth 2.0協議的宏觀實現流程。其中描述了OAuth客戶端、資源擁有方、驗證服務器以及資源服務器之間的交互方式。

要想通過API網關訪問某項微服務，請求發起方必須首先獲得有效的OAuth令牌。系統能夠以自身角色訪問微服務，也可以作為其他用戶實現訪問。對于后一種情況，假設用戶登錄至某Web應用，那么此后該Web應用即可以所登錄用戶的身份進行微服務訪問。

下面來看端到端通信的具體實現方式，如上圖所顯示：

用戶通過Identity Provider登錄至Web應用/移動應用，而Web應用/移動應用則通過OpenID Connect（也可以是SAML 2.0）信任該Provider。

該Web應用獲取一條OAuth 2.0 access_token與一條id_token。其中id_token將驗證訪問該Web應用的最終用戶。如果使用SAML 2.0，則該Web應用需要與其信任的OAuth驗證服務器的token端點進行通信，同時將SAML令牌交換為一條OAuth acess_token，隨后交換OAuth 2.0的SAML 2.0 grant type。

該Web應用會作為最終用戶調用一個API——并隨同API請求發送access_token。

API網關會攔截來自該Web應用的請求，提取access_token，與令牌交換端點（或者STS）進行通信，并由后者驗證該acess_token，而后向該API網關提供JWT（由其簽名）。此JWT還攜帶有用戶上下文。在STS對acess_token進行驗證時，其還將通過introspection API與對應的OAuth授權服務器進行通信。

API網關向下游微服務將同時發出請求與JWT。

每項微服務都會驗證其接收到的JWT，而后作為下游服務調用，其能夠創建新的自簽名JWT并將其與該請求一同發送。在其它方案中，亦會用到嵌套JWT——即由新的JWT攜帶上一JWT。

在上述流程當中，來自外部客戶端的API請求將經由該API網關。當某項微服務與其它微服務通信時，其將不再需要經過該網關。另外，從特定微服務的角度來看，無論大家是從外部客戶端還是其它微服務處獲取請求，獲得的都是JWT——也就是說，這是一種對稱安全模式。

授權屬于一項業務功能。每項微服務可以決定使用何種標準以允許各項訪問操作。從簡單的授權角度來講，我們可以檢查特定用戶是否向特定資源執行了特定操作。將操作與資源加以結合，也就構成了權限。授權檢查會評估特定用戶是否具備訪問特定資源的最低必要權限集合。該資源能夠定義誰可以進行訪問，可在訪問中具體執行哪些操作。為特定資源聲明必要權限可通過多種方式實現。

XACML已經成為細粒度訪問控制領域的客觀標準。其引入的方式能夠代表訪問某種資源所需要的權限集，且具體方法采用基于XML的特定域語言（簡稱DSL）編寫而成。

上圖所示為XACML組件架構。首先，策略管理員需要通過PAP（即策略管理點）定義XACML策略，而這些策略將被保存在策略存儲內。要檢查特定實體是否擁有訪問某種資源的權限，PEP（即策略執行點）需要攔截該訪問請求、創建一條XACML請求并將其發送至XACML PDP（即策略決策點）。該XACML請求能夠攜帶任何有助于在PDP上執行決策流程的屬性。舉例來說，其能夠包含拒絕標識符、資源標識符以及特定對象將對目標資源執行的操作。需要進行用戶授權的微服務則需要與該PDP通信并從JWT中提取相關屬性，從而建立XACML請求。PIP（即策略信息點）會在PDP發現XACML請求中不存在策略評估所要求的特定屬性時介入。在此之后，PDP會與PIP通信以找到缺失的對應屬性。PIP能夠接入相關數據存儲，找到該屬性而后將其返回至PDP。

遠程PDP模式存在幾大弊端，其可能與微服務的基本原則發生沖突：

性能成本：每一次被要求執行訪問控制檢查時，對應微服務都需要通過線纜與PDP進行通信。當該決策被緩存在客戶端時，此類傳輸成本與策略評估成本將得到有效降低。不過在使用緩存機制時，我們亦有可能根據陳舊數據進行安全決策。

策略信息點（簡稱PIP）的所有權：每項微服務都應當擁有自己的PIP，其了解要從哪里引入實現訪問控制所必需的數據。在以上方案中，我們建立起的一套“整體式”PDP，其中包含全部PIP——對應全部微服務。

如上圖所示，嵌入式PDP將遵循一類事件模式，其中每項微服務都會訂閱其感興趣的主題以從PAP處獲取合適的訪問控制策略，而后更新其內嵌PDP。大家可以通過微服務組或者全局多租戶模型獲取PAP。當出現新策略或者策略存在更新時，該PAP會向對應的主題發布事件。

這套方案不會違反微服務中的“服務器不變”原則。“服務器不變”意味著當大家在持續交付流程結尾處，直接利用加載自庫的配置構建服務器或者容器時，整個創建流程應該能夠基于同樣的配置進行不斷重復。因此，我們不希望任何用戶登入服務器并對配置做出變更。在內嵌PDP模式下，盡管服務器會加載對應的策略，但其仍同時處于運行當中。這意味著當我們啟動新容器時，其仍然立足于同樣的策略集。

在結束本篇文章之前，我們還有另一個重要的問題需要回答，即API網關在授權上下文中到底扮演著怎樣的角色。我們可以設置全局可訪問的訪問控制策略——其可用于最終用戶，并由網關進行強制執行——但無法設置服務層級的策略。因為顧名思義，服務層策略必須在服務層上執行。