我可以將內容從一個 Azure Log Analytics 工作區轉發到另一個嗎？
問題
- 是否可以將內容從一個 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之上的額外步驟。