基于擬態(tài)架構(gòu)的內(nèi)生安全云數(shù)據(jù)中心關(guān)鍵技術(shù)和實現(xiàn)方法

張帆，謝光偉，郭威，扈紅超，張汝云，劉文彥

（1. 國家數(shù)字交換系統(tǒng)工程技術(shù)研究中心，河南 鄭州 450002；2. 復(fù)旦大學(xué)計算機科學(xué)技術(shù)學(xué)院，上海 201203；3. 之江實驗室，浙江 杭州 311121）

1 引言

近年來，云計算技術(shù)的迅速崛起推動了服務(wù)模式與應(yīng)用架構(gòu)的變革重構(gòu)，互聯(lián)網(wǎng)業(yè)務(wù)的云化已成為主流趨勢，得到了學(xué)術(shù)界和產(chǎn)業(yè)界的廣泛關(guān)注[1]。然而，隨著云計算技術(shù)應(yīng)用的逐漸普及，其系統(tǒng)平臺與信息管理等方面的安全問題也日益凸顯[2]。根據(jù)近幾年國家信息安全漏洞共享平臺（CNVD）收錄的相關(guān)漏洞的統(tǒng)計分析可知，與云及虛擬化相關(guān)的漏洞數(shù)量和危害等級正在不斷升級[3]；另一方面，從每年產(chǎn)業(yè)界爆出的各類安全事件來看，大量云數(shù)據(jù)泄露、云設(shè)施服務(wù)中斷、用戶權(quán)限失效等問題，帶來了不計其數(shù)的經(jīng)濟損失。

云數(shù)據(jù)中心是云計算業(yè)務(wù)服務(wù)的承載實體，也是安全防護聚焦的重點方向。但是，現(xiàn)有云數(shù)據(jù)中心的安全手段大多繼承和沿用傳統(tǒng)網(wǎng)絡(luò)防護方法[4]，主要依賴于攻擊先驗知識的檢測判別、基于邊界“外掛式”的隔離阻斷或“后知后覺”的補丁式安全技術(shù)，無法有效應(yīng)對云環(huán)境下新的攻擊模式，更難以解決因軟/硬件缺陷、漏洞后門等內(nèi)生安全問題所引發(fā)的未知威脅。當(dāng)前，云環(huán)境下復(fù)雜嚴峻的安全問題已經(jīng)成為制約應(yīng)用與服務(wù)市場發(fā)展壯大的“達摩克里斯之劍”[5]。

值得關(guān)注的是，內(nèi)生安全概念的逐漸興起，使我們對以云數(shù)據(jù)中心為代表的新一代信息基礎(chǔ)設(shè)施安全內(nèi)涵進行了重新審視。從哲學(xué)意義上說，“世上萬物有利必有弊”的對立統(tǒng)一關(guān)系，決定了云信息系統(tǒng)的功能在設(shè)計和實現(xiàn)時必然存在兩面性，其負面性應(yīng)用會產(chǎn)生內(nèi)生安全問題的潛在影響。而想要抑制系統(tǒng)的內(nèi)生安全問題，不能依賴于攻擊者的先驗知識特征或外掛式的傳統(tǒng)安全技術(shù)，需要有效利用系統(tǒng)自身架構(gòu)、功能和運行機制等內(nèi)源性效應(yīng)獲得安全功能[6]。前期，相關(guān)團隊在6G網(wǎng)絡(luò)[7]、新型網(wǎng)絡(luò)[8]、交換機[9]等領(lǐng)域的探索已驗證了面向內(nèi)生安全解決方案的有效性[10]，值得我們進一步延拓至云安全領(lǐng)域開展研究。

2 云數(shù)據(jù)中心內(nèi)生安全分析

當(dāng)前，云數(shù)據(jù)中心所暴露的安全威脅眾多，大致包含的種類有：數(shù)據(jù)的泄露、篡改和丟失，應(yīng)用權(quán)限控制異常、API安全、賬戶劫持、惡意內(nèi)部人員攻擊、APT攻擊、拒絕服務(wù)攻擊等。將上述問題根據(jù)攻擊目標(biāo)和云數(shù)據(jù)中心架構(gòu)對應(yīng)，基本可以歸納為圖1所示表述方式。

