共用方式為

確保開發生命週期安全的建議

  • 發行項

適用於此 Power Platform Well-Architected 安全檢查表建議：

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

本指南介紹了透過在整個開發週期中應用安全最佳做法來保護程式碼和開發環境的建議。

工作負載的核心是實現業務邏輯的元件。 這些元件可以是低程式碼元素 (如畫布應用程式和流程) 和程式碼優先元素 (如外掛程式) 的混合。 構成工作負載的所有元件都必須不存在安全缺陷，以確保機密性、完整性和可用性。

透過身分和網路控制來保護基礎結構平面很重要，但這還不夠。 防止 Power Platform 工作負載實施不當以及這些工作負載中的活動受到損害，以加強您的整體安全狀況。 將安全性整合到開發生命週期的過程本質上是一個強化過程。 就像資源強化一樣，加強程式碼開發也是與情境無關的。 重點是增強安全性，而不是應用程式的功能要求。

定義

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

關鍵設計原則

安全措施應在多個點整合到您現有的軟體開發生命週期 (SDLC) 中，以確保：

  • 設計選擇不會導致安全漏洞。
  • 由於可利用的實現和不正確的編碼做法，低程式碼和程式碼優先的元件以及配置不會產生漏洞。
  • 低程式碼和程式碼優先的元件和部署流程不會被竄改。
  • 透過事件暴露的漏洞得到緩解。
  • 合規性要求不會受到影響或降低。
  • 稽核記錄在所有環境中實施。

以下部分提供了 SDLC 常用階段的安全策略。

需求階段

需求階段的目標是收集和分析工作負載或工作負載新功能的功能和非功能需求。 此階段很重要，因為它有助於建立適合工作負載目標的護欄。 保護工作負載的資料和完整性應該是整個開發生命週期每個階段的核心要求。

例如，考慮使用者將在應用程式中輸入和修改資料的工作負載。 安全設計選擇應涵蓋對使用者與資料互動的保證，例如對使用者身分進行身分驗證和授權，以及僅允許對資料進行允許的操作。 非功能性需求包括可用性、可用性和可維護性。 安全選擇應包括分段邊界、防火牆入口和出口以及其他跨領域的安全問題。

所有這些決策都應該有助於對工作負載的安全狀況進行良好的定義。 將安全要求記錄在商定的規範中，並將其反映在待辦事項中。 該文件應明確說明安全投資以及在投資未經業務利益相關者核准的情況下，企業願意承擔的取捨和風險。 例如，您可能會記錄在環境 Power Platform 中使用 IP 防火牆的需要，透過限制 Dataverse 僅存取允許的 IP 位置來保護您的組織資料。 如果業務利害關係人不願意承擔使用受控環境等解決方案的額外成本，他們必須準備好接受從公共場所 (例如咖啡店) 存取組織資源的風險。 再舉一個例子，假設您的應用程式必須連接到第三方資料來源。 Power Platform 可能為此提供了現成的連接器，但它可能不支援安全團隊核准的身分驗證要求。 在這種情況下，您的安全利害關係人可能願意接受使用未經核准的身分驗證方法的風險。 或者，您可以探索使用自訂連接器，同時取捨增加開發時間和潛在專案延遲的好處。

安全需求收集是此階段的關鍵部分。 如果沒有這種努力，設計和實現階段將基於未聲明的選擇，這可能會導致安全漏洞或不斷變化的需求，從而增加開發時間。 您可能需要稍後更改實作以適應安全性，這可能會很昂貴。

設計階段

