GitHub 是開發人員作業流程中不可或缺的一部分，無論你去哪個企業或開發團隊，GitHub 都以某種形式存在，它被超過8300萬開發人員，400萬個組織和托管超過2億個存盤庫使用，GitHub 是世界上最大的源代碼托管服務平臺，
?
GitHub 的使用便利與強大支持鞏固了其在市場中的主導地位，GitHub 用戶群體包羅萬象，從業余小白到專業人士，從個人用戶到大型企業組織，都在使用 GitHub，
?
?
使用 GitHub 就無需考慮安全嗎？
GitHub 提供了許多工具和存盤庫設定防止資料泄露，但產生安全問題的根本原因往往在于疏于監管和安全知識匱乏，根據2019年發布的一項研究，在對公共 GitHub 存盤庫進行全面掃描后，該平臺上共發現了超過57萬個敏感資料實體，例如 API 密鑰，私有密鑰，OAuth ID，AWS 訪問密鑰 ID 和各種訪問 token，這些暴露的主要風險包括但不限于經濟損失、隱私泄露、資料完整性受損以及不同程度的濫用，為提高代碼倉庫的穩健性，和幫助開發團隊實施安全優先，我們將一同探討 GitHub 安全實踐，
?
?
為什么需要加強 GitHub 安全實踐？
安全是所有軟體開發團隊都知道且需要落實的事情，但往往被放在了最后一步，而草率的做法和例行程式會降低基礎架構和資料完整性的成本，GitHub 的市場地位、社區支持和普及率遠超其他競爭對手，GitHub 也順理成章地成為代碼版本控制和應用開發流程的最強參照，但根據北卡羅來納州立大學的一項研究，對超過一百萬個 GitHub 帳戶進行為期六個月的連續掃描顯示，包含用戶名、密碼、API 令牌、資料庫快照、加密密鑰和組態檔的文本字串，是可以通過 GitHub 公開訪問的，其中包括超過 21萬 個 Google API 密鑰、超過 26000 個 AWS 訪問密鑰，以及總計超過 28000 個社交媒體訪問 token，
?
更令人擔憂的是，GitHub 上有542個 Stripe Standard API 密鑰公開可用，這些資訊足以讓惡意攻擊者直接訪問具有真實客戶詳細資訊的帳戶，一旦形成攻擊，將對企業的經濟、名譽、資料完整性造成毀滅性打擊，
?
GitHub 最佳安全實踐
1. 切勿在 GitHub 上存盤憑據和敏感資料
GitHub 的目的是托管代碼存盤庫，除了在帳戶上設定的權限之外，沒有其他安全方法可以確保您的密鑰、私鑰和敏感資料保留在受控且受保護的環境中，
?
Git code commit 保存了已添加和洗掉內容的歷史記錄，從而使敏感資料永久保留在分支上，當分支合并和 Fork 時，潛在的資料或基礎架構安全風險可能會呈指數級增長，降低此風險的最簡單方法是，在提交到分支之前不要在代碼中存盤憑據和敏感資料，可以在 CI/CD 流水線中使用 git-secreits 等工具，另一個方法是使用機密和身份管理工具，如 Vault 和 Keycloak，
?
2. 禁用 Fork
分叉（fork）是一種 git 技術，它允許開發人員在不涉及原始代碼的情況下創建代碼倉庫的副本，雖然 fork 非常適合實驗和沙箱，但它也可能導致無法跟蹤敏感資料和私有憑據的最終位置，代碼倉庫最初可能是私有的，但 fork 可以快速將所有內容暴露到公共空間中，風險隨著每次分叉的發生呈指數級增加，通過暴露的敏感資料創建樹狀的安全漏洞鏈，為了防止這種情況發生，請禁用 Fork 存盤庫以幫助降低敏感資料進入代碼的風險，
?
3. 禁用可見性更改
有時開發人員擁有的權限和權限比其角色范圍所需的權限更多，對于沒有安全概念的開發人員來說，很容易不小心更改代碼庫的可見性，如果代碼存盤庫中存在敏感資料，有權訪問此更改可見性功能的人員越多，則潛在的風險就越高，要防止此類情況，可以將更改存盤庫可見性的功能設定為僅對組織所有者開放，或允許管理員特權成員使用權限，
?
4. 驗證 GitHub 應用程式
現在的開發團隊有時由外部和第三方團隊組成，因此驗證 GitHub 應用程式涉及跟蹤第三方開發人員及其可訪問性級別，這也意味著，一旦他們離開專案，或者不再處理代碼，就需要撤銷他們的訪問權限，不同程度的可訪問性也應與他們在專案中的作用和參與程度掛鉤，比如，代碼審核只需要提取代碼的能力，而不需要創建提交，只有在具有相應權限的人進行一系列檢查和代碼驗證之后，才應進行拉取和合并請求，
?
5. 執行雙重認證
雙重身份驗證（2FA）現在是帳戶安全的行業標準，它也應當成為組織的標準安全要求，來防止通過不安全的帳戶泄漏代碼，2FA 在登錄 GitHub 時增加了一層額外的安全保護，并且可以通過組織的設定在組織級別強制執行，
?
當保存設定后，系統可能會提示有關未激活 2FA 的個人詳細資訊，這些資訊將從組織中洗掉，并且只有在其帳戶上實施 2FA 后才能重新添加，可以在組織的審核日志中查看已洗掉的成員，
?
6. 實行單節點登陸（僅限 GitHub Enterprise）
SAML 單點登錄 （Single Sign-On, SSO）是一項僅適用于 GitHub Enterprise 的功能，借助此功能，GitHub 上的組織可以通過顯示授予對特定資源（如單個代碼倉庫、拉取請求和引發的問題）的訪問權限來控制可訪問性，這允許組織對代碼推送、拉取和審閱程序的不同部分的可訪問性進行分段，SAML SSO 還允許企業設定已批準的身份提供商，這意味著，企業可以限制用戶僅使用組織的帳戶登錄，而不是使用個人 GitHub 帳戶，這能夠有效緩解在向 GitHub 帳戶授予可訪問性時可能發生的潛在安全風險，
?
7. 限制訪問允許的 IP 地址
對于大型企業而言，跟蹤訪問用戶既困難又耗時，防止不必要的訪問的方法是限制通過IP地址的訪問，這意味著只有內部部署的成員或有權訪問公司維護的靜態 IP 遠程網路的成員才能進入企業的代碼存盤庫和相關代碼作業，要限制、管理和將 IP 地址列入白名單，在這里可以以 CIDR 表示法配置特定 IP 地址或范圍的串列，
?
8. 嚴格管理外部參與者權限
企業可能通過外包來加快專案的進展，或者引入外部專業知識來幫助填補團隊空白，外部成員的參與越多，相應的安全風險就越高，通過嚴格管理外部協作者和參與者，企業可以減少冗余用戶數量及其對代碼存盤庫的可訪問性，管理外部協作者的一種方法是將訪問權限和權限授予權限集中給管理員，這樣做還可以降低由于 GitHub 的長期訪問成本，
?
9. 及時撤銷權限
一個好的安全策略，需要考慮到團隊成員離開企業或專案時，對應的權限進行怎樣的修改和調整，這包括撤銷不同型別帳戶的可訪問性的時間，有時團隊成員可能仍需要訪問代碼，但不需要參與，因此撤銷更改權限或將其切換為維護者角色可能更適合，此方法遵循最小特權原則，即授予執行特定任務所需的權限，這樣做將確保每個有權訪問代碼的人都只在其權限范圍內作業，
?
10. 要求提交簽名
提交簽名是對代碼合并進行加密簽名以進行驗證和可跟蹤性的程序，這對于代碼審核跟蹤非常重要，因為惡意攻擊者偽裝成其他人并不難，只需在 git 配置中更改其用戶名和電子郵件地址并推送剝削性代碼合并，可以將 Git 設定為通過 GPG（GNU Privacy Guard）對提交進行簽名，并在 git 配置中使用私有密鑰配置提交，完成此操作后，您可以將 GPG key 添加到 GitHub，在提交時，提交旁邊會顯示一個“已驗證”標志，
?
11. 執行提交前代碼審查
強制執行代碼審查可以防止惡意代碼正式合并到分支中，代碼審查也是檢測代碼例外的良好做法，能夠幫助企業避免導致未來的漏洞和長期的安全風險問題，GitHub 有一個拉取請求工具，允許授權的團隊成員在合并到基本分支之前討論和查看潛在的更改，發出拉取請求時，可以將作業負責人附加到拉取請求，來通知他們查看待處理的審核，
?
12. 添加 security.md 檔案
security.md 檔案是存盤庫的安全策略，此檔案的目的是正式記錄與安全相關的流程和程式，包括漏洞報告、機密性要求、加密標準、令牌可訪問性、電子郵件地址的使用、HTTPS 要求、云的使用、CDN、備份、身份驗證要求的程序以及資料完整性維護程序， security.md 檔案可以作為開發人員的寶貴指南，
?
13. 輪換 SSH 密鑰和個人訪問令牌
SSH (Secure Shell) 密鑰輪換可用作定期清除可能泄露的訪問密鑰，最好在安全要求策略中對所有 SSH 密鑰和個人訪問令牌設定到期日期，需要注意，雖然可以通過 GitHub 的 API 自動進行 SSH 密鑰輪換，但更改個人訪問令牌是手動程序，只能由用戶完成，要在 GitHub 上手動洗掉 SSH 密鑰，在 “SSH and GPG keys” 下，可以找到當前所有訪問密鑰的串列，
?
14. 審核上傳到 GitHub 的所有代碼
在應用程式構建程序中添加外部代碼存盤庫很容易，除此之外，企業也會匯入以往開發的軟體中的舊代碼，匯入舊代碼的問題是其安全性無法保障，審核上傳到 GitHub 的所有代碼的要求可能非常耗時，但有利于應用程式和軟體體系結構完整性的長期運行狀況，
?
15. 查看 Github 審核日志中是否存在可疑活動
GitHub 有審核日志工具，可讓企業的管理員快速查看團隊其他成員執行的操作，誰做了什么的詳細資訊可以幫助標記可疑活動，并根據用戶的操作、操作的基于國家/地區的位置以及發生的日期和時間創建快速跟蹤組態檔，這三條資訊可以幫助管理員檢測例外并快速查明其來源，
?
16. 為易受攻擊的依賴關系啟用警報
隨著軟體專案規模的增長，依賴關系也變得更加錯綜復雜，而易受攻擊的依賴項（尤其是組織外部的第三方依賴項）的風險最大，因為它們的狀態以及對包或模塊的更新方式缺乏控制，對于小型專案跟蹤難度可控，但隨著專案變得越來越大，這些依賴項很容易丟失，GitHub 具有檢測公共代碼倉庫中易受攻擊的依賴項的功能，可以通過組織設定中的 “Security & analysis” 選項來啟用警報，
?
17. 在預提交時采用自動密鑰掃描
在許多人的印象里，如果源代碼是私有的，那么硬編碼憑據也應該保持安全，但是私有倉庫不提供相同級別的保護和加密的保管庫，也不提供對可訪問性輪換的相同程度的控制，復制和分發源代碼也不難，在 CI/CD 流水線中，速度是傳輸代碼的關鍵，這可能會導致意外提交敏感資料，自動機密掃描可以降低此類憑據意外暴露的風險，
?
18. 清除 GitHub 歷史記錄
GitHub 保存了每個已提交更改的日志，但是，如果敏感資料進入代碼存盤庫可能會帶來麻煩，清理 GitHub 歷史記錄的程序分為兩個步驟，首先使代碼中的任何令牌和密鑰失效，第二步是使用 git filter-branch 命令清除和重寫存盤庫的歷史記錄，進一步向上游更改提交很重要，因為它會影響所有已經完成的后續提交，最好在運行 GitHub 歷史記錄之前合并并關閉所有拉取請求，
?
19. 啟用 git 分支保護
分支誤刪或 git squash 合并可能會導致資料丟失，或者通過引入漏洞在代碼中造成資料泄露，分支保護是一項 GitHub 功能，允許保護特定的 git 分支免受未經授權的修改，這項功能的目的是為了確保協作者不會通過洗掉和強制推送等程序對分支進行永久更改，其他分支保護方法包括要求簽名提交以確保真實性、可追溯性和拉取請求以防止未經授權的代碼合并，
?
20. 將敏感檔案添加到.gitignore
隨著專案規模和復雜性的增長，本地機正常作業所需的敏感資料也在增加，這些檔案往往是唯一的，并且位于部署的服務器上，不對公眾進行公開，在開發模式和本地主機中，軟體開發需要訪問這些令牌和密鑰，.gitignore將確保您的敏感資料不會意外合并并推送到 GitHub 存盤庫，
?
21. 使用 “Secrets Vault” 服務
隨著專案的增長，加密密鑰、令牌、密碼、證書和 API 密鑰等的數量也會增加，與其將這些資訊放在 GitHub 上，不如使用“密碼保險庫”服務，Vault 是一種用于保護高度敏感資料的工具，同時提供統一的訪問介面，除此之外，Vault 還提供更嚴格的訪問控制和審核跟蹤，使管理員能夠輕松檢測漏洞和違規行為，
?
參考鏈接：
Where the world builds software
https://github.com/about
?
How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories
https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/499855.html
標籤：其他
上一篇：水澤-資訊收集自動化工具安裝
下一篇：內網滲透學習（一）內網入門基礎