共用方式為

DevSecOps 控制項

  • 發行項

本文說明如何套用安全性控件以支持 持續 SDL 安全性做法。 這些安全性控制是跨人員、程序和技術的 DevSecOps策略 不可或缺的一部分。 本文件說明每個控件，並示範如何將這些控制項套用至三個安全性配置檔。 這些配置檔符合大部分組織常見商務案例的典型安全性需求：

安全性控件與時間和影響圖表。

安全性控制配置檔

本文所參考的控制配置檔有三層。

暫時性最小值 – 暫時性例外狀況狀態的縮寫安全性配置檔，以支援低風險工作負載的快速原型設計。 此配置文件應該只用於需要在加速時程表上發行的暫時例外狀況，以符合重要的商務需求。 使用此配置檔的項目應該會快速升階至標準配置檔。

標準 - 大部分工作負載的平衡方法，大部分時間。

高安全性 – 工作負載的嚴格安全性 ，對商務和人類安全性有潛在高影響。

DevSecOps 安全性控制

本節提供每種工作負載類型的建議安全性控制參考。 此參考可依現狀採用，也可以調整為現有的軟體開發和軟體安全性程式。 如果大部分的組織尚未執行其中一些控件，則無法立即實作所有這些控件。 採用持續改進方法通常是最佳方法：優先處理控件、實作第一個控件、移至下一個控件、實作控件等等。 大部分的組織應先排定關鍵基礎的優先順序。

如需詳細資訊，請參閱 DevSecOps旅程圖。

此圖表摘要說明安全性控制件，以及如何將它們套用至每個工作負載安全性配置檔。

主要規劃考慮包括：

  • 左移 但仔細檢查 - 此參考的設計目的是要儘早偵測並更正問題，讓您在修正問題時更容易且更便宜地修正問題（有時稱為左移），但也假設失敗，並在稍後的程式中包含雙重檢查。 請一律仔細檢查 CI/CD 程式中的任何安全性控制，確保可避免的問題不會流向生產系統。 此概念遵循「深度防禦」和「失敗安全」原則。
  • 人工智慧 （AI） – 人工智慧的兩個主要影響包括：
    • 保護所有程式代碼 ，無論由人類或產生 AI 撰寫
    • 針對安全性 使用兩者 - 同時套用傳統和 AI 控制項，以增加任何安全性問題的可見度和內容（例如程式代碼分析工具）

安全性控制項

這些控制項會分組成其套用的開發階段，以及適用於所有開發階段和控制項設定檔的通用控制項（關鍵基礎）：

下列各節會定義這些專案：

建立重要基礎

此控件支持持續 SDL 練習 1 – 建立安全性標準、計量和治理、練習 2 – 需要使用經過證實的安全性功能、語言和架構，以及練習 10 – 提供安全性訓練。

標準 - 這些控制元件適用於所有開發階段和控制設定檔。

提供安全性訓練

此控件著重於為您的開發人員和安全性小組提供訓練，以透過開發生命週期辨識和解決安全性問題。 如果沒有安全性訓練，您的小組可能會錯過在應用程式存留期內造成危害的核心安全性弱點。

因此，您必須在所有角色上實作安全性訓練（包括使用者、開發人員、產品線經理、測試人員等等）。 每個角色都必須具備安全性風險的教育，以及其在保護應用程式安全方面所扮演的角色。 此訓練的形式可能是：正式或隨選訓練、模擬練習、威脅模型、指導/顧問、安全性冠軍、應用程式安全性支援小組、紫色小組活動、播客、影片或任何其他學習方法。

最後，每個角色都需要瞭解：

  • 為何必須解決安全性風險
  • 其角色的安全性需要執行哪些動作
  • 如何讓安全性成為其日常角色的一部分

人員 瞭解攻擊者的觀點、目標，以及真實世界安全性事件如何迅速成為安全性盟友，而不是試圖避免安全性。

