附錄 B:SMS 憑證基礎結構 (Microsoft Systems Management Server 2003 的方案和處理程序:安全強化指南)

附錄 B:SMS 憑證基礎結構

發佈日期: 2004 年 1 月 9 日

為保護網路上的資料,您可以簽署資料,以免資料在傳輸過程中被攻擊者改變內容。同時,您也可以加密資料,以防攻擊者利用網路監視器等網路通訊協定分析程式讀取該資料。

如要加密資料,則需使用金鑰。金鑰是用來變更演算結果的一串位元。「對稱式」金鑰表示加密與解密資料的金鑰相同,而「非對稱式」金鑰則是在運算邏輯上相關的兩把金鑰,一把用於為資料加密,另一把用於為資料解密。非對稱式的金鑰通常指的是公開/私密金鑰組。用來為資料加密的金鑰為公開金鑰,因此每個人皆能使用該金鑰為資料加密。然而,用來為資料解密的金鑰受到安全保護且不能公開取得,唯有私密金鑰的持有人才能執行解密功能。

另外,金鑰也可用來為資料加上數位簽章,以確認資料未受變更。一般來說,資料會先經過雜湊處理。雜湊功能是一種加密程序,將各種長度的資料加密成為固定大小的資料串;此資料串即稱為「雜湊」。雜湊有時也稱為「摘要」。傳送已簽署的資料時,寄件者將資料雜湊化,用私密金鑰簽署資料後,再一同寄出資料和其雜湊。收件者將收到的資料雜湊化之後,再使用公開金鑰為已接收的雜湊解密。如果兩項結果相符,表示資料寄件者已經過確認 (假設私密金鑰未被洩漏) ,同時也確認該資料自加上簽章以來未受變更。即使小如一個字元的資料變更都意味著兩項雜湊不會相符,而該資料可能已被洩漏。

「憑證」,有時又稱「數位憑證」,是一份數位文件,通常用於對開放網路 (如:網際網路、外部網路和內部網路) 的資訊進行驗證以及安全交換。憑證會將公開金鑰繫結在具有對應私密金鑰的實體上。例如,您可將憑證附在已簽署的電子郵件訊息中寄出。收件者則利用該憑證來確認訊息寄件者。您也可以利用該憑證內含的公開金鑰來簽署、加密或解密資料。

本頁內容

SMS 密碼編譯

用戶端管理點驗證

進階用戶端原則簽署

簽署下載及執行的封裝

站台間的通訊簽署

用戶端驗證與加密

SMS 密碼編譯

Microsoft Systems Management Server (SMS) 2003 不需要公開金鑰基礎結構即可管理憑證。除了用來為通報點流量加密的 SSL 憑證之外,SMS 站台系統會維護自己的憑證基礎結構與公開/私密金鑰組。

簽署並加密 SMS 上的通訊可減輕數種類型攻擊的影響。

表 B.1   SMS 加密如何減輕攻擊的影響  

潛在攻擊

SMS 減輕影響對策

建立未經授權的管理點,並將用戶端導向該管理點。

利用憑證來對用戶端驗證管理點。

竄改進階用戶端原則。

由管理點簽署原則。

竄改已下載的軟體發佈套件。

簽署預定下載和執行的套件。

模擬或「偽造」父系或子站台伺服器。

站台間的通訊可以加上簽章,且能夠要求執行安全的金鑰交換。

公開帳戶認證資訊。

加密儲存在站台控制檔中的帳戶資訊。

傳送未經授權的用戶端詳細目錄。

進階用戶端使用憑證來驗證管理點和簽署其詳細目錄。1

讀取網路上的用戶端詳細目錄。

進階用戶端為詳細目錄加密後,再傳送至管理點。1

1. 此功能須安裝 SMS 2003 SP1。

用戶端管理點驗證

管理點必須向用戶端驗證,以防攻擊者插入未經授權的管理點,並將用戶端導向該管理點。當管理點建立時,它同時會建立用於簽署的憑證。該憑證為自動簽署的憑證,效期 99 年。憑證建立後,會儲存在管理點的憑證存放區。

當進階用戶端從管理點接收訊息時,用戶端會使用下列兩種方式的其中一種來驗證訊息來自有效的管理點。使用 Active Directory 或受信任的根目錄機碼即可驗證訊息。

什麼是受信任的根目錄機碼?

