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

自动实现 Sentinel 与 Azure DevOps 的集成

Microsoft Entra ID

Azure DevOps

Azure Key Vault

Microsoft Defender for Cloud

Microsoft Sentinel

本文介绍如何自动实现 Microsoft Sentinel 与 Azure DevOps 的集成和部署。使用 Microsoft Sentinel 功能实现 Azure DevOps，以帮助确保部署安全。然后使用 DevSecOps 框架管理和大规模部署 Microsoft Sentinel 项目。

体系结构

下图显示了 Azure DevOps 和 Microsoft Sentinel IaC 设置。

下载此体系结构的 Visio 文件。

数据流

Scrum Master 和产品管理使用 Azure DevOps 将长篇故事、用户情景和产品积压工作项定义为项目积压工作的一部分。
- Scrum Master 和产品管理使用 Azure Boards 创建积压工作、计划冲刺工作、审阅项目板、创建存储库结构，以及设置安全规则（例如审批工作流和分支）。
- Azure Git 存储库用于将管理 Microsoft Sentinel 项目所需的脚本和许可证存储在基础结构即代码中。
- 项目和源代码管理用于维护解决方案中使用的 DevSecOps 工作流的扩展文件和更新包或组件，例如 Azure 资源管理器模板工具包和 PowerShell Pester。
Microsoft Sentinel 项目：
- 策略。 SIEM 工程师在参考体系结构中使用 Azure 策略来配置和调整 Azure 服务的诊断设置。这些策略帮助自动部署 Microsoft Sentinel 数据连接器，例如 Azure Key Vault。这些策略依赖于 OMSIntegration API。
- 连接器。 Microsoft Sentinel 使用逻辑连接器（Azure 数据连接器）从支持的数据源（如 Microsoft Entra ID、Azure 资源、Microsoft Defender 或第三方解决方案）引入安全数据（如审核或指标）。数据连接器的主列表由 SecurityInsights API 管理，其他则依赖于 OMSIntegration API，并通过 Azure Policy 诊断设置进行管理。
- 托管标识。 Microsoft Sentinel 使用托管标识代表托管服务标识 (MSI) 执行操作，同时与 playbook、逻辑应用或自动化 runbook 和密钥保管库交互。
- 自动化。 SOC 团队在调查期间使用自动化。 SOC 团队使用 Azure 自动化来运行数字取证数据采集过程，例如 Azure 虚拟机 (VM) 监管链或 Microsoft Defender 电子数据展示（高级）。
- 分析。 SOC 分析师或威胁猎人使用内置或自定义分析规则来分析和关联 Microsoft Sentinel 中的数据，或者在识别威胁和事件时触发 playbook。
- Playbook。逻辑应用运行 SecOps 可重复操作，例如分配事件、更新事件或采取修正操作（例如隔离或包含 VM、撤销令牌或重置用户密码）。
- 威胁搜寻。威胁猎人使用主动威胁搜寻功能，这些功能可与 Jupyter Notebook 结合使用以用于高级用例，例如数据处理、数据操作、数据可视化、机器学习或深度学习。
- 工作簿。 SIEM 工程师使用工作簿仪表板可视化趋势和统计信息，以及查看 Microsoft Sentinel 实例及其子组件的状态。
- 威胁智能。特定的数据连接器，用于将威胁情报平台源融合到 Microsoft Sentinel 中。支持两种连接方法：TAXII 和图形 API。这两种方法在安全性 API 中充当 tiIndicator 或威胁情报指示器。
Microsoft Entra ID。向参考体系结构中使用的组件传递标识和访问管理功能，例如托管标识、服务主体、适用于 Microsoft Sentinel 的 Azure 基于角色的访问控制 (RBAC)、逻辑应用和自动化 runbook。
Azure Pipelines。 DevOps 工程师使用管道创建服务连接，以管理不同的 Azure 订阅，例如，通过持续集成和持续交付 (CI/CD) 管道来管理沙盒环境和生产环境。如果要管理每个 Azure 环境的多个订阅，建议使用审批工作流来防止意外部署和分隔的服务主体。
Azure Key Vault。 SOC 工程师使用密钥保管库安全存储服务主体机密和证书。当 Azure Pipeline 服务连接使用此体系结构组件时，其有助于强制实施 DevSecOps“代码中无机密”原则。
Azure 订阅。 SOC 团队在参考体系结构中使用两个 Microsoft Sentinel 实例，分隔在两个逻辑 Azure 订阅中以分别模拟生产环境和沙盒环境。可以根据需要扩展其他环境，例如测试环境、开发环境、预生产环境等。

数据流示例

管理员在其 Microsoft 365 配置文件的分支中添加、更新或删除条目。
管理员提交更改并将其同步到其分支存储库。
然后，管理员创建拉取请求 (PR)，以将更改合并到主存储库。
对 PR 运行生成管道。

组件

Microsoft Entra ID 是一种基于云的服务，用于管理标识和访问控制。
Azure DevOps 是一项云服务，用于协作编写代码、生成和部署应用或者计划和跟踪工作。
Azure Key Vault 是用于安全存储和访问机密的云服务。机密是你想要严格控制对其的访问的任何内容，例如 API 密钥、密码、证书或加密密钥。
Azure Policy 是一项服务，用于创建、分配和管理 Azure 环境中的策略定义。
Microsoft Sentinel 是可缩放的云原生 SIEM 和安全业务流程自动响应 (SOAR) 解决方案。
Azure 自动化是一项服务，用于通过流程自动化简化云管理。使用 Azure 自动化自动处理那些长时间运行的、需要手动操作的、易出错且重复性很高的任务。自动化有助于提高公司的可靠性和效率，并缩短价值实现时间。

方案详细信息

安全运营中心 (SOC) 团队在将 Microsoft Sentinel 与 Azure DevOps 集成时，有时会面临挑战。集成过程涉及许多步骤，可能需要数天时间才能完成设置，并且可能需要重复设置。在开发期间，可以自动执行此部分。

要实现云现代化，工程师必须不断学习新的技能和技术，以保护重要的业务资产。工程师必须构建可靠且可缩放的解决方案，以适应不断变化的安全格局和业务需求。安全解决方案必须灵活、敏捷，且必须从开发的最早阶段精心规划。这种早期规划方法称为“左移”。