不難發(fā)現(xiàn)，云數(shù)據(jù)中心所涉及的安全威脅在方法內(nèi)容上與傳統(tǒng)網(wǎng)絡(luò)安全威脅大相徑庭，只是在目標(biāo)對象及滲透鏈路上更為豐富，攻擊者可以基于云平臺層面對應(yīng)用業(yè)務(wù)及相關(guān)軟/硬件發(fā)難，這使得其安全狀態(tài)進一步惡化。如圖1所示，簡單來說，云數(shù)據(jù)中心的攻擊方法是在傳統(tǒng)的系統(tǒng)架構(gòu)下引入了云平臺新的攻擊層面及其對應(yīng)的新型攻擊方法。而這些攻擊方式手段看似繁雜，其實大多繞不開信息系統(tǒng)中存在的設(shè)計或?qū)崿F(xiàn)的漏洞后門，即前文提到的內(nèi)生安全問題。

圖1 攻擊鏈路示意圖

2009年，VMware虛擬化軟件MAC版本爆出嚴重的安全漏洞，攻擊者基于該漏洞可通過Windows虛擬機在其MAC主機上直接執(zhí)行惡意代碼，是一種代表性的基于API的向下滲透攻擊；2012年，僅XEN Hypervisor 4.1.4版本就修復(fù)了18個關(guān)鍵漏洞，隨后類似的GAE（Google App engine）漏洞也被發(fā)現(xiàn)，攻擊者可以利用它們逃逸虛擬機的隔離和安全保護措施，對系統(tǒng)平臺實施越權(quán)控制；2016年，QEMU組件與CloudStack SAML組件也爆出諸多問題，攻擊者可以基于其漏洞繞過身份驗證機制；2017年，OpenStack Glance Newton組件也被發(fā)現(xiàn)存在服務(wù)器端的安全限制繞過漏洞的問題。通過上述安全事件，可以預(yù)見由云平臺內(nèi)生安全問題引發(fā)的各類威脅是難以避免的，將是安全人員首要面對的難題。

在安全方案上，目前業(yè)界主流還是集中對云虛擬主機、云應(yīng)用以及云系統(tǒng)網(wǎng)絡(luò)進行安全防護，如防病毒工具、異常行為檢測、網(wǎng)絡(luò)訪問隔離、數(shù)據(jù)庫審計、防火墻、虛擬WAF等。整個思路與體系的構(gòu)建仍然沒有脫離基于先驗知識的傳統(tǒng)被動式防御，難以檢測和防御云平臺自身的未知漏洞和攻擊，例如，攻擊者利用云平臺本身的堆棧溢出、格式化字符串漏洞等繞過檢測和審計，釋放后再運用混淆、提權(quán)、API誤用等劫持軟件等執(zhí)行流程導(dǎo)致云計算環(huán)境被劫持或者信息泄露。而相較于傳統(tǒng)信息系統(tǒng)，云數(shù)據(jù)中心的新型服務(wù)模式更加容易遭受內(nèi)生安全威脅的影響。一方面，云服務(wù)實例的單一同質(zhì)性使得系統(tǒng)平臺更容易受到攻擊；另一方面，云上數(shù)據(jù)和計算資源集中管理會導(dǎo)致攻擊目標(biāo)集中，信息跨域傳遞也會導(dǎo)致攻擊目標(biāo)的加速暴露；技術(shù)耦合度高、集成軟件繁多也使得系統(tǒng)受攻擊面更廣，傳統(tǒng)防護方法更加難以生效。

以此來看，當(dāng)前云數(shù)據(jù)中心安全手段很難全面應(yīng)對系統(tǒng)的內(nèi)生安全問題，需要研究者另辟蹊徑，借助內(nèi)生安全的體制機制及方法改造自身架構(gòu)，發(fā)揮內(nèi)源安全功能效應(yīng)破解當(dāng)前問題。

3 云數(shù)據(jù)中心內(nèi)生安全架構(gòu)與關(guān)鍵技術(shù)

