基于擬態架構的內生安全云數據中心關鍵技術和實現方法

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

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

1 引言

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

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

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

2 云數據中心內生安全分析

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

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

圖1 攻擊鏈路示意圖

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

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

以此來看，當前云數據中心安全手段很難全面應對系統的內生安全問題，需要研究者另辟蹊徑，借助內生安全的體制機制及方法改造自身架構，發揮內源安全功能效應破解當前問題。

3 云數據中心內生安全架構與關鍵技術

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

3.1 云數據中心內生安全架構

基于擬態防御DHR架構可以對云數據中心進行擬態構造設計，內生安全邏輯架構如圖2所示，從邏輯上分為以下幾個部分。

基礎設施層：包括多種異構的物理服務器（x86和ARM或其他架構），形成計算虛擬資源池，為上層擬態SaaS應用提供異構容器資源，擬態存儲為SaaS應用提供安全的存儲服務，基礎設施層接受擬態云管理器的管理和調度，在不同節點上創建擬態SaaS應用執行體。

圖2 云數據中心內生安全邏輯架構

異構網絡交換層：作為通信層主要負責不同層次間的通信，包括外部網絡、業務網絡和管理網絡，負責不同系統的連接，其中外部用戶通過外部網絡訪問代理服務，擬態括號系統中的代理通過業務網絡訪問SaaS應用，擬態括號系統中的裁決器通過業務網絡接收位于基礎設施不同節點上的不同SaaS應用執行體的響應。管理網絡負責基礎設施間的互聯，管理員通過管理網絡基于擬態云管理器管理底層資源池，并對其他組件進行運維管理，同時管理網絡負責擬態括號系統和擬態云管理器的互連互通。

擬態云管理層：提供擬態化的云管理系統，包括代理（轉發資源調度等云操作管理方面的請求）、多個異構云管理系統和裁決器（裁決不同云管理系統對請求的處理結果（含配置信息），發送至基礎設施進行實際部署），對底層資源進行管理，接受管理員及租戶的請求創建擬態化SaaS應用，并對其進行生命周期管理。同時，其中的反饋控制模塊根據運行情況決策實現對在線容器執行體的策略性動態輪換控制。

SaaS應用層：基于生成的擬態化SaaS應用容器對外提供SaaS服務，包括代理、執行體和裁決器，執行體由底層不同區域的容器承載、代理和裁決器根據應用類型的不同分別設計與實現，同時為了增強其安全性，可以將代理和裁決器單獨實現，如硬件形式或基于專門的服務器設計實現，不在底層虛擬化資源池中承載，通過業務網絡對外提供服務。

運維管理層：基于管理網絡進行運維用戶管理（非SaaS用戶），進行各設備的配置管理，負責處理擬態化SaaS應用的部署請求并通過調用擬態云管理器的API實現在不同節點上的異構多樣化部署，監控系統各模塊的整體運行情況，進行整體的態勢感知展示，包括擬態SaaS應用的運行展示，此外，運維管理還需要將監控分析結果反饋至擬態云管理器中的反饋控制模塊輔助決策。

云數據中心內生安全架構通過各個層次的聯動工作，實現整個云數據中心業務應用的擬態化工作流程，從而產業內生性的安全效應。同時，還引入了擬態存儲、擬態云管、異構化網絡交換等具有內生安全功能的系統組件，保證了其核心環節的安全性與可靠性。

3.2 云數據中心內生安全關鍵技術

云數據中心內生安全架構的設計提供了系統構建的骨架，然而想要整個云系統最終做到正常運轉，則需要進一步研究云數據中心內生安全的具體實現。尤其是結合云計算業務處理的多樣化、靈活遷移等特點，形成適用于其應用場景的關鍵技術。本文著重選取擬態表決、業務遷移、數據同步3個重要處理環節，探討云數據中心內生安全的關鍵技術實現。

3.2.1 擬態表決技術

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

方法的核心思路是指擬態系統需要對執行體“過程數據和過程要素資源”進行監控，通過表決發現被攻擊的執行體。其中，“過程數據”包括執行體的進程狀態數據、內存數據、網絡狀態數據、注冊表狀態數據等運行過程中的實時狀態數據；“過程要素資源”包括執行體的可執行文件、配置文件、日志文件等運行過程中的相關文件。在表決的過程中，具體的過程數據和過程要素資源需要構建適合應用場景的集合。在執行體正常運行時，通過實時對比過程結果內容，判斷該執行體是否被攻擊。基于過程要素的多維度表決方法可以擴大擬態表決的范圍，實時進行擬態表決，更加高效地發現異常執行體。

圖3為基于過程結果的擬態表決示意圖，主要包括云集群、虛擬云主機和表決器。表決器通過對設定的“過程要素”進行擬態表決發現異常運行的云主機。若發現存在異常，將進行云平臺的自愈修復流程。

