设计 Log Analytics 工作区体系结构

对于使用 Azure Monitor 和 Microsoft Sentinel 的许多环境,单个 Log Analytics 工作区可能就足够了。 但许多组织将创建多个工作区以优化成本并更好地满足不同的业务需求。 本文将陈述一套有关是要使用单个工作区还是多个工作区的准则。 本文还讨论了这些工作区的配置和放置,以满足你的要求,同时优化成本。

注意

本文讨论 Azure Monitor 和 Microsoft Sentinel,因为许多客户在设计时需要考虑这两者。 大多数决策标准都适用于这两个服务。 如果你只使用其中一项服务,则可能在评估中忽略另一项。

设计策略

设计应始终从单个工作区开始,这可以降低管理多个工作区和从中查询数据的复杂性。 工作区中的数据量不会造成性能限制。 多个服务和数据源可以将数据发送到同一工作区。 确定创建更多工作区的准则时,设计应使用符合要求的最少数量。

设计工作区配置的过程包括评估多个准则。 但某些准则可能会发生冲突。 例如,可以通过在每个 Azure 区域中创建一个单独的工作区来减少传出费用。 合并到单个工作区可以通过承诺层级进一步减少费用。 单独评估每个准则。 考虑要求和优先级,确定哪种设计对你的环境最有效。

设计条件

下表列出了在设计工作区体系结构时要考虑的准则。 后面的部分描述了准则。

条件 说明
操作和安全数据 你可以选择将来自 Azure Monitor 的操作数据与来自 Microsoft Sentinel 的安全数据合并到同一工作区中,也可以将它们各自存放在一个单独的工作区中。 将它们合并在一起可让你更好地了解所有数据,但安全标准可能要求将它们分开存放,以便为安全团队提供一个专用的工作区。 你还可能会对每个策略有成本要求。
Azure 租户 如果你有多个 Azure 租户,则通常你会在每个租户中创建一个工作区。 多个数据源只能将监视数据发送到同一 Azure 租户中的工作区。
Azure 区域 每个工作区驻留在特定的 Azure 区域中。 你可能需要满足有关将数据存储在特定位置的管制或合规性要求。
数据所有权 可以选择创建单独的工作区来定义数据所有权。 例如,可以按子公司或附属公司创建工作区。
拆分计费 通过将工作区放在单独的订阅中,不同的参与方都可以对其计费。
数据保留和存档 你可以为每个工作区和工作区中的每个表设置不同的保留设置。 如果将数据发送到相同表的不同资源需要不同的保留设置,则你需要创建单独的工作区。
承诺层级 使用承诺层级,可以通过在单个工作区中承诺最少量的每日数据来降低引入成本。
旧版代理程序的局限性 旧版虚拟机代理对其可以连接的工作空间数量有限制。
数据访问控制 配置对工作区以及来自不同资源的不同表和数据的访问。
复原能力 为了确保工作区中的数据在发生区域故障时可用,可以将数据引入到不同区域中的多个工作区。

操作和安全数据

是要将来自 Azure Monitor 的操作数据与来自 Microsoft Sentinel 的安全数据合并在同一工作区中,还是将它们各自存放在一个单独的工作区中,这取决于具体的安全要求以及对环境的潜在成本要求。

专用工作区:为 Azure Monitor 和 Microsoft Sentinel 创建专用工作区可让你在运营团队和安全团队之间分离数据的所有权。 这种方法还有助于优化成本,因为如果在一个工作区中启用了 Microsoft Sentinel,则该工作区中的所有数据都受 Sentinel 定价的影响,即使数据是由 Azure Monitor 收集的操作数据。

使用 Microsoft Sentinel 的工作区可以免费保留 3 个月数据,而不是 31 天。 此方案通常会导致在没有 Microsoft Sentinel 的工作区中操作数据的成本更高。 请参阅 Azure Monitor 日志定价详细信息

