简介: 原理与演示。
01 / 什么是代码加密?
云端加密代码服务是云效团队的自研产品,是目前国内率先支持代码加密的托管服务,也是目前世界范围内率先基于原生Git实现加密方案的代码托管服务。
通过在云端对托管在云效Codeup的代码库进行落盘加密,可以有效避免数据拥有者之外的人接触到用户的明文数据,避免数据在云端发生泄露。同时,代码加密过程对用户完全透明,用户可以使用任意官方Git端(包括但不限于Git、JGit、libgit2等)来访问Codeup上的代码仓库。
02 / Linux社区重大安全性事件回顾
2011年8月底,用于维护和分发Linux操作系统的多台服务器感染了恶意软件,这些恶意软件非常厉害,可以获取root的访问权限,修改其上的系统软件以及登录密码。但社区的维护者称,维护linux的源代码,是未受到漏洞影响的。
这是为什么呢?因为他们使用了Git进行代码维护,对于linux内核代码将近40000个文件来说,每个文件都做了hash来确保唯一性,因此很难在不引起注意情况下,更改旧的版本。
虽然Git可以解决开源社区关心的源码篡改问题,却解决不了企业担心的数据泄露问题。而对于企业级代码托管来说,今天所面临的问题不但有数据安全、还有可靠性及成本问题。
当企业规模较小时,对可靠性要求也不高,一个自建的代码托管服务似乎就能满足需求。但随着规模不断扩大,代码量不断增加,可能需要更好的服务器配置,才能满足多人协作的需求,甚至还需要投入专人维护来保证可靠性,这时就不得不思考成本的问题。
而云代码托管服务,有着比自建代码托管服务更高的可靠性及更低的成本,但相比自建代码托管服务而言,由于其并不开放底层存储的直接访问,间接造成了用户不可控的安全心理。
而代码加密技术,正是通过将底层存储的不可控变为近完全可控,解决用户代码上云的顾虑。
03 / 自建真的比上云更安全么?
在回答这个问题之前,让我们一起来了解一些背景知识——Git的存储结构。
当我们使用Git进行代码提交时,最先接触到的便是提交记录及分支。分支或者标签,可以统称为引用。它们存储在以路径名作为引用名,以及对应版本hash作为内容的单个文件中。由于分支名通常与业务无关,所以可以认为,其中不包含敏感数据的。
除了提交记录commit之外,我们的代码文件被存储到blob对象,文件名及目录等信息,存储到tree对象,带有额外的信息的标签被存储到tag对象。
对象是Git中存储数据的基本单元。通常情况下,对象存储在以内容hash值命名的单个文件中,我们称之为松散对象。而通过执行gc(也就是垃圾回收)之后,这些对象就会被打包到一起,生成一个打包文件packfile。代码内容及文件名,都存储在blob及tree对象当中,所以可以认为,对象中是包含用户的代码内容数据,也就是包含敏感数据的。
Git中的对象存储,为了降低磁盘占用,会通过zlib进行一次数据的压缩。换句话说,只需通过解压缩就可以获取到数据内容,所以可以认为是明文存储。也就是说,任意可以接触到存储的人,都可以查看存储上的代码数据。
明文存储引发的信任问题
回答前面提出的问题,正是由于Git代码非安全存储的特点,自建的代码托管服务,既要防范来自外部的一些攻击风险,还要防范内鬼,因为通常企业代码数据泄露是从内部发生。
而对于云代码托管服务而言,我们可以借助阿里云安全,有效避免来自外部的黑客攻击风险,那么,如何解决用户对云代码托管服务的信任问题,让代码对运维人员不可见呢?
引入代码加密技术,通过使用用户的密钥,加密云端托管的代码数据,既增加了静态存储数据的安全性,又可以阻断代码对运维人员的可见性,从而消除用户上云的顾虑。
04 / 代码加密技术揭秘
我把它分化三个问题去解决:
1.密钥管理
使用一个安全合规的方式托管密钥,密钥存储安全,才能保证加密安全。这个可以借助阿里云的密钥管理服务KMS。
2.密钥使用
Git是一个计算密集型的服务,如果直接使用密钥管理服务的加解密能力,那么这个性能是难以接受的。
那这里还有什么方案呢?我们可以使用信封加密技术。顾名思义,我们可以使用数据密钥,来对我们明文的代码数据进行加密,使用数字信封技术,保证密钥保存、传输、使用过程的安全性。由于我们只存储密文的数据密钥及密文的代码数据,必须通过用户授权,才能完成运行态的代码数据解密。而处于静态存储的代码数据,则无法被运维人员获取。
3.基于原生Git的加密实现
在原生Git的基础上,通过增加代码加密补丁,以在实现加密的能力同时,最大程度地获取到原生Git带来的各种优势。
原生Git是如图所示的这样一个自上而下的分层架构,和我们常见的应用架构非常类似。
最上层是展现层,包含纷繁复杂的命令行入口,直接暴露给应用服务进行调用。
中间是业务处理层,从数据内容角度,可以分为引用操作及对象操作。通过增加一个加解密的模块,在内存中进行数据加密,将密文数据写入磁盘,从而保证静态数据的安全性。
为了获取最高的性能,仅选择与用户代码资产相关的对象数据进行加密存储,而对于引用列表及对象索引等数据,仍维持明文存储。利用硬件加速,代码加密的额外性能损耗控制在10%左右,在用户使用过程中几乎无感。
本地Git代码加密演示
事先准备好一个配置了代码加密的的仓库。这个仓库是空的。
我们向里面添加一个文件。
通过hexdump -C
查看这个文件的二进制内容,我们可以发现,它是以首字节78 01
起始,这是一个典型的经过zlib压缩后的文件头。
接下来,我们开启加密的开关,通过git commit
创建一个加密的提交记录。再次查看保存的提交记录二进制内容,发现这时创建的对象数据不再以78 01
开始,而是以我们指定的加密标记位开始。
注意,受时间关系,这里我们未进行同一个对象非加密与非加密状态下的直接对比,而是以文件头是否变化来判断加密与否。
在完成松散对象加密之后,我们可以通过git gc
,将松散对象转换为打包对象,再看一下打包对象会发生什么样的变化呢?由图中我们可以发现,加密后的打包文件包头版本中,不再是原有的00 00 00 02
,而是增加了特定标识的82 00 00 02
,并且包头也由原有的12字节扩展为24字节,增加了12字节的NONCE用于增加安全性。
那么,当我们移除密钥配置之后,是否可以继续访问这个仓库呢?
当我们移除密钥之后,由于缺少密钥,当我们尝试通过git show HEAD
查看当前版本时,会得到一个错误信息,提示未提供密钥。
这个错误是基于我们在原生Git基础上,定制化了代码加密能力补丁,若是没有这个补丁,会有什么样的表现呢?
针对加密的打包文件packfile,会提示当前版本较低,请升级Git版本;若针对松散对象,则提示文件头不正确,因为不是一个zlib的压缩头。
欢迎大家使用云效代码管理Codeup,全方位保护企业代码资产,帮助企业实现安全、稳定、高效的代码托管和研发管理。
原文链接
本文为阿里云原创内容,未经允许不得转载。