安全性是一個永不結束的遊戲，威脅、技術和商務資產所要保護的一律會改變，威脅執行者永遠不會放棄。 安全性訓練方法必須持續且持續發展。 有效的訓練符合並強化安全策略、軟體開發生命週期 （SDL） 做法、標準和軟體安全性需求。 訓練內容應來自衍生自數據和新可用技術功能的深入解析。

雖然安全性是每個人的工作，但請務必記住，並非每個人都需要成為安全性專家，也不必努力成為熟練的滲透測試人員。 確保每個人都了解安全性基本概念，以及如何將其套用至將安全性建置至軟體和服務的角色至關重要。 此訓練應包含工作站、應用程式、身分識別和帳戶的安全使用。

特別是，開發人員和工程師建置系統通常不是安全性專家。 在威脅模型化的技術和概念層面進行訓練是必要的，才能使其生效，以便建置依設計保護的系統。 此訓練對於威脅模型化程式而言非常重要，可在開發人員遠超過安全性專業人員的組織內大規模運作。 威脅模型化必須視為基本工程技能，所有開發人員和工程師都必須具備至少基本熟練度。 因此，開發和工程小組必須經過訓練，才能在上線期間和定期重新整理工具中具備威脅模型化能力。

在無責任事後分析中包含安全性

無可指責的驗屍分析是團隊有效且有效率地學習錯誤的重要方法，不需要尋求某人指責來觸發小組成員的防禦性。 安全性學習應明確納入無責任的驗屍程式，以確保小組也會最大化安全性學習。

建立安全性標準、計量和治理

組織應該建立這些安全性標準、計量和治理，因為它們能支撐創新的能力。 它可啟用強式安全性計劃，不僅能保護組織的資產，還能符合其商務目標。 安全性標準是保持組織系統、數據和程式安全的基準需求和最佳做法。

這些標準應受到測量和管理，包括監視合規性，並定期檢閱和更新這些標準，以取得目前的威脅、工具和其他因素。 此程式應該涵蓋從初始構想到解除委任應用程式和任何支援開發環境的整個生命週期。

計量是用來查看安全性控件和程式效率的度量。 其中一個主要計量是追蹤應用程式易受攻擊時間的平均補救時間（MTTR）。 此度量可讓我們更及時地投資發行安全性修正。

注意

此概念與 MTTR 在專注於時間的安全性作業中不同，以移除對組織資產的敵人存取權。

安全性控管可作為安全性小組的指導手，通常建立在組織用來管理及控制其資訊安全的架構和程式之上。 這些包括原則、程式、控件和風險管理。 計量有助於量化風險暴露。 如果沒有它們，組織可能無法完全瞭解其弱點和潛在影響。

由於安全性需求可能很新，因此您有機會採用漸進式方法，逐漸將程式代碼標準提升到理想狀態。 此方法可讓小組有時間學習並自動化監視和控件。

需要使用經過證實的安全性功能、語言和架構

定義併發佈已核准的工具清單及其相關聯的安全性檢查。 使用妥善建立且經過證實的安全性解決方案對於避免常見的錯誤很重要，因為建置安全解決方案是非常具有挑戰性的。 嘗試重塑安全性解決方案幾乎總是會導致安全性風險增加，並浪費時間和精力。

請確定開發人員和工程師會利用新的安全性分析功能和保護。 它們應該一律使用最新的編譯程式、連結器、連結庫，以及適當的編譯程式和鏈接器旗標來產生安全的可執行檔。

組織應實作檢閱和核准程式，以驗證任何整合元件的安全性。 他們應該建立原則，只使用建置和部署強制執行和監視的已核准元件。

基礎身分識別安全性

請確定身分識別的使用和整合遵循既定的安全性最佳做法。 威脅執行者經常針對生產系統和開發程式使用身分識別攻擊技術。 一個受歡迎的說擷取這個，“攻擊者不闖入，他們只是登入。

