当前位置:主页 > 查看内容

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

发布时间:2021-07-13 00:00| 位朋友查看

简介:01 /?什么是代码加密 云端加密代码服务是云效团队的自研产品 是目前国内率先支持代码加密的托管服务 也是目前世界范围内率先基于原生Git实现加密方案的代码托管服务。 通过在云端对托管在云效Codeup的代码库进行落盘加密 可以有效避免数据拥有者之外的人接触……

image.png


01 /?什么是代码加密


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


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

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

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


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


image.png


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


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


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


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


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

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

image.png


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


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


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


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

明文存储引发的信任问题

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


image.png


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


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

04 /?代码加密技术揭秘

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

1.密钥管理

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


2.密钥使用

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


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


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

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

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


image.png


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


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


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

本地Git代码加密演示

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

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

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


image.png


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


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


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


image.png


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

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

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

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

image.png



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


加入我们

如果你是一个懂代码 爱 Git 有技术梦想的工程师 并想要和我们一起打造世界 NO.1 的代码服务和产品 请联系我吧 C/C /Golang/Java 我们都要

( ′? )人(′? )

If not now, when? If not me, who?

简历投递邮箱 hanxin.hx alibaba-inc.com


本文转自网络,原文链接:https://developer.aliyun.com/article/785256
本站部分内容转载于网络,版权归原作者所有,转载之目的在于传播更多优秀技术内容,如有侵权请联系QQ/微信:153890879删除,谢谢!

推荐图文

  • 周排行
  • 月排行
  • 总排行

随机推荐