- 对本书的赞誉
- 序一
- 序二
- 序三
- 前言
- 第一部分 安全架构
- 第 1 章 企业信息安全建设简介
- 第 2 章 金融行业的信息安全
- 第 3 章 安全规划
- 第 4 章 内控合规管理
- 第 5 章 安全团队建设
- 第 6 章 安全培训
- 第 7 章 外包安全管理
- 第 8 章 安全考核
- 第 9 章 安全认证
- 第 10 章 安全预算、总结与汇报
- 第二部分 安全技术实战
- 第 11 章 互联网应用安全
- 第 12 章 移动应用安全
- 第 13 章 企业内网安全
- 第 14 章 数据安全
- 第 15 章 业务安全
- 第 16 章 邮件安全
- 第 17 章 活动目录安全
- 第 18 章 安全热点解决方案
- 第 19 章 安全检测
- 第 20 章 安全运营
- 第 21 章 安全运营中心
- 第 22 章 安全资产管理和矩阵式监控
- 第 23 章 应急响应
- 第 24 章 安全趋势和安全从业者的未来
- 附录
14.2 终端数据安全
跟数据打交道最多的场景是终端电脑,所以很多企业的数据安全建设工作都会围绕终端进行,市面上的解决方案有加密、权限控制、终端 DLP 桌面、虚拟化、安全桌面等几大类别,中间还会涉及一些外设管控、水印等,我们逐一阐述。
14.2.1 加密类
加密类解决方案可以分为磁盘加密、文件加密两类技术。
1.磁盘加密
磁盘加密技术目前主要有两种类型:一种是磁盘分区加密技术,另一种是全磁盘加密技术(Full Disk Encryption,FDE)。
磁盘分区加密技术是采用加密技术对磁盘上某一个扇区(或者分区)进行加解密。磁盘分区加密技术目前已经有广泛应用,虚拟磁盘加密技术(Vertual Disk Encryption,VDE)就是磁盘分区加密技术的代表之一,其他的还包括移动存储设备加密技术。很多企业提供类似“安全 U 盘”的设备,网上搜索“加密 U 盘”即可找到。
全磁盘加密技术,顾名思义,是对整个磁盘上的数据进行加解密,包括系统所在分区也是加密的。国内也有厂商提供全磁盘加密的技术解决方案,图 14-1 是某厂商的动态加解密过程原理图。
图 14-1 全磁盘加解密工作原理
随着操作系统功能的不断增强,都自带了磁盘加密功能,比如 Windows 的 BitLocker、Linux 的 LUKS、MAC 的 FileVault 等。除了系统自带外,个人用户还可以使用免费的 TrueCrypt,同时支持 Windows Vista、7/XP、Mac OS X、Linux 等操作系统。TrueCrypt 不需要生成任何文件即可在硬盘上建立虚拟磁盘,用户可以按照盘符进行访问,所有虚拟磁盘上的文件都被自动加密,需要通过密码进行访问。TrueCrypt 提供多种加密算法,包括 AES-256、Blowfish(448-bit key)、CAST5、Serpent、Triple DES 和 Twofish,其他特性还有支持 FAT32 和 NTFS 分区、隐藏卷标、热键启动等。因为安全原因,TrueCrypt 已经停止更新,用户可选用更安全的版本 VeraCrypt,除了免费这一优势,最关键的是操作也非常方便,如图 14-2 所示。
图 14-2 VeraCrypt 效果图
传统的磁盘加密方案,都是基于防止设备丢失等带来的被动泄密,而无法防止员工的主动泄密,所以以上的方案比较适合用在笔记本电脑、移动存储设备上。
业界还有一种新的商业产品方案,同样也是在磁盘上做文章,即在本地物理磁盘上创建一个文件(称为实体文件),把该文件映射为一个盘符,这个盘符与正常的盘符没有区别,只是读写这个盘的数据会被重定向成读写上述实体文件。除此之外,再结合对进程访问资源的控制,来实现对特定应用或业务系统的保护。基本的工作原理如图 14-3 所示。
图 14-4 所示的架构图比较清晰,只有指定的合法进程才能访问这个虚拟磁盘,而这些进程一旦打开了虚拟磁盘里面的文件,就会立即进入受控状态,一切可能导致数据泄露的行为都会被控制,控制方法包括允许、审计、禁止、审批等。
针对特定业务系统的保护,此方案是一个非常不错的选择,在实际使用过程中需要关注以下问题:
·受保护的业务系统是 C/S 还是 B/S 访问,内部是否有各种调用关系,这些都决定了要保护的进程、网络访问该如何配置。
·某些软件本身会有一些行为,如读写系统盘临时文件或者与业务系统无关的网络行为,这时候的强控制是否会引起兼容性问题?弱控制是否会引起数据泄露?这些问题可能都需要评估。
·实施方案要考虑应用的各种不同版本,以及应用软件功能升级情况,以免引起不兼容问题。
图 14-3 技术架构图
2.文件加密
这里的文件加密不是指给文档设置一个密码或者给文件压缩设置压缩密码,而是企业里常用的透明加解密方案。所谓透明是指,对使用者来说是未知的,当使用者在打开或编辑指定文件时,系统将自动对未加密的文件进行加密,对已加密的文件自动解密。文件在硬盘上是密文,在内存中是明文。一旦离开使用环境,由于应用程序无法得到自动解密的服务而无法打开,从而起到保护文件内容的效果。
透明加解密产品的实现技术,分为两种:应用加密、驱动层加密。
·应用层加密。通过调用应用系统的 Windows API 函数来对文件进行读写的加密控制,即平常所说的 Hook 技术。通过 Hook 技术,当监控到可信进程打开加密文件的时候将其进行解密,当监控到可信进程写入文件到磁盘的时候进行加密;而驱动层则工作在更底层,通过拦截操作系统文件过滤驱动的读写动作对文件进行加解密控制,由于工作在受 Windows 保护的内核层,运行速度更快,加解密操作更稳定。
·应用层加密,关心的是应用软件的行为(读写),由于各种软件读写数据的行为差异,软件环境的变更会带来巨大的开发成本与测试成本,增加二次开发的费用。而驱动层技术涉及 Windows 底层,开发难度相对更大一些,记得当年某同学研究微软新的文件过滤驱动 Minifilter 就花了整整半年时间。驱动层加密的难点不在于和文件系统的交互,而在于和其他系统内核模块的交互,特别是缓存系统。系统会把刚用过的文件内容缓存起来,于是同一份文件内容会同时出现在两个地方:缓存中和文件系统中。于是加解密过程需要同时处理这两处,同步、兼容等一系列过程,实现起来可难受了。如果处理不好与其他驱动的冲突,搞不好就会出现蓝屏或文件损坏。另外,如何确认一个进程是合法的需要解密也比应用层处理起来更麻烦一些。
业界关于到底是驱动层加密好还是应用层加密好的争论从来没有停止过,笔者多年前在某文档安全厂商工作,对市面上几乎所有的加密产品做过测试,特别是安全性测试,也实施过很多大型项目。应用层加密,有的产品会通过临时文件的方式来处理,一旦对临时文件的保护处理不到位就容易被人拿到明文。当然,并不一定驱动层就更安全,因为应用程序会有各种各样的功能,比如通过网络发送、通过管道传输、进程内部的复制粘贴拖拽、插入对象、甚至直接输出 exe 文件,还要防止截屏软件截图等,这些在驱动层是很难控制甚至无法控制的,所以很多家的厂家都会采用驱动+应用控制的方案来实现,比如,在应用层加解密结合在驱动层做防护,或者在驱动层加解密结合在应用层控制。
结合笔者经验,企业选择透明加解密类产品,需要结合具体企业的场景来看:
·如果保护的只是小范围的 Office 和 PDF,而且不会有太多交互,那两种方式加密基本上问题都不大。
·如果涉及研发代码类编译场景,采用应用层加解密,速度会是一个很大的问题。
·如果涉及各种内部交互,比如 OA 系统调用本地 Office,PDM 系统调用本地 AutoCad 程序等,那应用层加密会更加灵活一些。
·如果企业内部应用要实现服务端明文、终端密文,那还需要考虑如何防止合法终端进程走网络将数据传到非法服务端,一般的厂商会引入网关方案。
·如果推广范围较大,还需要考虑各种场景,如文件解密流程、笔记本临时或长期离线、文档外发控制、不同部门的密钥管理、支持不同的操作系统或移动终端等,需要自己评估。
企业在选择方案的时候一定要多方评估,目标产品是不是该公司的核心业务,否则可能在不久的将来也会面临类似的问题。
14.2.2 权限控制类
除了透明加解密之外,企业用户往往需要做更细粒度的控制,包括阅读、复制、编辑、打印等,我们称之为权限控制类方案。这里以微软 RMS 方案为例进行讲解。注意权限控制不代表不使用加密技术,相反,方案通过使用加解密、密钥管理类的技术,来保障被授权的用户才能有权限使用该文档;而文档权限的控制,保障被授权的用户,权限能够更细粒度地区分,比如阅读、复制、编辑、打印、二次授权、使用时长、打开次数、被打开的机器数量等。其中一些权限,如阅读、编辑、打印等,是通过控制文档编辑器来实现的,而二次授权是通过解密再加密授权实现的。
由于欧美和亚洲在防主动泄密的理念以及对用户安全意识的信任是不同的,导致产品功能稍有不同,但对用户的使用体验甚至安全性上有非常大的影响。在欧美,文档权限管理的目的,更偏重于让有安全意识的用户更好地授权自己的文档,以及信任有安全意识的用户合理使用文档,如果他一旦利用漏洞进行主动泄密,更多交给 DLP 来实现。但在亚洲,文档权限管理的目的更多是防止主动泄密,希望将被授权用户管理得非常严格。
说一下具体的场景:“阅读”这个权限非常好理解,就是被授权用户只能读,不能做任何其他操作。但以最典型的文档“复制”权限为例,是允许用户只能将该文档里的内容复制到其他的加密文档,还是可以复制到邮件或 Web 类的 OA 应用呢?微软的 RMS 是允许的,国内的很多软件是禁止的,或者是有限字节拷贝。双方都有合理的理由。
RMS 产品允许复制的原因是,的确有工作场景需要:
·加密的文档,只是文档中有些内容涉密,不等于所有内容都是高度涉密的。
·文档内容的交互不仅仅只是文档和文档之间,常常有些工作场景需要摘录文档中一些统计类图标、内容,发在邮件正文中作为报告的摘要信息提示。比如,系统方案上 OA 应用评审,也希望摘录部分不太涉密的评审点。因为随着信息化系统的高度发展,信息流转不仅仅是在文档和文档之间,也在文档和系统之间。但这样虽然方便了用户,却会造成安全风险,因为一旦可以将内容拷贝到邮件或者 OA 应用,那么加密就失效了。但欧美的理念是,员工都经过了安全意识教育,被授权的用户也应知道这些信息该如何处置,哪些内容可以复制到非加密的应用中而哪些不可以。如果他们主动或过失泄密,在技术上有 DLP 的监测或者其他审计,在管理上公司可依制度和法律问责。
国内产品禁止复制的原因,想必大家都能理解,因为一旦可以复制,就有极大的泄密风险,对于蓄意泄密的用户这就是很好被利用的策略漏洞,那企业在这方面的努力就付诸东流了。但这样做又会极大影响用户体验,一般有两个缓解方法:
·梳理并培训业务的核心信息。让用户知道,哪些信息该加密和授权,哪些信息不需要,避免加密和授权的滥用。这样也就较少存在上述由于权限管理严格导致信息交互不通畅的问题。但说起来容易做起来难。
·受限拷贝。限制字节数拷贝到非加密应用中,如邮件、OA 系统等,辅助对拷贝次数进行分析和自动化预警。策略越复杂,产品也越容易出 Bug。而且,字节阈值的限定也是一个难题。
不纠结以上这些细节,RMS 与微软 AD、Office 整合在一起是非常完美的,可惜很多企业还有大量非 Office 类文档需要保护,如设计图纸,源代码等。另外,此方案与 AD 绑得比较紧,用户名密码这种身份认证满足不了一些高安全要求的企业场景,而加密密钥保存在计算机上容易被不法分子通过技术手段获取,所以很多国内企业也趁机推出了自己的权限控制类产品,如控制打开时间、打开次数等。这类产品往往需要对原来的文件格式进行转换,采用厂商的定制工具打开,最后还是会调用原应用程序,只是在这个过程中控制一下权限,但一旦打开,后里面的各种应用功能(如剪贴板、插入对象等)也不太好控制,所以目前在市场上越来越少见了。
近几年,随着国产化的逐步推进,WPS 在政府军工企业用得越来越多,金山公司提供了文档安全相关的功能,除了有文档加密功能外,还有权限管理功能,包括浏览、编辑、复制、打印、另存、截屏、授权七种权限可以控制,而拥有文档授权权限的用户和文档安全管理员可以将权限授予给其他用户、部门或用户组,用户和管理员的操作日志在后台都能完整记录。除此之外,还有文档外发、打印分发等功能。
比较特别的一点是 WPS 安全文档的加密机制,与传统电子文档安全软件不同,安全文档采用一文一密钥的机制,密钥本身会二次加密,二次加密密钥由服务器产生并保存,每次打开安全文档需要到服务器利用二次密钥解开文档密钥,才能打开安全文档,多重防护确保了文档安全,保存与打开文档流程如图 14-4 和图 14-5 所示。
图 14-4 WPS 保存安全文档流程
图 14-5 WPS 打开安全文档流程
加解密方式特性如下:
·客户端密钥 Client 在每次保存时都会重新产生,以保证其安全性。
·服务端密钥 Server 不传输到任何地方。
·权限信息不写入安全文档中,而是保存在服务器。
·客户端和服务器均使用标准 AES 进行加解密,支持接入第三方算法。
企业如果决定使用 WPS 的安全文档方案,请认真考虑以下几个问题:
·企业里 WPS 推广落地效果如何?毕竟 WPS 和 Office 还是有差距的,有些 Excel 里的高级功能在 WPS 里可能没有或者不完善。
·密钥都存在后端服务器上,文档解密都需要与后端服务发生关系。如果服务端可用性架构设计不妥或者运维不当,都可能导致文件无法正常打开,这点需重点关注。
·每个文档都有不同的密钥,如果考虑到特殊情况下要全部解密怎么办?WPS 安全文档还提供了金钥匙功能,可以将其理解为一个万能钥匙,前提是在加密的时候使用这个 KEY,那这又引入了一个风险,这个 KEY 的保存、使用过程是否安全?
14.2.3 终端 DLP 类
市面上除了加密和权限控制类方案之外,还有一些提供终端 DLP 功能,通常包括敏感文件识别、外发文件阻断、外设端口管控、日志审计分析等功能。其中,最关键的是敏感文件识别,如果连文件内容都无法准确识别,那后面的阻断就成为无稽之谈。而外设端口管控、日志审计分析,在一些桌面管理类方案都有涉及,此处不过多阐述。
敏感文件识别,首先,要对终端上的各类文档进行深入解析,通常 Office、PDF、压缩包、文本类都是必需的,在测试的时候一定要对不同版本的 Office 文档进行测试,因为不同版本产生的文件格式也不一样;Office 还提供一些诸如插入对象的功能,那么 Word 里插入一个 xls 能解析吗?压缩有 Rar、Zip、7z 等格式,不同格式又会有一些不同的压缩算法,RAR5 支持吗?7-Zip 里的 LZMA、PPMd 等支持吗?图片文件是否能 OCR 识别?最后,copy/b 的绕过方法能否在 DLP 方案里有所体现,这是个加分项。其次,在解析内容的基础上,匹配相应的策略来判断文档是否敏感,从简单的关键字、正则表达式,到文件指纹,数据库指纹,再到语义分析、机器学习等,在条件上的与、或、非各种组合下,才能判定文件是否敏感,敏感度是多少,相应的动作是否阻断等。
外发文件阻断,通常需要考虑一些泄密的场景,包括 U 盘拷贝、打印、压缩、拷贝到共享、拷贝到远程桌面、拷贝到虚拟机、光盘刻录、邮件客户端发送、QQ/RTX/微信等通讯软件聊天以及传附件等一系列场景,有的甚至需要对截屏、剪贴板进行控制。至于是采用阻断还是采用只监控审计的方案,要看企业需求和文化氛围,只监控审计的方案对最终用户无感知,体验会更好,也更容易在企业落地。
14.2.4 桌面虚拟化
数据一旦落到终端,很多方案都会存在失效的可能。随着云计算、大数据的发展,很多企业意识到将数据统一集中管理、不落到终端上是一个不错的方法。在桌面虚拟化技术成熟之前,很多企业就已经在开发类似的方案了,基本上都围绕一个思路—数据不落地。比如,针对数据仓库的数据防护,采用瘦终端+终端服务器跳转来实现,结合外围物理控制,比如门禁、保安、不允许手机带入等。
得益于服务器虚拟化技术的成熟和服务器计算能力的增强,使得服务器可以提供多台桌面操作系统的计算能力,将远程桌面的远程访问能力与虚拟操作系统相结合,形成了桌面虚拟化技术。有些场景可能不需要用户有个完整的桌面,只需要特定的应用,于是出现了应用虚拟化。VMware 的虚拟桌面方案示意图如图 14-6 所示。
图 14-6 VMware 的虚拟桌面方案
虚拟桌面方案对网络质量要求较高,不同厂家的远程协议有各自的优化处理方案,需要仔细对比体验,除此之外,我们需要关注以下的一些关键点:
·用户认证功能。 一般方案都提供本地用户密码认证、AD 认证,有的还支持双因素认证。
·USB 存储功能。 有些场合需要使用 USB 设备,所以一般都提供了 USB 重定向功能,如果 USB 的存储功能受限,将会成为一个数据泄露的途径。
·剪贴板功能限制。 为了方便地将本地剪贴板内容拷贝到虚拟桌面,一般的方案都提供了剪贴板重定向功能,最好有方向上的控制。
·MAC 地址绑定功能。 虚拟桌面 IP 和 MAC 地址绑定,瘦终端的 MAC 地址与用户账号绑定,或者与虚拟计算机的名称绑定等。
·PC 截屏功能。 数据都在服务端,本地终端能看到但拿不到,难免会有人想截个屏,然后到本地桌面粘贴,这时候防截屏功能就能发挥作用了。
·虚拟桌面水印功能。 截屏不行还可以拍照,所以水印功能也必不可少,有明文水印,有些厂商还提供隐藏水印功能。
·如果在没有全员迁入到虚拟桌面的情况下,怎么保障虚拟桌面用户只能通过虚拟桌面而不能通过本地计算机访问核心信息系统,从而保障核心信息不落地?
·虚拟桌面本质上相当于将物理终端从前台移到了后台,解决了物理终端设备边界的问题,对于从网络和应用上访问所形成的数据安全风险,还需要结合其他安全方案进行巩固。
14.2.5 安全桌面
不同于桌面虚拟化方案在已有终端利用率不高、网络和后台资源占用多的情况,目前市场上还有一种“安全桌面”方案,其本质是利用 Sandbox 技术,在真实系统上虚拟出一个安全桌面,当用户访问敏感系统或数据的时候要使用安全桌面。基于沙箱的安全桌面可以在操作系统使用时虚拟出多个专用桌面,在这些专用桌面上的操作与宿主桌面共用操作系统和应用程序,但是不会共用数据。例如,在专用桌面中编辑文档信息和在宿主桌面一样,使用相同的办公软件,但是数据完全隔离,两个桌面各自编辑自己的文档。在基于沙箱的安全桌面上结合终端监控工具,就可以彻底区分业务数据,通过网络访问控制区分宿主桌面和专用桌面的访问范围,可以限制业务系统只能接受某些专用桌面的访问,并且结合存储控制,例如,数据只能存储在远程的文件服务器上或者禁止移动存储设备接入,完全能够实现监控专用桌面的数据访问和存储,对于业务数据保护非常完善。
结合笔者经验,此类方案主要存在两大问题需要解决:
·沙箱技术与操作系统强相关导致的兼容性问题。微软新推出一个操作系统,你的安全桌面方案还能支持吗?微软 IE 浏览器升级后,安全桌面方案是否需要调整?
·沙箱的隔离技术与操作系统功能导致的安全性问题。我们知道,进程除了与文件打交道,还会涉及网络、管道等,方案对不同桌面的网络控制进行了限制,其保护机制如何?简单修复 SPI 是否能绕过?在默认桌面起个服务监听网络端口然后在沙盒里通过网络访问呢?进程间通信管道用来传递数据呢?
终端本来就复杂,很多厂商不会在上面投入太多精力,随着操作系统和应用软件的不断升级,最后导致的结果就是支持力度上不去,使用了该方案的企业可能会陷入被动局面,所以请谨慎选择。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论