如果 Active Directory® 架構尚未延伸,且 SMS 沒有在 Active Directory 中發行的權限,進階用戶端會改用另一種方式來驗證管理點和其憑證的真實性。每個主要站台伺服器會產生受信任的根目錄機碼。如果主要站台已加入父系站台,則會消除自己的受信任根目錄機碼,轉而信任父系站台的受信任根目錄機碼。受信任的根目錄機碼功能近似於公開金鑰基礎結構中的根憑證。藉由使用受信任的根目錄機碼組的私密金鑰來簽署管理點憑證,以及藉由向進階用戶端提供受信任的根目錄機碼組的公開金鑰副本,用戶端能夠區分有效管理點和未經授權的管理點。如果 SMS 的 Active Directory 架構未延伸,進階用戶端僅會要求受信任的根目錄機碼。受信任的根目錄機碼儲存在 root\ccm\locationservices 目錄下的 WMI 中。

管理點如何取得受信任的根目錄機碼?

當新管理點建立時,其自動簽署的憑證會儲存至登錄中的某一位置。站台元件管理員從登錄中收集憑證,並將其憑證傳送到其站台伺服器。如果站台伺服器不是中央站台,憑證會被一層層地往上傳送,直到傳送到持有受信任的根目錄機碼的中央站台為止。中央站台伺服器以受信任的根目錄機碼簽署管理點的憑證後,再將憑證和受信任的根目錄機碼的副本一層層地往下送回管理點。當管理點接收受信任的根目錄機碼時,會使用自己的私密金鑰簽署受信任的根目錄機碼。如同本文稍後要討論的,這有助於復原能力。在此處,管理點擁有數種金鑰:

  • 管理點的自動簽署憑證

  • 由受信任的根目錄機碼所簽署的管理點憑證

  • 來自中央站台的受信任根目錄機碼副本

  • 由管理點的私密金鑰所簽署的受信任根目錄機碼副本

進階用戶端如何驗證管理點?

進階用戶端將下列金鑰及憑證資訊依類別儲存在 WMI 中:

  • 用戶端信任的管理點清單

  • 管理點清單中每個管理點的資訊,包含管理點憑證在內

  • 受信任的根目錄機碼

當進階用戶端從管理點提出要求時,會嘗試驗證回應。首先進階用戶端會檢查站台碼。如果站台碼有效,進階用戶端會查看管理點是否列於 WMI 的管理點清單中。如果已在清單中,進階用戶端會嘗試從 WMI 擷取一份管理點憑證的副本。假設進階用戶端找到憑證,即可驗證訊息。每個訊息都必須經過驗證,否則會被捨棄。

如果用戶端的 WMI 中未存有管理點憑證,用戶端會檢查管理點清單的最近更新時間。如果距離最近更新時間超過五分鐘,用戶端會擷取一份新的管理點清單。此外,如果 WMI 中沒有管理點清單,用戶端也必須擷取一份管理點清單。如表 B.1 所示,用戶端擷取管理點清單的位置會因用戶端模式和 SMS 的 Active Directory 架構是否已被延伸而異。

藉由安裝內容 SMSDIRECTORYLOOKUP=<參數> 來執行用戶端安裝,用戶端能夠被設定為三種模式之一。如果未指定參數,用戶端會以 [Secure WINS] 模式安裝。[Active Directory Only] 模式是最安全的模式,但只能在您已擴充架構的情況下使用。[Any WINS] 模式不安全,因此不建議您使用。表 B.2 說明每種模式與相關的管理點驗證程序。

表 B.2   管理點驗證程序

模式

參數

管理點驗證程序

Active Directory Only

NOWINS

進階用戶端只從 Active Directory 擷取管理點清單。如果進階用戶端無法從通用類別目錄伺服器擷取清單,則對應失敗,用戶端須等到通用類別目錄伺服器上的 SMS 資訊可供取得之後,才能和管理點進行通訊。

Secure WINS

WINSSECURE

進階用戶端先嘗試從 Active Directory 擷取管理點清單。如果嘗試失敗,則用戶端會向 Windows 網際網路名稱服務 (WINS) 要求管理點清單。用戶端接著會與清單上的預設管理點聯繫,要求管理點憑證。用戶端檢查自己在 WMI 中的受信任根目錄機碼副本,以驗證該憑證已由受信任的根目錄機碼簽署。如果憑證有效,用戶端會建立信任關係,並以此來驗證來自該管理點的訊息。如果管理點憑證上的簽章與用戶端的受信任根目錄機碼副本不符,用戶端會捨棄來自該管理點的訊息。

Any WINS

