安全性監控部署 EFS：第一篇

John Morello

大家一定聽過因為筆記型電腦遭竊或弄丟而遺失私人或機密資料的報導。筆記型電腦遺失的情形屢見不鮮。隨著身分盜用情形猖獗和法規日趨嚴格，行動式運算系統的整體資料保護也愈來愈重要。

有一種辦法是利用 Windows® (自 Windows 2000 之後) 的加密檔案系統 (EFS)，此系統提供內建的、高效能的磁碟加密。EFS 與 Windows 檔案總管的密切整合，讓使用者幾乎感覺不到正在使用的檔案已經加密。此外，EFS 也同樣適用於原生的 Windows 驗證和存取控制技術，使用者不需為了存取資料而牢記個別密碼。最後，為了提防使用者無法取得他的加密金鑰 (例如使用者設定檔被刪除或損毀，或遺失智慧卡)，EFS 還可提供管理選項來回復資料。

EFS 會針對受保護的資料採用 Windows 內建的加密技術，來產生、儲存及部署增強式加密金鑰。在 Windows XP Service Pack 1 (SP1) 和較新的版本中，EFS 採用具 256 位元金鑰的「先進加密標準」(AES) 演算法來加密磁碟上的資料。這些對稱金鑰會再經過非對稱 (RSA) 金鑰組的保護。EFS 會以 AES 金鑰來加密每一個檔案，再以使用者的 RSA 金鑰來加密這個金鑰，最後將結果儲存在檔案中。如需 EFS 加密的詳細資訊，請參閱「EFS 資源」資訊看板。我暫且不將重點放在 EFS 的技術基本原理上，而是要討論如何將 EFS 部署和運用在您的環境中。因此，本文章假設您已有 EFS 加密的觀念。

淺談 EFS 安全性

有些應用程式宣稱有能力破解 EFS 加密。這些應用程式實際上都不是破解 AES (或資料加密標準 (DES) 或擴充型資料加密標準 (DESX)) 加密的密碼文字，只是以暴力法破解使用者的密碼來取得使用者的 EFS 私密金鑰。請注意，EFS 加密中用來產生和保護加密資料的私密金鑰，是採用「資料保護」API (DPAPI)。DPAPI 以使用者憑證的衍生物來保護資料，所以結論是唯有使用者的密碼夠強，以 EFS 來保護資料才有用。現在有了 Windows Vista™，您可以將 EFS 加密憑證儲存在智慧卡上，使情況為之改觀，大幅提升以 EFS 保護之資料的相對安全性。

