github private 添加成员 权限_阿里云代码托管平台上多家企业误开放访问权限，谁的锅？...

据铅笔道昨日上午报道，上海一家科技公司的后端工程师张中南在半年前发现，由于阿里云代码托管平台的项目权限设置存在歧义，导致开发者操作失误，造成至少40家以上企业的200多个项目代码泄露，其中涉及到万科集团、咪咕音乐、51信用卡旗下51足迹、百度无人车合作伙伴ecarx等知名企业，问题至今未完全解决。(注：嘶吼未对涉及到企业是否泄露的真实性负责)

张中南在文章中表示，他发现一些企业竟把数据库也抛在公网上，很多为公司生产环境的具体数据，只要按照里面记录的账号密码登录，就能访问。这些账号密码可能被不法分子利用，造成虚假支付、用户劫持、信息泄露等诸多恶劣后果。

他通过研究和猜测认为，之所以出现这种情况，可能是因为这些公司的程序员在给项目建库时操作不当，将项目权限设置成“平台公开”。因为当时的阿里云代码托管业务还是全英文平台，可能很多企业在创建项目的时候会误选择“internal”，也就是“平台公开”。

在他看来，“internal”的意思得因人而异，在个人用户看来，那么‘internal’的意义非常明确，就是使用这个平台的人都能访问。但如果是企业在使用代码托管，那么‘internal’的意义是‘对企业内的用户都公开’还是‘使用这个代码托管平台的人都能访问’呢？”

在讨论谁该背锅之前，我们应该先对存放代码平台有基础的了解。

GitHub & GitLab & 云效

GitHub和Gitlab等平台是主流的代码开发协作平台：

GitHub是一个面向开源及私有软件项目的托管平台，因为只支持git作为唯一的版本库格式进行托管，故名GitHub。这个平台很重要的一个功能是代码共享，这个平台支持两种项目权限，分别是public(公开)和private(私有)。此前，该平台如果想要设置私有项目是收费的。

GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。也就是说，这是一个托管平台，每个客户(企业)自己有一个独立的instance，每个instance里面可以设置用户、项目等等。在这个平台下有三种项目权限，除了上述的public和private之外，还有一个名为internal的权限，其英文注释是the project can be coloned by any logged in user，意义为项目可以被所有已登录用户克隆。

阿里云的云效平台创立于2012年，是阿里巴巴旗下一站式研发提效平台。平台提供了从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑。云效平台采用了和GitLab相同的权限设置方式。

谁该背锅？

在上文铅笔道的报道中，张中南认为“internal”权限存在歧义，导致了该问题的发生。那么，这个锅阿里背吗？嘶吼小编请教了业内的资深人士，发现公司创始人和安全专家有两种不同的看法。

一些人认为，这个锅应该阿里云背，原因如下：

GitHub为什么没有internal这样的设置？因为没意义，和public相比就多了一道注册的门槛(而且注册是任何人都可以做的)。

而每个GitLab客户自己有instance，一般而言，注册到某个instance都必须经过该instance管理员的同意。internal在这种情况下就有意义，比如企业内部一些公用的、密级不高的项目设置成internal就很方便。

因为一般用户在私有服务器上架设GitLab，平台会默认项目私有。云效平台的模式和GitLab相似，一些用户会把云效的internal选项理解为企业内部私有。

此外，从安全技术角度看，因为产品设计导致用户(而且不是一个两个)极易理解错误，这是一个安全隐患。

阿里的很多企业产品为了避免用户错误导致的安全问题做了很多工作。比如阿里邮箱，点开外链或者给公司以外的人发邮件时，都会给出非常明显、清晰的安全提示。

这才是阿里正常的水平，给出清晰、明显、不能绕过的提醒，而不是只有一个非常误导的、一个点击就能选上的"internal"

所以，云效平台应该对此承担责任。

另外一些人认为，这个锅不应该让阿里云背，理由如下：

第一，很多开发者错误的理解了internal的含义

网络尖刀团队创办人曲子龙认为，这些开发者习惯使用GitLab，而忘记了internal的本意是“老子有账号就能克隆”，而不是“所有的 internal 都是内部私有”。

他告诉嘶吼：“internal = the project can be coloned by any logged in user，翻译过来就是项目可以被所有已登录用户克隆，我不知道提出产品设计有问题观点的人，是对语文有什么误会还是对中文有什么误解？就因为平时都是在用Gitlab，因为是公司单独部署自己在用的私有版，就当做是团队内部私有来翻译？那我想这样的人，可能连Gitlab和GitHub都分不清！

如果是这样，我真的很想公开批评一下阿里云代码托管的产品经理，他把这群没有工程师文化的程序员素质想象的过高了，甚至有点高估了这群ZZ的英文水平。”

此外，也有人表示，阿里云这个应该是按照gitlab的权限名称设计的，类似一个公共的大Gitlab，所以造成歧义。但是其实这种事情一定是公司创建的人没有仔细阅读。创建代码仓库这种事情都不仔细看，还怪阿里云。

第二，公司应该有基本的安全体系

曲子龙在他的公开文章中表示，很多大公司安全部门都会做这样的机制和培训来防止敏感代码和信息的泄露，网络尖刀的好几个员工都写了关于GitHub泄露监控的相关工具，这已经成为了一个规范的体系。

为什么没有有效的管理、培训、风控体系，才让程序员犯了这么低级的错误，导致出这一的大问题，我想是每一个技术负责人都该自我检讨和思考的。

据嘶吼了解，这类低级错误事件不是个例，2018年12月，阿里云便回复了一个“可重置任意阿里云服务器root密码”的网络传闻，真实情况为某客户自身的管理员AK(access key)泄露所导致的独立事件。

所以，这些人认为，这个锅不应该让阿里云背。

事件后续与反思

嘶吼小编发现，阿里云在当日上午11:18分前便已更新了Internal的说明选项。

2 月 22 日下午 2 点左右，阿里云在其新浪微博上发布了关于 Internal 访问权限的说明。

与此同时，小编在下午发现云效平台的管理控制台增加了风险提示，但小编收到云效平台电话、短信、邮件提示。

小编无法判断是不是每个开发者都会每天登陆管理控制台，因此可能存在潜在风险。

此外，这些开发者虽然已经删除了代码，但是否存在外泄的数据，造成了多大的危害，还不得而知。

对这次泄露事件，无论是阿里平台还是开发者，都应该对此反思：

1、建立合理的安全体系，无论发生什么事，这是每个企业最后的救命稻草。如果企业对代码泄露进行监测，或对企业对日志进行了及时处理分析，很有可能会很早发现泄露事件。

2、阿里云等大型企业要做好产品引导，考虑所有开发者的水平。一个好的产品对于核心功能应该做到清晰的提醒和引导，而不是引发了这场争论。在这里，我们看到了云效平台的及时更新。

3、我们应该呼吁平台，在重大事件时及时通知和披露受影响的企业，让其尽量减少 影响。

毕竟在一个安全事件发生后，每个人都难以幸免。