GitHub 中的 DevSecOps

Azure Active Directory
監視器
原則
Azure 資訊安全中心

從開發的第一個步驟開始,DevSecOps 會遵循安全性最佳作法。 DevSecOps 會使用 左移 策略來重新導向安全性焦點。 它不會在結束時指向審核,而是從一開始就轉移到開發。 除了產生穩固的程式碼,這種 失敗的快速 方法可協助您及早解決問題,而這些問題很容易修正。

透過許多安全性功能,GitHub 提供的工具可支援 DevSecOps 工作流程的每個部分:

  • 以瀏覽器為基礎的 Ide,內含內建的安全性延伸模組。
  • 持續監視資訊安全摘要報告的代理程式,並取代易受攻擊和過期的相依性。
  • 掃描原始程式碼是否有弱點的搜尋功能。
  • 以動作為基礎的工作流程,可將開發、測試和部署的每個步驟自動化。
  • 提供一種方式來私下討論和解決安全性威脅,然後發佈資訊的空間。

這些功能結合了 Azure 的監視和評估能力,可提供建立安全雲端解決方案的卓越服務。

潛在使用案例

GitHub DevSecOps 安裝涵蓋許多安全性案例。 可能的情況包括下列情況:

  • 想要利用預先設定的環境來提供安全性功能的開發人員。
  • 系統管理員可以隨時掌握最新、優先的安全性報告,以及受影響程式碼和建議修正的詳細資料。
  • 簡化的組織,需要系統在程式碼中留下秘密時,自動取得新的不安全裝置。
  • 當有較新或更安全的外部套件版本可供使用時,可能會受益于自動升級的開發小組。

架構

此架構圖表強調在 GitHub DevSecOps 環境中,于各種 GitHub 和 Azure 元件中執行的安全性檢查。

顯示在 GitHub DevSecOps 環境中執行之安全性檢查的架構圖表。 Azure AD 驗證開發人員之後,Codespaces 執行安全性掃描。 GitHub Actions 接著測試安全性和加密敏感性資料。 在生產環境中,Azure 原則、Azure 資訊安全中心和 Azure 監視器評估部署的軟體是否有風險。

下載此架構的 svg。

  1. 當開發人員存取 GitHub 資源時,GitHub 會將其重新導向至 SAML 驗證 Azure Active Directory (Azure AD) 。 在單一登入 (SSO) 程式中, Microsoft Authenticator 應用程式 接著會使用 FIDO2 增強式驗證。 無密碼 FIDO2 安全性金鑰 會與最新的 快速身分識別一致 (FIDO) 聯盟 規格。
  2. 開發人員開始處理 Codespaces 中的工作。 這些預先建立的開發環境會組織成容器,提供正確設定的 Ide,具備必要的安全性掃描延伸模組。
  3. 當開發人員認可新程式碼時,GitHub Actions 會自動掃描程式碼,以快速找出弱點和程式碼錯誤。
  4. 提取要求 (Pr) 透過 GitHub Actions 觸發程式碼組建和自動化測試。 GitHub 會在待用時加密秘密和認證,並在記錄中混淆這些專案。
  5. GitHub Actions 在對其他雲端資源(例如服務端點)進行變更時,將組建成品部署至 Azure App Service。
  6. Azure 原則會評估部署中的 Azure 資源。 然後,已定義的原則可能會拒絕發行、修改雲端資源,或在活動記錄中建立警告事件。
  7. Azure 資訊安全中心會識別以已部署專案中執行之應用程式為目標的攻擊。
  8. Azure 監視器持續追蹤並評估應用程式行為。 當威脅具體化時,此服務會傳送警示以開始將程式碼回復至先前的認可。