近年來，內(nèi)生安全理論得到了逐漸完善與廣泛應(yīng)用，其核心解決方法——擬態(tài)防御的有效性已經(jīng)得到了充分驗證。對于以漏洞、后門為代表的內(nèi)生安全問題，擬態(tài)防御通過動態(tài)異構(gòu)冗余（dynamic heterogeneous redundancy，DHR）構(gòu)造對系統(tǒng)結(jié)構(gòu)進行內(nèi)源性安全賦能[11]。首先，基于多樣性構(gòu)建異構(gòu)冗余的執(zhí)行空間，各執(zhí)行空間相互獨立承載完整的目標(biāo)對象功能，作為擬態(tài)架構(gòu)的基礎(chǔ)條件。即使單一空間存在協(xié)議邏輯實現(xiàn)的漏洞后門，也難以干擾其他異構(gòu)空間的正常運行；然后，利用分發(fā)－裁決機制對各個執(zhí)行空間的運行處理結(jié)果進行判定，輸出邏輯一致的處理結(jié)果，屏蔽和感知邏輯非一致結(jié)果；最后，利用反饋與動態(tài)調(diào)度機制對感知到的異常進行處理，從而規(guī)避攻擊和清洗還原系統(tǒng)，達到安全防御的效果。與傳統(tǒng)安全手段相比，擬態(tài)架構(gòu)并沒有增添知識庫、檢測機等外掛式的防護環(huán)節(jié)，而是通過對系統(tǒng)自身的內(nèi)在架構(gòu)改造使其具備了抵御漏洞、后門的安全功能，因此為云數(shù)據(jù)中心的內(nèi)生安全問題提供了有效解決思路。

3.1 云數(shù)據(jù)中心內(nèi)生安全架構(gòu)

基于擬態(tài)防御DHR架構(gòu)可以對云數(shù)據(jù)中心進行擬態(tài)構(gòu)造設(shè)計，內(nèi)生安全邏輯架構(gòu)如圖2所示，從邏輯上分為以下幾個部分。

基礎(chǔ)設(shè)施層：包括多種異構(gòu)的物理服務(wù)器（x86和ARM或其他架構(gòu)），形成計算虛擬資源池，為上層擬態(tài)SaaS應(yīng)用提供異構(gòu)容器資源，擬態(tài)存儲為SaaS應(yīng)用提供安全的存儲服務(wù)，基礎(chǔ)設(shè)施層接受擬態(tài)云管理器的管理和調(diào)度，在不同節(jié)點上創(chuàng)建擬態(tài)SaaS應(yīng)用執(zhí)行體。

圖2 云數(shù)據(jù)中心內(nèi)生安全邏輯架構(gòu)

異構(gòu)網(wǎng)絡(luò)交換層：作為通信層主要負責(zé)不同層次間的通信，包括外部網(wǎng)絡(luò)、業(yè)務(wù)網(wǎng)絡(luò)和管理網(wǎng)絡(luò)，負責(zé)不同系統(tǒng)的連接，其中外部用戶通過外部網(wǎng)絡(luò)訪問代理服務(wù)，擬態(tài)括號系統(tǒng)中的代理通過業(yè)務(wù)網(wǎng)絡(luò)訪問SaaS應(yīng)用，擬態(tài)括號系統(tǒng)中的裁決器通過業(yè)務(wù)網(wǎng)絡(luò)接收位于基礎(chǔ)設(shè)施不同節(jié)點上的不同SaaS應(yīng)用執(zhí)行體的響應(yīng)。管理網(wǎng)絡(luò)負責(zé)基礎(chǔ)設(shè)施間的互聯(lián)，管理員通過管理網(wǎng)絡(luò)基于擬態(tài)云管理器管理底層資源池，并對其他組件進行運維管理，同時管理網(wǎng)絡(luò)負責(zé)擬態(tài)括號系統(tǒng)和擬態(tài)云管理器的互連互通。

擬態(tài)云管理層：提供擬態(tài)化的云管理系統(tǒng)，包括代理（轉(zhuǎn)發(fā)資源調(diào)度等云操作管理方面的請求）、多個異構(gòu)云管理系統(tǒng)和裁決器（裁決不同云管理系統(tǒng)對請求的處理結(jié)果（含配置信息），發(fā)送至基礎(chǔ)設(shè)施進行實際部署），對底層資源進行管理，接受管理員及租戶的請求創(chuàng)建擬態(tài)化SaaS應(yīng)用，并對其進行生命周期管理。同時，其中的反饋控制模塊根據(jù)運行情況決策實現(xiàn)對在線容器執(zhí)行體的策略性動態(tài)輪換控制。

