這兩天在論壇上又看到有網友提問,"能不能利用一些比較簡單地方法實作對檔案伺服器上的私人檔案/檔案夾的保護呢?因為不想讓别的使用者浏覽到自己的共享檔案夾中的某些個檔案!".
應對這種需求時,檔案伺服器管理者在平常一般都會采用在檔案伺服器上共享出來的大目錄下建立子目錄然後修改NTFS權限來實作.但是對于普通域使用者,他們想更為靈活和簡單地掌控自己檔案檔案的安全性和隐私性的話,權限的疊加或者設定對他們而言就有些難以掌握了.
其實,對于大量采用Windows XP作為用戶端,Windows server 2003以上作為檔案伺服器作業系統并且有域環境的企業來說,讓使用者可以使用EFS對自己存儲在遠端伺服器上的私有資料進行加密就成為了一種可供選擇的方案.畢竟EFS對于使用者操作的透明性和簡易性比較于其他方案是有很大優勢的.
下面我們就一起來看一下如何配置使得使用者可以使用EFS對遠端檔案伺服器上的檔案加密.
相信看過我之前博文<域環境下如何保護重要資料檔案的安全---EFS加密(上下篇)>的朋友對于域環境中的EFS使用已經有了一些共識:本地計算機上使用EFS加密操作真的好簡單.在要加密的檔案上右鍵,選擇"正常"-->;"屬性"-->;"進階"-->;"加密内容以便保護資料"就完事了,同樣的做法直接搬到遠端檔案伺服器上呢?
這裡我使用一個名稱為"cfo"的普通域使用者賬号登陸用戶端(IP:172.16.0.201),先對他在檔案伺服器(IP:172.16.0.101,FQDN:contoso-sccm.contoso.com)上要通路的共享檔案夾(共享名test, cfo對其擁有完全控制權限)做一個磁盤映射,然後對其中的檔案試圖進行EFS加密,可以看到,
<a href="http://mrfly.blog.51cto.com/attachment/201004/11/151750_1270999988fylE.jpg"></a>
圖1
會直接提示"應用屬性時出錯",試圖加密失敗.
其實動手之前稍微想一下,失敗是必然的事情,遠端伺服器沒有得到使用者的信任和授權,同時也并不擁有使用者的證書和密鑰(如果您對證書及密鑰的概念不是很了解請詳細閱讀我之前的博文),怎麼可能就這樣輕而易舉地代替使用者實作加密.
是以我們需要先對遠端伺服器進行委派的動作.
來到域控上,
打開"Active Directory使用者和計算機",找到檔案伺服器的機器名,右鍵選擇"屬性",然後點選"委派"頁籤,選擇"僅信任此計算機來委派指定的服務",跟着單擊"添加",然後單擊"使用者和計算機",浏覽到檔案伺服器後點選"确定",這時會出現一個"可用服務"清單,選擇添加其中的"cifs"和"protectedstorage"服務.完成操作後需要将檔案伺服器進行一次重新開機.
<a href="http://mrfly.blog.51cto.com/attachment/201004/11/151750_1270999992EU6z.jpg"></a>
圖2
完成了委派的操作,就相當于對伺服器進行了授權,允許它代表使用者執行某種(或全部的)服務.下邊需要做的就是讓檔案伺服器擁有域使用者的證書和密鑰.關于這一步,有兩種做法,
一 ,直接在檔案伺服器上使用域使用者賬号登入一次,并且随便加密一個檔案,這樣就可以生成域使用者的證書和密鑰了.第二種做法是在域使用者擁有使用者漫遊配置檔案(Roaming Users Profile)的情況下,直接将RUP 下載下傳到檔案伺服器上對應的位置即可.(此步圖略,并且由于本人的實驗環境問題,選擇了第一種方式獲得的使用者證書及密鑰).
做完了以上的操作,我們再在用戶端試着用EFS來加密遠端伺服器上的共享文檔看看.
咦,竟然還是圖1的報錯. 這時我們不妨到檔案伺服器上看看有沒有相關的資訊.
來到檔案伺服器上執行eventvwr.msc打開事件檢視器,可以看到有這麼一條報錯資訊:
<a href="http://mrfly.blog.51cto.com/attachment/201004/11/151750_1270999997ig9z.jpg"></a>
圖3
這是因為EFS不支援NTLM身份驗證協定,而隻能使用Kerberos協定.
那怎麼看到用戶端上登入的賬号是采用了什麼身份驗證協定通路的網絡共享呢?
這個在事件檢視器上也是有記錄的:
<a href="http://mrfly.blog.51cto.com/attachment/201004/11/151750_1271000001A5hn.jpg"></a>
圖4
可以看到cfo是使用的NTLM協定來進行身份驗證的.
為了讓他轉為使用Kerberos協定,我們需要重新以\\FQDN方式來定位到共享檔案夾再進行磁盤映射.請記住: 為了Kerberos的正常工作,所有通信都必須都使用完全限定的域名 (FQDN)。
是以請保證你域内的DNS伺服器運作正常.
同樣,在轉為使用Kerberos協定進行身份驗證後,事件日志中也會有相應的記錄:
<a href="http://mrfly.blog.51cto.com/attachment/201004/11/151750_12710000060jqj.jpg"></a>
圖5
我們再來試試對遠端伺服器上的檔案加密:
<a href="http://mrfly.blog.51cto.com/attachment/201004/11/151750_12710000103NtE.jpg"></a>
圖6
可以看到,終于能夠在遠端 伺服器上使用EFS方式對檔案加密了.
總結一下使用EFS的委派模式對遠端伺服器上檔案加密的大體步驟:
1.在域控上對遠端伺服器進行信任委派并重新開機(安全起見隻委派兩個服務即可,不再複述,詳見正文内容)
2.在遠端伺服器上生成使用者的profile及private key(兩種方法,不再複述, 詳見正文内容)
最後仍有幾點需要說明:
1. 對于将要使用遠端伺服器的EFS加密的域使用者,務必在其賬号屬性中清除"敏感帳戶,不能被委派"複選框.
2.遠端加密不支援跨林的委派伺服器模式,要使用此方案,被委派的伺服器須和使用者帳号在同一個域内.
3. EFS隻能加密存儲在磁碟上的資料.在網絡中傳輸資料時資料仍是沒有被加密的.是以為了保證在網絡傳輸時的資料安全,你可能需要使用IPsec或者EFS over WebDAV模式.
4. 在有多名使用者對某個檔案夾都擁有足夠權限的時候,其中一個使用者使用EFS來加密了某些個檔案都會導緻别的使用者都無法再通路這些檔案.鑒于此, 請規劃好遠端EFS加密的使用并且對使用者說明正确的使用場景.為了以防萬一,也請将EFS域修復代理人提早設定妥當.
5.雖然域内可以使用自簽名( self-signed)的使用者證書,但對于涉及到證書的最佳實踐還是建立CA伺服器以獲得和活動目錄結合的PKI環境.
本文轉自 jrfly331 51CTO部落格,原文連結:http://blog.51cto.com/mrfly/293977,如需轉載請自行聯系原作者