元件

  • Azure AD 是多租使用者雲端式身分識別服務,可控制對 Azure 和其他雲端應用程式(如 Microsoft 365 和 GitHub)的存取。
  • GitHub 提供一個程式碼裝載平臺,可讓開發人員用來共同作業開放原始碼和 內部來源 專案。
  • Codespaces 是線上開發環境。 這項工具是由 GitHub 託管並由 Visual Studio Code提供,可在雲端提供完整的開發解決方案。
  • GitHub 安全性 的運作方式是以許多方式消除威脅。 代理程式和服務會識別存放庫和相依套件中的弱點。 它們也會將相依性升級為最新的安全版本。
  • GitHub Actions 是自訂工作流程,可在存放庫中直接提供持續整合 (CI) 和持續部署 (CD) 功能。 稱為「 操作器」的電腦會裝載這些 CI/CD 工作。
  • App Service 提供建立、部署和調整 web 應用程式的架構。 此平臺提供內建的基礎結構維護、安全性修補和調整。
  • Azure 原則 可協助小組透過可針對雲端資源強制執行規則的原則定義,來管理和防止 IT 問題。 比方說,如果您的專案即將部署具有無法辨識 SKU 的虛擬機器,Azure 原則會對問題發出警示,並停止部署。
  • Azure 資訊安全中心 跨混合式雲端工作負載提供統一的安全性管理和先進的威脅防護。
  • Azure 監視器 會收集並分析應用程式遙測,例如效能計量和活動記錄。 當此服務識別不規則的條件時,它會對應用程式和人員發出警示。

安全性