身分識別安全性採用兩種開發形式：

  • 身分識別開發程式安全性 - 確定開發程式中的所有參與者使用強身份驗證方法進行日常工作，而且只有執行其工作工作所需的許可權。 如需詳細資訊，請參閱身分識別/應用程式訪問控制一節。
  • 系統與應用程式的身分識別安全性 - 確保其設計及建置的系統遵循驗證和授權方法的最佳做法（且不會建置自己經過證實和維護的身分識別系統的弱式模仿）。

遵循下列資源中的指引，為系統和應用程式套用身分識別安全性：

密碼編譯標準

將健全密碼編譯做法套用至所有密碼編譯的使用方式。 遵循連續 SDL 練習 4 - 定義和使用密碼編譯標準中所述的所有指導方針。

如需詳細資訊，請參閱 Microsoft SDL 密碼編譯建議。

保護您的開發環境

此控制件支援連續 SDL 練習 6 – 保護您的工程環境。

此控制件著重於使用安全工作站和整合開發環境 （IDE） 來保護開發環境。 此控件強調在軟體開發生命週期中使用 零信任 方法的優點。

在目前的環境中，攻擊者會擴充其作業，以鎖定開發人員的計算機，並竄改建置程式。 此攻擊的關鍵範例是SolarWinds所經歷的，攻擊者會在軟體組建的最後階段之前插入惡意 DLL。 實際上，這個後門應用程式並導致目標攻擊，該攻擊是透過供應鏈散發給全球數千個客戶。 如需 SolarWinds 攻擊的詳細資訊，請參閱 Microsoft 部落格 分析 Solorigate、啟動複雜網路攻擊的遭入侵 DLL 檔案，以及 Microsoft Defender 如何協助保護客戶。

請務必強化工作站、建置環境、身分識別和其他開發系統，以確保開發應用程式的完整性。 無法這麼做會建立路徑，讓攻擊者透過原始程式碼管理 （SCM） 系統或透過開發人員工作站入侵您的應用程式。

這種做法是開發生命週期的重要基礎，應該在所有配置檔上建立。

在整個練習中，您必須採取 零信任 方法。 零信任 模型的核心是，不論要求的來源或存取的資源為何，每個存取要求（使用者、服務或裝置）都會驗證為源自不受信任的網路。 將此「一律驗證並授權」原則為基礎，以所有可用的數據點為基礎。 您應該透過 Just-In-Time 和 Just-Enough-Access （JIT/JEA） 原則來限制使用者存取，並分割存取權，以盡可能降低缺口時可能造成的損害。

您可以透過各種方法強化開發環境，但一個良好的起點是考慮開發人員工作站。 藉由利用 GitHub Codespaces 或 Microsoft DevBox 等技術，您可以將開發環境轉移到 SaaS 應用程式，然後透過安全性和網路設定或透過組織原則進行管理。

若要進一步鎖定開發人員工作站，您可以發出特殊許可權存取工作站/安全存取工作站（PAW/SAW）。 這些工作站可協助您減少威脅向量，並確保標準化和控制的開發人員裝置。

安全設計

執行威脅模型化 （安全性設計檢閱）

此控制件支援連續 SDL 練習 3 – 執行威脅模型化。

此控件可識別設計中可能導致安全性事件和業務損毀的安全性弱點。 在實作設計之後，設計中的安全性弱點可能會難以緩解，因此在生命週期早期找出並修正這些弱點非常重要。

威脅模型化是安全性設計檢閱程式，可將安全性整合到系統或應用程式的設計中。

威脅模型化會有系統地識別、評估、排定優先順序，並降低軟體系統內的安全性風險。 這個結構化方法來分析軟體應用程式的設計和架構，可識別開發程式中的潛在威脅和弱點。

最終目標是了解系統，以及可能發生什麼問題。 威脅模型化可藉由對系統本身以及潛在攻擊者如何檢視它，來協助達成該目標。

此程式通常會採用威脅探索研討會的形式，讓系統與安全性專家小組共同探索及記錄風險。 雖然此程式可能非正式啟動，但它應該會快速演變成結構化程式，討論所建置服務的各個層面、其使用方式，以及系統介面。

