共用方式為

DevOps 安全性

DevOps 安全性整合了整個軟體開發生命週期 （SDLC） 的安全實踐，從初始設計和編碼到建置、測試和部署再到生產。 與將安全性視為最後一道閘門的傳統安全方法不同，DevOps 安全性將安全性控制、自動化測試和持續監控嵌入到開發管道的每個階段。 這種方法認識到，現代軟體交付依賴於複雜的 CI/CD 管道、第三方依賴項、基礎設施即程式碼和自動化部署，每種管道都會引入對手主動利用的潛在攻擊媒介。 透過應用零信任原則 （假設違規、明確驗證） 和深度防禦策略，DevOps 安全性可確保程式碼、相依性、基礎結構組態和管線程式從設計到生產都保持可信且防竄改。 如果沒有全面的 DevOps 安全性，組織將面臨嚴重風險，包括供應鏈攻擊、管道中的憑證暴露、惡意程式碼注入、易受攻擊的容器映像以及未經授權的基礎設施變更，這些變更可能會建立影響所有下游消費者的持續後門。

以下是 DevOps 安全性安全性網域的三個核心支柱。

確保設計和供應鏈的安全： 儘早執行結構化威脅建模。 透過相依性和授權掃描、漏洞管理和 SBOM 產生來保護供應鏈。 驗證所有組件的來源和完整性。

相關控制項：

安全控制左移： 將 SAST、秘密掃描、IaC 掃描和 DAST 集成到 CI/CD 管道中以實現安全控制左移。 集中秘密管理 （例如 Key Vault）、限制管線變更授權單位，並在部署之前持續掃描和保護成品 （例如容器和 VM 映像）。

相關控制項：

監控和審核 DevOps 活動： 收集 DevOps 稽核和安全日誌並將其轉發到中央分析平台，以進行關聯和回應。 偵測未經授權的管道變更、權限提升、異常認可和非工作時間執行。

相關控制項：

DS-1：進行威脅建模

安全原則

在設計階段使用 STRIDE 方法實施系統威脅建模，以識別潛在的安全威脅、確定風險的優先順序，並在程式碼開發開始之前實施適當的緩解措施。 這種左移策略降低了補救成本並改善了整體安全態勢。

需要減輕的風險

未能在設計階段進行威脅建模的組織在操作時存在對手系統性利用的關鍵盲點。 在沒有系統威脅分析的情況下：

  • 後期建築缺陷： 嵌入式設計漏洞需要在生產中進行昂貴的重構，修復成本遠高於在設計階段解決問題的成本。
  • 未識別的攻擊面： 不安全的信任邊界、缺少身份驗證要求或資料流保護不足等威脅媒介仍未記錄在案，使攻擊者能夠利用防禦者不認識的已知弱點。
  • 安全控制不足： 威脅分析不完整導致安全控制（加密、身份驗證、授權、審計日誌記錄）缺失或不足，從而在縱深防禦策略中造成可利用的漏洞。
  • 合規盲點： 如果沒有記錄在案的威脅模型和緩解證據，就無法滿足強制安全設計驗證的法規要求（PCI-DSS、HIPAA、SOX）。
  • 證券債務累積： 在沒有威脅建模的情況下不斷添加功能會產生複雜的安全技術債務，使系統逐漸變得更加脆弱，並且難以追溯保護。

與早期設計階段的緩解相比，缺乏威脅建模會增加違規可能性、延長停留時間並導致更高的補救成本。

MITRE ATTCK(&C)

  • 初始存取（TA0001）：利用面向公眾的應用程式（T1190），通過威脅建模識別出的驗證、會話管理或輸入驗證中的架構缺陷進行攻擊。
  • 權限提升 （TA0004）：濫用權限提高控制機制 （T1548） 利用系統架構中權限分離不足或缺少授權檢查。
  • 防禦規避（TA0005）：利用系統設計中的稽核記錄缺失、監視差距或安全性遙測不足來削弱防禦（T1562）。

DS-1.1：實作以 STRIDE 為基礎的威脅建模

設計階段的系統威脅建模透過在開發開始之前識別漏洞，為安全軟體架構奠定了基礎。 在設計階段解決安全問題可大幅降低修復成本，並防止架構缺陷嵌入生產系統中。 早期威脅識別可確保安全控制內建於架構中，而不是稍後進行改造。

實作下列結構化方法來建立威脅模型：

  • 建立系統的 STRIDE 方法： 使用 STRIDE 方法（欺騙、篡改、否認、資訊揭露、拒絕服務、權限提升）將系統威脅建模建立為強制性設計階段活動。 首先建立資料流程圖 （DFD），以對應系統元件、資料流程、信任邊界和外部相依性。 對於每個元件和資料流，系統地評估所有六個 STRIDE 類別的潛在威脅，根據可能性和影響確定風險的優先順序，並在開發開始之前記錄具體的緩解措施。

  • 使用結構化威脅建模工具： 使用結構化威脅模型化工具，例如 Microsoft 威脅模型化工具 ，以保持一致性，並利用常見架構模式 （Web 應用程式、API、微服務、IoT 解決方案） 的預先建置範本。 該工具有助於建立 DFD、根據元件類型和資料流自動識別威脅，並產生具有相關安全控制的可操作緩解建議。 將威脅模型與架構文件作為版本化工件存儲在版本控制中。

  • 整合到開發工作流程中： 藉由將已識別的威脅匯出至 Azure DevOps 工作專案，並具有明確的擁有權、優先順序和接受準則，將威脅模型化輸出直接整合到開發工作流程中。 實施架構審查門檻，要求在設計核准前完成威脅模型，並建立拉取請求檢查，以便在偵測到架構變更時觸發威脅模型檢閱。 這可確保威脅分析在整個開發生命週期中與系統演進保持同步。

DS-1.2：自動化威脅分析整合

跨大型組織擴展威脅建模需要自動化和分散式功能，以防止安全審查成為開發瓶頸。 嵌入在專案啟動和拉取請求流程中的自動化威脅識別工作流程可確保一致的安全分析，而無需對每個專案進行手動幹預。 透過支援計劃在開發團隊中建立安全專業知識，可以建立可持續、可擴展的威脅建模實踐。