在此階段，安全要求轉化為技術要求。 在您的技術規格中，記錄所有設計決策，以防止實施過程中出現歧義。 以下是一些典型的任務：

  • 定義架構的安全維度。 用安全控制覆蓋架構。 例如，對網路隔離邊界實用的控制、工作負載元件所需的身分和身分驗證方法的類型以及要使用的加密方法的類型。

  • 評估平台提供的功能可供性。 了解您和 Power Platform 之間的責任劃分非常重要。 避免與本機安全控制項重疊 Power Platform 或重複。 您將獲得更好的安全覆蓋範圍，並能夠根據應用程式的需求重新分配開發資源。

    例如，不要建立自訂邏輯來被動地識別應用程式和流程中未經核准的使用模式並發出警報，而是使用資料遺失防護策略對連接器的使用方式進行分類。

    僅選擇受信任的參考實施、範本、代碼元件、腳本和庫。 您的設計也應該指定安全版本控制。 應用程式依賴項應來自受信任的各方。 第三方供應商應該能夠滿足您的安全要求 並分享其負責任的披露計劃。 任何安全事件都應及時報告，以便您採取必要的措施。 此外，您的組織可能會禁止某些程式庫或參考實作。 例如，即使它是安全且沒有漏洞，仍然可能被禁止，因為它使用尚未獲得您的組織核准的功能、許可限製或參考實現的支援模型。

    為了確保遵循此指南，請維護已核准和/或未核准的架構、程式庫和供應商的列表，並確保您的製造商熟悉此列表。 如果可能，在開發管道中放置護欄以支援該清單。 盡可能自動化地使用工具來掃描依賴項中的漏洞。

  • 安全地儲存應用程式密碼。 安全地實現應用程式使用的應用程式密碼和預共用金鑰的使用。 憑證和應用程式密碼永遠不應儲存在工作負載 (應用程式或流程) 的原始程式碼中。 使用 Azure Key Vault 等外部資源來確保，如果您的原始程式碼可供潛在攻擊者使用，則無法取得進一步的存取權限。

  • 安全地連接到您的資料。 利用 Microsoft Dataverse 提供的強大安全功能來保護您的資料，例如基於角色和列級安全性。 對於其他資料來源，請使用具有安全性驗證方法的連接器。 避免以純文字形式儲存使用者名稱和密碼的查詢。 避免使用 HTTP 建立自訂連接器。

  • 定義終端使用者如何與工作負載和資料互動。 考慮使用者是否可以直接存取資料、他們需要什麼級別的存取權限以及他們從哪裡存取資料。 考慮如何與終端使用者分享應用程式。 確保只有需要存取應用程式和資料的人才能存取。 避免複雜的資訊安全模型，這些模型會鼓勵採取變通辦法來避免安全障礙。

  • 避免硬編碼。 避免對 URL 和金鑰進行硬編碼。 例如，避免在 Power Automate HTTP 動作中將 URL 或金鑰硬編碼到後端服務。 請改用自訂連接器或使用環境變數做為 URL，使用 Azure Key Vault 做為 API 金鑰。

  • 定義測試計劃。 為安全需求定義明確的測試案例。 評估是否可以在管道中自動執行這些測試。 如果您的團隊有手動測試流程，請包括這些測試的安全要求。

注意

在此階段執行威脅建模。 威脅建模可以確認設計選擇是否符合安全要求，並揭示您應該縮小的差距。 如果您的工作負載處理高度敏感的資料，請投資安全專家，他們可以幫助您進行威脅建模。

最初的威脅建模練習應該在設計階段進行，即定義軟體的架構和高階設計。 在該階段執行此動作可以幫助您在潛在的安全問題併入系統結構之前識別它們。 然而，這項練習並不是一次性的活動。 這是一個持續的過程，應該貫穿軟體的整個發展過程。

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

開發和測試階段

在此階段，目標是防止程式碼、建置和部署管線中的安全缺陷和篡改。

在安全代碼實踐方面接受過良好訓練

開發團隊應接受安全編碼實踐方面的訓練。 例如，開發人員應熟悉 Microsoft Dataverse 中做法最低權限資訊安全模型的安全概念、模型導向應用程式的內容安全性原則 (限制嵌入到受信任網域) 以及連接器/本機閘道驗證方法。

應要求開發人員在開始處理 Power Platform 工作負載之前完成此訓練。

進行內部同儕程式碼審查以促進持續學習。

使用程式碼分析工具

解決方案檢查器應用於 Power Platform 資源，並且可以檢查任何傳統代碼的原始程式碼是否存在潛在的安全漏洞，包括代碼中是否存在憑據。 識別原始碼和設定檔中可能存在憑證和秘密洩漏的情況。 現在是回顧如何在生產中處理連接憑證的好時機。

執行模糊測試

使用格式錯誤和意外的資料來檢查漏洞並驗證錯誤處理，這對於包含 Power Pages 的解決方案尤其重要。

編寫足夠的程式碼

當您減少程式碼佔用量時，您也可以減少安全缺陷的機會。 重用已在使用且已通過安全驗證 的代碼和庫，而不是複製代碼。 開放原始碼可偵測和檢查版本、漏洞和法律義務。 開源 Power Platform 資源的數量不斷增加，因此這一點不容忽視。 如果可能，應在設計階段對此進行討論，以避免最後一刻出現問題。

保護開發人員環境

開發人員工作站需要透過強大的網路和身分控制進行保護，以防止暴露。 確保認真應用安全更新。

原始程式碼儲存庫也必須得到保護 。 根據需要授予對程式碼儲存庫的存取權限，並盡量減少漏洞的暴露以避免攻擊。 制定一個全面的流程來審查代碼 中的安全漏洞。 為此目的使用安全群組，並實施基於業務理由的核准程序。

安全代碼部署

僅僅保護程式碼是不夠的。 如果它在可利用的管道中執行，則所有安全努力都是徒勞且不完整的。 還必須保護 生成和發佈環境，因為您希望防止不良行為者在管道中運行惡意代碼。

