DoD 零信任 戰略與藍圖概述國防部元件和國防工業基地（DIB）合作夥伴根據 零信任 原則採用新的網路安全架構的路徑。 零信任 可消除傳統周邊和信任假設，以提升安全性、用戶體驗和任務效能的更有效率的架構。
本指南針對 DoD 零信任 功能執行藍圖中的 152 個 零信任 活動提供建議。 這些區段會對應 DoD 零信任 模型的七個支柱。
使用下列連結來移至指南的章節。
3 應用程式和工作負載
本節針對應用程式和工作負載支柱中的 DoD 零信任 活動Microsoft指導方針和建議。 若要深入瞭解，請參閱使用 零信任 保護應用程式。
注意
本節中的建議與 DoD Enterprise DevSecOps 參考設計草稿一致。
3.1 應用程式清查
Microsoft Entra ID 是應用程式和雲端平台的識別提供者（IdP），而不只是Microsoft 365 和 Azure。 Microsoft Entra 識別碼包含入口網站和 RESTful API，以擷取整合式應用程式的清單。 適用於雲端的 Microsoft Defender Apps 是 Microsoft Defender 全面偵測回應 的元件，具有探索、清查和封鎖未經批准之應用程式的功能。
| DoD 活動描述和結果 | Microsoft指引和建議 |
|---|---|
Target3.1.1 應用程式/代碼識別DoD 組織會建立已核准應用程式和程式碼的清查（例如原始程式碼、連結庫等）。 每個組織將至少在清查中追蹤支援性（例如作用中、舊版等）和託管位置（亦即雲端、內部部署、混合式等）。 結果： - 元件已識別應用程式，並分類為舊版、虛擬化的內部部署和裝載的雲端 |
Microsoft Entra 識別碼 使用 Microsoft Entra 系統管理中心下載Microsoft Entra 已註冊的應用程式清單。 選取頂端功能區中的 [下載]。 - 應用程式資源類型 如果您的組織使用 Active Directory 同盟服務 （AD FS），請部署 Microsoft Entra Connect Health。 使用應用程式活動報告來探索AD FS應用程式。 - 使用 Connect Health - Application 活動報告 監視 AD FS Microsoft Defender 弱點管理 使用 Defender 弱點管理中的軟體清查，以檢視組織中的軟體。 - 軟體清查 適用於雲端的 Microsoft Defender 應用程式 在 適用於雲端的 Defender Apps 中設定 Cloud Discovery，以取得使用者存取的應用程式快照集。 - 設定 Cloud Discovery- 調查應用程式 Microsoft Intune 探索到的應用程式 Intune 探索到的應用程式 是由租使用者中已註冊的 Intune 裝置偵測到。 這是租用戶的軟體清查。 在公司裝置上，不會收集此報表的應用程式或受控應用程式。 - 探索到的應用程式 Azure DevOps 使用此服務來保護套件管理。 開發人員會在一個地方共用程式碼及管理套件。 - Azure Artifacts- Azure GitHub 存放庫 |
3.2 保護軟體開發與整合
GitHub 進階安全性 （GHAS） 和 GitHub Actions 等 GitHub 功能可協助您建立 零信任 軟體開發和部署實務。 GitHub Enterprise Cloud 與 Microsoft Entra ID 整合，以使用 Microsoft Entra ID 控管 管理權利，並使用條件式存取原則保護存取權。
開發人員可以使用Microsoft驗證連結庫 （MSAL） 將應用程式與Microsoft Entra標識符整合。 如需詳細資訊，請參閱驗證 零信任的使用者。
| DoD 活動描述和結果 | Microsoft指引和建議 |
|---|---|
Target3.2.1 組建 DevSecOps Software Factory Pt1DoD 企業會為新式 DevSecOps 程式和 CI/CD 管線建立基礎標準。 這些概念會套用在可符合未來應用程式安全性需求的 DoD 組織標準化技術堆疊中。 在弱點管理計劃活動之後，全企業弱點管理計劃會與 CI/CD 管線整合。 結果： - 開發 DevSecOps 的數據/服務標準 - CI/CD 管線功能完整且測試成功 - 弱點管理計劃已正式就緒並運作 |
GitHub Actions GitHub Actions 使用持續整合和持續傳遞 （CI/CD） 將部署管線自動化。 - GitHub Actions GitHub 進階安全性 使用 GitHub 和 Azure DevOps 的 GitHub 進階安全性 來增強程式代碼和開發程式的安全性。 - Azure DevOps的進階安全性進階安全性- Microsoft Entra SSO，並使用 Microsoft Entra ID 為 Git 工具布 建單一登錄 （SSO）。 - SSO 與 GitHub Enterprise Cloud 組織 - SSO 整合與 GitHub Enterprise Server - 將組織連線到 Microsoft Entra ID 若要深入瞭解適用於 Azure 和其他雲端的 DevSecOps，請參閱 DoD Cheif 資訊官 （CIO） 連結庫。 |
Target3.2.2 組建 DevSecOps Software Factory Pt2DoD 組織會使用其核准的 CI/CD 管線來開發大部分的新應用程式。 任何例外狀況都會遵循標準化的核准程式，以舊版方式進行開發。 DevSecOps 程式也可用來開發所有新的應用程式，並更新現有的應用程式。 持續驗證函式會整合至 CI/CD 管線和 DevSecOps 程式，並與現有應用程式整合。 結果： - 應用程式開發會遷移至 CI/CD 管線 - 持續驗證程式/技術已實作且使用 中- 應用程式開發已移轉至 DevSecOps 程式和技術 |
GitHub 進階安全性 使用 GitHub 進階安全性 掃描程式代碼相依性和弱點。 設定定期組建以評估程式代碼品質。 - 使用基礎結構即程序代碼 （IaC） 搭配 Azure Resource Manager 和 Bicep 範本，掃描 Azure 布建雲端基礎結構中的進階安全性 - CodeQL 程式代碼掃描- 安全供應鏈 Bicep。 - Bicep 適用於雲端的 Microsoft Defender 針對具有應用程式工作負載的訂用帳戶啟用 適用於雲端的 Defender 工作負載保護。 - 保護適用於 DevOps 的Defender Microsoft Defender 使用適用於DevOps 的Defender來監視 Azure DevOps（ADO） 和 GitHub 中管線的安全性和警示。 - 適用於 DevOps 的 Defender |
Target3.2.3 自動化應用程式安全性與程式代碼補救 Pt1跨 DoD 企業實作應用程式安全性的標準化方法，包括程式代碼補救。 此活動的第一部分（1）包括整合安全 API 閘道與使用 API 或類似呼叫的應用程式。 程式代碼檢閱會以有條理的方法進行，容器及其基礎結構的標準化保護已就緒。 此外，第三方管理基礎結構的任何無伺服器函式，例如平臺即服務，都會利用適當的無伺服器安全性監視和回應功能。 程式代碼檢閱、容器和無伺服器安全性函式會適當地整合到 CI/CD 和/或 DevSecOps 程式中。 結果： - 安全 API 閘道可運作，而且大部分的 API 呼叫都是透過閘道 傳遞-應用程式安全性函式（例如程式代碼檢閱、容器和無伺服器安全性）會實作為 CI/CD 和 DevSecOps 的一部分 |
Azure 應用程式閘道 具有 Azure 應用程式閘道 和 Web 應用程式防火牆 的可公開存取 Web 應用程式和 API。 - Web 應用程式防火牆 Microsoft Entra ID 應用程式 Microsoft Entra ID 是 Web 應用程式和 API 存取的授權閘道。 使用 Microsoft Entra 公開已註冊應用程式的 API。 在 Azure App 服務 和 Azure Functions 中使用內建的驗證和授權 （Easy Auth）。 針對 Microsoft Entra ID-unaware API，請在 Azure API 管理中使用 OAuth 授權。 - 設定應用程式以在 Azure App 服務 和 Azure Functions 中公開 Web API - 驗證和授權，並授權 API GitHub 進階安全性使用 GitHub 和 Azure DevOps 的 GitHub 進階安全性。 - 請參閱 3.2.1 中的Microsoft指引。 Microsft 適用於雲端的 Defender 使用 API 工作負載的 Azure 訂用帳戶啟用 適用於雲端的 Defender 工作負載保護。 請參閱 3.2.2 中的Microsoft指引。 |
Advanced3.2.4 自動化應用程式安全性與程式代碼補救 Pt2DoD 組織會遵循微服務等最佳做法，將內部開發與受控服務的方法現代化。 當探索到安全性問題時，這些方法可讓每個微服務中的程式碼變更更快速，以啟用更具彈性且安全的架構。 在 DoD Enterprise 中，進一步提升安全性補救活動，並在發行程式期間納入容器的運行時間安全性功能、自動化易受攻擊的連結庫更新和自動化 CI/CD 核准。 結果： - 安全 API 閘道可運作，且大部分 API 呼叫都通過閘道 傳遞-服務會遵循服務導向架構 （SOA） - 安全性補救活動 （例如運行時間安全性、連結庫更新、發行核准）完全自動化 |
完成活動 3.2.2 和 3.2.3。 |
3.3 軟體風險管理
GitHub Actions 可協助自動化、自定義和執行 DevSecOps 的軟體開發工作流程。 使用 GitHub Actions，產生軟體材料帳單 （SBOM）、分析程式代碼，以及掃描供應鏈和相依性弱點。 若要深入瞭解 GitHub Actions，請參閱 GitHub Actions。
| DoD 活動描述和結果 | Microsoft指引和建議 |
|---|---|
Target3.3.1 已核准的二進位檔/程序代碼DoD 企業使用最佳做法方法，以有條不紊的方法管理已核准的二進位檔和程序代碼。 這些方法包括供應商採購風險管理、核准的存放庫使用方式、材料供應鏈風險管理帳單，以及業界標準 弱點管理。 結果： - 針對已核准的來源 評估及識別的供應商採購風險- 儲存機制和開發小組 所建立的更新通道 - 針對應用程式建立材料帳單，以識別來源、支援性和風險狀態 - 業界標準 （DIB） 和已核准的弱點資料庫會提取到 DevSecOps 中使用 |
GitHub Actions 標準化 DevSecOps 程式，以持續整合和持續傳遞 （CI/CD） 管線來產生軟體材料帳單 （SBOM）。 - 產生材料的軟體 帳單 使用 GitHub Dependabot 和 CodeQL 將安全性檢查和掃描相依性弱點自動化。 - 掃描安全供應鏈 的 CodeQL 程式代碼 - Windows Defender 應用程控使用 Windows Defender 應用程控 ，以防止不受信任的程式代碼在受控端點上執行。 - 應用程控和應用程式保險箱 - 平台程式代碼完整性 |
Target3.3.2 弱點管理計劃 Pt1DoD 企業會與組織合作，建立和管理弱點管理計劃。 該計劃包含所有組織所同意的原則和標準。 開發計劃至少包含根據 DoD 應用程式/服務之公用弱點的追蹤和管理。 組織會與主要項目關係人建立 弱點管理 小組，其中會遵循企業原則和標準討論和管理弱點。 結果： - 弱點管理小組已就緒，具有適當的專案關係人成員資格 - 弱點管理原則和程式已就緒，並同意 w/ 項目關係人 - 正在利用弱點的公用來源來追蹤 |
威脅和弱點管理 VM功能可啟用資產可見度和智慧型手機評定。 TVM 具有端點和伺服器的內建補救工具。 搭配 弱點管理 程式使用TVM。 - Microsoft Defender TVM Microsoft雲端安全性基準 檢閱Microsoft 線上服務 如何 弱點管理。 - TVM 概觀 - 狀態和 弱點管理 |
Target3.3.3 弱點管理計劃 Pt2程式是在 DoD 企業層級建立，以管理 DoD 維護/操作服務中公開和私人存取的弱點洩漏。 DoD 組織會展開 弱點管理 計劃，以追蹤和管理已關閉的弱點存放庫，例如 DIB、CERT 和其他專案。 結果： - 受控制（例如 DIB、CERT）弱點來源正用於追蹤 - 弱點管理計劃有一個程式可接受受控服務的外部/公開披露 |
威脅與弱點管理使用 Microsoft Defender TVM 中的弱點頁面，識別並排定組織裝置和伺服器上所發現弱點的優先順序。 - 組織中的 弱點使用TVM易受攻擊的裝置報告來追蹤補救活動。 - 易受攻擊的裝置報告 |
Target3.3.4 持續驗證DoD 組織會針對應用程式開發實作持續驗證方法，其中會進行平行部署，並與核准的環境層級整合（例如使用者驗收測試、生產環境）。 識別無法將持續驗證整合到 CI/CD 程式中的應用程式，並使用方法視需要提供例外狀況。 結果： - 更新的應用程式會部署在即時和/或生產環境中 - 標示淘汰和轉換的應用程式已解除委任 - 持續驗證工具會實作並套用至 CI/CD 管線 中的程式碼- 識別需要持續驗證的程式代碼，並建立驗證準則 |
Azure Chaos Studio使用 Azure Chaos Studio 來驗證工作負載。 - 持續驗證 GitHub 進階安全性 使用 DoD Enterprise DevSecOps 參考設計中 弱點管理 的 GitHub 功能和動作。 請參閱 3.2.1 中的Microsoft指引。 |
3.4 資源授權和整合
條件式存取是 Microsoft Entra 識別碼中的 零信任 原則引擎。 使用 Microsoft Entra ID 連接您的應用程式工作負載。 使用 Microsoft Entra ID 控管 以條件式存取原則管理權利和安全登入。 原則會使用安全性屬性，例如裝置健康情況、會話詳細數據和風險來做出調適型存取決策。 Microsoft Entra ID、Azure Resource Manager 和 CI/CD 管線在 Azure 中授權資源部署。
| DoD 活動描述和結果 | Microsoft指引和建議 |
|---|---|
Target3.4.1 資源授權 Pt1DoD 企業會針對組織的資源授權方法（例如軟體定義周邊）進行標準化。 資源授權閘道至少會與身分識別和裝置整合。 組織會部署核准的資源授權網關，並針對外部面向的應用程式/服務啟用。 其他無法移轉的應用程式和無法移轉的應用程式會識別為例外狀況或解除委任。 結果： - 資源授權閘道適用於外部面向的應用程式 - 與身分識別和裝置 整合的資源授權原則- 轉換標準的全企業指導方針會傳達給項目關係人 |
Microsoft Entra 識別碼 Microsoft Entra 是應用程式資源的授權閘道。 整合現代化和舊版應用程式的 SSO 與 Microsoft Entra。 請參閱 user 中的Microsoft指引 1.2.4。 Microsoft Entra ID 控管 使用 Microsoft Entra ID 控管 應用程式角色來存取應用程式。 使用靜態成員資格、動態Microsoft Entra 安全組或權利管理存取套件，將使用者指派給應用程式角色。 - 將應用程式角色新增至應用程式，並在令牌- 角色型訪問控制 條件式存取 中使用條件式存取原則來動態授權、控制或封鎖應用程式存取。 請參閱 user 中的Microsoft指引 1.8.3 和 Device 中的 2.1.4。 Azure 應用程式閘道 具有 應用程式閘道和 Web 應用程式防火牆 的可公開存取 Web 應用程式和 API。 請參閱Microsoft指引 3.2.3。 |
Target3.4.2 資源授權 Pt2資源授權閘道會用於所有可能的應用程式/服務。 無法使用閘道的應用程式已解除委任，或使用以風險為基礎的方法除外。 授權會進一步與 CI/CD 管線整合，以進行自動化決策。 結果： - 資源授權閘道會用於所有應用程式 - 資源授權與 DevSecOps 和 CI/CD 整合以進行自動化功能 |
Microsoft Entra 工作負載 ID 使用工作負載身分識別同盟來設定使用者指派的受控識別，或應用程式註冊以信任來自外部識別提供者 （IdP） 的令牌。 使用 GitHub Actions 工作流程的同盟工作負載身分識別。 - 工作負載身分識別同盟 Azure API 管理 使用 Azure API 管理 來管理、授權及公開 Azure 上和外部裝載的服務作為 API。 - Azure API 管理 |
Target3.4.3。SDC 資源授權 Pt1DoD 企業針對程式代碼型計算管理（亦即軟體定義計算）提供遵循業界最佳做法的標準化方法。 使用以風險為基礎的方法會使用已核准的程式代碼連結庫和套件集來建立基準。 DoD 組織會使用核准的程式代碼/二進位檔活動，以確保已識別應用程式，且無法支援此方法。 識別可支援新式軟體型設定和管理方法的應用程式，並開始轉換。 使用方法識別和允許透過例外狀況來識別無法遵循軟體型設定和管理方法的應用程式。 結果： - 無法更新為使用已核准二進位檔/程式代碼的應用程式會標示為淘汰並建立 轉換計劃- 已識別的應用程式沒有核准的二進位檔，且程式代碼會更新為使用已核准的二進位檔/程序代碼 - 整個企業的轉換標準指引會傳達給項目關係人 |
遵循安全性開發生命週期和已發佈的最佳做法，保護開發設計、開發和部署 Azure 應用程式。 - 安全開發 - 基礎結構即程式代碼 Azure 原則 做為程式代碼- 工作流程 Microsoft Entra ID 使用應用程式驗證和授權 Microsoft 身分識別平台。 - 將應用程式和驗證 Azure Migrate 遷移 至新式應用程式平臺，例如 Azure Kubernetes Service （AKS） 和 App Service 容器。 - 將工作負載遷移至新式應用程式平臺- 評估要移轉至 AKS - 的 ASP.NET 應用程式 ASP.NET 評估移轉至 Azure App 服務 |
Target3.4.4 SDC 資源授權 Pt2支援軟體型設定和管理的應用程式已轉換為生產/實時環境，且處於正常作業中。 如果可能的應用程式不支援軟體型設定和管理，則會解除委任。 結果： - 更新的應用程式會部署在即時和/或生產環境中 - 標示淘汰和轉換的應用程式已解除委任 |
使用 Azure Migrate：應用程式容器化工具，Azure Migrate 容器化並移轉 ASP.NET 應用程式和 Java Web 應用程式。 解除委任無法現代化的應用程式。 - ASP.NET 應用程式容器化和移轉至 AKS- ASP.NET 應用程式容器化，以及移轉至 Azure App 服務- Java Web 應用程式容器化，以及移轉至 AKS - Java Web 應用程式容器化，並移轉至 Azure App 服務 |
Advanced3.4.5 擴充資源授權 Pt1的屬性來自來源的初始屬性，例如使用者和實體活動監視、微分割服務、DLP 和數據管理 （DRM） 會整合到資源授權技術堆疊和原則中。 識別並規劃後續整合的任何其他屬性。 屬性可用來建立使用者、非人員實體 （NPE） 和允許授權決策的裝置的基本風險狀態。 結果： - 大部分的 API 呼叫都是通過安全 API 閘道 - 資源授權接收來自 Analytics Engine 的數據 - 授權原則會納入識別的屬性來進行授權決策 - 識別要用於初始擴充的屬性 |
Microsoft Entra 應用程式 使用 Microsoft Entra 識別碼來授權新式應用程式和 API。 部署 Microsoft Entra 應用程式 Proxy 和已啟用 Azure Arc 的伺服器，以將 entra 標識符延伸至舊版驗證通訊協定Microsoft。 請參閱 3.1.1 和 3.2.3 中的Microsoft指引。 條件式存取 Microsoft Entra 是資源授權的安全閘道。 條件式存取是授權引擎。 使用使用者、應用程式、使用者、環境條件，包括裝置合規性狀態，設定詳細授權的原則。 - 條件式存取條件式存取- 設計 - 需要符合規範的裝置 動態安全組 根據用戶屬性建立動態安全組。 根據用戶屬性，使用動態群組來設定靜態屬性授權的條件式存取原則範圍。 - 群組- 的動態成員資格 使用者、群組和工作負載身分 識別Microsoft Purview 敏感性資訊類型 定義具有精確數據比對的敏感性資訊類型 （EDM）。 搭配 Microsoft Purview 資訊保護 和 Purview 數據外洩防護 （DLP） 原則使用敏感性資訊類型。 - 以敏感性資訊類型 - 為基礎的數據比對探索和保護敏感性資訊 Microsoft Entra ID 控管 使用 Microsoft Entra ID 控管 以存取具有應用程式角色的應用程式。 將使用者指派給具有靜態成員資格、動態安全組或權利管理存取套件的應用程式角色。 - 新增應用程式角色，並在令牌 - 角色型訪問控制中接收它們 |
Advanced3.4.6。擴充資源授權 Pt2擴充識別屬性的屬性會與資源授權技術和原則整合。 信賴評分會在屬性中導入，以自動化方式建立更進階的授權決策方法。 結果： - 授權原則會納入信賴等級以進行授權決策 - 定義屬性的信賴等級 |
Microsoft Entra ID Protection 使用條件式存取原則集中Microsoft Entra ID Protection 的登入風險和使用者訊號。 根據環境詳細數據和風險等級設定驗證內容，包括建立信賴等級的風險。 - Microsoft Entra ID risk 原則範本：登入風險 - MFA- 驗證內容範例 請參閱使用者中的Microsoft指引 1.3.3。 自定義安全性屬性 管理及指派Microsoft Entra ID 使用者的自定義安全性屬性。 針對動態屬性型訪問控制使用角色指派條件 （ABAC）。 - 自訂安全性屬性 |
Advanced3.4.7。REST API Micro-Segment使用 DoD Enterprise 核准的 API 閘道（s），應用程式呼叫只會允許對特定目的地進行驗證和授權的存取（例如微服務）。 可能的話，API 微分割控制台會整合並感知其他微分割控制台，例如軟體定義的周邊控制器和/或軟體定義網路控制台。 結果： - 已核准的企業 API 會適當地進行微區隔 |
Azure 網路和連線 能力 隔離、篩選和控制跨輸入和輸出流程的網路流量。 在可用的網路界限使用本地化的網路控制來套用深度防禦原則。 遵循 Azure 架構完善的架構。 - 網路和聯機建議分割策略建議- API設計 遵循建議的做法來設計微服務的API。 使用 Microsoft Entra ID 保護及授權 API。 - 微服務 API - 保護 API |
3.5持續監視和持續授權
適用於雲端的 Microsoft Defender 安全性標準會持續評估範圍中的 Azure 訂用帳戶、Amazon Web Services （AWS） 帳戶和 Google Cloud Platform （GCP） 專案，適用於雲端的 Defender 啟用，以符合法規標準。
| DoD 活動描述和結果 | Microsoft指引和建議 |
|---|---|
Advanced3.5.1 持續授權操作 （cATO） Pt1DoD 組織利用環境中的自動化解決方案來標準化控件的監視，並提供識別偏差的功能。 適當的監視和測試會與 DevSecOps 程式整合。 結果： - 控件衍生已標準化且可供自動化 使用- 控件測試已與 DevSecOps 流程和技術整合 |
DoD 首席資訊官 （CIO） 連結庫 將監視和測試整合到 DevSecOps 程式中。 請參閱 DoD Enterprise DevSecOps 參考設計 - DoD CIO 連結庫 適用於雲端的 Microsoft Defender 使用 適用於雲端的 Defender 保護 Azure 和非 Azure 工作負載。 使用法規合規性和 Azure 原則 計劃，以設定標準持續評估基礎結構。 防止設定漂移。 - Microsoft Sentinel Automate Sentinel 整合和部署作業搭配 GitHub 和 Azure DevOps 指派安全性標準 - Multicloud 環境。 - Sentinel 和 Azure DevOps 整合 - 從存放庫部署自定義內容 |
Advanced3.5.2 持續授權操作 （cATO） Pt2DoD 組織完全自動化控制衍生、測試和監視程式。 偏差會使用現有的跨柱自動化基礎結構自動測試和解決。 儀錶板可用來監視授權與分析的狀態，並與負責的授權官員整合。< /br> 結果： - 控件測試已完全自動化 - 與標準 IR 整合，SOC 作業已自動化 |
Microsoft Defender 威脅與弱點管理 在您的 弱點管理 計劃中納入威脅與弱點管理（TVM）。 請參閱 3.3.2 中的Microsoft指引。 Azure DevOps 和 Microsoft Sentinel 自動化 Sentinel 與 Azure DevOps 的整合和部署作業。 - Sentinel 與 Azure DevOps 整合 Microsoft Defender 全面偵測回應 和 Sentinel 整合 Microsoft Defender 全面偵測回應 與 Sentinel 適用於雲端的 Defender。 - Sentinel 和適用於 零信任 的 Defender XDR |
下一步
為 DoD 零信任 策略設定 Microsoft 雲端服務：