本文描述了針對組織建議的日誌分析工作空間設計，並具備以下範例需求：
- 多租戶與區域，具備歐洲資料主權要求
- 單一租戶與多雲
- 多租戶、多個區域與集中式安全
欲了解更多資訊，請參閱 設計日誌分析工作空間架構。
本文是 Microsoft Sentinel 部署指南的一部分。
範例 1：多租戶與區域
Contoso 公司是一家總部設於倫敦的跨國企業。 Contoso在全球設有辦公室，重要的樞紐位於紐約市和東京。 最近，Contoso 已將生產力套件遷移至 Office 365，許多工作負載也遷移至 Azure。
Contoso 租戶
由於數年前的收購，Contoso 擁有兩個 Microsoft Entra 租戶：contoso.onmicrosoft.com和 wingtip.onmicrosoft.com。 每個租戶都有自己的 Office 365 實例和多個 Azure 訂閱，如下圖所示：
Contoso 合規與區域部署
Contoso 目前在三個不同區域托管 Azure 資源：美國東部、歐盟北部及西日本，並嚴格要求所有在歐洲產生的資料均屬於歐洲區域。
Contoso 的兩個 Microsoft Entra 租戶在美國東部、歐盟北部及西日本三個地區均有資源
Contoso 資源類型與收藏需求
Contoso 需要從以下資料來源收集事件：
- Office 365
- Microsoft Entra 登入與稽核日誌
- Azure Activity
- Windows 安全性事件，來自本地與 Azure VM 來源
- Syslog，來自本地及 Azure VM 來源
- CEF，來自多個本地網路設備，如Palo Alto、Cisco ASA及Cisco Meraki
- 多個 Azure PaaS 資源，例如 Azure 防火牆、AKS、金鑰保存庫、Azure Storage，以及 Azure SQL
- Cisco 傘
Azure 虛擬機大多位於歐盟北部地區，只有少數分布在美國東日本和西日本。 Contoso 在所有 Azure 虛擬機上使用 Microsoft Defender 作為伺服器。
Contoso 預計每天從所有資料來源匯入約 300 GB。
Contoso的存取要求
Contoso 的 Azure 環境已有單一的 Log Analytics 工作空間，供營運團隊監控基礎設施。 此工作區位於 Contoso Microsoft Entra 租戶中，位於歐盟北部區域，並用於從所有區域的 Azure VM 收集日誌。 牠們目前每天大約攝取50 GB。
Contoso 營運團隊需要存取目前工作區中所有的日誌，其中包括 SOC 不需要的多種資料類型，例如 Perf、 InsightsMetrics、 ContainerLog 等。 營運團隊不得存取 Microsoft Sentinel 中收集的新日誌。
Contoso 的解決方案
Constoso 的解決方案包含以下考量：
- Contoso 已經有現有的工作空間，他們希望能在同一工作空間中啟用 Microsoft Sentinel。
- Contoso 有法規要求，因此我們至少需要在歐洲為 Microsoft Sentinel 啟用一個 Log Analytics 工作空間。
- Contoso 的大多數虛擬機都在歐盟北部區域，他們已經有工作區。 因此，在這種情況下，頻寬成本不是問題。
- Contoso 有兩個不同的 Microsoft Entra 租戶，並從租戶層級的資料來源收集資料，例如 Office 365 和 Microsoft Entra 的登入與稽核日誌，我們每個租戶至少需要一個工作空間。
- Contoso 確實需要收集 非 SOC 資料，雖然 SOC 與非 SOC 資料之間沒有重疊。 此外，SOC 資料約佔每日 250 GB，因此為了成本效益，他們應該使用獨立的工作區。
- Contoso 只有一個 SOC 團隊，會使用 Microsoft Sentinel，因此不需要額外的分離。
- Contoso SOC 團隊的所有成員都能存取所有資料，因此無需額外分離。
Contoso 最終的工作空間設計如下圖所示：
建議的解決方案包括：
- 為 Contoso 營運團隊設立的獨立日誌分析工作區。 這個工作區只會包含 Contoso SOC 團隊不需要的資料，例如 Perf、 InsightsMetrics 或 ContainerLog 資料表。
- Microsoft Sentinel 啟用兩個 Log Analytics 工作空間，分別位於每個 Microsoft Entra 租戶中，可從 Office 365、Azure Activity、Microsoft Entra ID 及所有 Azure PaaS 服務匯入資料。
- 其他來自本地資料來源的資料，則可路由至兩個工作區之一。
範例 2：單一租戶與多雲
Fabrikam 是一個總部設於紐約市，並在美國各地設有辦公室的組織。 Fabrikam 正在開始他們的雲端旅程，但仍需部署首個 Azure 登陸區並遷移首批工作負載。 Fabrikam 已經在 AWS 上擁有一些工作負載，他們打算使用 Microsoft Sentinel 來監控這些工作。
Fabrikam 租賃要求
Fabrikam 擁有單一的 Microsoft Entra 租戶。
Fabrikam 合規與區域部署
Fabrikam 沒有合規要求。 Fabrikam 在美國的多個 Azure 區域都有資源，但跨區域的頻寬成本並非主要問題。
Fabrikam 資源類型與收藏需求
Fabrikam 需要從以下資料來源收集事件：
- Microsoft Entra 登入與稽核日誌
- Azure Activity
- 來自本地及 Azure VM 來源的安全事件
- Windows 事件，來自本地與 Azure VM 來源
- 效能資料，來自本地端與 Azure VM 來源
- AWS CloudTrail
- AKS 稽核與績效日誌
Fabrikam 存取要求
Fabrikam 營運團隊需要存取：
- 來自本地及 Azure VM 來源的安全事件與 Windows 事件
- 效能資料，來自本地端與 Azure VM 來源
- AKS (Container Insights) 與稽核日誌的效能
- All Azure Activity data
Fabrikam SOC 團隊需要存取：
- Microsoft Entra 登入與稽核日誌
- All Azure Activity data
- 來自本地與 Azure VM 來源的安全事件
- AWS CloudTrail 日誌
- AKS 稽核日誌
- 完整的 Microsoft Sentinel 入口網站
Fabrikam 的解決方案
Fabrikam 的解決方案包含以下考量：
Fabrikam 沒有現有的工作區，所以他們會自動需要新的工作區。
Fabrikam 沒有任何監管要求必須將資料分開保存。
Fabrikam 採用單一租戶環境，不需要每個租戶分開的工作空間。
然而，Fabrikam 需要為 SOC 與營運團隊分別設置獨立的工作空間。
Fabrikam 營運團隊需要從虛擬機和 AKS 收集效能資料。 由於 AKS 是基於診斷設定，他們可以選擇特定的日誌發送到特定工作區。 Fabrikam 可以選擇將 AKS 稽核日誌傳送到 Microsoft Sentinel 啟用的 Log Analytics 工作區，並將所有 AKS 日誌傳送到未啟用 Microsoft Sentinel 的獨立工作區。 在未啟用 Microsoft Sentinel 的工作區，Fabrikam 將啟用 Container Insights 解決方案。
對於 Windows 虛擬機，Fabrikam 可以使用 AMA) (Azure Monitoring Agent 來拆分日誌，將安全事件傳送到工作區，並將效能與 Windows 事件傳送到工作區而無需Microsoft Sentinel。
Fabrikam 選擇將重疊的資料，例如安全事件與 Azure 活動事件，視為僅為 SOC 資料，並將這些資料傳送至 Microsoft Sentinel 工作區。
Fabrikam 需要控制重疊資料的存取，包括安全事件和 Azure 活動事件，但沒有列層級的要求。 由於安全事件與 Azure 活動事件並非自訂日誌，Fabrikam 可以使用資料表層級的 RBAC 授權營運團隊存取這兩個資料表。
Fabrikam 產生的工作空間設計如下圖所示，僅包含關鍵日誌來源以簡化設計：
建議的解決方案包括：
- 美國區域有兩個獨立的工作空間：一個是啟用 Microsoft Sentinel 的 SOC 團隊，另一個是沒有 Microsoft Sentinel 的營運團隊。
- Azure 監控代理 (AMA) ，用於判斷從Azure及本地虛擬機傳送到每個工作空間的日誌。
- 診斷設定，用來判斷哪些日誌會從 Azure 資源（如 AKS）傳送到每個工作區。
- Microsoft Sentinel 啟用了重疊資料傳送至 Log Analytics 工作空間，並支援資料表層級的 RBAC，視需要授權營運團隊存取權限。
範例三：多租戶與多區域與集中式安全
Adventure Works 是一家總部設於東京的跨國公司。 冒險作品有10個不同的子實體，分布於世界各地不同國家和地區。
Adventure Works 是 Microsoft 365 E5 的客戶，且已經有 Azure 工作負載。
Adventure Works 租賃要求
Adventure Works 擁有三個不同的 Microsoft Entra 租戶，分別對應其子實體的洲際：亞洲、歐洲和非洲。 不同子實體的國家/地區身份取決於其所屬大陸的租戶。 例如，日本用戶屬於 亞洲 租戶，德國用戶屬於 歐洲 租戶，埃及用戶則屬於 非洲 租客。
冒險作品的合規與區域要求
冒險作品目前使用三個 Azure 區域，每個區域都對應子實體所在的大陸。 Adventure Works 沒有嚴格的合規要求。
冒險作品資源類型與收藏需求
Adventure Works 需要為每個子實體收集以下資料來源：
- Microsoft Entra 登入與稽核日誌
- Office 365 日誌
- Microsoft Defender 全面偵測回應端點原始日誌
- Azure Activity
- 適用於雲端的 Microsoft Defender
- Azure PaaS 資源，例如 from Azure 防火牆、Azure Storage、Azure SQL 同 Azure WAF
- Security and Windows Events from Azure VMS
- 來自本地網路設備的 CEF 日誌
Azure 虛擬機分布在三大洲，但頻寬成本並非問題。
冒險作品的進入要求
Adventure Works 擁有一個單一的集中 SOC 團隊，負責監督所有不同子實體的安全運作。
冒險工作隊還有三支獨立的SOC團隊，分別代表各大洲。 每個大陸的SOC團隊應該 只能存取其區域內產生的資料，而不會看到其他大陸的資料。 例如，亞洲 SOC 團隊應該只能存取部署在亞洲的 Azure 資源資料、從亞洲租戶存取 Microsoft Entra 登入，以及從亞洲租戶存取 Defender for Endpoint 日誌。
每個大洲的 SOC 團隊都需要完整體驗 Microsoft Sentinel 入口網站。
Adventure Works 的營運團隊獨立運作，擁有獨立的工作空間，沒有 Microsoft Sentinel。
冒險工作坊的解決方案
Adventure Works 的解決方案包含以下考量：
冒險工作室的營運團隊已經有自己的工作區，因此不需要新建一個。
Adventure Works 沒有任何監管要求必須將資料分開保存。
Adventure Works 有三個 Microsoft Entra 租戶，並需要收集租戶層級的資料來源，例如 Office 365 日誌。 因此，Adventure Works 應在每個租戶中至少建立一個啟用 Microsoft Sentinel 的日誌分析工作空間。
雖然本決定中考慮的所有資料將由 Adventure Works SOC 團隊使用，但他們仍需依所有權分類，因為每個 SOC 團隊僅需存取與該團隊相關的資料。 每個 SOC 團隊也都需要存取完整的 Microsoft Sentinel 入口網站。 Adventure Works 不需要以資料表來控制資料存取。
Adventure Works 的工作區設計圖如下圖所示，僅包含關鍵日誌來源以簡化設計：
建議的解決方案包括：
- 每個Microsoft Entra租戶都啟用了獨立的 Log Analytics 工作空間，以提供 Microsoft Sentinel。 每個工作區都會收集與其租戶相關的資料，涵蓋所有資料來源。
- 每個大陸的 SOC 團隊只能存取其自身租戶的工作空間，確保每個 SOC 團隊只能存取租戶邊界內產生的日誌。
- 中央 SOC 團隊仍可從獨立的 Microsoft Entra 租戶運作，使用 Azure Lighthouse 存取不同的 Microsoft Sentinel 環境。 如果沒有其他租戶，中央 SOC 團隊仍可使用 Azure Lighthouse 存取遠端工作空間。
- 中央 SOC 團隊若需要儲存對大陸 SOC 團隊隱藏的產物，或想匯入與大陸 SOC 團隊無關的其他資料，也可以建立另一個工作區。
後續步驟
在這篇文章中，你回顧了一組建議的組織工作空間設計。