維護整合到應用程式中的每個元件的最新清單

整合到應用程式中的每個新元件都會增加攻擊面。 為了確保在新增或更新新元件時進行適當的問責和發出警報，您應該擁有這些元件的清單。 定期檢查您的資訊清單是否與建置過程中的內容相符。 這樣做有助於確保不會意外新增包含後門或其他惡意軟體的新元件。

建議將管道用於 Power Platform 部署。 使用 GitHub Actions 擴充管線。 如果您使用 GitHub 工作流，則 Microsoft首選授權的任務。 此外，還要驗證任務，因為它們在管道的安全上下文中執行。

探索使用服務主體進行部署。

生產階段

生產階段是修復安全漏洞的最後一個負責任的機會。 記錄生產中發佈的黃金影像。

保留版本化的成品

保留所有已部署資產及其版本的目錄。 此資訊在事件分類、緩解問題以及使系統恢復工作狀態時非常有用。 版本化資產也可以與已發佈的常見漏洞和揭露 (CVE) 通知進行比較。 您應該使用自動化來執行這些比較。

緊急修復

您的自動化管道設計應該具有支援常規和緊急部署的靈活性。 這種靈活性對於支援快速且負責任的安全修復非常重要。

一個發佈通常與多個核准門相關聯。 考慮建立一個緊急流程來加速安全修復。 程序可能涉及團隊之間的溝通。 該管道應允許快速推薦和復原部署，以解決常規部署生命週期之外發生的安全性修復、嚴重錯誤和程式碼更新。

注意

始終優先考慮安全修復而不是便利性。 安全修復不應引入回歸或錯誤。 如果您想透過緊急管道加速修復，請仔細考慮可以繞過哪些自動化測試。 根據執行時間評估每個測試的價值。 例如，單元測試通常很快就會完成。 整合或端對端測試可以執行很長時間。

保持不同的環境分開

不應在較低的環境中**使用生產資料，因為這些環境可能沒有生產環境所具有的嚴格安全控制。 避免從非生產應用程式連接到生產資料庫，並避免將非生產元件連接到生產網路。

使用漸進曝光

使用漸進式曝光，根據所選標準向一部分使用者發佈功能。 如果出現問題，對這些使用者的影響將降至最低。 這種方法是一種常見的風險緩解策略，因為它減少了表面積。 隨著功能的成熟並且您對安全保證更有信心，您可以逐步將其發佈給更廣泛的使用者。

維護階段

此階段的目標是確保安全狀況不會隨著時間的推移而減弱。 SDLC 是一個持續的敏捷程序。 前面階段涵蓋的概念也適用於此階段，因為需求會隨著時間而改變。

持續改進。 通過考慮代碼審查、意見反應、經驗教訓和不斷變化的威脅以及提供的 Power Platform 新功能，持續評估和改進軟體開發過程的安全性。

停用過時或不再使用的舊資產 。 這樣做會減少應用程式的表面積。

維護也包括事件修復。 如果在生產中發現問題，需要立即將其整合回流程中，以免問題再次發生。

不斷改進您的安全編碼做法，以跟上威脅情況。

在 Microsoft Power Platform 中的 SDL

Power Platform 是以安全設計的文化和方法建立。 通過 Microsoft行業領先的 安全開發生命週期 （SDL）和 威脅建模 實踐，文化和方法都得到了不斷加強。

威脅建模檢閱程序可確保在設計階段發現威脅、降低威脅並進行驗證，以確保威脅已降低。

威脅建模也會將所有已透過連續定期查看的服務變更進行為活動。 依靠 STRIDE 模型 ，可協助解決最常見的不安全設計問題。

Microsoft的 SDL 相當於 OWASP 軟體保障成熟度模型 （SAMM）。 兩者都是建立在安全設計對 Web 應用程式安全性有整數的前提上。 有關詳細資訊，請參閱 Power Platform 中的 OWASP 十大風險：緩解措施。

Power Platform 簡易化

Microsoft 安全開發生命週期 (SDL) 推薦可應用於開發生命週期的安全做法。 有關更多資訊，請參閱 Microsoft 安全開發生命週期。

Defender for DevOps 和 SAST (靜態應用程式安全測試) 工具做為 GitHub Advanced Security 和 Azure DevOps 的一部分包含在內。 這些工具可以幫助您追蹤組織的安全評分。

您可以使用解決方案檢查工具功能，根據一組最佳做法規則，對您的解決方案執行各式各樣靜態分析檢查，並快速識別這些問題模式。 請參閱使用解決方案檢查器驗證您的解決方案。

安全性檢查清單

請參閱完整的建議集。

安全檢查表