本文介绍如何自动实现 Microsoft Sentinel 与 Azure DevOps 的集成和部署。可以扩展该解决方案，以服务于包含多个实体、订阅和各种操作模型的复杂组织。此解决方案支持的一些操作模型包括本地 SOC、全球 SOC、云服务提供商 (CSP) 以及托管安全服务提供商 (MSSP)。

本文主要供以下用户参考：

SOC 专家，如分析师和威胁猎人
安全信息和事件管理 (SIEM) 工程师
网络安全架构师
开发人员

可能的用例

此体系结构的典型用例如下：

快速原型制作和概念证明。此解决方案非常适合希望通过基础架构即代码 (IaC) 和 Microsoft Sentinel 提高云威胁覆盖率或实现其 SIEM 基础架构现代化的安全组织和 SOC 团队。
Microsoft Sentinel 即服务。此开发框架集成了服务生命周期管理原则。这些原则适用于简单的团队，也适用于复杂的团队，例如 MSSP，他们跨多个客户租户运行可重复、标准化的操作，并结合使用 Azure DevOps 和 Azure Lighthouse 的强大功能。例如，如果团队需要针对新的威胁行动者或正在进行的威胁行为发布 Microsoft Sentinel 用例，则可以使用此解决方案。
构建 SOC 威胁检测用例。许多团体和威胁情报平台依赖于 MITRE Att&ck 内容和分类来分析其在应对各种高级攻击者技术和策略时的安全态势。该解决方案通过在 Microsoft Sentinel 项目开发中引入 MITRE Att&ck 术语，定义了一种结构化方法来开发威胁检测工程实践。

下图显示了一种 MITRE Att&ck 云方案。

下载此体系结构的 Visio 文件。

基于 MITRE 的威胁定义攻击方案

下表显示了攻击方案的术语、定义和一些重要方面的详细信息。

数据项	描述	Microsoft Sentinel 项目
标题	攻击方案的描述性名称，其基于攻击途径特征或技术说明。	MITRE 清单
MITRE ATT&CK 策略	与攻击方案相关的 MITRE Att&ck 技巧	MITRE 清单
MITRE ATT&CK 方法	MITRE Att&ck 方法，包括与攻击方案相关的方法或细分方法 ID。	MITRE 清单
数据连接器源	传感器或日志记录系统从中收集信息的来源，可用于收集相关信息来识别对手正在执行的操作、操作序列或操作结果。	Microsoft Sentinel 数据连接器或自定义日志源
描述	与方法相关的信息，即方法的内容、常见用途、对手利用方式，以及方法变体的用法。包括引用权威文章（描述与方法相关的技术信息）和相应的自然使用场景。
检测	有助于识别对手所用方法的高级分析过程、传感器、数据和检测策略。此部分会通知负责检测对手行为的人员（如网络防御者），以便他们可以采取相应措施，例如编写分析或部署传感器。它应提供足够的信息和参考来帮助找到有用的防御方法。对于某些攻击方法，并非总有应对的检测措施，应将其记录下来。	Analytics 威胁搜寻
缓解措施	用于阻止攻击方法起作用或实现对手预期结果的配置、工具或流程。此部分会通知负责缓解对手行为的人员（如网络防御者或策略制定者），便于其采取相应措施，例如更改策略或部署工具。对于指定攻击方法，并非总有应对的缓解措施，应将其记录下来。
缓解措施	用于阻止攻击方法起作用或实现对手预期结果的配置、工具或流程。本部分介绍网络防御者或策略制定者如何减轻对手攻击的影响。它涵盖了更改策略或部署工具的步骤。对于某些攻击方法，并非总有应对的缓解措施，应将其记录下来。	playbook、自动化 runbook

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。有关详细信息，请参阅安全性支柱概述。

一般来说，在安全性方面，自动化可提高运营效率，同时缩短更复杂用例的时间，例如威胁检测工程、威胁情报、SOC 和 SOAR 用例。 DevOps 团队需要了解在 Microsoft Sentinel CI/CD 上下文的何处能够安全地使用 IaC。此过程会引入特定标识的使用，这些标识会由 Microsoft Entra ID 中称为服务主体和托管标识的非人工帐户来使用。

下表汇总了 Microsoft Sentinel 和 Azure DevOps 发布管道涵盖的服务主体和主要用例的安全注意事项。

使用案例	要求（最小特权）	角色分配持续时间	权限作用域	托管方	安全注意事项
启用 Microsoft Sentinel 连接器	安全管理员** 所有者* Microsoft Sentinel 参与者读取器	JIT（一次性激活）特定（每次部署新订阅和连接器时）	租户	SPN	使用密钥保管库存储服务主体名称 (SPN) 机密和证书。启用 SPN 审核。定期查看 SPN 权限分配（适用于 SPN 的 Azure Privileged Identity Management）或其可疑活动。针对特权帐户使用 Microsoft Entra 证书颁发机构和多重身份验证（如果支持）。使用 Microsoft Entra 自定义角色获得更高的粒度。
部署 Microsoft Sentinel 项目，例如工作簿、分析、规则、威胁搜寻查询、笔记本和 playbook	Microsoft Sentinel 参与者逻辑应用参与者	永久性	Microsoft Sentinel 的工作区或资源组	SPN	使用 Azure DevOps (ADO) 工作流审批和检查来保护此 SPN 的管道部署。
为 Microsoft Sentinel 分配用于配置日志流式传输功能的策略	资源策略参与者**	特定（每次部署新订阅和连接器时）	要监视的所有订阅	SPN	对于特权帐户，请使用 Microsoft Entra ID、CA 和 MFA。

* 仅涉及 Microsoft Entra 诊断设置。
** 特定连接器需要其他权限（例如“安全管理员”或“资源策略参与者”）才支持将数据流式传输到 Microsoft Sentinel 工作区、Microsoft Entra ID、Microsoft 365或 Microsoft Defender 以及 Azure Key Vault 等平台即服务 (PaaS) 资源。

特权访问模型

建议采用特权访问模型策略，迅速降低对特权访问的高影响和高可能性攻击给企业带来的风险。对于 DevOps 模型中的自动流程，标识需基于服务主体标识。

特权访问应该是每个公司的头等安全优先事项。任何这些标识的泄露都会带来极其负面的影响。特权标识有权访问业务关键型资产，当攻击者入侵这些帐户时，几乎总是会造成重大影响。

特权访问的安全性至关重要，因为它奠定了其他所有安全保障的基础。控制特权帐户的攻击者可以破坏所有其他安全保障。

因此，建议遵循最小特权原则，以逻辑方式将服务主体分布到不同的级别或层。下图演示了如何根据访问权限类型和需要访问权限的位置对服务主体进行分类。

管道中特权访问模型的分层体系结构示意图。

级别 0 服务主体

级别 0 服务主体具有最高级别的权限。这些服务主体授予某人全局管理员权限来执行租户范围或根管理组管理任务。

出于安全原因和可管理性，建议此级别仅一个服务主体。此服务主体的权限会持久保留，因此建议仅授予所需的最小权限，并保持帐户受监视和保护。

将此帐户的机密或证书安全地存储在 Azure Key Vault 中。强烈建议尽可能将密钥保管库放在专用管理订阅中。

级别 1 服务主体

级别 1 服务主体具有提升的权限，这些权限的作用域仅限于业务组织级别的管理组。这些服务主体授权某人在该作用域的管理组下创建订阅。

出于安全原因和可管理性，建议此级别仅一个服务主体。此服务主体的权限会持久保留，因此强烈建议仅授予所需的最小权限，并保持帐户受监视和保护。

将此帐户的机密或证书安全地存储在 Azure Key Vault 中。强烈建议尽可能将密钥保管库放在专用管理订阅中。

级别 2 服务主体

级别 2 服务主体仅限于订阅级别。这些服务主体授权某人在某个订阅下执行管理任务，充当该订阅的所有者。

将此帐户的机密或证书安全地存储在 Azure Key Vault 中。强烈建议将密钥保管库放在专用管理资源组中。

级别 3 服务主体

级别 3 服务主体仅限于工作负载管理员。在典型方案中，每个工作负载都包含在同一资源组中。此结构将服务主体权限仅限于此资源组。

出于安全原因和可管理性，建议每个工作负载仅一个服务主体。此服务主体的权限会持久保留，因此强烈建议仅授予所需的最小权限，并保持帐户受监视和保护。

将此帐户的机密或证书安全地存储在 Azure Key Vault 中。强烈建议将密钥保管库放在专用管理资源组中。

级别 4 服务主体

级别 4 服务主体具有最受限的权限。这些服务主体授权某人执行仅限于一个资源的管理任务。

建议尽可能使用托管标识。如果使用非托管标识，请将机密或证书安全地存储在存储级别 3 机密的 Azure Key Vault 中。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。有关详细信息，请参阅卓越运营支柱概述。

Microsoft Sentinel 解决方案由三个部分组成，它们可确保成功完成操作。

第一个部分是环境定义，它构成了基本的体系结构元素。对于此部分，主要考虑要部署的生产和非生产环境的数量，并确保设置在所有情况下都是同质的。

第二个部分是 Microsoft Sentinel 连接器部署，需要考虑团队所需的连接器类型以及启用连接器的安全要求。

第三个部分是 Microsoft Sentinel 项目生命周期管理，涵盖组件编码、部署和使用或销毁。例如，此部分包含分析规则、playbook、工作簿、威胁搜寻等。

请考虑项目之间的以下依赖项：

分析规则中定义的自动化规则
需要新数据源或连接器的工作簿或分析
管理现有组件的更新
- 如何对项目进行版本控制
- 如何识别、测试和部署更新或全新的分析规则

生成、测试并部署基础结构

在管理 Microsoft Sentinel 解决方案和 DevOps 时，请务必考虑企业体系结构的连接及安全方面。

Azure DevOps 可以使用 Microsoft 托管代理或自承载代理进行生成、测试和部署活动。根据公司的要求，可以使用 Microsoft 托管模型、自承载模型或两种模型的组合。

Microsoft 托管代理。此选项是使用 Azure DevOps 代理的最快方法，因为它是共享于整个组织的基础结构。有关如何在管道中使用 Microsoft 托管代理的详细信息，请参阅 Microsoft 托管代理。 Microsoft 托管代理可以在混合网络环境中工作，授予 IP 范围的访问权限。若要下载这些代理授予访问权限的 IP 范围，请参阅 Azure IP 范围和服务标记 – 公有云。
自托管代理。此选项在为生成和部署安装依赖软件时提供专用资源和更多控制。自承载代理可以在 Azure 上的 VM、规模集和容器中运行。有关自承载代理的详细信息，请参阅 Azure Pipelines 代理。

GitHub 运行程序

GitHub 可以使用 GitHub 托管运行程序或自承载运行程序进行与生成、测试和部署相关的活动。根据公司的需求，可以使用 GitHub 托管模型、自承载模型或两种模型的组合。

GitHub 托管的运行程序

此选项是使用 GitHub 工作流的最快方法，因为它是共享于整个组织的基础结构。有关详细信息，请参阅关于 GitHub 托管的运行器。根据某些网络要求，GitHub 托管代理会在混合网络环境中运行。有关网络要求的详细信息，请参阅支持的运行程序和硬件资源。

自托管运行程序

此选项为公司提供专用资源基础结构。自承载运行程序在 Azure 上的 VM 和容器中运行，并支持自动缩放。

选择运行程序时的考虑因素

为 Microsoft Sentinel 解决方案中的代理和运行程序选择选项时，请考虑以下需求：

贵公司是否需要专用资源以在 Microsoft Sentinel 环境中运行进程？
是否要将生产环境 DevOps 活动的资源与其余环境隔离？
是否需要测试某些需要访问关键资源或仅对内部网络可用的资源的情况？

发布过程的业务流程和自动化

可以使用 Azure DevOps 或 GitHub 设置部署过程。 Azure DevOps 支持使用 YAML 管道或发布管道。有关如何在 Azure DevOps 中使用 YAML 管道的详细信息，请参阅使用 Azure Pipelines。有关如何在 Azure DevOps 中使用发布管道的详细信息，请参阅发布管道。有关如何将 GitHub 与 GitHub Actions 配合使用的详细信息，请参阅了解 GitHub Actions。