實作這些自動化和啟用功能：

  • 透過自動化和啟用進行擴展： 透過自動化和啟用，在整個組織中擴展威脅建模。 在專案啟動範本中嵌入安全問卷，自動評估風險等級、確定威脅建模要求，並根據資料分類、外部暴露和監管範圍分配適當的安全審查檢查點。 在提取要求工作流程中自動執行架構檢閱觸發程序，以偵測系統界限、驗證流程或資料處理邏輯的變更，將此類變更路由至安全性架構師，以進行威脅模型驗證。

  • 與安全冠軍一起建置分散式功能： 建立安全冠軍計劃，在開發團隊內建立分散式威脅建模能力。 對 STRIDE 方法的擁護者進行培訓，為他們提供威脅建模工具和模板，並使他們能夠為團隊促進威脅建模會議。 安全冠軍充當第一線審查，將複雜的場景升級到集中式安全團隊，同時使大多數威脅建模能夠在沒有瓶頸的情況下進行。

自動化威脅分析實作：

  • 問卷式評估： 標準化安全性問卷整合至 Azure DevOps 範本中，以一致地識別威脅
  • 安全冠軍計劃： 每個開發團隊中指定的安全冠軍，接受威脅建模促進培訓
  • 架構審查自動化： 自動檢查需要威脅模型檢閱的架構圖更新提取要求
  • 威脅模型即代碼： 使用結構化格式 （JSON/YAML） 的版本控制威脅模型定義，可實現自動化分析

實作範例

當攻擊者利用支付 API 中在開發過程中從未發現的授權缺陷時，一家金融服務組織遭受了資料外洩，導致了重大詐欺交易和監管罰款。

挑戰： 微服務架構，無需安全審查即可部署大量 API。 開發團隊缺乏識別威脅的安全專業知識。 只有在生產事件之後才發現架構安全性問題。

解決方案方法：

  • STRIDE 威脅建模： 針對所有微服務和 API 端點實作 Microsoft 威脅模型化工具 ，其中包含顯示架構和敏感性資料流程的資料流程圖。
  • 安全冠軍計劃： 每個開發團隊中有受過訓練的威脅建模促進者，從設計上實現安全性，而不會造成中央安全團隊的瓶頸問題。
  • 自動化工作流程整合： 將威脅模型檢閱整合至 Azure DevOps 提取要求工作流程，需要架構變更的安全性核准。

結果： 在部署前發現了許多安全問題，防止了潛在的違規行為。 大幅減少生產中的安全性弱點。 安全審查為開發週期增加了極少的時間。

關鍵性層級

必須具備。

控制項對應

  • NIST SP 800-53 修訂版 5： SA-11、SA-15、PL-8、RA-3、RA-5
  • PCI-DSS v4： 6.3.1、6.3.2、12.3.1
  • CIS 控制 v8.1： 14.2、14.3
  • NIST CSF v2.0： ID.RA-3, PR.IP-2
  • ISO 27001：2022 認證： A.5.12、A.8.25
  • SOC 2： CC3.2、CC7.1

DS-2：保護軟體供應鏈

安全原則

在整合之前驗證所有第三方元件的來源、完整性和安全狀態，以實作相依性零信任。 持續掃描依賴項中的漏洞，維護全面的軟體物料清單 （SBOM），並強制執行自動化安全性更新，以最大限度地減少供應鏈攻擊面。

需要減輕的風險

軟體供應鏈攻擊構成了嚴重威脅，因為對手利用組織和第三方元件之間的信任關係，以最小的努力實現廣泛的影響。 沒有全面的供應鏈安全：

  • 惡意依賴： 攻擊者會將後門程式植入熱門的開放原始碼程式庫（類似 SolarWinds 的攻擊），或者建立名稱相似的誤植套件，使其在安裝或運行時執行惡意程式碼。
  • 易受攻擊的第三方庫：由於缺乏可見性和自動化漏洞管理，依賴項中的已知 CVE（Log4Shell、Heartbleed、Struts 漏洞）在數週或數月內仍未修補。
  • 遭入侵的組建成品： 攻擊者在儲存或傳輸過程中篡改編譯的二進位檔、容器映像或部署包，注入繞過原始程式碼審查的惡意軟體。
  • 依賴混淆攻擊： 惡意行為者將名稱與內部私有套件相符的套件上傳到公共儲存庫，利用套件管理器解析邏輯來替換惡意程式碼。
  • 傳遞依賴風險： 間接依賴關係（依賴關係的依賴關係）中的漏洞在沒有深度依賴樹分析和 SBOM 生成的情況下仍然是不可見的。
  • 缺乏出處驗證： 缺乏加密驗證會導致套件替換攻擊，其中合法套件被惡意版本取代。

供應鏈入侵會造成廣泛影響，可信任函式庫中的持續後門，以及因外觀合法而具有高度隱蔽性。

MITRE ATTCK(&C)

  • 初始存取 （TA0001）：供應鏈入侵 （T1195.001） 透過入侵軟體相依性和開發工具，在目標環境中取得初始立足點，以及信任關係 （T1199） 利用組織與第三方軟體廠商之間的信任來提供惡意更新。
  • 執行 （TA0002）：命令和腳本直譯器 （T1059） 執行嵌入在相依性安裝腳本或安裝後掛勾中的惡意程式碼。
  • 持續性 （TA0003）：入侵用戶端軟體二進位檔 （T1554） ，將後門內嵌在已編譯的程式庫中，這些程式庫會在應用程式更新中持續存在。

DS-2.1：實作相依性掃描與管理

全面的依賴安全管理透過保持對所有第三方元件的可見性、持續監控漏洞以及自動化修復流程來防止供應鏈攻擊。 現代應用程式依賴數百或數千個相依性 （直接和可轉移），因此無法進行手動安全性評估，並透過易受攻擊的程式庫建立廣泛的攻擊面。 具有持續監控的自動依賴項掃描可確保組織在漏洞被利用之前檢測並修復漏洞。

