探究虛擬機之管理及資安議題

Burton Group 資安及虛擬化產業分析師Alessandro Perilli 在今年6月美國San Diego 的Catalyst Conference 中（註一），點出虛擬化環境中幾個大家較容易忽略的資安問題，在此分享他的看法並探討如何藉助工具來解決這些問題。

Alessandro Perilli指出很多問題和虛擬機維運面（operation）息息相關。例如，如果一個虛擬機所含的guest OS沒有上到最新版的修補程式（patch）而又以此虛擬機為模版（template）來複製其它虛擬機；另外，有些單位將虛擬機及storage之權限控管都交由虛擬機管理者而導致權能分工無法落實；他也常看到在一台實體機上運行不同資安等級的虛擬機。從資安及風險管理觀點，這些疏忽值得我們注意。

在實作（implementation）面，當多台虛擬機同時存取儲存設備時，相關的使用權限控管是否規劃週延並落實？最後，比起實體機，虛擬機是相對容易被創建但資安相關的組態參數設定及控管要求，在準備（provision）虛擬機時是否被嚴格遵守？這點也常被忽略。

如何藉助完善的工具掌控虛擬機的佈署

過去申請實體機需要幾天甚至幾週來跑流程，在過程中相關控管機制可落實；在伺服器虛擬化之後，虛擬機（VM）可在幾分鐘內就創建，如果缺乏工具來控管VM的產生、佈署、改變及退役，很快的VM就會蔓生並衍生上述問題。意即IT 管理者不知道在公司內VM總共有那些？這些VM創建時，是否遵守相關規定？Guest OS上到那一版patch？誰改了VM設定，什麼時候改了VM設定？那些VM何時準備退役？那些VM其實沒在用而該退役？若這些管理問題不解決，其衍生之善後費用及對企業造成之損失將漸漸侵蝕原本虛擬化帶來之好處。

簡言之，對實體機及虛擬機必須使用同樣一套控管標準。

當然若實體伺服器數量不多，由專人透過Excel或資料庫來落實VM之申請、核准、佈署及退役是一個可行的方式；可是一旦VM數量一多，經驗告訴我們這類重覆、繁瑣管理工作不僅難落實也容易犯錯。如果將這些管理工作交由工具軟體來控管，對IT 管理者及VM使用者是雙贏；VMWare的Life Cycle Manager（LCM）即是針對此管控需求而研發之工具。如圖一所示，它協助監控從VM之需求提出、批准、創建、組態變更到退役的整個過程並忠實紀錄相關軌跡到日誌檔以供日後稽核之需。

對VM需求者，提出VM需求就類似請假流程。你可透過專屬網站知道你所申請之VM目前誰在審核，准了嗎？系統管理者可經由申請表格要求VM需求者註明所需之VM組態（CPU, disk, memory, OS, AP 版本etc.）用途、預計何時除役等資訊。藉助LCM掌控公司所有VM之生命週期，前面所提到無論在營運面或實作面的問題都可迎刃而解。

進一步落實虛擬機資安控管之貼心提醒

VMWare在設計VMWare ESX server時雖然已將資安列入考量，但若要進一步鞏固虛擬機、ESX及實體機之資安防護，仍有一些細節值得提醒。以下就節略在"VMWare Infrastructure 3 Security Hardening"（註二）文章中提到的一些重點，供各位參考。

先從虛擬機談起：

1. 對那些暫時冬眠的VM（即目前被power off，但未來會再啟動之VM），當它再度被啟用時，請注意是否相關patch都已上。
2. 關掉或拿掉不需要的service及週邊設備（例如DVD, USB, floppy等），減少資安侵入點。
3. 儘量利用模板（template）來創建VM以確保VM組態設定之一致性。此模板可只含OS，其它模板可利用此模板再安裝相關AP。若因OS或AP需要上      patch，可利用converter將打包好的VM image回復到組成之OS,AP，上完patch後，再打包成VM image。
4. 透過設定VM可使用的資源（memory, disk）之上限以避免它因軟體中毒導致無限制索取資源而造成其它VM無法運作之困境。
5. 在虛擬化環境中，存在一個虛擬網路（virtual network）。建議利用網段隔離（network segment）方法將虛擬機依功能區隔到不同網段，這有助於      防範攻或偵錯。

在管控虛擬機及ESX server時，建議儘量使用Virtual Center或VI Client。若有些管理指令只能透過service console，因為它可以改變ESX server重要屬性（諸如access right、儲存設備組態等），建議需要嚴加控管那些人能使用service console。另外，這三種管控工具最好都能在特定網段進行以限制使用區域。

因為Virtual Center是在Windows平台上運行，萬一它被攻陷，侵入者可經由它進一步攻擊相關ESX server及VM。因此建議要以保護server的等級來對待運行Virtual Center之PC。

對安裝ESX之實體機，有幾項提醒：

1. 除非為了偵錯需要，網卡不要隨意啟動promiscuous mode，因為它可能讓接到此網段的VM收到在這網段上其它VM的封包。
2. 為了一目瞭然及稽核方便，對虛擬網路之每個網段仍建議標示清楚。
3. 對storage，建議儘量活用zoning及LUN masking來區隔各個VM對此storage之使用，比如testing & production就應該分開。
4. 建議使用log輪調（rotation）機制來儲存VM相關之log以免因為這些log成長失控而塞滿storage空間。

以上提醒看起來較瑣碎，若讀者有興趣，請參考原文（註二），它有更完整之說明。

VMSafe

一台實體機虛擬化之後，雖然其上可能有數個VM同時在運行，對現今管控實體機之工具而言，它仍只是一台實體機，從資安觀點，這難免另人擔心；上述LCM及貼心之建議雖可彌補這個遺憾，但從整個虛擬化產業之永續發展而言，如何讓其它資安監控工具開發廠商能對ESX運作狀態有更透明之能見度（visualability）來監控ESX本身及在上運行之VM，VMWare於是在今年2月提出VMSafe API。相關廠商可依據此API開發相關工具；因為是公開之API，不同工具一起使用時不用擔心相容性之問題。

目前全世界各大知名資安控管工具開發廠商以及一些具有特色及創意之startup公司都已積極依循此API 開發相關產品，預期在不久之將來，系統及資安管理者將會有很好的虛擬化控管工具可使用。

參考資料
註一. Catalyst Conference 2008: Virtualization Security, Myths Vs. Reality （George Hulme）
http://www.informationweek.com/blog/main/archives/2008/06/catalyst_confer.html

註二. VMWare Infrastructure 3 Security Hardening
http://www.vmware.com/pdf/vi3_security_ hardening_wp.pdf