共用方式為

保護開發生命周期的建議

  • 發行項

適用於此 Azure 架構完善的架構安全性檢查清單建議：

SE：02 使用強化、大部分自動化且可稽核的軟體供應鏈，維護安全的開發生命週期。 使用威脅模型化來納入安全設計，以防止安全性失敗的實作。

相關指南： 威脅分析

本指南說明 在開發週期中套用安全性最佳做法，強化程式代碼、開發環境和軟體供應鏈 的建議。 若要瞭解本指南，您應該具備DevSecOps的知識。

安全性週期的圖表。

DevSecOps 會藉由：

  • 自動化安全性測試和驗證。

  • 實作安全性管線之類的工具，以掃描程式代碼和基礎結構即程序代碼（IaC）是否有弱點。

工作負載的核心是實作商業規則的應用程式程序代碼。 開發程式代碼的程式必須 沒有安全性缺陷 ，以確保機密性、完整性和可用性。

它不足以使用身分識別和網路和其他量值的控件來保護基礎結構平面。 防止程式代碼或遭入侵的程式代碼區塊 不正確實作，以強化整體安全性狀態。 使用平面，也就是應用程式程序代碼，也必須強化。 將安全性整合到開發生命週期的程式基本上是強化程式。 與資源強化一樣，加強程式代碼開發也與內容無關。 重點是增強安全性，而不是應用程式的功能需求。 如需強化的相關信息，請參閱 強化資源的建議。

定義

詞彙 定義
安全性開發週期 (SDL) Microsoft提供的一組做法，可支援安全性保證和合規性需求。
軟體開發生命週期 （SDLC） 開發軟體系統的多階段系統程式。

關鍵設計策略

安全性措施應該在多個點整合至您現有的軟體開發生命週期 （SDLC），以確保：

  • 設計選擇不會導致安全性缺口。

  • 應用程式程式代碼和組態不會因為可惡意探索的實作和不正確的編碼做法而造成弱點。

  • 透過供應鏈取得的軟體不會帶來安全性威脅。

  • 應用程式程式代碼、組建和部署程式不會遭到竄改。

  • 透過事件揭示的弱點會降低。

  • 未使用的資產已正確解除委任。

  • 合規性需求不會遭到入侵或降低。

  • 稽核記錄是在開發人員環境中實作。

下列各節提供 SDLC 常見階段的安全性策略。

收集並記錄安全性需求

需求階段 的目標是收集和分析應用程式的功能和非功能需求 ，或應用程式的新功能。 這個階段很重要，因為它有助於建立專為應用程序目標量身打造的護欄。 在開發生命週期的每個階段，保護應用程式的數據和完整性應該是核心需求。

例如，請考慮需要支援重要使用者流程的應用程式，讓用戶能夠上傳和操作數據。 安全性設計選擇應涵蓋使用者與應用程式的互動保證，例如驗證和授權使用者身分識別、只允許對數據執行允許的動作，以及防止 SQL 插入。 同樣地，請涵蓋可用性、延展性和可維護性等非功能性需求。 安全性選擇應包括分割界限、防火牆輸入和輸出，以及其他跨領域安全性考慮。

所有這些決策都應該能正確定義應用程式的安全性狀態。 在已同意的規格 中記錄安全性需求，並將其反映在待辦專案中。 如果業務項目關係人未核准投資，它應該明確說明企業願意承擔的安全性投資和取捨和風險。 例如，您可能會記載需要在應用程式前面使用 Web 應用程式防火牆 （WAF），例如 Azure Front Door 或 Azure 應用程式閘道。 如果商務項目關係人尚未準備好接受執行 WAF 的額外成本，則必須接受應用層攻擊可能會導向至應用程式的風險。

安全性需求收集是此階段的重要部分。 如果沒有這項努力，設計和實作階段會以未陳述的選擇為基礎，這可能會導致安全性缺口。 您稍後可能需要變更實作，以容納成本高昂的安全性。

將安全性需求轉譯為技術需求

