问题
- 是否可以将内容从一个 Azure Log Analytics 工作区转发到另一个?
请注意,我并不是在询问 Log Analytics 代理是否支持多宿主,以便将其写入两个工作区。相反,我想知道,在我已经有两个工作区的情况下,其中一个工作区是否可以持续将其内容发送到另一个工作区。
环境与商业案例
哨兵
我们正在使用 Azure Sentinel 来监控基于 Azure 和本地资源的日志。我们使用单个 Sentinel 实例和单个 Log Analytics 工作区。根据 Microsoft 文档的建议,我们需要监控的所有资源都将其日志存储在这个工作区中。
本地 Windows 主机
对于我们的本地 Windows 服务器,我们使用 Azure Log Analytics 代理将各种日志发送到 Sentinel Workspace。其中一个日志是 Windows 事件日志,我们将其中的某些事件从安全、应用程序和系统日志发送到 Azure。这运行良好。
未满足的要求
(注意:不要让 SQL Server 的提及吓到您;它只是与当前的问题有关。)
我们的一些本地 Windows 主机正在运行 SQL Server。我们有合规性要求来审核某些数据库事件。我们正在使用 SQL Server Audit 将这些事件写入 Windows 安全事件日志。
问题在于 Log Analytics 代理没有将我们关心的事件从安全事件日志发送到 Sentinel 的 Log Analytics 工作区。根据我们的配置,这是预料之中的;见下文。
技术问题
概念
我们可以配置将 Windows 事件日志中的哪些信息存储在 Azure 中。此配置由目标 Log Analytics 工作区定义。
然而,目前 Azure 仅允许相对粗略的配置选项。对于安全事件日志,我们可以存储任何内容、所有内容或两组事件之一:“最小”和“常见”。Microsoft 记录了每个类别中的事件 ID 列表。
问题
不幸的是,我们关心的 SQL Server 相关事件不包含在最小事件 ID 组或常见事件 ID 组中。
选项
我看到了几种用于存储我们想要的特定事件 ID 的选项,但每种选项都有一个不小的缺点:
存储所有事件。我们可以更改 Sentinel 工作区的配置以存储来自安全事件日志的所有事件。问题是更改此设置将影响我们所有的 Windows 主机(我们只需要增加运行 SQL Server 的主机子集的日志记录)。如果我们这样做,我们的数据输入和存储成本将大幅增加,尤其是考虑到我们的长期保留要求。
使用新的 Azure Monitor 代理。Azure Monitor 代理最终将取代 Log Analytics 代理,并包括定义细粒度事件存储过滤器的能力。但是,目前此代理处于预览状态。此外,我们的计划中没有足够的时间用 Azure Monitor 代理替换我们的 Log Analytics 代理、学习/编写过滤器或更新辅助基础设施(如自动将代理部署到新主机的 Azure 策略)。
创建第二个 Sentinel 实例。使用第二个 Sentinel 及其自己的日志分析工作区,我们可以从那里的数据库服务器发送日志。反过来,我们可以配置工作区以存储来自安全事件日志的所有事件。这将使我们能够从这几个数据库服务器存储我们需要的事件,而无需存储来自其他 Windows 服务器的大量噪音。问题是我们现在有两个独立的 Sentinel 实例,如果我理解正确的话,它们需要额外的配置(例如,跨工作区查询分析规则、工作簿等)来关联我们环境不同层级之间的安全事件(例如,数据库、Web 应用程序、操作系统)。
解决方案?
我设想了一种可能的解决方案,即我们为数据库服务器使用第二个“暂存”日志分析工作区。此工作区将配置为存储其安全事件日志中的所有事件 - 然后将那些事件转发到 Sentinel 工作区。
在此场景中,两个工作区将允许我们比使用单个工作区更精细地配置事件日志存储。但是,我们仍然会有一个 Sentinel 实例,可以使用一个合并的工作区关联事件。
诚然,第二个 Workspace 会存储重复的记录,但我们可以配置一个较短的保留期,因为它们将被转发到 Sentinel 正在使用的“真实”Workspace 进行长期存储。额外的成本是可以承受的。
不过,我不知道这是否可行。我读过有关从 Log Analytics 工作区进行持续导出的文章,但看起来目标只能是存储帐户和事件中心,而不能是其他工作区。
因此,我希望有人知道一种将记录从一个 Log Analytics 工作区转发到另一个 Log Analytics 工作区的简单方法(即原始问题)。
还有其他想法吗?
当然,如果您有其他建议来实现我们的业务目标,即将特定的 Windows 安全事件日志事件 ID 发送到我们的 Sentinel 实例,请随时提出建议。请注意,我们目前对 Sentinel 专业知识的访问有限,因此任何需要超过最适度的 Sentinel 重新配置的事情目前可能都不切实际。
提前感谢您的时间和考虑。
答案1
Azure Log Analytics 工作区限制
遗憾的是,目前还无法实现。Azure 尚不支持以下内容:
- 将日志从一个工作区发送到另一个工作区
- 将日志从一个工作区迁移到另一个工作区
为了降低成本,我们希望将工作区从某个区域迁移到美国东部区域,因为成本(编辑:以前较低。到 2021 年中期,其他地区的成本将降低至与 EUS 持平)EUS 降低了 40%。设置好新的工作区后,我们尝试寻求支持,帮助将日志从旧工作区移动到新工作区,但被告知这是不可能的,只能将旧的 Log Analytics 工作区数据保留足够长的时间,以便在保留期到期后自动删除数据。我们与 Azure 团队探讨了这两种选择,但被告知它们都不受支持。
注意事项
发送所有事件日志肯定会影响成本。不建议采用这种方法。相反,您可以尝试在源头过滤日志。
你说得对LA 数据导出仅适用于 Event Hub、Storage Accounts。不支持将日志发送到另一个 Workspace。
我刚刚了解到新的Azure Monitor 代理- 它看起来很有希望,但正如你提到的,仍处于预览阶段。
作为最佳实践,Azure 建议将 Sentinel Workspaces 保留为一个。这里这样做有其优缺点。这里的措辞可能会令人困惑。Sentinel Workspace 仅指与其相连的 LA Workspace,而不是 Sentinel 的实际实例。但是,根据业务需求,考虑到其他因素,使用多个应该没问题。
解决方案
选项1
您可以使用 Powershell 脚本过滤器并在本地收集日志,然后通过以下方式将其转发到您的 LA Workspace:Azure 监视器 API。这可能是最好的方法,因为它可以避免您更改 Azure 设置,但需要一些工作。
选项 2
您仍然可以考虑创建第二个 LA 工作区,仅用于有限的 SQL 相关日志。实际上,您不需要为此创建第二个 Azure Sentinel 实例。您只需要确保您的第二个工作区“链接”到您的单个 Sentinel 实例。我们目前正在使用两个连接到单个 Sentinel 实例的 LA 工作区。正如您所提到的,缺点是您仍然需要执行跨工作区查询才能跨工作区查询数据 - 这并不像听起来那么难,但可能会有一些轻微的延迟,等等局限性,在执行跨工作区查询时。请参见多个 Sentinel 工作区的用例。
选项 3
Azure 建议使用Azure 灯塔将 Sentinel 管理整合到一个界面中。使用 Azure Lighthouse 无需额外付费,尽管这是一款面向服务提供商的产品,但企业客户也可以利用它。此选项仍需要您拥有第二个 LA Workspace。我将其作为最后一个选项,因为尽管它可以帮助实现自动化,但它也是选项 2。