密碼需要多長，才足以抵抗這些攻擊？以當今的硬體能力和現代的密碼攻擊演算法來說，最好使用 11 個字元以上的密碼 (更正確的說法是「複雜密碼」)。11 個字元以上的複雜密碼較能抵抗目前最先進的攻擊法，包括預先計算的雜湊攻擊 (例如 Rainbow Table；如需詳細資訊，請參閱「資源」資訊看板中列出的部落格文章：Why you shouldn't be using passwords of any kind on your Windows networks (英文))。

究竟要不要使用 PKI？

大家都以為 EFS 一定要公開金鑰基礎結構 (PKI) 才行，這是最常見的誤解。只要組織裡有 PKI，EFS 就很容易整合和利用 PKI，但這絕非必要。也就是說，是否在 EFS 部署中使用 PKI，將影響未來許多的部署決策，所以事先要經過調查。

PKI 和 EFS 一起使用的主要好處，在於可以備份和復原金鑰。雖然 EFS 可獨自讓系統管理員執行資料復原，但只有配合 PKI 時才能自動復原金鑰，也只有以 Windows Server® 2003 Enterprise Edition 做為憑證授權單位 (CA) 時才有此能力。在資料復原過程中，無法取得加密金鑰的使用者可以將加密資料提供給一位指定的系統管理員，稱為「資料修復代理」(DRA)，此人可將資料解密，再傳回給使用者，或重新加密做為新的私密金鑰。DRA 就像使用者加密過程的追蹤者一樣，會將使用者以這個金鑰加密的所有資料也都會以一份 DRA 金鑰來加密。因此，當使用者遺失金鑰時，DRA 可以介入以取得密碼文字資料，並套用 DRA 金鑰來加密 (或重新加密)，然後將資料傳回給使用者。DRA 的方法很好，但如果使用者加密的資料量很大，或沒有本機 IT 人員可擔任 DRA，則可能不易管理。

另一方面，金鑰復原會要求 CA 在金鑰建立過程中必須備份使用者的加密金鑰，並將該金鑰複本安全地儲存在 CA 的資料庫中。此後，當使用者無法存取加密檔案時，CA 系統管理員只要進入這個資料庫，就可以取得使用者的金鑰。屆時，使用者馬上就能再次存取他的資料，不必再由 DRA 去復原資料。在這種做法下，金鑰復原速度更快、更有效率。不過，請注意，即使是使用金鑰復原，最好都能有 DRA 提供備援機制，以防金鑰遺失情形發生。這樣也方便大型組織建立分散式復原系統，本機 IT 系統管理員直接就能復原使用者的資料，不必再麻煩 PKI 系統管理員小組。

PKI 和 EFS 一起使用的另一項好處，是更容易共用加密檔案。回想一下，EFS 並不限於用在筆記型電腦系統上；在實體電腦的安全性無法保證的任何情況下，也同樣很有價值。在這些情況下，多位使用者可能同時需要存取相同的加密資料。雖然 Windows 對加密檔案的共用支援稍嫌不足，只能共用個別檔案，不能共用目錄，但還算是很實用的工具。為了提供共用 EFS 檔案的功能，共用檔案的使用者必須取得對方的公開金鑰 (如果這些使用者已將有效的 EFS 憑證發行到他們在 Active Directory® 中的帳戶，此時最容易取得)。雖然可以手動來執行這項發行動作，但使用以「企業 (Enterprise)」(Active Directory 整合) 模式安裝的 Windows CA 可讓整個過程完全自動化。

EFS 金鑰管理

如果您有 Windows Server 2003 的 PKI 可用，則使用者 EFS 憑證的產生就很簡單。Windows Server 2003 CA 提供一套預設的憑證範本，包括「基本 EFS」這個範本。但這只是第 1 版的範本，且尚未支援金鑰備份。因此，在您的 CA 上提供此範本之前，您可以複製範本來建立新的第 2 版範本 (例如，命名為「具金鑰備份的 EFS」，如 [圖 1] 所示)。在這個新的範本上，移至 [要求處理] 索引標籤，並選取選項來備份使用者的加密金鑰。請注意，在啟用這個選項之前，必須先在 CA 上適當地設定金鑰備份。在資源區段中，整個過程有很好的逐步解說。您也應該設定這個範本來取代「基本 EFS」範本，確保用戶端使用這個新版本 (請參閱 [圖 2])。

圖 1** 具金鑰備份的 EFS **(按影像可放大)

圖 2** 取代基本 EFS 範本 **(按影像可放大)

接下來，您必須在範本上設定適當的權限，只開放註冊權限給適當的使用者。第一次使用 EFS 時，因為 Windows 中的 EFS 元件會自動要求憑證，您通常不必讓使用者自動註冊 EFS 範本。實際上，除非您確定所有自動註冊的使用者都一定會使用 EFS，否則我建議不要啟用 EFS 憑證的自動註冊。[圖 3] 顯示 EFS 註冊設定。發行憑證給不可能使用 EFS 的使用者只會徒增 CA 資料庫的大小，有害無益。雖然 CA 資料庫本身沒有大小限制，但隨著您發行的憑證愈多，就會變得愈難以管理 (尤其是透過 Microsoft Management Console，MMC)。

圖 3** 設定 EFS 使用者權限 **(按影像可放大)

最後，如果您需要支援加密檔案的共用，您可以讓 CA 自動將使用者的憑證發行至 Active Directory。

在 CA 上適當地設定範本之後，當使用者第一次以 EFS 來加密檔案時，他將從 CA 取得憑證，而 CA 也會自動備份這個私密金鑰。

DRA 金鑰管理

如果您已有 PKI，則接下來的問題是要決定是否使用 CA 產生的 DRA 憑證。為何不要使用 PKI 的 DRA 憑證？假設發行 CA 的憑證有效期限非常短 (兩年以內)。該 CA 將無法發行有效期超過本身期限的任何憑證，這表示您的 DRA 憑證最多只有兩年的使用期限。這樣會造成資料復原情形更為複雜。下列案例說明這個假設性範例。

1. 有一位使用者在 2006 年 1 月時將一個檔案加密；經由「群組原則」推入至她機器上的 DRA 憑證會有兩年的使用期限 (2008 年 1 月到期)。
2. 該使用者繼續使用 EFS 來加密新的檔案。
3. 在 2008 年 1 月，DRA 憑證到期，系統管理員透過「群組原則」推入新的憑證。
4. 此後，任何加密作業都採用新的 DRA 憑證 (包括她開啟的任何以舊 DRA 加密的檔案；儲存檔案時會採用新的 DRA)，但她後來未接觸過的任何檔案仍然只由舊的 DRA 來保護)。
5. 有一天，使用者不小心毀損她的設定檔，需要復原資料。
6. IT 系統管理員現在必須有兩組 DRA 憑證：新的一組是針對步驟 3 之後接觸過的任何檔案，舊的一組是針對那時之後就未接觸的任何檔案。

