實錄分享 | 微服務訪問安全設計方案全探索

今天給你們帶來的是 數人云工程師文權在高效運維線上羣的分享實錄。從傳統單體應用架構到微服務架構，安全問題一直是人們關注的重點，文權與你們分享了關於微服務訪問安全設計方案的探索與實踐。

咱們首先從傳統單體應用架構下的訪問安全設計提及，而後分析現代微服務架構下，訪問安全涉及的原則，接着討論目前經常使用的幾種微服務架構下的訪問安全設計方案。最後，詳析Spring Cloud微服務架構下如何解決訪問安全的問題。

1、傳統單體應用的訪問安全設計

上面的示意圖展現了單體應用的訪問邏輯。用戶經過客戶端發出http或者https請求，通過負載均衡後，單體應用收到請求。接着通過auth層，進行身份驗證和權限批准，這裏，通常會有跟後端數據庫的交互。經過後，將請求分發到對應的功能邏輯層中去。完成相關操做後，返回結果給客戶端。

傳統單體應用的訪問安全設計——原則

從以上分析能夠看到，傳統單體應用的訪問安全設計原則爲：

第一，每次的用戶請求都須要驗證是否安全，這裏能夠分兩種狀況：

一種是沒有session的請求，須要通過幾個步驟完成session化。通常爲驗證當前用戶的credential，獲取當前用戶的identity，這兩步都須要訪問數據庫等持久化對象來完成，最後一步是爲當前可用建立session，返回給客戶端後，啓用該session。

另外一種是有session的請求，只需驗證請求中當前session的有效性，便可繼續請求。

第二，用戶的操做請求都在後端單個進程中執行完成，徹底依賴後端調用方法的可靠性。一旦出錯，應用是沒法再次重複請求。

傳統單體應用的訪問安全設計——優點和注意點

小結，傳統單體應用因爲設計相對簡單單一，暴露給外界的入口相對較少，從而具備被攻擊並形成危害性的可能小的優點。

也正是因爲單體應用簡單單一的特色，須要注意相關問題：

• 應用後端保存了全部的credential等敏感信息

• 一旦入侵了對這個應用的請求，就有可能拿到全部的保存在後端的信息

• 應用的每次操做通常都須要和數據庫進行交互，形成數據庫負載變高

2、微服務架構下，訪問安全設計原則

先來看下這張典型的微服務設計架構圖，如圖所示，有如下幾點特徵：

• 每一個服務只有權限去操做本身負責的那部分功能。

• 用戶請求的身份驗證和權限批准都由獨立的gateway服務來保障

• 對外服務的LB層沒法直接與提供業務服務的應用層進行訪問
  

從上面的特徵分析來看，想要給出一份訪問安全設計的原則說明，就要看看微服務架構下，訪問安全有哪些痛點，如下羅列了幾點：

• 單點登陸，即在微服務這種多獨立服務的架構下，實現用戶只須要登陸一次就能訪問全部相互信任的應用系統

• 微服務架構下的應用通常都是無狀態的，致使用戶的請求每次都須要鑑權，可能引起Auth服務的性能瓶頸

• 微服務架構下，每一個組件都管理着各自的功能權限，這種細粒度的鑑權機制須要事先良好的規劃

• 微服務架構下，須要考慮到那些非瀏覽器端的客戶請求，是否具備良好的可操做性

根據實際狀況，還有一些其餘痛點，這裏再也不一一贅述，而這些痛點，就造成了咱們在爲微服務架構設計訪問安全的原則。

3、微服務架構下，經常使用的訪問安全設計方案

• HTTP Basic Authentication + Independent Auth DB

• HTTP Basic Authentication + Central Auth DB

• API Tokens

• SAML

這裏列出4種，首先簡單介紹下，而後一一敘述。

第一種，使用HTTP Basic Auth協議，加上獨立的Auth數據庫。
第二種，也是使用HTTP Basic Auth協議，跟第一種不一樣的是，使用集中式的Auth數據庫
第三種，API Tokens協議，這種你們應該比較熟悉，不少公有服務（好比Github、Twitter等）的API都是用這種方式。
第四種，SAML，即Security Assertion Markup Language，翻譯過來，是『安全聲明標記語言』，它是基於XML的一種協議，企業內使用得較多。