透過以下核心功能建立持續的依賴安全性：

  • 建立全面的可見性和 SBOM 生成： 建立具有三個核心功能的持續依賴安全管理：全面可見性、自動化漏洞偵測和主動修復。 首先產生完整的相依性清單，以對應所有存放庫中的直接相依性 （在套件資訊清單中明確宣告） 和可轉移相依性 （相依性之相依性）。 以業界標準格式（SPDX、CycloneDX）維護軟體物料清單 （SBOM），以符合法規遵循和事件回應準備。

  • 實施自動化漏洞掃描和修復： 實作自動化弱點掃描，持續監控國家弱點資料庫 （NVD）、GitHub 諮詢資料庫和特定語言安全建議的相依性。 當新的 CVE 被公開且影響您的相依項目時，設定即時警示，並根據嚴重性路由至適當的團隊。 啟用自動化安全性更新功能，以產生具有相依性版本升級的提取要求，包括相容性測試和智慧型合併衝突解決，以減少手動補救負擔。

  • 將安全驗證整合到開發工作流程中：透過提取請求審查將相依性安全性驗證直接整合到開發工作流程中，自動評估相依性變更的安全影響，標記具有已知漏洞、授權合規性問題或可疑特徵（錯字錯誤、缺乏維護者聲譽）的新相依性。 為高風險相依性變更建立核准閘道，並強制執行原則，禁止具有嚴重弱點的相依性合併至受保護的分支。

  • 將可見性擴展到生產環境： 使用適用於 雲端的 Microsoft Defender DevOps 安全性 等工具，將可見度從原始程式碼延伸至已部署的環境，將程式代碼相依性與執行中的工作負載相互關聯、透過相依性鏈結識別攻擊路徑，並根據實際生產暴露而不是僅理論風險來排定補救的優先順序。 GitHub Advanced Security 等工具提供全面的相依性圖表視覺效果、Dependabot 驅動的自動更新，以及專屬套件生態系統的自訂弱點模式支援。

實作範例

一家醫療保健組織在生產應用程式中發現惡意 npm 套件，該套件竊取了數月的患者資料。 調查發現已知 CVE 存在廣泛的易受攻擊的依賴關係，包括嚴重的 Log4Shell 漏洞。

挑戰： 數百個儲存庫中的數千個相依性，無法查看弱點或惡意套件。 手動進行相依性審查會耗費每個應用程式數週的時間。 監管審計發現了關鍵的供應鏈差距。

解決方案方法：

結果： 快速偵測並修復廣泛的易受攻擊的相依性。 透過自動化驗證，防止了多個惡意套件事件。 通過全面的 SBOM 文檔實現了監管合規性。

關鍵性層級

必須具備。

控制項對應

  • NIST SP 800-53 修訂版 5： SR-3、SR-4、SR-6、SA-12、SA-15（9）、RA-5
  • PCI-DSS v4： 6.2.4、6.3.2、6.3.3
  • CIS 控制 v8.1： 16.1、16.2、16.11
  • NIST CSF v2.0： ID.SC-2、ID.SC-4、DE.CM-8
  • ISO 27001：2022 認證： A.5.19、A.5.22、A.5.23
  • SOC 2： CC3.2、CC8.1

DS-3：保護 DevOps 基礎架構

安全原則

透過全面的機密管理、具有核准閘道的管線存取控制、安全的建置代理程式設定和持續監控，為建置基礎結構實施深度防禦。 消除硬式認證並強制執行最低權限存取，以保護軟體開發和部署程式的完整性。

需要減輕的風險

不安全的 DevOps 基礎設施會產生嚴重漏洞，對手利用這些漏洞來破壞整個軟體交付鏈。 如果沒有全面的基礎設施安全：

  • 受損的 CI/CD 管道： 攻擊者透過竊取的憑證、利用的漏洞或內部人員存取來建立管道，從而實現程式碼注入、工件篡改或影響所有下游消費者的部署操縱。
  • 組建記錄和成品中公開的秘密： 硬式編碼的認證、API 金鑰、憑證和連接字串會透過管道日誌、錯誤訊息或編譯的成品洩漏，為攻擊者提供直接存取生產環境的機會。
  • 未經授權的管道修改： 缺乏變更控制和核准工作流程，可讓惡意執行者修改管線定義、注入惡意建置步驟，或變更部署組態，而不會被偵測到。
  • 存取控制不足： 過於寬鬆的角色指派和缺乏職責分離，可在 DevOps 基礎架構內實現橫向移動、權限提升和持久存取建立。
  • 不安全的建置代理程式： 未修補、配置錯誤或受損的建置代理程式為攻擊者提供了對建置環境的持續存取以及生產網路的潛在樞軸點。
  • 缺少稽核追蹤： DevOps 活動的記錄和監控不足會阻止偵測到未經授權的存取、可疑修改或內部威脅。

基礎設施入侵允許攻擊者在源頭注入代碼，繞過受信任的管道，並影響每個下游應用程序。

MITRE ATTCK(&C)

  • 初始存取 （TA0001）：使用竊取的認證或服務主體密碼來存取 DevOps 平台和管線的有效帳戶（T1078）。
  • 持續性 （TA0003）：帳戶操作 （T1098） 建立後門服務主體、個人存取權杖或 SSH 金鑰以維護存取。
  • 認證存取 （TA0006）：不安全的認證 （T1552.001） 從管線記錄、環境變數或組態檔收集秘密。
  • 防禦規避 （TA0005）：損害防禦 （T1562） ，停用管線定義中的安全性掃描步驟、稽核記錄或核准閘道。

DS-3.1：實作管線的密碼管理

集中式秘密管理可從程式碼、組態檔和管線定義中移除硬式編碼秘密，以消除 DevOps 管線中的憑證暴露。 管道 YAML、環境變數或來源存放庫中內嵌的認證代表管道入侵的主要攻擊媒介，使存取存放庫或記錄的攻擊者能夠提取生產認證。 透過動態檢索和即時存取模式實施受加密保護的秘密存儲，可以防止憑證被盜，同時保持營運效率。

使用下列安全性控制來設定秘密管理：

  • 透過集中式儲存消除硬編碼憑證： 透過加密存取控制和全面的稽核追蹤，將所有機密集中在專用的機密管理基礎架構中，從管道定義和原始程式碼中消除硬編碼憑證。 建立秘密絕不能儲存在管線 YAML 檔案、記錄中可見的環境變數或存放庫中的組態檔中的原則，這些是 DevOps 環境中憑證公開的主要向量。

  • 使用受控識別設定動態秘密擷取： 使用 Azure 金鑰保存庫 等解決方案實作集中式秘密儲存體，這些解決方案提供加密的秘密儲存體、細微的存取原則、自動秘密輪替和全面的稽核記錄。 設定管線，以透過安全服務連線在執行階段動態擷取密碼，而不是將其內嵌在管線定義中。 使用受控身份或工作負載身份聯邦來驗證對秘密存放區的管道存取，這樣就不需要長期使用那些本身易成為竊取目標的服務主體憑證。

  • 使用審批門強制執行即時存取： 強制執行即時秘密存取模式，其中僅在需要時擷取秘密，並在管道完成後自動撤銷，以將認證存留期暴露降到最低。 實施有時限的存取限制，並要求多人授權（批准門）才能存取生產機密的管道，確保沒有單一受損帳戶可以在沒有額外驗證的情況下存取敏感憑證。

  • 建立分層基礎架構存取控制： 為 DevOps 基礎結構建立分層存取控制：將管道修改權限限制為經過安全性審查的人員、強制執行需要核准生產部署的環境特定權限、實作存放庫層級服務連線限制，防止管道存取其預期範圍之外的秘密，以及部署具有敏感工作負載網路隔離的強化自我裝載建置代理程式。 將基礎結構即程式碼安全性掃描整合到管線中，以防止部署配置錯誤的資源，這些資源可能會暴露機密或建立未經授權的存取路徑。