WINSPROMISCUOUS

進階用戶端先嘗試從 Active Directory 擷取管理點清單。如果擷取失敗,用戶端會向 WINS 要求管理點清單。然後用戶端會聯繫清單上的預設管理點,且不經任何憑證檢查便信任該管理點。

關於使用進階用戶端安裝程式的更多資訊,請參閱《Microsoft Systems Management Server 2003 的方案和處理程序:規劃及部署》中的<附錄 I:安裝與設定 SMS 用戶端>。

進階用戶端如何取得受信任的根目錄機碼?

在 SMS 2003 SP1 中,使用下列方式安裝的用戶端會在安裝期間自動接收受信任的根目錄機碼,無須要求安全安裝的其他動作。

  • 登入由指令碼啟動的用戶端安裝 (Capinst.exe)

  • 手動用戶端安裝 (Ccmsetup.exe)

  • 用戶端發送安裝

如果您使用 Windows 群組原則安裝 (Client.msi),則必須執行其他步驟,以確保進階用戶端在安裝期間會接收受信任的根目錄機碼。相關程序,請參閱<附錄 E:SMS 安全性程序>中的<使用 Windows 群組原則安裝方式 (Client.msi) 安裝受信任的根目錄機碼>。

如果進階用戶端尚未收到受信任根目錄機碼的副本,進階用戶端會向管理點要求一份副本。如果用戶端無法擷取受信任根目錄機碼的初步副本,用戶端將會信任由管理點提供的憑證。

在沒有受信任根目錄機碼的情況下,用戶端可能會被誤導至攻擊者的管理點,而接收來自未經授權的管理點的原則。上述很有可能是深思熟慮的攻擊者會採取的行動,而且可能會在用戶端從有效管理點擷取受信任根目錄機碼之前的有限時間內發生。

進階用戶端如何重新整理受信任的根目錄機碼?

進階用戶端取得受信任的根目錄機碼副本後,會將副本存放於 WMI 中。用戶端會定期重新整理受信任的根目錄機碼,捨棄目前的管理點憑證,並取得由受信任的根目錄機碼所簽署的新憑證副本。

進階用戶端如何從中央站台故障中復原?

如果中央站台需要復原,此站台會產生新的受信任根目錄機碼。來自階層內所有管理點的憑證會被收集並傳送至中央站台,由受信任的根目錄機碼簽署後,再傳回各管理點。因為用戶端信任管理點,因此會接受新的受信任根目錄機碼。如果用戶端連絡一個不信任的管理點,用戶端將不會接受來自該管理點的資訊。用戶端會保持離線,直到它能夠連絡受信任的管理點並接收新的受信任根目錄機碼為止。

如果沒有可供用戶端連絡的受信任管理點,則可能會發生問題。例如,用戶端可能會向兼有站台管理點功能的中央站台伺服器報告,表示站台伺服器故障。這種情況通常發生在小型的部署架構中,其中只有一個站台,而站台伺服器執行站台的所有功能。在站台伺服器系統故障的情況下,為了進行復原,您必須建立新管理點的新受信任根目錄機碼及新憑證。進階用戶端沒有受信任的管理點或根目錄機碼,也沒有可以取得上述兩項目的機制,在與新管理點建立信任關係前將不會運作。

如果要復原用戶端,您必須依照以下說明移除舊有的受信任根目錄機碼,然後依<附錄 E:SMS 安全性程序>中的<重新安裝受信任的根目錄機碼>安裝新的受信任根目錄機碼,或是如<表 B.2 管理點驗證程序>所述,允許用戶端自動取得機碼。

如何從用戶端移除受信任的根目錄機碼?

如果進階用戶端持有的是錯誤的受信任根目錄機碼,而且沒有可取得有效的新受信任根目錄機碼的管理點,則您必須從用戶端刪除受信任的根目錄機碼。另外,如果您計畫將用戶端從一個站台階層移至另一站台階層,您也必須先移除受信任的根目錄機碼。

以 RESETKEYINFORMATION 參數執行 CCMSetup 可從 WMI 刪除受信任的根目錄機碼。您必須在用戶端本機上執行此動作,因為在用戶端有受信任的管理點之前,軟體發佈功能不會運作。執行此項參數需要進階用戶端的本機系統管理權限。執行此參數後,用戶端在接收受信任的根目錄機碼之前會較容易遭受攻擊,因為用戶端無法區分站台的有效管理點和攻擊者建立的未授權管理點。如前所述,您應該重新安裝用戶端與新的受信任根目錄機碼。

