Windows Server 2012的AD虛擬化安全
各位讀者朋友,有多少人嘗試過對Active Directory(簡稱AD)進行虛擬化?如果答案是肯定的,你又是否了解或閱讀過微軟公司針對AD虛擬化所提供的指南、清楚哪些事情該做而哪些不該做?這就是我們本文要討論的內容。根據微軟的客戶服務及支持說明,AD是整個Windows Server中引發求助請求最多的項目,而AD虛擬化又是AD當中最令人頭痛的話題(至少是之一)。
看看,大家的懶惰引發多少麻煩。好消息是Windows Server 2012已經對AD進行了改進,這就讓使我們在偷懶的同時保證公司的業務體系更加安全。
除非大家把時間都花在喝茶扯淡上了,否則作為一位IT人,我們都應該會注意到虛擬化技術逐步覆蓋數據中心的逼人氣勢。歷史最悠久——因此也最發達——的虛擬化領域正在于服務器層面。另外,由于虛擬化是云計算的基本構成要素之一,它的普及自然也受到云崛起的積極影響。
如果大家本身就是AD管理員,那么這一趨勢就意味著虛擬化團隊正嘗試把我們手中的AD域控制器(簡稱DC)也拉進虛擬領域。AD管理員從本質上說屬于對風險非常敏感且時刻準備回避的人群(如果我們能面對面交流,我會詳細講解自己——當然不光是我一個人——如何在防御層的眼皮底下管理三萬個英特爾用戶賬戶的更新工作),所以我們對虛擬化介入的***反應很可能是拒絕的——你不能讓我用我就用。然而搞虛擬化的家伙卻非常頑固,他們不接受簡單的拒絕,而是希望了解哪些因素阻礙了將整個AD體系納入虛擬機的步伐。在英特爾的工作經歷中,我成功捍衛了自己的觀點。那時候我興趣出了兩個至關重要的理由,其中一個直到今天仍然適用,而另一個則已經被時間所化解。
對AD虛擬化持謹慎態度的原因
安全性是首要原因。當我回絕虛擬化團隊的建議時,提出了兩點安全性方面的關注重點:客戶虛擬機隔離與主機管理。我們之所以關注客戶機之間的安全問題,是因為我們并不完全相信虛擬機之間無法互相訪問及滲透的說法。不過隨著服務器虛擬化技術的日益成熟,這個問題如今已經不再是問題。但第二點理由——關注與主機管理相關的操作安全——目前仍然存在,而且將在可以預見的未來始終扮演不容忽視的重要角色。
主機管理的操作安全如今用更平實些的話來解釋,是指我們的虛擬化主機服務器管理員不一定了解與虛擬化AD域控制器有關的注意事項與維護方法。在所有現存的Windows Server版本當中,服務器主機或虛擬化管理員都可以輕松搞砸我們所安裝的AD——具體方式包括使用基于鏡像的恢復、快照回滾或者虛擬域控制器副本等虛擬產品基礎功能。
Windows Server 2008 R2及更早版本分布式特性使其無法理解并接納虛擬化產品給虛擬域控制器帶來的狀態變更,因為這些在物理域控制器當中是不可能存在的。正是由于缺乏理解,其設計思路也就沒有把這些變更作為考慮事項。分布式系統的邏輯架構可能喪失完整性(尤其是在USN回滾方面),而且一般說來AD數據完整性問題既難于檢測、也不易恢復。微軟公司曾經發布過一篇題為《在Hyper-V中運行域控制器》的綜合性文章,詳細討論了虛擬化域控制器的管理話題——其中還對USN回滾以專門章節加以闡述。
Server 2012如何保障AD虛擬化安全
讓AD在虛擬環境中獲得可靠的安全性是AD團隊追求的首要目標,而他們在Server 2012中也用實際表現回應了我們的呼聲。他們提高的不僅僅是安全全,而且讓AD有能力享受由虛擬化功能帶來的一切優勢。從概念上講,整個實現方式其實并不復雜。首先,我們需要明確回滾操作的發生時間;其次,域控制器必須既保持完整性又能夠正常實現功能。
為了實現***項要求,執行變更的層(也就是管理程序)需要標記回滾的發生時間,并通過虛擬化堆棧將其作為通信內容。應用程序隨之進行接收。這個過程顯然需要開發人員對管理程序、OS以及AD應用程序的設計做出改變。這種標記機制被稱為VM-GenerationID。
這套VM-GenerationID(或簡稱為VM Gen ID)是一個128位的值,其中包含著當前虛擬機的狀態,由管理程序保有。當虛擬機隨時間推移而不斷發生變化,VM Gen ID卻始終保持初始狀態。一旦虛擬機發生回滾——無論是基于鏡像還是快照——該ID才會有所變動。這個ID映射虛擬機內存中的某個地址,因此隨時可被虛擬中運行著的應用程序所調用。那么域控制器怎么會知道自己的VM Gen ID有沒有發生改變呢?當Server 2012域控制器進行初始化(或更新)時,它會在安裝時把VM Gen ID標記的值保存在AD副本中域控制器計算目標的msDS-GenerationID屬性當中。這樣當域控制器重新啟動或處理事務(例如屬性更新)時,它就會將內存中的現有VM Gen ID值與保存在AD中的值進行比較。倘若二者不同,則意味著虛擬機已經進行過回滾,而域控制器必須采取相應步驟以保持其完整性。VM Gen ID獨立于管理程序之外,而且已經有一些管理程序供應商(例如VMware)開始將這項功能集成到自家產品當中。
一旦檢測到虛擬機回滾現象,域控制器會執行兩項操作以防止USN回滾:首先,重置AD數據庫的invocationID并清空其本地相關標記(簡稱RID)池。如果標準恢復流程與域控制器有所沖突,那么同時觸發invocationID(即本地數據庫的版本號)重置以排除其它機制,這就確保了域控制器始終擁有與其它域控制器一致的更新內容(包括它自己創建的新內容),最終免受回滾操作所影響。RID池是指利用RID主控機制整理的與域控制器相關的數百個RID(域惟一SID的一部分),旨在針對域控制器所創建的新安全原則生成SID。清空RID池與重新整理RID主控對象確保了域中不存在重復的SID。請注意,上述流程并不會危及我們的定期備份機制。
從技術角度講AD是能夠實現全面虛擬化的,但截至本文發稿時,微軟的AD團隊還沒有最終決定以官方形式公布這一結論。但大家是否愿意對AD進行全面虛擬化?在做出決策之前,大家***從宏觀角度審視這一問題。現代化數據中心已經(或者必然將要)在AD服務與不可靠的硬件之間搭建起一個又一個抽象層。大家一定還記得“把雞蛋放進一個籃子”原則:審視服務之下的每個層,解決各個層在模擬故障時帶來的技術問題、弄清楚意外情況對服務造成的影響,并以此為依據制定服務配置方案。
舉例來說,大家應該考慮在基礎設施中的某些關鍵部位采用多套虛擬化方案,這樣一旦某套方案發生故障(例如VMware ESXi內核驅動程序損壞或者Hyper-V主分區崩潰等),對于整體服務而言都不屬于單點失效。在虛擬機方面也是如此,盡量使用多臺不同的主機及不同類型的虛擬化產品,并把它們保存在同一套SAN當中。如果解決某種問題的惟一途徑是采用一些物理域控制器,那也不必猶豫,放手大干吧。即使虛擬化團隊表示反對,聲稱(可能屬于他們的次級管理范疇)物理設備的存在有可能提高基礎設施的運營成本,但相對于突然某一天公司上上下下無法登錄賬戶的巨大風險,這點支出還是非常值得的。
Server 2012的Active Directory域服務(簡稱AD DS)讓我們少了些焦慮心、多了份安全感。但是對于任何一種新功能,我們都需要結合基礎設施實際情況加以權衡,最終決定如何使其發揮***效果、實現***價值。