【云安全聯(lián)盟】微服務(wù)架構(gòu)模式

微服務(wù)架構(gòu)模式t

應(yīng)用容器和微服務(wù)工作組的網(wǎng)址：

https://doudsecirtiyalliancaorg/research/working-groups/containerization/

序言

隨著數(shù)字化時代的到來，微服務(wù)應(yīng)用進入飛速發(fā)展時代。微服務(wù)是一種新興的分布式系統(tǒng)

開發(fā)范式，在架構(gòu)層面，安全性是必需認(rèn)真考慮的重要工作。我國隨著《數(shù)據(jù)安全法》和《個

人信息保護法》的頒布，對安全和數(shù)據(jù)保護的重視程度日益提高，架構(gòu)層的安全問題必將上升

到組織安全治理層面。

如何保證微服務(wù)架構(gòu)的安全？本文檔給出了CSA的最佳實踐與總結(jié)，通過CSA微服務(wù)安

全參考架構(gòu)以及安全控制措施疊加的新思路，保證了微服務(wù)在架構(gòu)層面的安全性，CSA微服務(wù)

安全工作組也在陸續(xù)推出微服務(wù)安全相關(guān)的指南與白皮書.文章深入淺出，值得大家參考。

李雨航Y(jié)aleLi

CSA大中華區(qū)主席兼研究院院長

3

致

謝

本文檔《微服務(wù)架構(gòu)模式》(MicroservicesArchitecturePattern)由CSA應(yīng)用容器和微服務(wù)工

作組專家編寫，CSA大中華區(qū)秘書處組織翻譯并審校。

中文版翻譯專家組(排名不分先后)：

組長：高卓

翻譯組：高卓賀進李巖廖武鋒馬琳琳

審校組：郭鵬程姚凱

感謝以下單位對本文檔的支持與貢獻：

北京江南天安科技有限公司浪潮云信息技術(shù)有限公司

北京北森云計算股份有限公司

英文版本

主編/工作組聯(lián)合主席：AnilKarine1AndrewWild

主要供稿者：GustavoNievesArreazaMarinaBregkouCraigEllrod

MichaelHoldenJohnJiangKevinKeane

NumrataKulkarniVaniMurthyPradeepNampiar

VinodBbuVanjarapuMarkYanaiitis

審稿者：AnkurGargiAlexReboMichaelRozaAnkitSharma

CSA分析師：HillaryBaronMarinaBregkou

CSA全球人員：ClaireLehnertAnnMarieUlskey

4

在此感謝以上專家。如譯文有不妥當(dāng)之處，敬請讀者聯(lián)系CSAGCR秘書處給與雅正！聯(lián)系

郵箱：research@c-csa.cn；云安全聯(lián)盟CSA公眾號。

5

目錄

序言3

致謝..............................................................................4

121=="7

1*JI.........................................................................??????................../

2目的9

************************************************************************************************************************************???????????????????????????????????????????1

4.1模式和控制措施疊力口..................................................................11

4.2微服務(wù)架構(gòu)模式簡介...................................................................13

5.微服務(wù)架構(gòu)模式..............................................................................15

5.1模式.................................................................................15

5.1.1卸載（Offload）模式.............................................................15

5.1.2路由（路由選擇）模式..........................................................17

5.1.3聚合模式......................................................................19

5.1.4緩存模式......................................................................22

5.1.5代理..........................................................................24

5.1.7AuthZ（授權(quán)；模式.............................................................29

5.1.8Facade模式....................................................................32

5.1.9StranglerFig模式.............................................................34

5.1.10斷路器（CircuitBreaker）模式..................................................37

5.1.11適配器（包裝器/轉(zhuǎn)化/轉(zhuǎn)換）模式...............................................40

6.安全控制措施疊力口............................................................................42

6.1疊加介紹..............................................................................44

6.1.2IAM”口50

*1?1I

6.1.6微服務(wù)的彈性和可用性疊加.......................................................61

於、件/結(jié)論67

附錄C：參考文獻...............................................................................76

1.0微服務(wù)架構(gòu)模式模板........................................................................80

1.2二式模板1.I...............................................................................80

2.1安全疊加作.業(yè)練習(xí)指導(dǎo).................................................................82

211介紹82

2.1.2V備知識.......................................................................83

6

1.引言

以較弱方式構(gòu)建微服務(wù)的影響始終存在「表現(xiàn)為不夠安全和把應(yīng)用編程接口（API）過度

暴露，構(gòu)成了微服務(wù)應(yīng)用程序風(fēng)險的核心部分。一些業(yè)務(wù)和技術(shù)負(fù)責(zé)人跳過搭建架構(gòu)的方法2,

僅憑幾條粗略的要求尋找軟件解決方案。然而在開放市場上尋求解決方案的人們最終還是要用

搭建架構(gòu)的方式把采購的解決方案融入到現(xiàn)有控制環(huán)境中。即便是新建的微服務(wù)應(yīng)用程序也耍

與企業(yè)舊有的其他部分集成一一沒有哪家公司會年年淘汰現(xiàn)有架構(gòu)。不采用架構(gòu)方法而單純購

買解決方案將不可避免地在日后引入各種制約和附加組件.修修補補的資金成本會隨著時間的

推移而不斷增加。

無論企業(yè)領(lǐng)導(dǎo)者傾向于購買現(xiàn)成解決方案還是支持“內(nèi)部構(gòu)建”，API消費和微服務(wù)集成

都會是一種常見的系統(tǒng)集成預(yù)期。最好能有一種辦法指導(dǎo)將架構(gòu)的使用、架構(gòu)模式和安全控制

措施疊加集成為一個整體，確保信息安全成為既定要求的集合。微服務(wù)架構(gòu)模式和相應(yīng)的安全

控制措施的疊加為微服務(wù)的開發(fā)奠定了基礎(chǔ)，形成一種完整的思路。模式和疊加可確保信息安

