从B站的代码泄露事件中，咱们能学到些什么？

先声明一下，本文不聊ISSUE中的七七八八，也不聊代码是否写的好，更不聊是否是跟蔡徐坤有关之类的吃瓜内容。仅站在技术人的角度，从此次的代码泄露事件，聊聊在代码的安全管理上，一般都须要作哪些事来预防此类事件的发生。同时，你们在阅读本文的时候，也能够深刻思考下，本身团队是否也存在相似的问题，通过此次的事件，是否有必要针对性的作一些优化。

最小权限

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

在代码的安全管理上，“最小权限”原则一样适用。可是，今后次的代码泄露内容中能够看到，这一点作的并很差，一块儿来看看源自泄露代码的README介绍：

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

能够看到这个大仓库中包含了很是多的业务模块与相关负责人信息。

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

配置分离

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

为何要强调这一点呢？一样的，咱们看看从网络上流出的一段代码片断：

若是这段代码是真实存在的话，那么配置管理和安全意识上确实就作得很是差了。

因此，对于配置中心的建设，大论大小团队，从安全角度上来讲，都是很是重要的。况且在目前有大量开源配置中心的大背景之下，作到配置分离，是一件性价比很是高的事。若是作到这一点，那么即便代码有流出，对于重要密钥、数据库帐户密码等等敏感信息也不会被泄露。

外部监控

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

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

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

对于不少中小团队来讲，可能自己就没有什么人力去作这件事，那么是否是就没办法了呢？实际上，不少安全服务商，甚至一些大型互联网公司都有提供这样的产品服务，好比携程的Github Scan：

若是说，你连买这类产品的钱都不想出，那么顺手推荐一个开源项目能够参考一下：Github leaked patrol

最近，欢迎留言交流，说说你们所在团队对于代码的安全性都是如何作的？用了什么商业服务？或是用了什么开源软件？欢迎一块儿分享学习与进步！