簡(jiǎn)介： 原理與演示。

01 / 什么是代碼加密？

云端加密代碼服務(wù)是云效團(tuán)隊(duì)的自研產(chǎn)品，是目前國(guó)內(nèi)率先支持代碼加密的托管服務(wù)，也是目前世界范圍內(nèi)率先基于原生Git實(shí)現(xiàn)加密方案的代碼托管服務(wù)。

通過在云端對(duì)托管在云效Codeup的代碼庫(kù)進(jìn)行落盤加密，可以有效避免數(shù)據(jù)擁有者之外的人接觸到用戶的明文數(shù)據(jù)，避免數(shù)據(jù)在云端發(fā)生泄露。同時(shí)，代碼加密過程對(duì)用戶完全透明，用戶可以使用任意官方Git端（包括但不限于Git、JGit、libgit2等）來訪問Codeup上的代碼倉(cāng)庫(kù)。

02 / Linux社區(qū)重大安全性事件回顧

2011年8月底，用于維護(hù)和分發(fā)Linux操作系統(tǒng)的多臺(tái)服務(wù)器感染了惡意軟件，這些惡意軟件非常厲害，可以獲取root的訪問權(quán)限，修改其上的系統(tǒng)軟件以及登錄密碼。但社區(qū)的維護(hù)者稱，維護(hù)linux的源代碼，是未受到漏洞影響的。

這是為什么呢？因?yàn)樗麄兪褂昧薌it進(jìn)行代碼維護(hù)，對(duì)于linux內(nèi)核代碼將近40000個(gè)文件來說，每個(gè)文件都做了hash來確保唯一性，因此很難在不引起注意情況下，更改舊的版本。

雖然Git可以解決開源社區(qū)關(guān)心的源碼篡改問題，卻解決不了企業(yè)擔(dān)心的數(shù)據(jù)泄露問題。而對(duì)于企業(yè)級(jí)代碼托管來說，今天所面臨的問題不但有數(shù)據(jù)安全、還有可靠性及成本問題。

當(dāng)企業(yè)規(guī)模較小時(shí)，對(duì)可靠性要求也不高，一個(gè)自建的代碼托管服務(wù)似乎就能滿足需求。但隨著規(guī)模不斷擴(kuò)大，代碼量不斷增加，可能需要更好的服務(wù)器配置，才能滿足多人協(xié)作的需求，甚至還需要投入專人維護(hù)來保證可靠性，這時(shí)就不得不思考成本的問題。

而云代碼托管服務(wù)，有著比自建代碼托管服務(wù)更高的可靠性及更低的成本，但相比自建代碼托管服務(wù)而言，由于其并不開放底層存儲(chǔ)的直接訪問，間接造成了用戶不可控的安全心理。

而代碼加密技術(shù)，正是通過將底層存儲(chǔ)的不可控變?yōu)榻耆煽?#xff0c;解決用戶代碼上云的顧慮。

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

在回答這個(gè)問題之前，讓我們一起來了解一些背景知識(shí)——Git的存儲(chǔ)結(jié)構(gòu)。

當(dāng)我們使用Git進(jìn)行代碼提交時(shí)，最先接觸到的便是提交記錄及分支。分支或者標(biāo)簽，可以統(tǒng)稱為引用。它們存儲(chǔ)在以路徑名作為引用名，以及對(duì)應(yīng)版本hash作為內(nèi)容的單個(gè)文件中。由于分支名通常與業(yè)務(wù)無關(guān)，所以可以認(rèn)為，其中不包含敏感數(shù)據(jù)的。

除了提交記錄commit之外，我們的代碼文件被存儲(chǔ)到blob對(duì)象，文件名及目錄等信息，存儲(chǔ)到tree對(duì)象，帶有額外的信息的標(biāo)簽被存儲(chǔ)到tag對(duì)象。