Azure DevOps

可以在 Azure DevOps 部署中执行以下部署活动。

使用 YAML 管道自动触发 PR 审批或按需运行。
使用 Azure DevOps 组管理不同环境的服务连接。
在关键环境中，使用服务连接功能和 Azure DevOps 组设置部署审批，以在团队中分配特定用户权限。

GitHub

可以在 GitHub 部署中执行以下部署活动。

使用 GitHub 创建 PR 或部署活动。
使用 GitHub 机密管理服务主体凭据。
通过与 GitHub 关联的工作流集成部署审批。

自动部署 Microsoft Sentinel 基础结构

可以部署一个或多个 Microsoft Sentinel 环境，具体取决于企业的体系结构：

在生产环境中需要多个实例的组织可以在同一租户中为每个地理位置设置不同的订阅。
生产环境中的一个集中式实例提供对同一租户中的一个或多个组织的访问权限。
需要多个环境（例如生产环境、预生产环境、集成环境等）的组可以根据需要创建和销毁环境。

物理环境与逻辑环境定义

在设置环境定义时，有两种选择：物理环境或逻辑环境。两者都有不同的选项和优点：

Microsoft Sentinel 体系结构的元素由基础结构即代码 (IaC) 的以下选项定义：
- Bicep 模板
- Azure 资源管理器模板（ARM 模板）
- Terraform
逻辑定义 - 充当抽象层，用于在组中设置不同的团队并定义其环境。通过使用物理基础结构层，在部署管道和工作流中将此定义设置为生成环境的输入。

定义逻辑环境时，请考虑以下几点：

命名约定
环境标识
连接器和配置

代码存储库

鉴于上一部分中显示的环境方法，请考虑以下 GitHub 代码存储库组织方式。

物理定义 - 基于 IaC 选项考虑一种方法，即使用在主部署定义中链接的单个模块定义。

以下示例演示如何组织代码。

GitHub 中用于物理环境定义的可能代码组织示意图。

将对此存储库的访问限制为在物理级别定义体系结构的团队，确保企业体系结构中的定义同质。

可以根据每个组织的部署策略调整分支和合并策略。如果团队需要从定义开始，请参阅采用 Git 分支策略。

有关 ARM 模板的详细信息，请参阅在部署 Azure 资源时使用链接模板和嵌套模板。

有关如何设置 Bicep 环境的详细信息，请参阅安装 Bicep 工具。有关 GitHub 的详细信息，请参阅 GitHub 流。

逻辑定义用于定义公司的环境。 Git 存储库用于收集公司的不同定义。

以下示例演示如何组织代码。

GitHub 中用于逻辑环境定义的可能代码组织示意图。

存储库反映了不同团队执行的 PR 操作。多个环境由不同的团队定义，并由公司的所有者或审批者批准。

可运行环境部署的特权级别为级别 2。此级别可确保为环境创建具备必要安全性和隐私性的资源组和资源。此级别还设置用户在生产环境和预生产环境中允许具有的操作权限。

如果希望按需拥有测试环境和开发环境，并且能够在完成测试后销毁环境，组织可以实施 Azure DevOps 管道或 GitHub 操作。他们可以使用 Azure DevOps 事件或 GitHub 操作设置计划的触发器，以根据需要销毁环境。

Microsoft Sentinel 连接器自动配置

Microsoft Sentinel 连接器是解决方案的重要组成部分，它支持与企业体系结构环境中的不同元素连接，例如 Microsoft Entra ID、Microsoft 365、Microsoft Defender、威胁情报平台解决方案等。

定义环境时，可使用连接器配置来设置具有同类配置的环境。

服务主体级别模型必须支持包含连接器的 DevOps 模型。这一点很重要，它可确保正确的权限级别，如下表所示。

连接器方案	特权访问模型级别	Azure 最小特权	需要工作流审批
Microsoft Entra ID	级别 0	全局管理员或安全管理员	建议
Microsoft Entra ID 保护	级别 0	全局管理员或安全管理员	建议
Microsoft Defender for Identity	级别 0	全局管理员或安全管理员	建议
Microsoft Office 365	级别 0	全局管理员或安全管理员	建议
Microsoft Cloud App Security	级别 0	全局管理员或安全管理员	建议
Microsoft Defender XDR	级别 0	全局管理员或安全管理员	建议
Microsoft Defender for IOT	级别 2	参与者	建议
Microsoft Defender for Cloud	级别 2	安全读取者	可选
Azure 活动	级别 2	订阅读者	可选
威胁情报平台	级别 0	全局管理员或安全管理员	建议
安全事件	级别 4	无	可选
Syslog	级别 4	无	可选
DNS（预览）	级别 4	无	可选
Windows 防火墙	级别 4	无	可选
通过 AMA 收集的 Windows 安全事件	级别 4	无	可选

Microsoft Sentinel 项目部署

在 Microsoft Sentinel 项目的实现过程中，DevOps 可获取更大范围的关联性，因为每个公司都会创建多个项目来预防攻击和对攻击进行相应补救。

实现这些项目可能是一个团队或多个团队共同的责任。自动生成和项目部署通常是最常见的流程要求，它决定了使用代理和运行程序的方法和条件。

部署和管理 Microsoft Sentinel 项目需要使用 Microsoft Sentinel REST API。有关详细信息，请参阅 Microsoft Sentinel REST API。下图显示了 Azure REST API 堆栈上的 Azure DevOps 管道。

Microsoft Sentinel API 堆栈上的 Azure DevOps 管道示意图。

还可以使用 PowerShell 实现存储库。

如果团队使用 MITRE，请考虑对不同的项目进行分类，并为每个项目指定技巧和方法。确保包含每个项目类型相应的元数据文件。

例如，如果使用 Azure ARM 模板创建新的 playbook，且文件名为 Playbook.arm.json，则添加了名为 Playbook.arm.mitre.json 的 JSON 文件。然后，此文件的元数据会包含与所使用的 MITRE 技巧或方法对应的 CSV、JSON 或 YAML 格式。

按照这种做法，团队可以根据在设置期间完成的作业评估所使用的不同项目类型的 MITRE 覆盖率。