在設計階段， 安全性需求會轉換成技術需求。 在您的技術規格中，記錄所有設計決策，以避免在實作期間模棱兩可。 以下是一些一般工作：

定義系統架構的安全性維度

將架構與安全性控制件重疊。 例如，每個 分割策略在隔離界限上實際執行的控件、應用程式元件所需的身分識別類型，以及要使用的加密方法類型。 如需一些範例架構，請參閱身分識別和存取管理和網路文章的小節中的圖例。

評估平臺提供的能供性

請務必瞭解 您與雲端提供者之間的責任劃分。 例如，避免與 Azure 原生安全性控件重疊。 您將獲得更好的安全性涵蓋範圍，並能夠將開發資源重新配置至應用程式的需求。

例如，如果您的設計呼叫輸入上的 Web 應用程式防火牆，您可以將該責任卸除給負載平衡器，例如 應用程式閘道 或 Azure Front Door。 避免將功能複寫為應用程式中的自定義程式碼。

只選擇受信任的架構、連結庫和供應鏈軟體。 您的設計也應該指定安全版本控制。 應用程式相依性應來自受信任的合作物件。 第三方廠商應能夠符合您的安全性需求 ，並共用其負責任的披露計劃。 應立即報告任何安全性事件，以便採取必要的動作。 此外，您的組織可能會禁止某些連結庫。 例如，軟體可能會受到弱點保護，但仍因為授權限制而不允許。

為了確保本指南後面接著軟體的所有參與者， 請維護已核准和/或未經核准的架構、連結庫和廠商清單。 可能的話，請在開發管線中放置護欄以支援清單。 盡可能自動使用工具來掃描相依性是否有弱點。

判斷應用程式程式代碼應該實作的安全性設計模式。

模式可以支援安全性考慮，例如分割和隔離、強式授權、統一的應用程式安全性和新式通訊協定。 某些作業模式，例如隔離模式，可協助驗證及封鎖可能帶來安全性弱點的軟體使用。

如需詳細資訊，請參閱 支援安全性的雲端設計模式。

安全地儲存應用程式秘密

安全地實作使用應用程式秘密和應用程式所使用的預先共用密鑰。 認證和應用程式密碼不應該儲存在原始程式碼樹狀結構中。 使用 Azure 金鑰保存庫 之類的外部資源，以確保如果您的原始程式碼可供潛在攻擊者使用，則無法取得進一步的存取權。 一般而言，請尋找避免秘密的方法。 可能的話，使用受控識別是達成該目標的一種方式。 如需詳細資訊，請參閱 管理應用程式秘密的建議。

定義測試計劃

定義安全性需求的清楚測試案例。 評估您是否可以在 管線中自動執行這些測試。 如果您的小組有手動測試的程式，請包含這些測試的安全性需求。

注意

在此階段執行威脅模型化。 威脅模型可以確認設計選擇符合安全性需求，並公開您應該減輕的差距。 如果您的工作負載處理高度敏感數據，請投資可協助您進行威脅模型化的安全性專家。

在定義軟體架構和高階設計時，初始威脅模型化練習應該會在設計階段進行。 在該階段執行此動作可協助您找出潛在的安全性問題，再將其併入系統的結構。 不過，此練習不是一次性活動。 這是一個持續的過程，應該在整個軟體的演進過程中繼續。

如需詳細資訊，請參閱 威脅分析的建議。

保護開發和測試做法

在開發和測試階段，目標是 要防止程式代碼、組建和部署管線中的安全性缺陷 和竄改。

在安全程式代碼實務中訓練良好

開發小組應 具備安全編碼實務的正式和特製化訓練。 例如，Web 和 API 開發人員可能需要特定的訓練來防範跨網站腳本攻擊，而後端開發人員可以從深入訓練中獲益，以避免 SQL 插入式攻擊之類的資料庫層級攻擊。

開發人員必須先完成此訓練，才能取得生產原始程式碼的存取權。

您也應該執行內部對等程式代碼檢閱，以促進持續學習。

使用安全性測試工具

執行威脅模型化來評估應用程式架構的安全性。