對(duì)象是Git中存儲(chǔ)數(shù)據(jù)的基本單元。通常情況下，對(duì)象存儲(chǔ)在以內(nèi)容hash值命名的單個(gè)文件中，我們稱之為松散對(duì)象。而通過執(zhí)行g(shù)c（也就是垃圾回收）之后，這些對(duì)象就會(huì)被打包到一起，生成一個(gè)打包文件packfile。代碼內(nèi)容及文件名，都存儲(chǔ)在blob及tree對(duì)象當(dāng)中，所以可以認(rèn)為，對(duì)象中是包含用戶的代碼內(nèi)容數(shù)據(jù)，也就是包含敏感數(shù)據(jù)的。

Git中的對(duì)象存儲(chǔ)，為了降低磁盤占用，會(huì)通過zlib進(jìn)行一次數(shù)據(jù)的壓縮。換句話說，只需通過解壓縮就可以獲取到數(shù)據(jù)內(nèi)容，所以可以認(rèn)為是明文存儲(chǔ)。也就是說，任意可以接觸到存儲(chǔ)的人，都可以查看存儲(chǔ)上的代碼數(shù)據(jù)。

明文存儲(chǔ)引發(fā)的信任問題

回答前面提出的問題，正是由于Git代碼非安全存儲(chǔ)的特點(diǎn)，自建的代碼托管服務(wù)，既要防范來自外部的一些攻擊風(fēng)險(xiǎn)，還要防范內(nèi)鬼，因?yàn)?strong>通常企業(yè)代碼數(shù)據(jù)泄露是從內(nèi)部發(fā)生。

而對(duì)于云代碼托管服務(wù)而言，我們可以借助阿里云安全，有效避免來自外部的黑客攻擊風(fēng)險(xiǎn)，那么，如何解決用戶對(duì)云代碼托管服務(wù)的信任問題，讓代碼對(duì)運(yùn)維人員不可見呢？

引入代碼加密技術(shù)，通過使用用戶的密鑰，加密云端托管的代碼數(shù)據(jù)，既增加了靜態(tài)存儲(chǔ)數(shù)據(jù)的安全性，又可以阻斷代碼對(duì)運(yùn)維人員的可見性，從而消除用戶上云的顧慮。

04 / 代碼加密技術(shù)揭秘

我把它分化三個(gè)問題去解決：

1.密鑰管理

使用一個(gè)安全合規(guī)的方式托管密鑰，密鑰存儲(chǔ)安全，才能保證加密安全。這個(gè)可以借助阿里云的密鑰管理服務(wù)KMS。

2.密鑰使用

Git是一個(gè)計(jì)算密集型的服務(wù)，如果直接使用密鑰管理服務(wù)的加解密能力，那么這個(gè)性能是難以接受的。

那這里還有什么方案呢？我們可以使用信封加密技術(shù)。顧名思義，我們可以使用數(shù)據(jù)密鑰，來對(duì)我們明文的代碼數(shù)據(jù)進(jìn)行加密，使用數(shù)字信封技術(shù)，保證密鑰保存、傳輸、使用過程的安全性。由于我們只存儲(chǔ)密文的數(shù)據(jù)密鑰及密文的代碼數(shù)據(jù)，必須通過用戶授權(quán)，才能完成運(yùn)行態(tài)的代碼數(shù)據(jù)解密。而處于靜態(tài)存儲(chǔ)的代碼數(shù)據(jù)，則無法被運(yùn)維人員獲取。

3.基于原生Git的加密實(shí)現(xiàn)

在原生Git的基礎(chǔ)上，通過增加代碼加密補(bǔ)丁，以在實(shí)現(xiàn)加密的能力同時(shí)，最大程度地獲取到原生Git帶來的各種優(yōu)勢(shì)。

原生Git是如圖所示的這樣一個(gè)自上而下的分層架構(gòu)，和我們常見的應(yīng)用架構(gòu)非常類似。