威脅模型化的階段如下：

  1. 識別使用案例、案例和資產 – 從了解系統可讓哪些商務功能和使用案例開始，協助評估任何系統入侵的潛在商務影響，並通知討論要遵循。
  2. 建立架構概觀 – 建立應用程式的視覺摘要（或使用現有的應用程式）來清楚了解系統及其運作方式。 此概觀應包括：商務程式對應、元件和子系統、信任界限、驗證和授權機制、外部和內部介面，以及動作專案與元件之間的數據流。
  3. 識別威脅 - 使用常見方法來列舉潛在的安全性威脅，例如 STRIDE 模型 或 OWASP 威脅模型。
  4. 識別和追蹤風險降低 - 使用現有的開發程式和工具來監視和追蹤探索到的設計缺陷，以確保修正已實作並記載。 此程序應該包括，優先處理哪些風險降低措施，讓小組先花在最重要的工作上。 此程式是風險驅動，您可能沒有資源可完全降低第一個週期中的所有風險。 請仔細考慮哪些風險降低措施，包括部分風險降低，以降低攻擊者的防禦成本和資源。 安全性的目標是攻擊者失敗，這可以採取完全封鎖攻擊技術的形式，偵測它們以啟用防禦者回應、減緩攻擊速度，讓防禦者有時間回應、限制損害範圍等等。

威脅模型通常可作為所有相關人員的教育程式，並提供其他安全性規劃、實作和測試的重要內容。

包含人工智慧 （AI） 元件使用的應用程式必須評估與 AI 相關聯的特定風險類型，這與傳統應用程式不同。

藉由建立和分析威脅模型：傳達其系統的安全性設計、使用經過證實的方法分析潛在安全性問題的這些設計，以及建議和管理安全性問題的防護功能。

安全程式碼

程式碼分析

此控制項支援連續 SDL 練習 7 – 執行安全性測試。

此控制件著重於在開發人員將程式代碼寫入/輸入整合開發環境 （IDE） 或簽入程式代碼時提高程式碼的安全性。 此控件是 DevSecOps 做法的基石，因為它會直接解決攻擊者定期惡意探索的弱點。

如果沒有此控件，開發人員可能會遺漏直接編碼至應用程式的弱點。 您的開發人員不是惡意的，但可能缺乏識別其編碼原因不安全所需的技能。

此控件是將工具直接整合到 IDE 中，以取得左移方法生產力和安全性優點的關鍵。 此程式可在最早且最符合成本效益的機會快速探索和補救弱點。 此程式可以追溯套用至已經開發的應用程式，方法是識別安全性弱點，並稍後修正它們（雖然費用和難度更大）。

此程式通常會採用 IDE 外掛程式或專用掃描工具的形式，使用靜態分析安全性測試 （SAST） 和動態分析安全性測試 （DAST） 工具組掃描程式碼。

SAST 工具會掃描現有的程式代碼基底，並具有程式碼的完整存取權。 SAST 工具可以識別程序代碼本身的核心弱點。 另一方面，DAST 會在已部署的應用程式上執行。 因此，它無法存取程序代碼，而且會執行來模擬及識別運行時間的安全性弱點。

注意

AI 應用程式具有與傳統應用程式不同的弱點類型（例如偏差和幻覺），而且需要專注於這些弱點的工具。

品質控制很重要！ 執行這些工具的關鍵考慮是確保您微調這些工具，以減少誤判的雜訊和浪費工作。 調整這些工具通常需要具備開發人員背景的安全性專業人員，以瞭解貴組織的開發程式。 相同的專業人員也可以為開發人員提供個別偵測的分級指引和專業知識。 它們有助於區分真實和誤判、實際問題與誤報。 開發人員存取這些專家的程式通常與提供安全性訓練密切相關，例如透過冠軍計畫、應用程式安全性支援小組等。