SaaS應(yīng)用層：基于生成的擬態(tài)化SaaS應(yīng)用容器對外提供SaaS服務(wù)，包括代理、執(zhí)行體和裁決器，執(zhí)行體由底層不同區(qū)域的容器承載、代理和裁決器根據(jù)應(yīng)用類型的不同分別設(shè)計與實現(xiàn)，同時為了增強其安全性，可以將代理和裁決器單獨實現(xiàn)，如硬件形式或基于專門的服務(wù)器設(shè)計實現(xiàn)，不在底層虛擬化資源池中承載，通過業(yè)務(wù)網(wǎng)絡(luò)對外提供服務(wù)。

運維管理層：基于管理網(wǎng)絡(luò)進行運維用戶管理（非SaaS用戶），進行各設(shè)備的配置管理，負責(zé)處理擬態(tài)化SaaS應(yīng)用的部署請求并通過調(diào)用擬態(tài)云管理器的API實現(xiàn)在不同節(jié)點上的異構(gòu)多樣化部署，監(jiān)控系統(tǒng)各模塊的整體運行情況，進行整體的態(tài)勢感知展示，包括擬態(tài)SaaS應(yīng)用的運行展示，此外，運維管理還需要將監(jiān)控分析結(jié)果反饋至擬態(tài)云管理器中的反饋控制模塊輔助決策。

云數(shù)據(jù)中心內(nèi)生安全架構(gòu)通過各個層次的聯(lián)動工作，實現(xiàn)整個云數(shù)據(jù)中心業(yè)務(wù)應(yīng)用的擬態(tài)化工作流程，從而產(chǎn)業(yè)內(nèi)生性的安全效應(yīng)。同時，還引入了擬態(tài)存儲、擬態(tài)云管、異構(gòu)化網(wǎng)絡(luò)交換等具有內(nèi)生安全功能的系統(tǒng)組件，保證了其核心環(huán)節(jié)的安全性與可靠性。

3.2 云數(shù)據(jù)中心內(nèi)生安全關(guān)鍵技術(shù)

云數(shù)據(jù)中心內(nèi)生安全架構(gòu)的設(shè)計提供了系統(tǒng)構(gòu)建的骨架，然而想要整個云系統(tǒng)最終做到正常運轉(zhuǎn)，則需要進一步研究云數(shù)據(jù)中心內(nèi)生安全的具體實現(xiàn)。尤其是結(jié)合云計算業(yè)務(wù)處理的多樣化、靈活遷移等特點，形成適用于其應(yīng)用場景的關(guān)鍵技術(shù)。本文著重選取擬態(tài)表決、業(yè)務(wù)遷移、數(shù)據(jù)同步3個重要處理環(huán)節(jié)，探討云數(shù)據(jù)中心內(nèi)生安全的關(guān)鍵技術(shù)實現(xiàn)。

3.2.1 擬態(tài)表決技術(shù)

由于云平臺上的業(yè)務(wù)多樣性，其正常的邏輯結(jié)果也通常會表現(xiàn)出不一致特點，決定了針對云主機難以基于結(jié)果進行表決。這里給出一種基于過程結(jié)果的擬態(tài)表決方法，通過對過程性結(jié)果進行取證分析，再配合基于負反饋機制對異常執(zhí)行體實施自愈修復(fù)操作。

方法的核心思路是指擬態(tài)系統(tǒng)需要對執(zhí)行體“過程數(shù)據(jù)和過程要素資源”進行監(jiān)控，通過表決發(fā)現(xiàn)被攻擊的執(zhí)行體。其中，“過程數(shù)據(jù)”包括執(zhí)行體的進程狀態(tài)數(shù)據(jù)、內(nèi)存數(shù)據(jù)、網(wǎng)絡(luò)狀態(tài)數(shù)據(jù)、注冊表狀態(tài)數(shù)據(jù)等運行過程中的實時狀態(tài)數(shù)據(jù)；“過程要素資源”包括執(zhí)行體的可執(zhí)行文件、配置文件、日志文件等運行過程中的相關(guān)文件。在表決的過程中，具體的過程數(shù)據(jù)和過程要素資源需要構(gòu)建適合應(yīng)用場景的集合。在執(zhí)行體正常運行時，通過實時對比過程結(jié)果內(nèi)容，判斷該執(zhí)行體是否被攻擊。基于過程要素的多維度表決方法可以擴大擬態(tài)表決的范圍，實時進行擬態(tài)表決，更加高效地發(fā)現(xiàn)異常執(zhí)行體。