實作範例

當攻擊者使用管道日誌中發現的被盜服務主體憑證存取生產資料庫時，一家零售組織遭受了入侵，從而暴露了數百萬條客戶記錄。

挑戰： 在管線變數中硬編碼的資料庫連接字串和 API 金鑰。 過於寬鬆的管線權限允許任何開發人員部署到生產環境。 建置代理程式入侵提供了對基礎設施的持久存取。

解決方案方法：

  • 集中秘密管理： 實作 Azure 金鑰保存庫 整合，從管線中消除硬式編碼的秘密。 已設定受控識別驗證，以移除認證暴露風險。
  • 管線存取控制： 使用 Azure DevOps 環境 建立核准閘道和環境特定許可權，需要安全性小組核准才能進行生產部署。
  • 強化的建置代理程式： 部署具有安全性強化和網路隔離功能的自我裝載代理程式，適用於處理受管制資料的敏感工作負載。
  • 基礎設施安全掃描： ARM 範本和 Terraform 組態的整合安全性驗證，防止組態部署錯誤。

結果： 消除管線日誌中的秘密，防止憑證被盜。 消除未經授權的生產部署。 在部署之前偵測並封鎖基礎結構組態錯誤。

關鍵性層級

必須具備。

控制項對應

  • NIST SP 800-53 修訂版 5： AC-2、AC-3、AC-6、SC-12、SC-13、AU-2、AU-6
  • PCI-DSS v4： 8.3.2、8.6.1、8.6.3、12.3.3
  • CIS 控制 v8.1： 4.1、4.7、6.1、6.5
  • NIST CSF v2.0： 保護.AC-4，保護.DS-5，檢測.CM-7
  • ISO 27001：2022 認證： A.5.15、A.5.16、A.8.3
  • SOC 2： CC6.1、CC6.6、CC6.7

DS-4：整合靜態應用程式安全測試 （SAST）

安全原則

透過整合到每個建置流程中的多個專用靜態應用程式安全測試 （SAST） 掃描器，實施全面的自動化安全測試。 使用多掃描器覆蓋範圍進行全面檢測，實施具有推送保護的秘密掃描，並部署語意程式碼分析，以便在漏洞進入生產環境之前識別和阻止漏洞。

需要減輕的風險

在開發過程中逃脫檢測的代碼級漏洞會造成持續的安全弱點，對手會系統地利用這些弱點。 沒有全面的 SAST 集成：

  • 注入漏洞： SQL 注入、跨站腳本 （XSS）、命令注入和 LDAP 注入缺陷使攻擊者能夠操縱應用程式邏輯、提取敏感資料或執行任意程式碼。
  • 硬式編碼認證： 開發人員無意中將密碼、API 金鑰、憑證和連接字串提交到原始程式碼儲存庫，從而為攻擊者提供了對生產系統和資料的直接存取。
  • 不安全的加密實作： 弱加密演算法（DES、MD5）、硬編碼加密金鑰、不正確的初始化向量或金鑰長度不足會損害資料的機密性和完整性。
  • 緩衝區溢位和記憶體損毀： C/C++ 應用程式中的不安全記憶體操作可以實現任意程式碼執行、權限提升和拒絕服務攻擊。
  • 業務邏輯缺陷： 繞過身份驗證、授權間隙、競爭條件和輸入驗證不足會導致權限升級、欺詐和未經授權的訪問。
  • 基礎結構即程式碼 （IaC） 設定錯誤： 不安全的 Terraform、ARM 範本或 Kubernetes 資訊清單會部署易受攻擊的基礎結構，這些基礎結構具有過於寬鬆的存取、缺少加密或公開的管理端點。

沒有自動化的靜態應用程式安全測試（SAST），漏洞就會累積成技術債務，延長其存在時間，並使在生產階段的修復成本變得高昂。

MITRE ATTCK(&C)

  • 初始存取（TA0001）：利用面向公眾應用程式（T1190）的注入漏洞或應用程式程式碼中的驗證繞過進行攻擊。
  • 執行 （TA0002）：為進行用戶端執行攻擊（T1203），濫用用戶端弱點，例如 XSS 或不安全的反序列化。
  • 認證存取 （TA0006）：來自密碼存放區 （T1555） 的認證，可從原始程式碼、組態檔或編譯的二進位檔擷取硬式編碼認證。
  • 權限提升（TA0004）：利用緩衝區溢位或記憶體損毀來進行權限提升（T1068）以獲取更高存取權。

DS-4.1：實作多掃描器 SAST 管線

整合到每個建置中的全面靜態應用程式安全測試，可在程式碼層級漏洞到達生產環境之前及早偵測它們。 現代應用程式使用多種語言、框架和基礎設施即程式碼，需要專門的分析器，沒有單一掃描器可以偵測所有漏洞類別。 多層 SAST 策略將專用工具與自動執行和品質門相結合，確保全面覆蓋，同時在偵測到安全問題時為開發人員提供即時回饋。

