微服务访问安全设计方案全探索
文章來源：https://segmentfault.com/a/1190000006785852
今天給大家?guī)淼氖?數(shù)人云工程師文權(quán)在高效運維線上群的分享實錄。從傳統(tǒng)單體應(yīng)用架構(gòu)到微服務(wù)架構(gòu)，安全問題一直是人們關(guān)注的重點，文權(quán)與大家分享了關(guān)于微服務(wù)訪問安全設(shè)計方案的探索與實踐。
我們首先從傳統(tǒng)單體應(yīng)用架構(gòu)下的訪問安全設(shè)計說起，然后分析現(xiàn)代微服務(wù)架構(gòu)下，訪問安全涉及的原則，接著討論目前常用的幾種微服務(wù)架構(gòu)下的訪問安全設(shè)計方案。最后，詳析Spring Cloud微服務(wù)架構(gòu)下如何解決訪問安全的問題。
1.傳統(tǒng)單體應(yīng)用的訪問安全設(shè)計
上面的示意圖展示了單體應(yīng)用的訪問邏輯。用戶通過客戶端發(fā)出http或者https請求，經(jīng)過負載均衡后，單體應(yīng)用收到請求。接著經(jīng)過auth層，進行身份驗證和權(quán)限批準，這里，一般會有跟后端數(shù)據(jù)庫的交互。通過后，將請求分發(fā)到對應(yīng)的功能邏輯層中去。完成相關(guān)操作后，返回結(jié)果給客戶端。
1.1傳統(tǒng)單體應(yīng)用的訪問安全設(shè)計——原則
從以上分析可以看到，傳統(tǒng)單體應(yīng)用的訪問安全設(shè)計原則為：
第一，每次的用戶請求都需要驗證是否安全，這里可以分兩種情況：
一種是沒有session的請求，需要經(jīng)過幾個步驟完成session化。一般為驗證當前用戶的credential，獲取當前用戶的identity，這兩步都需要訪問數(shù)據(jù)庫等持久化對象來完成，最后一步是為當前可用創(chuàng)建session，返回給客戶端后，啟用該session。
另一種是有session的請求，只需驗證請求中當前session的有效性，即可繼續(xù)請求。
第二，用戶的操作請求都在后端單個進程中執(zhí)行完成，完全依賴后端調(diào)用方法的可靠性。一旦出錯，應(yīng)用是無法再次重復(fù)請求。
1.2 傳統(tǒng)單體應(yīng)用的訪問安全設(shè)計——優(yōu)勢和注意點
傳統(tǒng)單體應(yīng)用由于設(shè)計相對簡單單一，暴露給外界的入口相對較少，從而具有被攻擊并造成危害性的可能小的優(yōu)勢。
也正是由于單體應(yīng)用簡單單一的特點，需要注意相關(guān)問題：
應(yīng)用后端保存了所有的credential等敏感信息
一旦入侵了對這個應(yīng)用的請求，就有可能拿到所有的保存在后端的信息
應(yīng)用的每次操作一般都需要和數(shù)據(jù)庫進行交互，造成數(shù)據(jù)庫負載變高
2.微服務(wù)架構(gòu)下，訪問安全設(shè)計原則
來看下這張典型的微服務(wù)設(shè)計架構(gòu)圖，如圖所示，有以下幾點特征：
- 每個服務(wù)只有權(quán)限去操作自己負責(zé)的那部分功能。
- 用戶請求的身份驗證和權(quán)限批準都由獨立的gateway服務(wù)來保障
- 對外服務(wù)的LB層無法直接與提供業(yè)務(wù)服務(wù)的應(yīng)用層進行訪問
從上面的特征分析來看，想要給出一份訪問安全設(shè)計的原則說明，就要看看微服務(wù)架構(gòu)下，訪問安全有哪些痛點，以下羅列了幾點：
- 單點登錄，即在微服務(wù)這種多獨立服務(wù)的架構(gòu)下，實現(xiàn)用戶只需要登錄一次就能訪問所有相互信任的應(yīng)用系統(tǒng)
- 微服務(wù)架構(gòu)下的應(yīng)用一般都是無狀態(tài)的，導(dǎo)致用戶的請求每次都需要鑒權(quán)，可能引發(fā)Auth服務(wù)的性能瓶頸
- 微服務(wù)架構(gòu)下，每個組件都管理著各自的功能權(quán)限，這種細粒度的鑒權(quán)機制需要事先良好的規(guī)劃
- 微服務(wù)架構(gòu)下，需要考慮到那些非瀏覽器端的客戶請求，是否具有良好的可操作性
根據(jù)實際情況，還有一些其他痛點，這里不再一一贅述，而這些痛點，就形成了我們在為微服務(wù)架構(gòu)設(shè)計訪問安全的原則。
3.微服務(wù)架構(gòu)下，常用的訪問安全設(shè)計方案
- HTTP Basic Authentication + Independent Auth DB
- HTTP Basic Authentication + Central Auth DB
- API Tokens
- SAML
這里列出4種，首先簡單介紹下，然后一一敘述。
第一種，使用HTTP Basic Auth協(xié)議，加上獨立的Auth數(shù)據(jù)庫。
第二種，也是使用HTTP Basic Auth協(xié)議，跟第一種不同的是，使用集中式的Auth數(shù)據(jù)庫
第三種，API Tokens協(xié)議，這種大家應(yīng)該比較熟悉，很多公有服務(wù)（比如Github、Twitter等）的API都是用這種方式。
第四種，SAML，即Security Assertion Markup Language，翻譯過來，是『安全聲明標記語言』，它是基于XML的一種協(xié)議，企業(yè)內(nèi)使用得較多。
下面一一做介紹。
3.1 微服務(wù)常用訪問安全設(shè)計方案——Basic Auth + Independent Auth DB
一種，如上示意圖所示，使用Basic Auth協(xié)議，配合每個服務(wù)自己都擁有存儲Credential敏感數(shù)據(jù)的數(shù)據(jù)庫（或者其他持久化倉庫）。
簡單介紹下Basic Auth協(xié)議，它是在用戶的請求中添加一個Authorization消息頭，這個消息頭的值是一個固定格式：Basic base64encode(username+“:”+password)
完整的消息頭列子為：Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic Auth協(xié)議基本上被所有流行的網(wǎng)頁瀏覽器都支持。
這種方案的特點：
- 每個提供功能的服務(wù)都擁有自己獨立的鑒權(quán)和授權(quán)機制
- 每個提供功能的服務(wù)都擁有自己獨立的數(shù)據(jù)庫，來保存敏感信息
- 每次用戶請求都需要攜帶用戶的credential來完成操作
小結(jié)下使用這種方案的好處：
- 微服務(wù)的應(yīng)用可以實現(xiàn)100%無狀態(tài)化
- 基于Basic Auth開發(fā)簡單
同時，小結(jié)下使用這種方案需要注意的地方：
由于每個服務(wù)都有自己存儲credential的機制，需要事先為每個服務(wù)設(shè)計好如何存儲和查找用戶的Credential由于每次用戶請求都會攜帶用戶的Credential，需要事先設(shè)計好如何管理鑒權(quán)機制。
3.2微服務(wù)常用訪問安全設(shè)計方案——Basic Auth + Central Auth DB
二種，如上示意圖所示，使用Basic Auth協(xié)議，與第一種方案相比，每個服務(wù)共用有同一個Auth DB。
第二種方案的特點和第一種很相似：
- 每個提供功能的服務(wù)都擁有自己獨立的鑒權(quán)和授權(quán)機制
- 每個提供功能的服務(wù)共用同一個DB，來保存Credential等敏感信息
- 每次用戶請求都需要攜帶用戶的credential來完成操作
小結(jié)下使用第二種方案的好處：
除了擁有第一種方案相似的好處外，由于共用了同一個持久化倉庫來管理用戶信息，簡化了原來獨立管理的機制
同時，小結(jié)下使用這種方案需要注意的地方：
- 中心化Auth DB會被每次用戶請求來訪問連接，可能引發(fā)AuthDB性能瓶頸
- 需要在每個服務(wù)中實現(xiàn)對共有Auth DB查找用戶信息的邏輯
3.3微服務(wù)常用訪問安全設(shè)計方案——API Tokens
第三種，如上示意圖所示，使用Token Based協(xié)議來對用戶請求進行操作鑒權(quán)。
簡單介紹下最基本的Token Based的交互方式：
- 用戶使用包含用戶名和密碼的credential從客戶端發(fā)起資源請求
- 后端接受請求，通過授權(quán)中心，生產(chǎn)有效token字符串，返回給客戶端
- 客戶端獲得token后，再次發(fā)出資源請求
- 后端接受帶token的請求，通過授權(quán)中心，獲取相關(guān)資源，返回給客戶端
業(yè)界常用的OAuth就是基于Token Based這套邏輯，實現(xiàn)的互聯(lián)網(wǎng)級的鑒權(quán)機制。
第三種方案的特點明顯：
使用token來進行鑒權(quán)，替換用戶本身的用戶名和密碼，提高了交互安全性每次用戶請求需要攜帶有效token，與Auth服務(wù)進行交互驗證
小結(jié)下使用第三種方案的好處：
由于使用了token來鑒權(quán)，業(yè)務(wù)服務(wù)不會看到用戶的敏感信息
同時，小結(jié)下使用這種方案需要注意的地方：
Auth服務(wù)可能需要處理大量的生產(chǎn)token的操作
3.4微服務(wù)常用訪問安全設(shè)計方案——SAML
第四種，如上示意圖所示，使用SAML協(xié)議來對用戶請求進行操作鑒權(quán)。它是一個基于XML的標準，用于在不同的安全域(security domain)之間交換認證和授權(quán)數(shù)據(jù)。在SAML標準定義了身份提供者(identity provider)和服務(wù)提供者(service provider)，這兩者構(gòu)成了前面所說的不同的安全域。
以上圖Google提供的Apps SSO的機制，簡單介紹下SAML鑒權(quán)的交互方式：
- 用戶請求訪問自建的google application
- 當前application 生成一個 SAML 身份驗證請求。SAML 請求將進行編碼并嵌入到SSO 服務(wù)的網(wǎng)址中。
- 當前application將重定向發(fā)送到用戶的瀏覽器。重定向網(wǎng)址包含應(yīng)向SSO 服務(wù)提交的編碼 SAML 身份驗證請求。
- SSO（統(tǒng)一認證中心或叫Identity Provider）解碼 SAML 請求，并提取當前application的 ACS（聲明客戶服務(wù)）網(wǎng)址以及用戶的目標網(wǎng)址（RelayState 參數(shù)）。然后，統(tǒng)一認證中心對用戶進行身份驗證。
- 統(tǒng)一認證中心生成一個 SAML 響應(yīng)，其中包含經(jīng)過驗證的用戶的用戶名。按照 SAML 2.0 規(guī)范，此響應(yīng)將使用統(tǒng)一認證中心的 DSA/RSA 公鑰和私鑰進行數(shù)字簽名。
- 統(tǒng)一認證中心對 SAML 響應(yīng)和 RelayState 參數(shù)進行編碼，并將該信息返回到用戶的瀏覽器。統(tǒng)一認證中心提供了一種機制，以便瀏覽器可以將該信息轉(zhuǎn)發(fā)到當前application ACS。
- 當前application使用統(tǒng)一認證中心的公鑰驗證 SAML 響應(yīng)。如果成功驗證該響應(yīng)，ACS 則會將用戶重定向到目標網(wǎng)址。
- 用戶將重定向到目標網(wǎng)址并登錄到當前application。
目前SAML在業(yè)界也有相當?shù)氖褂枚?#xff0c;包括IBM Weblogic等產(chǎn)品。
第四種方案的特點有：
由Identity Provider提供可信的簽名聲明服務(wù)的訪問安全由可信的Identity Provider提供
小結(jié)下使用第四種方案的好處：標準的可信訪問模型
同時，小結(jié)下使用這種方案需要注意的地方：
基于XML協(xié)議，傳輸相對復(fù)雜對非瀏覽器客戶端適配不方便。
4.Spring Cloud Security解決方案
Spring Cloud Security特點有：
- 基于OAuth2 和OpenID協(xié)議的可配置的SSO登錄機制
- 基于tokens保障資源訪問安全
- 引入UAA鑒權(quán)服務(wù)，UAA是一個Web服務(wù)，用于管理賬戶、Oauth2客戶端和用戶用于鑒權(quán)的問題令牌(Issue Token)。UAA實現(xiàn)了Oauth2授權(quán)框架和基于JWT(JSON web tokens)的問題令牌。
下面簡單介紹下UAA，事實上，它是由CloudFoundry發(fā)起的，也是CloudFoundry平臺的身份管理服務(wù)（https://docs.cloudfoundry.org…）。
主要功能是基于OAuth2，當用戶訪問客戶端應(yīng)用時，生成并發(fā)放token給目標客戶端。
UAA認證服務(wù)包含如下幾個方面的內(nèi)容：
- 認證對象。如用戶、客戶端以及目標資源服務(wù)器
- 認證類型。主要有授權(quán)碼模式、密碼模式以及客戶端模式
- 認證范圍，即認證權(quán)限，并作為一個命名的參數(shù)附加到AccessToken上。
接下來，結(jié)合實例，一起來看下UAA在Spring Cloud中的實踐。
如圖所示，這是一個簡單的基于Spring Cloud微服務(wù)架構(gòu)的例子，它的主要組件有：
- Eureka組件提供服務(wù)發(fā)現(xiàn)功能
- 獨立的Config組件提供類似配置中心的服務(wù)，持久化層可以是文件系統(tǒng)，也可是git repository
- Auth組件提供基于UAA的鑒權(quán)服務(wù)
- Account組件保存用戶的業(yè)務(wù)信息 其他組件不一一介紹了
這里主要講Auth組件和Account組件是如何基于UAA服務(wù)進行認證和授權(quán)。
一為Auth組件業(yè)務(wù)代碼中定義了不同客戶端的認證類型和認證范圍，其中：
瀏覽器端的認證類型是password，認證范圍是uiaccount組件端的認證類型是client_credentials，認證范圍是server
圖二為config組件（配置中心）定義的請求路由的規(guī)則，其中：
使用/uaa/**來轉(zhuǎn)發(fā)基于uaa的認證請求至auth組件
使用/accouts/**來轉(zhuǎn)發(fā)請求至account組件，并標記serviceId為account-service，與圖一中的withClient對應(yīng)。
一為瀏覽器打開應(yīng)用入口后，輸入用戶名和密碼后，發(fā)出的認證請求：
認證url為/uaa/oauth/token，這是uaa模式下標準的請求獲取token的url表單中包含了字段scope（認證范圍）和字段password（認證類型）
圖二為圖一發(fā)出認證請求的返回結(jié)果：
Access_token為有效認證token，將來被其他請求使用
圖三為發(fā)出獲取當前用戶的信息的請求：
在請求里的Authorization的值為圖二中獲得的access_token
圖一為Account組件在Config組件（配置中心）定義的OAuth2協(xié)議下獲取token的方式，這里定義了：
clientID和clientSecret
accessTokenUrl，這里指定了auth組件的uaa獲取token的url
grant-type，即認證類型，這里指定為client_credentials
scope，這里指定了server，說明是這個認證請求只適用在各微服務(wù)之間的訪問。
圖二為Accout組件業(yè)務(wù)代碼中定義了需要使用Auth組件進行事先鑒權(quán)的方法：
使用@PreAuthorize
annotation中可以指定認證范圍的具體條件，這里是限定了server或者是demo賬戶，才有權(quán)限發(fā)起認證。
最后小結(jié)下Spring Cloud Security的特點：
- 基于UAA，使用OAuth2協(xié)議。不會暴露用戶的敏感信息
- 基于認證類型和認證范圍，實現(xiàn)細粒度的鑒權(quán)機制
- 非瀏覽器客戶端下良好的操作性
5.Q&A
問題：Basic Auth + Central Auth DB這種方式中，每個服務(wù)有自己的鑒權(quán)DB，這塊只是一個緩沖嗎？如果中途通過別的方式修改了中心DB的數(shù)據(jù)，而緩沖又沒過期，這個時候有什么解決方案嗎？答：不是緩沖，這里的Central Auth DB是指各個微服務(wù)共用一個數(shù)據(jù)庫。
問題：微服務(wù)架構(gòu)需要服務(wù)路由和服務(wù)注冊么？跟esb的區(qū)別在哪里？答：服務(wù)路由組件和服務(wù)注冊組件和是相對必要的，他們保證了用戶請求能發(fā)到正確的微服務(wù)中去。ESB企業(yè)服務(wù)總線是相對比較重的組件，而不是像微服務(wù)組件一樣只負責(zé)單個業(yè)務(wù)。
問題:在微服務(wù)中，對于數(shù)據(jù)權(quán)限的粒度，是可以集中在在gateway中進行還是由每個微服務(wù)自己獨立配置？答：推薦由那個專門負載權(quán)限的微服務(wù)組件來配置。
問題：您好，辛苦了，請問現(xiàn)在有類似SAML協(xié)議，但是不基于XML，而是基于JSON或者其他簡化格式的協(xié)議嗎？答：目前據(jù)我所知沒有基于JSON的SAML協(xié)議。有個叫JWT（JSON web token）的協(xié)議，它是完全基于JSON的，Spring Cloud架構(gòu)中也使用了JWT。
問題：對于這個架構(gòu)，服務(wù)劃分的粒度有沒有什么好的建議？另外登錄憑證保存在客戶端如何解決報文被攔截的安全漏洞？答：服務(wù)劃分需要按具體業(yè)務(wù)來說，一般來說，一個業(yè)務(wù)實體作為一個微服務(wù)。使用https可以一定程度上提高安全性。
問題:spring cloud security可以解決token重放攻擊么？答：token重放攻擊不是特別了解，可能是數(shù)據(jù)弱一致性導(dǎo)致的，建議設(shè)計盡可能短的過期時間。
問題：我們公司現(xiàn)在在設(shè)計DMP，從行業(yè)的狀況來看，采用了微服務(wù)，但是有一點，首先對于應(yīng)用本身暴露出來的服務(wù)，是和應(yīng)用一起部署的，也就是并非單獨的部署，那么業(yè)務(wù)組件接口暴露部署是否合理呢？答：業(yè)務(wù)組件的接口一般可以通過統(tǒng)一網(wǎng)關(guān)來管理。也可以對業(yè)務(wù)接口像spring cloud中設(shè)置訪問scope限制。
問題：所有暴露的微服務(wù)是否需要一個統(tǒng)一的服務(wù)管控和治理平臺？答：是的，一般有服務(wù)網(wǎng)關(guān)和服務(wù)發(fā)現(xiàn)組件來管理用戶請求。
問題：微服務(wù)的gateway需要實現(xiàn)底層多個細粒度的API組合的場景，我們現(xiàn)在一部分使用異步，但是遇到了沒辦法全面的解藕。我想問問，對于此，使用響應(yīng)式？還是異步回調(diào)式？它們的區(qū)別點會有哪些呢？答：使用哪種API方案，其實要看業(yè)務(wù)。如果后端業(yè)務(wù)需要強數(shù)據(jù)一致性，建議使用響應(yīng)式的。反之，可以使用異步回調(diào)或者消息隊列。
問題：uaa和netflix zull集成 可行嗎？是否做過這方面的嘗試？
答：可以。Zuul組件提供網(wǎng)關(guān)服務(wù)，uaa是基于OAuth2協(xié)議，提供授權(quán)服務(wù)的。微服務(wù)架構(gòu)下，他們是獨立的，是可以自由組合的。舉個例子，可以在zuul組件的配置文件中，為授權(quán)服務(wù)（auth-service）組件的指定路由表。
可以參考：https://gist.github.com/nevermosby/875b9f7b1799a6207832010d6eafcfc3
總結(jié)
以上是生活随笔為你收集整理的微服务访问安全设计方案全探索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Altium Designer学习---
- 下一篇： JavaScript总结01