防代码泄漏的监控系统架构与实践 – 作者:糖果L5Q

*本文作者:糖果L5Q,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

0x01 概要

代码资源是组织的核心资源,对于敏感的代码是不希望流传到外部的,但由于各种原因还是有资源泄露出去, 对于泄露的原因先不论,因为相对比较难避免,但我们可以通过一定的技术手段对关键的数据进行审计监控,把资源泄露缩小到一定的范围内,现在普遍流行的方式是对Github进行监控,在Github查找敏感词,比较常见。本文在此之外提出了一种对内监控的方案,以SVN监控为例。从相关人员从内部系统下载时就行一定成度的监控审计,对下载者的下载量和行为进行分析,这个出发点建立一个监控系统。

0x02 关键资源与角色

整个数据泄露的过程是一个把关键资源从内部仓库下载到本地,再上传到Github的过程。对开发者本地的监听是比较不合适的,但我们可以对外部Github仓库监听,Github本身也提供相对方便的监听接口。我们这次重点不讲gihub的监控, 讲内部仓库监控分析, 自动化的产生下载量分析报告和特定行为提示的系统构建思路。

三种资源仓库:

1.内部仓库:组织内部的代码管理系统,外部人员不可见,比如SVN。

2.开发者仓库:开发者本地仓库。

3.Github外部仓库:Github对外公有仓库。

0x03 敏感资源角色关系模式

从代码资源生产到消费一般会有三种角色:

1.代码提交者: 代码工程相关上传人员,代码生产者。

2.开发下载者:开发者本身:

3.代码读者(消费者):本地仓库的消费者就是相关开发人员,外部Gihub仓库的消费读者就是Github用户。

我们的系统是,增加一个第4种人:安全管理监控人员。通过接入二种监控系统来分析当前资源是否泄露:1.内部仓库下载行为分析系统。2. Github敏感词监控系统。

0x04 重要监控着眼点

内部仓库监控和外部仓库监听的核心关注重点是什么。

1.内部仓库监控重点:关键代码资源被下载时要关注,异常下载量过大要关注,特别用户的下载要关注。内部监控系统的成果物:下载量统计更表,重点资源被下载报警提示。

2.外部仓库监控重点:外部仓库因为我们没有明确的用户列表,现阶段是通过对关键资源有关联的关键字进行监控, 这种系统很多公司都在用,文章最后我们给出代码方案。

0x05 构建内部仓库审计分析系统的生产实践

对于内部了仓库系统进行审计的一个关键是,如何收集相关的数据,其次是如何分析数据,分析行为。一般企业代码管理仓库可能有自己的特定要求,对于主流的代码管理工具来说,最常的工具就是SVN和Git。我们以SVN为例,我们选择对SVN的日志进行集中并进行分析,来实现对资源和用户的审计。

构建内部监控系统分两步走:

1.系统日志收集: 收集SVN系统日志,传统的SVN日志都在服务器本地,需要把文本日志集中。一般重要生产服务器是不希望部署太多的不相关服务,系统本身的工具如Rsyslog、Rsync不会对系统的稳定性有损害。如果不在乎数据同步的周期时间快慢,可以使用Rsync进行日志数据同步。

2.日志数据接口化:对自动监控程序来说,好的交互方式不是去直接读文本,如果可以通过调用REST API, 监控业务可以集中做监控策略而不是,把大量的时间去做数据处理。所以像ELK、SPLUNK、Graylog这种数据服务的存在就可以减监控开发本身的工作量。

对于一般的公司来说,可以选择适合自己的方式,选择对应的方案进行处理。这里我们抽象出了一个相对通用的处理流程给大家,但不一定能普通适用所有场景。

我们将日志数据接口化构建分成5个步骤:

1.SVN文本日志-> 2.rsync到一台大容量文本服务器->3.文本服务器部署nxlog发送到syslog服务器->4.syslog服务器进行数据接收并通过本地服务将文本数据存入ES–>5.建立一个数据网关对外提供REST API服务提供数据查询。

3 监听策略实施:当我们有了日志查询的REST API,再对数据进行监控就是相关容易了, 我们通过ES本身的功能,进行数据的检索和统计。使用Python和GO或是其它语言工具都可以,每个公司的业务不一样,自己定制比较好。

0x06 监听任务分发处理

为什么用RPC做监听分析处理:

日志是用户行为分析的最好的素材,上面系统的构建后,我们可以通过REST API相对容易的得到日志数据,下面我们就可以集中精力,实现我们的监控策略。我们通过按一定的时间周期自动拉取分析的日志数据。crontab与监听的调度问题,Cron在这里只是我们按时间切分执行任务的一个触发者,我们在真正的分析处理和Cron之间加了一层任务调度层Wrapper应用,Cron只是执行到Wrapper层,具体调度任务的内容可随时调整 ,与时间周期无关的更新都不用修改Cron,然后再次解耦,用RPC把监听与Cron机分开,通过Wrapper层进行通信, 这样具体监听分析处理和Cron调度放到不同机器上。如果监听审计的需求变更,只需要改Wrapper调层配置好新执行层就可以免于整体工程的集中变更。

分析成果物:

我们设计的这个系统的成果物是: 单位周期X内用户SVN下载量的统计,特定资源下载提示报警,高权限用户下载行为提示。可以通过邮件、钉钉、企业微信等形式通知管理员。随着安全策略的增加,报告成果物也会越来越多。

0x07 总结

自动化的审计手段只能在一定程度上监控审计泄露问题,但不能从根本杜绝问题的发生。本文只是对我们生产实践系统的一次思路分享,有不足的地方希望大家给出您宝贵的意见,帮助我们改进。

本文提供了内部监控和外部监控二种方案:

1.Github外部监控:给大家推荐一个方案:https://github.com/freebuf-friends/x-patrol

2. 内部监控:要搭建自己的日志系统,就推荐文章,以大家的工程能力搭建系统和实现监控都不难。ELK、SPLUNK、Graylog根据场景选择,这种系统是平台系统,构建完成了可多次重用,不只可能分析SVN行为审计,可以分析各种数据行为。

相关文章

请戳:

一般型网站日志接入大数据日志系统的实现:https://www.freebuf.com/column/166112.html

老树新芽:Windump与大数据工具结合做流量统计分析:https://www.freebuf.com/articles/network/144767.html

*本文作者:糖果L5Q,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

来源:freebuf.com 2019-05-01 09:30:53 by: 糖果L5Q

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论