在域环境下如何保护重要资料文件的安全(一)---EFS加密(上)这篇文章中我们回顾了如何通过使用EFS加密从而达到保护重要资料文件安全的目的.相信通过演示,大家也是对EFS的效果比较满意的,有兄弟就蠢蠢欲动了,想推广和部署在生产环境中了.哦,先别急别急,多听我说几句.
EFS在生产环境中使用,你需要考虑这么几个很现实的问题:
1.含密钥的用户证书的导出和备份
因为EFS操作简单易用,可能会有很多人使用它.但是使用EFS的人越多,对于用户证书及密钥的管理就越麻烦,不备份证书及密钥当然不可行,遇到系统故障需要重做系统或者用户账号被删除,都是极其麻烦的事情;导出来了存放在什么安全的位置又需要考虑,总不能还放在用户磁盘中让"有心人"很容易就能找到吧.
2.需要防止用户无意或者恶意地对一些共享性质文件加密操作.
举个极端点的例子,某某员工在离职前夕用EFS加密了很多办公电脑上的重要资料,他倒是拍拍屁股走了后脚开会要用到这些资料了,而他的域账号刚巧也被IT管理人员kill掉了,这个时候他的工作接班人可就难受了.其实域账号还好了,网管员还能从AD备份中执行授权还原回来(请参考: http://mrfly.blog.51cto.com/151750/191430) ,要是那个员工用的是自己建立的本地账号,而后还删除掉了,那就没那么简单了.所以,在你的环境中如果给予用户账号权限过大,这个是需要你结合起来慎重考虑的.
3.EFS是微软推出的蛮久的一种系统应用,正因为其历史悠久,它的算法及加密流程等已被计算机高手所攻破,所以网上也散布着不少破解工具(有兴趣的朋友可以看下http://www.cctips.com/?p=39).如果你的环境中没有能有效防止"有心人"在别人电脑上使用这些软件的手段(包括技术上和行政上的),那么别有用心之徒还有有机会将加密文件解开的.
所以在上篇的讨论部分中胡兄的友情提示大家还是要用心体会一下的.
其实,在域环境下,我们还是有一些技术手段设置能缓解上面的问题的.
Now,为大家介绍EFS Recovery Agent,中文官名:EFS恢复代理,文中以下简称EFSRA.
EFSRA,说简单点,就相当于一个或多个被用户信任的人,他/他们手里握有一种万能钥匙,拿着这把钥匙,可以解密任何信任他/他们的用户使用EFS加密过的文件.
在比较早的时候,处于工作组环境下的Windows 2000 pro/server 系统中默认的EFSRA就是管理员账户administrator(这里我就不截图了,手头一时找不到没有加域的Windows 2000的机器).这意味着就算发生上面提到过的状况,使用administrator都可以打开任何用户的加密文件.这样会产生一些问题,对于网管朋友们可能就根本不用去思考要不要备份用户私钥,对于用户加密过的文件安全性不高.所以到了xp pro/Windows server 2003时代,微软修正了工作组环境下的管理员账户已经不再是默认的EFSRA了.
这里我打开一台还未加域的XP SP3计算机,使用本地管理员帐号加密了一个文件,然后在属性中看它的EFS恢复代理,可以看到,确实为空白,没有任何恢复代理账号的存在.
我现在把这台机器加入域.
仍使用上篇中使用过的普通域账号cto登陆.
查看刚才本地管理员加密过的文件属性里的EFSRA信息,没变化,还是空白.
新建一个文件然后加密,看看属性...
看到了有一个EFSRA了吧,又是administrator,他是被自动添加进来的哦.
不过,这个administrator可不是次计算机本地管理员帐号的证书,而是domain administrator的.他能被自动加进来也是因为默认域组策略生效的使然.
口说无凭,我们到DC上看一下.
打开默认域策略Default Domain Policy,找到"计算机配置"---"Windows设置"--"安全设置"--"公钥策略"---"加密文件系统"
我们可以看到这里有一个证书的存在,名称是administrator,预期目的是"文件故障恢复".
双击此证书
浏览到"详细信息"选项卡
仔细看一下证书微缩图号码.(若是在Windows server 2003 上则被称为证书指纹)
AD中:
客户端上: 
证明这俩是同一个物件.
那么,我们怎么使用EFSRA来解密用户的加密文件呢?
模拟情景:
cto此域账号已经被删除并无法还原,在Windows XP pro上经cto使用EFS加密的文件全部无法打开(包括使用local administrator 和domain administrator账号登录),EFSRA为domain administrator.
我们开始救援行动,先到DC上导出EFS恢复代理的证书和密钥.
注意一定要选择一并导出私钥
余下过程图略,与上篇演示相似.
然后到客户机上使用域管理账号登陆.导入刚才导出的证书.
导入成功后再试试看点开刚才不能访问的文件
可以看到cto先生加密过的文件啦~
操作流程真的很简单,不是吗?
而且,域内有这么一个真神坐镇后方,作为系统管理员的你是不是安心了很多呢?
深一步想,我们是可以用内置网域管理员账号Administrator还有他的包含私钥的证书来解密任何一个域账号加密过的文件了,但是,在实际管理中这样操作可能不是很方便, 因为正规企业一般都是会要求为员工建立相应的网域账号的,连网管员也不例外,所以我们平时工作中使用的账号基本上不会是这个内置的域管理员账号Administrator,例如我平时用的账号是jrfly331.那么,能不能把我们自建的账号以及对应的用户证书设置为恢复代理呢?答案是肯定的.我们来看一下怎么做吧.
到DC上,还是打开默认域策略Default Domain Policy,找到"计算机配置"---"Windows设置"--"安全设置"--"公钥策略"---"加密文件系统",在其上鼠标右击,
选择"添加数据恢复代理程序",略过向导画面,可以看到
注意高亮部分,说的很明白,如果你要添加的用户证书已经在AD中发布,就可以直接选择"浏览目录",如果没发布在AD中,需要手动指定用户证书文件(.cer格式).
我们先来看一下手动指定的方式.
先使用我的域账号jrfly331登陆到任意一台客户机上,这个时候肯定是看不了cto加密过的文件的.
我们调出cmd命令提示符,在里面输入cipher /?
可以看到,cipher 其实就是使用EFS加密操作的命令行方式.参数很多,大家可以仔细看一下,不难发现,其实上篇中所有操作基本上都可以用cipher来完成的.
这里我们特别关注一下/R参数
呵呵,原来.cer文件是可以这样生成的.
继续
两个证书都生成了.
我们把其中的.cer(安全证书)证书拷贝到DC上去,并且打开添加数据恢复代理程序,找到它
导入完成后可以看到jrfly331也成为了EFSRA了
余下的步骤和前面一样,在客户机上导入jrfly331的私钥证书
使用gpupdate/force刷新组策略
再次点击刚才不能访问的cto的加密文件
可以查看了
看文件属性
加密代理中可以看到jrfly331的身影了
(大家在测试到这块的时候如果仍不能查看加密文件就需要确认你的组策略是否已经在客户端更新了,因为我的是实验环境,所以比较快)
由于篇幅有限,至于如何把用户证书发布到活动目录中然后能够在"添加数据恢复代理程序"时候选择"浏览目录",我就比较简单地说一下过程吧:
首先在CA服务器上从"证书模板"中选择复制"EFS 故障恢复代理"模板
在新模板属性中勾选发布到AD中,然后在"安全"中添加账号并允许其注册
新建要颁发的证书模板
启用刚才配置好的新模板
在客户端进入certmgr.msc证书控制单元,申请新证书
选择证书类别
导入,我们可以看到两个证书的颁发者是不同的
同时,我们在DC上也可以通过目录找到拥有证书的用户了
剩下的工作就不用我再说了,前面演示过了.
总结:
看完了这两篇关于EFS的文章,相信各位对域环境下使用EFS会有自己的思考.
EFS的效果是显著的,同时不足之处也是明显的,我们如果要用他来加强文件资料的资安,一定要做好前期的规划和准备工作,包括用户证书的备份与存放,包括故障恢复的设计与实现等等.并且最终的方案一定是会把EFS结合NTFS权限来做的.允许谁解密,解开了他又能做什么操作......
正如老胡所说,貌似微软自己现在都不怎么提EFS了,呵呵,这也是因为不断有新产品新技术的出现必然的结果.那么,我们当然也要与时俱进,欢迎大家收看这个系列后面的内容---域环境下如何保护重要资料文件的安全(二)之IRM&RMS,敬请期待~
转载http://mrfly.blog.51cto.com/151750/192026