生成工件

生成过程的目的是确保生成质量最高的项目。下图显示了生成过程中可以执行的一些操作。

下载此体系结构的 Visio 文件。

可以在 JSON 或 YAML 格式的描述性架构上建立项目定义，然后验证该架构以避免语法错误。
- 使用 ARM 模板测试工具包验证 ARM 模板。
- 使用 PowerShell 验证自定义模型的 YAML 和 JSON 文件。
验证监视列表设置，并确保定义的无类别域际路由选择 (CIDR) 记录遵循正确的架构，例如 10.1.0.0/16。
将关键字查询语言 (KQL) 查询（可在语法级别进行验证）用于分析规则、搜寻规则和实时流规则（可在语法级别进行验证）。
将 KQL 本地验证设置为一个选项。
在 DevOps 管道中集成 KQL 内联验证工具。
如果要实现的逻辑基于适用于 Azure 自动化的 PowerShell，则可以使用以下元素引入语法验证和单元测试：
- Pester
- PSScriptAnalyzer
基于随项目包含的元数据文件生成 MITRE 清单元数据报告。

导出组件

通常，多个团队会处理多个 Microsoft Sentinel 实例来生成必要的项目并对其进行验证。为了重用现有项目，公司可以设置自动流程，以便从现有环境获取项目定义。自动化还可以提供有关设置期间由不同开发团队创建的任何项目的信息。

下图演示了示例项目提取过程。

下载此体系结构的 Visio 文件。

部署项目

部署过程的目标是：

缩短上市时间。
提高多个团队设置和管理解决方案的绩效。
设置集成测试以评估环境的运行状况。

开发团队使用此过程来确保可以部署、测试和验证正在开发的项目用例。体系结构团队和 SOC 团队在 QA 环境中验证管道质量，并将集成测试用于攻击方案。在测试用例中，团队通常将不同的项目合并为分析规则、修正 playbook、监视列表等。每个用例中都包括模拟攻击，在其中评估整个链，包括引入、检测和修正。

下图显示了部署过程序列，该序列可确保按正确的顺序部署项目。

下载此体系结构的 Visio 文件。

通过将 Sentinel 项目作为代码进行管理，可以灵活地维护操作并在 CI/CD DevOps 管道中自动执行部署。

Microsoft 解决方案为以下项目提供自动化工作流。

项目	自动化工作流
播放列表	代码评审架构验证部署创建、更新、删除监视列表和项
分析规则融合 Microsoft 安全性 ML 行为分析异常已计划	代码评审 KQL 语法验证架构验证 Pester 部署创建、启用、更新、删除、导出警报模板支持
自动化规则	代码评审架构验证部署创建、启用、更新、删除、导出
连接器	代码评审架构验证部署操作：启用、删除（禁用）、更新
搜寻规则	代码评审 KQL 语法验证架构验证 Pester 部署操作：创建、启用、更新、删除、导出
攻略	代码评审 TTK 部署操作：创建、启用、更新、删除、导出
工作簿	部署操作：创建、更新、删除
Runbook	代码评审 PowerShell 语法验证 Pester 部署操作：创建、启用、更新、删除、导出

根据所选的自动化语言，某些自动化功能可能不受支持。下图显示了每种语言支持的自动化功能。

受支持的自动化功能图表示意图。

* 尚未记录的开发中的功能
** Microsoft 操作见解或 Microsoft 见解资源提供程序 API 支持的自动化方法

Azure 自动化

下图显示了使用托管服务标识简化 Microsoft Sentinel 访问的组件。

使用托管服务标识简化 Microsoft Sentinel 访问的示意图。

下载此体系结构的 Visio 文件。

如果需要授予对其他资源的访问权限，请使用托管标识，这可确保使用唯一标识进行所有关键操作。

使用 Azure 自动化设置 playbook。将 PowerShell 脚本用于以下复杂任务和自动化功能：

与需要不同级别凭据并基于 Microsoft Entra ID 或自定义凭据的第三方解决方案集成：
- Microsoft Entra 用户凭据
- Microsoft Entra 服务主体凭据
- 证书身份验证
- 自定义凭据
- 托管标识
实现可重用组织脚本的解决方案，或实现需要使用 PowerShell 命令来避免 playbook 复杂转换的解决方案：
- 基于 PowerShell 的解决方案
- 基于 Python 的解决方案
在修正操作可能会影响云资源和本地资源的混合方案中实现解决方案。

Microsoft Sentinel 存储库

经验丰富的 DevOps 团队可能会考虑使用内置于 Azure DevOps 的 CI/CD 管道在基础结构即代码 (IaC) 中管理 Microsoft Sentinel。产品组了解客户和合作伙伴在构建 Azure DevOps 安全体系结构时面临的挑战，因此以下两项计划有助于：

记录参考体系结构
开发在 Ignite 2021 上公布的新解决方案，称为“Microsoft Sentinel 存储库”

为了便于选择符合团队需求的解决方案，下表比较了功能和技术标准。

用例和功能	Azure DevOps 和 GitHub 自定义方法	Microsoft Sentinel 存储库
我们希望迅速开始部署 Microsoft Sentinel 项目，而无需花费时间定义 Azure DevOps 体系结构组件，例如代理、管道、Git、仪表板、Wiki、服务主体、RBAC、审核等。	不推荐	建议
我们的团队规模较小，且不具备管理 CI/CD 管道所需的技能集。	不推荐	建议
我们希望控制和管理 CI/CD 管道的所有安全方面。	支持	不支持
我们需要在允许开发人员触发部署管道之前集成入口和分支，以便监督集成，如源代码管理、编码评审、回滚、工作流审批等。	支持	部分支持
我们拥有自定义 Git 或存储库结构。	支持	支持
我们不使用资源管理器或 Bicep IaC 语言来生成项目。	支持	不支持
我们希望在一个 Microsoft Entra 租户中集中管理多个 Microsoft Sentinel 工作区的项目部署。	支持	支持
我们希望跨多个 Microsoft Entra 租户集成或扩展 CI/CD 管道。	支持	支持
我们的 playbook 根据订阅、位置、环境等进行了不同的参数化处理。	支持	待定，待记录的指南
我们希望将不同的项目集成到同一存储库中，以撰写用例。	支持	支持
我们希望能够批量删除项目。	支持	不支持

