微服務(wù)安全面臨的挑戰(zhàn)

• 更多的入口點(diǎn)，更高的安全的風(fēng)險(xiǎn)
• 性能問題
• 服務(wù)間通訊安全
• 跨多個(gè)微服務(wù)的請(qǐng)求難以追蹤【對(duì)于一個(gè)服務(wù)來(lái)說(shuō)喳魏，可觀測(cè)性是一個(gè)很重要的指標(biāo)悲柱，可觀測(cè)性包含了三個(gè)方面的意義】
• 容器化部署導(dǎo)致的證書和訪問控制問題
• 如何在微服務(wù)間共享用戶登陸狀態(tài)
• 多語(yǔ)言架構(gòu)要求每個(gè)團(tuán)隊(duì)都有一定的安全經(jīng)驗(yàn)

一民晒、 更多的入口點(diǎn)芙贫，更高的安全的風(fēng)險(xiǎn)

1. 在原來(lái)單塊的應(yīng)用場(chǎng)景下搂鲫，我的入口點(diǎn)只有一個(gè)，就是我們的應(yīng)用屹培，所有的請(qǐng)求都會(huì)從這個(gè)入口點(diǎn)進(jìn)來(lái)，可能是 80 端口怔檩，也可能是 443端口褪秀，反正入口點(diǎn)很少，在這個(gè)入口點(diǎn)上薛训，只需要建立一組fitter【J2EE 原生攔截器實(shí)現(xiàn)】或者 interecptor【Spring 容器內(nèi)攔截器的實(shí)現(xiàn)】媒吗，就可以控制住所有的安全風(fēng)險(xiǎn)
2. 那么在一個(gè)微服務(wù)環(huán)境下，業(yè)務(wù)邏輯不在是在一個(gè)單一的進(jìn)程乙埃，而是分散在很多的進(jìn)程里面闸英，每一個(gè)微服務(wù)都是一個(gè) tomcat【進(jìn)程】锯岖，而每一個(gè)進(jìn)程 tomcat 都有自己的入口點(diǎn)，這會(huì)導(dǎo)致我們防范的攻擊面比原來(lái)大的多甫何，風(fēng)險(xiǎn)也會(huì)高的多

二出吹、性能問題

1. 單體應(yīng)用：原來(lái)的單體應(yīng)用里面所有的業(yè)務(wù)邏輯都在同一個(gè)進(jìn)程里面，那么我需要的安全信息也都在里面辙喂，請(qǐng)求進(jìn)來(lái)以后捶牢，需要驗(yàn)證身份、權(quán)限都是在同一個(gè)進(jìn)程里面完成的
2. 而在微服務(wù)架構(gòu)里面巍耗，關(guān)于需要的安全的信息很可能在單個(gè)微服務(wù)的進(jìn)程里面是沒有的秋麸，比如訪問訂單的時(shí)候，用戶的信息炬太、權(quán)限的信息在訂單系統(tǒng)里面是拿不到的灸蟆，需要調(diào)用安全中心、用戶中心來(lái)獲取相關(guān)的信息亲族，這樣就需要進(jìn)行一個(gè)遠(yuǎn)程調(diào)用了炒考，就會(huì)對(duì)性能造成影響

三、微服務(wù)間通信安全

單體應(yīng)用場(chǎng)景下只需要考慮從外部進(jìn)來(lái)的請(qǐng)求是不是安全的孽水，里面涉及到的服務(wù)之間相互的調(diào)用是不需要我們考慮安全的票腰，但是在微服務(wù)場(chǎng)景下從訂單去調(diào)用物流的時(shí)候，是需要跨網(wǎng)絡(luò)女气，從一個(gè)進(jìn)程進(jìn)入另一個(gè)進(jìn)程杏慰，所以需要考慮服務(wù)之間的通信安全

四、跨多個(gè)微服務(wù)的請(qǐng)求難以追蹤

對(duì)于一個(gè)服務(wù)來(lái)說(shuō)炼鞠，可觀測(cè)性是一個(gè)很重要的指標(biāo)缘滥，可觀測(cè)性包含了三個(gè)方面的意義

1. log 【日志，用來(lái)記錄我們系統(tǒng)發(fā)生了什么】
   分布式環(huán)境中谒主，我們每個(gè)系統(tǒng)都會(huì)單獨(dú)記錄日志朝扼，所以日志是分散來(lái)記錄的，這個(gè)時(shí)候需要一個(gè)機(jī)制能夠把所有日志串起來(lái)