進階用戶端原則簽署

因應每項影響進階用戶端的 [SMS Administrator] 主控台變更,站台伺服器上的原則提供者會產生新的原則,以及指向該原則實體的 URL 指派。原則提供者建立原則實體的 SHA-1 雜湊,並將已簽署的雜湊儲存於該指派中。

進階用戶端向管理點要求其指派,並依序下載每項原則。進階用戶端在本機上為每項原則計算其雜湊。計算後得出的雜湊會與指派提供的雜湊互相比對。如果兩者相符,原則會被接受。這有助於防範「有線」安全性攻擊,在此類攻擊中原則有可能被中途攔截及重新執行。因為用戶端和管理點之間是使用匿名 HTTP 進行通訊,所以用戶端必須確認已下載的原則為有效原則。用戶端下載原則後會檢查簽章,並使用本機產生的值比對雜湊。如果兩者相符,原則會被接受。

簽署下載及執行的封裝

進階用戶端有兩個主要的軟體安裝選擇:

  • 從網路上執行

  • 下載與執行

如果有一個通告被設為下載與執行,站台伺服器的發佈管理員服務會雜湊內容檔。原則提供者會將雜湊加入軟體發佈原則內。進階用戶端依本文件上述說明下載原則。當用戶端下載內容時,會在本機重新產生雜湊,並將其與原則所提供的雜湊互相比對。如果兩項雜湊相符,則內容未受變更,用戶端可以下載內容。如果軟體中有任意位元組遭到變更,兩項雜湊不會相符,軟體即不會被安裝。此外,此項檢查有助於確認下載的是正確的軟體,因為實際內容會與原則進行交叉比對。

note.gif  注意
此項檢查僅在下載軟體時執行。直接從發佈點安裝軟體 (從網路上執行) 的情況下,此項檢查不會執行。

站台間的通訊簽署

站台控制檔包含站台及其子站台的所有設定內容。當系統管理員變更子站台的設定時,父系站台會將控制檔內的變更傳送到子站台伺服器。如果子站台的系統管理員變更設定,則變更會以站台控制檔的型式傳送到父系站台。

依預設,站台間可以進行未經簽署的通訊。此舊版相容性讓您可以使用尚未升級到 SP5 的 SMS 2.0,但這不是安全的設定。關於變更此項設定的程序,請參閱<附錄 E:SMS 安全性程序>中的<停用站台間未經簽署的通訊>。

即使在通訊通道不安全的情況下,相關設定仍可使 SMS 自動發佈站台間的通訊憑證到父系或子站台。依預設,安全的通道不是必要條件,但為了確保安全環境,這項設定應被啟用。關於相關程序,請參閱<附錄 E:SMS 安全性程序>中的<要求安全金鑰交換>。啟用此項設定後,站台間的通訊公開金鑰可由以下其中一種方式交換:

  • 如果 SMS 的 Active Directory 架構已擴充,且 SMS 有發行到 Active Directory 的權限,則站台伺服器會自動將其站台間通訊公開金鑰發行到系統管理容器中的站台物件。

  • 如果 Active Directory 架構尚未啟用,或 SMS 沒有發行到 Active Directory 的權限,則 SMS 系統管理員必須使用 Preinst 命令列出公開金鑰,然後手動將公開金鑰複製到目的地站台。

important.gif  重要事項
自動金鑰交換不會在樹系間運作。如果站台階層超越樹系的界限,即使兩方面的樹系皆已擴充架構,且 SMS 已發行在 Active Directory 中,系統管理員還是必須手動交換金鑰。

關於相關程序,請參閱<附錄 E:SMS 安全性程序>中的<手動傳送站台金鑰>。

傳送站台控制檔之前,寄件站台建立雜湊並以其私密金鑰加以簽署。收件站台利用憑證內的公開金鑰檢查簽章,並以本機產生的值與收到的雜湊進行比對。如果兩者相符,則收件站台接受站台控制檔。如果兩值不相符,站台控制檔會被拒。

站台控制檔中的加密帳戶資訊

下列已授與權限的帳戶和密碼儲存在站台控制檔中:

  • SMS Service 帳戶

  • SMS Server Connection 帳戶

  • Client Push Installation 帳戶

如果攻擊者取得這些認證資訊,可能會導致安全性嚴重降低,因此認證資訊被加密存在站台控制檔中。站台控制檔在站台間傳輸時本身並沒有加密。儲存在站台控制檔中的其他帳戶在其他電腦上不須要求系統管理員權限,通常也只擁有非常低的權限。