暫時性最低 – 請確定您啟用內建 IDE 安全性功能，並在存放庫中實作最低層級的 SAST 掃描，以識別整個應用程式的弱點。 必須有記載的程式，才能在合理的時間內補救發現的問題，不過必須修正其缺陷的「Bug 列」標準會受到限制，直到應用程式達到標準平衡或高安全性配置檔為止。

標準 - 請務必使用所有適用的 SAST/DAST 工具完整掃描所有元件，並找出弱點。 確定應用程式程式代碼的完整安全性涵蓋範圍。 請確定您遵循已記載的補救程式，並具有符合組織風險承受能力的「Bug 列」標準。

高安全性 – 確定所有適用的應用程式都會強制執行詳細且記載的程式，以解決所有安全性弱點。 在任何組建或發行活動之前強制執行修正程式。 請確定您遵循記載的補救程式，並具有高度限制的「Bug 列」，符合貴組織對高安全性業務關鍵工作負載的風險承受能力。

有許多工具可用於靜態分析。 請檢閱 Microsoft 安全性開發生命週期的清單，以尋找詳細資訊。

保護 CI/CD 管線

供應鏈/相依性管理

此控制件支援持續 SDL 練習 5 - 保護軟體供應鏈。

此控制元件著重於使用軟體組合分析 （SCA） 工具和架構，例如安全供應鏈取用架構 （S2C2F） 來保護開發供應鏈。 這些程式有助於降低非 Microsoft 程式代碼危害的風險。

在現今的格局中，大部分的應用程式都依賴 開放原始碼 軟體（OSS），而這些元件的取用者幾乎沒有監督或控制。 此控件強調核心策略、技術和技術，以安全地內嵌、取用、使用和維護 OSS。 它也強調保護內部相依性，確保完整端對端生命週期，無論誰撰寫軟體。

無法控制軟體供應鏈會讓您面臨您不受控制的程式碼所引進的重大弱點。 一個臭名昭著的範例是log4J/Log4Shell弱點，允許使用此套件在任何系統或應用程式中執行遠端程序代碼。 這類弱點可能會意外或惡意地發生。

保護您的供應鏈是確保安全開發生命週期不可或缺的一部分，而且應該在每個配置檔狀態考慮，儘管每個單一狀態都應該遵循相同標準化的擷取相依性程式。

暫時性最低 – 清查所有相依性，讓您瞭解 OSS 弱點對應用程式的影響。 您可以使用 Dependabot 或其他軟體組合分析 （SCA） 工具來達成此清查。 這些工具也可以協助您產生軟體材料帳單（SBOM）。

標準 - 分析所有 OSS 弱點，並使用自動提取要求自動修正它們。 您也可以使用 Dependabot 和 GitHub 相依性圖表/檢閱來達成此控制件。

高安全性 – 主動封鎖應用程式中使用可惡意探索弱點的所有不安全套件。

若要深入瞭解此控件並測量您的 OSS 安全性成熟度，請檢閱 OSS 供應鏈架構 和 GitHub 關於保護您的開發生命週期的最佳做法檔。

安全性程式代碼檢閱

此控件著重於擁有安全性專家檢閱程式代碼，以找出潛在的安全性缺陷。 這有助於找出難以自動偵測的安全性問題。

此檢閱可以由：具有應用程式安全性專業知識的同儕小組、組織內的安全性擁護者、中央應用程式安全性小組的應用程式安全性專家或外部合作對象來執行。

此檢閱一律必須與撰寫程式代碼的開發人員分開。 完成自動化程式代碼分析之後，此檢閱應該做為個別活動。

暫時性最小值 – 此設定文件建議使用此控制件。

標準 - 此設定檔建議使用此控制件。

高安全性 – 所有高安全性 應用程式都需要此控件，而且通常牽涉到多個個別專家。

認證和秘密掃描

此控制項支援連續 SDL 練習 7 – 執行安全性測試。

此控制件著重於降低驗證金鑰和其他在程式代碼中公開的秘密的風險。 威脅執行者具有專業知識和自動化，可尋找並利用程式代碼中的內嵌秘密。