合并工作区:通过在同一工作区中对来自 Azure Monitor 和 Microsoft Sentinel 的数据进行梳理,可以更好地了解所有数据,从而轻松地将两者合并到查询和工作簿中。 如果对安全数据的访问权限应限制在特定团队范围内,则可以使用表级别 RBAC 来阻止特定用户访问包含安全数据的表,或限制用户使用资源上下文来访问工作区。

如果此配置有助于你达到某个承诺层级(该层级可为引入费用提供折扣),则可以节省成本。 例如,假设一个组织每天引入约 50 GB 的操作数据和安全数据。 在同一工作区中组合数据将支持每天 100 GB 的承诺层级。 该方案将为 Azure Monitor 提供 15% 的折扣,为 Microsoft Sentinel 提供 50% 的折扣。

如果你为其他条件创建单独的工作区,则通常会创建更多工作区对。 例如,如果有两个 Azure 租户,可以创建四个工作区 - 每个租户中的一个操作和安全工作区。

  • 如果同时使用 Azure Monitor 和 Microsoft Sentinel:如果安全团队有相应要求或可节省成本,请考虑将两种类型的数据各自存放在一个专用工作区中。 如需更好地了解合并的监视数据,或者如果合并有助于达到承诺层级,请考虑将这两者合并在一起。
  • 如果同时使用 Microsoft Sentinel 和 Microsoft Defender for Cloud:请考虑为这两种解决方案使用相同的工作区,以将安全数据保存在一个位置。

Azure 租户

大多数资源只能将监视数据发送到同一 Azure 租户中的工作区。 使用 Azure Monitor 代理Log Analytics 代理的虚拟机可以将数据发送到单独 Azure 租户中的工作区。 可将此方案视为服务提供商

  • 如果你只有一个 Azure 租户:为该租户创建单个工作区。
  • 如果你有多个 Azure 租户:为每个租户创建一个工作区。 有关其他选项(包括服务提供商策略),请参阅多租户策略

Azure 区域

每个 Log Analytics 工作区军驻留在特定的 Azure 区域中。 你可能出于法规或合规性目的将数据保存在特定区域中。

  • 如果需要将数据保留在特定地理位置:为具有此类要求的每个区域创建单独的工作区。
  • 如果不需要将数据保留在特定地理位置:为所有区域使用单个工作区。

另请考虑到将数据从另一个区域中的资源发送到工作区时可能收取的带宽费用。 对于大多数客户而言,这些费用相比数据引入费用通常微不足道。 这些费用通常是从虚拟机向工作区发送数据时产生的。 使用诊断设置监视来自其他 Azure 资源的数据不会产生传出费用

使用 Azure 定价计算器来估算成本,并确定所需的区域。 如果带宽费用很高,请考虑多个区域的工作区。

  • 如果带宽费用足以证明额外复杂性的合理性:为每个使用虚拟机的区域创建单独的工作区。
  • 如果带宽费用不足以证明额外复杂性的合理性:为所有区域使用单个工作区。

数据所有权

你可能需要根据所有权隔离数据或定义边界。 例如,你可能有不同的子公司或附属公司需要描述其监视数据。

  • 如果需要数据隔离:为每个数据所有者使用单独的工作区。
  • 如果不需要数据隔离:为所有数据所有者使用单个工作区。

拆分计费

你可能需要在不同方之间拆分计费或向客户或内部业务部门收取费用。 可使用 Azure 成本管理 + 计费来按工作区查看费用。 你还可以使用日志查询按 Azure 资源、资源组或订阅查看可计费数据量。 此方法可能足以满足计费要求。

  • 如果不需要拆分计费或退款:请对所有成本所有者使用单个工作区。
  • 如果需要拆分计费或退款:请考虑 Azure 成本管理 + 计费或日志查询是否能提供满足要求的足够精细成本报告。 如果不能,请为每个成本所有者使用单独的工作区。

数据保留和存档