GitHub 安全性 提供多個功能來解決安全性風險:

  • 程式代碼掃描會檢查程式碼是否有已知的弱點和程式碼錯誤。 例如,如果開發人員離開程式碼中公開的資料庫連接字串,此功能就會探索秘密。 在使用資料庫確認其有效性之後,GitHub 會開始取得不合法字串的進程。 這些檢查會使用 CodeQL,這個程式碼分析平臺會將程式碼視為資料,以改善傳統分析器。 掃描會在排定的時間或發生特定事件(例如認可或推播)之後自動執行。

  • GitHub Dependabot 會檢查是否有過期或易受攻擊的套件和應用程式。 此自動化代理程式會更新軟體,以較新的安全版本取代過期或不安全的相依性。 比方說,如果您的專案使用開放原始碼程式庫,Dependabot 會檢查該程式庫。 假設程式庫不會加密其儲存在資料庫中的敏感性純文字。 在此情況下,Dependabot 會建立 PR,以將程式庫升級為加密資料的版本。

  • 弱點管理 會識別和更新程式碼中的已知弱點,以及程式碼所使用的軟體套件。 每當發生下列事件時,它就會執行檢查:

    • 當專案從 .NET 切換至 .NET Core) 時,存放庫的相依性會變更 (例如。

    • WhiteSource會顯示通知。 此協力廠商服務會藉由持續掃描開放原始碼存放庫來追蹤弱點。

    • 新的弱點進入 GitHub 諮詢資料庫。 此資料庫中的專案源自下列來源:

當 GitHub 識別弱點時,它會採取下圖所示的步驟。

說明如何識別弱點觸發之事件鏈的架構圖表,包括警示、升級和部署。

說明 GitHub DevSecOps 執行中的一連串事件的架構圖表。 在一開始,GitHub 會識別弱點並傳送電子郵件警示。 Dependabot 接著會建立分支、更新弱點來源,以及建立 PR。 分支合併。 在最後一個步驟中,GitHub Actions 部署新的應用程式。

下載此圖表的 svg

  1. GitHub 會將電子郵件警示傳送給組織擁有者和儲存機制系統管理員。
  2. GitHub Dependabot (DevOps bot 代理程式)會自動完成下列三項工作:
    1. 在存放庫中建立新的分支。
    2. 將必要的相依性升級為消除弱點所需的最小可能安全版本。
    3. 使用已升級的相依性建立 PR。
  3. 當 PR 獲得核准時,新的分支會與基底分支合併。
  4. 合併的分支會在 GitHub Actions 中觸發 CI/CD 工作。
  5. GitHub Actions 將新的應用程式版本部署至測試或預備環境。

考量

若要讓 GitHub DevSecOps 解決方案與 Azure Well-Architected Framework的原則保持一致,請在決定如何執行此模式時,考慮下列幾點。

成本最佳化

  • GitHub 會向客戶收取 GitHub Actions 分鐘的費用。 此外,裝載動作作業的作業系統選擇會影響每分鐘的耗用量率和每分鐘成本。 可能的話,請選擇 Linux 來裝載動作。 請參閱 GitHub 動作的計費
  • 嚴格排程的專案經理可能會擔心新增安全性措施將會延遲開發。 使用下列指導方針來節省時間,以進行相反的體驗:
    • 向左移位測試,更接近來源。 因此,小組會產生較少的錯誤。
    • 在程式設計期間解決問題,而不是在生產環境中的程式列下解決。 然後,開發人員不需要重新整理其程式碼的知識。

卓越營運

  • 在使用弱點管理功能的環境中執行自動化測試和維護,因為這些功能會代表您變更程式碼及其相依性。 自動化測試會識別這些變更所造成的任何問題。

  • 利用 Azure 原則功能。 除了拒絕部署和記錄合規性問題之外,這些原則也可以修改資源,使其符合規範,即使它們不是以這種方式部署也一樣。 例如,如果您嘗試在 Azure 中部署使用 HTTP 的儲存體帳戶,Azure 原則會偵測到此情況。 原則接著可以自動變更部署,並強制儲存體帳戶使用 HTTPS。

  • Azure Resource Manager 會使用 JSON 範本來描述與部署相關的資源。 小組也可以使用 DevOps 工具(例如版本控制、程式碼共同作業和 CI/CD 工作流程)來管理這些範本檔。

  • DevSecOps 的其中一個問題是,程式碼掃描可能產生有雜訊的結果,並以誤報表示,並導致下列類型的問題:

    • 開發人員會浪費時間來調查不存在的問題。
    • 解決安全性問題會中斷工作流程。
    • 因為不准確,所以開發人員忽略了安全性工具的信任,而忽略了結果。

    將安全性整合到軟體生命週期,以克服這些障礙:

    • 採用 Codespaces 這類工具,將掃描檢查內嵌在 Ide 中,這表示開發人員在熟悉的環境中使用這些工具。
    • 讓安全性檢查成為程式碼審核的一般部分,而不是事後進行。
    • 讓開發人員負責高精確度的掃描,但將嘈雜檢查留給安全性團隊。

效能效率

針對長時間執行或複雜的動作,請為 CI/CD 作業裝載您自己的執行程式。 然後,您可以選擇具有強大處理功能和海量儲存體的電腦。 請參閱 關於自我裝載的主機

可靠性

  • 如果您使用 GitHub Enterprise Server 所提供之 GitHub.com 的內部部署,請使用 高可用性容錯移轉 設定來提高復原能力。
  • 如果您選擇自行裝載的動作執行器,請考慮將它們分散到不同的位置。

安全性

  • 不建議針對公用存放庫使用自我裝載的動作執行程式。 惡意使用者可以加入您的存放庫,並建立可在您網路中的電腦上執行 unsafe 程式碼的 PR。 GitHub 裝載的主機會移除此風險。
  • 使用 CodeQL 分析引擎掃描您的程式碼。 CodeQL 可以探索潛在的弱點和程式碼錯誤。 它可依排程和事件發生時(例如認可或 PR 建立)來執行。 請參閱 關於程式碼掃描
  • 請務必 設定 Dependabot 安全性更新,這會從專案中移除已知的威脅。
  • 您可以新增 github 協力廠商程式碼掃描工具 ,以 (SARIF) 檔產生靜態分析結果交換格式,以增強 github 的程式碼掃描功能。 GitHub 接著會在這些工具識別潛在的安全性問題時建立警示。

後續步驟