note.gif  注意
藉由使用進階安全性,大部分的操作會以 LocalSystem 帳戶或電腦帳戶執行,而省去將這些帳戶認證資訊儲存在站台控制檔內的需要。SMS Service 帳戶、Site System Connection 帳戶、Server Connection 帳戶,以及 Site System Database 帳戶不在進階安全性中使用。Client Push Installation 帳戶只在用戶端發送安裝啟用時、或被 Client Push Installation 精靈啟動時使用。關於 SMS 帳戶的更多資訊,請參閱<附錄 C:SMS 帳戶、群組與密碼>。

用戶端驗證與加密

用戶端驗證與加密是 SMS 2003 SP1 的新功能。驗證和加密並不是預設啟用。這兩項功能提供更強大的安全性,但也帶來某些效能耗損和系統管理成本。啟用簽署和加密對用戶端效能的影響微乎其微。管理點可能會感受到些許的效能降低,但這對管理點可以支援的用戶端數目並不造成影響。

您必須為個別站台啟用用戶端驗證和加密。請先確認站台和所有用戶端皆已成功升級為 SMS 2003 SP1,接著啟用此階層內所有站台的加密和簽署功能,以預防漫游用戶端的詳細目錄被拒絕的問題發生。一旦啟用用戶端詳細目錄簽署功能,即無法停用。關於相關程序,請參閱<附錄 E:SMS 安全性程序>中的<啟用詳細目錄資料的用戶端簽署與加密>。

SMS 使用安全雜湊演算法 (SHA-1) 和 1024 位元 RSA 金鑰來簽署詳細目錄。詳細目錄是使用 3DES 加密區塊鏈結 (CBC) 來加密。用戶端產生自動簽署的憑證來簽署和加密,然後將憑證儲存在本機電腦的 \SMS\Certificates 目錄下。您可透過其好記的名稱來加以識別。

note.gif  注意
透過在 SMS 2003 SP1 安裝期間指派給進階用戶端與管理點憑證之好記的名稱,簡化了在設有管理點的進階用戶端電腦上之驗證與加密疑難排解。然而,當站台升級成 SMS SP1 時,現有的憑證不會受到修改並新增好記的名稱。

用戶端識別碼是以 SMS 唯一識別碼和簽署憑證為基礎決定的。如果用戶端必須重新建立映像且目前憑證尚未先匯出,則新的憑證會被建立。這會使用戶端識別為新的電腦,因此用戶端的記錄將不會與新電腦產生關聯。在為用戶端重新建立映像前,請先匯出憑證 (包括私密金鑰),然後匯入到新電腦。關於管理憑證的更多資訊,請參閱 [說明及支援中心]。

以下是已經簽署的訊息從進階用戶端到其管理點的流程:

  1. 用戶端從站台伺服器和管理點擷取受信任的根目錄機碼與管理點機碼。

  2. 用戶端以探索資料記錄 (Discovery Data Record;DDR) 寄出自己的識別機碼。 

  3. 站台伺服器上的探索資料管理員 (Discovery Data Manager) 會將機碼插入 SMS 站台資料庫中作為用戶端識別碼。

  4. SMS 2003 SP1 用戶端只簽署詳細目錄訊息。

  5. 當已簽署的訊息從用戶端抵達時,管理點會決定用戶端的公開金鑰是否在 SMS 站台資料庫內。

    • 如果找不到金鑰,則訊息會標記為未驗證。

    • 如果在資料庫中找到用戶端的公開金鑰,則訊息的簽章會受到驗證。

    • 如果簽章有效,訊息會標記為已驗證,並進入處理程序。

    • 如果簽章無效,訊息會被捨棄,系統會記錄錯誤訊息。

以下是已加密的訊息從進階用戶端到其管理點的流程:

  1. 用戶端建立詳細目錄,並使用對稱式加密金鑰為目錄加密。用戶端同時以用戶端識別碼金鑰簽署詳細目錄。

  2. 此詳細目錄包含以管理點金鑰加密的加密金鑰。

  3. 管理點會使用自己的金鑰從詳細目錄訊息中擷取加密金鑰。

  4. 管理點為訊息解密。

    • 如果管理點無法將訊息解密,則訊息會被捨棄,系統產生狀態訊息。

    • 如果解密成功,訊息會傳送到站台伺服器以進行用戶端識別驗證和訊息處理。

顯示: