揭秘！业界创新的代码仓库加密技术

左手的ㄟ右手 2022-08-31 15:19 229阅读 0赞

**简介：** 原理与演示。

![image.png][]

## 01 / 什么是代码加密？ ##

云端加密代码服务是云效团队的自研产品，是目前**国内率先****支持代码加密**的托管服务，也是目前**世界范围内率先**基于原生Git实现加密方案的代码托管服务。

通过在云端对托管在云效Codeup的代码库进行落盘加密，可以有效避免数据拥有者之外的人接触到用户的明文数据，避免数据在云端发生泄露。同时，代码加密过程对用户完全透明，用户可以使用任意官方Git端（包括但不限于Git、JGit、libgit2等）来访问Codeup上的代码仓库。

## 02 / Linux社区重大安全性事件回顾 ##

2011年8月底，用于维护和分发Linux操作系统的多台服务器感染了恶意软件，这些恶意软件非常厉害，可以获取root的访问权限，修改其上的系统软件以及登录密码。但社区的维护者称，维护linux的源代码，是未受到漏洞影响的。

这是为什么呢？因为他们使用了Git进行代码维护，对于linux内核代码将近40000个文件来说，每个文件都做了hash来确保唯一性，因此很难在不引起注意情况下，更改旧的版本。

![image.png][image.png 1]

虽然Git可以解决开源社区关心的**源码篡改**问题，却解决不了企业担心的**数据泄露**问题。而对于企业级代码托管来说，今天所面临的问题不但有**数据安全**、还有**可靠性**及**成本问题**。

当企业规模较小时，对可靠性要求也不高，一个自建的代码托管服务似乎就能满足需求。但随着规模不断扩大，代码量不断增加，可能需要更好的服务器配置，才能满足多人协作的需求，甚至还需要投入专人维护来保证可靠性，这时就不得不思考成本的问题。

而云代码托管服务，有着比自建代码托管服务更高的可靠性及更低的成本，但相比自建代码托管服务而言，由于其并不开放底层存储的直接访问，间接造成了用户不可控的安全心理。

而代码加密技术，正是通过将底层存储的不可控变为近完全可控，解决用户代码上云的顾虑。

## 03 / 自建真的比上云更安全么？ ##

在回答这个问题之前，让我们一起来了解一些背景知识——Git的存储结构。

![image.png][image.png 2]

当我们使用Git进行代码提交时，最先接触到的便是提交记录及分支。分支或者标签，可以统称为引用。它们存储在以路径名作为引用名，以及对应版本hash作为内容的单个文件中。由于分支名通常与业务无关，所以可以认为，其中**不包含敏感数据**的。

除了提交记录commit之外，我们的代码文件被存储到blob对象，文件名及目录等信息，存储到tree对象，带有额外的信息的标签被存储到tag对象。

**对象是Git中存储数据的基本单元**。通常情况下，对象存储在以内容hash值命名的单个文件中，我们称之为松散对象。而通过执行gc（也就是垃圾回收）之后，这些对象就会被打包到一起，生成一个打包文件packfile。代码内容及文件名，都存储在blob及tree对象当中，所以可以认为，对象中是包含用户的代码内容数据，也就是**包含敏感数据**的。

Git中的对象存储，为了降低磁盘占用，会通过zlib进行一次数据的压缩。换句话说，只需通过解压缩就可以获取到数据内容，所以可以认为是明文存储。也就是说，任意可以接触到存储的人，都可以查看存储上的代码数据。

## **明文存储引发的信任问题** ##

回答前面提出的问题，正是由于Git代码非安全存储的特点，自建的代码托管服务，既要防范来自外部的一些攻击风险，还要防范内鬼，因为**通常企业代码数据泄露是从内部发生**。

![image.png][image.png 3]

而对于云代码托管服务而言，我们可以借助阿里云安全，有效避免来自外部的黑客攻击风险，那么，如何解决用户对云代码托管服务的信任问题，让代码对运维人员不可见呢？

**引入代码加密技术**，通过使用用户的密钥，加密云端托管的代码数据，既增加了静态存储数据的安全性，又可以**阻断代码对运维人员的可见性**，从而消除用户上云的顾虑。

## 04 / 代码加密技术揭秘 ##

我把它分化三个问题去解决：

1.密钥管理

使用一个安全合规的方式托管密钥，密钥存储安全，才能保证加密安全。这个可以借助阿里云的密钥管理服务KMS。

2.密钥使用

Git是一个计算密集型的服务，如果直接使用密钥管理服务的加解密能力，那么这个性能是难以接受的。

那这里还有什么方案呢？我们可以使用信封加密技术。顾名思义，我们可以使用数据密钥，来对我们明文的代码数据进行加密，使用数字信封技术，保证密钥保存、传输、使用过程的安全性。由于我们只存储密文的数据密钥及密文的代码数据，必须通过用户授权，才能完成运行态的代码数据解密。而处于静态存储的代码数据，则无法被运维人员获取。

3.基于原生Git的加密实现

在原生Git的基础上，通过增加代码加密补丁，以在实现加密的能力同时，最大程度地获取到原生Git带来的各种优势。

原生Git是如图所示的这样一个自上而下的分层架构，和我们常见的应用架构非常类似。

![image.png][image.png 4]

最上层是展现层，包含纷繁复杂的命令行入口，直接暴露给应用服务进行调用。

中间是业务处理层，从数据内容角度，可以分为引用操作及对象操作。通过增加一个加解密的模块，在内存中进行数据加密，将密文数据写入磁盘，从而保证静态数据的安全性。

为了获取最高的性能，仅选择与用户代码资产相关的对象数据进行加密存储，而对于引用列表及对象索引等数据，仍维持明文存储。利用硬件加速，代码加密的额外性能损耗控制在10%左右，在用户使用过程中几乎无感。

### **本地Git代码加密演示** ###

事先准备好一个配置了代码加密的的仓库。这个仓库是空的。

我们向里面添加一个文件。

通过`hexdump -C`查看这个文件的二进制内容，我们可以发现，它是以首字节`78 01`起始，这是一个典型的经过zlib压缩后的文件头。

![image.png][image.png 5]

接下来，我们开启加密的开关，通过`git commit`创建一个加密的提交记录。再次查看保存的提交记录二进制内容，发现这时创建的对象数据不再以`78 01`开始，而是以我们指定的加密标记位开始。

注意，受时间关系，这里我们未进行同一个对象非加密与非加密状态下的直接对比，而是**以文件头是否变化来判断加密与否**。

在完成松散对象加密之后，我们可以通过`git gc` ，将松散对象转换为打包对象，再看一下打包对象会发生什么样的变化呢？由图中我们可以发现，加密后的打包文件包头版本中，不再是原有的`00 00 00 02`，而是增加了特定标识的`82 00 00 02`，并且包头也由原有的12字节扩展为24字节，增加了12字节的NONCE用于增加安全性。

![image.png][image.png 6]

那么，当我们移除密钥配置之后，是否可以继续访问这个仓库呢？

当我们移除密钥之后，由于缺少密钥，当我们尝试通过`git show HEAD` 查看当前版本时，会得到一个错误信息，提示未提供密钥。

这个错误是基于我们在原生Git基础上，定制化了代码加密能力补丁，若是没有这个补丁，会有什么样的表现呢？

针对加密的打包文件packfile，会**提示当前版本较低**，请升级Git版本；若针对松散对象，则**提示文件头不正确**，因为不是一个zlib的压缩头。

![image.png][image.png 7]

欢迎大家使用云效代码管理Codeup，全方位保护企业代码资产，帮助企业实现安全、稳定、高效的代码托管和研发管理。

[原文链接][Link 1]

本文为阿里云原创内容，未经允许不得转载。

[image.png]: /images/20220829/ae47ac8dbe454e94a273766da9035640.png
[image.png 1]: /images/20220829/236029336600429ca8dc2681177139ae.png
[image.png 2]: /images/20220829/92533faf650d4d498a0299a0066f16c7.png
[image.png 3]: /images/20220829/3d9fe5d6c36e465ba1643a39920d7ba5.png
[image.png 4]: /images/20220829/d68df350cc8047018055abd3015ceab4.png
[image.png 5]: /images/20220829/328d41ca1f96415a9b710771de0c8353.png
[image.png 6]: /images/20220829/a6abe31670c948ba9672516b60f90924.png
[image.png 7]: /images/20220829/9c2939a38e054949a62a2e82ae645161.png
[Link 1]: http://click.aliyun.com/m/1000285454/