可用性、性能和可伸缩性

为公司的 Azure DevOps 代理选择 Microsoft Sentinel 方案的体系结构时，请考虑以下需求：

生产环境可能需要专用代理池，以便通过 Microsoft Sentinel 环境进行操作。
非生产环境可能会与大量实例共享代理池，以便满足团队的不同需求（CI/CD 做法尤其如此）。
- 攻击模拟方案是可能需要专用代理的特例。考虑是否必须提供专用池来满足测试需要。
使用混合网络方案的组织可能会考虑在网络内部集成代理。

组织可以根据容器创建自己的代理映像。有关详细信息，请参阅在 Docker 中运行自承载代理。

使用 Azure DevOps 的 Microsoft Sentinel 跨租户管理

作为全局 SOC 或 MSSP，你可能需要管理多个租户。 Azure Lighthouse 支持同时跨多个 Microsoft Entra 租户进行缩放操作，便于更高效地完成管理任务。有关详细信息，请参阅 Azure Lighthouse 概述。

跨租户管理在以下方案中尤其有效：

管理客户租户中的 Microsoft Sentinel 资源。
跨多个租户跟踪攻击并查看安全警报。
跨分布在租户中的多个 Microsoft Sentinel 工作区查看事件。

加入客户的方法

加入客户的方法有两种：托管服务套餐和 ARM 模板。

使用 ARM 模板手动加入

如果你不想以服务提供商身份将产品/服务发布到 Azure 市场，或不满足所有要求，可使用 ARM 模板手动加入客户。这是企业方案中最有可能的选项，在方案中，同一企业具有多个租户。

下表对加入方法进行了比较。

注意事项	托管服务套餐	ARM 模板
需要合作伙伴中心帐户	是	否
需满足白银级或黄金级云平台资格级别或 Azure 专家托管服务提供商 (MSP) 状态	是	否
通过 Azure 市场提供给新客户	是	否
可以只向特定客户发布产品/服务	是（仅适用于私有产品/服务，不适用于通过 CSP 计划的经销商获得的订阅）	是
需要客户接受 Azure 门户	是	否
可以借助自动化来加入多个订阅、资源组或客户	否	是
立即提供对新内置角色和 Azure Lighthouse 功能的访问权限	不一定（通常会延迟一段时间才能访问）	是

有关如何发布托管服务套餐的详细信息，请参阅将托管服务套餐发布到 Azure 市场。

有关如何创建 ARM 模板的详细信息，请参阅创建和部署 ARM 模板。

下图演示了 MSSP 租户与客户资源提供程序租户之间通过 Azure Lighthouse 和 Microsoft Sentinel 进行的高级体系结构集成。

下载此体系结构的 Visio 文件。

通过 ARM 模板或 Azure 市场服务产品集成 MSP 产品/服务。
Azure 委派资源管理检查请求是否来自合作伙伴租户，并调用托管服务资源提供程序。
托管服务资源提供程序使用 RBAC 来控制 MSP 的访问。
MSP 对客户资源完成 SecOps 操作。
计费过程将费用视为客户费用。如果客户实体在同一 Microsoft Entra 租户中具有多个单独的工作区，则可能会拆分计费。
数据的安全性和主权取决于客户的租户边界。

跨多个租户的标识

若要使用 Azure DevOps 管理 Microsoft Sentinel，请评估组件的以下设计决策。

使用案例	优点
用于管理 DevOps 操作的全局标识，单个服务主体	此情况适用于涉及所有租户的全局部署过程。使用统一标识有助于访问不同的租户，但会使特定租户的审批操作管理变得复杂。此类标识的保护机制和授权模型对于避免因相关全局影响而导致的非授权使用也至关重要。
用于管理 DevOps 操作的专用标识，多个服务主体	此情况适用于每个租户专用或租户操作要求审批的部署过程。在这种情况下，即时影响减弱，对此标识使用的保护和授权建议也与全局情况相同。

代码存储库组织方式

使用案例	优点
所有租户共用单个代码版本的统一存储库	此用例有助于提供统一版本的存储库代码。在这种情况下，使用统一代码版本管理租户特定版本时，可能需要通过每个用例的分支来提供支持。
每个租户使用特定代码文件夹的统一存储库	此用例是对单个存储库用例的补充。在这里，文件夹结构可以按租户拆分专用项目。
每个租户使用专用存储库	此方法便于隔离管理代码项目。具有不同团队或要求的租户之间能够更加轻松地实现演变。存储库之间需要建立更改合并流程，可能需要进行相应维护。

生成和部署过程

使用案例	优点
所有租户共用单个生成过程	所有租户使用同一版本的项目时，这是实现生成和打包的最简单选项。
每个租户使用单个生成过程	向每个租户部署不同版本的代码。
所有租户共用全局部署过程	全新部署和更新部署应用于所有租户。部署和更新过程的步骤适用于所有租户。
每个租户使用全局部署过程	全新部署和更新部署应用于一个或多个租户。
每个租户使用专用部署过程	针对每个租户调整部署过程。

成本优化

成本优化就是减少不必要的费用和提高运营效率。有关详细信息，请参阅成本优化支柱概述。

解决方案的成本取决于以下因素：

公司每月传输到 Microsoft Sentinel Log Analytics 工作区中的数据量
选择的承诺层级或计费方法，例如即用即付 (PAYG)
数据策略在表级别或全局级别的保留率

有关详细信息，请参阅 Azure 数据类型保留。

若要计算定价，请参阅 Microsoft Sentinel 定价计算器。有关高级定价注意事项和示例的详细信息，请参阅计划 Microsoft Sentinel 的成本。

如果使用以下组件扩展解决方案，可能会产生额外的成本：

playbook - 用于 Azure 逻辑应用和 Azure Functions 的运行时。有关详细信息，请参阅定价详细信息。
导出到外部存储，例如 Azure 数据资源管理器、事件中心或 Azure 存储帐户。
Jupyter Notebook 组件使用的机器学习工作区和计算。

部署此方案

以下部分介绍了部署此方案的步骤，采用的示例用例可涵盖各种 DevOps 流程。