全根植于產(chǎn)品之內(nèi)。如果做得好，安全控制措施疊加會變得與用于創(chuàng)建微服務(wù)應(yīng)用程序的架構(gòu)

和設(shè)計方法難以區(qū)分。有人稱這種現(xiàn)象為“DevSecOps”（開發(fā)-安全-運維）/安全控制措施

疊加的概念起源于美國《聯(lián)邦信息系統(tǒng)管理法案（FISMA）》。"根據(jù)卜'ISMA的說法，“安全疊

加是運用裁剪指南對控制基線裁剪后得出的一個全套特定控制措施、控制措施強化和補充指南

集?！泵绹鴩覙?biāo)準(zhǔn)和技術(shù)研究所（NIST）特別出版物SP800-53《聯(lián)邦信息系統(tǒng)和機構(gòu)安全

和隱私控制措施》第4版第3.3節(jié)'對安全控制措施疊加作了進一步闡述。盡管疊加是NIST引

入的概念，但是ISACACOBIT5、PCI-DSS3.2.1或CSACCMv3.0.1等其他控制框架也可使用。

軟件開發(fā)的展開離不開以軟件設(shè)計模式為引導(dǎo)工安全控制措施疊加（overlay）是指由全

1Hinkley,C.(2019,November6).DissectingtheRisksandBenefitsofMicroserviceArchitecture

TechZone360.httDS://www.techzor>/topics/techzone/articles/2019/ll/06/44366Q-dissecting~risks-beneflls-niicroservice~archilecliirehim

2TheOpenGroup.TheTOGAFStandard,Version9.2Ovendew,PhaseA,RCPEEandG.RetrievedAugust11,2021,from

https:〃www.oDenH/togaf.

2CloudSecurityAlliance.(2019,August1).InformationSecurityManagementthroughReflexiveSecurity

https://d0udsecuritvalliance.0r2/artifacts/informatiorrsecuritymanagement~throughrcflcxiv(rsecurity/(l3t14,16).

4NIST.SecurityandPrivateControlOverlayOverview.RetrievedAugust11,2021,from

https:〃csrc.nist.ROv/proiects/riskmanagemcnt/sp800-53-controls/overlay~rcpositcry/ovcrlavovcrview.

5NIST.(2020,September).NISTSpecialPublication800-53,Revision5:SecurityandPrivacyControlsforInformationSystemsand

Organizations.https://nvlpubsrdstgov/nistpubs/SpecialPublications/NISTSP.800-53r4.pdf

6Bass,L,Clement^RC,&Kazman,R.(2012,September).SoftwareArchitectureinPracticeThird

Edition.https://resource&seiemuedu/libi'ary/asset-view.cfm?assetid=30264.

7

套特定控制措施、控制措施強化和補充指南組成的離散集，可集成到架構(gòu)設(shè)計流程中，充當(dāng)嵌

入和既定的管理、技術(shù)或物理要求。軟件設(shè)計模式與安全控制措施疊加結(jié)合到一起會告訴我們，

軟件開發(fā)工作要把安全作為一個設(shè)計元素“內(nèi)置”到軟件產(chǎn)品之中，而不能只把安全當(dāng)作最后

才涂抹到軟件產(chǎn)品上的一層外衣，而這一層外衣到了日后成為必須付出極高代價才能做出改變

的地方。本文后面的章節(jié)將為使軟件架構(gòu)形成一個完整思路打下基礎(chǔ)。架構(gòu)意義上的完整思路

是指表現(xiàn)得像一個完美數(shù)學(xué)方程式的架構(gòu)表達(dá)方式；把這個思路向前推進，可以得到它的預(yù)期

產(chǎn)品，向后推演，則可以看到它的非功能和功能要求。

開發(fā)人員一旦掌握軟件設(shè)計模式和安全控制措施疊加.就可以在架構(gòu)成熟度上更.上一層樓,

從特定的微服務(wù)視角揭示底層服務(wù)交付框架具體方面（如數(shù)據(jù)、集成和部署架構(gòu)）所需耍的控

制狀態(tài)。雖然這些還不是“微服務(wù)架構(gòu)”，但可以支持對于那些要求保證系統(tǒng)行為可重復(fù)性、

可靠性、準(zhǔn)確性和完整性的架構(gòu)和設(shè)計。

微服務(wù)架構(gòu)風(fēng)格體現(xiàn)在分布式應(yīng)用程序的處理足跡里，其中靜態(tài)配置、動態(tài)適應(yīng)和抽象化

設(shè)想組合在一起所形成的能力，產(chǎn)生人們所說的“應(yīng)用功能”。在微服務(wù)和容器化轉(zhuǎn)型出現(xiàn)之

前，許多配置和抽象化設(shè)想存在于單個整體式應(yīng)用程序邊界之內(nèi)。隨著整體代碼庫變得越來越

大，內(nèi)部應(yīng)用程序的狀態(tài)和相互依賴變得越來越難以分辨，從而帶來許多架構(gòu)、開發(fā)和運維上

的挑戰(zhàn)。然而，讓一名業(yè)務(wù)代表負(fù)責(zé)業(yè)務(wù)流程功能.同時讓另一名產(chǎn)品負(fù)責(zé)人履行應(yīng)用托管義

務(wù)并在一個組織結(jié)構(gòu)下管理聯(lián)合開發(fā)人員的情況依然十分常見。微服務(wù)架構(gòu)風(fēng)格改變了組織結(jié)

構(gòu)，就像改變軟件的構(gòu)建和組裝樣。架構(gòu)的每個部分，無論是在平臺、軟件定義、應(yīng)用編程

接口（API）層面，還是在軟件開發(fā)層面，都是在微服務(wù)應(yīng)用程序交付的整體功能中執(zhí)行具體

和特定功能。機構(gòu)把多個開發(fā)團隊組織到一起應(yīng)對技術(shù)變化，響應(yīng)計算、內(nèi)存、存儲和網(wǎng)絡(luò)虛

擬化成一種能力的趨勢。存儲、網(wǎng)絡(luò)和服務(wù)器計算機團隊的混合體由分散的團隊組合而成。

隨著微服務(wù)軟件開發(fā)深入人心，業(yè)界越來越重視DevSecOps（開發(fā)-安全-運維）、軟件組

7

裝和應(yīng)用程序安全。例如，一個業(yè)務(wù)負(fù)責(zé)人可能擁有涵蓋整個工作流程的應(yīng)用程序，但是只負(fù)

責(zé)處理涉及改進現(xiàn)有能力或建立新能力的前瞻性請求。業(yè)務(wù)負(fù)責(zé)人關(guān)心的是已交付或可交付成

品的價值最大化；這個角色游離于軟件構(gòu)建團隊之外。在微服務(wù)架構(gòu)風(fēng)格中，多個產(chǎn)品負(fù)責(zé)人

服從于某一個業(yè)務(wù)負(fù)責(zé)人，與業(yè)務(wù)負(fù)責(zé)人保持一致的情況是可能存在的。產(chǎn)品負(fù)責(zé)人和相關(guān)軟

件開發(fā)團隊（也就是敏捷用語中所說的“機組”[crew]）可能擁有特定功能的所有權(quán)，如搜索

8

功能（API使用、排序、算法、元數(shù)據(jù)編目），而第二個產(chǎn)品負(fù)責(zé)人則專注于前端客戶的用戶

體驗（風(fēng)格、演示、流程和整體體驗）。數(shù)據(jù)的集成可能會由服務(wù)于多個產(chǎn)品負(fù)責(zé)人數(shù)據(jù)需求

的一個聯(lián)合“機組”負(fù)責(zé)。整體應(yīng)用程序把所有這些角色和行動捆綁進一個垂直的支持體系，

這便是微服務(wù)架構(gòu)風(fēng)格的一個關(guān)鍵特點一一微服務(wù)軟件的開發(fā)和生產(chǎn)部署行動使機構(gòu)的傳統(tǒng)

垂直體系扁平化。不僅應(yīng)用程序的功能是分散布局的，而且它的支撐結(jié)構(gòu)也是分布式的，從而

迫使我們更多地依靠自動化提供以前在垂直體系中相互隔離的各種基礎(chǔ)設(shè)施、策略、安全、身

份和網(wǎng)絡(luò)功能。運維部門通常擁有一套部署和管理IT服務(wù)的流程，但是部署和測試的責(zé)任有

時會左移給構(gòu)建軟件的開發(fā)人員。架構(gòu)師往往需要在實施軟件工程的過程中掌握新的技能，才

能更好地把習(xí)慣和傳統(tǒng)的架構(gòu)工作轉(zhuǎn)換成微服務(wù)架構(gòu)風(fēng)格。

附錄B進一步定義業(yè)務(wù)負(fù)責(zé)人、產(chǎn)品負(fù)責(zé)人、開發(fā)人員、運維人員和架構(gòu)師的角色。有關(guān)

這五種角色的更多詳細(xì)信息和具體定義，請參見詞匯表。

2.目的

CSA于2020年2月出版《實現(xiàn)安全微服務(wù)架構(gòu)的最佳實踐》\為讀者提供了可信安全系

統(tǒng)設(shè)計指南，其中最后一章著重從開發(fā)人員、運維人員和架構(gòu)師的視角闡述。

本文旨在提川一種可重復(fù)的方法,用于按“MAP"（MicroservicesArchitecturePattern,

微服務(wù)架構(gòu)模式）構(gòu)建、開發(fā)和部署微服務(wù)。我們提出的這個“MAP”包含微服務(wù)獨立運行和

與其他微服務(wù)通信所需要的全部信息一一這些微服務(wù)聚合到一起，會形成轉(zhuǎn)而又會成為應(yīng)用程

序成分的能力。本文描述了“MAP”的關(guān)鍵元素、應(yīng)該怎樣設(shè)計和部署，以及應(yīng)該怎樣通過一

種合規(guī)即代碼方法把安全和合規(guī)左移。

本文的主要目的是開發(fā)一個廠商中性的參考架構(gòu)基礎(chǔ)，從這個基礎(chǔ)分解出軟件和平臺（企

業(yè)）平面體現(xiàn)的軟件架構(gòu)模式，以后還可以通過添加安全控制措施疊加重新構(gòu)建。微服務(wù)架構(gòu)

模式的成功分解和重組就證明了這一點；其中的集成操作便是安全控制措施的疊加。

8CloudSecurityAlliance(202QFebruary24).BestPracticesinImplemeritingaSecureMicrosendees

Architecture.https://cloudsecmisallianceorg/aitifocts/bestrpractices4irimplementing-a-securemicrosemces-architecture/m.

9

3.讀者

本文的目標(biāo)讀者是應(yīng)用程序開發(fā)人員、應(yīng)用程序架構(gòu)師、系統(tǒng)和安全管理員、安全項目經(jīng)

理、信息系統(tǒng)安全官以及其他對應(yīng)用程序容器和微服務(wù)的安全負(fù)有責(zé)任或感興趣的人員。

我們假定讀者具備一定程度的操作系統(tǒng)、網(wǎng)絡(luò)和安全專業(yè)知識，同時還掌握了應(yīng)用程序容

器、微服務(wù)和敏捷應(yīng)用程序方面的專業(yè)知識。由于應(yīng)用程序容器技術(shù)具有不斷變化的性質(zhì)，因

此我們鼓勵讀者借助其他資源（包括本文列出的參考文獻）獲得更新和更詳細(xì)的信息。

4.架構(gòu)與解決方案

架構(gòu)并不是解決方案。解決方案是指通過架構(gòu)、模式和設(shè)計上的努力滿足特定行業(yè)需要或

解決具體業(yè)務(wù)問題的辦法。解決方案旨在向客戶和企業(yè)負(fù)責(zé)人提供持續(xù)的價值。以POS機系統(tǒng)

為例，POS機系統(tǒng)是人員之間交互、技術(shù)支持的業(yè)務(wù)流程和后端支付平臺運行的綜合體現(xiàn)，用

于創(chuàng)建一種只靠架構(gòu)無法實現(xiàn)的特定業(yè)務(wù)能力。POS機解決方案的設(shè)計是概念、系統(tǒng)屬性和模

式為應(yīng)對某一特定業(yè)務(wù)挑戰(zhàn)而組合到一起的結(jié)果。任何問題都會有化解挑戰(zhàn)癥結(jié)的解決方案。

但是你若想搞清問題的來龍去脈，就必須回到源頭去了解這個問題之所以會產(chǎn)生的條件和決定。

架構(gòu)與解決方案的區(qū)別在于：解決方案的根本在于設(shè)計。設(shè)計包含一組模式，而這些模式

起源于最早的抽象形式一一??個架構(gòu)。架構(gòu)構(gòu)成了運行環(huán)境中系統(tǒng)的基本概念或?qū)傩?，由系統(tǒng)

的元素、關(guān)系以及系統(tǒng)的設(shè)計和進化原則體現(xiàn)出來。商業(yè)和技術(shù)草圖和圖紙依然是架構(gòu)師向工

程設(shè)計團隊表述自己想法的主要手段。為了進一步消除開發(fā)過程中的可變性，架構(gòu)師與工程師

一起挑選商定的模式，共同奠定設(shè)計和框架設(shè)計活動的基礎(chǔ)。架構(gòu)、模式和設(shè)計不引用特別命

名的技術(shù)，保持了廠商中性。設(shè)計完成后，業(yè)務(wù)負(fù)責(zé)人和技術(shù)負(fù)責(zé)人決定是全部自行構(gòu)建、全

部對外采購還是結(jié)合這兩種構(gòu)建方法，從而針對具體問題創(chuàng)建一個符合業(yè)務(wù)需要的技術(shù)解決方

案。有些業(yè)務(wù)和技術(shù)負(fù)責(zé)人選擇跳過構(gòu)建架構(gòu)的過程并僅憑一組要求尋找現(xiàn)成的解決方案，而

其他人則選擇根據(jù)要求自己構(gòu)建解決方案。

那些到市場上尋求一站式、垂直集成、低代碼或無代碼解決方案的公司，最終也還是要用

構(gòu)建架構(gòu)的方法把買來的解決方案融進現(xiàn)有的控制環(huán)境。而這將不可避免地導(dǎo)致權(quán)衡，其中有

些對初始條件極為敏感，日后倒是能夠引入約束或解決方案重構(gòu)，但是到了那時，改造會帶來

10

經(jīng)濟成本的上升；而這無非是在償還不斷積累的技術(shù)負(fù)債。

許多人認(rèn)為微服務(wù)也是一種架構(gòu)，但微服務(wù)其實只是一種架構(gòu)風(fēng)格。大肆使用水泥預(yù)制板

的粗野主義和依托精雕細(xì)刻的橡木承載使命感的工匠風(fēng)格代表了能夠渲染整棟建筑物的架構(gòu)

風(fēng)格。每種風(fēng)格都有自己的架構(gòu)原則，應(yīng)用得當(dāng)時，這些原則會體現(xiàn)在藍(lán)圖中，引導(dǎo)產(chǎn)生特定

設(shè)計，從而在物理上呈現(xiàn)出預(yù)期的風(fēng)格。如果目標(biāo)是構(gòu)建高度模塊化的分布式應(yīng)用程序，則應(yīng)

用微服務(wù)原理、架構(gòu)、模式和設(shè)計會導(dǎo)致出現(xiàn)一款微服務(wù)應(yīng)用程序。

4.1模式和控制措施疊加

模式是指以可預(yù)測方式發(fā)生的一組可重復(fù)動作和安排。模式是可以通過物理外觀、直接或

間接觀察或分析看出的。設(shè)計應(yīng)用系統(tǒng)時，軟件模式是用于解決一類計算機編程問題的一種已

知可重用方法。軟件模式顯示構(gòu)建元素之間的關(guān)系，但不規(guī)定問題或要求的最終艇決方案。我

們可以把軟件模式視為軟件代碼與支持軟件的系統(tǒng)之間的中間結(jié)構(gòu)體現(xiàn)。以往的軟件模式缺乏

一個關(guān)鍵的宏觀架構(gòu)表述：安全控制措施指南。開發(fā)人員通常不會自行開發(fā)安全解決方案，而

是選擇依靠從平臺或應(yīng)用程序繼承的功能，只有在迫不得已的情況下才會創(chuàng)建自己的安全控制

措施。用加鹽的散列函數(shù)給保存的口令單向加密是開發(fā)人員自己構(gòu)建安全控制措施的一個例子。

歷史上軟件模式都是指導(dǎo)軟件開發(fā)，并不使用信息技術(shù)(IT)安全控制措施。

IT安全控制措施提供了調(diào)節(jié)和管理應(yīng)用系統(tǒng)行為的手段。IT安全控制措施是一種抽象說

法，表述了與應(yīng)對感知風(fēng)險的預(yù)防、檢測或糾正對策相應(yīng)的底層技術(shù)、管理或物理能力。IT

安全控制措施的目標(biāo)是把潛在風(fēng)險降低到可接受、無害或無關(guān)緊要的水平?？刂颇繕?biāo)也是一種

抽象說法，但不同之處在于它是對以特定方式實施控制措施所要達(dá)到的預(yù)期結(jié)果或目的的陳述。

控制目標(biāo)通過使用一個或通常的一組控制措施實現(xiàn)；后者便是所謂的深度防御一一用不同類型

的多個控制措施協(xié)同預(yù)防、檢測和/或糾正次優(yōu)運行狀態(tài)?？刂颇繕?biāo)源自一個控制框架，后者

是可用于幫助業(yè)務(wù)流程負(fù)責(zé)人履行防止信息丟失職責(zé)的一組基本控制措施。多層布局的控制措

施可以在應(yīng)用程序生命周期的不同階段以及應(yīng)用程序運行環(huán)境的不同層面發(fā)揮作用。IT安全

控制措施從新軟件創(chuàng)意誕生，到構(gòu)建、部署，再到平臺運行的所有階段一直存在；這些階段構(gòu)

成了所謂軟件開發(fā)生命周期。

安全專業(yè)人員確實在推動開發(fā)人員左移，但是應(yīng)用程序安全領(lǐng)域要求的專業(yè)水平與IT安

全平臺專業(yè)人員技術(shù)水平的差異越來越大，距離也越來越遠(yuǎn)。機構(gòu)可以通過培養(yǎng)或雇用具有開

11

拓精神的軟件開發(fā)人員或者使用由不同領(lǐng)域?qū)I(yè)人員組成的角色組合管理技能上的差距。在整

體式應(yīng)用程序下，管理技能差距是可以實現(xiàn)的，但是分布式應(yīng)用程序設(shè)計的實體化會擴大豎井

式組織結(jié)構(gòu)部門的控制范圍，從而進一步加劇技能差距和所有權(quán)之爭。

表現(xiàn)不同且論述或探索最少的是企業(yè)平臺層面一一這里有多個豎井式組織結(jié)構(gòu)部門使用

IT控制措施（網(wǎng)絡(luò)、安全、服務(wù)器、存儲、消息傳遞）一一與軟件開發(fā)層面（安全軟件開發(fā)

生命周期和安全測試自動化）之間的空間。安全控制措施疊加可以把企業(yè)平臺層面與較低的軟

件開發(fā)層面聯(lián)系到一起。安全疊加的使用代表了一個適合可擴展安全架構(gòu)角色的領(lǐng)域，其中保

密性、完整性和可用性可擴展到把彈性和隱私問題也包括進來。隨著世界轉(zhuǎn)向使用以軟件為中

心的抽象化方法以及企業(yè)接受軟件中心主義，依賴不僅耍求服務(wù)具有彈性，而且還要求可通過

整個人機交互過程中自我管理數(shù)據(jù)訪問能力實現(xiàn)完整的隱私。安全架構(gòu)作為一種完整思路涵蓋

了人、平臺，外加軟件。

安全架構(gòu)代表了企業(yè)架構(gòu)中專門解決信息系統(tǒng)彈性問題并為滿足安全要求的功能提供架

構(gòu)信息的部分。微服務(wù)語境F的安全架構(gòu)不僅在現(xiàn)有平臺和軟件架構(gòu)上引入了控制措施疊加的

概念，而且安全架構(gòu)師有責(zé)任和義務(wù)劃出一條界線，把體現(xiàn)在平臺層面的控制措施疊加與體現(xiàn)

在軟件本身的控制措施疊加區(qū)分開來。作為一種完整的安全架構(gòu)思路，安全疊加是用于降低風(fēng)

險的多項控制措施的集合體，是管理、技術(shù)和物理控制措施的組合。

全面考慮問題的安全架構(gòu)師往往會先構(gòu)建威脅模型，然后才把控制措施運用到復(fù)雜的解決

方案架構(gòu)之中。威脅建模是把控局面的一種方式。紅藍(lán)對抗、STRIDE,攻擊樹、Trike、VAST、

PASTA和ISO-31010Delphi是風(fēng)險識別方法的示例。威脅建模在很大程度上屬于圍繞著人展

開的一種活動。最好的分析產(chǎn)生于各有側(cè)重的多樣化人群，這樣的群體對攻擊面各個方面的深

入體驗，遠(yuǎn)遠(yuǎn)超過一個人的單獨認(rèn)知。即便是分析受到的系統(tǒng)性沖擊，群體分析也不太容易變

得脆弱。強健的威脅模型來自于對當(dāng)前狀態(tài)、制度歷史和想象力的深入的行業(yè)縱向認(rèn)識，以及

選擇一種適合問題的分析方法.而不是安全架構(gòu)師的方便程度。讓威脅模型契合戰(zhàn)術(shù)實施范圍

并避免空幻、存在主義和黑天鵝場景至關(guān)重要。威脅模型得出的結(jié)果會使IT安全控制措施的

落實合法化，從而形成個可以抑制已知或假定風(fēng)險的強大疊加。在這一點上，安全架構(gòu)不同

于解決方案架構(gòu)，因為它可以減輕乃至消除在擬議的解決方案架構(gòu)中發(fā)現(xiàn)的潛在技術(shù)、管理或

物理風(fēng)險。

一個微服務(wù)應(yīng)用程序不會把每個設(shè)計模式和每個安全控制措施疊加全部囊括其中，但是會

12

包含那些被認(rèn)為對于有效設(shè)計不可或缺，可以解決客戶問題的軟件架構(gòu)模式和安全疊加。而這

正是軟件層面實現(xiàn)扁平化并融進平臺層面的結(jié)合部。在微服務(wù)架構(gòu)風(fēng)格中，任何解決方案除非

在每個所用模式都配備了相應(yīng)的安全控制措施疊加，否則都談不上概念完整。所有疊加都與模

式配套，才算解決方案架構(gòu)構(gòu)建完成。模式與疊加組合到一起，構(gòu)成了微服務(wù)應(yīng)用程序的安全

控制措施狀態(tài)。

4.2微服務(wù)架構(gòu)模式簡介

