文/山東省德州市水利局 張卓
自從互聯網成為通信領域的一支力量以來,其對數據存儲和安全的需求不斷增加。這一需求在過去二十年中呈指數增長,促生云計算的出現。與數據存儲相關的問題已在很大程度上得到解決,但安全性仍然是研究人員面臨的挑戰。
虛擬機(有線或無線)之間或從一個云網絡到另一個云網絡之間的文件傳輸就會面臨安全性問題,需要將其作為云安全的一部分加以解決。文件傳輸協議(FTP)通常用于傳輸文件,但FTP的原始形式存在許多安全漏洞。FTP的目的沒有提到安全性,因此FTP受到多種威脅。所有的傳輸都是純文本的,包括用戶名和密碼,因此任何具有正確配置的人都可以執行包嗅探以獲取網絡上的敏感信息。
為了解決FTP中的漏洞,開發人員提出了各種解決方案,包括將FTP與安全協議集成,或者簡單地使用SCP(secure copy)在計算機之間復制文件。本文將描述幾種考慮數據保密性和完整性的協議。此外,還將討論這些協議的性能,其中包括加密開銷如何影響延遲或資源使用方面的總體操作。
(一)安全外殼文件傳輸協議(SFTP)。SFTP負責使用SSH訪問和管理遠程系統上的文件。SFTP和FTP的主要區別在于前者對命令和數據進行加密,防止敏感信息以明文形式通過網絡傳輸。SFTP可以在遠程機器上執行許多操作,例如獲取文件大小、遍歷目錄、計算目錄中的文件數、刪除文件、創建符號鏈接等等。由于SFTP能夠重新利用SSH連接,加密期間產生的開銷與SSH差別不大。SFTP還能夠在具有不同操作系統的遠程計算機之間傳輸文件。例如,為了將文件傳輸到Windows操作系統,需要在Windows上手動安裝SSH服務器。由于Microsoft的IIS(Internet Information Services)只支持FTP,所以有WINSSHD、Freeshd、FREEFTPd、FILEZILLA等SSH服務器可用于支持SFTP。通過SFTP的認證可以通過兩種方式執行:密碼認證和公鑰認證。這兩種方法都同樣安全,但后者將花費更少的時間。另一方面,如果密鑰太多,則密鑰管理可能成為一個問題,在這種情況下,基于密碼的身份驗證將優先。
(二)安全套接字層(FTPS)上的文件傳輸協議。FTPS還負責訪問和管理遠程系統上的文件。然而,與SFTP相比,主要的區別在于用于添加安全性的底層協議。對于FTPS,使用的底層協議是SSL/TLS。FTPS協議使用X.509證書進行身份驗證,該證書依次包含公鑰和證書所有者的信息。有兩種不同形式的FTP over SSL:顯式和隱式加密。在顯式加密的情況下,連接以明文開始,并在發送auth命令后加密,而在隱式加密開始時加密。對于大多數平臺提供的FTPS支持,默認設置為顯式加密。
(三)SSH隧道。安全SHELL(SSH)隧道是一個基于SSH協議的加密隧道,可以通過數據連接進行傳輸。通過該通道的數據通常以未加密的格式傳輸。OPENSSH軟件用于在兩臺遠程機器之間建立隧道。SSH隧道可以用于安全傳輸文件,但通常建議克服防火墻設置。端口轉發用于將所有流量定向到遠程計算機。有兩種類型的端口轉發:本地端口轉發和遠程端口轉發。在本地端口轉發中,定義一個本地端口,然后使用它通過轉發此端口將文件傳輸到遠程計算機。在遠程端口轉發中,遠程計算機上的應用程序可以訪問本地主機上的服務。
(四)SCP和RSYNC協議。安全復制(SCP)是另一種網絡協議,用于遠程主機之間的文件傳輸。負責提供身份驗證的底層協議是SSH。RSYNC是另一種用于在系統之間傳輸文件的協議。但是,SCP和RSYNC的主要區別在于前者覆蓋目標主機上的每個文件,而后者更多的是同步算法,在主機之間執行增量傳輸。由于RSYNC只執行增量傳輸,因此與SCP相比,該協議消耗的網絡資源要少得多。
(五)基于IPSEC的FTP協議。在IPSEC中,協議安全性在進行數據包處理的網絡層實現。早期的協議是在TCP/IP模型的應用層實現的,在該層中,需要在個人的客戶機中進行更改。但在IPSEC中,為了增強安全性,需要在網絡層(特別是路由器)進行更改,以將其作為跨網絡的標準安全措施來實現。IPSEC本身包含兩個主要協議:身份驗證頭(AH)和封裝安全負載(ESP)。ESP是首選,因為它既提供認證又提供機密性,而AH不提供機密性保護。由于所涉及的復雜性和實現過程中產生的成本,通常不使用IPSEC進行安全文件傳輸。然而,它對于大型企業設計自己的虛擬專用網絡(VPN)非常有用。
“表1”提供了文件從一個Linux虛擬機傳輸到另一個虛擬機所用的秒數。當文件數為8、100和500時,在3種不同的情況下重復此場景,并在每個情況下記錄文件傳輸的執行時間。在Linux操作系統中,使用名為“date”的內置實用程序以秒為單位記錄時間,精確到小數點后2位。此外,在兩臺遠程計算機都安裝了CentOS并且位于同一子網中的環境中執行,以便將由于交換機和路由器而引起的延遲降到最低。

表1 虛擬機間傳輸文件時間對比
從表中可以看出,當底層協議為FTP時,文件傳輸所用的時間最少,因為連接未加密,文件以純文本形式傳輸,因此不涉及加密頭。另一方面,當文件數為8時,第一種情況下的SFTP文件傳輸所花費的時間幾乎高出51%,而當文件數分別為100和500時,第二種情況下的SFTP文件傳輸所花費的時間減少到35%左右,第三種情況下的SFTP文件傳輸所花費的時間減少到31%。考慮到云計算所涉及的可伸縮性,我們可以安全地假設,假設線性回歸,對于數千個文件,性能下降將降到20%左右。
當底層協議是FTPS時,兩個主機之間的文件傳輸所花費的時間與SFTP幾乎相似。因此,我們可以得出結論,就通過FTP實現FTPS或SFTP可能導致的文件傳輸延遲而言,這幾乎是相似的。輕微差異可能是由于同一子網上的網絡流量不同,在不同情況下可能會有所不同。
對于SCP,兩個主機之間的文件傳輸所用的時間與觀察到的SFTP和FTPS的時間相當。對于8個文件,SCP時間更長,但對于大量文件,執行時間小于SFTP或FTPS觀察到的時間。這可能是因為在SCP的情況下使用了密碼驗證,因為與SFTP相比,觀察到的時間略有不同。但由于SCP中的底層協議也是SSH,所以我們可以安全地假設,在公開密鑰認證的情況下,SCP的性能將類似于SFTP。但是,在大多數情況下,都會優先考慮SFTP,因為SCP的功能僅限于在使用SFTP時傳輸文件,還可以在遠程計算機上對文件執行許多操作。在RSYNC的情況下,文件傳輸所花費的時間比SCP文件傳輸所花費的時間稍短。這是因為RSYNC不會覆蓋遠程計算機上的現有文件,并執行增量操作,其中只傳輸那些不在遠程計算機目標目錄中的文件。
然而,基于上述觀察結果,不能斷言哪種協議最理想。這完全取決于云計算中的特定場景。它還取決于安裝在客戶機上的操作系統。例如,Windows不支持SSH,盡管更高版本的Microsoft IIS確實支持SSL,而SSL又與Windows具有更好的兼容性。因此,在這些情況下,建議在任何其他基于SSH的協議上使用FTPS。
選擇安全文件傳輸協議時可能考慮的另一個因素是CPU使用率。雖然高端服務器在市場上有售,但由于成本高昂,許多小規模組織可能無法購買。在這種情況下,優化CPU使用率變得至關重要,如果需要傳輸數千個文件,CPU使用率可能會非常高。在這方面,隧道技術和端口轉發技術可能會派上用場。在許多組織中,云本身將受到外部訪問的保護,因此可能不需要保護每個文件傳輸。在這種情況下,最好使用延遲時間短、網絡資源消耗少的協議。
盡管云計算繼續主導信息技術領域的市場,但仍有許多安全漏洞需要解決。本文重點介紹了其中的一些解決方案,并對這些解決方案進行了簡要的嘗試,使讀者能夠理解這些解決方案的部署環境。此外,還對不同協議進行了比較,以提供延遲發生和網絡資源使用的前景。