【】不可否认，我们正处在数据爆炸的时代，无论是初创公司还是百年老店，企业里的各种文件每天都在以几何的数量级增长着。数据在企业内部的存储和企业之间的流通环境日趋复杂。无论是在数据库、应用中间件、用户终端、业务系统和网络设备上，还是数据的产生、存储、使用、修改、流转和销毁等各个环节，数据泄漏的可能性随时随处都会发生。
[[196054]]
我们作为企业一线的IT人员，面对这些反复重演的扎心剧情，就算你能拍马赶到，也往往却是为时已晚。面对领导的压力和用户的抱怨，我们光靠躲进“深夜厨房”吃泡面是显然不够的。那么这一次，让我来给大家静水流深地切开数据泄漏防护(DLP)这块“大牛排”，咱们一口、一口地来咀嚼它。
西方理念中常提到“双人舞”的概念，我们东方人则常谈的是围棋里的两眼论，那么下面我就从防御和检测两个方面来进行深入讨论。
识别数据泄露的“灾区”
- 有过数据库管理经验的小伙伴应该都有这种感受：如今各种安防产品对各种后台数据库里的数据可谓是“严防死守”，而往往容易造成敏感数据泄漏的形式却是那些非结构化的内容。说白了就是那些Excel、PPT里的数据，以及PDF和剪贴板的图片文件等。
- 另一个数据泄露的“灾区”是企业的文件与信息的交换平台，如大家日常频繁使用的邮件客户端(如Outlook)和内网协作平台(如SharePoint)。当前，随着云平台的使用，各种企业混合云以及公网上的共享云平台(如百度云等)都成为了数据被转移出去的“跳板”。
从管理上杜绝泄漏的发生
- 在生成文档和数据的时候，应按照最小权限的原则设定好各类属性的默认值，如attribute默认为私有(private)而非公开(public)，可访问(包括读/写/改/删等权限)的用户群仅限于创建者所在的部门和组。同时在属主(属主不一定是创建者，也可以是日常使用人)的岗位发生变化时(如离职或调岗)，要做好接任属主的接管工作。
- 规范文件、文件夹和数据的命名规则(Naming convention)，以便能够根据其表征名称迅速定位或追查。
- 对于那些并无属主或是项目已结束的文档，本地管理员应及时联系业务部门做好集中和离线转移的工作。
- 对于各种非常规的共享方式，如按需添加的服务器或主机文件夹的临时共享，应予以集中化的记录。这是在源头上实施的用户行为和习惯控制，也是数据泄露防护的最佳实践之一。
- 培养用户在处理敏感数据时的遮挡意识和与客户交换文件时的加密习惯。
从架构上清除泄漏的坑点
- 用户终端必须使用安全的代理服务器进行上网，以预防恶意软件、钓鱼网站、域名劫持和其他类似的攻击。
- 入站的电子邮件里如果包含有外部的链接，应通过反钓鱼技术的链接重写方式发送到管控中心进行健康检查，从而抵御潜在的垃圾邮件和钓鱼攻击。
- 用户终端除了本地的硬盘加密之外，还要通过组策略(Group Policy)禁止用户擅自修改系统设置和安装软件。
- 为那些必须连到内网进行协作的上下游合作伙伴，提供非本域的账号和受限的科学远程连接方式。同时，非本域的账号登录到企业的无线网络时，应限制其仅能向外访问到互联网，这种单一的访问路径与权限。
- 通过在用户终端上安装主机测的DLP agent，过滤和监控带有敏感字段的文档、数据(如源代码)、邮件以及剪贴板上的内容，防止用户通过网络或移动设备拷贝的方式转移到不安全的系统、设备甚至是公网的网盘上。
- 在内网中部署网络级的DLP，以旁路式分析流量，从而识别出im(即时通讯)、http、ftp、telnet和smtp等协议中正文及附件内容。
- 对于如今许多企业都应用到的云服务，可以购置和部署最新类型的DLP，通过与云访问安全代理 (CASB)的集成，持续监控各种云应用程序中敏感数据内容的添加、修改和删除。
有“记”无患，未雨绸缪
前面几期的廉环话，我们有提到对系统和网络日志的检测。正所谓巧妇难为无米之炊，那么首先你就要能得到及时且充分的各类日志。在设计或添置日志系统的时候，我们需要扪心自问、或是与部门内成员讨论如下与记录有关的问题：
- 进行了什么操作?
- 谁或是哪个系统(即主体)执行的操作?
- 对谁或是哪个系统(即对象) 执行的操作?
- 何时操作的?
- 操作用到了什么工具?
- 操作后的状态(如成功与失败)、结果、或输出是什么?
在日志分类上，想必大家都能区分出：操作系统日志、应用系统日志、数据库日志、网络设备日志和安全设备日志的基本不同。而各类日志所记录的基本信息也应涵括到：设备/服务本身的启动/关闭/重启，用户的登录/注销/密码修改，服务属性的配置/变更，关键进程/端口的启动/关闭，权限的切换，以及各种报警/故障信息等。
既然有这么多类型的日志，而且会产生海量的记录条目，那么我们就需要用一套集中化的日志管理系统，通过使用syslog或syslog-ng之类的开放网络协议来汇聚历史信息，从而进行过滤和分析。说到这里，爱思考的小伙伴也许会问了：既然针对的是历史信息，那么是否有针对实时的呢?我的回答是：还真的有，那就是SIEM(安全信息事件管理)，它可以对各类实时的记录进行事件关联与趋势分析。
值得多说一句的是：一般日志管理系统都应该能够将发送来的、各种格式的日志存储到一个遵循ansi-sql规范的数据库中，以方便日后生成适合审计的日志文件。
准确定位，有的放矢
前面我们介绍了各项基础性的准备工作。Let’s move forward。正所谓没有绝对的安全。那么一旦不幸发生了数据泄漏事件，我们应该从哪里着手进行检测甚至是取证呢?在此，我给大家提供一个可参考的速查蓝本。
- 在用户终端上，使用取证工具对电子邮件客户端、浏览器的脱机内容、浏览历史等进行检查。注意，有些人会使用到不同的浏览器(如IE、Chrome、Firefox等)，因此一定要逐一检查每一个浏览器的历史记录。
- 在代理服务器的相关日志里检查可疑账户访问过的URL及其服务类型。
- 在可疑用户使用过的各种外部存储设备(如U盘、CD、DVD、移动硬盘、智能手机以及SD卡等)上直接或间接(如利用恢复工具)寻找蛛丝马迹。
- 当然，用户也可能身处企业之外，通过科学连进来，或者是在企业内连接到外部的SSH服务器进行数据的收与发。在这种情况下，我们一般只能找到有关连接的记录证明，却无法查看到具体传送的数据内容。
- 除了电子的形式，数据或文件也可能被发送到打印机转成hard copy。在这种情况下，我们应该对用户端的假脱机程序或直接在打印机上进行检查。
- 有时候用户并非主动泄漏信息，而是其终端上的恶意软件所致。对此，我们可以结合网上最近针对各类频发的恶意病毒的相关对策进行逐一识别。这里就不赘述了。
识别关键，筛选策略
既然我们屡次提到日志和记录，那么面对汗牛充栋的“大数据”，应该如何大海捞针呢?我分享给大家如下的特征关键点，以便籍此进行筛选策略的制定：
- 新用户或组的添加，对用户权限的改变，身份验证和授权的相关活动。
- 文件及文件夹属性、注册表键值以及计划任务(自启动项)的更改。
- 系统和软件补丁的安装和更新，新软件的安装、升级与卸载。
- 数据库对象权限的修改。
- 达到资源门限值(比如CPU、内存、网络连接、网络带宽、磁盘空间等)所导致的应用程序进程的中止、异常或报错，网络服务(如DHCP和DNS)的失败，以及硬件故障等。
- FW/IDS/IPS/AV(防病毒系统)的规则更改和端口调整。
日志元素，抽丝剥茧
在得到了上述筛选过的分类记录之后，我们可以回顾一下在前面准备设计阶段所思考过的问题列表。我们同样可以进一步将“理想”照进“现实”，着手对如下的日志元素进行分析：
- 操作的类型，包括各种授权、创建、读取、更新、删除和网络连接的接受。
- 操作的属性，包括流程或事务的名称或唯一标识号。
- 操作主体的特征，包括用户名、计算机名、IP地址和MAC地址。
- 操作对象的特征，包括访问的文件名、访问数据库的查询/定位参数和记录的唯一标识号、用户名、计算机名、IP地址和MAC地址。
- 当操作涉及到更新数据元素时，其执行前、后的不同数值。
- 操作执行的日期和时间，包括相对应的时区信息。
- 根据访问控制机制，被拒绝的相关描述和原因/错误代码。
日志维护，查缺补漏
最后，我给大家分享一下日志系统维护的落地和实操。
- 首先最为重要的、也是经常被运维人员所忽略的是：日志管理系统必须保持其时钟信息与内网里各台服务器的时钟相同步。这可以通过设置NTP来实现，当然运维人员也可以每月检查确认，并予以记录。
- 各类日志内容至少需要保存半年，关键系统的日志甚至可以延长为一年。
- 任何运维人员不得擅自停用日志服务。如需暂停某项日志记录，则要走常规的变更管理的流程。
- 运维人员应每周登录到日志管理系统进行检查，对日志中的错误或可疑项进行记录。如发现有可疑的事件或无法判断的内容，应提交给信息安全部门进行分析，处理结果应当被补充标注到例检中。
- 各类日志文件应被集中管理和存放，同样需设置相应的日志文件的访问控制权限，以防止未授权的篡改或删除。
- 内部审计部门应当定期(如每季度)对日志的采集范围和筛选策略进行检查，并对各个系统管理员和操作员的操作记录进行审计。
小结
随着技术的不但迭代和升级，现在信息安全业界也出现了端点检测与响应(EDR)的解决方案。它不但可以基于威胁情报和大数据分析，来发现新的威胁行为或攻击迹象，还能进行威胁追踪和数据回溯。
我们做信息安全实务的，不应该只会单纯利用各类产品，像“打地鼠”那样出现一个问题就去解决一个问题，而是应该掌握基本全面的理念和思路，活用技术和产品实现1+1>2的闭环防护效果。各位老铁，上述的娓娓分析，虽谈不上什么庖丁解牛，但整体结构还算比较清晰，相信爱思考、爱做笔记的您已经能画出一张思维导图或是系统结构图了吧?好的，请直接拿去使用吧，不谢!
【原创稿件，合作站点转载请注明原文作者和出处为.com】
文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/135369.html<