雖然 IT 系統管理員可以在步驟 3 之後執行指令碼，以新的 DRA 來更新所有檔案 (使用 cipher.exe /u)，但整個過程相當耗時。更明確地說，如果修復原則包含過期的 DRA 憑證，則 EFS 元件就不允許任何新的加密作業，但這不表示 DRA 金鑰組在超過到期日之後就毫無用處。以過期的 DRA 金鑰組來加密的舊檔案，當然還是可以用這些金鑰組來復原。因此，切勿捨棄有效存留期已過的 DRA 金鑰組；不是用不到，只是時候未到。

基於這些理由，對於 CA 憑證使用期限很短的環境，建議採用期限較長的自行簽名 DRA 憑證。cipher 公用程式有一個參數 (cipher.exe /r) 可自動建立存留期長達 100 年的 EFS 修復代理金鑰組 (請參閱 [圖 4])。這個金鑰組的憑證可以附加至群組原則物件 (GPO)，並做為整個組織的 DRA。因為 EFS 元件不會檢查 DRA 憑證的信任鏈結，就算不變更系統上的「受信任的根憑證授權單位」清單，這些自行簽名憑證也一樣沒有問題。姑且不論組織的 CA 使用期限有多長，我建議至少建立一個長期的 DRA 憑證並附加至網域 GPO。這是後援的資料復原選項，萬一其他所有選項都失敗，就可派上用場。如果您在沒有 CA 金鑰備份的情況下使用 CA 產生的 DRA 金鑰，這更是不可或缺。萬一洩露 DRA 憑證，您可以用新的憑證來更新 GPO，並使用剛才提到的 cipher.exe /u 來更新檔案。

圖 4** 執行 Ciquer /R **(按影像可放大)

EFS 資源

如需 EFS 特性和最佳做法的詳細資訊，請瀏覽下列網站。

• Why you shouldn’t be using passwords of any kind on your Windows networks (英文)
• Implementing Key Archival Walkthrough (英文)
• Encrypting File System in Windows XP and Windows Server 2003 (英文)

KRA 和 DRA 的部署

金鑰備份可讓 CA 系統管理員代替使用者來復原委付的加密金鑰。顯然，這是一種非常敏感且強大的功能，因為在組織內的任何資料，只要用到 CA 所簽署的金鑰，就可以被 CA 系統管理員解密。因此，必須謹慎處理金鑰的備份和復原，只有極少數值得信賴的安全人員才應該獲得這種權限。基於金鑰復原的機密性質，如果您想以此做為重獲 EFS 加密資料的主要機制，則傳給 CA 管理小組的復原要求一定要明確定義授權程序。一定要仔細檢查要求之後，才能開始進行復原程序。實際復原金鑰之後，應該透過安全的方法來提供給使用者 (換言之，不要透過電子郵件)，因為復原的金鑰已有能力存取使用者所有以 EFS 保護的資料。

金鑰修復代理或 KRA 金鑰會由 CA 系統管理員來產生和保存，不會透過「群組原則」公告。實際上，EFS 本身並無法判斷所使用的金鑰是否已封存，只會一如往常地執行加密作業。此外，在 CA 上建立的 KRA 金鑰絕不可能只供 EFS 使用。使用金鑰備份的 CA 會在 CA 等級上附加 n 個 KRA 金鑰，用來保護 CA 備份的任何金鑰。這些金鑰可能用於 EFS、安全電子郵件，或其他需要加密的任何憑證用途。KRA 金鑰應該由各金鑰修復代理來妥善保存，且至少要有兩個 KRA，以防其中一個金鑰遺失。

當系統管理員在新建立的網域中第一次登入網域控制站時，將會使用 DC 上的系統管理員設定檔中儲存的自行簽名憑證和金鑰組，在網域等級上建立預設的修復原則。此 DRA 憑證的有效存留期為三年。建議移除這個預設的憑證，並取代為更長期的自行簽名憑證或 PKI 發行的憑證。如果不移除這個預設的自行簽名憑證，則自建立之日起的三年內，EFS 將不會加密整個網域中的新檔案。這是因為憑證已過期，當修復原則包含過期的 DRA 憑證時，EFS 將禁止加密任何後續的資料。雖然可以在沒有修復代理原則的情況下操作 Windows XP 及更新版的系統，但這樣極為不妥。如果這樣做，萬一使用者因故無法存取他的加密金鑰，也無法將金鑰復原，則會永遠失去他的所有資料，無法挽回。

我說過，DRA 金鑰可以是自行簽名或由 CA 發行。在大多數情況下，兩者兼用最佳，整個企業至少要有兩個長期的自行簽名 DRA 做為最終的修復代理。因為 DRA 憑證也是透過群組原則物件來部署，所以繼承能力和其他 GPO 一樣。換句話說，標準的本機、網站、網域、組織單位 (OU) GPO 累加和應用演算法 (控制其他 GPO 設定的運用) 也都適用於 DRA。因此，組織可以輕易地對 DRA 採取分層做法，亦即 IT 中心小組對整個企業擁有 DRA 存取權限，但本機 IT 小組也有各自的責任範圍。這在分散各處的大型組織中極具價值，因為不必再為了復原資料而透過 WAN 連結傳送大量的加密資料。[圖 5] 顯示常見的多層 DRA 部署。

圖 5** 多層 DRA 部署 **

在這個案例中，Baton Rouge OU 的使用者到最後每一個加密檔案都會有六個 DRA：其中兩個來自他的本機系統管理員、兩個來自 North America IT 小組、兩個來自網域等級。因此，萬一使用者無法存取他的加密資料，則可由位於 Baton Rouge 的本機 DRA 或 North America IT 小組的 DRA 來復原。在最遭的情況下，萬一這四個 DRA 都不在，還有網域等級 DRA 可接手來復原資料。不論由哪個 DRA 執行復原，整個過程在本質上都一樣。首先，使用者要提供資料給 DRA。DRA 必須採取必要的步驟，確認請求合法且來自真正的資料擁有者。確認之後，DRA 會載入 DRA 憑證、將資料解密 (通常建議重新加密)，然後再將資料傳回給使用者。有些組織也會選擇執行本機復原，由 DRA 實際拜訪有問題的使用者，將他的 DRA 金鑰組載入設定檔中，然後將資料解密並移除金鑰組。之後，使用者會取得純文字格式的資料，且可以用新的金鑰來重新加密。請注意，這種做法很不安全，因為 DRA 金鑰組會複製 (暫時) 到本機電腦上，但的確可以節省一些時間，尤其在必須復原大量資料時，這樣或許值得。

請注意，如果是透過金鑰備份和復原的方式來協助使用者復原，則復原要求的處理方式和這個過程截然不同。完全不用 DRA，使用者將向 CA 系統管理員提出金鑰復原要求，此人必須檢查要求，然後進入備份處來取得使用者的私密金鑰。接著要將這個私密金鑰安全地送到使用者手上，例如放在安全網站上供他下載 (如果使用者在 Windows Vista 中使用智慧卡來儲存 EFS 金鑰，則應該一併重新發行此金鑰)。當使用者將這個金鑰載入他的設定檔之後，立刻就能存取他的所有加密資料。

因為 DRA 和 KRA 金鑰組都可以將機密資料解密，所以一定要妥善保管。DRA 和 KRA 金鑰組不應該儲存在系統管理員的一般桌面設定檔中 (用來執行日常工作的設定檔)。這些金鑰組應該安全地儲存在離線磁片、光碟或快閃媒體上，然後存放在真正安全的位置。以後需要復原時，修復代理就可以將這個媒體中的金鑰組載入復原工作站內、執行復原作業，然後移除金鑰組。機密需求特別高的組織會指定專用的工作站來負責復原，以進一步提高這些金鑰組的安全性，但並非所有組織都有這種需求。

下期預告

我現在已討論過 EFS 計劃的金鑰管理、資料復原及 Active Directory 方面的問題，在下個一月，我將在本主題的第二篇中探討用戶端的部署問題。涵蓋的主題將包括透過「群組原則」來控制 EFS 使用方式、選擇要加密的對象、透過登入指令碼來自動加密，以及有哪些用戶端增強功能可讓 Windows 檔案總管更容易處理以 EFS 保護的資料。

John Morello 以最優異的成績畢業於 LSU，且已在 Microsoft 工作六年，擔任過各種角色。身為資深的顧問，他曾為美國財星前 100 大 (Fortune 100) 企業及民間和國防部門設計安全解決方案。他目前擔任 Windows Server 小組的專案經理，負責開發安全性和遠端存取技術。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.