文獻標(biāo)識碼: A
文章編號: 0258-7998(2013)04-0133-04
云計算代表了IT領(lǐng)域向集約化、規(guī)模化與專業(yè)化道路發(fā)展的趨勢,但它在提高使用效率的同時,為實現(xiàn)用戶信息資產(chǎn)安全與隱私保護帶來極大的沖擊與挑戰(zhàn)。2009年11月,F(xiàn)orrester Research公司的調(diào)查結(jié)果顯示,有51%的中小型企業(yè)認為安全性和隱私問題是其尚未使用云服務(wù)的最主要原因。因此,云安全問題成為必須解決的問題之一[1]。
平臺即服務(wù)(PaaS)作為云計算的一種,是將基礎(chǔ)設(shè)施平臺作為一種服務(wù)呈現(xiàn)給用戶的商業(yè)模式,是一種低成本的方案。
本文首先分析了現(xiàn)有的PaaS平臺特征及其面臨的安全問題,然后提出了一個提供容器安全功能的多層次PaaS平臺安全解決方案。
1 相關(guān)工作
目前,針對云計算安全問題,一些學(xué)者和組織給出了相應(yīng)的解決方案。巴斯塔和哈爾頓提出一種通過盡可能地使用加密協(xié)議來避免IP欺騙的方法。他們提出,為了避免ARP中毒,需要root權(quán)限才能更改ARP表,而且盡量使用靜態(tài)表而非動態(tài)ARP表;如果一家要使用ARP表,至少也要確定變化的ARP表被記錄下來。拉吉等人提出了資源隔離的方法,通過在處理過程中隔離虛擬機中處理器的高速緩存并隔離這些虛擬高速緩存的虛擬機管理程序緩存,確保數(shù)據(jù)的安全性。在數(shù)據(jù)管理頂級會議SIGMOD 2009上,Wong等[2]提出了一種安全性較高KNN查詢方案,使得惡意的云服務(wù)器無法獲得用戶私有的敏感信息。Apache自由軟件基金會基于Google云計算系統(tǒng)的設(shè)計思想,實現(xiàn)了開源的Hadoop項目[3], Hadoop實現(xiàn)了Google的MapReduce編程模型,提供了簡單易用的編程接口,也提供了自己的分布式文件系統(tǒng)HDFS。
2 PaaS平臺的安全問題
PaaS平臺分為兩類,一類是應(yīng)用部署和運行平臺APaaS(Application- Platform-as-a-Service),另一類是集成平臺IPaaS(Integration-Platform-as-a-Service)。在多租戶APaaS中,云平臺主要面臨三個方面的安全威脅:容器內(nèi)部應(yīng)用共享資源引起的安全問題、容器自身安全問題及容器在網(wǎng)絡(luò)層的安全問題。
2.1 容器內(nèi)部應(yīng)用共享資源引起的安全問題
林兆驥等人在《云計算安全關(guān)鍵問題研究》中提到[4],在多租戶APaaS中,應(yīng)用面臨著一些安全隔離問題。
2.2 容器自身安全問題
在2009年,Google、Microsoft、Amazon等公司的云計算服務(wù)均出現(xiàn)了重大故障,有些是由于容器自身引起的安全問題。云平臺中,惡意應(yīng)用通過獲取容器的特征信息(如類型、版本信息等),針對容器本身進行攻擊,將造成安全問題。以目前主流的Tomcat為例,其面臨的安全問題如下:
(1) 掃描威脅
由于Tomcat默認通過8080端口對外提供Web服務(wù)。通過掃描網(wǎng)絡(luò)中開啟了8080端口的主機,并利用掃描工具,攻擊者不但能夠獲得開啟了8080端口的Tomcat服務(wù)器的IP地址,還可以掃描自動破解弱口令。
(2) 登錄后臺威脅
通過掃描獲得IP和弱口令后,攻擊者就可以通過默認的admin用戶登錄后臺。在Tomcat的后臺可以看到站點的所有目錄和文件,并且對目錄實施“開啟”、“停止”、“重啟”、“卸除”等操作。對于攻擊者來說,不僅可以通過停止或卸除操作影響當(dāng)前容器內(nèi)應(yīng)用的正常運行,更可以通過把jsp網(wǎng)馬打包生成war包,上傳后在容器內(nèi)運行該網(wǎng)馬。
(3) Webshell威脅
通過后臺上傳用war打包的網(wǎng)馬后,在Tomcat站點下生成與上傳文件同名的目錄。點擊該目錄,可以看見jsp網(wǎng)馬,在瀏覽器中輸入該網(wǎng)馬的URL地址,可獲得一個Webshell。攻擊者可以通過Webshell對系統(tǒng)進行提權(quán)、滲透,進而獲得整個服務(wù)器的控制權(quán)。
2.3 容器網(wǎng)絡(luò)層的安全問題
互聯(lián)網(wǎng)是云計算的基礎(chǔ),所以PaaS平臺運行托管環(huán)境中實現(xiàn)安全容器,需要考慮容器在網(wǎng)絡(luò)層的幾個安全問題:
(1) DDoS攻擊
DDoS攻擊即通過向服務(wù)器提交大量請求使服務(wù)器超負荷,從而阻斷用戶訪問服務(wù)器,阻斷某服務(wù)與特定系統(tǒng)或個人的通信。DDoS攻擊帶來兩方面的安全威脅:阻斷VM正常的網(wǎng)絡(luò)通信,使其無法響應(yīng)用戶請求;向某一Web Container提交大量請求,影響Container內(nèi)應(yīng)用的正常運行。亞馬遜采取保持內(nèi)部帶寬超過互聯(lián)網(wǎng)給予帶寬的方式來減少潛在的DDoS攻擊[5]。
(2) IP欺騙
SUBASHINI S等人在參考文獻[5]中提到IP欺騙在網(wǎng)絡(luò)安全方面給了攻擊者可乘之機。IP欺騙是指一臺主機通過冒充另外一臺主機的IP地址與其他設(shè)備通信,從而達到某種目的。
(3) 端口掃描
在PaaS平臺中,通過端口掃描獲得某主機上提供的網(wǎng)絡(luò)服務(wù),并搜集到很多關(guān)于目標(biāo)主機有用的信息,例如是否能夠匿名登陸、是否有可寫的FTP目標(biāo)、是否能用Telnet等。
3 PaaS平臺安全的解決方案
圖1顯示了云計算環(huán)境下的容器及其關(guān)系。為解決PaaS云平臺面臨的安全問題,本文將PaaS平臺安全容器進行分層來提供安全,三個層次分別為容器內(nèi)部應(yīng)用安全、容器自身安全及容器外部入侵防御安全。
3.1 容器內(nèi)部的應(yīng)用安全
在多租戶PaaS模式中,最核心的安全原則就是多租戶應(yīng)用隔離。為了實現(xiàn)多租戶應(yīng)用隔離,云提供商必須提供“沙盒”架構(gòu),通過平臺的“沙盒”性實現(xiàn)集中維護客戶部署在PaaS平臺上應(yīng)用的保密性和完整性。為此,云提供商一般通過為每一個用戶應(yīng)用提供一個Servlet容器的方法來實現(xiàn)邏輯上的隔離。
現(xiàn)有解決方案能有效提供平臺的“沙盒”架構(gòu),實現(xiàn)多租戶應(yīng)用隔離。但同時,多租戶模式下運行多個Servlet容器的模式會帶來較大的系統(tǒng)開銷。本文在現(xiàn)有解決方案的基礎(chǔ)上,提出了一種由一個Servlet容器承載不同應(yīng)用的解決方案,在實現(xiàn)多租戶應(yīng)用隔離的同時保證系統(tǒng)性能。
本文提出的PaaS平臺安全容器,就是利用Java技術(shù)提供的安全性,并在此基礎(chǔ)上結(jié)合托管PaaS平臺特點進行定制而實現(xiàn)的。
3.1.1 Java安全體系結(jié)構(gòu)
Java技術(shù)從多個方面提供了對安全性的支持:Java語言本身安全性、虛擬機的雙親委托類加載機制、安全管理器和Java API。這些共同構(gòu)成了Java安全體系結(jié)構(gòu),即沙盒模型,是一個支持靈活的細粒度訪問控制的安全策略,并且具有可擴充性和伸縮性的安全體系結(jié)構(gòu)。
Java沙盒采用了靈活的保護域安全模型,由安全策略來決定代碼具有的訪問許可,對被保護資源的訪問會激發(fā)安全檢查,這些檢查會將授權(quán)的許可和其試圖訪問所需要的權(quán)限進行比較。這些激發(fā)安全檢查的訪問包括文件系統(tǒng)訪問、JNI訪問本地代碼、創(chuàng)建Socket連接等。
3.1.2 基于Java安全體系結(jié)構(gòu)的托管PaaS安全容器
利用Java沙盒模型提供的訪問控制功能,可以將同一JVM中運行的代碼邏輯上分開,分別運行于不同的沙盒中。在本研究中,托管PaaS平臺安全容器,利用Java沙盒模型,使不同的應(yīng)用運行于不同的沙盒中,實現(xiàn)應(yīng)用隔離功能。
本研究中,針對托管PaaS平臺及Jetty和用戶應(yīng)用的特點,在Java沙盒模型的基礎(chǔ)上進行了擴展,其體系結(jié)構(gòu)如圖2所示。
在托管PaaS平臺運行環(huán)境中,安全容器提供應(yīng)用運行的受限的環(huán)境,即沙盒環(huán)境。沙盒環(huán)境實現(xiàn)應(yīng)用運行時5個方面的訪問控制:文件訪問控制、網(wǎng)絡(luò)訪問控制、多線程控制、JNI訪問控制及System.exit()方法訪問控制。如圖2所示,在托管PaaS平臺運行環(huán)境中,安全容器在Java安全體系結(jié)構(gòu)基礎(chǔ)上進行擴展,實現(xiàn)了兩套邏輯沙盒模型,在邏輯上將系統(tǒng)代碼和應(yīng)用代碼分開處理,簡化了安全策略文件的配置,提高了系統(tǒng)性能。
在托管PaaS平臺運行環(huán)境中,兩套邏輯沙盒模型(默認沙盒和應(yīng)用沙盒)分別提供系統(tǒng)代碼和應(yīng)用代碼的運行環(huán)境,并實現(xiàn)訪問控制。托管PaaS平臺運行環(huán)境安全模型主要通過保護域模塊、類加載模塊、安全策略模塊和訪問控制模塊來實現(xiàn)。
在PaaS系統(tǒng)中,保護域模塊由系統(tǒng)保護域和應(yīng)用保護域組成。系統(tǒng)保護域使用Java安全體系結(jié)構(gòu)中默認的域模型,即通過代碼位置及簽名指定保護域。應(yīng)用保護域由每個應(yīng)用的AppContext來指定,邏輯上與一個Web應(yīng)用相對應(yīng)。在類加載模塊中實現(xiàn)了系統(tǒng)類(Jetty代碼和服務(wù)端代碼)和應(yīng)用類兩套類加載策略,分別由系統(tǒng)類加載器和WebApp類加載器加載。在安全策略模塊中,默認沙盒采用Java安全體系結(jié)構(gòu)默認的安全策略文件來實現(xiàn)安全策略。默認安全策略指定了PaaS系統(tǒng)中應(yīng)用的默認權(quán)限,由WebApp ClassLoader加載應(yīng)用類型時,創(chuàng)建相應(yīng)App實例,同時初始化該App的權(quán)限集合Permissions。對于訪問控制模塊,按照兩套邏輯分別進行權(quán)限檢查。同時出于安全考慮,設(shè)計了WebApp SecurityManager。當(dāng)代碼請求訪問被保護資源時,WebApp SecurityManager判斷當(dāng)前請求是否來自應(yīng)用,繼而觸發(fā)相應(yīng)的訪問控制邏輯或是將請求委托給父類安全管理器。
3.2 容器自身安全
目前主流的Servlet容器有Tomcat、jetty、jboss等,這些容器都存在自身的弱點,為預(yù)防攻擊者針對容器進行攻擊,在PaaS云平臺中應(yīng)該隱藏容器信息,包括容器類型、版本信息等。
目前獲取容器特征信息的方式主要有以下三種:
(1)通過容器提供的API獲取,對于實現(xiàn)sun的Servlet2.3以上的Servlet提供以下方法支持,通過GenericServlet類的getServletContext()獲取ServletContext,再由ServletContext.getServerInfo()方法獲取服務(wù)器類型;
(2) 通過工具類提供的API獲取,Liferay里面提供了一個方法來判斷不同的應(yīng)用服務(wù)器;
(3) 惡意應(yīng)用通過執(zhí)行非法操作拋出異常,通過捕捉異常信息追蹤調(diào)用堆棧,也可分析獲取容器類型信息。
針對上述3種獲取容器特征信息的方法,本文將從兩個方面來實現(xiàn)PaaS平臺容器的信息隱藏。圖3顯示了容器信息隱藏的過程: (1)應(yīng)用運行依賴的jar包、容器本身的靜態(tài)信息和動態(tài)信息等由安全容器來集中管理; (2)安全容器的Connector模塊負責(zé)處理用戶請求并返回應(yīng)用運行結(jié)果,在所有運行結(jié)果返回給用戶之前進行檢測,所有可能暴露容器特征信息的異常信息通過包裝之后由過濾模塊進行決策再將相應(yīng)結(jié)果返回給用戶。
如圖4所示,當(dāng)外部入侵者通過多種方式盜取容器信息時,容器過濾模塊中的攔截模塊和欺騙模塊都將做出防御行為。攔截模塊指依據(jù)策略攔截入侵者的請求;行為模塊包括允許、不允許、過濾部分請求、欺騙用戶等行為;決策模塊具有智能算法,它依托于策略服務(wù)器作為其策略庫,以此給出合適的處理方式。對于決策模塊時,本解決方案為各種決策算法設(shè)計了公共的可用接口,神經(jīng)網(wǎng)絡(luò)、決策樹等決策算法均可以插件的形式應(yīng)用到該模塊中。欺騙模塊指對入侵者發(fā)送假消息來誤導(dǎo)入侵者,從而保護容器自身的信息不泄露。當(dāng)容器過濾模塊收到用戶請求時,由決策模塊調(diào)用策略服務(wù)器來決定處理方式,若需要欺騙用戶來保證容器安全則會調(diào)用欺騙模塊。最后由行為模塊來執(zhí)行動作。
3.3 容器外部的入侵防御安全
互聯(lián)網(wǎng)是云計算的基礎(chǔ),所以PaaS平臺運行托管環(huán)境中實現(xiàn)安全容器,需要考慮容器在網(wǎng)絡(luò)層的安全問題,包括避免容器受到DDoS攻擊、防止外部對容器的嗅探等。如圖5所示,本文針對以上情況給出了PaaS平臺的安全解決方案。
3.3.1 DDoS攻擊防御
單一的DoS攻擊一般采用一對一方式,當(dāng)攻擊目標(biāo)各項性能指標(biāo)不高時(CPU速度低、內(nèi)存小或者網(wǎng)絡(luò)帶寬小等),它的效果是非常明顯的。分布式拒絕服務(wù)DDoS(Distributed Denial of Service)攻擊逐漸出現(xiàn)。處于不同位置的多個攻擊者同時向一個或多個目標(biāo)發(fā)起協(xié)同的拒絕服務(wù)攻擊,或者一個或多個攻擊者控制了位于不同位置的多臺機器并利用這些機器對受害者同時實施攻擊。
本文提出的多層次解決方案采取了3種措施來防御DDoS攻擊:
(1) 提出網(wǎng)絡(luò)節(jié)流和服務(wù)器均衡算法
在圖5所示的云平臺子系統(tǒng)中,采用了負載均衡的算法。該算法由負載監(jiān)控、負載調(diào)整和負載策略控制器3個子模塊共同協(xié)作完成。
(2) 提出報文過濾算法
在圖5所示的云平臺接入子系統(tǒng)中,反DDoS模塊采用了報文過濾算法。具體來說,采用了入口報文過濾和路由報文過濾兩種算法。入口報文過濾[4](Ingress Filtering)是一種對付匿名攻擊的方,可以過濾掉偽造源IP地址的數(shù)據(jù)包。本文將這種機制配置在路由器的入口,通過網(wǎng)絡(luò)提供者利用路由器將來源地址不屬于該客戶區(qū)域的數(shù)據(jù)包過濾掉。
(3) 為云平臺安裝防火墻
在反DDoS模塊中,系統(tǒng)采用的另一方法是在PaaS云平臺中加裝防火墻系統(tǒng),使得無論是進入還是送出防火墻的數(shù)據(jù)都經(jīng)過嚴(yán)格過濾。同時,在防火墻中關(guān)掉未使用的端口號,從而防止容器從外部被入侵。
3.3.2 預(yù)防網(wǎng)絡(luò)監(jiān)聽與端口掃描
近年來,網(wǎng)絡(luò)監(jiān)聽和端口掃描一直是計算機網(wǎng)絡(luò)安全的敏感話題,它能造成極大的危害。網(wǎng)絡(luò)監(jiān)聽是指將網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)捕獲并進行分析的行為。端口掃描是一種非常重要的預(yù)攻擊探測手段。通過端口掃描可以知道目標(biāo)主機上開放了哪些端口、運行了哪些服務(wù),這些都是入侵系統(tǒng)的可能途徑[6]。
在多層次的云平臺解決方案中,由反監(jiān)聽掃描模塊來預(yù)防網(wǎng)絡(luò)監(jiān)聽和端口掃描。它采取了3種方法來預(yù)防網(wǎng)絡(luò)監(jiān)聽與端口掃描:
(1) 在解決方案中利用SATAN等工具分析網(wǎng)絡(luò),從而識別出一些與網(wǎng)絡(luò)相關(guān)的安全問題;
(2) 在PaaS平臺上通過防火墻技術(shù)監(jiān)聽、限制以及更改跨越防火墻的數(shù)據(jù)流,盡可能地對外部網(wǎng)絡(luò)屏蔽有關(guān)被保護網(wǎng)絡(luò)的信息、結(jié)構(gòu),實現(xiàn)網(wǎng)絡(luò)的安全保護;
(3) 在PaaS平臺中對傳輸?shù)男畔⑦M行加密。使用手段使監(jiān)聽者不能有效地獲得要監(jiān)聽的信息,使得即使監(jiān)聽者可以得到所有的網(wǎng)絡(luò)通信包,仍然不能獲得有用的信息。
本論文研究了PaaS云平臺所面臨的一些安全問題,并從容器內(nèi)部應(yīng)用安全、容器自身安全、容器外部的入侵防御安全三個方面給出了多層次的解決方案。促進了云計算的推廣和應(yīng)用。
參考文獻
[1] NORT H S. 網(wǎng)絡(luò)入侵檢測分析員手冊[M].北京:人民郵電出版社,2000.
[2] WONG W K, CHEUNG D W, KAO B. Secure kNN computation on encrypted databases[J]. ACM SIGMOD International Conference on Management of Data.2009:139-152.
[3] Apache. Hadoop[EB/OL].[2012-05-12].http://hadoop.apache.org/.
[4] 林兆驥.云計算安全關(guān)鍵問題研究[J].信息化研究,2011,37(2):1-4.
[5] SUBASHINI S, KAVITHA V. A survey on security issues in service delivery models of cloud computing[C]. India: Anna University Tirunelveli.2007.
[6] 唐曉明,梁錦華.網(wǎng)絡(luò)端口掃描及其防御技術(shù)研究[J].計算機工程與設(shè)計,2002,23(9):15-17.