為了便于指導(dǎo)安全控制措施疊加對微服務(wù)的施用，通用微服務(wù)架構(gòu)模式用兩個分支形成了

兩個不同的視角。第一個視角著眼于企業(yè)層面。企業(yè)層面包含了可協(xié)助實現(xiàn)微服務(wù)架構(gòu)治理的

信息技術(shù)資產(chǎn)。企業(yè)期望減少控制措施狀態(tài)的變數(shù)。自定義編碼、生產(chǎn)狀態(tài)變通方案和一次性

修改都會增加開發(fā)成本。技術(shù)負(fù)債（如以增添安全設(shè)備形式出現(xiàn)的技術(shù)負(fù)債）、在設(shè)計中引入

會限制靈活性的緊耦合等，可能會妨礙基礎(chǔ)設(shè)施作為代碼部署的能力，從而形成沒有必要的持

久存在。企業(yè)環(huán)境期望軟件開發(fā)盡可能多地繼承安全控制措施，以防開發(fā)團隊在編制應(yīng)用程序

安全指南的過程中出現(xiàn)可變性和不可靠性。安全疊加同時存在于企業(yè)層面和軟件層面。API注

冊中心處理已完成開發(fā)的微服務(wù)的清單和版本以及主導(dǎo)服務(wù)供應(yīng)商和第三方集成。服務(wù)存儲庫

（存放API規(guī)范、模板、代碼腳手架、用于構(gòu)建過程的構(gòu)件等）在微服務(wù)開發(fā)過程中建立統(tǒng)一

性、自動進行靜態(tài)和動態(tài)安全測試，并把微服務(wù)引入容器，最終通過公共管道交付合為一體的

功能（例如會先觸發(fā)安全檢查，然后觸發(fā)配置管理資源部署計劃的Jenkins操作）。理想狀態(tài)

是，按企業(yè)層面的要求在執(zhí)行引導(dǎo)進程的過程中交付平臺層面的安全鉤、調(diào)用和集成，這樣可

以避免在運行期間不得不進行的修改。

第二個視角著眼于軟件層面。圖1是分布式微服務(wù)應(yīng)用的分解圖，這種狀況存在于軟件層

面，是最接近軟件代碼的表現(xiàn)方式。該圖描述了合成的分布式微服務(wù)應(yīng)用程序的一般性圖景。

它像是一張X光片，在上半部分顯示主要的可繼承的企業(yè)層面的系統(tǒng)集成，在下半部分顯示微

服務(wù)組件。各類機器客戶端（瀏覽器、物聯(lián)網(wǎng)、移動、API集成）和物理消費者通過企業(yè)層面

訪問分布式微服務(wù)應(yīng)用程序提供的功能。API控制著客戶端使用的表示邏輯，并提供一項且只

有一項業(yè)務(wù)功能，同時包含用來控制客戶端可以從暴露的API獲取哪些內(nèi)容的其他業(yè)務(wù)規(guī)則。

API可以整理來自多個來源的數(shù)據(jù)，并且可以訪問安放在托管微服務(wù)API的容器外面數(shù)據(jù)卷上

的數(shù)據(jù)。微服務(wù)利用企業(yè)層面的服務(wù)和軟件層面的API網(wǎng)關(guān)服務(wù)在容器之間平衡負(fù)載，允許多

個微服務(wù)實例在生產(chǎn)中同時運行。在軟件層面的微服務(wù)環(huán)境下，由sidecar服務(wù)代表公用程序

13

服務(wù)處理與微服務(wù)中存在業(yè)務(wù)邏輯無關(guān)的任務(wù)。每個微服務(wù)API都有一個sidecar與之配對，

而在集群容器環(huán)境中，sidecar根據(jù)服務(wù)通信策略和安全策略交付服務(wù)的手段。通信流的主要

組成機制是網(wǎng)絡(luò)訪問控制邏輯?？刂茣蕴摂M局域網(wǎng)、基于策略的路由選擇、基于上下文的

ACL、特定網(wǎng)關(guān)邏輯和軟件定義的網(wǎng)絡(luò)的形式出現(xiàn)。這些企業(yè)層面執(zhí)行方案中的每一個都自帶

安全疊加權(quán)衡。構(gòu)成通信流和控制流的主要手段，是企業(yè)層面嚴(yán)格管理的授權(quán)，以及攜帶被加

密客戶端權(quán)限（即OAuth）、外部管理的托管憑證（如平臺層面機對機憑證托管和管理）和mTLS

（企業(yè)層面相互傳輸層安全證書管理）的訪問令牌。安全控制措施疊加可以在一個層面內(nèi)以及

跨企業(yè)和軟件層面發(fā)揮作用一一從而實現(xiàn)深度防御。安全控制措施疊加同時存在于兩個層面。

客戶端

（客戶'設(shè)備、第三方APIJII點、可值和半可信方）

企業(yè)層面

企業(yè)內(nèi)容交付和ONS圈務(wù)

企業(yè)路由和交換凰務(wù)

企業(yè)防火墻股務(wù)

企業(yè)代理冊務(wù)

身份供應(yīng)裕KIK務(wù)雷碼程務(wù)DEVOPS/安全SMC容4注霸API注冊

（生命冏期、挑范、

聯(lián)合和JR務(wù)ID管理入侵,欺保、異常定犯和迂書管理Cl/COTRia（影像.檔案.快照）

運行時配

軟件層面

集群/集群API

:段式

容器容器

極式枚式：ifeKB

SDCKFacade/~^p\融凰務(wù)參考

珞由選擲

傲原務(wù)（UI）\/（業(yè)務(wù)邏輯）

震合

代理

SidecarSidecar

API網(wǎng)關(guān)記錄

數(shù)據(jù)源

段式

贛脫務(wù)

（包奘X）

極式

舊有應(yīng)用程序

Sidecar

企業(yè)層面監(jiān)控和遙測

