从B站的代码泄漏事件中我们学到了什么？

本文仅站在技术人的角度，从这次的代码泄露事件，聊聊在代码的安全管理上，通常都需要做哪些事来预防此类事件的发生。同时，大家在阅读本文的时候，也可以深入思考下，自己团队是否也存在类似的问题，经过这次的事件，是否有必要针对性的做一些优化。

最小权限

“最小权限”原则是我们在学习Linux用户管理时候经常被提到，并且被反复强调的内容。该原则是指每个程序和系统用户都应该具有完成任务所必需的最小权限集合。赋予每一个合法动作最小的权限，就是为了保护数据以及功能避免受到错误或者恶意行为的破坏。

在代码的安全管理上，“最小权限”原则同样适用。但是，从此次的代码泄露内容中可以看到，这一点做的并不好，一起来看看源自泄露代码的README介绍：

从说明中，可以知道这是一个后端项目的大仓库，每个业务线都通过文件夹的方式管理自己的业务模块。那也就是说，每个业务模块的人都是可以看到这个大仓库的。继续看README最后的负责人信息：

可以看到这个大仓库中包含了非常多的业务模块与相关负责人信息。

由于Git的权限管理都是对整个仓库的，无法精细化到具体的文件夹。换言之，对于这个大仓库的访问，其实是有非常多的人员可以拿到全量代码的，而其中有大部分代码可能并不是自己业务线的内容。可见，这个仓库的内容，对于代码自身的保护上，并没有做到最小权限控制。所以，当出现代码泄漏的时候、对于泄露范围就很难控制。可能一个小环节的过失，就会导致非常大的泄漏灾难。

配置分离

配置与代码的分离，自云原生应用的流行开始，就一直被反复的强调。将配置内容隔离开之后，赋予代码的将仅仅是逻辑，对于各种与环境相关的敏感信息都应该被剥离出去，这就使得代码中将不再含有各种环境信息和敏感信息。同时，这么做也可以轻松的实现多环境的不同配置，这种实现方式与我们传统通过构建工具来实现的多环境是完全不同的。只有在严格分离了配置之后，才真正的可以实现：一次构建，多处运行的目标。基于构建工具实现的多环境部署，实质上多次构建，多处运行的结果，每个环境运行的介质只是上都不是同一个程序。

为什么要强调这一点呢？同样的，我们看看从网络上流出的一段代码片段：

如果这段代码是真实存在的话，那么配置管理和安全意识上确实就做得非常差了。

所以，对于配置中心的建设，大论大小团队，从安全角度上来说，都是非常重要的。何况在目前有大量开源配置中心的大背景之下，做到配置分离，是一件性价比非常高的事。如果做到这一点，那么即使代码有流出，对于重要密钥、数据库账户密码等等敏感信息也不会被泄露。

外部监控

任何与安全相关的内容，都少不了监控。事前的所有策略，最终都有可能被一一击破，留给我们最后的一道防线就是在事件发生之后马上得将其堵住，以防止问题的扩大，而造成更大的损失。

在笔者知道这件事的时候，距离代码上传已经有6小时之久了。各类技术讨论群中几乎也都是相关信息的八卦。几乎每一次刷新页面，都是几百Star的增长。虽然处理的速度不能说快，但是没过多久，与之相关的仓库都开始无法访问。至于，是不是有做代码泄露扫描的监控，我们不得而知。因为，在扫描告警之后，对于代码的扩散控制，作为B站来说，本身是被动的，还是需要Github等仓库运营方来完成。所以，这中间到底哪一步慢了，我们无法考证。

不过这些都不重要，这里主要强调一点，除了管理上的防护之外，必须留一手外部监控，以快速的发现泄漏并采取措施。这块可能大部分开发人员不太了解，这边我就稍微提一下。做一下这个是不是很费劲？

对于很多中小团队来说，可能本身就没有什么人力去做这件事，那么是不是就没办法了呢？实际上，很多安全服务商，甚至一些大型互联网公司都有提供这样的产品服务。如果说，你连买这类产品的钱都不想出，那么顺手推荐一个开源项目可以参考一下：Github leaked patrol

转载自：https://www.cnblogs.com/didispace/p/10754729.html