保護開發生命周期的建議

  • 發行項

適用於此 Azure Well-Architected Framework 安全性檢查清單建議：

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

相關指南： 威脅分析

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

安全性週期的圖表。

DevSecOps 會將安全性整合到 DevOps 程式中，方法是：

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

  • 實作安全性管線之類的工具，以掃描程式代碼和基礎結構作為程式代碼， (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) 使用動態應用程式安全性測試 。 此工具鏈可以檢查安全性網域中的錯誤，並模擬一組攻擊來測試應用程式的安全性復原能力。 可能的話，請將此工具整合到您的組建管線中。

遵循業界標準來保護程式代碼撰寫做法。 For more information, see the Community resources section of this article.

使用 linters 和程式代碼分析器來防止認證推送至原始程式碼存放庫。 例如，.NET Compiler Platform (Roslyn) Analyzers 會檢查您的應用程式程式代碼。

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

使用測試的組合。 如需安全性測試的一般資訊，請參閱 安全性測試的建議。

撰寫足夠的程序代碼

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

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

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

保護開發人員環境

開發人員工作站必須 受到強式網路和身分識別控制的保護，以避免暴露。 請確定已仔細套用安全性更新。

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

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

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

安全程式碼部署

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

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

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

管線工作

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

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

將不同的環境分開

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

漸進式曝光

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

生產階段

生產階段提供最後一個 負責修正安全性差距的機會。 保留生產環境中發行之黃金映像的記錄。

保留已建立版本的成品

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

緊急修正

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

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

注意

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

維護階段

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

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

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

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

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

持續改善您的安全程式代碼撰寫做法，以跟上威脅環境。

Azure 指導

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

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

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

若要在原始碼中尋找認證，請考慮使用 GitHub Advanced Security 和 OWASP 原始碼分析工具等工具。

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

安全性檢查清單

請參閱一組完整的建議。

安全性檢查清單