生成并发布 Microsoft Sentinel 框架

首先，在专用存储库（其各个进程都能使用生成的版本）中设置必要的 NuGet 组件。

如果使用的是 Azure DevOps，则可以创建组件源来托管来自适用于 PowerShell 的 Microsoft Sentinel 框架中的不同的 NuGet 包。有关详细信息，请参阅 NuGet 包入门。

如果团队选择 GitHub 注册表，则可以将其作为 NuGet 存储库进行连接，因为它与源协议兼容。有关详细信息，请参阅 GitHub 包简介。

有可用的 NuGet 存储库时，管道将包含 NuGet 的服务连接。这些屏幕截图显示了名为“Microsoft Sentinel NuGet 框架连接”的新服务连接配置。

屏幕截图显示如何创建新的服务连接。

屏幕截图显示如何编辑服务连接。

配置源后，可以直接从 GitHub 的特定分支中导入用于生成 PowerShell 框架的管道。有关详细信息，请参阅生成 GitHub 存储库。本例创建了一个新的管道并选择 GitHub 作为代码源。

另一种选项是将 Git 存储库导入为基于 Git 的 Azure DevOps 存储库。在这两种情况下，若要导入管道，请指定以下路径：

src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml

现在可以首次运行管道。然后，框架将生成并发布到 NuGet 源。

定义 Microsoft Sentinel 环境

开始使用 Microsoft Sentinel 并使用这些示例时，请定义公司中的环境，例如，环境即代码或 EaC。指定每个用例中构成该环境的不同元素。

Microsoft Sentinel 体系结构包含 Azure 中的以下元素：

Log Analytics 工作区 - 此工作区构成了解决方案的基础。此处存储安全相关的信息，工作区是 Kusto 查询语言 (KQL) 的引擎。
Log Analytics 工作区上的 Microsoft Sentinel 解决方案 - 此解决方案通过纳入 SIEM 和 SOAR 功能扩展了 Log Analytics 工作区的功能。
密钥保管库 - 密钥保管库保存修正过程中使用的机密和密钥。
自动化帐户 - 此帐户是可选帐户，用于修正过程。使用的修正过程基于 PowerShell 和 Python runbook。此过程包括一个系统托管标识，该标识根据最佳做法处理不同资源。
用户托管标识 - 此功能充当 Microsoft Sentinel 统一标识层，用于管理 Microsoft Sentinel playbook 和 runbook 之间的交互。
逻辑应用连接 - 这些连接适用于使用用户托管标识的 Microsoft Sentinel、密钥保管库和自动化。
外部逻辑应用连接 - 这些连接适用于修正过程涉及的基于 playbook 的外部资源。
Azure 事件中心 - 此功能是可选功能，用于处理 Microsoft Sentinel 与其他解决方案（例如 Splunk、Azure Databricks 和机器学习以及弹性解决方案）之间的集成。
存储帐户 - 此功能是可选功能，用于处理 Microsoft Sentinel 与其他解决方案（例如 Splunk、Azure Databricks 和机器学习以及弹性解决方案）之间的集成。

通过使用存储库中的示例，可以使用 JSON 文件定义环境，以指定不同的逻辑概念。可用于定义环境的选项可能是文字选项或自动选项。

在文字定义中，指定环境中每个资源的名称和元素，如以下示例所示。

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Literal",
            "ResourceGroupName": "<resource-group-name>"
         }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Literal",
            "LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
            "ManagedIdentityName": "<user-managed-identity-name>",
            "SentinelConnectionName": "<Sentinel-API-connection-name>",
            "KeyVaultName": "<Key-Vault-name>",
            "KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
        },
        "Automation":
        {
            "Type": "Literal",
            "AutomationAccountName": "<automation-account-name>",
            "AutomationAccountConnectionName": "<automation-account-API-connection-name>"
        },
        "Integration":
        {
            "Type": "Literal",
            "EventHubNamespaces": [
                "<Event-Hubs-namespace-1-name>",
                "<Event-Hubs-namespace-2-name>",
                "<Event-Hubs-namespace-3-name>",
                "<Event-Hubs-namespace-4-name>",
                "<Event-Hubs-namespace-5-name>",
                "<Event-Hubs-namespace-6-name>",
                "<Event-Hubs-namespace-7-name>",
                "<Event-Hubs-namespace-8-name>",
                "<Event-Hubs-namespace-9-name>",
                "<Event-Hubs-namespace-10-name>",
            ],
            "StorageAccountName": "<storage-account-name>"
        }
    }
}

在自动定义中，根据命名约定自动生成元素名称，如以下示例所示。

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Automatic"
        }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Automatic"
        },
        "Automation":
        {
            "Type": "Automatic"
        },
        "Integration":
        {
            "Type": "Automatic",
            "MaxEventHubNamespaces": 5
        }
    }
}

可以在 GitHub 存储库的 Microsoft Sentinel 环境路径下找到示例，并在准备用例时将这些示例用作参考。

部署 Microsoft Sentinel 环境

在至少定义了一个环境后，可以创建 Azure 服务连接以与 Azure DevOps 集成。创建服务连接后，将链接的服务主体设置为目标订阅的所有者角色或类似权限级别。

导入用于创建新环境的管道，如以下文件所定义。

src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml
接下来，输入表示此环境的服务连接的名称。
选择存储库中环境定义的分支。 
在“Azure 环境连接”框中输入订阅的 Azure DevOps 服务连接的名称。
输入服务连接用于解析同一订阅中的多个环境的环境名称。
选择要应用于连接器的操作。
如果要使用 PowerShell 框架组件的预发行版，请选择“使用 PowerShell 预发行版项目”。

管道的部署流中包括以下步骤：

