何文強(qiáng) 方良柯 黃晴晴

摘 ?要：近年來(lái)，微服務(wù)的應(yīng)用開(kāi)發(fā)架構(gòu)越來(lái)越受到軟件開(kāi)發(fā)人員的關(guān)注和青睞，很多公司都已經(jīng)開(kāi)始使用微服務(wù)架構(gòu)來(lái)進(jìn)行應(yīng)用程序的開(kāi)發(fā)。但是微服務(wù)架構(gòu)的應(yīng)用，也引入了很多對(duì)應(yīng)的安全問(wèn)題。本文主要從微服務(wù)架構(gòu)核心安全問(wèn)題，從用戶訪問(wèn)微服務(wù)的身份認(rèn)證和鑒權(quán)、微服務(wù)與微服務(wù)之間的通信時(shí)身份認(rèn)證與鑒權(quán)，微服務(wù)與第三方通信的邊界三個(gè)方面進(jìn)行分析，并對(duì)目前針對(duì)這些問(wèn)題常用的解決方案和技術(shù)進(jìn)行研究和探索。

微服務(wù)架構(gòu)的引入為軟件的開(kāi)發(fā)帶了諸多好處，比如開(kāi)發(fā)語(yǔ)言選擇的靈活性，縮短軟件的開(kāi)發(fā)周期，減少小團(tuán)隊(duì)軟件開(kāi)發(fā)成本，增強(qiáng)應(yīng)用服務(wù)的伸縮能力等等。微服務(wù)架構(gòu)在帶來(lái)各種開(kāi)發(fā)優(yōu)勢(shì)的同時(shí)，也帶了分布式系統(tǒng)的很多安全問(wèn)題，微服務(wù)架構(gòu)在帶來(lái)各種開(kāi)發(fā)優(yōu)勢(shì)的同時(shí)，也帶了分布式系統(tǒng)的很多安全問(wèn)題。對(duì)于微服務(wù)的安全性問(wèn)題來(lái)說(shuō)，其應(yīng)用層的訪問(wèn)權(quán)限和鑒權(quán)的安全性問(wèn)題是整個(gè)安全體系中占據(jù)著至關(guān)重要的地位。

1 微服務(wù)架構(gòu)下安全問(wèn)題簡(jiǎn)述

微服務(wù)架構(gòu)是一種將單個(gè)應(yīng)用程序作為一套小型服務(wù)開(kāi)發(fā)的方法，每種應(yīng)用服務(wù)程序都可以獨(dú)立在自己的進(jìn)程中運(yùn)行，并且相互之間可以使用輕量級(jí)機(jī)制來(lái)進(jìn)行通信。這些服務(wù)程序主要圍繞業(yè)務(wù)進(jìn)行構(gòu)建，每個(gè)應(yīng)用程序都可以部署到獨(dú)立的服務(wù)器上，因此其可以使用自動(dòng)部署機(jī)制進(jìn)行獨(dú)立部署，而且每個(gè)應(yīng)用服務(wù)都可以使用不同的編程語(yǔ)言進(jìn)行編寫(xiě)，也可以使用不同數(shù)據(jù)管理技術(shù)，

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

基于以上現(xiàn)象，微服務(wù)架構(gòu)的身份認(rèn)證和鑒權(quán)問(wèn)題是影響整個(gè)微服務(wù)架構(gòu)安全的核心問(wèn)題，其對(duì)微服務(wù)架構(gòu)的推廣和應(yīng)用起著關(guān)鍵性的作用。

2 微服務(wù)架構(gòu)的身份認(rèn)證與鑒權(quán)問(wèn)題

2.1用戶訪問(wèn)微服務(wù)的身份認(rèn)證和鑒權(quán)

用戶訪問(wèn)微服務(wù)時(shí)，主要是用戶身份信息傳遞的安全性問(wèn)題，其包含用戶身份信息的認(rèn)證信息和對(duì)應(yīng)身份和權(quán)限信息的管理問(wèn)題。對(duì)于用戶訪問(wèn)微服務(wù)的身份認(rèn)證與鑒權(quán)的方法，