使用以下元件實施自動化安全測試：

  • 實施多層掃描策略： 將自動化靜態應用程式安全測試嵌入到每個建置中，以便在程式碼進入生產環境之前偵測漏洞。 實作結合多個專用掃描器的多層 SAST 策略 - 沒有單一工具可以偵測所有弱點類別，因此全面涵蓋範圍需要特定語言的分析器 （Python、JavaScript、C/C++）、基礎結構即程式碼掃描器 （Terraform、ARM 範本、Kubernetes 清單）、秘密偵測，以及複雜資料流弱點的語意程式碼分析。

  • 使用品質閘道設定自動執行： 將 SAST 掃描配置為在每個提交和拉取請求時自動執行，在程式碼上下文新鮮時為開發人員提供有關安全問題的即時回饋。 建立以嚴重性為基礎的品質閘道，在偵測到嚴重性或高嚴重性弱點時封鎖合併或部署，防止易受攻擊的程式碼在管道中推進。 將掃描器設定為以標準化格式 （SARIF） 輸出調查結果，從而實現一致的漏洞追蹤、跨工具的重複資料刪除以及與集中式安全儀表板的整合。

  • 部署具有推送保護的秘密掃描： 實作專用秘密掃描，配合推送保護機制，以防止開發人員在提交階段將憑證、API 金鑰、證書或令牌提交到儲存庫。此機制能在提交時即刻檢測和阻止秘密洩漏，而不是在幾週後的稽核審查中發現問題。 支援標準秘密模式 （AWS 金鑰、Azure 權杖、資料庫連接字串） 和自訂組織特定模式，以進行專屬驗證機制。 偵測到秘密時，請立即提供補救指引，包括認證輪替程式和安全替代方案。

  • 使用語意程式碼分析來處理複雜的漏洞： 部署語意程式碼分析工具，例如 GitHub CodeQL ，以執行深度資料流程分析，以識別模式比對掃描器不可見的複雜弱點，例如透過多個函式呼叫進行 SQL 插入、商務邏輯中的驗證略過，或不安全的還原序列化鏈結。 建立針對組織的架構、安全性需求，以及事件回顧中識別的常見弱點模式量身打造的自訂安全性查詢。 透過具有特定行號、漏洞解釋和補救建議的拉取請求註釋，直接將 SAST 檢測結果整合到開發人員的工作流程中。

  • 使用統一平台進行協調：Microsoft Security DevOps Extension 等統一 SAST 平台可以透過單一管道任務協調多個專用掃描器（AntiMalware、Bandit、BinSkim、Checkov、ESLint、Template Analyzer、Terrascan、Trivy），從而跨異質工具生態系統標準化配置管理和結果聚合。

實作範例

一家 SaaS 供應商遭受 SQL 注入攻擊，暴露了數十萬條客戶記錄。 事件後分析揭示了廣泛的程式碼級漏洞，包括存在數月的硬編碼憑證和注入缺陷。

挑戰： 手動程式碼審查僅發現了一小部分漏洞。 開發人員缺乏安全培訓來識別注入缺陷和加密弱點。 在生產部署之前沒有自動掃描。

解決方案方法：

  • 多掃描器 SAST： 使用 CodeQL、ESLint 和 Bandit 部署 Microsoft 安全性 DevOps 延伸模組 ，提供跨語言和弱點類型的全面涵蓋範圍。
  • 秘密保護： 實施 GitHub Advanced Security，包含秘密掃描和推送保護，以防止在提交中洩露憑證。
  • 語義分析： 設定 GitHub CodeQL，並使用自訂查詢來檢測商務邏輯弱點和架構特定的安全性模式。
  • 安全門： 在 Azure Pipelines 中建立管線安全閘，阻止部署具有高度嚴重性的發現項目。

結果： 快速識別並修復廣泛的漏洞。 防止重大安全漏洞進入生產環境。 大幅減少擔保債務。

關鍵性層級

必須具備。

控制項對應

  • NIST SP 800-53 修訂版 5： SA-11、RA-5、SI-2
  • PCI-DSS v4： 6.3.2、6.4.1、11.3.1
  • CIS 控制 v8.1： 16.3、16.6
  • NIST CSF v2.0： PR.IP-2, DE.CM-4
  • ISO 27001：2022 認證： A.8.25、A.8.29
  • SOC 2： CC7.1、CC7.2

DS-5：整合動態應用程式安全測試 （DAST）

安全原則

透過容器化工作負載的容器安全掃描、Web 應用程式和應用程式介面 （API） 的自動化滲透測試，以及驗證、授權和工作階段管理的專門測試，在預生產環境中實施全面的動態安全測試。 執行時期驗證可識別靜態分析無法偵測到的組態弱點及整合弱點。

需要減輕的風險

靜態分析不可見的執行階段弱點會造成嚴重的安全漏洞，攻擊者在部署應用程式後會利用這些漏洞。 沒有全面的 DAST：

  • 部署組態弱點： 錯誤配置的身份驗證提供者、過於寬鬆的 CORS、弱 TLS 配置或缺少安全標頭（CSP、HSTS、X-Frame-Options）能導致源碼審查無法檢測到的攻擊。
  • API 安全漏洞： 具有身份驗證略過、授權失敗、過多資料暴露、缺少速率限制或不安全的直接物件參考 （IDOR） 的 REST 和 GraphQL API 允許未經授權的存取和資料擷取。
  • 身份驗證和授權略過： 會話管理、密碼重設流程、多因素身份驗證實施或基於角色的存取控制邏輯中的缺陷使得權限升級和帳戶接管成為可能。
  • 會話管理漏洞： 可預測的會話令牌、逾時強制執行不足、會話固定漏洞或遺失的令牌撤銷會導致會話劫持和憑證竊取。
  • 環境特定的安全問題： 與資料庫、訊息佇列、外部 API 或第三方服務的整合點會引入開發或隔離測試中不可見的執行階段漏洞。
  • 業務邏輯缺陷： 競爭條件、狀態操縱漏洞、複雜工作流程中的輸入驗證不足或交易完整性問題會導致欺詐和資料操縱。

DAST 會驗證執行時期行為、環境配置及整合安全，提供靜態分析無法涵蓋的檢查範圍。

MITRE ATTCK(&C)

  • 初始存取 （TA0001）：利用執行階段測試發現的身份驗證繞過、注入缺陷或不安全的 API 端點來攻擊面向公眾的應用程式 （T1190）。
  • 認證存取 （TA0006）：暴力攻擊 （T1110） 利用在 DAST 期間發現的速率限制遺漏、弱密碼政策或可預測的會話權杖。
  • 權限提升 （TA0004）：有效帳戶 （T1078） 濫用已部署應用程式中的授權略過或角色操作弱點。
  • 收集 （TA0009）：來自資訊儲存庫 （T1213） 的資料，透過過多的 API 回應、目錄遍歷或不安全的直接物件參考漏洞來擷取敏感資料。
  • 外洩 （TA0010）：透過 Web 服務外流 （T1567），利用 API 安全性漏洞，在不偵測的情況下大規模擷取資料。