最佳方法是盡可能使用受控識別和新式驗證通訊協定，而不是密鑰和秘密。 雖然使用 API 金鑰和秘密傳統上一直是編碼和測試練習，但慣用的方法一律是資源的身分識別型驗證，因為安全性與生命週期管理能力增加。 此控件的實作採用使用受控識別的形式，例如 Azure 資源的受控識別。

如果需要使用秘密，您必須在整個生命週期中保護秘密，包括建立、使用、定期輪替和撤銷。 請避免直接在程式代碼中使用秘密，並視需要將它們儲存在安全密鑰/秘密記憶體系統中，例如 Azure 金鑰保存庫 或硬體安全性模組 （HSM）。 在任何情況下，純文本密鑰和秘密都不應該儲存在程式碼中，即使是暫時的！ 攻擊者會尋找並利用這些秘密。

重要

內部原始碼存放庫不安全！

內部存放庫應受到與公開面對的存放庫相同的需求，因為威脅執行者在透過網路釣魚或其他方式取得環境存取權之後，經常在存放庫中尋找秘密和密鑰。 這是假設缺口並據此設計安全性控制之 零信任 方法的必要專案。

標準 - 良好的秘密衛生是必要的，而且在所有配置檔中都是必要的。

注意

當您的小組或攻擊者找到這些秘密時，除了將機制修改為更安全的存取方法，例如受控識別，您還必須確定密鑰無法用來存取資源（依資源類型而有所不同）。

更多詳細資料和資源包括：

注意

強烈建議您將每個工作負載密鑰與 Azure 金鑰保存庫 等秘密記憶體解決方案搭配使用。

安全管線

此控制件支援持續 SDL 練習 5 - 保護軟體供應鏈。

此控制件著重於保護 DevOps 管線，以及應用程式建置程式期間建立的所有成品。

管線是自動化DevSecOps生命週期內的核心可重複活動不可或缺的一部分。 在 CI/CD 中，您的小組會定期將開發人員程式代碼合併為中央程式代碼基底，並自動執行標準組建和測試程式，其中包括安全性工具組。

使用管線來執行腳本或將程式代碼部署到生產環境，可能會帶來獨特的安全性挑戰。 請確定您的 CI/CD 管線不會成為執行惡意代碼、允許認證遭竊或讓攻擊者存取的任何介面區。 您也應該確保只會部署小組想要發行的程序代碼。 此程式包含 CI/CD 管線的成品，特別是可在攻擊中用來作為攻擊一部分的不同工作之間共用的成品。

軟體材料帳單 （SBOM） 產生應該自動化到建置程式，以建立這個非常重要的程式代碼證明成品，而不需要手動開發人員動作。

您可以確保管線安全性，確保對管線中使用的資源進行良好的訪問控制，並定期驗證/更新核心相依性/腳本。 請務必注意，CI/CD 管線中使用的腳本也是程序代碼，而且應該以您在專案中處理其他程式碼的方式處理。

注意

管線的安全性取決於基礎結構的安全性，以及用於進程的帳戶/身分識別。 如需詳細資訊，請參閱保護您的開發環境和安全作業控制項（身分識別/應用程式 存取控制、主機/容器控件、網路 存取控制）

標準 - 此控制項應在專案的每個資源的存取層級上進行評估;這是所有 DevSecOps 配置檔層級的必要控件。

若要深入瞭解管線安全性，請參閱 保護 Azure Pipelines。

安全作業

即時網站滲透測試

此控制項支援連續 SDL 練習 7 – 執行安全性測試。

讓專業應用程式滲透測試人員嘗試入侵完整工作負載的即時實例。 這項測試會驗證工作負載的安全性控制是否有效且一致。 滲透測試有助於尋找並醒目提示攻擊者可用來惡意探索應用程式並危害業務的最低抵抗路徑。 滲透測試在正確的時間完成時可能非常有價值。 一旦您減輕先前掃描中找到的廉價且容易利用弱點，請使用它們。

