通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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-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 Dependency graph/review 实现此控件。

高安全性 – 主动阻止应用程序中正在使用的可利用漏洞的所有不安全包。

若要详细了解此控制和衡量 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 云安全基准（MCSB）中概述的安全最佳做法。

高安全性 – 严格应用 MCSB 标准，并 执行支持每个高安全工作负荷的基础结构特定威胁模型 。

更多详细信息和资源包括：

网络访问控件

此控件支持持续 SDL 实践 8 – 确保运营平台安全性和实践 6 – 保护工程环境。

确保针对开发环境、CI/CD 管道、操作工作负荷环境和其他开发系统的所有技术元素遵循网络访问管理的安全最佳做法。 威胁参与者对标识攻击具有复杂的方法和自动化，这些攻击经常针对生产系统和开发过程使用。 网络安全是 Microsoft 建议的零信任模型的基础支柱。

网络安全应包括：

  • 外部网络保护 – 与未经请求的外部/Internet 流量隔离，并缓解已知攻击类型。 这种隔离通常采用 Internet 防火墙、Web 应用程序防火墙（WAF）和 API 安全解决方案的形式。
  • 内部网络保护 – 隔离来自未经请求的内部流量（来自其他企业网络位置）。 这种隔离可能使用类似的控制作为外部网络保护，并且可能会精细到工作负荷或特定的单个组件和 IP 地址。
  • 拒绝服务缓解 – 针对分布式拒绝服务（DDoS）和其他拒绝服务攻击的保护。
  • 安全服务边缘 （S标准版） - 使用客户端微分类直接提供对资源的安全访问，包括应用零信任策略。

确保所有开发系统和托管它们的基础结构都遵循安全最佳做法（VM、容器、网络设备等）。

临时最低 - 为工作负荷应用标准企业配置。

标准 - 确保所有系统都具有外部网络保护、DDoS 防护和最低每个工作负荷的内部网络保护。

高安全性 – 所有标准保护加上内部网络保护的高粒度、通过外部网络保护机制强制隧道出站服务器流量，以及 支持每个高安全工作负荷的网络基础结构的特定于工作负荷的威胁模型 。

更多详细信息和资源包括：

监视、响应和恢复

此控件支持持续 SDL 实践 9 - 实现安全监视和响应。

确保安全操作（SecOps/SOC）团队对工作负荷（API 和应用）以及托管它们的基础结构具有可见性、威胁检测和响应过程。 确保 SecOps 和基础结构/工作负荷团队之间的跨团队流程和工具在攻击后能够快速恢复。

此控制在生产环境中并积极在组织中运行后，将持续工作负荷的安全性。 此过程应与现有的 安全操作 功能集成，以便检测和响应安全事件。

自定义工作负荷的安全监视通过分析日志和其他应用程序数据来检测和调查潜在的安全威胁，将常见组件的扩展检测和响应解决方案组合在一起。 自定义应用程序数据通常包括：有关用户请求、应用程序活动、错误代码、网络流量、应用程序、数据库、网络终结点和其他系统组件的其他相关详细信息的信息。

然后，通过实时威胁情报的见解来增强此数据，以识别异常行为的模式，这些模式可能指示可能尝试渗透网络。 聚合、关联和规范化后，XDR 和安全信息和事件管理（SIEM）平台将提供修正操作。

临时最低 – 在环境中部署 XDR 功能，以监视最终用户设备的流量。

标准 - 部署 XDR 和自定义 SIEM 检测，以识别相对于整体环境的异常行为。 此配置文件可能包括针对单个工作负荷的自定义检测。

高安全性 – 标准控制以及基于工作负荷威胁建模见解的自定义每工作负载检测。 将此配置文件与 AI 相结合，以提供修正建议的上下文感知。

后续步骤

采用这些安全控制措施，使其适应组织的风险容忍度和生产力要求。 应使用持续改进方法，以持续构建理想状态。

首先优先考虑控件和最低的理想目标级别。 确保首先对安全产生积极影响和低摩擦更改。 对第一个控件进行优先级、实现和集成，然后将该过程与下一个控件重复。

应首先确定关键基础的优先级，因为它们具有广泛的积极影响和凭据和机密扫描，因为它具有很高的影响和频繁的攻击者使用。