查詢並排除你儲存在 AWS 和 GitHub 中的資料裡的漏洞。

-- Alison Naylor,anderson Silva（作者）

如果你的日常工作是開發者、系統管理員、全棧工程師或者是網站可靠性工程師（SRE），工作內容包括使用 Git 從 GitHub 上推送、提交和拉取，並部署到亞馬遜 Web 服務上（AWS），安全性就是一個需要持續考慮的一個點。幸運的是，開源工具能幫助你的團隊避免犯常見錯誤，這些常見錯誤會導致你的組織損失數千美元。

本文介紹了四種開源工具，當你在 GitHub 和 AWS 上進行開發時，這些工具能幫助你提升專案的安全性。同樣的，本著開源的精神，我會與三位安全專家—— Travis McPeak ，奈飛高階雲安全工程師； Rich Monk ，紅帽首席高階資訊保安分析師；以及 Alison Naylor ，紅帽首席資訊保安分析師——共同為本文做出貢獻。

我們已經按場景對每個工具都做了區分，但是它們並不是相互排斥的。

1、使用 gitrob 發現敏感資料

你需要發現任何出現於你們團隊的 Git 倉庫中的敏感資訊，以便你能將其刪除。藉助專注於攻擊應用程式或者作業系統的工具以使用紅/藍隊模型，這樣可能會更有意義，在這個模型中，一個資訊保安團隊會劃分為兩塊，一個是攻擊團隊（又名紅隊），以及一個防守團隊（又名藍隊）。有一個紅隊來嘗試滲透你的系統和應用要遠遠好於等待一個攻擊者來實際攻擊你。你的紅隊可能會嘗試使用 Gitrob ，該工具可以克隆和爬取你的 Git 倉庫，以此來尋找憑證和敏感資訊。

2、使用 git-secrets 來避免合併敏感資料

雖然在你的 Git 倉庫裡發現並移除敏感資訊很重要，但在一開始就避免合併這些敏感資訊豈不是更好？即使錯誤地提交了敏感資訊，使用 git-secrets 可以避免你陷入公開的困境。這款工具可以幫助你設定鉤子，以此來掃描你的提交、提交資訊和合並資訊，尋找常見的敏感資訊模式。注意你選擇的模式要匹配你的團隊使用的憑證，比如 AWS 訪問金鑰和祕密金鑰。如果發現了一個匹配項，你的提交就會被拒絕，一個潛在的危機就此得到避免。

為你已有的倉庫設定 git-secrets 是很簡單的，而且你可以使用一個全域性設定來保護所有你以後要建立或克隆的倉庫。你同樣可以在公開你的倉庫之前，使用 git-secrets 來掃描它們（包括之前所有的歷史版本）。

3、使用 Key Conjurer 建立臨時憑證

有一點額外的保險來防止無意間公開了儲存的敏感資訊，這是很好的事，但我們還可以做得更好，就完全不儲存任何憑證。追蹤憑證，誰訪問了它，儲存到了哪裡，上次更新是什麼時候——太麻煩了。然而，以程式設計的方式生成的臨時憑證就可以避免大量的此類問題，從而巧妙地避開了在 Git 倉庫裡儲存敏感資訊這一問題。使用 Key Conjurer ，它就是為解決這一需求而被創建出來的。有關更多 Riot Games 為什麼建立 Key Conjurer，以及 Riot Games 如何開發的 Key Conjurer，請閱讀 Key Conjurer：我們最低許可權的策略 。

4、使用 Repokid 自動化地提供最小許可權

任何一個參加過基本安全課程的人都知道，設定最小許可權是基於角色的訪問控制的最佳實現。難過的是，離開校門，會發現手動運用最低許可權策略會變得如此艱難。一個應用的訪問需求會隨著時間的流逝而變化，開發人員又太忙了沒時間去手動削減他們的許可權。 Repokid 使用 AWS 提供提供的有關身份和訪問管理（IAM）的資料來自動化地調整訪問策略。Repokid 甚至可以在 AWS 中為超大型組織提供自動化地最小許可權設定。

工具而已，又不是大招

這些工具並不是什麼靈丹妙藥，它們只是工具！所以，在嘗試使用這些工具或其他的控制元件之前，請和你的組織裡一起工作的其他人確保你們已經理解了你的雲服務的使用情況和用法模式。

應該嚴肅對待你的雲服務和程式碼倉庫服務，並熟悉最佳實現的做法。下面的文章將幫助你做到這一點。

對於 AWS：

管理 AWS 訪問金鑰的最佳實現AWS 安全審計指南

對於 GitHub：

介紹一種新方法來讓你的程式碼保持安全GitHub 企業版最佳安全實現

同樣重要的一點是，和你的安全團隊保持聯絡；他們應該可以為你團隊的成功提供想法、建議和指南。永遠記住：安全是每個人的責任，而不僅僅是他們的。

via: https://opensource.com/article/19/9/open-source-cloud-security

作者： Alison Naylor , Anderson Silva 選題： lujun9972 譯者： hopefully2333 校對： wxy