圖3為基于過程結(jié)果的擬態(tài)表決示意圖，主要包括云集群、虛擬云主機和表決器。表決器通過對設(shè)定的“過程要素”進行擬態(tài)表決發(fā)現(xiàn)異常運行的云主機。若發(fā)現(xiàn)存在異常，將進行云平臺的自愈修復(fù)流程。

圖3 擬態(tài)表決示意圖

圖4為擬態(tài)表決的算法流程?？刂破鞑呗孕缘匕l(fā)出表決指令，表決器依據(jù)特定的表決算法，對多維度內(nèi)容進行表決，若發(fā)現(xiàn)某執(zhí)行體出現(xiàn)異常，將首先完成云上虛擬云主機的數(shù)據(jù)同步和業(yè)務(wù)遷移，隨后完成異常云主機的下線和自愈修復(fù)操作。

圖4 基于過程結(jié)果的擬態(tài)表決流程

3.2.2 業(yè)務(wù)遷移技術(shù)

由于擬態(tài)架構(gòu)需要對異常的執(zhí)行空間進行修復(fù)，因此需要良好的業(yè)務(wù)遷移技術(shù)支持。業(yè)務(wù)遷移的核心是實現(xiàn)虛擬云主機間在異構(gòu)云之間的遷移，同時還要保持業(yè)務(wù)不中斷，這里給出一種基于緩沖池技術(shù)，在跨平臺異構(gòu)云間實現(xiàn)業(yè)務(wù)平滑遷移。

圖5 業(yè)務(wù)遷移示意圖

業(yè)務(wù)遷移示意圖如圖5所示，業(yè)務(wù)數(shù)據(jù)經(jīng)過高級消息隊列協(xié)議（advanced message queuing protocol，AMQP）緩沖池到達分發(fā)器，分發(fā)器依據(jù)當(dāng)前策略對業(yè)務(wù)數(shù)據(jù)流進行定向轉(zhuǎn)發(fā)。為提高系統(tǒng)的運行效率，流入數(shù)據(jù)必須經(jīng)過緩沖池，而流出數(shù)據(jù)可不經(jīng)過緩沖池。同時，在云發(fā)生異常時，由分發(fā)器完成數(shù)據(jù)鏈路由1切換到2。

虛擬云主機業(yè)務(wù)遷移流程如圖6所示，用戶請求通過高級消息隊列協(xié)議（AMQP）經(jīng)由分發(fā)器發(fā)送到某臺虛擬云主機，對過程數(shù)據(jù)和要素資源組合內(nèi)容進行表決。若當(dāng)前虛擬云主機出現(xiàn)異常，則遷移整個過程數(shù)據(jù)和業(yè)務(wù)，并將業(yè)務(wù)平滑遷移至異構(gòu)虛擬云主機。同時，異常虛擬云主機下線自愈。

圖6 虛擬云主機業(yè)務(wù)遷移流程

虛擬云主機切換的流程如圖7所示，當(dāng)在線虛擬云主機所在的執(zhí)行空間出現(xiàn)異常時，控制器發(fā)出虛擬云主機切換命令。若當(dāng)前異構(gòu)云集群中存在可用的虛擬云主機，則將業(yè)務(wù)數(shù)據(jù)及業(yè)務(wù)遷移至虛擬云主機，原虛擬云主機下線自愈修復(fù)。

圖7 虛擬云主機切換流程

3.2.3 數(shù)據(jù)同步技術(shù)

為了更好地恢復(fù)補充擬態(tài)架構(gòu)中的異構(gòu)資源池，需要將異常的執(zhí)行空間進行數(shù)據(jù)同步恢復(fù)，保證其進行正常的工作狀態(tài)。虛擬云主機的數(shù)據(jù)實時同步可以通過多種方式實現(xiàn)，大致分為靜態(tài)遷移（或稱冷遷移）和動態(tài)遷移（或稱熱遷移）。冷遷移因為需要虛擬云主機在關(guān)機或暫停的情況下從一朵云遷移到另一朵云中。所以，從用戶角度看有一段明確的服務(wù)停止時間。異構(gòu)云平臺所支持的靜態(tài)文件格式對比見表1。對比可知，在當(dāng)前業(yè)界對于鏡像文件，在多種異構(gòu)云管理平臺下，都進行了很好的兼容性支持，為冷遷移提供了技術(shù)支撐。同時，為了提升遷移效率，業(yè)界普遍采用普通快照加增量快照的方式完成鏡像文件的生成。

表1 云平臺所支持的鏡像文件對比