下面一一作介紹。

微服務經常使用訪問安全設計方案——Basic Auth + Independent Auth DB

第一種，如上示意圖所示，使用Basic Auth協議，配合每一個服務本身都擁有存儲Credential敏感數據的數據庫（或者其餘持久化倉庫）。

簡單介紹下Basic Auth協議，它是在用戶的請求中添加一個Authorization消息頭，這個消息頭的值是一個固定格式：
Basic base64encode(username+「:」+password)

完整的消息頭列子爲：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Basic Auth協議基本上被全部流行的網頁瀏覽器都支持。

這種方案的特色：

• 每一個提供功能的服務都擁有本身獨立的鑑權和受權機制

• 每一個提供功能的服務都擁有本身獨立的數據庫，來保存敏感信息

• 每次用戶請求都須要攜帶用戶的credential來完成操做

小結下使用這種方案的好處：

• 微服務的應用能夠實現100%無狀態化

• 基於Basic Auth開發簡單

同時，小結下使用這種方案須要注意的地方：

因爲每一個服務都有本身存儲credential的機制，須要事先爲每一個服務設計好如何存儲和查找用戶的Credential
因爲每次用戶請求都會攜帶用戶的Credential，須要事先設計好如何管理鑑權機制

微服務經常使用訪問安全設計方案——Basic Auth + Central Auth DB

第二種，如上示意圖所示，使用Basic Auth協議，與第一種方案相比，每一個服務共用有同一個Auth DB。

第二種方案的特色和第一種很類似：

• 每一個提供功能的服務都擁有本身獨立的鑑權和受權機制

• 每一個提供功能的服務共用同一個DB，來保存Credential等敏感信息

• 每次用戶請求都須要攜帶用戶的credential來完成操做

小結下使用第二種方案的好處：

除了擁有第一種方案類似的好處外，因爲共用了同一個持久化倉庫來管理用戶信息，簡化了原來獨立管理的機制

同時，小結下使用這種方案須要注意的地方：

• 中心化Auth DB會被每次用戶請求來訪問鏈接，可能引起AuthDB性能瓶頸

• 須要在每一個服務中實現對共有Auth DB查找用戶信息的邏輯

微服務經常使用訪問安全設計方案——API Tokens

第三種，如上示意圖所示，使用Token Based協議來對用戶請求進行操做鑑權。

簡單介紹下最基本的Token Based的交互方式：

• 用戶使用包含用戶名和密碼的credential從客戶端發起資源請求

• 後端接受請求，經過受權中心，生產有效token字符串，返回給客戶端

• 客戶端得到token後，再次發出資源請求

• 後端接受帶token的請求，經過受權中心，獲取相關資源，返回給客戶端

業界經常使用的OAuth就是基於Token Based這套邏輯，實現的互聯網級的鑑權機制。

第三種方案的特色明顯：

使用token來進行鑑權，替換用戶自己的用戶名和密碼，提升了交互安全性
每次用戶請求須要攜帶有效token，與Auth服務進行交互驗證

小結下使用第三種方案的好處：

因爲使用了token來鑑權，業務服務不會看到用戶的敏感信息

同時，小結下使用這種方案須要注意的地方：

Auth服務可能須要處理大量的生產token的操做

微服務經常使用訪問安全設計方案——SAML

第四種，如上示意圖所示，使用SAML協議來對用戶請求進行操做鑑權。它是一個基於XML的標準，用於在不一樣的安全域(security domain)之間交換認證和受權數據。在SAML標準定義了身份提供者(identity provider)和服務提供者(service provider)，這二者構成了前面所說的不一樣的安全域。

以上圖Google提供的Apps SSO的機制，簡單介紹下SAML鑑權的交互方式：

• 用戶請求訪問自建的google application

