DoD 零信任战略和路线图概述了国防部各部门和国防工业基地 (DIB) 合作伙伴采用基于零信任原则的新网络安全框架的路径。 零信任消除了传统的边界和信任假设，从而实现了更高效的体系结构，增强了安全性、用户体验和任务性能。
本指南针对 DoD 零信任功能执行路线图中的 152 项零信任活动提出了建议。 这些部分与 DoD 零信任模型的七大支柱相对应。
使用以下各链接，转到指导的各节。
3 应用程序和工作负载
本部分提供了 Microsoft 针对应用程序和工作负载支柱中的 DoD 零信任活动的指导和建议。 有关详细信息，请参阅通过零信任保护应用程序。
注意
本部分的建议与 DoD 企业 DevSecOps 参考设计草案相一致。
3.1 应用程序盘点
Microsoft Entra ID 是适用于应用程序和云平台（而不仅仅是 Microsoft 365 和 Azure）的标识提供者 (IdP)。 Microsoft Entra ID 包括 Web 门户和 RESTful API，用于检索集成应用程序列表。 Microsoft Defender for Cloud Apps 是 Microsoft Defender XDR 的一个组件，具有发现、盘点和阻止未经批准的应用的功能。
| DoD 活动说明和结果 | Microsoft 指导和建议 |
|---|---|
Target 3.1.1 应用程序/代码识别DoD 组织创建已批准应用程序和代码（例如源代码、库等）的清单。 每个组织至少在清单中跟踪可支持性（例如活动、旧版等）和托管位置（例如云、本地、混合等）。 结果： - 组件已标识应用程序并分类为旧版、本地虚拟化和云托管 |
Microsoft Entra ID 使用 Microsoft Entra 管理中心下载 Microsoft Entra 注册的应用程序列表。 选择顶部功能区中的“下载”。 - 应用程序资源类型 如果组织使用 Active Directory 联合身份验证服务 (AD FS)，请部署 Microsoft Entra Connect Health。 使用应用程序活动报告来发现 AD FS 应用程序。 - 通过 Connect Health 监视 AD FS - 应用程序活动报告 Microsoft Defender 漏洞管理 使用 Defender 漏洞管理中的软件清单来查看组织中的软件。 - 软件清单 Microsoft Defender for Cloud Apps 在 Defender for Cloud Apps 中设置 Cloud Discovery，以获取用户访问的应用程序的快照。 - 设置 Cloud Discovery - 调查应用 Microsoft Intune 发现的应用 Intune 发现的应用由租户中 Intune 注册的设备检测。 这是租户的软件清单。 在企业设备上，此报告不会收集应用或托管应用。 - 发现的应用 Azure DevOps 使用此服务进行安全包管理。 开发人员在一个位置共享代码和管理包。 - Azure Artifacts - Azure GitHub 存储库 |
3.2 安全软件开发和集成
GitHub Advanced Security (GHAS) 和 GitHub Actions 等 GitHub 功能可帮助你建立零信任软件开发和部署实践。 GitHub Enterprise Cloud 与 Microsoft Entra ID 集成，通过 Microsoft Entra ID 治理管理权利，并通过条件访问策略来确保访问安全。
开发人员可以使用 Microsoft 身份验证库 (MSAL) 将应用程序与 Microsoft Entra ID 集成。 有关详细信息，请参阅对用户进行身份验证以实现零信任。
| DoD 活动说明和结果 | Microsoft 指导和建议 |
|---|---|
Target 3.2.1 生成 DevSecOps 软件工厂第 1 部分DoD 企业为新式 DevSecOps 流程和 CI/CD 管道创建基础标准。 这些概念应用于 DoD 组织的标准化技术堆栈，能够满足将来的应用程序安全要求。 企业范围的漏洞管理计划按照漏洞管理计划活动与 CI/CD 管道集成。 结果： - 为 DevSecOps 制定数据/服务标准 - CI/CD 管道功能齐全且测试成功 - 漏洞管理计划正式实施到位且正常工作 |
GitHub Actions GitHub Actions 使用持续集成和持续交付 (CI/CD) 来自动化部署管道。 - GitHub Actions GitHub Advanced Security 使用适用于 GitHub 和 Azure DevOps 的 GitHub Advanced Security 来增强代码和开发流程的安全性。 - Advanced Security - 适用于 Azure DevOps 的 Advanced Security Microsoft Entra SSO 和预配 使用 Microsoft Entra ID 为 Git 工具配置单一登录 (SSO)。 - 与 GitHub Enterprise Cloud 组织的 SSO 集成 - 与 GitHub Enterprise Server 的 SSO 集成 - 将组织连接到 Microsoft Entra ID 若要详细了解 Azure 和其他云的 DevSecOps，请参阅 DoD 首席信息官 (CIO) 库。 |
Target 3.2.2 生成 DevSecOps 软件工厂第 2 部分DoD 组织将使用批准的 CI/CD 管道来开发大多数新应用程序。 任何例外情况都将遵循标准化审批流程，以便能够以传统方式进行开发。 DevSecOps 流程还用于开发所有新应用程序和更新现有应用程序。 持续验证功能集成到 CI/CD 管道和 DevSecOps 流程中，并与现有应用程序集成。 结果： - 将应用程序开发迁移到 CI/CD 管道 - 实现并使用持续验证流程/技术 - 将应用程序开发迁移到 DevSecOps 流程和技术 |
GitHub Advanced Security 使用 GitHub Advanced Security 扫描代码依赖项和漏洞。 配置定期生成以评估代码质量。 - Advanced Security - CodeQL 代码扫描 - 保护供应链 Azure 中的 Bicep 使用基础结构即代码 (IaC) 通过 Azure 资源管理器 (ARM) 和 Bicep 模板来预配云基础结构。 - Bicep Microsoft Defender for Cloud 为具有应用程序工作负载的订阅启用 Defender for Cloud 工作负载保护。 - 保护云工作负载 Microsoft Defender for DevOps 使用 Defender for DevOps 监视 Azure DevOps (ADO) 和 GitHub 中管道的安全性和警报。 - Defender for DevOps |
Target 3.2.3 自动化应用程序安全性和代码修正第 1 部分在整个 DoD 企业中实现标准化应用程序安全性方法（包括代码修正）。 此活动的第一部分包括将安全 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 应用服务和 Azure Functions 中的内置身份验证和授权（简易身份验证）。 对于 Microsoft Entra ID 无法感知的 API，在 Azure API 管理中使用 OAuth 授权。 - 配置应用以公开 Web API - 在 Azure 应用服务和 Azure Functions 中进行身份验证和授权 - 对 API 进行身份验证和授权 GitHub Advanced Security 使用适用于 GitHub 和 Azure DevOps 的 GitHub Advanced Security。 请参阅 3.2.1 中的 Microsoft 指南。 Microsft Defender for Cloud 为具有 API 工作负载的 Azure 订阅启用 Defender for Cloud 工作负载保护。 请参阅 3.2.2 中的 Microsoft 南。 |
Advanced 3.2.4 自动化应用程序安全性和代码修正第 2 部分DoD 组织遵循最佳做法对内部开发和管理的服务（例如微服务）的交付方法进行现代化改造。 使用这些方法可以在发现安全问题时更快地更改每个微服务中的代码，从而实现更具弹性和安全性的体系结构。 在整个 DoD 企业中继续开展进一步的安全修正活动，包括适当的容器运行时安全功能、自动化的有漏洞库更新，以及发布过程中的自动化 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 指导和建议 |
|---|---|
Target 3.3.1 批准的二进制文件/代码DoD 企业遵循最佳做法有条不紊地管理批准的二进制文件和代码。 这些方法包括供应商寻源风险管理、批准的存储库用法、材料清单供应链风险管理和行业标准漏洞管理。 结果： - 评估并识别已批准来源的供应商寻源风险 - 建立存储库和更新通道以供开发团队使用 - 创建应用程序材料清单并识别来源、可支持性和风险态势 - 引入行业标准 (DIB) 和批准的漏洞数据库以在 DevSecOps 中使用 |
GitHub Actions 标准化 DevSecOps 流程，以通过持续集成和持续交付 (CI/CD) 管道生成软件材料清单 (SBOM)。 - 生成软件材料清单 使用 GitHub Dependabot 和 CodeQL 自动化安全检查并扫描依赖项漏洞。 - CodeQL 代码扫描 - 确保供应链安全 Windows Defender 应用程序控制 使用 Windows Defender 应用程序控制来防止不受信任的代码在托管终结点上执行。 - 应用控制和应用保险箱 - 平台代码完整性 |
Target 3.3.2 漏洞管理计划第 1 部分DoD 企业与各组织合作来制定和管理漏洞管理计划。 该计划包括所有组织议定的策略和标准。 制定的计划至少包括基于 DoD 应用程序/服务的公共漏洞跟踪和管理。 组织与主要利益干系人组建漏洞管理团队，根据企业策略和标准探讨和管理漏洞。 结果： - 组建漏洞管理团队并分配适当的利益干系人成员资格 - 漏洞管理策略和流程已实施到位，并得到利益干系人的同意 - 利用公开漏洞源进行跟踪 |
威胁和漏洞管理 VM 功能可以实现资产可见性和智能评估。 TVM 为终结点和服务器提供内置的修正工具。 将 TVM 与漏洞管理计划配合使用。 - Microsoft Defender TVM Microsoft 云安全基准 了解 Microsoft 联机服务如何进行漏洞管理。 - TVM 概述 - 态势和漏洞管理 |
Target 3.3.3 漏洞管理计划第 2 部分在 DoD 企业级别建立流程，用于管理 DoD 维护/操作的、可公开和私密访问的服务中漏洞的披露。 DoD 组织扩展了漏洞管理计划，以跟踪和管理 DIB、CERT 等封闭漏洞存储库。 结果： - 利用受控（例如 DIB、CERT）的漏洞源进行跟踪 - 漏洞管理计划提供一个流程用于接受托管服务的外部/公开披露 |
威胁和漏洞管理 使用 Microsoft Defender TVM 中的漏洞页面来识别在组织设备和服务器上发现的漏洞并确定其优先级。 - 组织中的漏洞 使用 TVM 有漏洞设备报告跟踪修正活动。 - 有漏洞设备报告 |
Target 3.3.4 持续验证DoD 组织将针对应用程序开发实施持续验证方法，在验证过程中将执行并行部署并与批准的环境级别（例如用户验收测试、生产）集成。 识别出无法将持续验证集成到 CI/CD 流程的应用程序，并根据需要有条不紊地提供例外情况。 结果： - 更新的应用程序将部署在实时和/或生产环境中 - 标记为停用和有待过渡的应用程序将被去除 - 实施持续验证工具并将其应用于 CI/CD 管道中的代码 - 识别需要持续验证的代码并制定验证标准 |
Azure Chaos Studio 使用 Azure Chaos Studio 验证工作负载。 - 持续验证 GitHub Advanced Security 在 DoD 企业 DevSecOps 参考设计中使用 GitHub 功能和操作进行漏洞管理。 请参阅 3.2.1 中的 Microsoft 指南。 |
3.4 资源授权和集成
条件访问是 Microsoft Entra ID 中的零信任策略引擎。 将应用程序工作负载与 Microsoft Entra ID 相连接。 使用 Microsoft Entra ID 治理通过条件访问策略管理权利和安全登录。 这些策略使用设备运行状况、会话详细信息和风险等安全属性来做出自适应访问决策。 Microsoft Entra ID、Azure 资源管理器和 CI/CD 管道为 Azure 中的资源部署授权。
| DoD 活动说明和结果 | Microsoft 指导和建议 |
|---|---|
Target 3.4.1 资源授权第 1 部分DoD 企业与组织一起将资源授权方法（例如软件定义的外围）标准化。 资源授权网关至少需要与标识和设备集成。 组织部署批准的资源授权网关，并为面向外部的应用程序/服务启用这些网关。 其他需要迁移的应用程序以及无法迁移的应用程序将被标识为例外或有待去除。 结果： - 为面向外部的应用程序部署资源授权网关 - 与标识和设备集成的资源授权策略 - 向利益干系人传达企业范围的有关转换标准的指导 |
Microsoft Entra ID Microsoft Entra 是应用程序资源的授权网关。 集成新式和旧式应用程序以通过 Microsoft Entra 实现 SSO。 请参阅用户中的 Microsoft 指导 1.2.4。 Microsoft Entra ID 治理 使用 Microsoft Entra ID 治理应用角色来访问应用程序。 使用静态成员资格、动态 Microsoft Entra 安全组或权利管理访问包将用户分配到应用角色。 - 将应用角色添加到应用，并在令牌中接收这些角色 - 基于角色的访问控制 条件访问 使用条件访问策略动态授权、控制或阻止应用程序访问。 请参阅用户中的 Microsoft 指南 1.8.3 和设备中的指南 2.1.4。 Azure 应用程序网关 通过应用程序网关和 Web 应用程序防火墙启用可公开访问的 Web 应用程序和 API。 请参阅 3.2.3 中的 Microsoft 指南。 |
Target 3.4.2 资源授权第 2 部分资源授权网关用于所有可能的应用程序/服务。 无法利用网关的应用程序将通过基于风险的合理方法去除或加入例外项。 授权进一步与 CI/CD 管道集成，以实现自动化决策。 结果： - 资源授权网关用于所有应用程序 - 资源授权与 DevSecOps 和 CI/CD 集成以实现功能自动化 |
Microsoft Entra 工作负载 ID 使用工作负载标识联合来配置用户分配的托管标识，或使用应用注册信任来自外部标识提供者 (IdP) 的令牌。 为 GitHub Actions 工作流使用联合工作负载标识。 - 工作负载标识联合 Azure API 管理 使用 Azure API 管理来管理、授权 Azure 内外托管的服务并将其公开为 API。 - Azure API 管理 |
Target 3.4.3.SDC 资源授权第 1 部分DoD 企业遵循行业最佳做法，为基于代码的计算管理（例如软件定义的计算）提供标准化方法。 通过基于风险的方法，使用批准的代码库和包集创建基线。 DoD 组织使用批准的代码/二进制文件活动，以确保识别出能够或不能够支持该方法的应用程序。 识别能够支持新式基于软件的配置和管理方法的应用程序并开始过渡。 识别无法遵循基于软件的配置和管理方法的应用程序，并有条不紊地通过例外项来允许使用这些应用程序。 结果： - 无法更新为使用批准的二进制文件/代码的应用程序将标记为停用，并为其创建过渡计划 - 已识别出的没有批准的二进制文件和代码的应用程序将更新为使用批准的二进制文件/代码 - 向利益干系人传达企业范围的有关转换标准的指导 |
安全开发 按照安全开发生命周期和发布的最佳做法设计、开发和部署 Azure 应用程序。 - 安全开发 - 基础结构即代码 - Azure Policy 即代码工作流 Microsoft Entra ID 使用 Microsoft 标识平台进行应用身份验证和授权。 - 迁移应用和身份验证 Azure Migrate 迁移到新式应用平台，例如 Azure Kubernetes 服务 (AKS) 和应用服务容器。 - 将工作负载迁移到新式应用平台 - 评估 ASP.NET 应用是否可迁移到 AKS - 评估 ASP.NET 应用是否可迁移到 Azure 应用服务 |
Target 3.4.4 SDC 资源授权第 2 部分支持基于软件的配置和管理的应用程序已过渡到生产/实时环境并处于正常运行状态。 如果可能，将去除无法支持基于软件的配置和管理的应用程序。 结果： - 更新的应用程序部署在实时和/或生产环境中 - 去除标记为停用和有待过渡的应用程序 |
Azure Migrate 使用“Azure Migrate：应用容器化”工具来容器化和迁移 ASP.NET 应用与 Java Web 应用。 去除无法现代化的应用程序。 - 容器化 ASP.NET 应用并将其迁移到 AKS - 容器化 ASP.NET 应用并将其迁移到 Azure 应用服务 - 容器化 Java Web 应用并将其迁移到 AKS - 容器化 Java Web 应用并将其迁移到 Azure 应用服务 |
Advanced 3.4.5 扩充资源授权属性第 1 部分来自用户和实体活动监视、微分段服务、DLP 和数据权限管理 (DRM) 等源的初始属性将集成到资源授权技术栈和策略。 识别任何其他属性并规划好将来的集成。 属性用于创建用户、非人员实体 (NPE) 和设备的基本风险态势，以做出授权决策。 结果： - 大多数 API 调用都将通过安全 API 网关传递 - 资源授权从分析引擎接收数据 - 授权策略在授权决策中整合识别的属性 - 识别用于初始扩充的属性 |
Microsoft Entra 应用程序 使用 Microsoft Entra ID 来为新式应用程序和 API 授权。 部署 Microsoft Entra 应用程序代理和已启用 Azure Arc 的服务器，将 Microsoft Entra ID 扩展到旧式身份验证协议。 请参阅 3.1.1 和 3.2.3 中的 Microsoft 南。 条件访问 Microsoft Entra 是用于资源授权的安全网关。 条件访问是授权引擎。 使用用户、应用程序、用户、环境条件（包括设备合规状态）配置详细授权策略。 - 条件访问 - 条件访问设计 - 需要合规设备 动态安全组 基于用户属性创建动态安全组。 使用动态组基于用户属性来限定静态属性授权的条件访问策略范围。 - 组的动态成员资格 - 用户、组和工作负载标识 Microsoft Purview 敏感信息类型 使用精确数据匹配 (EDM) 定义敏感信息类型。 将敏感信息类型用于 Microsoft Purview 信息保护和 Purview 数据丢失防护 (DLP) 策略。 - 基于敏感信息类型进行数据匹配 - 发现和保护敏感信息 Microsoft Entra ID 治理 使用 Microsoft Entra ID 治理访问具有应用角色的应用程序。 使用静态成员资格、动态安全组或权利管理访问包将用户分配到应用角色。 - 添加应用角色并在令牌中接收这些角色 - 基于角色的访问控制 |
Advanced 3.4.6.扩充资源授权属性第 2 部分扩展标识属性与资源授权技术和策略集成。 在各种属性中引入置信度评分，以自动创建更高级的授权决策方法。 结果： - 授权策略在授权决策中整合置信度 - 定义属性的置信度级别 |
Microsoft Entra ID 保护 在条件访问策略集中使用来自 Microsoft Entra ID 保护的登录风险和用户信号。 配置身份验证上下文，包括根据环境详细信息和风险级别建立信任级别的风险。 - Microsoft Entra ID 风险 - 策略模板：登录风险 MFA - 身份验证上下文示例 请参阅用户中的 Microsoft 指导 1.3.3。 自定义安全属性 管理和分配 Microsoft Entra ID 用户的自定义安全属性。 使用角色分配条件进行基于属性的动态访问控制 (ABAC)。 - 自定义安全属性 |
Advanced 3.4.7.REST API 微分段使用 DoD 企业批准的 API 网关对应用程序调用进行微分段，以便仅在经过身份验证和授权的情况下访问特定目标（例如微服务）。 如果可能，API 微分段控制台将会集成并感知其他微分段控制台，例如软件定义的外围控制器和/或软件定义的网络控制台。 结果： - 已对批准的企业 API 进行适当的微分段 |
Azure 网络和连接 隔离、筛选和控制入口和出口流中的网络流量。 在可用网络边界使用本地化网络控制来应用深层防御原则。 遵循 Azure 架构良好的框架。 - 网络和连接建议 - 分段策略建议 API 设计 遵循建议的做法为微服务设计 API。 使用 Microsoft Entra ID 保护和授权 API。 - 微服务 API - 保护 API |
3.5 持续监视和持续授权
Microsoft Defender for Cloud 安全标准持续评估范围内的 Azure 订阅、Amazon Web Services (AWS) 帐户和启用了 Defender for Cloud 的 Google Cloud Platform (GCP) 项目，以确保其符合监管标准。
| DoD 活动说明和结果 | Microsoft 指导和建议 |
|---|---|
Advanced 3.5.1 持续操作授权 (cATO) 第 1 部分DoD 组织在环境中利用自动化解决方案来标准化控制措施的监视，并提供用于识别偏差的功能。 在适当的情况下，监视和测试将与 DevSecOps 流程集成。 结果： - 控制派生已标准化并准备好实现自动化 - 控制测试与 DevSecOps 流程和技术集成 |
DoD 首席信息官 (CIO) 库 将监视和测试集成到 DevSecOps 流程中。 参阅 DoD 企业 DevSecOps 参考设计 - DoD CIO 库 Microsoft Defender for Cloud 使用 Defender for Cloud 保护 Azure 和非 Azure 工作负载。 使用法规遵从性和 Azure Policy 计划根据配置标准持续评估基础结构。 防止配置偏差。 - 分配安全标准 - 多云环境 Microsoft Sentinel 通过 GitHub 和 Azure DevOps 自动执行 Sentinel 集成和部署操作。 - Sentinel 和 Azure DevOps 集成 - 从存储库部署自定义内容 |
Advanced 3.5.2 持续操作授权 (cATO) 第 2 部分DoD 组织完全自动化控制派生、测试和监视流程。 使用现有的跨支柱自动化基础结构自动测试和解决偏差。 仪表板用于监视授权状态，分析结果将与负责的授权官员的结果集成。</br> 结果： - 控制测试完全自动化 - 与标准 IR 和 SOC 操作的集成将自动化 |
Microsoft Defender 威胁和漏洞管理 将威胁和漏洞管理 (TVM) 整合到漏洞管理计划中。 请参阅 3.3.2 中的 Microsoft 指南。 Azure DevOps 和 Microsoft Sentinel 通过 Azure DevOps 自动执行 Sentinel 集成和部署操作。 - Sentinel 与 Azure DevOps 集成 Microsoft Defender XDR 和 Sentinel 将 Microsoft Defender XDR 和 Defender for Cloud 与 Sentinel 集成。 - 使用 Sentinel 和 Defender XDR 实现零信任 |
后续步骤
为 DoD 零信任策略配置 Microsoft 云服务：