基于Intel SGX的Ansible安全增強①

楊 驍,于佳耕,武延軍

1(中國科學院 軟件研究所 基礎(chǔ)軟件國家工程研究中心,北京 100190)2(中國科學院大學,北京 100049)

基于Intel SGX的Ansible安全增強①

楊 驍1,2,于佳耕1,武延軍1

1(中國科學院 軟件研究所 基礎(chǔ)軟件國家工程研究中心,北京 100190)2(中國科學院大學,北京 100049)

Ansible是當今最主流的云平臺自動化運維工具之一,通常擁有大量集群的管理員賬號信息來批量執(zhí)行運維任務(wù),這些賬號信息一般明文存儲在配置文件中.但在云計算環(huán)境中這種機制具有較大的安全隱患,因為Ansible的配置信息的機密性和完整性依賴云服務(wù)廠商提供的基礎(chǔ)軟件的安全性.因此,加強Ansible配置信息管理機制的安全性至關(guān)重要.本文基于Intel近年推出的安全機制 SGX(Software Guard eXtensions)開發(fā)了Ansible的配置管理模塊,它可以獨立地在可信的執(zhí)行環(huán)境(Trusted Execution Environment,TEE)內(nèi)管理Ansible的配置信息,從而保證了Ansible配置信息不被外界讀取和修改,同時其安全性不再依賴于底層基礎(chǔ)軟件.實驗評估顯示,本文方案更加安全可靠,性能的額外開銷也在接受范圍之內(nèi),而且可以進一步擴展成通用的配置管理組件集成到OpenStack等云平臺中.

Intel SGX; 云計算; 安全; 運維; Ansible

自動化運維工具在現(xiàn)在的云平臺上使用非常廣泛,它大大方便了用戶對服務(wù)器集群的管理和配置,降低了集群的運維成本.主流的自動化運維工具有Ansible[1]、Puppet、Chef等等,其中Ansible誕生較晚,但是目前看來最為活躍,市場占有率持續(xù)增長,很有潛力成為日后最為主流的自動化運維工具.

Ansible管理著服務(wù)器集群的登錄信息,這些信息都會被保存在Ansible的配置文件中.一旦Ansible的配置文件的信息被泄露,相應(yīng)的集群中服務(wù)器的管理權(quán)限也將被竊取,所以對Ansible的配置信息的保護至關(guān)重要.但是目前Ansible的配置信息一般是明文存儲在磁盤上,讀取磁盤的權(quán)限一旦被惡意程序獲取,將導致大量服務(wù)器的管員權(quán)限被竊取.針對這個問題,除了在磁盤上明文存儲配置信息之外,Ansible可以用其內(nèi)置的vault機制先將配置文件加密,再將加密后的信息存儲在磁盤,但是這需要用戶每次使用Ansible時都提供解密配置文件的密鑰,這將極大的降低Ansible本身的便捷性.除此之外,目前沒有其他方法來保護Ansbile的配置信息.其主要原因在于單純地依賴軟件來保護配置文件是不夠的.現(xiàn)有軟件層面的保護手段需要將一些龐大的底層模塊納入TCB(Trusted Computing Base),TCB過大將會降低系統(tǒng)的安全性,一旦TCB中的任何組件出現(xiàn)漏洞,就意味著其他程序的安全性無法保障.另一方面,如果攻擊者可以從物理上訪問設(shè)備,直接控制軟件本身,軟件是無法抵御的.而且從軟件層面是無法防御像內(nèi)存嗅探這種物理攻擊的.

因此,本文引入了Intel SGX[2-4]硬件保護機制,Intel SGX可以將Ansible的配置信息和相應(yīng)的關(guān)鍵代碼運行在加密內(nèi)存中,在程序運行的過程中,外部無法窺探加密內(nèi)存.當需要將配置信息持久化存儲時,程序會先在加密內(nèi)存中用外部無法獲知的密鑰先將配置信息加密后再寫入到磁盤.因此即使惡意程序獲取了整個磁盤和內(nèi)存的訪問權(quán)限,也無法竊取Ansible的配置信息.

