那么,我们要用什么方法来尽量避免此类情况出现呢?并且前提是:
一.尽量花钱少,现在提倡开源节流,申请买什么都难啊,别说是动辄几千上万的软件硬件了.
二.用户体验良好,不能有太复杂的操作让用户(员工)来做,这点很重要.操作过于复杂,可能造成用户操作失误而没有达到效果,另外长期以往,用户会产生抵触心理而不怎么使用它.
三.加密技术成熟,不要像PDF,winrar这类加密文件随便google一下也有百八十种破解工具.
好吧,目标很明确了,开始挑战之旅吧.
先看看现有的环境.公司客户端操作系统基本上都安装的是Windows XP Professional,还有极少部分的Windows 2000 Professional,并且磁盘上的分区格式基本上都为NTFS(老旧的2000还有用FAT32格式,XP系统都是我们IT部门统一安装的,可以保证是NTFS磁盘文件格式).我们在请出今天的主角之前,要先把残留的FAT32消灭,都换成NTFS.
那得先把装Win2000的客户端从局域网中都找出来.手段多种多样,最省事的,发个全厂mail通知用户查看自己的计算机情况,然后不是ntfs的打电话或发邮件反馈,那样动静太大了,而且也体现不出我们系统工程师的水平...所以,一般可以使用脚本收集客户端信息再来导入到数据库中查找(---最专业最繁琐的做法), 好在我的环境中有SMS2003,省事了,直接到计算机集合里面看看就知道啦~
[图略]
找到了以后提出远程控制请求.取得了客户机的控制权以后我们要做的就是转化磁盘格式.命令相信大家已经烂熟于心了:
CONVERT volume /FS:NTFS [/V] [/CvtArea:filename] [/NoSecurity] [/X]
如果提示你当前域用户权限不足,而你又不想登出切换管理员账号,不妨用用runas命令.
然后重启计算机,完成磁盘格式转化.
接下来我们可以请出本文主角了---EFS (Encrypting File System，加密档案系统)
简单介绍一下EFS吧.从Windows 2000/XP/Server 2003开始,系统都配备了EFS（Encrypting File System，加密档案系统），它可以针对存储在NTFS磁盘卷上的文件和文件夹执行对用户透明的加密操作.说到对用户透明,是因为你(用户)使用它加密的文件在访问时不会产生任何让你输入密码之类的操作,感觉和没有和访问未加密文件没有区别.我们后面演示部分会看到.
其实,DFS加密技术也是采用了公钥/私钥密码学原理的,这个原理要铺上来怕是几千字都不够写,大家只要记住一点就好:公钥加密,私钥解密.所以任何被某用户公钥加密后的NTFS文件也只能被此用户的私钥解密,没有手握这个用户私钥的其他用户想解密/查看是办不到的.
要使用EFS来加密文件或文件夹,那真的是非常简单:
这里有个域用户cto想要加密他的一份重要文件,他要做的操作就是
在要加密的文件上鼠标右键点击"属性"---点击"高级"--勾选"加密内容以便保护数据"
OK,完成.
如果是要加密整个文件夹,就在文件夹属性里执行上面的操作,有一小点不同的是你需要选择是只对此文件夹加密还是要对文件夹中所有的资料(文件,子文件夹)加密.
点击确定后完成加密,可以看到文件名字变成了绿色,用户cto双击文件,可以正常查看修改.
然后我们注销系统,使用另外一个域用户cfo登陆,定位到刚才的文件,双击打开,
拒绝访问了.效果达到,用户cfo不能查看用户cto使用EFS加密过的文件.
有的朋友问了,如果这个文件是放在共享文件夹内的呢?
会提示你无法查看也无法复制的.就算你是使用的相同的域账号登录的.
记得有个网友问过如果复制过来的分区是FAT32格式的呢,结果是一样的.
仍然是拒绝访问.
这是为什么呢?
道理很简单
谁有那把秘密钥匙谁才能开那个箱子.
问题来了,那把密钥到底放在那个房子(存放加密文件的计算机)的什么地方呢?若是把那把密钥给我我就能开那个箱子了吗?
回看cto加密<重要资料>的计算机上,确保使用cto此域账号登陆,使用mmc命令调出控制台(或者使用certmgr.msc),添加"证书"管理单元,选择"我的用户账户"
点开个人---证书,可以看到有一个对应当前cto用户名的证书,我们选择导出它.
这里一定要选择"是,导出私钥" , 私钥正是我们苦苦寻找的那把解锁的钥匙
保持默认
密钥外头还要套个密码箱才能交给别人,怎么样?保护的够周到吧.
切记,你要把这把钥匙给别人用,你的这个装它的密码箱密码也是要交给别人的
给钥匙起个名字
完成,导出
传说中的"血色十字军钥匙"
现在我们可以换cfo登录系统,找到刚才导出的cto的密钥
双击,导入,导入时要输入刚才导出时设置的密码
导入成功后可以在cfo的证书管理控制单元中看到cto的证书
注意看上图中,只有新导入的cto的用户证书,而没有cfo自己的,这是因为cfo还没有使用EFS加密过文件,等他第一次执行过EFS加密,就会看到相应的证书了.
cfo现在可以看cto亲手加密的文件了.
这样做其实有一定的后果,你想,cfo拿到了cto的私钥,以后这台机器上只要是cto的加密文件cfo就都能看了,cto可不干了,有没有办法让cto指定cfo能看哪些加密的,不能看哪些加密的呢?
其实,这个问题,在Windows XP Professional版本中就得到了解决,
要达到这个效果,需要让cfo也使用DFS加密一次以便生成自己的用户证书.
注明:我已经将刚才导入的cto证书删除,模拟cto证书没有导入的情况
此时cfo已经无法访问cto加密过的文件
下图为例,cfo想要访问cto加密的一个文件,文件名为<极其重要资料>
可以看到,访问拒绝
回到用cto账号登录,在此文件<极其重要资料>上右键属性---点击加密旁边的"详细信息按钮",在"可透明访问这个文件的用户"下点击添加
可以看到cfo的用户证书也赫然在列,我们把它加进来
注销,再以cfo登录
cfo可以看cto特意为他共享出来的EFS加密文件了,然而他贪心不足地还想看看旁边的那个
想投机把自己证书加进去...
就是这样.
经过了DFS加密设置,cto只要保护好自己的账号密码,就不用担心有人能偷偷登录到他本机去看他的重要资料了.
但是有一点,非常关键,想必吃过这个亏的网友都牢记住了,用来解密文件的用户私钥是一定需要随证书导出来备份的,否则当重新安装了操作系统而无相应的用户证书导入之时,就算你用相同的用户再登入也是无法解密的.
那用户当时就是忘记了备份含密钥的证书了,而现在出问题了,怎么办?我只能告诉你,网上可能会有一些破解EFS加密的软件你可以尝试,但完全恢复几率很低.要么你可以尝试重构计算机SID,加密时使用的账号/域账号的SID,这个难度很大很大.所以,我觉得防患于未然才是王道,
1.含密钥的用户证书的导出和备份
因为EFS操作简单易用,可能会有很多人使用它.但是使用EFS的人越多,对于用户证书及密钥的管理就越麻烦,不备份证书及密钥当然不可行,遇到系统故障需要重做系统或者用户账号被删除,都是极其麻烦的事情;导出来了存放在什么安全的位置又需要考虑,总不能还放在用户磁盘中让"有心人"很容易就能找到吧.
2.需要防止用户无意或者恶意地对一些共享性质文件加密操作.
举个极端点的例子,某某员工在离职前夕用EFS加密了很多办公电脑上的重要资料,他倒是拍拍屁股走了后脚开会要用到这些资料了,而他的域账号刚巧也被IT管理人员kill掉了,这个时候他的工作接班人可就难受了.其实域账号还好了,网管员还能从AD备份中执行授权还原回来(请参考: [url]http://mrfly.blog.51cto.com/151750/191430[/url]) ,要是那个员工用的是自己建立的本地账号,而后还删除掉了,那就没那么简单了.所以,在你的环境中如果给予用户账号权限过大,这个是需要你结合起来慎重考虑的.
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上也可以通过目录找到拥有证书的用户了
剩下的工作就不用我再说了,前面演示过了.
1193
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