可以为工作区配置默认数据保留和归档设置,或为每个表配置不同设置。 对于特定表中的不同数据集,你可能需要不同的设置。 如果是这样,你需要将该数据隔离到不同的工作区,并在每个工作区中使用独特的保留设置。

  • 如果你可以对每个表中的所有数据使用相同的保留和存档设置:为所有资源使用单个工作区。
  • 如果需要对同一表中的不同资源使用不同的保留和存档设置:为不同的资源使用单独的工作区。

承诺层级

如果你承诺每天提交特定数量的数据,承诺层级会为你的工作区引入成本提供折扣。 你可以选择在单个工作区中合并数据以达到特定层级的级别。 除非你有专用群集,否则跨多个工作区分布的相同数据量不符合同一层级的条件。

如果你可以承诺每天至少引入 100 GB,那么你应该实现一个专用群集来提供额外的功能和性能。 专用集群还允许你合并来自群集中多个工作区的数据,以达到承诺层级。

  • 如果你将在所有资源中每天至少引入 100 GB:请创建一个专用群集并设置适当的承诺层级。
  • 如果你每天要引入所有资源的至少 100 GB 数据:考虑将它们组合到单个工作区以利用承诺层级。

旧版代理程序的局限性

应避免将重复数据发送到多个工作区(因为会产生额外费用),但可以将虚拟机连接到多个工作区。 最常见的场景是代理连接到 Azure Monitor 和 Microsoft Sentinel 的单独工作区。

Azure Monitor 代理适用于 Windows 的 Log Analytics 代理可以连接到多个工作区。 适用于 Linux 的 Log Analytics 代理只能连接到单个工作区。

  • 如果使用适用于 Linux 的 Log Analytics 代理:迁移到 Azure Monitor 代理或确保你的 Linux 计算机只需要访问单个工作区。

数据访问控制

当你授予用户访问工作区的权限时,该用户有权访问该工作区中的所有数据。 此访问权限适用于必须访问所有资源的数据的中心管理或安全团队的成员。 对工作区的访问权限还取决于资源上下文基于角色的访问控制 (RBAC) 和表级 RBAC。

资源上下文 RBAC:默认情况下,如果用户对某个 Azure 资源拥有读取访问权限,则他们将继承对该资源的、发送到工作区的任何监视数据的权限。 这种访问级别允许用户访问有关自己管理的资源的信息,而无需被授予对工作区的显式访问权限。 如果你需要阻止此访问权限,可以更改访问控制模式以要求显式的工作区权限。

  • 如果你希望用户能够访问其资源的数据:保留默认访问控制模式“使用资源或工作区权限”。
  • 如果你要为所有用户显式分配权限:将访问控制模式更改为“需要工作区权限”。

表级 RBAC:使用表级 RBAC 可以授予或拒绝对工作区中特定表的访问权限。 这样,就可以实现环境中特定情况所需的精细权限。

例如,你可以仅将 Microsoft Sentinel 收集的特定表的访问权限授予内部审计团队。 如果资源所有者需要的是与其自己资源相关的操作数据,你也可以拒绝资源所有者访问与安全相关的表。

  • 如果不需要按表进行精细访问控制:请授予操作和安全团队对其资源的访问权限,并允许资源所有者对其资源使用资源上下文 RBAC。
  • 如果需要按表进行精细访问控制:请使用表级别 RBAC 授予或拒绝对特定表的访问权限。

复原能力

为了确保工作区中的关键数据在发生区域故障时可用,可以将部分或所有数据引入到不同区域中的多个工作区中。

此选项需要为每个工作区单独管理与其他服务和产品的集成。 即使发生故障时备用工作区中的数据仍可用,但依赖于这些数据的资源(如警报和工作簿)并不知道要切换到备用工作区。 请考虑使用 Azure DevOps 中的备用工作区的配置来存储关键资源的 ARM 模板,或者将其存储为可在故障转移方案中快速启用的禁用策略。

使用多个工作区

