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

admin 2022年3月24日02:49:02企业安全评论31 views2208字阅读7分21秒阅读模式

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

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 总结

自动化的审计手段只能在一定程度上监控审计泄露问题,但不能从根本杜绝问题的发生。本文只是对我们生产实践系统的一次思路分享。


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


本文始发于微信公众号(疯猫网络):防代码泄漏的监控系统架构与实践

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年3月24日02:49:02
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  防代码泄漏的监控系统架构与实践 https://cn-sec.com/archives/510393.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: