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