第一種現(xiàn)有的方法就是使用單點(diǎn)登錄（SSO），但是在這種方案中，每個(gè)面向用戶的服務(wù)都必須與認(rèn)證服務(wù)交互，這會(huì)產(chǎn)生大量非?，嵥榈木W(wǎng)絡(luò)流量和重復(fù)的工作，當(dāng)動(dòng)輒數(shù)十個(gè)微應(yīng)用時(shí)，這種方案的弊端會(huì)更加明顯。

第二種是分布式的Session，這種方案的原理主要是將關(guān)于用戶認(rèn)證的信息存儲(chǔ)在共享存儲(chǔ)中，且通常由用戶會(huì)話作為 key 來(lái)實(shí)現(xiàn)的簡(jiǎn)單分布式哈希映射。當(dāng)用戶訪問(wèn)微服務(wù)時(shí)，用戶數(shù)據(jù)可以從共享存儲(chǔ)中獲取。在某些場(chǎng)景下，這種方案很不錯(cuò)，用戶登錄狀態(tài)是不透明的。同時(shí)也是一個(gè)高可用且可擴(kuò)展的解決方案。這種方案的缺點(diǎn)在于共享存儲(chǔ)需要一定保護(hù)機(jī)制，因此需要通過(guò)安全鏈接來(lái)訪問(wèn)，這時(shí)解決方案的實(shí)現(xiàn)就通常具有相當(dāng)高的復(fù)雜性了。第三種方法就是客戶端 Token 方案，這種方案里令牌在客戶端生成，由身份驗(yàn)證服務(wù)進(jìn)行簽名，并且必須包含足夠的信息，以便可以在所有微服務(wù)中建立用戶身份。令牌會(huì)附加到每個(gè)請(qǐng)求上，為微服務(wù)提供用戶身份驗(yàn)證，這種解決方案的安全性相對(duì)較好，但身份驗(yàn)證注銷是一個(gè)大問(wèn)題，緩解這種情況的方法可以使用短期令牌和頻繁檢查認(rèn)證服務(wù)等。對(duì)于客戶端令牌的編碼方案，Borsos 更喜歡使用JSON Web Tokens（JWT），它足夠簡(jiǎn)單且?guī)熘С殖潭纫脖容^好。目前還有一種解決方案是客戶端Token與API網(wǎng)關(guān)結(jié)合，這個(gè)方案里所有請(qǐng)求都通過(guò)網(wǎng)關(guān)，從而可以有效地隱藏了微服務(wù)。在請(qǐng)求時(shí)，網(wǎng)關(guān)將原始用戶令牌轉(zhuǎn)換為內(nèi)部會(huì)話ID令牌。這種方案的出現(xiàn)主要是為了解決第三種方案中撤銷服務(wù)難的問(wèn)題。

2.2微服務(wù)與微服務(wù)之間的通信時(shí)身份認(rèn)證與鑒權(quán)

微服務(wù)之間的產(chǎn)生通信的場(chǎng)景主要包括用戶間接觸發(fā)的微服務(wù)之間的相互訪問(wèn)和非用戶觸發(fā)的微服務(wù)之間的相互訪問(wèn)兩種，針對(duì)這兩種情況，根據(jù)應(yīng)用系統(tǒng)的數(shù)據(jù)敏感程度的不同，對(duì)于系統(tǒng)內(nèi)微服務(wù)的相互訪問(wèn)可能有不同的安全要求充分考慮，對(duì)于微服務(wù)之間通信時(shí)的身份認(rèn)證和鑒權(quán)問(wèn)題，目前常用的方式有采用Service Account（服務(wù)賬號(hào)）進(jìn)行安全控制，這種方法是使用用戶賬號(hào)（User Account）來(lái)標(biāo)識(shí)一個(gè)系統(tǒng)用戶，并對(duì)其進(jìn)行身份認(rèn)證和操作鑒權(quán)。類似地，可以為系統(tǒng)中每一個(gè)服務(wù)也創(chuàng)建一個(gè)賬號(hào)，稱為服務(wù)賬號(hào)（Service Accout）。該服務(wù)賬號(hào)表示了微服務(wù)的身份，以用于控制該微服務(wù)對(duì)系統(tǒng)中其它微服務(wù)的訪問(wèn)權(quán)限。當(dāng)一個(gè)微服務(wù)訪問(wèn)另一個(gè)微服務(wù)時(shí)，被訪問(wèn)的微服務(wù)需要驗(yàn)證訪問(wèn)者的服務(wù)賬號(hào)，以確定其身份和資源操作權(quán)限。另一種方法是采用服務(wù)之間相互進(jìn)行身份識(shí)別的SPIFEE標(biāo)準(zhǔn)。