• 當前application 生成一個 SAML 身份驗證請求。SAML 請求將進行編碼並嵌入到SSO 服務的網址中。

• 當前application將重定向發送到用戶的瀏覽器。重定向網址包含應向SSO 服務提交的編碼 SAML 身份驗證請求。

• SSO（統一認證中心或叫Identity Provider）解碼 SAML 請求，並提取當前application的 ACS（聲明客戶服務）網址以及用戶的目標網址（RelayState 參數）。而後，統一認證中心對用戶進行身份驗證。

• 統一認證中心生成一個 SAML 響應，其中包含通過驗證的用戶的用戶名。按照 SAML 2.0 規範，此響應將使用統一認證中心的 DSA/RSA 公鑰和私鑰進行數字簽名。

• 統一認證中心對 SAML 響應和 RelayState 參數進行編碼，並將該信息返回到用戶的瀏覽器。統一認證中心提供了一種機制，以便瀏覽器能夠將該信息轉發到當前application ACS。

• 當前application使用統一認證中心的公鑰驗證 SAML 響應。若是成功驗證該響應，ACS 則會將用戶重定向到目標網址。

• 用戶將重定向到目標網址並登陸到當前application。

目前SAML在業界也有至關的使用度，包括IBM Weblogic等產品。

第四種方案的特色有：

由Identity Provider提供可信的簽名聲明
服務的訪問安全由可信的Identity Provider提供

小結下使用第四種方案的好處：標準的可信訪問模型

同時，小結下使用這種方案須要注意的地方：

基於XML協議，傳輸相對複雜
對非瀏覽器客戶端適配不方便

4、Spring Cloud Security解決方案

Spring Cloud Security特色有：

• 基於OAuth2 和OpenID協議的可配置的SSO登陸機制

• 基於tokens保障資源訪問安全

• 引入UAA鑑權服務，UAA是一個Web服務，用於管理帳戶、Oauth2客戶端和用戶用於鑑權的問題令牌(Issue Token)。UAA實現了Oauth2受權框架和基於JWT(JSON web tokens)的問題令牌。
  

下面簡單介紹下UAA，事實上，它是由CloudFoundry發起的，也是CloudFoundry平臺的身份管理服務（https://docs.cloudfoundry.org...）。

主要功能是基於OAuth2，當用戶訪問客戶端應用時，生成併發放token給目標客戶端。

UAA認證服務包含以下幾個方面的內容：

• 認證對象。如用戶、客戶端以及目標資源服務器

• 認證類型。主要有受權碼模式、密碼模式以及客戶端模式

• 認證範圍，即認證權限，並做爲一個命名的參數附加到AccessToken上。

接下來，結合實例，一塊兒來看下UAA在Spring Cloud中的實踐。

如圖所示，這是一個簡單的基於Spring Cloud微服務架構的例子，它的主要組件有：

• Eureka組件提供服務發現功能

• 獨立的Config組件提供相似配置中心的服務，持久化層能夠是文件系統，也但是git repository

• Auth組件提供基於UAA的鑑權服務

• Account組件保存用戶的業務信息
  其餘組件不一一介紹了

這裏主要講Auth組件和Account組件是如何基於UAA服務進行認證和受權。

圖一爲Auth組件業務代碼中定義了不一樣客戶端的認證類型和認證範圍，其中：

瀏覽器端的認證類型是password，認證範圍是ui
account組件端的認證類型是client_credentials，認證範圍是server

圖二爲config組件（配置中心）定義的請求路由的規則，其中：

