共用方式為

保护Microsoft Sentinel中的 MSSP 知识产权

重要

注意：所有 Microsoft Sentinel 功能将根据 世纪互联发布的公告 于 2026年8月18日 在中国地区的 Azure 正式停用。

本文介绍托管安全服务提供商（MSSP）可用于保护他们在Microsoft Sentinel中开发的知识产权的方法，例如Microsoft Sentinel分析规则、搜寻查询、运行簿和工作簿。

选择的方法取决于每个客户如何购买 Azure：无论是您作为云解决方案提供商 (CSP) 行事，还是客户拥有企业协议 (EA) / 预付 (PIA)账户。 下面各部分分别介绍了每种方法。

云解决方案提供商 (CSP)

作为云解决方案提供商（CSP）如果您转售Azure，则需要管理客户的Azure订阅。 由于 Admin-On-Behalf-Of（AOBO），MSSP 租户中的管理员代理组中的用户被授予对客户的Azure订阅的所有者访问权限，并且客户默认没有访问权限。

如果 MSSP 租户中的其他用户在管理员代理组外部需要访问客户环境，建议使用 Azure Lighthouse。 Azure Lighthouse使你能够使用其中一个内置角色授予具有特定作用域（例如资源组或订阅）访问权限的用户或组。

如果需要向客户用户提供对Azure环境的访问权限，建议在 resource group 级别授予他们访问权限，而不是整个订阅，以便根据需要显示/隐藏环境的各个部分。

例如：

  • 可以向客户授予对其应用程序所在的多个资源组的访问权限，但仍将Microsoft Sentinel工作区保留在客户没有访问权限的单独资源组中。

  • 使用此方法可以使客户能够查看选定的工作簿和 playbook，它们是可驻留在其各自资源组中的独立资源。

即使客户在资源组级别授予访问权限，也有权访问其可以访问的资源的日志数据，例如 VM 中的日志，即使无法访问Microsoft Sentinel也是如此。 有关详细信息，请参阅按资源对Microsoft Sentinel数据进行管理访问。

提示

如果需要为客户提供对整个订阅的访问权限，请查看企业协议 (EA)/提前支付 (PIA) 中的指南。

Microsoft Sentinel CSP 体系结构示例

下图说明了向 CSP 客户提供访问权限时，上一部分中所述的权限的工作原理：

这张图像中：

  • 拥有对 CSP 订阅的 Owner 访问权限的用户是 MSSP Microsoft Entra 租户中的管理员代理组内的用户。

  • MSSP 中的其他组可通过Azure Lighthouse访问客户环境。

  • 客户对Azure资源的访问权限由资源组级别的 Azure RBAC 管理。

    这允许 MSSP 根据需要隐藏Microsoft Sentinel组件，例如分析规则和搜寻查询。

有关详细信息，请参阅 Azure Lighthouse 文档。

企业协议 (EA)/提前支付 (PIA)

如果客户直接从Microsoft购买，则客户已拥有对Azure环境的完全访问权限，并且无法隐藏客户Azure订阅中的任何内容。

相反，根据需要保护的资源类型，保护Microsoft Sentinel中开发的知识产权，如下所示：

分析规则和搜寻查询

分析规则和搜寻查询都包含在Microsoft Sentinel中，因此无法与Microsoft Sentinel工作区分开。

即使用户只有 Microsoft Sentinel 阅读者权限，他们也可以查看查询。 在这种情况下，建议你在自己的 MSSP 租户而不是客户租户中托管分析规则和搜寻查询。

为此，需要在自己的租户中启用Microsoft Sentinel工作区，还需要通过 Azure Lighthouse 查看客户工作区。

若要在引用客户租户中的数据的 MSSP 租户中创建分析规则或搜寻查询，必须使用 workspace 语句，如下所示：

workspace('<customer-workspace-explicit-identifier>').SecurityEvent
| where EventID == '4625'

在将workspace语句添加到分析规则时，请考虑以下内容：

  • 为了获得最佳性能，请在跨工作区查询中使用客户的显式工作区标识符。 有关详细信息，请参阅跨工作区查询的标识符格式。

  • 客户工作区中不应包含警报。 通过这种方式创建的规则不会在客户工作区中创建警报或事件。 警报和事件只会存在于 MSSP 工作区中。

  • 为每位客户创建单独的警报。 使用此方法时，我们还建议为每位客户和每次检测使用单独的预警规则，因为工作区语句在每种情况下会有所不同。

    可以将客户名称添加到预警规则名称中，以便轻松识别触发警报的客户。 单独的警报可能会导致大量规则，你可能希望使用脚本或以代码形式的Microsoft Sentinel来管理。

    例如：

    在 MSSP 工作区中为每位客户创建单独的规则。

  • 为每位客户创建单独的 MSSP 工作区。 为每位客户和每次检测创建单独的规则可能会达到工作区的最大分析规则数 (512)。 如果你有很多客户并预计将达到此限制，则可能需要为每位客户创建一个单独的 MSSP 工作区。

    例如：

    在 MSSP 租户中为每位客户创建工作区和规则。

重要

若要成功使用此方法，关键在于使用自动化来管理工作区中的众多规则。

有关详细信息，请参阅跨工作区的分析规则

工作簿

如果已开发不希望客户复制的Microsoft Sentinel工作簿，请在 MSSP 租户中托管工作簿。 确保你有权通过Azure Lighthouse访问客户工作区，然后确保修改工作簿以使用这些客户工作区。

例如：

跨工作区的工作簿

有关详细信息，请参阅跨工作区的工作簿。

如果希望客户能够查看工作簿可视化效果，同时仍保留代码机密，建议将工作簿导出到Power BI。

将工作簿导出到Power BI：

  • 使工作簿可视化更易于共享。 可以向客户发送指向Power BI仪表板的链接，他们可以在其中查看报告的数据，而无需Azure访问权限。
  • 启用计划。 配置Power BI以定期发送包含该时间仪表板快照的电子邮件。

有关详细信息，请参阅 将 Azure Monitor 日志数据导入 Power BI 中。

playbook

可以按以下方式保护 playbook，具体取决于触发 playbook 的分析规则的创建位置：

  • 在 MSSP 工作区中创建的分析规则。 请确保在 MSSP 租户中创建 playbook，并从 MSSP 工作区获取所有事件和警报数据。 可在工作区中创建新规则时，请附加 playbook。

    例如：

    在 MSSP 工作区中创建的规则。

  • 在客户工作区中创建的分析规则。 使用 Azure Lighthouse 将客户工作区中的分析规则链接到 MSSP 工作区中托管的 playbook。 在这种情况下，playbook 将从客户工作区中获取警报和事件数据以及所有其他客户信息。

    例如：

    在客户工作区中创建的规则。

在这两种情况下，如果 playbook 需要访问客户的 Azure 环境，请使用通过 Lighthouse 拥有访问权限的用户或服务主体。

但是，如果 playbook 需要访问客户租户中的非 Azure 资源（例如 Microsoft Entra ID 或 Office 365），请在客户租户中创建具有适当权限的服务主体，然后在 playbook 中添加该标识。

注意

如果将自动化规则与 playbook 结合使用，则必须在 playbook 所在的资源组上设置自动化规则权限。 有关详细信息，请参阅运行 playbook 的自动化规则的权限。

后续步骤

有关详细信息，请参阅：

  • Last updated on