许多设计将包含多个工作区,因此 Azure Monitor 和 Microsoft Sentinel 包含的某些功能可以帮助你跨工作区分析此数据。 有关详细信息,请参阅:

多租户策略

包含多个 Azure 租户的环境(包括 Microsoft 服务提供商 (MSP)、独立软件供应商 (ISV) 和大型企业)通常需要一种策略,以便其中的中心管理团队可以访问位于其他租户中的管理工作区。 每个租户可能代表不同的客户或不同的业务单位。

注意

对于加入云解决方案提供商 (CSP) 计划的合作伙伴和服务提供商,Azure Monitor 中的 Log Analytics 是 Azure CSP 订阅中可用的 Azure 服务之一。

以下部分介绍了此功能的两个基本策略。

分布式体系结构

在分布式体系结构中,在每个 Azure 租户中创建 Log Analytics 工作区。 如果你正在监视虚拟机以外的 Azure 服务,这是你的唯一选择。

有两个选项可让服务提供商管理员访问客户租户中的工作区:

  • 使用 Azure Lighthouse 访问每个客户租户。 服务提供商管理员包含在服务提供商租户的 Microsoft Entra 用户组中。 在加入过程中,每个客户都向此组授予访问权限。 然后,这些管理员可以从自己的服务提供商租户访问每个客户的工作区,而无需单独登录到每个客户的租户。 有关详细信息,请参阅大规模监视客户资源
  • 将服务提供商中的个人用户添加为 Microsoft Entra 来宾用户 (B2B)。 客户租户管理员管理每个服务提供商管理员的个人访问权限。 服务提供商管理员必须登录到 Azure 门户中每个租户的目录才能访问这些工作区。

此策略的优点:

  • 可以从所有类型的资源中收集日志。
  • 客户可以使用 Azure 委派资源管理来确认特定级别的权限。 或者,客户可以使用自己的 Azure RBAC 管理对日志的访问。
  • 每个客户都可以为其工作区设置不同的设置,例如保留期和数据上限。
  • 在客户之间进行隔离以遵守监管和合规要求。
  • 客户订阅账单中包含每个工作区的费用。

此策略的缺点:

  • 使用 Azure Monitor 工作簿等工具来集中可视化和分析不同客户租户的数据可能会导致体验变慢。 在分析 50 个以上的工作区的数据时尤其如此。
  • 如果未为客户完成 Azure 委托资源管理的加入,则必须在客户目录中预配服务提供商管理员。 这项要求使得服务提供商一次性管理大量客户租户的难度更大。

集中式

在服务提供商的订阅中创建一个工作区。 此选项只能从客户虚拟机收集数据。 虚拟机上安装的代理被配置为将其日志发送到此中央工作区。

此策略的优点:

  • 可以轻松管理大量客户。
  • 服务提供商对日志和各种项目(例如函数和保存的查询)拥有完全所有权。
  • 服务提供商可以对其所有客户执行分析。

此策略的缺点:

  • 只能从安装了代理的虚拟机收集日志。 它不适用于 PaaS、SaaS 或 Azure Service Fabric 数据源。
  • 由于客户的数据共享单个工作区,因此在客户之间隔离数据可能很困难。 查询需要使用计算机的完全限定域名或 Azure 订阅 ID。
  • 来自所有客户的全部数据都将存储在具有单独账单和相同保留期及配置设置的同一区域中。

混合

在混合模型中,每个租户具有自身的工作区。 可以使用一种机制将数据拉取到中心位置进行报告和分析。 此数据可以包含少量数据类型,或者每日统计数据等活动摘要。

在中心位置实现日志有两种选择:

  • 中心工作区:服务提供商在其租户中创建一个工作区,并使用一个脚本,该脚本利用 Query API日志引入 API 将来自租户工作区的数据带到这个中心位置。 另一种选择是使用 Azure 逻辑应用将数据复制到中央工作区。
  • Power BI:租户工作区使用 Log Analytics 工作区和 Power BI 之间的集成将数据导出到 Power BI。

后续步骤