你当前正在访问 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) 系统或开发人员工作站入侵应用程序。
这种做法是开发生命周期的关键基础，应在所有配置文件中建立。
在整个实践过程中，必须采取“零信任”方法。 零信任模型的核心是要求对每个访问请求（用户、服务或设备）进行验证，就像它来自一个不受信任的网络一样，无论该请求来自哪里或访问什么资源。 这种“始终进行身份验证和授权”的策略以所有可用数据点为基础。 应通过实时和恰好足够的访问权限 (JIT/JEA) 策略来限制用户访问，尤其是特权用户，并对访问进行细分，以最大限度地降低出现漏洞时可能造成的损失。
强化开发环境可以通过多种方法实现，但首先考虑开发人员工作站是一个良好的起点。 通过利用 GitHub Codespaces 或 Microsoft DevBox 等技术，可以将开发环境转移到 SaaS 应用程序，然后通过安全和网络设置或组织策略对其进行管理。
为进一步锁定开发人员工作站，可以向其发放特权访问工作站/安全访问工作站 (PAW/SAW)。 这些工作站可帮助你减少威胁载体，确保开发人员设备的标准化和可控性。
安全设计
执行威胁建模（安全设计审核）
此控制支持持续 SDL 实践 3 – 执行威胁建模。
此控制可识别设计中可能导致安全事故和业务损失的安全漏洞。 设计中的安全弱点在设计实施后可能难以缓解，因此在生命周期的早期发现并修复这些弱点至关重要。
威胁建模可作为安全设计审核流程，可将安全性融入系统或应用程序的设计中。
威胁建模可系统地识别、评估、优先处理和缓解软件系统中的安全风险。 这种结构化的方法用于分析软件应用程序的设计和架构，可在开发过程的早期识别潜在的威胁和漏洞。
最终目标是了解系统和可能出现的问题。 通过深入了解系统本身和潜在攻击者对系统的看法，威胁建模有助于实现这一目标。
此过程通常采取威胁发现研讨会的形式，由系统专家和安全专家组成的团队共同发现和记录风险。 虽然这一过程在开始时可能并非正式的，但它应迅速发展成为一个结构化的过程，讨论正在构建的服务的各个方面、使用方式和系统接口。
威胁建模的阶段包括：
- 确定用例、场景和资产 – 首先要了解系统能够实现哪些业务功能和用例，以帮助评估任何系统受损对业务的潜在影响，并为后续讨论提供信息。
- 创建体系结构概述 – 创建应用程序的可视化摘要（或使用现有摘要），以便清楚地了解系统及其工作方式。 该概述应包括：业务流程图、组件和子系统、信任边界、身份验证和授权机制、外部和内部接口，以及参与者和组件之间的数据流。
- 识别威胁 – 借助常用方法来枚举潜在的安全威胁，如 STRIDE 模型或 OWASP 威胁建模。
- 识别和跟踪缓解措施 – 使用现有的开发流程和工具监控和跟踪发现的设计缺陷，确保修复措施得到实施和记录。 此过程应包括确定首先采取哪些缓解措施的优先次序，以便团队将时间首先花在最重要的工作上。 这一过程是风险驱动的，你可能没有资源在第一个周期内完全缓解所有风险。 仔细考虑哪些缓解措施（包括部分缓解措施）能以最少的防御成本和资源加大攻击者的成本。 安全目标是让攻击者失败，而失败的形式可以是完全阻止攻击技术、检测到攻击技术以便采取应对措施、减缓攻击速度以便让安全人员有时间采取应对措施、限制破坏范围等。
威胁模型通常可作为所有相关人员的教育过程，并为其他安全规划、实施和测试提供重要背景信息。
包含使用人工智能 (AI) 组件的应用程序必须评估与 AI 相关的特定风险类型，而这些类型与传统应用程序有所不同。
通过以下方式创建和分析威胁模型：就系统的安全设计进行沟通，使用经验证的方法来分析这些设计中潜在的安全问题，并建议和管理安全问题的缓解措施。
保护代码
代码分析
此控制支持持续 SDL 实践 7 – 执行安全测试。
此控制侧重于在开发人员编写代码/将代码输入集成开发环境 (IDE) 或检查代码时提高代码的安全性。 此控制是 DevSecOps 实践的基石，因为它直接解决了攻击者经常利用的漏洞。
如果没有这种控制，可能就会遗漏开发人员直接编码到应用程序中的漏洞。 开发人员对此并非恶意，但可能缺乏必要的技能来识别他们编码的内容为何不安全。
通过将工具直接集成到集成开发环境中，这种控制是获得左移方法的生产效率和安全性优势的关键。 通过这一过程，可以尽早以最具成本效益的方式快速发现和修复漏洞。 此过程可以追溯到已经开发的应用程序，找出安全漏洞并在日后加以修复（尽管要付出更大的代价，并且难度也更大）。
这一过程通常采用 IDE 插件或专用扫描工具的形式，使用静态分析安全测试 (SAST) 和动态分析安全测试 (DAST) 工具集来对代码进行扫描。
SAST 工具可扫描现有的代码库，并可完全访问代码。 SAST 工具可以找出代码本身的核心弱点。 而 DAST 则在部署的应用程序上执行。 因此，它无法访问代码，其执行目的是在运行时模拟和识别安全漏洞。
注意
与传统应用程序相比，人工智能应用程序具有不同类型的漏洞（如偏见和幻觉），因此需要使用针对这些漏洞的工具。
质量控制很重要！ 运行这些工具的一个关键考虑因素是确保对它们进行优化，以减少误报带来的干扰和浪费精力。 优化这些工具通常需要具有开发人员背景并了解企业开发流程的安全专业人员。 同样的专业人员还可以为开发人员提供会审指导和有关单个检测的专业知识。 它们可以帮助区分真阳性和假阳性、真实问题和虚假警报。 开发人员接触这些专家的流程通常与提供安全培训密切相关，例如通过冠军计划、应用程序安全支持团队等。
临时最低 – 确保启用内置 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 Key Vault 或硬件安全模块 (HSM)。 在任何情况下，都不能将纯文本密钥和机密存储在代码中，哪怕是暂时的也不行！ 攻击者会寻找并利用这些机密。
重要
内部源代码存储库并不安全！
内部存储库应遵守与面向公众的存储库相同的要求，因为威胁行为者通过网络钓鱼或其他手段进入环境后，经常都会在存储库中寻找机密和密钥。 这是零信任方法所要求的，该方法假定存在漏洞，并据此来设计安全控制。
标准 – 良好的机密保护至关重要，所有资料都必不可少。
注意
当这些秘密被团队或攻击者发现时，除了将机制修改为更安全的访问方法（如托管标识）外，还必须确保密钥不能被用于访问资源（因资源类型而异）。
更多详细信息和资源包括：
注意
强烈建议使用 Azure Key Vault 等机密存储解决方案来为每个工作负荷提供密钥。
保护管道
此控制支持持续 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)。 对支持每个高安全性工作负荷的标识系统和组件执行针对特定工作负荷的威胁模型。
在可能的情况下，托管标识是更安全和更可取的身份验证方法。 由于需要在应用程序层存储和检索令牌和机密，因此使用令牌和机密的安全性较低。 此外，托管标识可自动滚动更新，无需手动干预。
更多详细信息和资源包括：
- 保护特权访问 (SPA) 指导
- 保护你的身份基础结构的五个步骤
- 什么是 Azure 资源托管标识？
- 什么是 Microsoft Entra Privileged Identity Management
- 什么是 Microsoft Entra 权限管理？
主机/容器/环境控制
此控制支持持续 SDL 实践 8 – 确保操作平台安全性和实践 6 – 保护工程环境。
确保在开发生命周期的所有技术要素中，所有计算资源和托管环境都遵循安全最佳做法。 威胁者拥有先进的方法和自动化手段来对基础结构和用户终结点发起攻击，他们经常借助这些方法来攻击生产系统和开发流程。 基础结构安全性是 Microsoft 推荐的零信任模式的基础支柱。
此控制必须包括开发和运行生命周期的所有要素，包括但不限于：
- 常规 IT/操作工作站和环境
- 专用开发工作站和环境
- CI/CD 管道基础结构
- 工作负荷托管环境
- 任何其他开发系统。
此控制包括可运行任何代码的任何资源，包括但不限于：
- 虚拟机 (VM) 主机和 VM
- 容器和容器基础结构
- 应用程序、脚本和代码托管平台
- 云订阅/帐户和注册
- 开发人员、用户和 IT 管理员工作站
确保将安全最佳做法应用于基础结构组件，包括安全更新（补丁）、基线安全配置等。
临时最低 – 为主机和订阅应用标准企业配置。
标准 – 确保基础结构符合 Microsoft 云安全基准 (MCSB) 中列出的安全最佳做法。
高安全性 – 严格执行 MCSB 标准，对支持每个高安全性工作负荷的基础结构执行特定于工作负荷的威胁模型。
更多详细信息和资源包括：
- Microsoft 云安全基准 (MCSB)
- Microsoft Defender for Cloud
- AppLocker
- 保护 SQL Server
- Windows 安全基线
- 应用控制和基于虚拟化的代码完整性保护
网络访问控件
此控制支持持续 SDL 实践 8 – 确保操作平台安全性和实践 6 – 保护工程环境。
确保开发环境、CI/CD 管道、运营工作负荷环境和其他开发系统的所有技术要素都遵循网络访问管理的安全最佳做法。 威胁者拥有先进的标识攻击方法和自动化手段，他们经常利用这些方法对生产系统和开发流程发起攻击。 网络安全性是 Microsoft 推荐的零信任模式的基础支柱。
网络安全应包括：
- 外部网络保护 – 隔离未经请求的外部/Internet 流量，同时缓解已知的攻击类型。 这种隔离通常采用 Internet 防火墙、Web 应用程序防火墙 (WAF) 和 API 安全解决方案等形式。
- 内部网络保护 – 隔离未经请求的内部流量（来自其他企业网络位置）。 这种隔离可使用与外部网络保护类似的控制，并可细化到工作负荷甚至特定的单个组件和 IP 地址。
- 拒绝服务缓解 – 防范分布式拒绝服务 (DDoS) 以及其他拒绝服务攻击。
- 安全服务边缘 (SSE) – 使用客户端微分段来直接提供对资源的安全访问，包括应用零信任策略。
确保所有开发系统及其托管基础结构（VM、容器、网络设备等）都遵循安全最佳做法。
临时最低 – 为工作负荷应用标准企业配置。
标准 – 确保所有系统都有外部网络保护、DDoS 保护和最低限度的按工作负荷内部网络保护。
高安全性 – 所有标准保护措施加上高粒度的内部网络保护措施、通过外部网络保护机制强制传输出站服务器流量，以及支持每个高安全性工作负荷的网络基础结构的特定于工作负荷的威胁模型。
更多详细信息和资源包括：
监控、响应和恢复
此控制支持持续 SDL 实践 9 – 实现安全监控和响应。
确保安全运营 (SecOps/SOC) 团队对工作负荷（API 和应用）以及托管它们的基础结构具有可见性、威胁检测和响应程序。 确保 SecOps 团队和基础结构/工作负荷团队之间的跨团队流程和工具能够在攻击发生后迅速恢复。
一旦工作负荷投入生产并在企业中积极运行，这种控制就能确保工作负荷的安全性。 此流程应与检测和应对安全事件的现有安全操作功能相集成。
自定义工作负荷的安全监控结合了针对常见组件的扩展检测和响应 (XDR) 解决方案，能够通过分析日志和其他应用数据来检测和调查潜在的安全威胁。 自定义应用程序数据通常包括：关于用户请求、应用程序活动、错误代码、网络流量、应用程序、数据库、网络终结点以及其他系统组件的其他相关详细信息的信息。
然后，利用实时威胁情报的见解对这些数据进行强化，以识别异常行为模式，这些模式可能表明有人试图渗透网络。 一旦聚合、关联和规范化，XDR 和安全信息与事件管理 (SIEM) 就会提供补救措施。
临时最低 – 在环境中部署 XDR 功能，以监控最终用户设备的流量。
标准 – 部署 XDR 和自定义 SIEM 检测，以识别与整体环境相关的异常行为。 此配置文件可能包括针对个别工作负荷的自定义检测。
高安全性 – 标准控制加上基于对工作负荷威胁建模的深入了解而定制的每个工作负荷检测。 将此配置文件与 AI 相结合，为补救建议提供情景感知。
- Microsoft Defender
- Microsoft Sentinel
- 管理和响应安全警报
- Microsoft 下载：Microsoft Office 365 中的安全事件管理
- Microsoft 事件响应和云计算的责任分担
后续步骤
采用这些安全控制措施，并使其适应组织的风险承受能力和生产效率要求。 应采用持续改进的方法，不断向理想状态迈进。
首先确定控制的优先级和最低理想目标级别。 首先确保有积极的安全影响和低摩擦变化。 优先考虑、实现和整合第一个控制，然后重复下一个控制的流程。