使用 靜態應用程式安全性測試 （SAST） 分析程式代碼是否有弱點。 將此方法整合到開發人員環境中，以即時偵測弱點。

在運行時間期間使用動態應用程式安全性測試 （DAST）。 此工具鏈可以檢查安全性網域中的錯誤，並模擬一組攻擊來測試應用程式的安全性復原能力。 可能的話，請將此工具整合到您的組建管線中。

遵循業界標準，以確保程式碼撰寫做法的安全。 如需詳細資訊，請參閱本文的社群 資源 一節。

使用 linters 和程式代碼分析器來防止認證推送至原始程式碼存放庫。 例如，.NET 編譯程式平臺 （Roslyn） 分析器會檢查您的應用程式程序代碼。

在建置程式期間， 使用管線附加元件來攔截原始程式碼中的認證。 掃描所有相依性，例如第三方連結庫和架構元件，作為持續整合程式的一部分。 調查工具所標幟的易受攻擊元件。 將此工作與其他程式代碼掃描工作結合，以檢查程式代碼變換、測試結果和涵蓋範圍。

使用測試的組合。 如需一般安全性測試的相關信息，請參閱 安全性測試的建議。

撰寫足夠的程序代碼

當您減少程式代碼使用量時，也會降低安全性缺陷的機會。 重複使用已在使用中的程式代碼和連結庫，並已透過安全性驗證 ，而不是複製程序代碼。

利用 Azure 功能是防止不必要的程式碼的另一種方式。 其中一種方式是使用受控服務。 如需詳細資訊，請參閱 使用平臺即服務 （PaaS） 選項。

根據預設，使用全拒絕方法撰寫程序代碼。 僅針對需要存取權的實體建立allowlist。 例如，如果您有需要判斷是否應該允許特殊許可權作業的程式代碼，您應該撰寫它，讓 拒絕 結果是預設案例，而且 只有在程式代碼特別允許時才會發生允許 結果。

保護開發人員環境

開發人員工作站必須使用 強網路和身分識別控制來保護，以防止暴露。 請確定安全性更新已刻苦套用。

組建代理程式具有高度特殊許可權，而且可以存取組建伺服器和程序代碼。 它們必須受到與工作負載元件相同的嚴格性保護。 這表示 必須驗證和授權組建代理程式的存取權、應以防火牆控制進行網路區隔、應受限於弱點掃描等等。 Microsoft裝載的組建代理程式應該優先於自我裝載的組建代理程式。 Microsoft裝載的代理程式提供優點，例如每個管線執行的全新虛擬機。

自定義建置代理程式會增加管理複雜性，並可能成為攻擊媒介。 必須安全地儲存組建機器認證，而且您必須定期從文件系統移除任何暫時的組建成品。 您可以只允許來自組建代理程式的連出流量來達到網路隔離，因為它使用與 Azure DevOps 通訊的提取模型。

原始程式碼存放庫也必須受到 保護。 根據需要知道的方式授與程式代碼存放庫的存取權，並盡可能減少弱點的暴露，以避免攻擊。 有一個徹底的程式，以檢閱程式代碼 是否有安全性弱點。 針對該目的使用安全組，並實作以業務理由為基礎的核准程式。

保護部署管線中的程序代碼

它不足以保護程序代碼的安全。 如果它在可惡意探索管線中執行，則所有安全性工作都是徒勞且不完整的。 建置和發行環境也必須受到保護 ，因為您想要防止不良執行者在您的管線中執行惡意代碼。

維護整合至應用程式之每個元件的最新清查

整合至應用程式的每個新元件都會增加受攻擊面。 若要確保新增或更新新元件時適當的責任和警示，您應該會有這些元件的清查。 將它儲存在建置環境之外。 定期檢查您的指令清單是否符合建置程式中的內容。 這樣做有助於確保不會意外新增任何包含後門或其他惡意代碼的新元件。