本文工作的主要難點在于:1)對Intel SGX接口的更高層封裝; 2)設(shè)計和開發(fā)獨立的配置管理模塊與Ansible結(jié)合.雖然Intel SGX官方SDK已經(jīng)提供了一些較為底層的接口,但是使用它保護配置信息還需要根據(jù)需求進行相應(yīng)的設(shè)計和實現(xiàn),本文針對配置信息保護這一類需求開發(fā)了更便捷的接口.目前Intel SGX官方的SDK僅支持C和C++接口.本文實現(xiàn)的高層封裝支持python語言,基于此架構(gòu)添加對其他語言的支持也非常簡單.另一方面,Intel SGX官方SDK目前只支持將enclave以動態(tài)鏈接庫的形式加載到其他進程中,這樣導致在不同的進程之間共享enclave中的數(shù)據(jù)較為麻煩,而且和其他程序的集成代價較大.本文針對此問題設(shè)計和開發(fā)了獨立的配置管理模塊,它可以不依賴其他進程單獨地運行,支持多個進程同時訪問機密數(shù)據(jù),任何程序都可以通過web接口直接和配置管理模塊交互,這種方式大大降低了在原有程序內(nèi)集成Intel SGX來保護機密信息的難度.

1 相關(guān)工作

對應(yīng)用機密信息的保護一直是一個熱門的研究課題,其關(guān)鍵在于防止特權(quán)代碼對用戶機密信息的訪問.其研究方向主要分為基于軟件層面的保護和基于硬件層面的保護.

首先探討基于軟件層面的研究.微軟早期就提出了NGSCB[5],它在硬件之上使用了稱之為isolation kernel的隔離層,然后再在隔離層之上同時運行了可信和不可信的操作系統(tǒng),最終將需要保護的應(yīng)用運行在可信的操作系統(tǒng)中.它通過隔離層和另一個可信的操作系統(tǒng)阻止了來自不可信操作系統(tǒng)的訪問,但是其TCB包含了隔離層和可信的操作系統(tǒng),是較為龐大的.之后Richard Ta-Min等人提出的Proxos[6]基于xen實現(xiàn)了類似于NGSCB的相似機制,在不可信的系統(tǒng)運行的同時也運行另一個可信系統(tǒng)來保護目標應(yīng)用.之后Xiaoxin Chen等人提出的Overshadow[7]是基于VMware的VMM上實現(xiàn)了對指定的Guest OS的內(nèi)存的加密,從而防止其他的系統(tǒng)對該系統(tǒng)內(nèi)存的訪問.這些從軟件層面防護的方法都需要在操作系統(tǒng)下層有一個可信的虛擬化層,而且受保護的應(yīng)用所在的Guest OS也必須是可信的.這兩個組件本身就非常復雜,做到完全可信比較困難.而且如果攻擊者可以從物理上訪問系統(tǒng),一旦該虛擬層被控制或者攻擊者從物理上進行內(nèi)存嗅探,這些軟件保護措施都無法應(yīng)對.

由于僅依賴軟件層面保護應(yīng)用有一定的局限性,所以也出現(xiàn)了很多從硬件層面保護應(yīng)用的手段.除了本文將要使用的Intel SGX之外,當前最為主流的手段是TPM(trusted platform modules)[8]和ARM TrustZone[9].

TPM提供一些特定的功能來保證系統(tǒng)的安全性.Flicker[10]實現(xiàn)了基于TPM的安全模塊,但是因為TPM的性能問題,安全模式和非安全模式的切換會導致較高的性能開銷.針對TPM的性能問題,CloudVisor[11]為了避免頻繁使用TPM,它將整個hypervisor也包括在TCB中,而TPM主要負責hypervisor的啟動完整性校驗.顯然,這擴大了TCB.

ARM TrustZone主要應(yīng)用在移動設(shè)備應(yīng)用安全,它將整個系統(tǒng)分為普通區(qū)域和安全區(qū)域,然后從硬件上保障普通區(qū)域的組件無法訪問安全區(qū)域,將需要保護的代碼和數(shù)據(jù)運行在安全區(qū)域.因為TrustZone的安全區(qū)域只能有一個,所以它需要在安全區(qū)域內(nèi)運行單獨的可信的系統(tǒng)來進行管理,這部分系統(tǒng)是包含在TCB中的.