OS.踩速、淵■指標(biāo)，??.工作流、成擬化）

圖4T微服務(wù)參考架構(gòu)一一企業(yè)層面和軟件層面

14

5.微服務(wù)架構(gòu)模式

5.1模式

以下架構(gòu)模式適用于將微服務(wù)開發(fā)成業(yè)務(wù)應(yīng)用。研究這些模式時一定會注意到，正是許多

模式的共同作用，構(gòu)成了一個安全的系統(tǒng)。盡管最初可能要從某一個模式(如身份驗證)入手,

但必須搞清，這些模式是怎樣通過彼此交互支撐起一個安全而富有彈性的業(yè)務(wù)解決方案的。

5.1.1卸載(Offload)模式

卸載是針對具體環(huán)境的一個通用數(shù)據(jù)流動作。卸載可以與API網(wǎng)關(guān)功能緊密耦合，例如通

過內(nèi)核軟件或加速器硬件提供TLS密碼終止功能，從而使后端設(shè)備不必管理TLS連接。卸載也

可以與數(shù)據(jù)訪問層緊密耦合，在這一層把數(shù)據(jù)寫入分散到多個同時進行的數(shù)據(jù)提交動作中，從

而提高數(shù)據(jù)寫入或讀取的速度。卸載還可以應(yīng)用了身份驗證和授權(quán)。一般來說，被卸載的功能

是常被許多其他服務(wù)作為共享服務(wù)使用的功能。如果選擇卸載一項服務(wù)，就表明一個資源不必

再被微服務(wù)API納入它的代碼庫。

版本1.0

15

模式目的展現(xiàn)鞏固技術(shù)能力的機會

層面位置企業(yè)(平臺)層面

結(jié)構(gòu)描述API網(wǎng)關(guān)是外部流量進入微服務(wù)應(yīng)用的入口。

行為描述卸載TLS證書托管；TLS終止；AuthN和AuthX請求中介服務(wù)

數(shù)據(jù)特性傳輸中的數(shù)據(jù)

主要依賴性平臺層面與IAM平臺、證書管理平臺相互連接;上游入口堡壘防火墻；

上游負(fù)載平衡平臺

次要依賴性容器集合體(containerfleet.)；相鄰的安全U志相互連接

內(nèi)部事件/消息HTTPSv2/3；AS2

傳遞需要

外部事件/消息傳遞API層面日志；網(wǎng)關(guān)層面系統(tǒng)日志；AuthN和AuthX消息交換

鏈接

事件響應(yīng)行為發(fā)送，不接收。沒有轉(zhuǎn)換；原始機器輸出

共同的上游鏈接防火墻：全局和/或本地通信流負(fù)載平衡；網(wǎng)絡(luò)間ACL

共同的下游鏈接發(fā)證機構(gòu)；配置管理；API注冊中心；集群管理API安全環(huán)境；機器

ID/服務(wù)ID憑證托管

Ops安全回接API性能監(jiān)控；syslog監(jiān)控；機器健康監(jiān)控；異常檢測

DcvSccOps回接安全SDLC；API注冊中心；Swagger/YAMLAPI定義；AuthN和AuthX

控制

16

評估方法API性能趨勢分析；SIEM日志分析并與上游事件關(guān)聯(lián)；跨APT訪問端

口和協(xié)議的異常關(guān)聯(lián)

控制措施疊加的特性可從平臺繼承，而不是內(nèi)置于API規(guī)范或容器基礎(chǔ)設(shè)施。

復(fù)合狀態(tài)（獨有/通通用；其他模式也使用這一疊加。

用）

5.1.2路由（路由選擇）模式

當(dāng)一個端點需要暴露背后的多項服務(wù)時.，可使用路由模式，根據(jù)入站請求路由請求和消息。

路由選擇策略和路由通信流管理被嵌入服務(wù)網(wǎng)格和/或使用sidecar服務(wù)。如果服務(wù)網(wǎng)格沒有嵌

入路由策略和通信流管理.則需要把API規(guī)范與有關(guān)消息隊列設(shè)計的路由邏輯結(jié)合到一起實現(xiàn)

API拓?fù)洌础罢l可以與誰交談，誰可以從誰那兒獲得消息”）。以往，大型分布式整體式傳

統(tǒng)應(yīng)用程序依靠消息隊列傳輸交易信息.以便應(yīng)用保持狀態(tài)。如果沒有服務(wù)網(wǎng)格可供使用，微

服務(wù)將可能不得不擁有路由選擇邏輯.以此執(zhí)行原本該由sidecar服務(wù)執(zhí)行的公用程序功能。

另外，路由選擇模式（或功能）可以設(shè)置在APT網(wǎng)關(guān)上。路由模式可以存在于硬件或軟件中。

17

路由模式

版本1.0

根據(jù)請求中的數(shù)據(jù)，如識別身份、來源、客戶端類型、請求主機

模式目的

值、請求URI路徑元素等的請求標(biāo)頭，將請求通信流路由給同服

務(wù)的不同版本或?qū)嵗?。根?jù)通過源1P地址確定的請求源在有限時

間內(nèi)將請求路由給服務(wù)的一個新版本，便是路由選擇模式的一個

用例。

路由目的地也可以是消息隊列而不是同步服務(wù)端點。

層面位置企業(yè)（平臺）層面

結(jié)構(gòu)描述根據(jù)路由策略配置所定義的請求或消息數(shù)據(jù)，將請求路由到服務(wù)

的特定版本或?qū)嵗蛳㈥犃小?/p>

行為描述根據(jù)請求數(shù)據(jù)和路由策略配置對入站請求進行評估，確定目標(biāo)服

務(wù)實例的目的地或消息隊列。

數(shù)據(jù)特性使用中的數(shù)據(jù)/傳輸中的數(shù)據(jù)