建議您在 DevSecOps 安全性設定檔的所有層級執行這項測試。

暫時性最低 – 建議您對所有應用程式執行滲透測試。 由於時間限制，您只能識別攻擊者可能利用的應用程式較容易的方法。 規劃將此值快速提升至標準層級。

標準 - 在標準 配置檔中，建議您進行滲透測試。 在此情況下，您可能會發現更複雜的弱點，因為開發程式初期會特別小心。

高安全性 – 針對企業營運應用程式和關鍵工作負載，需要完成滲透測試。 這些應用程式中的任何弱點都應該受到額外的注意和照顧。

整合這些活動的結果和意見反應，以改善您的安全性程式和工具。

身分識別/應用程式訪問控制

此控制項支援連續 SDL 練習 8 – 確保作業平臺安全性和練習 6 – 保護您的工程環境。

請確定針對開發環境、CI/CD 管線、作業工作負載和其他開發系統的所有技術元素，遵循身分識別和存取管理的安全性最佳做法，包括 保護特殊許可權存取 。 威脅執行者對於身分識別攻擊具有複雜的方法和自動化，這些攻擊經常針對生產系統和開發程式使用。 身分識別和存取管理是 Microsoft 建議 零信任 模型的基礎要素。

請確定所有開發系統和裝載它們的基礎結構都遵循安全性最佳做法（VM、容器、網路裝置等等）。

暫時性最低 – 確保每個人都使用多重要素驗證，而且只能存取執行其日常工作所需的系統。

標準 - 確保裝載工作負載的基礎結構元件（例如 VM、容器、網路和身分識別系統）符合身分識別和存取管理的安全性最佳做法，包括保護特殊許可權存取。

高安全性 – 實作完整的 零信任 策略，其中包含 MFA、身分識別威脅偵測和回應，以及雲端基礎結構權利管理（CIEM）。 針對支援每個高安全性工作負載的身分識別系統和元件執行工作負載特定的威脅模型 。

受控識別是盡可能安全且慣用的驗證方法。 由於需要在應用層儲存和擷取令牌和秘密，因此使用令牌和秘密較不安全。 此外，受控識別會自動變換，而不需要手動介入。

更多詳細資料和資源包括：

主機/容器/環境控件

此控制項支援連續 SDL 練習 8 – 確保作業平臺安全性和練習 6 – 保護您的工程環境。

請確定針對開發生命週期的所有技術元素，遵循所有計算資源和裝載環境的安全性最佳做法。 威脅執行者對於基礎結構和用戶端點攻擊具有複雜的方法和自動化，這些攻擊經常針對生產系統和開發程式使用。 基礎結構安全性是 Microsoft 建議 零信任 模型的基礎支柱。

此控制項必須包含開發和作業生命週期的所有元素，包括但不限於：

  • 一般 IT/操作工作站和環境
  • 專用的開發工作站和環境
  • CI/CD 管線基礎結構
  • 工作負載裝載環境
  • 任何其他開發系統。

此控制檔包含任何可以執行任何程式碼的資源，包括但不限於：

  • 虛擬機 （VM） 主機和 VM
  • 容器和容器基礎結構
  • 應用程式、腳本和程式代碼裝載平臺
  • 雲端訂用帳戶/帳戶和註冊
  • 開發人員、使用者和IT管理員工作站

請確定您將安全性最佳做法套用至基礎結構元件，包括安全性更新（修補程式）、基準安全性設定等等。

暫時性最低 – 套用主機和訂用帳戶的標準企業設定。

標準 - 確定基礎結構符合 Microsoft Cloud Security Benchmark （MCSB） 中所述的安全性最佳做法。

高安全性 – 嚴格套用 MCSB 標準，並 執行支援每個高安全性工作負載之基礎結構的工作負載特定威脅模型 。

更多詳細資料和資源包括：

網路存取控制