Intel SGX也是一種基于硬件的軟件防護機制.相比TPM,它的模式切換并不需要較大代價,所以它沒有TPM的性能問題,也不需要將hypervisor這種龐大的系統(tǒng)納入TCB.相比ARM TrustZone,它可以同時運行多個互不干擾的安全環(huán)境,每個安全環(huán)境僅僅包含應(yīng)用程序本身,不需要另外的可信系統(tǒng)進行單獨的管理.同時,Intel SGX還可以防御物理內(nèi)存嗅探,這一點是TPM和ARM TrustZone都無法做到的.所以本文采取Intel SGX技術(shù)對Ansible進行安全增強,避免了TPM和ARM TrustZone的上述缺陷.

2 技術(shù)背景

2.1 Ansible

Ansible是一個開源的跨平臺自動化運維工具,它的誕生時間相對于Puppet、Chef等等同類工具較晚,但是后來居上.在github上的star、fork和commit數(shù)量遠遠超過了其他同類工具,這說明它的社區(qū)活躍度非常高.根據(jù)OpenStack的2016年4月份的用戶調(diào)查[12],使用Ansible部署和配置OpenStack集群的用戶比例已經(jīng)和位于第一的Puppet相差在1%以內(nèi).而在去年同期,Ansible的用戶比例落后Puppet 14%左右.這說明Ansible在OpenStack的部署和配置方面的應(yīng)用非常廣泛,而且還在持續(xù)地增長.根據(jù)The New Stack的調(diào)查[13],Ansible在容器編排方面的應(yīng)用已經(jīng)遠遠超過了Puppet和Chef.

Ansible可以方便地管理Linux和Windows系統(tǒng).相比其他的自動化運維工具,Ansible的優(yōu)勢在于它的配置和部署簡單,它不需要在被管理的系統(tǒng)上安裝任何agent程序.只需要在Ansible的配置文件中設(shè)置好登錄信息,Ansible就可以根據(jù)這些信息登錄相應(yīng)的系統(tǒng)進行預設(shè)的管理操作.而Ansible的配置信息目前是明文地存儲在系統(tǒng)磁盤上的,一旦磁盤的訪問權(quán)限被攻擊者非法獲取,這將意味著這些機密信息將完全被攻擊者掌握,攻擊者將得到相應(yīng)的系統(tǒng)的管理權(quán)限,這將造成巨大的安全隱患.

Ansible針對配置文件中機密信息保護的問題提出了相應(yīng)功能,即Vault.Vault會根據(jù)用戶提供的密碼將配置文件加密,達到了配置文件中的機密信息不會明文出現(xiàn)在磁盤中的目的.但是這樣做也有很大的缺陷.首先,如果需要修改配置文件,那么必須對整個文件重新加密.其次,用戶每次讀取配置文件時,用戶需要提供解密配置文件的密碼.如果用戶每次使用Ansible都需要手動輸入密碼,其便捷性將大大降低; 如果用戶將加密配置信息的密碼保存成另外一個配置文件,這又會讓問題回到原點,這個存儲密碼的配置文件又明文出現(xiàn)在了磁盤上.本文將針對這個問題使用Intel SGX來加固Ansible的配置安全.

2.2 Intel SGX

SGX是Intel開發(fā)的新的處理器擴展指令集,全稱為Intel Software Guard Extensions,用于增強軟件安全性.SGX能將安全應(yīng)用依賴的TCB減小到僅包含CPU和安全應(yīng)用本身,將不可信的其他所有因素都排除在安全邊界之外.

SGX可以在計算平臺上提供一個可信的空間,將用戶軟件的安全操作封裝在一個enclave(飛地)中,保障用戶關(guān)鍵代碼和數(shù)據(jù)的機密性和完整性,甚至外部的特權(quán)軟件(比如操作系統(tǒng)或者Hypervisor)都無法訪問enclave中的代碼和數(shù)據(jù).Enclave的代碼和數(shù)據(jù)位于一段稱之為EPC(enclave page cache)的受保護的物理內(nèi)存中,內(nèi)置在CPU中的內(nèi)存加密引擎(memory encryption engine,MME)會在存取DRAM中的數(shù)據(jù)和指令時進行加密解密.