DS-5.1：在預生產中實施自動化 DAST

動態應用程式安全測試會驗證執行中應用程式中的安全控制，探索靜態分析無法偵測到的執行階段漏洞。 雖然 SAST 檢查原始程式碼，但 DAST 會測試具有類似生產配置的部署應用程式，以識別部署特定的問題，包括僅在操作環境中出現的身份驗證錯誤配置、授權缺陷和整合安全漏洞。 預生產中的自動化 DAST 可確保在客戶暴露之前進行安全驗證，同時測試針對整合系統的真實攻擊場景。

透過以下功能實作執行階段安全性驗證：

  • 透過執行階段驗證來補充 SAST：透過動態應用程式安全測試來補充靜態分析，以驗證具有類似生產環境的配置執行應用程式的安全性。 雖然 SAST 會識別原始碼中的漏洞，但 DAST 會發現靜態分析不可見的執行時期問題：部署配置弱點（錯誤配置的鑑別提供者、寬鬆的 CORS 原則、遺漏的安全標頭）、環境特定的整合缺陷（資料庫連線安全、已部署環境定義中的 API 授權），以及僅在實際操作條件下顯現的商業邏輯漏洞。

  • 在類似生產環境的預備環境中部署： 在預備環境中部署 DAST 掃描，這些環境會鏡像生產架構、網路拓撲、外部相依關係及配置參數。 自動化 DAST 執行應在部署到預備時觸發，系統地測試身份驗證流程、授權界限、會話管理、輸入驗證、API 安全性以及實際負載和使用模式下的錯誤處理。 這會驗證安全控制在與類似生產的外部系統 （身分識別提供者、資料庫、訊息佇列、第三方 API） 整合時是否正常運作。

  • 實作容器的執行階段監控： 對於容器化工作負載，請實作持續執行階段安全監控，將部署前映像掃描與部署後行為分析相結合。 在部署之前掃描容器映像檔是否有已知漏洞，然後監控正在運行的容器是否有異常網路連線、未經授權的進程執行、檔案系統修改和權限提升嘗試。 分析正常的 Kubernetes 工作負載行為，以偵測指出入侵的偏差，並根據 CIS 基準和安全最佳實務持續評估容器組態。

  • 專注於高風險的攻擊面： 將專門的 DAST 工作重點放在高風險的攻擊面上：REST 和 GraphQL API （測試驗證略過、授權失敗、注入弱點、過多的資料暴露、不安全的直接物件參考）、驗證和工作階段管理 （驗證權杖安全性、逾時強制執行、登出功能、密碼重設流程、多重要素驗證） 和商務邏輯工作流程 （測試競爭條件、狀態操作、交易完整性問題）。 建立 SAST/DAST 關聯工作流程，結合兩種方法的發現，將透過靜態和動態分析確認的漏洞列為最高風險的優先順序。

  • 利用整合平台： 針對容器化環境，Microsoft Defender for Containers 在整個容器生命週期中提供整合式運行時間弱點評估、工作負載配置和威脅偵測功能。

實作範例

一家電子商務公司發現了支付 API 中的身份驗證繞過問題，允許未經授權的折扣。 SAST 錯過了運行時配置缺陷，該缺陷僅在具有外部身份驗證提供者的部署環境中表現出來。

挑戰： SAST 偵測到程式碼漏洞，但遺漏了執行階段組態問題和 API 授權缺陷。 生產部署組態與開發不同，會造成靜態分析不可見的安全漏洞。

解決方案方法：

  • 自動 DAST 掃描： 在預生產環境中部署 OWASP ZAP ，測試具有類似生產配置的已部署應用程式。
  • 容器執行階段保護： 已實作適用於 容器的 Microsoft Defender 進行執行階段安全性監視和弱點評量。
  • API安全測試： 設定了專門的 API 測試，以驗證已部署的 REST 和 GraphQL 端點中的身份驗證、授權和資料驗證。
  • SAST/DAST 相關性： 建立弱點關聯工作流程，結合靜態和動態發現，以進行全面的安全驗證。

結果： 發現 SAST 遺漏的執行階段漏洞，包括身份驗證繞過和 API 授權缺陷。 透過生產前偵測來防止安全事件。

關鍵性層級

必須具備。

控制項對應

  • NIST SP 800-53 修訂版 5： SA-11、CA-8、RA-5
  • PCI-DSS v4： 6.4.2、11.3.2
  • CIS 控制 v8.1： 16.7、16.8
  • NIST CSF v2.0： DE.CM-4, PR.IP-12
  • ISO 27001：2022 認證： A.8.29、A.8.30
  • SOC 2： CC7.1、CC7.3

DS-6：保護工作負載生命週期

Azure Policy： 請參閱 Azure 內建政策定義：DS-6。

安全原則

透過容器工作負載的容器登錄庫和安全掃描、虛擬機器（VM）工作負載的 golden image 管理和自動建置，以及自動隔離的持續漏洞掃描，實現具有全面映像安全性的不可變基礎架構。 驗證加密簽章、維護最少的基底映像，並在整個工作負載生命週期中強制執行安全基準。

需要減輕的風險

不安全的工作負載生命週期管理允許易受攻擊或受損的成品到達生產環境，從而創建對手系統地利用的持續攻擊媒介。 如果沒有完整的工作負載安全性：

  • 易受攻擊的生產 VM 映像： 未修補的作業系統基準或設定錯誤的黃金映像會在所有已部署的 VM 之間傳播弱點。
  • 未修補的易受攻擊基礎映像： 建立在受 CVE 影響的基礎 （Log4Shell、Heartbleed、OpenSSL） 上的容器會使工作負載受到利用和逃逸。
  • 過時的易受攻擊成品：未經掃描的映像檔與套件會讓漏洞風險（CVE）累積，因此擴大攻擊範圍。
  • 影像驗證不足： 缺乏加密簽名和來源驗證使對手能夠用包含後門或惡意軟體的受損版本替換合法圖像。
  • 臃腫的攻擊面： 包含不必要的套件、開發工具或偵錯公用程式的容器映像會增加漏洞暴露，並為攻擊者提供額外的攻擊工具。
  • 缺少安全性基準： 在未符合 CIS 基準測試、安全性強化或最低權限配置的情況下部署的 VM 和容器映像會在深度防禦中造成可利用的差距。

受損的成品會成為持續的攻擊媒介，有助於橫向移動，並且對防禦者來說似乎是合法的。

