过去几天，关于阿里云代码仓库权限设置问题，导致多个大型企业信息与数据外泄的消息，引起了开发者社区的不少关注与讨论。事情的原委已有很多新闻网站发表，如 InfoQ 新闻: 一个“Internal”牵扯出的代码泄露，阿里云独家回应，这里不再赘述。我想讨论的是该事件的技术细节以及我个人的看法。

GitLab：不合理的项目设置

我自己并未使用阿里云效平台。从各方的评论来看，该平台应该是在 Gitlab 社区版 基础上修改而来的，因而继承了 Gitlab 的许多特性，包括项目初始创建时的权限设置，也就是引发这次风波的 Internal 选项：

图中可见，Gitlab 确实提供了 Internal 选项，其说明为“所有登录用户均可见”。当然，默认选择还是 Private。而其他厂商包括 Github 在内提供的只有 Public/Private。Gitlab 之所以这样设计，可能是以公司内部托管源码这种应用作为典型场景，这时面向公司内部公开是可以理解的。但对以源码托管作为服务的公有云提供商，这样的设计就有问题了。从用户角度理解，所谓 Internal 一般会理解为对公司内部公开，而对云平台上的所有用户完全放开————包括和自己毫无关联的其他公司，明显是不合适的，这是把用户视角和平台视角混为一谈了。不合理的设计应该说是 GitLab 的问题。

从网络资料来看，此问题在两年前已经有人发现并提出过，参见 Issue: Internal Projects (Public or Private)。对此 GitLab 官方的反应是，提出了一些改进建议，但并未明确表明态度。仔细研究可发现，项目可见性如果设为 Internal，后面还是可以在设置中改成仅内部成员可见的，如下：

然而这个选项隐藏比较深，且 GitLab 本身界面也较为复杂，如果不仔细寻找的话，一般恐怕很难知道这个设置。同时，我也查找了一下文档，虽然有所说明，但太过简略，也没有针对性的提醒，在一大堆文字中很难注意到。

在此之前，我也在 GitLab 上存放了一些项目，包括 Public/Private 类型，但并未特别注意 Internal 类型。今天我特地用两个账号尝试了一下，发现按照默认设置，在 GitLab 网站上创建的 Internal 项目的确能被其他登录用户看到，除非手工修改设置之后才会隐藏。

总之，我个人以为 GitLab 作为公有云平台的确是存在设计问题的。合理的选择，要么像 Github 那样只允许 Public/Private 两个类型，要么 Internal 默认只允许组织内部访问。目前这样的设计对于多租户类型的平台明显不合理，因而在此事件上，GitLab 应该负有一定的责任。

阿里云：缺乏安全意识和用户责任

从目前网友提供的资料来看，阿里云效平台是基于 GitLab 社区版，可能自己也未发现这个问题的存在。官方声明中提到的中英文我反倒认为不太重要，因为合格的开发者应该有基本的英文认知水平。但这并不能撇清阿里自身的责任。GitLab 虽然也有问题，但作为开源程序并无义务为其他公司商用过程中发生的结果承担责任，这和 Ant Design 开发者有意加入的代码不是同一个性质的问题。而阿里既然把别人的开源程序拿来商用，你作为商业平台的维护者就有义务将产品吃透，并向开发者尽到说明义务。

从结果看，阿里的做法是：

阿里云方面表示，2018 年 9 月底，阿里云曾增强对 Internal 权限的中文注解，并于近日发出全站通知提醒。同时，阿里云正在逐一通知之前将访问权限设为 Internal 的开发者用户，确保大家正确理解该访问权限的含义，并将继续评估、改进相关产品设计，让所有开发者有一个更安全、清晰的使用体验。

也就是说，5个月前他们已经知道了问题，但只是内部修改而未对用户进行任何提醒，直到这两天问题爆出才全站通告，那么早干什么去了？为什么当时没有意识到这是一个严重的安全问题？信息泄露是最终结果，这背后暴露出的安全意识缺失才是根本。这不能不让人对阿里云的可信性产生怀疑。是的，我们都知道阿里有很多牛X的工程师，但我们也明白一个基本的道理，那就是：

安全不仅仅是技术问题。再安全的技术配上没有安全意识的人，等于没有安全。

从这个角度讲，我认为阿里在该事件中应当承担主要责任。

开发人员：未仔细阅读界面说明

前面我批评了 GitLab 和阿里，那么在阿里云上托管代码的工程师是否就没有任何责任呢？也不尽然。

我很明白，像 GitLab 这么复杂的产品，绝大多数开发者不可能通读所有文档、全方位地了解各个方面以后才来部署；像阿里这样的云开发商有义务提供一个足够安全的默认值。但从前面的图我们也看到了，即便按照默认设置，对于 Internal 的含义也是有说明的：

The project can be accessed by any logged in user.

这不是什么复杂的语法，我相信有基本英语阅读能力的开发者应该有能力读懂这句话的含义，如果只有翻译成中文界面才能理解的话，那么这个开发者是否合格确实应该打一个问号。

不过话说回来，网上有一种观点是开发者阅读并点击了确认说明他们已经同意分享，再回头说有安全问题就是赖账。这个我觉得就有点泼脏水了，没有哪个脑袋正常的企业开发者会随便同意把公司内部代码拿出去分享给其他你根本不知道的企业的。这些开发者或许缺乏安全意识，或许英文不过关，但你要说他们是自己主动同意分享的，那是没有可能的事情。

结语

总之，本次事件中几方其实都有一定责任。事情既已发生，责怪谁已经没有意义，但希望从这次事件更加明白，安全问题是一个木桶，只要存在一个短板，那么上下游都难以幸免。我以前也谈过一个观点，就是：

哪怕是私有仓库，也不应该在里面存储任何私密信息，因为你难以保证分布式环境下每个操作环节都是安全的。

本次事件中的开发者显然没有注意这个问题。希望引以为戒吧。