更改管理流程的一個主要目標是:確保受即將實施的更改影響的所有各方都注意到並了解更改所產生的影響。 由於大多數系統是密切相關的,在系統的一個部分中進行的更改可能會對另一部分產生深遠影響。 為了緩解或消除所有負面影響,更改管理將在部署更改前先嘗試確定所有受影響的系統和過程。 通常,目標(或托管)環境是生產環境,但還應該包括關鍵集成環境、測試環境和臨時環境。
對 IPsec 環境的所有更改都應遵循以下標准 MOF 更改管理過程:
1.
更改請求。 通過提交更改請求 (RFC),正式啟動更改。
2.
更改分類。 根據更改在基礎結構或用戶方面的緊急程度和影響程度來分配更改的優先級和類別。 這一指定會影響實施速度和路由。
3.
更改授權。 由更改管理者和擁有 IT 與業務代表的更改審批委員會 (CAB) 考慮更改並批准或否決它。
4.
更改開發。 規劃和開發更改的過程,其規模有大有小,並包括關鍵的階段性審核。
5.
更改發布。 將更改發布並部署到生產環境。
6.
更改審查。 實施過程後的行為,它審核更改是否達到了為其設定的目標,並確定是保持更改有效還是取消。
下節描述在您的 IPsec 環境中很可能需要定期進行的某些關鍵更改的更改開發過程。 每個更改開發過程都將有一個配套的更改發布過程來描述如何將更改部署到生產中。
更改 IPsec 策略了解在 IPsec 策略中所進行的更改如何影響通信是很重要的。 在初始部署時,首先要考慮的問題是更改時間,因為這個時間會影響實施更改的能力及回滾更改的時間段。
策略應用延遲當組策略對象 (GPO) 中的 IPsec 策略分配被更改為新的 IPsec 策略時,會發生某些延遲。 有域中包含分配的 GPO 屬性的 Active Directory 復制延遲,也有檢測 GPO 中的更改的域成員組策略客戶端的輪詢延遲。 這些延遲的范圍從小位置中的不足一分鐘到全球企業中的幾小時不等。 Microsoft 建議為您的特定環境測試和記錄這些延遲(最小、最大和中等延遲),以便在進行更改時可預計首次影響和整個部署所需的時間。
當已分配的 IPsec 策略的內容被更改時,也會發生類似的延遲。 有 IPsec 策略對象的 Active Directory 復制延遲,也有成員計算機上的 IPsec 策略服務的輪詢延遲。 可創建這樣一個條件:在復制 IPsec 策略之前復制 GPO 中的策略分配,這將導致客戶端似乎已分配基於域的 IPsec 策略 — 但它們無法檢索該策略。 在這種情況下,Windows 2000 和 Windows XP 主機將無法應用基於域的策略。 也將無法應用可能被分配的任何本地策略。
為了完全地適應 Active Directory 復制延遲,請確保先創建所有對象(GPO、IPsec 策略等),然後將 IPsec 策略分配到 GPO 中。
影響 IPsec 連接性的更改有很多領域可影響組成 IPsec 解決方案的策略和組內的連接性。 本節提供有關在客戶端可能沒有最新更新時,從更改服務器策略的角度來看常見更改如何影響 IPsec 連接性的信息。 如果某項更改導致 Internet 密鑰交換 (IKE) 主模式或快速模式失敗,則一旦當前 IPsec 安全關聯 (SA) 空閒或它們以字節或秒為單位的生命周期已過,通信流就會停止。
此討論包括大多數更改類型對 IPsec 客戶端服務器功能的影響。 不假定 Woodgrove Bank IPsec 策略設計。 針對此討論,客戶端可能有類似於 Woodgrove Bank 設計(其中客戶端有可啟動 IKE 到服務器的篩選器)的策略或它們可能僅使用默認響應規則(在 Woodgrove 設計中不使用)。
主模式更改更改身份驗證方法或主模式安全措施將導致 IKE 刪除現有主模式,但不會影響已建立的快速模式 IPsec SA。 重新生成下一個快速模式密鑰時將生成新的主模式 SA。
通常,服務器策略更改不會影響現有客戶端重新生成主模式密鑰的功能。 但對服務器方進行的某些更改會導致 IKE 主模式與客戶端協商失敗,這些更改包括:
•更改為新的身份驗證方法(僅適用於證書),不包括客戶端可使用的舊身份驗證方法。
•更改為 3DES/SHA1/DH1 或 DH2,在客戶端被配置為僅使用 DES/SHA1/DH1 時作為主模式安全措施。
•激活主模式完全向前保密 (PFS),不更新客戶端和服務器策略,以避免二者都使用主模式 PFS。
•激活快速模式 PFS,不更新客戶端和服務器策略,避免二者都使用快速模式 PFS。
下列服務器策略更改將不影響客戶端重新生成主模式 SA 密鑰的功能:
•策略更改的輪詢間隔(因為不是主模式 IKE 設置)
•使用相同主密鑰的會話密鑰(例如,每個主模式的 IKE 快速模式數量)
•添加客戶端不知道的新安全措施
•更改 IKE 主模式 SA 的“身份驗證和生成新密鑰”生命周期參數的 IPsec 策略高級密鑰交換設置。
快速模式更改在用於 IPsec SA 的篩選器操作中所做的更改將導致在那些策略設置下建立的現有 IPsec SA 被刪除。 因此,如果通信流正在傳輸,則嘗試使用新的快速模式。 在此更改過程中可能會丟失一些通信流,但 TCP 連接應該會恢復。 但在高速傳輸數據時,立即刪除 IPsec SA 會導致出站通信流中斷,直到建立新的快速模式才恢復正常。 例如,從視頻數據流突然增加數據包(TCP 無法恢復)將導致視頻應用程序的連接需要重置。
以下服務器策略更改將影響活動 IPsec 客戶端重新生成快速模式密鑰的功能:
•將普通篩選器更改為特定篩選器。 這種更改的一個示例為:服務器以所有通信流篩選器開始,再刪除它,保留僅 TCP 篩選器。 為了避免麻煩,添加特定篩選器時保留現有的普通篩選器。 例如,如果客戶端帶有默認響應策略並且服務器帶有從“所有通信流”更改為“僅 TCP”的策略,則特定篩選器將取決於服務器上的出站通信流,這將在客戶端進行默認響應時為僅 TCP 建立新的 IPsec SA。 所有客戶端上的“所有通信流”篩選器最終將被刪除(兩個小時後),然後可在服務器策略中安全地刪除它。
如果服務器添加了具有允許操作的特定篩選器,則該通信流將允許立即開始傳輸並且可能被帶有普通 IPsec 默認響應篩選器的客戶端中斷。 例如,免除 Internet 控制消息協議 (ICMP) 的篩選器已被添加到服務器中,但客戶端已確保了到服務器的所有通信流安全。 在這種情況下,客戶端將確保其出站 ICMP 的安全、接收回復的明文 ICMP 並中斷數據包,因為當前 IPsec 默認響應篩選器要求所有通信流都必須安全。 此特定示例不會影響服務器和客戶端之間的任何通信流(除 ICMP 通信流外),並且將如預期設計的那樣在服務器請求客戶端的所有通信流都安全之後始終生成丟失的 ICMP 通信流。 這可能是一個嚴重的操作問題,也可能不是。
•在不兼容安全措施之間或封裝類型之間更改。 例如,從 ESP 傳輸模式的僅 3DES/SHA1 到 ESP 傳輸模式的僅 3DES/MD5。 通過在新安全措施中包括舊安全措施或封裝類型作為最後的選擇,可避免由這種更改類型而導致 IKE 快速模式協商失敗。 在觀察到所有 IPsec SA 都在使用新封裝方法之後,可刪除安全措施列表底部的舊措施。
•完全禁用客戶端建立 IKE 主模式或快速模式所需的規則。 在快速模式下,篩選器將被刪除,以便其他篩選器或沒有篩選器來管理 IKE 主模式和快速模式協商。
•完全將篩選器操作從協商安全性更改為允許或阻止。 明確允許或阻止的通信流將不需要重新生成密鑰,因為通信流將不再參與由 IPsec 保護的通信通道。
•清除“回退到使用明文”復選框。 此操作將導致只要軟 SA 持續下去當前連接的客戶端就一直保持連接。 SA 到期或空閒後,將有更多服務器出站通信流會導致 IKE 嘗試進行新的主模式協商並確定不回退的新設置。 不可對 IKE 協商成功響應的客戶端將無法連接。 這可能是預定行為。
•清除“允許不安全的通信”復選框。 如果某些客戶端沒有 IPsec 篩選器啟動出站 IKE 主模式,則此操作將導致這些客戶端斷開連接。 默認響應規則客戶端將一直保持連接,直到其動態默認響應篩選器在兩小時沒有通信流傳輸到服務器後空閒下來並無法重新連接時才斷開。
下列服務器策略更改將不影響客戶端重新生成快速模式密鑰的功能:
•添加與已在當前 IPsec SA 中的通信流不匹配的篩選器將不影響該通信流。 例如,如果允許將篩選器添加到域控制器的新 IP 地址的服務器策略中。
•更改以字節或時間為單位的篩選器操作 IPsec SA 生命周期。
•將篩選器操作從“允許”更改為“協商”安全性。 如果客戶端可響應,它們將仍能夠為該通信流協商安全連接。
IPsec 策略更改步驟下列各節提供修改通過使用 GPO 發送的 IPsec 策略的步驟。 雖然每個任務給出的步驟使用 IP 安全策略 Microsoft 管理控制台 (MMC) 管理單元,但通過使用 Windows Server 2003 系統上的 Netsh 命令行工具也可完成這些任務中的每個任務。
Microsoft 建議將 Windows Server 2003 平台作為策略管理站,因為該平台提供了用於編制腳本和監視的最佳功能。
Windows IPsec 策略導出和導入的目的在於執行備份和恢復。 導出功能復制存儲位置中的所有 IPsec 策略對象,以確保在備份中捕獲所有相關對象。 要將所有當前域策略移到本地存儲中進行測試,建議使用導出。 因為有可能會出錯,因此在使用導出功能之前,從本地存儲中刪除每個不想