MITRE ATTCK(&C)

  • 初始存取 （TA0001）：攻擊面向公眾的應用程式（T1190），利用應用程式容器或 Web 服務中未修補的漏洞。
  • 執行 （TA0002）：部署容器 （T1610） 部署因映像驗證不足而看似合法的惡意容器。
  • 權限提升 （TA0004）：利用容器漏洞逃逸到主機 （T1611） 以突破容器隔離並危害主機系統。
  • 橫向移動（TA0008）：利用遠端服務（T1210）在被入侵映像部署的易受攻擊的 VM 或容器間進行樞紐轉移。

DS-6.1：實作容器映像檔安全性

容器和 VM 映像代表關鍵的攻擊面，需要在其整個生命週期中進行全面的安全控制。 易受攻擊的基礎映像會將弱點傳播到每個已部署的執行個體，從而放大整個基礎設施的影響。 以與原始程式碼相同的安全嚴謹性（包括掃描、簽署和安全儲存）來處理工作負載成品，可確保組織僅部署經過驗證、值得信賴的映像，同時防止攻擊者利用已知漏洞或替換惡意映像。

透過下列實踐保護工作負載成品：

  • 建立不可變的基礎設施原則： 將容器映像和 VM 映像視為重要成品，需要相同的安全性嚴謹性，因為原始程式碼易受攻擊的基底映像會將弱點傳播到每個已部署的執行個體。 建立不可變的基礎架構原則，其中工作負載成品建置一次、全面掃描、加密簽署，並在不進行修改的情況下部署，以確保整個生命週期的一致性和可追溯性。

  • 將最小基底映像與多階段組建搭配使用： 對於容器工作負載，從僅包含基本執行階段元件的最小基礎映像開始實施分層映像安全性，與完整的作業系統映像相比，可大幅減少攻擊面。 使用多階段建置將建置時相依性與執行階段映像分離，編譯並建置功能豐富的映像，然後僅將最終成品複製到最小的執行階段映像，從而消除開發工具、套件管理器和建置相依性，這些相依性會增加漏洞暴露，並為攻擊者提供利用工具。

  • 將自動掃描與隔離策略整合： 將自動化漏洞掃描集成到映像構建管道中，該管道在註冊表存儲之前掃描每個映像，檢查全面的 CVE 數據庫，並在新漏洞披露時不斷重新掃描存儲的映像。 實作自動化隔離原則，以防止部署具有嚴重或高嚴重性弱點的映像檔，例外工作流程需要安全小組核准和記錄風險接受。 在安全性修補程式發佈時，使用自動管線觸發器建立基礎映像重新整理原則，確保映像不會隨著時間的推移累積 CVE。

  • 強制執行加密簽名和驗證： 透過在每個階段進行加密簽署和驗證來強制執行映像完整性 - 在建置時簽署映像、在部署前驗證簽章，以及自動拒絕未簽署或竄改的映像。 這可以防止圖像替換攻擊，即對手將合法圖像替換為包含後門的受損版本。 將映像儲存在安全的容器登錄中，具有網路存取控制 （私人端點、虛擬網路整合）、限制誰可以推送/提取映像的角色型存取原則，以及所有登錄作業的完整稽核記錄。

  • 維護 VM 的強化黃金映像： 對於 VM 工作負載，請維護具備符合 CIS 基準的強化基礎映像的集中化黃金映像儲存庫，這些映像會定期進行安全性修補和合規性驗證。 實作自動化映像建置管道，其中包含安全性更新、移除不必要的服務、強制執行最低權限設定，以及依定義的排程產生新映像，而不是修補執行中的系統。

  • 利用整合安全平台：Azure 容器登錄與適用於容器的 Microsoft Defender 整合之類的解決方案，可提供自動化掃描、隔離工作流程、內容信任，以及具有一致安全性原則的多區域複寫。

實作範例

一個物流組織部署了容器應用程式，其中包含未修補的基礎映像，其中包含嚴重的遠端程式碼執行漏洞。 攻擊者在部署後不久就利用了該漏洞，損害了運輸數據。

挑戰： 大量容器映像，無需漏洞掃描。 幾個月前建置的映像檔累積了多項 CVE，包括嚴重漏洞。 未進行驗證以防止惡意圖像替換。

解決方案方法：

  • 容器登錄安全性： 在部署之前，使用弱點掃描隔離具有高嚴重性 CVE 的映像，實作 Azure Container Registry 。
  • 強化的 VM 映像： 部署了 Azure 共用映像庫，內含符合 CIS 基準的 VM 映像以支援受管制的工作負載。
  • 運行時保護： 已設定適用於 容器的 Microsoft Defender 以進行持續的威脅偵測和漂移監視。
  • 工件完整性： 透過加密簽名和驗證，確保映像檔在整個生命週期中的真實性。

結果： 封鎖生產部署中的易受攻擊映像。 大幅減少每個映像檔中的容器 CVE 數量。 透過簽名驗證防止影像替換攻擊。

關鍵性層級

必須具備。

控制項對應

  • NIST SP 800-53 修訂版 5： CM-2、CM-3、SI-2、SI-7、RA-5
  • PCI-DSS v4： 6.2.4、6.3.3、11.3.1
  • CIS 控制 v8.1： 4.1、7.3、7.4
  • NIST CSF v2.0： PR.IP-1，PR.IP-3，DE.CM-8
  • ISO 27001：2022 認證： A.8.9、A.8.31、A.8.32
  • SOC 2： CC7.2、CC8.1

DS-7：實作 DevOps 記錄和監視

安全原則

透過稽核串流實作全面的 DevOps 活動記錄，並整合至集中式安全資訊和事件管理 （SIEM） 平台，以進行安全分析、即時威脅偵測和自動回應。 建立行為分析、異常偵測和安全指標，以實現快速事件回應並維護合規性稽核追蹤。

需要減輕的風險