此控制項支援連續 SDL 練習 8 – 確保作業平臺安全性和練習 6 – 保護您的工程環境。

請確定針對開發環境、CI/CD 管線、操作工作負載環境和其他開發系統的所有技術元素，遵循網路存取管理的安全性最佳做法。 威脅執行者對於身分識別攻擊具有複雜的方法和自動化，這些攻擊經常針對生產系統和開發程式使用。 網路安全性是 Microsoft 建議 零信任 模型的基礎支柱。

網路安全性應包括：

  • 外部網路保護 – 與未經請求的外部/因特網流量隔離，以及已知攻擊類型的緩和措施。 這種隔離通常採用因特網防火牆、Web 應用程式防火牆 （WAF） 和 API 安全性解決方案的形式。
  • 內部網路保護 – 與未經請求的內部流量隔離（來自其他企業網路位置）。 此隔離可能會使用與外部網路保護類似的控件，而且可能會更細微地處理工作負載或特定個別元件和IP位址。
  • 阻斷服務風險降低 – 防止分散式阻斷服務 （DDoS） 和其他阻斷服務攻擊的保護。
  • 安全性服務 Edge （SSE） – 使用用戶端微分類來直接提供對資源的安全存取，包括套用 零信任 原則。

請確定所有開發系統和裝載它們的基礎結構都遵循安全性最佳做法（VM、容器、網路裝置等等）。

暫存最低 – 為工作負載套用標準企業設定。

標準 - 確定所有系統都有外部網路保護、DDoS 保護，以及每個工作負載內部網路保護的最小值。

高安全性 – 所有標準保護加上內部網路保護的高粒度、透過外部網路保護機制強制通道輸出伺服器流量，以及 支援每個高安全性工作負載之網路基礎結構的工作負載特定威脅模型 。

更多詳細資料和資源包括：

監視、回應和復原

此控件支持連續 SDL 練習 9 – 實作安全性監視和回應。

請確定安全性作業 （SecOps/SOC） 小組具有工作負載 （API 和應用程式） 以及裝載這些工作負載的可見性、威脅偵測和回應程式。 確定 SecOps 與基礎結構/ 工作負載小組之間的跨小組程式與工具可在攻擊後快速復原。

此控件會在工作負載在生產環境中且主動在組織中執行時維持工作負載的安全性。 此程式應與您的現有 安全性作業 功能整合，以偵測及回應安全性事件。

自定義工作負載的安全性監視結合常見元件的擴充偵測和回應解決方案，藉由分析記錄和其他應用程式數據來偵測及調查潛在的安全性威脅。 自訂應用程式數據通常包括：使用者要求、應用程式活動、錯誤碼、網路流量、應用程式的其他相關詳細數據、資料庫、網路端點和其他系統元件的相關信息。

此數據接著會透過即時威脅情報的深入解析來增強，以識別異常行為的模式，以指出可能嘗試滲透網路。 匯總、相互關聯且正規化之後，XDR 和安全性資訊與事件管理 （SIEM） 平臺會提供補救動作。

暫時性最低 – 在您的環境中部署 XDR 功能，以監視終端用戶裝置的流量。

標準 - 部署 XDR 和自定義 SIEM 偵測，以識別相對於整體環境的異常行為。 此配置檔可能包含個別工作負載的自定義偵測。

高安全性 – 標準控件加上根據工作負載威脅模型化見解的自定義個別工作負載偵測。 將此配置檔與 AI 結合，以提供內容感知到補救建議。

下一步

採用這些安全性控制措施，並將其調整為貴組織的風險承受能力和生產力需求。 您應該使用持續改善方法，以持續建置至理想狀態。

首先，將控件和最理想的目標層級設為優先順序。 請確定您先有正面的安全性影響和低摩擦變更。 排定優先順序、實作並整合第一個控件，然後重複程式與下一個控件。

您應該先排定關鍵基礎的優先順序，因為其具有廣泛的正面影響和認證和秘密掃描，因為其高影響和經常使用攻擊者。