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

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

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行为审计，可以分析各种数据行为。

相关文章

请戳：

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

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

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