簡介
在我多年致力於微軟基礎架構及企業部署的工作中，微軟文件加密系統（Microsoft’s Encrypting File System，EFS）是我迄今爲止見過的最強大的加密技術之一，但其中大多數安全功能卻並未被充分利用到。我很少看到這種技術應用在企業級或中等規模的開發環境中，即使有，也只是個人或團隊將其作爲他們自己基於EFS安全控制中一些孤立的實例來使用。這樣做是有一定的道理的。EFS易於進行個人設置和自主使用，但在大規模正確部署EFS時，就需要對其許可、恢復代理管理、備份、存儲以及實現訪問模型方面進行詳細的計劃。錯誤部署EFS可能導致失去對數據的訪問權等嚴重的後果。爲了說得更加具體一些，假設基於一個失敗的場景，不合適的EFS控制設計可能導致在文件系統中無法對已加密的文件解密。雖然這個問題可以通過實體存儲層去解決。
EFS是一種基於用戶的加密控制。其基本工作方式爲：當用戶請求對一個文件或文件夾進行加密時，EFS爲用戶生成一個證書並將其私鑰存放在用戶的配置文件中。公鑰與用戶創建的文件一同存儲，只有這樣用戶才能解密這些文件。正是因爲如此，恢復代理證書通常與不同的用戶帳號相關聯，且這些用戶的公鑰也嵌入到該文件中。即使用戶丟失了用來加密文件的證書，而恢復代理用戶，或更具體地說是相關私鑰的持有者也能將文件解密。同樣，恢復代理的公鑰是自動和加密文件一同存儲的，也可以爲文件分配其他用戶的公鑰，以便允許他們解密文件。這就允許了多個用戶共享一個已加密的文件。當EFS證書通過CA（證書管理機構）分發，或在某個域環境中EFS操作第一次請求時而自動創建，用戶證書的公鑰存儲在AD當中。對恢復代理認證同樣如此，實際上，公鑰自動包含在域中創建的EFS文件的方式爲：在基於策略設定的AD上直接將文件恢復組織策略對象提取出來。我將在後續章節對此進行詳細講述。
讓我們花點時間詳細講述加密過程。當涉及到多個用戶共享一個加密的文件時，瞭解其工作原理和加密處理層面上的相關知識有助於更好地理解EFS是如何在企業或更小的AD環境中工作的。EFS證書並沒有什麼神奇的。它只不過是一個用EFS作爲密鑰的X.509證書，是基於Rivest, Shamir, and Adleman (RSA)算法生成的一對私/公鑰，如圖2.2所示。
當爲用戶創建證書時，系統採用RSA算法生成公鑰和私鑰，並將它們存放在用戶證書當中。只有公鑰存放在AD當中。數據使用公鑰進行加密，私鑰進行解密。這就是爲什麼公鑰是公開的原因，因此，其他用戶可以爲你加密數據，而只有持有私鑰的人才能對數據進行解密。這樣，即使用戶使用公鑰對數據進行加密後，也不能立即對數據進行解密。
在我認識的大多數人當中，似乎他們對RSA密鑰的印象是其用來對已加密的文件中的實際數據進行加密和解密工作的。其實這適用於所有基於RSA的加密方式，而不僅僅是EFS。實際情況是，在文件加密之前，已經生成了一個強隨機的密鑰。在這種情況下，該密鑰基於默認的高級加密標準（Advanced Encryption Standard，AES)的密碼。實際上，RSA算法加密的是密鑰，而不是數據本身。RSA公鑰用於加密AES密鑰，而AES密鑰則是用來加密實際數據的。
RSA和AES
RSA是一種非對稱的加密算法。其使用一個密鑰對數據進行加密，而採用其他密鑰進行解密。這種類型的加密運算量是非常大的。實際上它的運算速度取決於處理器，在使用相同的密鑰進行加密和解密的情況下，該算法比對稱密碼的運算要慢得多。一般的方式爲：使用RSA公鑰加密AES密鑰，用戶使用對應的RSA私鑰解密AES密鑰。這樣就對文件進行了加解密。每次向擁有加密文件權限的用戶列表中添加用戶時，系統會生成新的AES密鑰。列表中的每個用戶都可以用其公鑰加密這個AES密鑰，只有這個用戶能用對應的私鑰進行解密。
究其原因，是因爲RSA密碼可加密的文件數據量取決於其密鑰長度。一個1024位（bits，下同）的RSA密鑰可加密大約116字節的數據。這個加密量並不高。而2048位的RSA密鑰可加密大約245字節（Bytes）的數據。這是因爲：如果文件是由RSA方式生成的公鑰加密的，那麼該文件只能用其對應的私鑰來解密。AES密鑰卻沒有限制加密信息長度。AES用來分組加密文件，正因爲如此，任意長度的文件都可以進行分組並加密，最後將加密後的內容輸出到一個文件中。這種類型的加密方案產生了兩種攻擊途徑：一種是攻擊RSA密鑰，另一種是攻擊AES密鑰。如果可以破解AES密鑰，那麼加密該密鑰的RSA密鑰再強大也無濟於事。這就正是使用強加密密鑰的原因。下面是一個使用Base64編碼的256位AES密鑰，該密鑰使用2048位RSA密鑰加密。
256位密鑰。。。
真正的密鑰本身要比上面字符串長度小很多，但通過這個例子我們對密鑰有了基本認識。如果使用簡單的詞組如“bananadog”作爲生成的AES密鑰的密碼，對這種簡單密碼暴力破解會比較容易，而對不基於密碼組合的強加密密鑰的破解則要相對困難一些。針對2048位的RSA密鑰破解要更難。下面是有意生成的一個小例子，爲一個用BASE64編碼的2048位RSA私鑰，其公鑰可以從由C#實現的RSA加密服務提供者模塊中獲取。
2048位密鑰。。。
試圖通過蠻力破解該密鑰需要大量的時間，所以通常認爲蠻力破解是不可能的。目前，即使考慮摩爾定律對計算機性能增長的貢獻，通過計算來破解2048位的RSA密碼也被認爲是不可能的。形象的來說，即使我們坐在餐廳中靠窗的位置一直等到宇宙毀滅，密碼也破解不了。 但這只是以現在的眼光看待這個問題，誰又知道未來會怎麼樣呢。加密模型的描述見圖2.3中的示意圖。
一般認爲AES是一種對稱加密算法。但在利用AES算法生成密碼時，也可爲密碼配置不同的加密方式，如橢圓曲線加密。對於公共環境中連續加密的方式，我設計編寫了一個可自由使用的Windows加密程序，我稱之爲Thor’s Godly Privacy (TGP)。
提示：
由於種種原因，我不喜歡 Gnu Privacy Guard加密軟件的標準，也不喜歡商業版的Pretty Good Privacy加密軟件。所以我編寫了TGP軟件中，在該軟件中用自己的方法進行加密數據通信和密鑰分發。您可以在我的網站上獲得更多關於TGP的信息：www.hammerofgod.com/tgp.aspx。
EFS計劃和故障排除
有關EFS的最常見的問題之一是關於證書的妥善管理和恢復計劃。我不想在EFS管理上花費太多的時間，但我會說明如何在管理員沒有意識到的情況下創建一個恢復項。
最佳計劃
先講一個小故事。你在一個不斷髮展的組織中，該組織的管理員不停的換人，但政策規定需要對相關領域和企業管理員帳戶進行精心控制和管理。當然，這並不會經常發生，但假設本例中出現了這種情況。在過去EFS的使用中，EFS文件的表現都挺不錯的。例如：假設有一個已加密的EFS目錄，目錄下有一個名爲Splinter.txt的文件，該文件中包含了成功通關遊戲的所有步驟。該EFS文件的訪問屬性應該與圖2.4中顯示的相同。
看上去沒什麼問題，可是一旦系統崩潰，那麼就不得不重建一個新的文件。更進一步地說，假設所有的數據存放在系統中互相獨立的磁盤中，如果只需要備份一個磁盤，那麼事情將變得簡單。啓動並運行系統，加載數據磁盤，訪問SplinterCell.txt，獲得如圖2.5所示的對話框。
我們發現不能打開Splinter.txt文件，也不能打開其他已加密的文件。這時，可通過查看文件的EFS屬性來了解誰可以對這個文件進行訪問，如圖2.3所示。我們發現用戶可以訪問文件，且管理員是恢復代理 。當正在使用中的電腦死機時，包含用於加密文件的私鑰的EFS證書將存放到舊系統的配置文件當中。創建任何新的加密文件都會產生一個新的EFS證書（首次創建時，EFS將詢問並要求創建證書），該證書將在後面繼續使用。但這基本上沒什麼用。因爲我們一般都是直接將文件清除了。然後不得不去乞求管理員，讓他恢復你的數據。管理員將你的硬盤接到電腦上，以管理員的身份登錄，找到SpinterCell.txt文件並打開，此時將出現如圖2.6所示的歡迎對話框。
管理員再次檢查文件，查看管理員賬戶是否真的是恢復管理，但這樣做也無法打開文件。於是管理員決定將EFS屬性中的證書指紋與域管理員帳戶中的進行比較，如圖2.7所示。
管理員會說“啊哦”，指紋不匹配，不能打開文件。這不是正確的證書。很明顯，一般都認爲證書指紋是由恢復策略定義的。管理員啓動組策略管理器 （Group Policy Management Editor ），並在計算機|Windows設置|安全設置|公鑰策略中可用的GPO中搜索和檢查EFS條目。可看到GPO引用的證書（見圖2.3頂部），打開並展開證書的屬性，如圖2.8所示。
看！指紋匹配了！證書上的金色標誌的私鑰幫管理員解圍了。管理員現在所要做的是將證書和相關的私鑰導出並安裝到系統上，然後就可以恢復數據了。他會被用戶當作英雄來崇拜。但當他導出文件時，將會看到如圖2.9所示的對話框。
“啊哦”，沒有私鑰。不應該發生這樣的問題的。這是因爲證書是在用戶的系統上創建的，其系統管理使了一些小伎倆。由於他們安裝了自己的微軟證書服務（Microsoft Certificate Services），管理員所要做的是展開證書列表，查找所有的證書項，在相應的證書中用指紋匹配的方法查找出其管理員用戶。於是他進入CA管理控制檯，按指紋對所有證書項進行排序，如圖2.10所示。
“啊哦”，這裏沒有d2 43 57 e0 0f 45 d0 d6 1e d4 73 5a 7e b3 52 09 86 35 0e 50 指紋項。由於CA沒有發佈該證書，也就沒有持有該證書的用戶。用密鑰加密的數據在系統中根本就不存在，而且也沒辦法找回來。 且據我所知，在這種情況下，不存在超級黑客或後門可以恢復數據，哪怕是王母娘娘也不能讓管理員恢復數據。一個糟糕的結局。
後期用例分析
這裏解釋下發生了什麼。在創建域時，也就創建了域控制器，並在第一個域控制器上爲管理員創建恢復證書。恢復證書存儲於管理員用戶的證書存儲區，且在AD中存儲一份其公鑰證書的副本，並將其設置爲恢復代理證書。當管理員首次轉出EFS時，要特別注意上述概念。當然，也可以添加其他域控制器，但如果系統出現了某些情況導致第一個域控制器轉出，那麼將導致默認的恢復證書消失。在部署EFS時，需要注意兩個方面，一是需要針對系統爲恢復代理創建一定數量的信任帳戶，二是需要備份這些私鑰的證書並存儲在一個安全的位置。
現在建立一個常見的可運作的例子：基於網絡的文件訪問。該案例利用EFS和IIS一同大幅度增加安全係數。
雖然我選擇這個平凡而常用的功能來作爲示例可能有點令人驚訝，但這的確是經過深思熟慮的。 安全可不是說說而已。所以 我提出了一個相當複雜的網絡設計，形象的來說，該網絡由互相鏈接的交織的線和重疊的盒子組成。該網絡模型難以建立，部署該模型的難度等同於同級別的安全問題。爲該網絡模型構建維護計劃留給讀者自己了，因爲其內容超出了本書的範疇。我不會探討過多關於管理和操作方面的知識，畢竟這是一本關於安全方面的寶典。這樣做算是一種逃避，會讓讀者永遠不會嘗試這種模型。安全應該是簡單和可持續的。但並不是意味着本書中的例子都是簡單且易配置的。
本書的基本前提是設計一個能產生可重複結果的可記錄和部署的安全控制基礎架構。