SGX提供了一套密鑰供給機制.在同一個處理器上,enclave中的程序可以生成一套和該enclave唯一對應(yīng)的密鑰.這個密鑰只有在同一個enclave中才能獲取和使用,整個過程對外界完全是加密的,而且其他的enclave中也無法獲取該密鑰.基于這套密鑰供給機制,SGX實現(xiàn)了密封機制.密封可以在enclave中的數(shù)據(jù)持久化存儲之前將其加密,同時保證這些加密數(shù)據(jù)只有在相同的enclave中能解密.Enclave首先獲取專屬于自己的密鑰,然后將enclave中的機密信息加密后導出到磁盤上持久保存.當enclave需要再次解密原來的數(shù)據(jù)時,只需要再次獲取專屬于自己的密鑰來解密數(shù)據(jù).因為其他任何程序都無法獲取該密鑰,所以可以保證這些信息的機密性.

3 系統(tǒng)整體架構(gòu)

Ansible默認把配置信息明文存儲在磁盤的配置文件中.顯然,這樣很容易造成Ansible的配置信息泄露,而且Ansible配置文件中的信息包含了其管理的系統(tǒng)的賬號密碼,泄露這些信息的危害非常大.因此必須將Ansible的配置信息保護起來.為了保護Ansible的配置信息,文本采取的方式是將Ansible的配置管理功能獨立成一個模塊,再基于Intel SGX對此模塊進行安全增強.

系統(tǒng)的整體架構(gòu)如圖1所示,整個系統(tǒng)主要包括Ansible、配置管理模塊和持久化存儲三個部分.配置管理模塊運行在支持Intel SGX的平臺上,它將配置信息和管理配置信息的關(guān)鍵代碼運行在enclave中,確保里面的數(shù)據(jù)和代碼的機密性和完整性.然后在enclave外層進行封裝,提供配置信息增刪改查的接口,Ansible只能通過這些接口來獲取配置信息.模塊的另一重要功能是持久化存儲配置信息.顯然,在將配置文件寫入到磁盤之前必須將數(shù)據(jù)加密.配置管理模塊會利用SGX的密封機制保證數(shù)據(jù)的機密性.

圖1 系統(tǒng)整體架構(gòu)圖

4 系統(tǒng)實現(xiàn)

4.1 設(shè)計配置管理模塊

配置管理模塊運行在開啟了Intel SGX功能的平臺上,它負責Ansible的配置信息的管理和存取,該模塊的關(guān)鍵代碼和相關(guān)數(shù)據(jù)運行在enclave中,Intel SGX技術(shù)保證了enclave中的內(nèi)容無法被外部非法窺探,用戶僅可以通過指定的API查詢和修改數(shù)據(jù).

配置管理模塊的設(shè)計如圖2.最底層的關(guān)鍵代碼使用C++編寫,這些代碼會被編譯成一個enclave.signed.so動態(tài)鏈接庫文件,運行時會以enclave的形式運行在加密內(nèi)存之中,只有CPU內(nèi)部能獲取解密后的數(shù)據(jù)和指令.Enclave.signed.so以邊界函數(shù)(Edge-routines)的形式對外部程序開放特定的接口,這些接口是enclave和外部程序唯一的交互方式.ECALLS表示外部程序通過邊界函數(shù)調(diào)用enclave內(nèi)部程序的接口; OCALLS代表enclave內(nèi)部程序通過邊界函數(shù)調(diào)用外部程序的接口.

因為ECALLS只能被C/C++代碼直接調(diào)用,為了讓各種語言編寫的程序都可以調(diào)用enclave的接口,sgxdb.so對ECALLS再次做了一層封裝,向上提供了能適配各種語言的純C的接口.

最外層的非核心業(yè)務(wù)邏輯和網(wǎng)絡(luò)通信功能使用python實現(xiàn).sgxdblib.py模塊對sgxdb.so提供的C接口做了進一步的python封裝,任何python程序都可以便捷地通過它來調(diào)用enclave提供的接口.最終配置管理模塊以Web接口的形式向外提供服務(wù).

圖2 配置管理模塊設(shè)計結(jié)構(gòu)圖

4.2 持久化存儲配置信息

程序的停止和重啟是任何應(yīng)用程序生命周期中必然會發(fā)生的環(huán)節(jié),配置管理模塊也不例外.配置管理模塊的配置信息存儲在enclave中,必須有相關(guān)的機制在程序停止前持久化存儲enclave中的狀態(tài)和數(shù)據(jù),并能夠在下次程序重啟時進行恢復.在模塊的運行過程中,enclave內(nèi)部的數(shù)據(jù)和代碼無法被外部任何程序窺探,所以對enclave內(nèi)狀態(tài)和數(shù)據(jù)的保存和恢復必須在enclave內(nèi)部完成.為了保證數(shù)據(jù)的機密性,最終保存在磁盤上的數(shù)據(jù)必須是進行過加密的,而且必須保證這些數(shù)據(jù)無法被任何第三方解密.

持久化存儲配置信息流程如圖3所示.當配置管理模塊需要將enclave中的狀態(tài)和數(shù)據(jù)持久化存儲時,需要獲得和當前enclave唯一對應(yīng)的密鑰,然后用該密鑰在enclave內(nèi)部將需要導出的數(shù)據(jù)加密,最終將加密后的信息導出到enclave外部的持久化存儲中.

首先,程序會在enclave內(nèi)部使用EGETKEY指令,該指令會收集能唯一標識該enclave的信息和嵌入在CPU內(nèi)部的SGX master Derivation Key這兩個數(shù)據(jù)作為AES-CMAC[14]算法的輸入,然后生成Provisioning Key.只要這兩個輸入的值確定,最后生成的Provisioning Key就是確定的.每個支持SGX的CPU都有唯一的SGX master Derivation Key,為了保證它的機密性,用戶僅僅可以在使用EGETKEY指令時讓CPU自動讀取它,但是無法直接獲取它的值.唯一標識該enclave的信息有兩種選擇,調(diào)用EGETKEY指令時可以選擇enclave的度量(enclave measurement)或者enclave的作者的身份信息(即enclave初始化時MRSIGNER寄存器中的值)來標識一個Enclave.如果使用的是enclave的度量信息作為AES-CMAC算法的輸入,下次相同代碼和初始數(shù)據(jù)的enclave才能生成相同的Provisioning Key; 如果使用enclave作者的信息,即使代碼和初始數(shù)據(jù)有不同,只要是相同的作者創(chuàng)建的enclave,也會生成相同的Provisioning Key.本文中使用enclave的度量作為標識信息.最終,用生成的Provisioning Key來加密enclave中的狀態(tài)和數(shù)據(jù),將加密的數(shù)據(jù)導出到持久化存儲中后,配置管理模塊就可以正常關(guān)閉了.

圖3 持久化存儲配置信息流程

當配置管理模塊再次啟動需要恢復之前的狀態(tài)和數(shù)據(jù)時,仍然用相同的方式調(diào)用EGETKEY.在同一個處理器上的相同的enclave可以保證SGX master Derivation Key和標識enclave本身的信息相同,從而可以得到相同的Provisioning Key.生成了相同的密鑰后,我們就可以再次在enclave中解密數(shù)據(jù)來恢復程序關(guān)閉之前的狀態(tài).

5 評估

5.1 安全增強評估

TCB是保障系統(tǒng)安全所需的軟硬件的集合,保持較小規(guī)模的TCB可以減少系統(tǒng)產(chǎn)生漏洞的概率.

本系統(tǒng)的TCB的軟件部分的代碼都包含在配置管理模塊中,其代碼近似行數(shù)(lines of code,LoC)見表1.移植到Enclave內(nèi)的C++標準庫占了代碼量的絕大比重,而且這一部分代碼量是較多的.Intel在SGX SDK中包含了C++標準庫的移植,在編譯階段整個C++標準庫會被靜態(tài)鏈接到最終生成的enclave.signed.so庫函數(shù)中.相比其他的庫函數(shù)和用戶自己編寫的代碼,C++標準庫函數(shù)經(jīng)過了大量使用和檢驗,其本身的可靠性較高,將它移植到Enclave中并不會對它的可靠性造成太大影響,所以這部分代碼是較為可靠的.其他包含在TCB中的代碼在4000行左右,總體來看,軟件規(guī)模是較小的,系統(tǒng)是相對安全可控的.

表1 代碼量統(tǒng)計

除了軟件部分,本系統(tǒng)還依賴于Intel SGX CPU的安全性.Intel SGX假設(shè)攻擊者可以控制包括操作系統(tǒng)在內(nèi)的所有軟件,對系統(tǒng)中傳輸?shù)娜魏螖?shù)據(jù)進行任意修改,對物理內(nèi)存進行任意讀取,但是無法從物理上破解帶有Intel SGX功能的CPU.只要符合該假設(shè),Intel SGX就可以保障enclave內(nèi)部數(shù)據(jù)和代碼的機密性和完整性.對于攻擊者來說,攻擊CPU硬件是極其困難的,而且Intel也做了相當多的工作來保障CPU的安全,因此硬件方面的可靠性是相當高的.

本系統(tǒng)主要關(guān)注配置管理模塊本身的安全性,當配置信息從配置管理模塊被取出后,其機密性不受本系統(tǒng)保障.但是Ansible取出配置信息后,其他仍在模塊內(nèi)的配置信息的機密性不受影響,而且這些取出的配置信息僅僅會短時間存在于內(nèi)存中.

5.2 性能評估

本節(jié)設(shè)計了實驗來評估加入配置管理模塊后對Ansible日常操作性能的影響.本文使用了戴爾Inspiron i7359筆記本電腦,CPU型號為Intel(R)Core(TM)i7-6500U CPU @ 2.50 GHz,內(nèi)存大小為8 G,操作系統(tǒng)版本為Ubuntu 14.04 LTS,本文選用的linux sgx driver的版本為1.7.配置管理模塊和Ansible都運行在Inspiron i7359上,被管理的服務(wù)器是一臺裝有Ubuntu 14.04 LTS的虛擬機,其CPU為2核,內(nèi)存大小為4 G.本文使用TP-LINK WR842N搭建局域網(wǎng)作為實驗網(wǎng)絡(luò)環(huán)境.

實驗中,Ansible執(zhí)行了服務(wù)器管理操作并對相應(yīng)操作計時.實驗根據(jù)Ansible是否使用配置管理模塊分為兩組,每組實驗執(zhí)行100次指定的操作,然后對比兩組實驗的每次操作平均其耗時.實驗中選用的操作一共包含三種:1)獲取根目錄下的文件列表; 2)安裝Nginx;3)重啟Mysql服務(wù).實驗將根據(jù)是否使用配置管理模塊對比這三種操作的平均耗時.因為一般程序首次啟動時間會比之后啟動時間稍長,為了避免這一不穩(wěn)定因素,每組實驗的最初的5次操作時間不會被計算到最終的操作平均耗時.

如果使用配置管理模塊,Ansible執(zhí)行服務(wù)器管理操作時,會先從配置管理模塊查詢相應(yīng)的服務(wù)器配置信息.否則,Ansible將直接從磁盤讀取配置信息.根據(jù)圖4的結(jié)果,從配置管理模塊讀取配置信息比直接從磁盤讀取配置信息平均耗時多179～227 ms,占總耗時的4%～13%.在保證安全性的條件下,這個性能損耗是可以接受的.根據(jù)配置管理模塊的統(tǒng)計,每次從配置管理模塊讀取配置信息的耗時大約在200 ms左右,其中執(zhí)行查詢操作時間消耗在1 ms左右,剩下的時間主要由網(wǎng)絡(luò)通訊和外部的web框架本身的開銷組成.因為執(zhí)行的查詢操作并非計算密集型,這部分耗時較少是符合預期的.如果仍然覺得配置管理模塊的開銷較大,可以直接將配置管理模塊以動態(tài)鏈接庫的方式嵌入在Ansible中來消除相應(yīng)的網(wǎng)絡(luò)開銷.這種方式雖然可以達到和原生Ansible一樣的性能,但是與將配置管理模塊以單獨的服務(wù)運行相比,它會增加系統(tǒng)的耦合性.

圖4 實驗平均耗時對比

6 總結(jié)與展望

本文對基于Intel SGX技術(shù)實現(xiàn)了對Ansible的配置信息的保護,相比原來Ansible直接將包含敏感信息的配置文件明文存儲在磁盤上,本文達到了配置文件在內(nèi)存和磁盤中都處于被加密狀態(tài)的目標,實現(xiàn)了對Ansible的安全增強.從實驗評估結(jié)果可以看到,本文提出的安全機制雖然會帶來一些額外性能開銷,但其性能損耗是可以接受的.本文配置管理模塊的代碼已經(jīng)開源[15].

本文目前僅僅是將配置管理的安全增強應(yīng)用在了Ansible中,但在未來還可以將其擴展成通用組件,作為通用的配置管理安全增強模塊集成到例如OpenStack等云平臺中.

1https://github.com/ansible/ansible.

2INTEL CORP.Intel?software guard extensions programming reference,Ref.#.329298-002US.https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf.[2014-10].

3INTEL CORP.Intel?software guard extensions (Intel?SGX),Reference Number:332680-002.https://software.intel.com/sites/default/files/332680-002.pdf.[2015-06].

4Costan V,Devadas S.Intel sgx explained.Cryptology ePrint archive:Report 2016/086.https:// eprint.iacr.org/2016/086.[2017-02-20].

5Peinado M,Chen YQ,England P,et al.NGSCB:A trusted open system.Australasian Conference on Information Security and Privacy.Berlin Heidelberg,Germany.2004.86–97.

6Ta-min R,Litty L,Lie D.Splitting interfaces:Making trust between applications and operating systems configurable.Proc.of the 7th USENIX Symposium on Operating Systems Design and Implementation.Seattle,WA,USA.2006.279–292.

7Chen XX,Garfinkel T,Lewis EC,et al.Overshadow:A virtualization-based approach to retrofitting protection in commodity operating systems.Proc.of the 13th International Conference on Architectural Support for Programming Languages and Operating Systems.Seattle,WA,USA.2008.2–13.

8ARM Limited.ARM security technology:Building a secure system using trustZone technology.White Paper PRD29-GENC-009492C,2009.

9Trusted Computing Group.TPM Main Part 1 Design Principles,Specification.version 1.2,revision 103,2007.

10Mccune JM,Parno BJ,Perrig A,et al.Flicker:An execution infrastructure for TCB minimization.Proc.of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems.Glasgow,Scotland UK.2008.315–328.

11Zhang FZ,Chen J,Chen HB,et al.CloudVisor:Retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization.Proc.of the 23rd ACM Symposium on Operating Systems Principles.2011.203–216.

12Openstack user survey:A snapshot of openstack users’attitudes and deployments.https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf.[2016-04].

13Hecht L.TNS research:Is ansible really leading chef and puppet for container orchestration? http://thenewstack.io/ansible-leading-chef-puppet/.[2016-06-17].

14Dworkin M.Recommendation for block cipher modes of operation:The CMAC mode for authentication NIST Special Publication 800-38B,NIST,2005.

15https://github.com/you-n-g/sgxdb.

Security Enhancement of Ansible Based on Intel SGX

YANG Xiao1,2,YU Jia-Geng1,WU Yan-Jun11(National Engineering Research Center for Fundamental Software,Institute of Software,Chinese Academy of Sciences,Beijing 100190,China)2(University of Chinese Academy of Sciences,Beijing 100049,China)

As one of the most popular tools for automatic operation and maintenance in cloud platforms,Ansible usually stores a lot of administrator accounts information in a configuration file for batching executions.The configuration file is usually stored in the disk in plain text.However,it is not safe in the cloud because the confidentiality and integrity of configuration of Ansible depend on the security of the underlying software.Therefore,it is crucial to reinforce the security of configuration management mechanism of Ansible.In this paper,we implement a configuration management component for Ansible based on SGX (Software Guard eXtensions)proposed by Intel in recent years,which can manage the configuration information of Ansible in a trusted execution environment (TEE)independently.With this component,the configuration information cannot be read or written from outside and its security doesn’t depend on the underlying software.The experiments show that our solution is more reliable,and the extra overhead is also acceptable.It is possible to extend our application to a general component for configuration protection in cloud platforms such as OpenStack.

Intel SGX; cloud computing; security; operation and maintenance; Ansible

楊驍,于佳耕,武延軍.基于Intel SGX的Ansible安全增強.計算機系統(tǒng)應(yīng)用,2017,26(10):67–72.http://www.c-s-a.org.cn/1003-3254/5977.html

中國科學院先導專項(XDA06010600); 國家自然科學基金青年基金(61402451)

2017-01-04; 采用時間:2017-02-13