部署 NuGet 组件。
使用 NuGet 工具与项目存储库连接。
解析源。
安装所需的模块。
获取环境定义。
验证目标中存在的资源。
如果工作区中没有 Log Analytics 和 Microsoft Sentinel，请添加它们。
如果已有 Log Analytics，请在 Log Analytics 实例上添加 Microsoft Sentinel。
创建托管标识以表示 Microsoft Sentinel 与逻辑应用之间的交互。
创建 Azure Key Vault，并将用于管理机密和密钥的角色分配设置为托管标识。
如果适用，请创建 Azure 自动化帐户并启用系统分配的托管标识。
为系统分配的托管标识设置密钥保管库的角色分配。
如果没有事件中心定义，请创建它们，并设置该定义是否包含集成元素。
为系统分配的托管标识设置密钥保管库的角色分配。
如果没有存储帐户定义，请创建它们，并设置该定义是否包含集成元素。
为系统分配的托管标识设置密钥保管库的角色分配。
部署连接器操作。
在自动化帐户上部署集成 runbook。
如果在环境中定义了逻辑应用连接，则部署这些连接。

销毁 Microsoft Sentinel 环境

不再需要环境（如开发或测试环境）时，可以将其销毁，如以下文件所定义。

src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml

与部署环境管道一样，指定表示该环境的服务连接的名称。

使用 Microsoft Sentinel 环境

环境准备就绪后，可以开始创建项目以设置不同的用例。

从正在使用的环境中导出这些项目，如以下文件所定义。

src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.yml
选择存储库中环境定义的分支。
在“Azure 环境连接”框中输入要导出项目的环境的 Azure DevOps 服务连接的名称。
如果要使用 PowerShell 框架组件的预发行版，请选择“使用 PowerShell 预发行版项目”。
选择用于分析和搜寻规则的格式。

结果中提供了项目输出文件。拥有项目后，可以将输出文件添加到 Git 存储库中。

在 Microsoft Sentinel 环境中生成项目

将项目放置在 Microsoft Sentinel MITRE 用例路径下。根据不同的项目类型设置文件夹结构。

开始生成过程，如以下文件所定义。

src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yaml
选择存储库中环境定义的分支。

有关如何选择用于生成项目的分支的关系图。](./media/build-artifacts-pipeline.png)
如果要使用 PowerShell 框架组件的预发行版，请选择“使用 PowerShell 预发行版项目”。

管道由以下步骤组成：

部署 NuGet 组件。
将 NuGet 工具连接到项目存储库。
解析源。
安装所需的模块。
获取用于验证 ARM 模板的测试工具包框架。
验证 ARM 模板。
验证 PowerShell runbook 代码并执行语法验证。
如果适用，请运行 Pester 单元测试。
验证搜寻和分析规则中的 KQL 语法。

将项目部署到 Microsoft Sentinel 环境

在部署项目时，可以使用 Microsoft Sentinel 存储库或此存储库中的部署管道示例。有关详细信息，请参阅从存储库部署自定义内容。

Microsoft Sentinel 存储库

如果使用 Microsoft Sentinel 存储库，可以设置发布过程，以将项目纳入与每个 Microsoft Sentinel 实例连接的存储库中。将项目提交到存储库中后，创建管道并启用 Microsoft Sentinel 存储库期间，某些步骤会自动完成。

此外，还可以根据本文档中所述的做法自定义 Microsoft Sentinel 存储库执行的部署过程。需要考虑的一个要点是发布审批，通过以下方法可以对其进行设置：

提交项目时的 PR 审批。有关详细信息，请参阅创建拉取请求。
运行部署时的发布管道审批。有关详细信息，请参阅定义审批和检查。

Microsoft Sentinel 部署管道示例

通过使用 Microsoft Sentinel 部署管道示例，可以设置发布过程。

设置发布过程，如以下文件所定义。

src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.yml
选择存储库中环境定义的分支。
在“Azure 环境连接”框中输入要导出项目的环境的 Azure DevOps 服务连接的名称。
如果要使用 PowerShell 框架组件的预发行版，请选择“使用 PowerShell 预发行版项目”。

作者

本文由 Microsoft 维护，它最初是由以下贡献者撰写的。

主要作者：

Kevin Kisoka | 助理架构师

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

若要了解单租户体系结构中包含 DevOps 的 Microsoft Sentinel 的信息，请参阅部署和管理 Microsoft Sentinel 即代码。
若要了解如何设计跨多个Microsoft Entra 目录工作的 MSSP 体系结构，请参阅将 Azure Lighthouse 与 Microsoft Sentinel 的 DevOps 功能相结合。
有关用于 Microsoft Sentinel 的托管标识的信息，请参阅新增功能：Microsoft Sentinel 逻辑应用连接器的托管标识。
若要了解如何从 Microsoft Sentinel 存储库部署内容，请参阅从存储库部署自定义内容。
要了解 Azure DevOps 安全注意事项，请参阅默认权限快速参考。
若要了解如何保护 Azure DevOps 存储库，请参阅为存储库资源添加保护。
有关如何管理 Azure DevOps 服务连接安全性的信息，请参阅 Azure Pipelines 中的服务连接。

通过

自动实现 Sentinel 与 Azure DevOps 的集成

体系结构

数据流

数据流示例

组件

方案详细信息

可能的用例

基于 MITRE 的威胁定义攻击方案

注意事项

安全性

特权访问模型

级别 0 服务主体

级别 1 服务主体

级别 2 服务主体

级别 3 服务主体

级别 4 服务主体

卓越运营

生成、测试并部署基础结构

GitHub 运行程序

发布过程的业务流程和自动化

Azure DevOps

GitHub

自动部署 Microsoft Sentinel 基础结构

物理环境与逻辑环境定义

代码存储库

Microsoft Sentinel 连接器自动配置

Microsoft Sentinel 项目部署

生成工件

导出组件

部署项目

Azure 自动化

Microsoft Sentinel 存储库

可用性、性能和可伸缩性

使用 Azure DevOps 的 Microsoft Sentinel 跨租户管理

加入客户的方法

使用 ARM 模板手动加入

跨多个租户的标识

代码存储库组织方式

生成和部署过程

成本优化

部署此方案

生成并发布 Microsoft Sentinel 框架

定义 Microsoft Sentinel 环境

部署 Microsoft Sentinel 环境

销毁 Microsoft Sentinel 环境

使用 Microsoft Sentinel 环境

在 Microsoft Sentinel 环境中生成项目

将项目部署到 Microsoft Sentinel 环境

Microsoft Sentinel 存储库

Microsoft Sentinel 部署管道示例

作者

后续步骤

相关资源

反馈

其他资源