什么是代碼加密？基于云效 Codeup的代碼倉庫加密是如何實作的？在互聯網快速發展的時代，代碼是企業最核心的資產，代碼安全也是首當其沖；為了保護企業代碼安全，各公司使出的手段也是五花八門，但未必安全，而云端加密代碼服務是阿里云 云效團隊的自研產品，是目前國內率先支持代碼加密的托管服務，能夠有效的阻斷代碼對運維人員的可見性，從而消除用戶上云的顧慮， 本篇文章為大家揭秘業界創新的代碼倉庫加密技術背后的知識，
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，10萬企業都在用的代碼管理平臺，能夠全方位保護企業代碼資產，幫助企業實作安全、穩定、高效的代碼托管和研發管理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/304218.html
標籤：其他
上一篇：Jenkins持續集成與部署