DevOps 日誌記錄和監控不足會造成嚴重盲點，對手利用這些盲點在未被發現的情況下進行操作、建立持久性以及洩露敏感程式碼或憑證。 缺乏全面能見度：

  • 未偵測到的管道入侵： 攻擊者修改 CI/CD 管道以注入惡意程式碼、竊取機密或建立後門，而不會因審計日誌記錄缺失或不足而觸發警報。
  • 修改程式碼或基礎結構的內部威脅： 惡意內部人員或受損帳戶在未被發現的情況下對原始程式碼、基礎設施定義或部署配置進行未經授權的變更。
  • 缺乏全面的審計追蹤： 缺乏詳細的活動日誌會阻止在安全事件發生時進行取證調查、影響評估和根本原因分析，從而延長停留時間並增加違規影響。
  • 延遲事件回應： 當安全團隊缺乏即時警報、異常偵測和 DevOps 安全事件的自動關聯時，平均偵測時間 （MTTD） 會從幾小時延長到幾週。
  • 合規性稽核失敗： 如果沒有集中的 DevOps 監控，就無法滿足強制執行全面稽核追蹤、變更追蹤和存取日誌記錄的監管要求（SOX、PCI-DSS、HIPAA、ISO 27001）。
  • 權限提升盲目症： 未經授權的權限提升、建立後門帳戶或修改存取控制，如果沒有行為分析和權限監控，就會在未被發現的情況下進行。

日誌記錄差距隱藏了高權限開發路徑中的惡意管道變更、權限提升和持續存取嘗試。

MITRE ATTCK(&C)

  • 防禦規避 （TA0005）：削弱防禦 （T1562），停用稽核日誌記錄、安全掃描步驟或監控代理程式，以便在盲點中運作，以及指標刪除 （T1070），清除稽核日誌或管道執行歷史，以隱藏惡意活動。
  • 持續性 （TA0003）：帳戶操作 （T1098） 建立其他服務主體、個人存取權杖或 SSH 金鑰，而不會偵測到。
  • 集合 （TA0009）：來自資訊存放庫 （T1213） 的資料，透過管線存取竊取原始程式碼、秘密或智慧財產權。
  • 認證存取 （TA0006）：不安全的認證 （T1552） 會從管線記錄或執行歷程記錄中收集公開的秘密。

DS-7.1：實作 DevOps 平台的稽核日誌

具有生產基礎設施和敏感源代碼特權訪問權限的 DevOps 平台需要全面的安全監控，以檢測對手活動和內部威脅。 審計日誌記錄差距使惡意行為者能夠長時間在未被發現的情況下進行操作，而集中式日誌聚合則能夠與更廣泛的安全遙測相關聯，從而揭示複雜的攻擊鏈。 即時行為分析可識別孤立事件中不可見的可疑模式，將原始稽核資料轉換為可操作的安全情報。

透過以下功能建立全面的 DevOps 安全監控：

  • 擷取全面的安全相關活動： 建立完整的稽核記錄，以擷取所有與安全性相關的 DevOps 活動：使用者驗證和授權事件、原始程式碼認可和分支作業、管線建立和修改、部署執行、秘密存取、權限變更、服務主體建立和管理動作。 DevOps 平台擁有對生產基礎設施的特權訪問權限，敏感的代碼記錄差距使對手和惡意內部人員能夠長時間在未被發現的情況下運行。

  • 將日誌即時轉送至集中式 SIEM：將稽核記錄即時轉送至集中式 SIEM 平台，而不是依賴 DevOps 平台原生保留 （通常為 90 天），從而實現長期鑑識分析、合規性報告，以及與其他系統安全事件的關聯。 透過結構化格式 （JSON） 的標準化通訊協定 （/azure Event Hubs、syslog） 將記錄串流至安全性作業中心，以啟用自動剖析、分析和警示，而不需要手動記錄檢閱。

  • 部署行為分析和異常偵測： 在 DevOps 稽核資料上實作行為分析和異常偵測，以識別個別事件中不可見的可疑模式：下班後管線修改、敏感性存放庫的異常存取、快速權限提升、服務主體建立後接著可疑部署、從非預期位置執行管線，或異常的秘密存取模式。 為使用者和服務建立基準行為設定檔，對可能表示入侵或內部威脅的統計顯著偏差發出警報。

  • 設定高風險活動的自動警示： 設定高風險活動的自動警示，並立即通知安全性小組：生產部署失敗、受保護分支中的管線修改、新的服務主體建立、權限提高許可權事件、停用安全性掃描步驟、稽核記錄轉送設定變更，或嘗試從未經授權的管線存取秘密。 實作以嚴重性為基礎的升級，確保關鍵警示立即到達安全作業，同時批次處理例行事件進行分析。

  • 與更廣泛的安全遙測整合： 將 DevOps 稽核記錄與 SIEM 平台中更廣泛的安全性遙測整合，以與端點偵測、網路安全、身分識別事件和威脅情報摘要建立關聯。 這可讓您偵測複雜的攻擊鏈結，其中 DevOps 入侵是多階段作業中的一個階段，例如，將網路釣魚憑證與後續管道修改和異常雲端資源佈建相關聯。

  • 利用整合的 SIEM 平台：Azure DevOps 稽核串流與 Microsoft Sentinel 整合之類的平臺提供即時記錄轉送、DevOps 威脅的預先建置偵測規則、用於調查的安全性活頁簿，以及自動化回應協調流程。

實作範例

一家製造組織在前承包商修改 CI/CD 管道並將後門程式碼注入生產應用程式時，發現了內部威脅。 由於審計記錄不足，該事件幾個月來仍未被發現。

挑戰： 沒有集中記錄 DevOps 活動。 管道修改和特權存取變更未受到監控。 法醫調查因缺乏審計線索而受到阻礙。 由於變更追蹤不足，合規性審計失敗。

解決方案方法：

  • 集中式稽核記錄： 已啟用 Azure DevOps 稽核串流 將事件轉送至 Microsoft Sentinel ，以進行安全性分析和長期保留。
  • 行為分析： 實施異常檢測，識別異常存取模式、下班後管道修改以及指示內部威脅的權限升級。
  • 自動警報： 針對可疑活動設定警示，包括未經授權的生產部署和服務主體建立路由傳送至安全性作業。
  • 合規報告： 創建自動審計跟踪生成，通過全面的變更跟踪滿足監管要求。

結果： 快速偵測並防止後續未經授權的管道修改。 透過全面的稽核追蹤，大幅縮短事件調查時間。 實現了符合記錄在案的變更管理標準。

關鍵性層級

應該有。

控制項對應

  • NIST SP 800-53 修訂版 5： AU-2、AU-3、AU-6、AU-12、SI-4
  • PCI-DSS v4： 10.2.1、10.2.2、10.3.4
  • CIS 控制 v8.1： 8.2、8.5、8.11
  • NIST CSF v2.0： DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001：2022 認證： A.8.15、A.8.16
  • SOC 2： CC7.2、CC7.3
  • Last updated on