对于使用 Azure Monitor 和 Microsoft Sentinel 的许多环境,单个 Log Analytics 工作区可能就足够了。 但许多组织都会创建多个工作区,以优化成本并更好地满足不同的业务需求。 本文将陈述一套有关是要使用单个工作区还是多个工作区的准则。 本文还讨论了这些工作区的配置和放置,以满足你的要求,同时优化成本。
注意
本文讨论 Azure Monitor 和 Microsoft Sentinel,因为许多客户在设计时需要考虑这两者。 大多数决策标准都适用于这两个服务。 如果只使用这些服务之一,请忽略评估中的另一个服务。
设计策略
设计应始终从单个工作区开始,这可以降低管理多个工作区和从中查询数据的复杂性。 工作区中的数据量不会施加性能限制。 多个服务和数据源可以将数据发送到同一工作区。 确定创建更多工作区的条件时,设计应使用最少数量的工作区来满足你的要求。
设计工作区配置的过程包括评估多个准则。 但某些准则可能会发生冲突。 例如,你可以通过在每个 Azure 区域中创建单独的工作区来降低出口费用。 整合到一个工作区后,您还可能通过承诺套餐进一步降低费用。 单独评估每个准则。 请考虑你的需求和优先级,以确定哪种设计对你的环境最有效。
设计条件
下表列出了在设计工作区体系结构时要考虑的准则。 后面的部分描述了准则。
| 条件 | 说明 |
|---|---|
| 操作和安全数据 | 你可以选择将来自 Azure Monitor 的操作数据与来自 Microsoft Sentinel 的安全数据合并到同一工作区中,也可以将它们各自存放在一个单独的工作区中。 将它们合并在一起可让你更好地了解所有数据,但安全标准可能要求将它们分开存放,以便为安全团队提供一个专用的工作区。 你还可能需要考虑每种策略的成本影响。 |
| Microsoft Entra 租户 | 如果有多个Microsoft Entra租户,通常会在每个租户中创建一个工作区。 多个数据源只能将监视数据发送到同一Microsoft Entra租户中的工作区。 |
| 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% 的折扣。
如果你为其他条件创建单独的工作区,则通常会创建更多工作区对。 例如,如果您有两个 Microsoft Entra 租户,则可以创建四个工作区,在每个租户中分别设置一个运营工作区和一个安全工作区。
- 如果同时使用 Azure Monitor 和 Microsoft Sentinel:如果安全团队有相应要求或可节省成本,请考虑将两种类型的数据各自存放在一个专用工作区中。 如需更好地了解合并的监视数据,或者如果合并有助于达到承诺层级,请考虑将这两者合并在一起。
- 如果同时使用 Microsoft Sentinel 和 Microsoft Defender for Cloud:请考虑为这两种解决方案使用相同的工作区,以将安全数据保存在一个位置。
Microsoft Entra 租户
大多数资源只能将监视数据发送到同一Microsoft Entra租户中的工作区。 使用 Azure Monitor Agent 或 Log Analytics 代理的虚拟机可以将数据发送到单独的Microsoft Entra租户中的工作区。 您可以作为服务提供商来考虑这种情况。
- 如果你只有一个 Microsoft Entra 租户:为该租户创建一个工作区。
- 如果有多个Microsoft Entra租户:为每个租户创建工作区。 有关其他选项(包括服务提供商策略),请参阅多租户策略。
Azure 区域
每个 Log Analytics 工作区军驻留在特定的 Azure 区域中。 你可能出于法规或合规性目的将数据保存在特定区域中。
- 如果需要将数据保留在特定地理位置:为具有此类要求的每个区域创建单独的工作区。
- 如果不需要将数据保留在特定地理位置:为所有区域使用单个工作区。
如果要将数据发送到工作区区域之外的地理位置或区域,无论发送资源是否驻留在 Azure :请考虑使用与数据位于同一地理位置或区域中的工作区。
另请考虑到将数据从另一个区域中的资源发送到工作区时可能收取的带宽费用。 对于大多数客户而言,这些费用相比数据引入费用通常微不足道。 这些费用通常是从虚拟机向工作区发送数据时产生的。 使用诊断设置监视来自其他 Azure 资源的数据不会产生传出费用。
使用 Azure 定价计算器来估算成本,并确定所需的区域。 如果带宽费用很高,请考虑多个区域的工作区。
- 如果带宽费用足以证明额外复杂性的合理性:为每个使用虚拟机的区域创建单独的工作区。
- 如果带宽费用不足以证明额外复杂性的合理性:为所有区域使用单个工作区。
数据所有权
你可能需要根据所有权隔离数据或定义边界。 例如,你可能有不同的子公司或附属公司需要描述其监视数据。
- 如果需要数据隔离:为每个数据所有者使用单独的工作区。
- 如果不需要数据隔离:为所有数据所有者使用单个工作区。
拆分计费
你可能需要在不同责任方之间分摊费用,或将费用转嫁给客户或内部业务单元。 Azure 成本管理 + 计费显示按工作区划分的费用明细。 日志查询还可以通过Azure资源、资源组或订阅显示可计费的数据量。 此方法可能足以满足计费要求。
- 如果不需要拆分计费或退款:请对所有成本所有者使用单个工作区。
- 如果需要拆分计费或退款:请考虑 Azure 成本管理 + 计费或日志查询是否能提供满足要求的足够精细成本报告。 如果无法做到,请为每位成本负责人使用单独的工作区。
数据保留
为工作区配置默认 数据保留设置 ,或 为每个表配置不同的设置。 在 Azure 门户中,转到 Log Analytics 工作区>你的工作区>表,以查看和修改各个表的保留期。 对于特定表中的不同数据集,你可能需要不同的设置。 如果是这样,请将数据分成不同的工作区,每个工作区都有唯一的保留设置。
- 如果同一保留设置适用于每个表中的所有数据: 对所有资源使用单个工作区。
- 如果你需要为同一表中的不同资源使用不同的保留设置:请分别为不同的资源使用单独的工作区。
承诺层级
如果你承诺每天提交特定数量的数据,承诺层级会为你的工作区引入成本提供折扣。 你可以选择在单个工作区中整合数据,以达到某个层级。 除非你有专用群集,否则跨多个工作区分布的相同数据量不符合同一层级的条件。
如果每日引入量至少达到 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 授予或拒绝对特定表的访问权限。
有关详细信息,请参阅按资源管理对 Microsoft Sentinel 数据的访问。
复原能力
为了确保工作区中的关键数据在发生区域故障时可用,请将部分或所有数据引入到不同区域中的多个工作区中。
此选项需要为每个工作区单独管理与其他服务和产品的集成。 即使发生故障时备用工作区中的数据仍可用,但依赖于这些数据的资源(如警报和工作簿)并不知道要切换到备用工作区。 请考虑使用 Azure DevOps 中的备用工作区的配置来存储关键资源的 ARM 模板,或者将其存储为可在故障转移方案中快速启用的禁用策略。
多工作区注意事项
许多设计包含多个工作区。 例如,中央安全运营团队可能会使用自己的 Microsoft Sentinel 工作区来管理集中式工件,例如分析规则或工作簿。
Azure Monitor 和 Microsoft Sentinel 都包含有助于跨工作区分析此数据的功能。 有关详细信息,请参阅:
命名每个工作区时,请在名称中包含有意义的指示器,以便可以轻松识别每个工作区的用途。
多租户策略
具有多个Microsoft Entra租户的组织通常需要一种策略来管理跨租户边界的工作区。 常见的多租户方案包括:
- 服务提供商:MSP、MSSP 和 ISV,它们代表客户管理各自独立租户中的工作区。
- 企业合并和收购:子公司或收购公司,在集成期间或之后保留单独的租户。
- 环境分离:使用单独的租户进行开发、过渡和生产环境的组织。
在每个方案中,管理中心团队通常需要访问位于其他租户中的工作区。 每个租户可能代表单独的客户、业务部门或环境阶段。
注意
对于加入云解决方案提供商 (CSP) 计划的合作伙伴和服务提供商,Azure Monitor 中的 Log Analytics 是 Azure CSP 订阅中可用的 Azure 服务之一。
以下部分介绍了此功能的两个基本策略。
分布式体系结构
在分布式体系结构中,在每个Microsoft Entra租户中创建Log Analytics工作区。 此选项是唯一可用于监视虚拟机以外的Azure服务。
两个选项允许服务提供商管理员访问客户租户中的工作区:
- 使用 Azure Lighthouse 访问每个客户租户。 服务提供商管理员包含在服务提供商租户的 Microsoft Entra 用户组中。 在加入过程中,每个客户都向此组授予访问权限。 然后,这些管理员可以从自己的服务提供商租户访问每个客户的工作区,而无需单独登录到每个客户的租户。 有关更多信息,请参阅大规模监控客户资源。
- 将服务提供商中的个人用户添加为 Microsoft Entra 来宾用户 (B2B)。 客户租户管理员管理每个服务提供商管理员的个人访问权限。 服务提供商管理员必须登录到 Azure 门户中每个租户的目录才能访问这些工作区。
此策略的优点:
- 可以从所有类型的资源中收集日志。
- 客户可以使用 Azure 委派资源管理来确认特定级别的权限。 或者,客户可以使用自己的 Azure RBAC 管理对日志的访问。
- 每个客户都可以为其工作区设置不同的设置,例如保留期和数据上限。
- 在客户之间进行隔离以遵守监管和合规要求。
- 客户订阅账单中包含每个工作区的费用。
此策略的缺点:
- 在大量工作区上运行查询速度缓慢,而且无法缩放到 100 个工作区以上。 中央可视化和数据分析层是可能的,但如果存在十几个工作区,则速度会很慢。 如果所有工作区都位于同一个专用群集上,那么这种情况不会太严重。 有关详细信息,请参阅 跨工作区运行查询。
- 如果客户尚未载入 Azure 委托资源管理,则必须将服务提供商管理员预配到客户目录中。 这项要求使得服务提供商一次性管理大量客户租户的难度更大。
- 在工作区上运行查询时,工作区管理员可以通过查询审核查看查询的全文。
集中式
在服务提供商的订阅中创建一个工作区。 此选项可以根据诊断设置从客户虚拟机和 Azure PaaS 服务收集数据。 可以将虚拟机上安装的代理和 PaaS 服务配置为将其日志发送到此中央工作区。
此策略的优点:
- 服务提供商从单个工作区管理许多客户。
- 服务提供商对日志和各种项目(例如函数和保存的查询)拥有完全所有权。
- 服务提供商可以对其所有客户执行分析。
此策略的缺点:
- 只能从具有代理或 Azure PaaS 服务的虚拟机(通过 Azure Lighthouse 委派)收集日志。 它不适用于 SaaS 连接器或 Azure Service Fabric 数据源。
- 由于客户的数据共享单个工作区,因此在客户之间隔离数据可能很困难。 查询必须使用计算机的完全限定域名或 Azure 订阅 ID。
- 来自所有客户的全部数据都将存储在具有单独账单和相同保留期及配置设置的同一区域中。
混合
在混合模型中,每个租户具有自身的工作区。 可以使用一种机制将数据拉取到中心位置进行报告和分析。 此数据可以包含少量数据类型,或者每日统计数据等活动摘要。
有多个选项可用于在中心位置实现日志:
-
中心工作区:服务提供商在其租户中创建一个工作区,并通过以下方式从各个工作区拉取数据:
- 使用查询 API 和日志引入 API 的脚本,将数据从租户工作区发送到中心工作区。
- 使用 Azure 逻辑应用,将数据复制到中心工作区。
- 从源工作区导出数据并重新引入到中心工作区。
- Power BI:租户工作区使用 Log Analytics 工作区和 Power BI 之间的集成将数据导出到 Power BI。
后续步骤
- 详细了解如何在工作区中设计和配置数据访问。