2. metrics【把日志信息聚合起來(lái)】
metrics 有兩個(gè)關(guān)鍵要素霎肯，第一個(gè)是時(shí)間窗口擎颖，第二個(gè)是一個(gè)數(shù)字【比如說(shuō)流量：我們一般會(huì)說(shuō)在1秒鐘之內(nèi)有10個(gè)請(qǐng)求，在1分鐘之內(nèi)有兩百個(gè)請(qǐng)求观游，過去三小時(shí)內(nèi)下了50個(gè)單搂捧，過去一天的成交額是100萬(wàn)】最簡(jiǎn)單的metrics 是我們的流量，即每秒鐘有多少個(gè)請(qǐng)求懂缕。在單體應(yīng)用里面允跑，我們很容易控制這個(gè)事情，但是在分布式應(yīng)用中，可能我們的訂單能夠承受的并發(fā)量是500聋丝，物流承受的并發(fā)量是700索烹，這個(gè)時(shí)候我們需要一個(gè)整個(gè)能夠承受服務(wù)的流控，而不是單一的承受某一個(gè)微服務(wù)的流控弱睦，這也是一個(gè)要解決的問題
3. tracing
   要解決在經(jīng)過某一個(gè)服務(wù)的耗時(shí)百姓，以及經(jīng)過所有服務(wù)的耗時(shí)，然后統(tǒng)計(jì)性能

五每篷、容器化部署導(dǎo)致的證書和訪問控制問題

1. 在微服務(wù)的場(chǎng)景里面瓣戚，我們最常用的部署手段就是容器化，在我們以前的部署里邊焦读，部一個(gè)應(yīng)用子库，部一個(gè)集群，我們就要4臺(tái)機(jī)器矗晃，然后部署4個(gè)實(shí)例仑嗅，這個(gè)時(shí)候我們的IP 地址都是固定的。然后我們要做什么白名單张症、安裝證書仓技，然后在這4個(gè)機(jī)器上安裝證書，然后根據(jù)這4個(gè)機(jī)器的IP 寫白名單就可以了
2. 而在微服務(wù)里面俗他，我們通常是通過容器化完成部署的脖捻。容器化的一個(gè)好處就是帶來(lái)了一個(gè)不可變的服務(wù)器，當(dāng)一個(gè)容器一旦產(chǎn)生兆衅，里面的內(nèi)容是不會(huì)變的地沮，不可變的服務(wù)器意味著你可以隨時(shí)干掉這個(gè)容器，然后在另外一個(gè)地方啟用一個(gè)一摸一樣的羡亩，當(dāng)我們請(qǐng)求壓力大的時(shí)候摩疑，立馬再啟用多個(gè)容器，來(lái)把壓力分擔(dān)掉畏铆，所以在微服務(wù)部署里面雷袋，容器化或者不可變的服務(wù)是一個(gè)很重要的原則，在這樣一個(gè)情況下辞居，就是導(dǎo)致我們證書楷怒、訪問控制會(huì)出現(xiàn)一個(gè)問題。當(dāng)然我們可以把證書打到鏡像里面瓦灶，這就要求我們服務(wù)的每個(gè)鏡像是不一樣的鸠删，那么這個(gè)時(shí)候，這種差異就會(huì)帶來(lái)維護(hù)上的困難倚搬，當(dāng)然也是可以的
3. 當(dāng)然更好的解決方案是我們有一個(gè)自動(dòng)化的機(jī)制冶共，在每個(gè)容器創(chuàng)建的時(shí)候乾蛤，根據(jù)這個(gè)容器的屬性不同每界，有一個(gè)自動(dòng)注入的機(jī)制捅僵，把他需要的證書注入進(jìn)去，這樣每個(gè)應(yīng)用就不用關(guān)心自己的證書問題了
4. 另外一個(gè)訪問控制：我們?cè)瓉?lái)機(jī)器就4個(gè)節(jié)點(diǎn)眨层，我寫個(gè)簡(jiǎn)單的白名單庙楚，寫個(gè)IP，針對(duì)這4個(gè)IP能對(duì)外訪問趴樱÷疲或者別人訪問我們的時(shí)候，只寫這4個(gè)IP 就可以了
5. 但是在容器化的部署中叁征，我們可能隨時(shí)產(chǎn)生容器的調(diào)度纳账，容器的擴(kuò)縮容，IP 地址是不斷變化的捺疼，這個(gè)時(shí)候如何控制白名單疏虫、黑名單進(jìn)行訪問控制也是我們要面臨的新的問題
6. 但是在容器化的部署中，我們可能隨時(shí)產(chǎn)生容器的調(diào)度啤呼，容器的擴(kuò)縮容卧秘，IP 地址是不斷變化的，這個(gè)時(shí)候如何控制白名單官扣、黑名單進(jìn)行訪問控制也是我們要面臨的新的問題

六翅敌、如何在微服務(wù)間共享用戶登陸狀態(tài)

1. 原來(lái)在單體應(yīng)用中，我們用的是固定session惕蹄，session是覆蓋到所有服務(wù)
2. 但是在微服務(wù)環(huán)境下蚯涮，在進(jìn)入訂單服務(wù)的時(shí)候，我們需要知道用戶是誰(shuí)焊唬，在進(jìn)入物流服務(wù)的時(shí)候恋昼，我們需要知道用戶是誰(shuí)
3. 如何在多個(gè)應(yīng)用之間共享用戶登陸狀態(tài)？在這個(gè)請(qǐng)求中所涉及的微服務(wù)都知道當(dāng)前用戶是誰(shuí)赶促？這樣 一個(gè)信息