使用/uaa/**來轉發基於uaa的認證請求至auth組件
使用/accouts/**來轉發請求至account組件，並標記serviceId爲account-service，與圖一中的withClient對應。

圖一爲瀏覽器打開應用入口後，輸入用戶名和密碼後，發出的認證請求：

認證url爲/uaa/oauth/token，這是uaa模式下標準的請求獲取token的url
表單中包含了字段scope（認證範圍）和字段password（認證類型）

圖二爲圖一發出認證請求的返回結果：

Access_token爲有效認證token，未來被其餘請求使用

圖三爲發出獲取當前用戶的信息的請求：

在請求裏的Authorization的值爲圖二中得到的access_token

圖一爲Account組件在Config組件（配置中心）定義的OAuth2協議下獲取token的方式，這裏定義了：

clientID和clientSecret
accessTokenUrl，這裏指定了auth組件的uaa獲取token的url
grant-type，即認證類型，這裏指定爲client_credentials
scope，這裏指定了server，說明是這個認證請求只適用在各微服務之間的訪問。

圖二爲Accout組件業務代碼中定義了須要使用Auth組件進行事先鑑權的方法：

使用@PreAuthorize
annotation中能夠指定認證範圍的具體條件，這裏是限定了server或者是demo帳戶，纔有權限發起認證。

最後小結下Spring Cloud Security的特色：

• 基於UAA，使用OAuth2協議。不會暴露用戶的敏感信息

• 基於認證類型和認證範圍，實現細粒度的鑑權機制

• 非瀏覽器客戶端下良好的操做性

Q&A

問題：Basic Auth + Central Auth DB這種方式中，每一個服務有本身的鑑權DB，這塊只是一個緩衝嗎？若是中途經過別的方式修改了中心DB的數據，而緩衝又沒過時，這個時候有什麼解決方案嗎？
答：不是緩衝，這裏的Central Auth DB是指各個微服務共用一個數據庫。

問題：微服務架構須要服務路由和服務註冊麼？跟esb的區別在哪裏？
答：服務路由組件和服務註冊組件和是相對必要的，他們保證了用戶請求能發到正確的微服務中去。ESB企業服務總線是相對比較重的組件，而不是像微服務組件同樣只負責單個業務。

問題:在微服務中，對於數據權限的粒度，是能夠集中在在gateway中進行仍是由每一個微服務本身獨立配置？
答：推薦由那個專門負載權限的微服務組件來配置。

問題：您好，辛苦了，請問如今有相似SAML協議，可是不基於XML，而是基於JSON或者其餘簡化格式的協議嗎？
答：目前據我所知沒有基於JSON的SAML協議。有個叫JWT（JSON web token）的協議，它是徹底基於JSON的，Spring Cloud架構中也使用了JWT。

問題：對於這個架構，服務劃分的粒度有沒有什麼好的建議？另外登陸憑證保存在客戶端如何解決報文被攔截的安全漏洞？
答：服務劃分須要按具體業務來講，通常來講，一個業務實體做爲一個微服務。使用https能夠必定程度上提升安全性。

問題:spring cloud security能夠解決token重放攻擊麼？
答：token重放攻擊不是特別瞭解，多是數據弱一致性致使的，建議設計儘量短的過時時間。

問題：咱們公司如今在設計DMP，從行業的情況來看，採用了微服務，可是有一點，首先對於應用自己暴露出來的服務，是和應用一塊兒部署的，也就是並不是單獨的部署，那麼業務組件接口暴露部署是否合理呢？
答：業務組件的接口通常能夠經過統一網關來管理。也能夠對業務接口像spring cloud中設置訪問scope限制。

問題：全部暴露的微服務是否須要一個統一的服務管控和治理平臺？
答：是的，通常有服務網關和服務發現組件來管理用戶請求。

問題：微服務的gateway須要實現底層多個細粒度的API組合的場景，咱們如今一部分使用異步，可是遇到了沒辦法全面的解藕。我想問問，對於此，使用響應式？仍是異步回調式？它們的區別點會有哪些呢？
答：使用哪一種API方案，其實要看業務。若是後端業務須要強數據一致性，建議使用響應式的。反之，可使用異步回調或者消息隊列。

問題：uaa和netflix zull集成 可行嗎？是否作過這方面的嘗試？
答：能夠。Zuul組件提供網關服務，uaa是基於OAuth2協議，提供受權服務的。微服務架構下，他們是獨立的，是能夠自由組合的。舉個例子，能夠在zuul組件的配置文件中，爲受權服務（auth-service）組件的指定路由表。可參照：https://gist.github.com/never...