你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
设计 Microsoft Sentinel 工作区体系结构
本文提供了一个决策树，旨在帮助用户做出有关如何设计 Microsoft Sentinel 工作区体系结构的重要决策。 有关详细信息，请参阅 Microsoft Sentinel 示例工作区设计和 Microsoft Sentinel 工作区体系结构最佳做法。 本文是 Microsoft Sentinel 部署指南的一部分。
先决条件
在使用该决策树之前，请确保掌握以下信息：
| 先决条件 | 说明 |
|---|---|
| 与 Azure 数据驻留有关的法规要求 | Microsoft Sentinel 可在 Log Analytics 正式发布版支持的大部分区域的工作区中运行，但并不能在支持的所有区域中运行。 新支持的 Log Analytics 区域可能需要一些时间来加入 Microsoft Sentinel 服务。 由 Microsoft Sentinel 生成的数据，例如事件、书签和分析规则，可能包含来源于客户 Log Analytics 工作区的一些客户数据。 有关详细信息，请参阅地理可用性和数据驻留。 |
| 数据源 | 了解需要连接哪些数据源，包括 Microsoft 和非 Microsoft 解决方案的内置连接器。 也可以使用常用事件格式 (CEF)、Syslog 或 REST-API 将数据源与 Microsoft Sentinel 相连接。 如果 Azure VM 位于多个 Azure 位置，则需要从这些位置收集日志，并且节省数据出口流量成本对用户来说很重要，用户需要使用带宽定价计算器计算每个 Azure 位置的数据出口流量成本。 |
| 用户角色和数据访问级别/权限 | Microsoft Sentinel 使用 Azure 基于角色的访问控制 (Azure RBAC) 提供可在 Azure 中分配给用户、组和服务的内置角色。 所有 Microsoft Sentinel 内置角色都授予对 Microsoft Sentinel 工作区中数据的读取访问权限。 因此，需要确定是否需要按数据源或行级别控制数据访问，因为这会影响工作区设计决策。 有关详细信息，请参阅自定义角色和高级 Azure RBAC。 |
| 每日引入速率 | 每日引入速率（通常以 GB/天为单位）是 Microsoft Sentinel 的成本管理和规划注意事项以及工作区设计的关键因素之一。 在大多数云和混合环境中，网络设备（如防火墙或代理）以及 Windows 和 Linux 服务器生成的引入数据最多。 为了获得最准确的结果，Microsoft 建议使用详尽的数据源清单。 此外，Microsoft Sentinel 成本计算器还包括有助于估计数据源的空间占用情况的表格。 重要说明：这些估计只是一个起点，日志详细程度设置和工作负载将会产生差异。 建议定期监视系统，以跟踪任何更改。 建议根据具体情况进行定期监视。 有关详细信息，请参阅 Azure Monitor 日志定价详细信息。 |
决策树
下图显示了一个完整的决策树流程图，有助于了解如何出色地设计工作区。
以下部分提供了该决策树的全文版本，包括图像中引用的以下备注：
备注 1 | 备注 2 | 备注 3 | 备注 4 | 备注 5 | 备注 6 | 备注 7 | 备注 8 | 备注 9 | 备注 10
步骤 1：新工作区还是现有工作区？
是否有可用于 Microsoft Sentinel 的现有工作区？
如果没有，无论如何都要创建一个新的工作区，则直接继续执行步骤 2。
如果有可以使用的现有工作区，请考虑要引入的数据量。
步骤 2：是否将数据保存在不同的 Azure 地理区域中？
如果根据法规要求，需要将数据保存在不同的 Azure 地理区域中，则为每个有合规性要求的 Azure 区域使用单独的 Microsoft Sentinel 工作区。 有关详细信息，请参阅区域注意事项。
如果不需要将数据保存在不同的 Azure 区域，请继续执行步骤 3。
步骤 3：是否有多个 Azure 租户？
如果只有单个租户，请直接继续执行步骤 4。
如果有多个 Azure 租户，请考虑是收集特定于租户边界的日志，例如 办公室 365 或 Microsoft Defender XDR。
如果没有任何特定于租户的日志，请直接继续执行步骤 4。
如果要收集特定于租户的日志，请为每个 Microsoft Entra 租户使用单独的 Microsoft Sentinel 工作区。 继续执行步骤 4，了解其他注意事项。
：特定于租户边界的日志（例如来自 Office 365 和 Microsoft Defender for Cloud 的日志）只能存储在同一租户的工作区中。
虽然可以使用自定义收集器从另一个租户的工作区收集特定于租户的日志，但由于存在以下缺点，不建议这样做：
- 由自定义连接器收集的数据将引入自定义表中。 因此，用户将无法使用所有的内置规则和工作簿。
- UEBA 和机器学习规则等部分内置功能不会考虑自定义表。
- 自定义连接器需要额外的成本和工作量，例如使用 Azure Functions 和逻辑应用。
如果这些缺点对你的组织不是问题，请继续执行步骤 4，无需使用单独的 Microsoft Sentinel 工作区。
步骤 4：是否拆分计费/退款？
如果需要拆分计费或退款，请考虑使用情况报告或手动交叉记帐是否适用。
如果不需要拆分计费或退款，请继续执行步骤 5。
如果确实需要拆分计费或拒付，请考虑使用手动交叉计费。 为了获取每个实体的准确成本，可以使用按实体细分成本的 Microsoft Sentinel 成本工作簿的修改版本。
如果使用情况报告或手动交叉记帐适用，请继续执行步骤 5。
如果使用情况报告或手动交叉记帐均不适用，请为每个成本所有者使用单独的 Microsoft Sentinel 工作区。
：有关详细信息，请参阅 Microsoft Sentinel 成本和计费。
步骤 5：是否收集任何非 SOC 数据？
如果不收集任何非 SOC 数据（如操作数据），可以直接跳到步骤 6。
如果要收集非 SOC 数据，请考虑是否存在任何重叠，因为 SOC 和非 SOC 数据需要使用相同的数据源。
如果 SOC 数据和非 SOC 数据之间存在重叠，则只将重叠数据作为 SOC 数据。 然后，考虑 SOC 数据和非 SOC 数据的引入量是否都低于 100 GB/天，但合并后超过 100 GB/天：
在任一情况下，如需了解详细信息，请参阅备注 10。
如果没有重叠的数据，考虑 SOC 数据和非 SOC 数据的引入量是否都低于 100 GB/天，但合并后超过 100 GB/天：
合并 SOC 数据和非 SOC 数据
决策树备注 3：虽然我们通常建议客户为非 SOC 数据保留一个单独的工作区，以便非 SOC 数据不计入 Microsoft Sentinel 成本，但在某些情况下，合并 SOC 数据和非 SOC 数据比将其分离开的成本更低。
例如，假设一家组织的安全日志引入量为 50 GB/天，操作日志引入量为 50 GB/天，工作区在美国东部区域。
下表比较了包含和不包含单独工作区的工作区选项。
注意
下表所列的成本和条款均为虚设，仅用于说明目的。 有关最新成本的详细信息，请参阅 Microsoft Sentinel 定价计算器。
| 工作区体系结构 | 说明 |
|---|---|
| SOC 团队有自己的工作区，启用了 Microsoft Sentinel。 Ops 团队有自己的工作区，未启用 Microsoft Sentinel。 |
SOC 团队： 按 50 GB/天计算，Microsoft Sentinel 的每月成本为 6,500 美元。 前 3 个月保留期免费。 Ops 团队： - 按 50 GB/天计算，Log Analytics 的每月成本约为 3,500 美元。 - 前 31 天保留期免费。 这两者的每月总成本等于 10,000 美元。 |
| SOC 和 Ops 团队共用相同的工作区，启用了 Microsoft Sentinel。 | 通过合并这两种日志，引入量将达到 100 GB/天，符合享受承诺层级（Sentinel 为 50%，LA 为 15%）的资格。 按照 100 GB/天，Microsoft Sentinel 的每月成本为 9,000 美元。 |
在此示例中，通过合并两个工作区，每月可节省 1,000 美元，而且 Ops 团队还将享有 3 个月免费保留期，而不是只有 31 天。
只有在 SOC 数据和非 SOC 数据的引入量均为高于或等于 50 GB/天且低于 100 GB/天时，此示例才适用。
：建议为非 SOC 数据使用单独的工作区，以便非 SOC 数据不计入 Microsoft Sentinel 成本。
然而，为非 SOC 数据使用单独工作区的建议纯粹是从成本角度考虑的，在决定使用单个或多个工作区时，还需要考虑其他一些重要的设计因素。 为了避免双重引入成本，可以考虑只使用表级别的 Azure RBAC 在单个工作区中收集重叠数据。
步骤 6：是否有多个区域？
如果只从单个区域的 Azure VM 收集日志，请直接继续执行步骤 7。
如果要从多个区域的 Azure VM 收集日志，对数据出口流量成本的关注程度如何？
：数据出口流量是指将数据移出 Azure 数据中心所需的带宽成本。 有关详细信息，请参阅区域注意事项。
如果减少维护单独工作区所需的工作量是优先事项，请继续执行步骤 7。
如果数据出口流量成本足以使维护单独的工作区变得非常重要，则在需要降低数据出口流量成本的每个区域使用单独的 Microsoft Sentinel 工作区。
决策树备注 5：建议使用尽可能少的工作区。 使用 Azure 定价计算器来估算成本，确定实际需要的区域，并为出口流量成本低的区域合并工作区。 与单独的 Microsoft Sentinel 和 Log Analytics 引入成本相比，带宽成本可能只占 Azure 账单的一小部分。
例如，成本可能会按如下所示进行估算：
- 1,000 个 VM，每个 VM 每天生成 1 GB；
- 将数据从美国区域发送到欧洲区域；
- 在代理中使用 2:1 的压缩率
这一估算成本的计算方法为：
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost与单独的 Microsoft Sentinel 和 Log Analytics 工作区的每月成本相比，此示例成本要低得多。
注意
所列成本为虚设，仅用于说明目的。 有关最新成本的详细信息，请参阅 Microsoft Sentinel 定价计算器。
步骤 7：是否分离数据或按所有权定义边界？
如果不需要分离数据或定义任何所有权边界，请直接继续执行步骤 8。
如果需要分离数据或根据所有权定义边界，则每个数据所有者是否需要使用 Microsoft Sentinel 门户？
如果每个数据所有者都必须拥有 Microsoft Sentinel 门户的访问权限，请为每个所有者使用单独的 Microsoft Sentinel 工作区。
：访问 Microsoft Sentinel 门户要求每个用户至少拥有 Microsoft Sentinel 读取者的角色，并对工作区中的所有表拥有读取者权限。 如果用户无权访问工作区中的所有表，则需要使用 Log Analytics 访问搜索查询中的日志。
如果通过 Log Analytics 来访问日志对于无权访问 Microsoft Sentinel 门户的任何所有者来说已足够，请继续执行步骤 8。
有关详细信息，请参阅 Microsoft Sentinel 中的权限。
步骤 8：是否按数据源/表控制数据访问？
如果不需要按数据源或表控制数据访问，可使用单个 Microsoft Sentinel 工作区。
如果需要按数据源或表控制数据访问，可以考虑在以下情况下使用资源上下文 RBAC：
如果需要在行级别控制访问，例如，在每个数据源或表上提供多个所有者
如果有多个自定义数据源/表，且其中每个都需要单独的权限
在其他情况下，如果不需要在行级别控制访问，可以提供多个具有单独权限的自定义数据源/表，使用单个 Microsoft Sentinel 工作区，并使用表级别 RBAC 进行数据访问控制。
有关资源上下文 RBAC 或表级别 RBAC 的注意事项
计划使用资源上下文 RBAC 或表级别 RBAC 时，请注意以下信息：
决策树备注 7：为非 Azure 资源配置资源上下文 RBAC 时，可能需要在向 Microsoft Sentinel 发送数据时将资源 ID 与数据关联，以便使用资源上下文 RBAC 对权限进行限定。 有关详细信息，请参阅显式配置资源上下文 RBAC 和按部署划分的访问模式。
：资源权限或资源上下文使得用户只能查看其有权访问的资源的日志。 工作区访问模式必须设置为“用户资源或工作区权限”。 在 Microsoft Sentinel 中的“日志”页面的搜索结果中，只包括与用户拥有权限的资源相关的表。
：表级别 RBAC 允许在其他权限之外，对 Log Analytics 工作区中的数据进行更精细的控制。 使用此控制措施可以定义仅供特定一组用户访问的特定数据类型。 有关详细信息，请参阅 Microsoft Sentinel 中的表级别 RBAC。
后续步骤
本文介绍了一个决策树，旨在帮助用户做出有关如何设计 Microsoft Sentinel 工作区体系结构的重要决策。