主要依賴性API網(wǎng)關(guān)、經(jīng)過配置的服務(wù)網(wǎng)格功能、sidecar等路由組件必須可

用。

次要依賴性路由目的地或消息隊列必須可用。

內(nèi)部事件/消息傳遞目標(biāo)服務(wù)和消息隊列目的地的健康和可用

需要

外部事件/消息傳遞服務(wù)網(wǎng)格日志和遙測

鏈接

事件響應(yīng)行為響應(yīng)目標(biāo)服務(wù)不可用的自適應(yīng)或后備路由

18

共同的上游鏈接IAM平臺、網(wǎng)關(guān)平臺（API,負(fù)載平衡，基于策略的路由）

共同的下游鏈接隊列、數(shù)據(jù)存儲庫、其他內(nèi)部API

API網(wǎng)關(guān)可用性

Ops安全回接

DDOS預(yù)防

擴展或節(jié)制通信流以確?？捎眯?/p>

SAST——服務(wù)網(wǎng)格配置審計

DevSecOps回接

DAST---服務(wù)端點的AuthN和AuthZ測試

IAST一一剔除假陽性結(jié)果

評估方法路由功能的可觀察性、遙測和U志記錄。U志記錄可提供實時可

見性和可觀察性。

控制措施疊加的特性預(yù)防性---DevSecOps控制、DDoS預(yù)防

檢測性和糾正性一一擴容/收縮以確?？捎眯?/p>

復(fù)合狀態(tài)（獨有7通用）通用

5.1.3聚合模式

聚合模式接收并向多個微服務(wù)發(fā)出請求，然后把對后端服務(wù)發(fā)出的多個請求合并成一個請

求，用以響應(yīng)初始請求。當(dāng)許多設(shè)備向一個中心點發(fā)送交易消息和活動日志時，往往會在云邊

緣發(fā)生軟件定義的聚合。其他模式可能會在網(wǎng)關(guān)聚合背后發(fā)揮作用，如Facade模式、代理模

式和斷路器模式，具體由應(yīng)用目標(biāo)和通信特點決定。這些設(shè)計模式有類似的結(jié)構(gòu)，但是使用它

們的意圖或目的各不相同。

19

版本l.o

模式目的聚合（網(wǎng)關(guān)）模式的目的是減少應(yīng)用程序?qū)蠖朔?wù)提出請求的

數(shù)量，并提高應(yīng)用程序在高時延網(wǎng)絡(luò)上的性能。

層面位置企業(yè)（平臺）層面

結(jié)構(gòu)描述聚合（網(wǎng)關(guān)）模式用于將多個單獨的請求聚合成一個請求或響應(yīng)。

行為描述當(dāng)一個客戶端需要向各種后端系統(tǒng)發(fā)出多個調(diào)用來執(zhí)行一項操作

時，聚合（網(wǎng)關(guān)）模式會很有用。

數(shù)據(jù)特性當(dāng)聚合器合并來自多個終端的數(shù)據(jù)集時，使用中的數(shù)據(jù)可能需要

得到安全保護。否則，聚合器可能只在請求者與響應(yīng)者之間傳輸

數(shù)據(jù)。

主要依賴性網(wǎng)絡(luò)（網(wǎng)絡(luò)可能會帶來嚴(yán)重時延）

次要依賴性可用性和接近性（將與這一模式通信的各種系統(tǒng)的可用性）

20

內(nèi)部事件/消息傳遞需聚合器模式可安全驗證請求者的身份并傳遞一個訪問令牌。服務(wù)

要可驗證請求者是否得到授權(quán)可以執(zhí)行所涉操作。

外部事件/消息傳遞網(wǎng)絡(luò)安全控制措施（網(wǎng)絡(luò)訪問控制——AuthN、AuthZ、通過加密

鏈接保護靜止數(shù)據(jù)等）

事件響應(yīng)行為確保聚合網(wǎng)關(guān)具有可滿足應(yīng)用程序可用性要求的彈性設(shè)計。

聚合網(wǎng)關(guān)可能是一個單點故障（SPOF）點，因此應(yīng)該具備處理負(fù)

載平衡的良好能力。

聚合網(wǎng)關(guān)應(yīng)該配備有適當(dāng)?shù)目刂?，可確保來自后端系統(tǒng)的任何響

應(yīng)延遲都不會造成性能問題。

共同的上游鏈接配置管理；API安全；策略管理和執(zhí)行

共同的下游鏈接維護、運行時間/停機時間、集成、測試、漏洞掃描和打補丁

Ops安全回接Tie-backAPI性能監(jiān)控：系統(tǒng)日志監(jiān)控；健康監(jiān)控：異常檢測、事件管理、

反惡意軟件/病毒、漏洞抑制、補丁

DevSecOps回接安全SDLC：敏捷、更簡單/更靈活的開發(fā)和測試周期、持續(xù)集成/持

續(xù)交付（CI/CD）管道

評估方法日志記錄/監(jiān)控；警報、基于授權(quán)失敗條件的計量警報、SIEM事故

和事件管理

控制措施疊加的特性網(wǎng)關(guān)可改善并直接影響應(yīng)用程序的性能和規(guī)模。

預(yù)防性：漏洞抑制、打補丁

糾正性：事件響應(yīng)

檢測性：性能監(jiān)控、健康監(jiān)控

復(fù)合狀態(tài)（獨有/通用）通用

21

5.1.4緩存模式

應(yīng)用設(shè)計中的緩存通常是用來滿足提高可用性、改善應(yīng)用性能和/或減少后端數(shù)據(jù)讀寫的

要求的。緩存可以是嵌入式的，也可以是分布式的。主要緩存模式有許多衍生。如果?項'也務(wù)

操作對于后續(xù)使用具有持續(xù)的價值，可以考慮把結(jié)果緩存起來。例子包括按交易定價的數(shù)據(jù)兀

素，如