這幾年來，越來越多的企業開始使用虛擬化環境。不管是將虛擬化環境用於支援系統，還是將重要核心系統佈署在虛擬化的環境當中，虛擬化環境的安全性都是一項不可忽視的議題。虛擬化環境的導入，通常以提高資源使用效率與可用性為主要目的，而安全性卻往往沒有受到同等的重視。事實上，將系統從實體環境轉換到虛擬化的環境後，除了原有的安全考量之外，還多了一些額外的事項需要注意。因此，如果只是單純將系統從實體環境轉換到虛擬化環境之中，整體的安全性可能反而是下降的。在這篇文章中，我將針對 VMware vShpere 5 的虛擬化環境，提供一些用來加強虛擬化環境安全性的建議作法：
- 充分使用 ESXi 內建的防火牆 ESXi 已經內建防火牆，而且預設就是開啟的。更棒的是，如果某些服務 (如ssh daemon) 被開啟或關閉時，系統將會自動啟用或關閉相對應的防火牆設定。ESXi 內建防火牆的設定以各項服務為主體，而不是單純的網路協定或埠號，也就是說我們無法透過 ESXi 的防火牆指定開放 TCP Port 3306 (MySQL 服務)。乍看之下可能會令人覺得這樣的設定方式不夠完整，但是其實這樣設定方式卻是再方便不過了。事實上，我們沒有必要進行開放 TCP Port 3306 的設定，原因在於 ESXi 防火牆僅適用於過濾與主機 (host) 溝通的封包。對於與虛擬主機溝通的封包，ESXi 內建的防火牆並不會進行任何過濾的行為。如果我們要限制虛擬機所能提供的服務，必須透過作業系統 (guest OS) 內的防火牆機制或是其他套件來達成此一目的。
在使用 EXSi 內建防火牆時有一個需要特別注意的地方，那就是預設並沒有針對任何遠端 IP 位址進行限制。也就是說如果一旦選擇開放 ssh daemon 的服務，任何 IP 位址都可以對此服務進行存取。想當然爾，這並不是一個安全的設定方式，我們應該針對實際的情況限制可以存取服務的 IP 位址，以避免任何不安全的存取嘗試。在下圖中，我限制只有 211.x.x.x 的 IP 位址可以存取主機上的 snmp daemon。
最後，ESXi 內建的防火牆必須一台台主機加以設定。對於同時管理多台主機的管理者而言，可以利用 host profile 或其他工具來統一進行主機的防火牆設定作業。 - 使用其他針對虛擬化環境設計的安全產品
傳統的安全機制不是無法套用於虛擬環境之中，不然就是效能將受到影響，所以針對虛擬化環境我們必須採用專門為其所發展的產品。VMware 有另外一個稱之為 vShield 的產品，可以用來強化整體虛擬環境的安全性。 - 啟用集中管理的日誌功能
ESXi 支援 syslog 的機制，可以將系統相關訊息透過 syslog 的機制統一遞送到 syslog 伺服器。在 VMware Server 的安裝光碟上包含了一個 syslog 伺服器的套件，安裝後就可以在 VMware Client 上直接看到日誌的相關資訊。雖然看似方便，但是我個人並不建議使用此一套件，原因在於我們並不能透過 VMware Client 直接查看日誌的內容。所以比較建議的方式是將這些主機的訊息遞送到企業原有的 syslog 伺服器以便進行統一個管理。syslog 的相關設定，同樣必須一台台主機加以設定。 - 記得更新 EXSi 與 VMware Tools
雖然 ESXi 看似單純，而且也不似我們之前常接觸的作業系統，但是不管如何，ESXi 還是一個不則不扣的作業系統。所以跟所有的軟體一樣，ESXi 也有更新的需求。然而因為通常單一主機上執行了多台的虛擬機，所以造成管理者對於更新作業所要求的重啟行為會有所擔憂。此部份如果搭配 vMotion, VMware HA, FT 等機制，其實並不會因為主機重啟而造成服務的中斷。除了 ESXi 更新之外，VMware Tools 也應該隨時保持在最新的狀態。我們可以透過 Update Manager 這個 plug-in 來簡化這些更新作業的進行，不過 Update Manager 必須搭配 VMware Server 方可使用。 - 考慮使用其他非自簽的憑證
雖然 ESXi 預設已經使用憑證進行資料的溝通 (例如 VMware Client 與 主機之間的溝通)，但是因為內建的憑證是自簽的關係，所以不容易確保憑證的合法性。如果企業內部擁有 CA 的機制，應該統一採用企業所簽發的憑證。如果企業內部沒有建置 CA，那就應該考慮採用外部機構所簽發的憑證了。 - 使用安全性足夠的密碼
在我們安裝 ESXi 的過程中，系統會強制我們設定一組密碼，而這組密碼是用來搭配預設的本機管理者 (root) 帳號。安裝完畢後，我們可以建立其他的本機帳號，用以管理此一主機。這些帳號的密碼必須提供足夠的安全性，以避免主機受到有心份子的惡意使用。除了建立本機帳號之外，我們也可以整合環境中現有的 AD 架構，達到統一管理帳號資訊的目的。
當使用 VMware Server 時，帳號資訊將來自於安裝 VMware Server 的作業系統之內。如果我們希望統一透過 VMware Server 來進行虛擬環境的管理作業，就不需要在本機建立額外的帳號了。 - 謹慎地使用授權機制
ESXi 提供了相當彈性的授權機制，然而也因為彈性而造成設定上必須多加注意以避免開放過多的權限而造成安全危害。ESXi 的授權預設是具備繼承性的，也就是父物件的權限也會適用於子物件 (如果子物件沒有其他權限設定)。舉例來說，如果我開放資料中心 (Datacetner ) 的網路設定 (Network – Configure) 權限給 A 這個使用者，那麼 A 就可以設定這個資料中心下所有主機的網路。雖然我們可以取消這樣的繼承關係，但是這樣做卻可能造成不少額外的設定工作。好在 ESXi 另外提供一個叫做 No Access 的權限，透過 No Access 權限的使用，我們可以讓 A 無法設定特定主機的網路。總而言之，如何決定適當的物件層級並搭配 No Access 的使用，將是授權是否合適的關鍵。
此外必須特別注意的是，當使用本機帳號直接連結主機時，權限是依附在本機帳號上。但是如果是透過 VMware Server 進行連結，那麼權限就是依附在 VMware Server 的帳號上。兩者設定的地方不同，甚至選項也不一樣。因此建議如果是採用 VMware Server 的環境，就應該限制使用者只能透過 VMware Server 進行管理，以避免權限管理的額外負擔。 - 限制遠端登入本機 Shell 的權限 當我們在建立本機帳號時，有一個選項 (Grant shell access to this user) 可以決定是否允許此一帳號從遠端登入本機 Shell，這個選項預設的關閉的 (也就是不能從遠端登入本機 Shell)。除非有很明確的需求，並做好了相關的安全措施，否則請勿開啟這個權限。
- 妥善地利用 Host Profile
前面我提到有些主機的設定(應該說是大部分，如防火牆、syslog) 必須一台台加以進行，而這種作法將會遭遇到幾個問題，一個是設定上過於費時，另外一個則是很難確保所有主機的設定都符合政策要求。此外，如果採用自動佈署的方式來安裝主機，如何確保這些主機的設定也能自動符合要求更是一大困擾。別擔心，這些困擾都可以透過 Host Profile 機制來加以解決。透過 Host Profile 的建立，我們可以檢查主機是否符合 Host Profile 內的設定基準，甚至可以將 Host Profile 內的設定基準套用到主機之上。所以只要好好利用 Host Profile，我們就可以輕鬆管理主機的所有設定值。 - 盡可能使用實體隔離的方式保護用以管理主機的網路介面
雖然是處於虛擬化的環境，但是 ESXi 依舊必須透過實體的資源才能提供服務，而在這些資源中一個很重要的資源就是網路。前面提到 ESXi 內建防火牆的時候，我們知道 ESXi 把與主機溝通的封包跟與虛擬機溝通的封包做了不同的處理。這樣的作法雖然有其安全性，但是仍舊有所不足。
在安裝 EXSi 時，不管系統上安裝了多少張實體網卡，系統都會要求並限制我們只能選取一張網路作為管理之用。當系統安裝完畢之後，我們可以利用 VMware Client 針對其他網卡進行管理功能的開放。如果主機上擁有足夠的實體網卡，最好能夠將管理與虛擬機使用的網卡區分開來，並連結至不同的交換器，以減少安全問題發生的機會。對於不打算開放管理功能的網卡，請記得不要設定 IP 位址。如果實體網卡的數量不夠，可以搭配 VLAN 的機制，將管理用的 VLAN 與虛擬機用的 VLAN 區隔開來。
以一般主機常見的安裝兩張網卡來說，我們有兩種選擇。 第一種是一張網卡專門作為管理之用，另外一張網卡則作為虛擬機專用。第二種選擇則是兩張網卡同時提供管理與虛擬機使用。對此我個人傾向第二種的選擇，一則兩個管理用的網卡可以避免因為單一網卡故障而無法管理的困境，二則虛擬機通常也需要兩個以上的實體網路，以便有效區隔不同的流量。所以如果主機上只有兩張實體網卡，那就只好充分利用 VLAN 的功能了。
不管採用哪種佈署方式，都別忘了防火牆等安全機制的必要性。 - 保護你的虛擬交換器 雖然 ESXi 虛擬交換器的功能不似實體交換器那般強大，但是倒還是有一些安全選項可供設定。包含是否允許使用 Promiscuous Mode (預設拒絕)、MAC Address Changes (預設允許) 與 Forged Transmits (預設允許)。Promiscuous Mode 可以讓 Guest OS 看到此一 Port Group 與"外界"溝通的封包，而 MAC Address Changes 與 Forged Transmits 則限制了 Guest OS 使用自定 MAC Address 時是否可以正常的接收 (MAC Address Changes) 或傳送 (Forged Transmits) 封包。除非有特殊的需求，否則這些選項應該都設定為拒絕 (Reject)。
- 監測你的虛擬環境 如果你的環境包含 VMware Server，那麼你就可以直接利用 VMware Server 進行相關的監測作業。VMware Server 提供許多詳細的資訊與圖表，可以讓管理者很方便的了解各項資源的使用狀況。充分利用這些圖表，我們可以即早發現可能出現的問題。
除了這些圖表，我們也可以透過前述的 syslog、snmp daemon、以及接下來要談的 alarm 來協助我們監測整個虛擬環境。 - 設定合適的告警 (alarm)
雖然 VMWare Server 內建的資訊與圖表可以幫助我們在需要時了解虛擬環境的狀況，但是除非你沒別的事可以幹，不然絕對是不會沒事就盯著這些圖表的。而針對一些需要管理者特別注意的狀況 (例如記憶體使用量過高)，除了可以透過圖表被動的發現外，EXSi 還會主動對管理者進行提示。很可惜的是這些提示預設只顯示在 VMware Client 的介面上，也就是說除非你一直盯著 VMware 的管理介面，否則還是不會發現這些善意的提醒。因此我們必須將一些重要的告警設定為其他的通知方式 (如寄發 email、snmp trap 等)，好在問題發生的第一時間就能加以掌握。 - 使用作業系統的磁碟加密功能 在大部分的情況下，虛擬機的硬碟其實是對應到所謂的 VMDK 檔案。在這個 (些) VMDK 檔案內，包含了 Guest OS 所有存放於硬碟內的資料。也就是說，在實體環境中偷取硬碟的困難工作，在虛擬環境中變成了只要複製 VMDK 檔案的簡單動作。除了複製檔案遠較實際偷取硬碟簡單外，非授權複製行為的發生也比硬碟失竊更難以被管理者所發現。我們可以採用作業系統內建的硬碟加密功能，以大大降低 VMDK 檔案不幸遺失時所造成資料外洩的可能性。現今大部分的作業系統都已經內建硬碟加密的功能，千萬不要吝於使用了。
- 備份檔案也別忘了加密
就像實體環境中的備份資料需要與原本資料同等的安全性要求，虛擬環境下的備份也是如此。因此我們可以採用加密的技術來保護這些備份的資料 (通常可能是 VMDK 的檔案)，以避免有心份子透過備份檔案取得重要的機密資料。加密除了可以避免有心份子對於資料的誤用，同時也可以避免有心份子竄改備份資料。此一保護措施對於那些沒有使用前述硬碟加密技術保護的 VMDK 檔案來說顯得格外重要。 - 保護好你的 datastore ESXi 利用 datastore 來存放各式各樣的資料，包含虛擬機的檔案 (如 VMDK 與設定檔)、虛擬機所使用的光碟/軟碟映像檔、以及虛擬機的記憶體交換檔 (swap file)。因為 datastore 不只用來存放 VMDK 檔案，因此即使我們已經使用 Guest OS 的硬碟加密技術來保護其內的資料，對於 datastore 的保護依舊馬虎不得。這裡所謂的記憶體交換檔，指的並不是 Guest OS 內所使用的交換檔，而是 ESXi 為了因應無法利用實體記憶體來完全滿足虛擬機所設定的記憶體時的一種模擬技術。Guest OS 並不知道這些檔案的存在，而且這些檔案包含了存放於 Guest OS 記憶體內的資料。這種檔案預設與虛擬機其他檔案存放在同一個目錄之下，在保護上必須多加小心。
至於如何保護 datastore，則根據 datastore 屬於 Local Disk、SAN 或 NFS 架構而在作法上有所不同。 - 使用強化過的版型 (Template) 來建立新的虛擬機
雖然我們可以在每次建立虛擬機的時候，透過傳統的方式重新安裝一套可供運行的 Guest OS，但這並不是很有效率的作法，比較建議的作法是利用已經存在的虛擬機來產生新的虛擬機。實際上常用的作法有二，一種是利用複製的功能，將虛擬機複製出一個新的虛擬機。另外一種則是利用版型 (Template) 的方式，利用版型創建出新的虛擬機。嚴格來說，版型與一般的虛擬機沒有什麼多大的差別，最大的不同之處在於我們無法開啟 (Power-On) 版型，所以可以有效避免無意間開機與修改動作的發生。這樣的特性讓管理者可以輕鬆地建立出各種 Guest OS 的基本安裝與設定，並加以妥善防護，以便在需要時可以快速建立出合乎企業安全需求規範的虛擬機與 Guest OS。 - 修改 Guest OS 的設定
除非是新建的虛擬機，否則不管是透過複製 (Clone)、匯入 (Import)，甚至是從樣板 (Template) 所建立的虛擬機，都繼承了原有虛擬機內 Guest OS 的全部設定。雖然在這些過程當中，有些設定可以改變，但是大部分的設定依舊必須進入 Guest OS 後才能加以修改。這些設定包含(但不局限於)： - 主機名稱。
- 網路設定，尤其是 IP 位址。
- 主機對應檔 (hosts 檔)。
- 主機的防火牆設定。
- 存取限制 (/etc/hosts.deny 與 /etc/hosts.allow)。
- ssh daemon 的金鑰設定值。
- 個人的 ssh 設定，包含 known_hosts 與 authorized_keys。
- 謹慎地佈署從別處取得的虛擬機檔案
現今有些軟體是以虛擬機檔案的方式加以發佈，這種形式通常又稱之為 Virutal Appliance。在我們將這些 Virtual Appliance 實際佈署到我們的環境前，首先當然必須根據前述要點進行必須要的設定修改 (如果廠商沒有提供類似的安裝程序)。除此之外，我們也必須確保虛擬機所連結的虛擬交換器 Port Group 其安全設定符合標準。除非有特殊的考量，否則此 Port Group 的三個安全選項應該都設定為拒絕 (Reject)。甚至我們可以考慮將此虛擬機置於獨立的 Port Group，以減少發生問題的機會。 - 關閉用不到的系統
有一句話是這樣說的，鎖在保險箱並避免與外界有任何接觸的系統才是最安全的。在虛擬環境下，雖然我們沒有辦法把虛擬機鎖在保險箱之內，但是我們還是可以在系統不需使用時加以關閉。儘管這種作法也適用於實體的環境，但是在虛擬環境下我們不需要特別的設備就可以輕鬆地從任何地方完成開關機的動作。如果搭配腳本的使用，我們甚至可以做到系統使用前自動開機，並於使用完畢後加以關閉 (或暫停)。這種作法對於一些處理重要資料的系統而言，顯得格外有效。 - 使用密碼保護開機韌體 (BIOS/EFI)
在大部分的情況下，管理者可能不會意識到虛擬機內也有 BIOS 的存在。儘管如此，ESXi 確實在虛擬機內提供了 BIOS 的功能。除了提供 BIOS 的選項，ESXi 還提供新的開機韌體 EFI。不管使用哪種開機韌體，因為虛擬機並沒有實體的主控台 (Console)，只要連上主機或 VMware Server 就可以存取到對應的虛擬主控台，因此傳統上的實體保護措施並沒有辦法發揮效果。也因此在虛擬環境下，主控台的其他安全防護措施就顯得格外重要。其中一個最重要的步驟，就是利用密碼功能來保護開機韌體，以避免有心份子修改開機韌體的設定，造成非預期行為的發生。 - 避免使用自動登入的功能
同樣因為虛擬機使用了虛擬主控台，所以一旦 Guest OS 採用了開機自動登入的設定，任何連上主機或 VMware Server 的使用者都可能可以直接獲得系統的存取權限。 - 使用完畢一定要記得登出系統
理由同上。尤其是透過虛擬主控台登入系統時，更是千萬要記得在使用系統完畢後立即進行登出的動作。 - 設定密碼保護的螢幕保護程式
理由同上。此一措施應視為登出要求未被遵守時的補救措施，而非用來取代登出要求此一安全措施。 - 嚴格限制帳號本機存取的權限 理由同上。
- 關閉不需使用的外接設備 對虛擬機而言，大多數的外接設備都支援熱插拔的功能。即使是一般實體環境下大多不支援熱插拔功能的設備 (像是 IDE 光碟機、IDE 軟碟機、網卡等)，在虛擬環境下也都支援了熱插拔。正因為外接設備易於插拔，所以我們可以在不需使用這些外接設備時加以關閉，並於需要時重新連結即可。這些所謂的關閉，並非從 Guest OS 內加以移除或是停用，而是直接從虛擬機的設定加以關閉。這些被關閉的設備，在再次被開啟之前，都無法被 Guest OS 所使用。舉例來說，當我們不需使用到光碟機的時候，就可以關閉光碟機的連結，以避免有心份子讀取到非授權的資料。
- 將虛擬環境的安全需求整合至原有的安全政策之內
虛擬化前的安全政策，都應該繼續存在於虛擬化後的環境中。原因在於一般虛擬化並非 100% 的虛擬化，而是實體與虛擬共存，因此原有針對實體環境所設置的安全政策依舊有其存在的必要性。即使是 100% 虛擬化的環境，原有的安全政策也多必須予以保留。包含管理面、實體層次、作業系統層次、應用系統層次的安全政策，在虛擬環境下都還是會面臨到同樣的安全問題。舉例來說，在虛擬環境下備份整個 Guest OS 是件相當簡單且必要的事情，但是 Guest OS 的備份並不能用來取代傳統的備份機制。傳統的備份方式，可以讓我們在必要時快速找到所需的資料 (如某個檔案)，而這是 Guest OS 備份很難做到的事情。所以虛擬化之後應該是針對原有的安全政策做出相對應的新增與修正，以期達到一致性的安全水平。
沒有留言:
張貼留言