管線工作

  • 從受信任的來源提取管線中的工作，例如 Azure Marketplace。 執行管線廠商所撰寫的工作。 我們建議使用 GitHub 工作或 GitHub Actions。 如果您使用 GitHub 工作流程，偏好Microsoft撰寫的工作。 此外，驗證工作，因為它們是在管線的安全性內容中執行。

  • 管線秘密。 在管線內執行的部署資產可以存取該管線中的所有秘密。 針對管線 的不同階段適當分割，以避免不必要的暴露。 使用管線內建的秘密存放區。 請記住，在某些情況下，您可以避免使用秘密。 探索工作負載身分識別的使用（用於管線驗證）和受控識別（用於服務對服務驗證）。

將不同的環境分開

在不同環境中使用的數據必須分開。 生產數據不應該用於較低環境 ，因為這些環境可能沒有生產環境所擁有的嚴格安全性控制。 避免從非生產應用程式連線到生產資料庫，並避免將非生產元件連線到生產網路。

漸進式曝光

使用漸進式曝光， 根據所選準則將功能發行給用戶 子集。 如果發生問題，則會將這些用戶的影響降到最低。 這種方法是常見的風險降低策略，因為它會降低介面區。 隨著功能成熟，而且您對安全性保證更加有信心，您可以逐漸將其發行給一組更廣泛的使用者。

保護生產環境中的程序代碼

生產階段提供最後一個 負責的機會，以修正安全性缺口。 保留生產環境中發行的黃金映射記錄。

保留版本化成品

保留所有已部署資產及其版本的目錄。 這項資訊在事件分級、緩和問題，以及讓系統回到工作狀態時很有用。 已設定版本資產也可以與已發佈的常見弱點與漏洞 (CVE) 通知進行比較。 您應該使用自動化來執行這些比較。

緊急修正

您的自動化管線設計應該有彈性來支援 一般和緊急部署。 這種彈性對於支援快速且負責任的安全性修正非常重要。

發行通常與多個核准網關相關聯。 請考慮建立緊急程式來加速安全性修正。 此程式可能涉及小組之間的通訊。 管線應該允許快速向前復原和復原部署，以解決在一般部署生命週期外發生的安全性修正、重大錯誤和程式碼更新。

注意

一律將安全性修正排定優先順序，以利於便利性。 安全性修正不應該引入回歸或錯誤。 如果您想要透過緊急管線加速修正，請仔細考慮可以略過哪些自動化測試。 根據運行時間評估每個測試的值。 例如，單元測試通常會快速完成。 整合或端對端測試可以長時間執行。

在整個生命週期中維護程式碼安全性

此階段 的目標是確保安全性狀態不會隨著時間而衰落。 SDLC 是一個進行中的敏捷式程式。 上述階段涵蓋的概念適用於此階段，因為需求會隨著時間而變更。

修補程式管理。 使用安全性修補程式和更新，讓軟體、連結庫和基礎結構元件保持在最新狀態。

持續改善。 藉由考慮程式代碼檢閱、意見反應、所學到的教訓，以及不斷演變的威脅，持續評估和改善軟體開發程序的安全性。

解除委任過時或不再使用的舊版資產 。 這樣做會減少應用程式的介面區。

維護也包含事件修正。 如果在生產環境中發現問題，則必須將問題及時整合到程式中，使其不會遞歸。

持續改善您的安全編碼做法，以跟上威脅環境。

Azure 便利化

Microsoft安全性開發週期 （SDL） 建議您可以套用至開發生命週期的安全做法。 如需詳細資訊，請參閱 Microsoft安全性開發生命週期。

適用於 DevOps 的 Defender 和 SAST 工具包含在 GitHub 進階安全性或 Azure DevOps 中。 這些工具可協助您追蹤組織的安全性分數。

請遵循這些資源中所述的 Azure 安全性建議：

若要在原始碼中尋找認證，請考慮使用 GitHub 進階安全性和 OWASP 原始碼分析工具等工具。

驗證應用程式中任何開放原始碼的安全性。 這些免費工具和資源可協助您進行評量：

安全性檢查清單

請參閱一組完整的建議。

安全性檢查清單