而對于一個業(yè)務(wù)服務(wù)系統(tǒng)來說，熱遷移是擬態(tài)架構(gòu)實現(xiàn)中更加值得關(guān)注的研究點。熱遷移是在虛擬云主機不停機的情況下完成的，將一個虛擬云主機從一朵云遷移到另一朵云。

目前熱遷移有共享存儲的動態(tài)遷移和本地存儲的動態(tài)遷移兩種方案。以共享存儲為例，大多數(shù)虛擬化軟件如KVM和XEN都支持共享存儲，如NFS（網(wǎng)絡(luò)文件系統(tǒng)）。那么，即可利用NFS在虛擬云主機間共享數(shù)據(jù)，動態(tài)遷移時直接將虛擬機鏡像遷移到其他云中相同的目錄結(jié)構(gòu)處放置即可。虛擬云主機同步的模塊示意圖如圖8所示。

圖8 虛擬云主機同步的模塊示意圖

在利用網(wǎng)絡(luò)傳輸解決動態(tài)同步問題時，所有虛擬云主機間建立TCP連接，通過網(wǎng)絡(luò)傳輸或者刪除文件。由于虛擬云主機數(shù)據(jù)同步的時效性要求，各物理設(shè)備間的網(wǎng)絡(luò)連接帶寬要盡量得到保證。

基于共享存儲的實時遷移內(nèi)容如圖9所示，當(dāng)一臺虛擬云主機需要進行數(shù)據(jù)同步時，首先將動態(tài)過程數(shù)據(jù)和靜態(tài)要素資源進行文件化處理；處理后的文件存放在擬態(tài)存儲服務(wù)器中；最后，在異構(gòu)云上的虛擬云主機利用共享文件進行還原。為了確保文件的安全，可以引入擬態(tài)存儲系統(tǒng)放置共享文件數(shù)據(jù)。

熱遷移下實現(xiàn)動態(tài)數(shù)據(jù)同步的過程如圖10所示。首先，控制器發(fā)出數(shù)據(jù)遷移的命令開始數(shù)據(jù)動態(tài)遷移，動態(tài)數(shù)據(jù)遷移器從源虛擬云主機中取出相關(guān)數(shù)據(jù)形成文件；然后，將數(shù)據(jù)傳入目標(biāo)虛擬云主機；最后，源虛擬云主機完成下線自愈操作。其中，目標(biāo)虛擬云主機在完成數(shù)據(jù)輸入前需要無業(yè)務(wù)在線運行。

4 云數(shù)據(jù)中心擬態(tài)化改造模式與未來趨勢

基于前文所述的云數(shù)據(jù)中心架構(gòu)與關(guān)鍵技術(shù)，未來云數(shù)據(jù)中心擬態(tài)化改造中可能存在3種模式。

圖9 基于共享存儲的實時遷移內(nèi)容

圖10 動態(tài)數(shù)據(jù)同步流程

模式1：對信息技術(shù)產(chǎn)品處理流程的關(guān)鍵部位或模塊進行異構(gòu)化處理，設(shè)置擬態(tài)括號及配置相關(guān)的軟/硬資源，從而盡可能減少功能性能、成本等方面的開銷，如圖11所示。

圖11 面向關(guān)鍵部位或模塊的升級改造模式

適用場景：對系統(tǒng)關(guān)鍵部位或模塊進行局部的擬態(tài)化改造需要清楚該部分的功能邏輯與接口，因此該模式比較適合于代碼可控的自有產(chǎn)品，比如云計算開源社區(qū)發(fā)布的各類軟件。

模式2：針對某種應(yīng)用技術(shù)產(chǎn)品的功能性能以及技術(shù)架構(gòu)，在核心部位設(shè)置擬態(tài)輸入和裁決部件，并直接配置相應(yīng)的COTS級軟/硬構(gòu)件構(gòu)成擬態(tài)化子系統(tǒng)，如圖12所示。

圖12 面向完整軟硬中間件的集成開發(fā)模式

適用場景：在更多的情況下，云應(yīng)用的業(yè)務(wù)提供商并不希望公開自己的代碼，對此可以采取模式2直接將第三方產(chǎn)品作為獨立的執(zhí)行體集成到擬態(tài)化系統(tǒng)中。

模式3：直接面向業(yè)務(wù)協(xié)議進行擬態(tài)化改造，在目標(biāo)服務(wù)應(yīng)用的輸入/輸出接口增加分發(fā)、裁決及反饋調(diào)度等機制即可，如圖13所示。

