欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

防代码泄漏的监控系统架构与实践

来源:本站整理 作者:佚名 时间:2019-04-30 TAG: 我要投稿

0×01 概要
代码资源是组织的核心资源,对于敏感的代码是不希望流传到外部的,但由于各种原因还是有资源泄露出去, 对于泄露的原因先不论,因为相对比较难避免,但我们可以通过一定的技术手段对关键的数据进行审计监控,把资源泄露缩小到一定的范围内,现在普遍流行的方式是对Github进行监控,在Github查找敏感词,比较常见。本文在此之外提出了一种对内监控的方案,以SVN监控为例。从相关人员从内部系统下载时就行一定成度的监控审计,对下载者的下载量和行为进行分析,这个出发点建立一个监控系统。
0×02 关键资源与角色
整个数据泄露的过程是一个把关键资源从内部仓库下载到本地,再上传到Github的过程。对开发者本地的监听是比较不合适的,但我们可以对外部Github仓库监听,Github本身也提供相对方便的监听接口。我们这次重点不讲gihub的监控, 讲内部仓库监控分析, 自动化的产生下载量分析报告和特定行为提示的系统构建思路。
三种资源仓库:
1.内部仓库:组织内部的代码管理系统,外部人员不可见,比如SVN。
2.开发者仓库:开发者本地仓库。
3.Github外部仓库:Github对外公有仓库。

0×03 敏感资源角色关系模式
从代码资源生产到消费一般会有三种角色:
1.代码提交者: 代码工程相关上传人员,代码生产者。
2.开发下载者:开发者本身:
3.代码读者(消费者):本地仓库的消费者就是相关开发人员,外部Gihub仓库的消费读者就是Github用户。
我们的系统是,增加一个第4种人:安全管理监控人员。通过接入二种监控系统来分析当前资源是否泄露:1.内部仓库下载行为分析系统。2. Github敏感词监控系统。

0×04 重要监控着眼点
内部仓库监控和外部仓库监听的核心关注重点是什么。
1.内部仓库监控重点:关键代码资源被下载时要关注,异常下载量过大要关注,特别用户的下载要关注。内部监控系统的成果物:下载量统计更表,重点资源被下载报警提示。
2.外部仓库监控重点:外部仓库因为我们没有明确的用户列表,现阶段是通过对关键资源有关联的关键字进行监控, 这种系统很多公司都在用,文章最后我们给出代码方案。

0×05 构建内部仓库审计分析系统的生产实践
对于内部了仓库系统进行审计的一个关键是,如何收集相关的数据,其次是如何分析数据,分析行为。一般企业代码管理仓库可能有自己的特定要求,对于主流的代码管理工具来说,最常的工具就是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或是其它语言工具都可以,每个公司的业务不一样,自己定制比较好。
0×06 监听任务分发处理
为什么用RPC做监听分析处理:
日志是用户行为分析的最好的素材,上面系统的构建后,我们可以通过REST API相对容易的得到日志数据,下面我们就可以集中精力,实现我们的监控策略。我们通过按一定的时间周期自动拉取分析的日志数据。crontab与监听的调度问题,Cron在这里只是我们按时间切分执行任务的一个触发者,我们在真正的分析处理和Cron之间加了一层任务调度层Wrapper应用,Cron只是执行到Wrapper层,具体调度任务的内容可随时调整 ,与时间周期无关的更新都不用修改Cron,然后再次解耦,用RPC把监听与Cron机分开,通过Wrapper层进行通信, 这样具体监听分析处理和Cron调度放到不同机器上。如果监听审计的需求变更,只需要改Wrapper调层配置好新执行层就可以免于整体工程的集中变更。

分析成果物:
我们设计的这个系统的成果物是: 单位周期X内用户SVN下载量的统计,特定资源下载提示报警,高权限用户下载行为提示。可以通过邮件、钉钉、企业微信等形式通知管理员。随着安全策略的增加,报告成果物也会越来越多。
0×07 总结
自动化的审计手段只能在一定程度上监控审计泄露问题,但不能从根本杜绝问题的发生。本文只是对我们生产实践系统的一次思路分享,有不足的地方希望大家给出您宝贵的意见,帮助我们改进。
本文提供了内部监控和外部监控二种方案:
1.Github外部监控:给大家推荐一个方案:https://github.com/freebuf-friends/x-patrol
2. 内部监控:要搭建自己的日志系统,就推荐文章,以大家的工程能力搭建系统和实现监控都不难。ELK、SPLUNK、Graylog根据场景选择,这种系统是平台系统,构建完成了可多次重用,不只可能分析SVN行为审计,可以分析各种数据行为。
 

【声明】:黑吧安全网(http://www.ylxj.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载