2.3微服務(wù)與第三方通信的邊界安全問(wèn)題

除用戶訪問(wèn)和微服務(wù)之間的相互訪問(wèn)外，外部的第三方系統(tǒng)也可能需要訪問(wèn)系統(tǒng)內(nèi)部的微服務(wù)。對(duì)于微服務(wù)集與外部世界的通信，一般由API網(wǎng)關(guān)模式實(shí)現(xiàn)。利用API網(wǎng)關(guān)模式，需要進(jìn)行聲明的微服務(wù)能夠在該網(wǎng)關(guān)內(nèi)獲得對(duì)應(yīng)的API。當(dāng)然，并不是所有微服務(wù)都需要立足于API網(wǎng)關(guān)實(shí)現(xiàn)聲明。而且最終用戶對(duì)微服務(wù)的訪問(wèn)（通過(guò)API實(shí)現(xiàn)）應(yīng)當(dāng)在邊界或者API網(wǎng)關(guān)處進(jìn)行驗(yàn)證。對(duì)目前最為常見(jiàn)的API安全保護(hù)模式為OAuth2.0方式進(jìn)行研究和驗(yàn)證。

對(duì)于微服務(wù)與第三方應(yīng)用的身份認(rèn)證與鑒權(quán)問(wèn)題，目前也有了一些解決方案，第一種就是使用API Token，由微服務(wù)應(yīng)用提供一個(gè)API Token的生成界面，用戶登錄后可以生成自己的API Token，并在第三方應(yīng)用使用該API Token訪問(wèn)微服務(wù)的API。這樣就只允許第三方應(yīng)用訪問(wèn)該Token所屬用戶自身的數(shù)據(jù)，而不能訪問(wèn)其他用戶的敏感私有數(shù)據(jù)。但是某些第三方應(yīng)用需要訪問(wèn)不同用戶的數(shù)據(jù)，或者對(duì)多個(gè)用戶的數(shù)據(jù)進(jìn)行整合處理，就出現(xiàn)了使用 OAuth來(lái)進(jìn)行權(quán)限控制的操作。這種方式在當(dāng)?shù)谌綉?yīng)用訪問(wèn)服務(wù)時(shí)，應(yīng)用會(huì)提示用戶授權(quán)第三方應(yīng)用相應(yīng)的訪問(wèn)權(quán)限，根據(jù)用戶的授權(quán)操作結(jié)果生成用于訪問(wèn)的Token，以對(duì)第三方應(yīng)用的操作請(qǐng)求進(jìn)行訪問(wèn)控制。

3 總結(jié)

微服務(wù)架構(gòu)越來(lái)越受到開(kāi)發(fā)者的喜愛(ài)和關(guān)注，本文主要是對(duì)微服務(wù)架構(gòu)模式下身份認(rèn)證和鑒權(quán)技術(shù)進(jìn)行分析，提出微服務(wù)架構(gòu)所面臨的安全性問(wèn)題，并針對(duì)微服務(wù)架構(gòu)需要進(jìn)行身份認(rèn)證和鑒權(quán)的三種情況進(jìn)行分析，并對(duì)著三種情況下所采用的身份認(rèn)證和鑒權(quán)技術(shù)進(jìn)行分析和比較。