最上層是展現(xiàn)層，包含紛繁復(fù)雜的命令行入口，直接暴露給應(yīng)用服務(wù)進(jìn)行調(diào)用。

中間是業(yè)務(wù)處理層，從數(shù)據(jù)內(nèi)容角度，可以分為引用操作及對(duì)象操作。通過增加一個(gè)加解密的模塊，在內(nèi)存中進(jìn)行數(shù)據(jù)加密，將密文數(shù)據(jù)寫入磁盤，從而保證靜態(tài)數(shù)據(jù)的安全性。

為了獲取最高的性能，僅選擇與用戶代碼資產(chǎn)相關(guān)的對(duì)象數(shù)據(jù)進(jìn)行加密存儲(chǔ)，而對(duì)于引用列表及對(duì)象索引等數(shù)據(jù)，仍維持明文存儲(chǔ)。利用硬件加速，代碼加密的額外性能損耗控制在10%左右，在用戶使用過程中幾乎無感。

本地Git代碼加密演示

事先準(zhǔn)備好一個(gè)配置了代碼加密的的倉(cāng)庫(kù)。這個(gè)倉(cāng)庫(kù)是空的。

我們向里面添加一個(gè)文件。

通過hexdump -C查看這個(gè)文件的二進(jìn)制內(nèi)容，我們可以發(fā)現(xiàn)，它是以首字節(jié)78 01起始，這是一個(gè)典型的經(jīng)過zlib壓縮后的文件頭。

接下來，我們開啟加密的開關(guān)，通過git commit創(chuàng)建一個(gè)加密的提交記錄。再次查看保存的提交記錄二進(jìn)制內(nèi)容，發(fā)現(xiàn)這時(shí)創(chuàng)建的對(duì)象數(shù)據(jù)不再以78 01開始，而是以我們指定的加密標(biāo)記位開始。

注意，受時(shí)間關(guān)系，這里我們未進(jìn)行同一個(gè)對(duì)象非加密與非加密狀態(tài)下的直接對(duì)比，而是以文件頭是否變化來判斷加密與否。

在完成松散對(duì)象加密之后，我們可以通過git gc ，將松散對(duì)象轉(zhuǎn)換為打包對(duì)象，再看一下打包對(duì)象會(huì)發(fā)生什么樣的變化呢？由圖中我們可以發(fā)現(xiàn)，加密后的打包文件包頭版本中，不再是原有的00 00 00 02，而是增加了特定標(biāo)識(shí)的82 00 00 02，并且包頭也由原有的12字節(jié)擴(kuò)展為24字節(jié)，增加了12字節(jié)的NONCE用于增加安全性。

那么，當(dāng)我們移除密鑰配置之后，是否可以繼續(xù)訪問這個(gè)倉(cāng)庫(kù)呢？

當(dāng)我們移除密鑰之后，由于缺少密鑰，當(dāng)我們嘗試通過git show HEAD 查看當(dāng)前版本時(shí)，會(huì)得到一個(gè)錯(cuò)誤信息，提示未提供密鑰。

這個(gè)錯(cuò)誤是基于我們?cè)谠鶪it基礎(chǔ)上，定制化了代碼加密能力補(bǔ)丁，若是沒有這個(gè)補(bǔ)丁，會(huì)有什么樣的表現(xiàn)呢？

針對(duì)加密的打包文件packfile，會(huì)提示當(dāng)前版本較低，請(qǐng)升級(jí)Git版本；若針對(duì)松散對(duì)象，則提示文件頭不正確，因?yàn)椴皇且粋€(gè)zlib的壓縮頭。

歡迎大家使用云效代碼管理Codeup，全方位保護(hù)企業(yè)代碼資產(chǎn)，幫助企業(yè)實(shí)現(xiàn)安全、穩(wěn)定、高效的代碼托管和研發(fā)管理。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的揭秘！业界创新的代码仓库加密技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。