七液肌、多語(yǔ)言架構(gòu)要求每個(gè)團(tuán)隊(duì)都有一定的安全經(jīng)驗(yàn)

常見的微服務(wù)安全整體架構(gòu)

整體架構(gòu).png

OAuth 2.0 簡(jiǎn)要介紹

角色分類

用戶

真正的人

客戶端應(yīng)用

可能是一個(gè) Web App 或者手機(jī) App，用戶會(huì)直接訪問這些應(yīng)用

認(rèn)證服務(wù)器

1. 作用
   它的作用是認(rèn)證鸥滨，證明一個(gè)人真的是他嗦哆，然后發(fā)出令牌

2. 需要做的事情
   1）首先它需要知道有哪些客戶端應(yīng)用【被授權(quán)系統(tǒng)】要請(qǐng)求令牌
   2）還需要知道有哪些合法的用戶【因?yàn)樗钦J(rèn)證服務(wù)器】
   3）最后需要知道道發(fā)出去的令牌應(yīng)該用于訪問哪些資源服務(wù)器

3. 認(rèn)證服務(wù)器和資源服務(wù)器扮演者一對(duì)多的關(guān)系，一個(gè)認(rèn)證服務(wù)器可以替無(wú)限多個(gè)資源服務(wù)器做認(rèn)證

資源服務(wù)器

存儲(chǔ)資源的服務(wù)器

OAuth.png

核心交互流程

1. 用戶在使用客戶端的時(shí)候婿滓，它首先要去認(rèn)證服務(wù)器做一個(gè)認(rèn)證老速，認(rèn)證服務(wù)器的作用是用來(lái)認(rèn)證說(shuō)自己是“張三”的真的是張三
2. 證明了以后會(huì)發(fā)一個(gè)令牌給客戶端應(yīng)用，告訴客戶端應(yīng)用說(shuō)凸主，你拿這個(gè)令牌橘券，這個(gè)令牌就代表了張三這個(gè)用戶
3. 下邊客戶端應(yīng)用就會(huì)拿這個(gè)令牌去訪問我們的資源服務(wù)器，也就是我們的微服務(wù)，這個(gè)時(shí)候就會(huì)帶著這個(gè)令牌去訪問旁舰，相當(dāng)于代表用戶去訪問我們這個(gè)微服務(wù)
4. 資源服務(wù)器【也就是我們的微服務(wù)】收到這個(gè)請(qǐng)求以后锋华，拿到請(qǐng)求里面的令牌后，他會(huì)去訪問認(rèn)證服務(wù)器來(lái)驗(yàn)證請(qǐng)求中的令牌箭窜，問認(rèn)證服務(wù)器毯焕，我現(xiàn)在收到一個(gè)令牌，這個(gè)令牌是誰(shuí)磺樱，認(rèn)證服務(wù)器告訴他纳猫，這個(gè)令牌是張三找颓，訂單服務(wù)【資源服務(wù)器】就會(huì)認(rèn)為這個(gè)請(qǐng)求是張三這個(gè)用戶發(fā)過來(lái)的

核心流程的本質(zhì)

1. 本質(zhì)仍然是一個(gè)基于令牌 token 的認(rèn)證方式
2. 這個(gè)和我們基于 Cookie屯伞、Session 的本質(zhì)是一樣的，都是基于 token 的認(rèn)證方式
3. 本質(zhì)都是認(rèn)證服務(wù)器發(fā)送令牌給客戶端簸喂，客戶端攜帶令牌進(jìn)行訪問

OAuth 2.0 微服務(wù)架構(gòu)下的問題

1. 安全處理和業(yè)務(wù)邏輯耦合块差，增加復(fù)雜性和變更成本
2. 隨著業(yè)務(wù)節(jié)點(diǎn)增加物遇，認(rèn)證服務(wù)器壓力增大
3. 多個(gè)微服務(wù)同時(shí)暴露，增加了外部訪問的復(fù)雜性

解決方案

所有請(qǐng)求都由網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)

1. 安全處理都放在網(wǎng)關(guān)憾儒，這樣安全處理和業(yè)務(wù)邏輯就不會(huì)耦合了
2. 即使業(yè)務(wù)節(jié)點(diǎn)增加了询兴，認(rèn)證服務(wù)器承受的壓力變小了【因?yàn)闃I(yè)務(wù)節(jié)點(diǎn)增加了，網(wǎng)關(guān)可能也需要擴(kuò)容起趾，但是認(rèn)證服務(wù)不會(huì)直接受網(wǎng)關(guān)的影響】
3. 外部訪問只需要訪問網(wǎng)關(guān)即可诗舰，不需要關(guān)注具體的微服務(wù)

微服務(wù).png