圖3 擬態表決示意圖

圖4為擬態表決的算法流程。控制器策略性地發出表決指令，表決器依據特定的表決算法，對多維度內容進行表決，若發現某執行體出現異常，將首先完成云上虛擬云主機的數據同步和業務遷移，隨后完成異常云主機的下線和自愈修復操作。

圖4 基于過程結果的擬態表決流程

3.2.2 業務遷移技術

由于擬態架構需要對異常的執行空間進行修復，因此需要良好的業務遷移技術支持。業務遷移的核心是實現虛擬云主機間在異構云之間的遷移，同時還要保持業務不中斷，這里給出一種基于緩沖池技術，在跨平臺異構云間實現業務平滑遷移。

圖5 業務遷移示意圖

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

虛擬云主機業務遷移流程如圖6所示，用戶請求通過高級消息隊列協議（AMQP）經由分發器發送到某臺虛擬云主機，對過程數據和要素資源組合內容進行表決。若當前虛擬云主機出現異常，則遷移整個過程數據和業務，并將業務平滑遷移至異構虛擬云主機。同時，異常虛擬云主機下線自愈。

圖6 虛擬云主機業務遷移流程

虛擬云主機切換的流程如圖7所示，當在線虛擬云主機所在的執行空間出現異常時，控制器發出虛擬云主機切換命令。若當前異構云集群中存在可用的虛擬云主機，則將業務數據及業務遷移至虛擬云主機，原虛擬云主機下線自愈修復。

圖7 虛擬云主機切換流程

3.2.3 數據同步技術

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

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

而對于一個業務服務系統來說，熱遷移是擬態架構實現中更加值得關注的研究點。熱遷移是在虛擬云主機不停機的情況下完成的，將一個虛擬云主機從一朵云遷移到另一朵云。

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

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

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

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

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

4 云數據中心擬態化改造模式與未來趨勢

基于前文所述的云數據中心架構與關鍵技術，未來云數據中心擬態化改造中可能存在3種模式。

圖9 基于共享存儲的實時遷移內容

圖10 動態數據同步流程

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

圖11 面向關鍵部位或模塊的升級改造模式

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

模式2：針對某種應用技術產品的功能性能以及技術架構，在核心部位設置擬態輸入和裁決部件，并直接配置相應的COTS級軟/硬構件構成擬態化子系統，如圖12所示。

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

適用場景：在更多的情況下，云應用的業務提供商并不希望公開自己的代碼，對此可以采取模式2直接將第三方產品作為獨立的執行體集成到擬態化系統中。

模式3：直接面向業務協議進行擬態化改造，在目標服務應用的輸入/輸出接口增加分發、裁決及反饋調度等機制即可，如圖13所示。

圖13 面向業務協議的升級改造模式

適用場景：在云數據中心環境下為了保證可靠性和可用性，在管理或應用業務中類似資源分配、數據存儲等環節都具有分布、冗余、動態的特性時，則適合使用該模式進行改造。

對于云技術內生安全的發展而言，未來趨勢大致包括3點。

首先，加快云數據中心內生安全基礎軟/硬件研發。現有擬態設備大多以COTS級軟硬件直接作為多樣化的異構執行體，未能深入模塊或流程級開展擬態化改造。對于云數據中心而言，其更大的場景規模和更高的應用需求都決定了必須開展內生安全設計語言、工具鏈、工具庫等研發，從而增強云業務系統與內生安全組件的耦合度，才能更好地釋放內生安全效應。

第二，進一步完善關鍵基礎組件的研發。內生安全云數據中心除了對云業務本身的擬態化改造研究，還需要安全可信的存儲系統、網絡設備設施、云管平臺等各種系統組件的支撐。因此，需要同步突破云管平臺、云組件、分布式存儲系統等關鍵環節的內生安全技術攻關，才能更好地支持推動內生安全云數據中心的新一代信息基礎設施建設。

最后，面向云數據中心構建開源開放的內生安全技術研發、測試、評估等生態鏈。一方面能夠更好地豐富軟硬生態的多樣化發展，為內生安全技術研究與實現提供基礎環境；另一方面，也能更好地推動內生安全云數據中心的落地與良性迭代發展，促進系統與核心技術的實用性提升。

5 結束語

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

未來，云安全領域的從業者和研究者應著眼于網絡安全技術研發從“外掛式”向“內生性”轉變的技術變革，才能更好地推進“新基建”信息技術產業升級演進，催生網絡信息服務與應用發展新業態。而其中，基于內生安全的新型云服務模式或將成為“新基建+新安全”“雙輪驅動”的應用發展機遇，研發內生安全云系統平臺，構建內生安全云應用服務生態等，將是筑牢云技術產業的發展基礎，是助力我國數字經濟繁榮發展的重要方向。