圖13 面向業(yè)務(wù)協(xié)議的升級改造模式

適用場景：在云數(shù)據(jù)中心環(huán)境下為了保證可靠性和可用性，在管理或應(yīng)用業(yè)務(wù)中類似資源分配、數(shù)據(jù)存儲等環(huán)節(jié)都具有分布、冗余、動態(tài)的特性時，則適合使用該模式進行改造。

對于云技術(shù)內(nèi)生安全的發(fā)展而言，未來趨勢大致包括3點。

首先，加快云數(shù)據(jù)中心內(nèi)生安全基礎(chǔ)軟/硬件研發(fā)?，F(xiàn)有擬態(tài)設(shè)備大多以COTS級軟硬件直接作為多樣化的異構(gòu)執(zhí)行體，未能深入模塊或流程級開展擬態(tài)化改造。對于云數(shù)據(jù)中心而言，其更大的場景規(guī)模和更高的應(yīng)用需求都決定了必須開展內(nèi)生安全設(shè)計語言、工具鏈、工具庫等研發(fā)，從而增強云業(yè)務(wù)系統(tǒng)與內(nèi)生安全組件的耦合度，才能更好地釋放內(nèi)生安全效應(yīng)。

第二，進一步完善關(guān)鍵基礎(chǔ)組件的研發(fā)。內(nèi)生安全云數(shù)據(jù)中心除了對云業(yè)務(wù)本身的擬態(tài)化改造研究，還需要安全可信的存儲系統(tǒng)、網(wǎng)絡(luò)設(shè)備設(shè)施、云管平臺等各種系統(tǒng)組件的支撐。因此，需要同步突破云管平臺、云組件、分布式存儲系統(tǒng)等關(guān)鍵環(huán)節(jié)的內(nèi)生安全技術(shù)攻關(guān)，才能更好地支持推動內(nèi)生安全云數(shù)據(jù)中心的新一代信息基礎(chǔ)設(shè)施建設(shè)。

最后，面向云數(shù)據(jù)中心構(gòu)建開源開放的內(nèi)生安全技術(shù)研發(fā)、測試、評估等生態(tài)鏈。一方面能夠更好地豐富軟硬生態(tài)的多樣化發(fā)展，為內(nèi)生安全技術(shù)研究與實現(xiàn)提供基礎(chǔ)環(huán)境；另一方面，也能更好地推動內(nèi)生安全云數(shù)據(jù)中心的落地與良性迭代發(fā)展，促進系統(tǒng)與核心技術(shù)的實用性提升。

5 結(jié)束語

當(dāng)前，云系統(tǒng)安全與應(yīng)用安全已經(jīng)成為了備受關(guān)注的焦點問題。本文從近年來頻繁曝光的云系統(tǒng)漏洞及安全事件出發(fā)，著重分析和探討了其內(nèi)生安全問題及威脅根源；然后，結(jié)合最新的內(nèi)生安全理論與技術(shù)思路，給出了一種典型的云安全架構(gòu)及其相關(guān)技術(shù)內(nèi)容，闡述了內(nèi)生安全的生效機理與過程；進一步地，對后續(xù)內(nèi)生安全技術(shù)發(fā)展與云內(nèi)生安全未來趨勢進行了分析闡述。

未來，云安全領(lǐng)域的從業(yè)者和研究者應(yīng)著眼于網(wǎng)絡(luò)安全技術(shù)研發(fā)從“外掛式”向“內(nèi)生性”轉(zhuǎn)變的技術(shù)變革，才能更好地推進“新基建”信息技術(shù)產(chǎn)業(yè)升級演進，催生網(wǎng)絡(luò)信息服務(wù)與應(yīng)用發(fā)展新業(yè)態(tài)。而其中，基于內(nèi)生安全的新型云服務(wù)模式或?qū)⒊蔀椤靶禄?新安全”“雙輪驅(qū)動”的應(yīng)用發(fā)展機遇，研發(fā)內(nèi)生安全云系統(tǒng)平臺，構(gòu)建內(nèi)生安全云應(yīng)用服務(wù)生態(tài)等，將是筑牢云技術(shù)產(chǎn)業(yè)的發(fā)展基礎(chǔ)，是助力我國數(shù)字經(jīng)濟繁榮發(fā)展的重要方向。