Microsoft Sentinel 範例工作區設計

  • 發行項

本文說明針對具有下列範例需求的組織所建議的工作區設計：

  • 具有歐洲資料主權需求的多租使用者和區域
  • 具有多個雲端的單一租使用者
  • 多個租使用者，具有多個區域和集中式安全性

本文中的範例會使用 Microsoft Sentinel 工作區設計決策樹 來判斷每個組織的最佳工作區設計。 如需詳細資訊，請參閱 Microsoft Sentinel 工作區架構最佳做法 。

本文是 Microsoft Sentinel 的部署指南的 一部分。

範例 1：多個租使用者和區域

Contoso 公司是一家跨國企業，總部設在倫敦。 Contoso 在世界各地設有辦事處，擁有紐約市和東京的重要中心。 最近，Contoso 已將其生產力套件移轉至 Office 365，且許多工作負載已移轉至 Azure。

Contoso 租使用者

由於幾年前的收購，Contoso 有兩個 Microsoft Entra 租使用者： contoso.onmicrosoft.com 和 wingtip.onmicrosoft.com 。 每個租使用者都有自己的 Office 365 實例和多個 Azure 訂用帳戶，如下圖所示：

Diagram of Contoso tenants, each with separate sets of subscriptions.

Contoso 合規性和區域部署

Contoso 目前裝載于三個不同的區域中的 Azure 資源：美國東部、歐盟北部和日本西部，以及嚴格要求將歐洲產生的所有資料保留在歐洲區域內。

Contoso 的 Microsoft Entra 租使用者在這三個區域中都有資源：美國東部、歐盟北部和日本西部

Contoso 資源類型和集合需求

Contoso 必須從下列資料來源收集事件：

  • Office 365
  • Microsoft Entra 登入和稽核記錄
  • Azure 活動
  • 從內部部署和 Azure VM 來源Windows 安全性事件
  • 來自內部部署和 Azure VM 來源的 Syslog
  • CEF，來自多個內部部署網路裝置，例如 Palo Alto、Cisco ASA 和 Cisco Meraki
  • 多個 Azure PaaS 資源，例如Azure 防火牆、AKS、金鑰保存庫、Azure 儲存體和 Azure SQL
  • Cisco Umbrella

Azure VM 大多位於歐盟北部區域，只有少數位于美國東部和西部日本。 Contoso 會在其所有 Azure VM 上使用適用于伺服器的 Microsoft Defender。

Contoso 預期會從其所有資料來源擷取大約 300 GB/天。

Contoso 存取需求

Contoso 的 Azure 環境已經有 Operations 小組用來監視基礎結構的單一現有 Log Analytics 工作區。 此工作區位於歐盟北部區域內的 Contoso Microsoft Entra 租使用者中，並用來從所有區域中的 Azure VM 收集記錄。 他們目前每天內嵌約 50 GB。

Contoso Operations 小組必須能夠存取工作區中目前擁有的所有記錄，其中包括 SOC 不需要的數種資料類型，例如 Perf 、InsightsMetrics 、 ContainerLog 等等。 Operations 小組不得 存取 Microsoft Sentinel 中收集的新記錄。

Contoso 的解決方案

下列步驟會 套用 Microsoft Sentinel 工作區設計決策樹 ，以判斷 Contoso 的最佳工作區設計：

  1. Contoso 已經有現有的工作區，因此我們可以探索在同一個工作區中啟用 Microsoft Sentinel。

    非 SOC 資料擷取小於 100 GB/天，因此我們可以繼續執行 步驟 2 ，並確定在步驟 5 中 選取相關選項。

  2. Contoso 具有法規需求，因此我們需要歐洲至少一個 Microsoft Sentinel 工作區。

  3. Contoso 有兩個不同的 Microsoft Entra 租使用者，並從租使用者層級資料來源收集，例如 Office 365 和 Microsoft Entra 登入和稽核記錄，因此我們需要每個租使用者至少一個工作區。

  4. Contoso 不需要 退款 ，因此我們可以繼續進行 步驟 5 。

  5. Contoso 確實需要收集非 SOC 資料，不過 SOC 和非 SOC 資料之間沒有任何重迭。 此外，SOC 資料大約為 250 GB/天，因此它們應該使用個別的工作區，以符合成本效益。

  6. 大部分 Contoso 的 VM 都是歐盟北部區域，其中已有工作區。 因此，在此情況下，頻寬成本並不相關。

  7. Contoso 有一個 SOC 小組，將會使用 Microsoft Sentinel，因此不需要額外的分隔。

  8. Contoso SOC 小組的所有成員都可以存取所有資料，因此不需要額外的區隔。

Contoso 產生的 Microsoft Sentinel 工作區設計如下圖所示：

Diagram of Contoso's solution, with a separate workspace for the Ops team.

建議的解決方案包括：

  • Contoso Operations 小組的個別 Log Analytics 工作區。 此工作區只會包含 Contoso SOC 小組不需要的資料，例如 Perf 、 InsightsMetrics 或 ContainerLog 資料表。

  • 每個 Microsoft Entra 租使用者中有兩個 Microsoft Sentinel 工作區，用來內嵌 Office 365、Azure 活動、Microsoft Entra ID 和所有 Azure PaaS 服務的資料。

  • 所有其他來自內部部署資料來源的資料，都可以路由傳送至兩個 Microsoft Sentinel 工作區的其中一個。

範例 2：具有多個雲端的單一租使用者

Fabrikam 是一個組織，總部在紐約市和各地辦事處美國。 Fabrikam 正在開始其雲端旅程，但仍需要部署其第一個 Azure 登陸區域，並移轉其第一個工作負載。 Fabrikam 在 AWS 上已經有一些工作負載，他們想要使用 Microsoft Sentinel 進行監視。

Fabrikam 租用需求

Fabrikam 有單一 Microsoft Entra 租使用者。

Fabrikam 合規性和區域部署

Fabrikam 沒有合規性需求。 Fabrikam 在美國的數個 Azure 區域中有資源，但跨區域的頻寬成本並不是主要問題。

Fabrikam 資源類型和集合需求

Fabrikam 必須從下列資料來源收集事件：

  • Microsoft Entra 登入和稽核記錄
  • Azure 活動
  • 來自內部部署和 Azure VM 來源的安全性事件
  • 來自內部部署和 Azure VM 來源的 Windows 事件
  • 來自內部部署和 Azure VM 來源的效能資料
  • AWS CloudTrail
  • AKS 稽核和效能記錄

Fabrikam 存取需求

Fabrikam Operations 小組必須存取：

  • 來自內部部署和 Azure VM 來源的安全性事件和 Windows 事件
  • 來自內部部署和 Azure VM 來源的效能資料
  • AKS 效能 （Container Insights） 和稽核記錄
  • 所有 Azure 活動資料

Fabrikam SOC 小組必須存取：

  • Microsoft Entra 登入和稽核記錄
  • 所有 Azure 活動資料
  • 來自內部部署和 Azure VM 來源的安全性事件
  • AWS CloudTrail 記錄
  • AKS 稽核記錄
  • 完整的 Microsoft Sentinel 入口網站

Fabrikam 的解決方案

下列步驟會 套用 Microsoft Sentinel 工作區設計決策樹 ，以判斷 Fabrikam 的最佳工作區設計：

  1. Fabrikam 沒有現有的工作區，因此請繼續進行 步驟 2 。

  2. Fabrikam 沒有法規需求，因此請繼續進行 步驟 3 。

  3. Fabrikam 具有單一租使用者環境。 因此請繼續進行 步驟 4 。

  4. Fabrikam 不需要分割費用，因此請繼續進行 步驟 5 。

  5. Fabrikam 需要其 SOC 和 Operations 小組的個別工作區：

    Fabrikam Operations 小組必須從 VM 和 AKS 收集效能資料。 由於 AKS 是以診斷設定為基礎，因此可以選取要傳送至特定工作區的特定記錄。 Fabrikam 可以選擇將 AKS 稽核記錄傳送至 Microsoft Sentinel 工作區，並將所有 AKS 記錄傳送至未啟用 Microsoft Sentinel 的個別工作區。 在未啟用 Microsoft Sentinel 的工作區中，Fabrikam 會啟用 Container Insights 解決方案。

    針對 Windows VM，Fabrikam 可以使用 Azure 監視代理程式 （AMA） 來分割記錄、將安全性事件傳送至 Microsoft Sentinel 工作區，並將效能和 Windows 事件傳送至沒有 Microsoft Sentinel 的工作區。

    Fabrikam 選擇考慮其重迭的資料，例如安全性事件和 Azure 活動事件，僅限 SOC 資料，並使用 Microsoft Sentinel 將此資料傳送至工作區。

  6. 頻寬成本不是 Fabrikam 的主要考慮，因此請繼續進行 步驟 7 。

  7. Fabrikam 已決定針對 SOC 和作業小組使用不同的工作區。 不需要進一步分離。

  8. Fabrikam 確實需要控制重迭資料的存取權，包括安全性事件和 Azure 活動事件，但沒有資料列層級的需求。

    安全性事件和 Azure 活動事件不是自訂記錄，因此 Fabrikam 可以使用資料表層級 RBAC 為 Operations 小組授與這兩個數據表的存取權。

針對 Fabrikam 產生的 Microsoft Sentinel 工作區設計如下圖所示，只包括為了設計簡單起見，只包含主要記錄檔來源：

Diagram of Fabrikam's solution, with a separate workspace for the Ops team.

建議的解決方案包括：

  • 美國區域中的兩個不同的工作區：一個適用于已啟用 Microsoft Sentinel 的 SOC 小組，另一個適用于 Operations 小組，不含 Microsoft Sentinel。

  • Azure 監視代理程式 （AMA） ，用來判斷哪些記錄會從 Azure 和內部部署 VM 傳送至每個工作區。

  • 診斷設定，用來判斷哪些記錄會從 AKS 等 Azure 資源傳送至每個工作區。

  • 正在傳送至 Microsoft Sentinel 工作區的重迭資料，並視需要將作業小組的存取權授與資料表層級 RBAC。

範例 3：多個租使用者和區域和集中式安全性

Adventure Works 是一家跨國公司，總部設在東京。 Adventure Works 有 10 個不同的子實體，以世界各地的不同國家/地區為基礎。

Adventure Works 是 Microsoft 365 E5 客戶，且已在 Azure 中擁有工作負載。

Adventure Works 租用需求

Adventure Works 有三個不同的 Microsoft Entra 租使用者，每個各大洲各有一個租使用者：亞洲、歐洲和非洲。 不同子實體的國家/地區在其所屬大陸的租使用者中具有其身分識別。 例如，日文使用者位於 亞洲 租使用者中，德文使用者位於 歐洲 租使用者，而埃及使用者則位於 非洲 租使用者中。

Adventure Works 合規性和區域需求

Adventure Works 目前使用三個 Azure 區域，每個區域都與子實體所在的大陸一致。 Adventure Works 沒有嚴格的合規性需求。

Adventure Works 資源類型和集合需求

Adventure Works 需要為每個子實體收集下列資料來源：

  • Microsoft Entra 登入和稽核記錄
  • Office 365 記錄
  • 端點原始記錄的Microsoft Defender 全面偵測回應
  • Azure 活動
  • 適用於雲端的 Microsoft Defender
  • Azure PaaS 資源，例如從 Azure 防火牆、Azure 儲存體、Azure SQL 和 Azure WAF
  • 來自 Azure VM 的安全性和 Windows 事件
  • 來自內部部署網路裝置的 CEF 記錄

Azure VM 分散在三大洲，但頻寬成本並不相關。

Adventure Works 存取需求

Adventure Works 具有單一集中式 SOC 小組，負責監督所有不同子實體的安全性作業。

Adventure Works 也有三個獨立的 SOC 團隊，每個大陸各有一支。 每個大陸的 SOC 小組應該只能存取其區域內產生的資料，而不會看到來自其他大陸的資料。 例如，亞洲 SOC 小組應該只存取部署于亞洲的 Azure 資源、來自亞洲租使用者的 Microsoft Entra 登入，以及來自亞洲租使用者的適用于端點的 Defender 記錄。

每個大陸的 SOC 小組都必須存取完整的 Microsoft Sentinel 入口網站體驗。

Adventure Works 的作業小組會獨立執行，且有自己的工作區，沒有 Microsoft Sentinel。

Adventure Works 解決方案

下列步驟會 套用 Microsoft Sentinel 工作區設計決策樹 ，以判斷 Adventure Works 的最佳工作區設計：

  1. Adventure Works 的作業小組有自己的工作區，因此請繼續進行 步驟 2 。

  2. Adventure Works 沒有法規需求，因此請繼續進行 步驟 3 。

  3. Adventure Works 有三個 Microsoft Entra 租使用者，而且需要收集租使用者層級資料來源，例如 Office 365 記錄。 因此，Adventure Works 應該至少建立 Microsoft Sentinel 工作區，每個租使用者一個。

  4. Adventure Works 不需要分割費用，因此請繼續進行 步驟 5 。

  5. 由於 Adventure Works 營運小組有自己的工作區，因此 Adventure Works SOC 小組將會使用此決策中考慮的所有資料。

  6. 頻寬成本不是 Adventure Works 的主要考慮，因此請繼續進行 步驟 7 。

  7. Adventure Works 需要依擁有權來隔離資料，因為每個內容的 SOC 小組只需要存取與該內容相關的資料。 不過，每個大陸的 SOC 小組也需要存取完整的 Microsoft Sentinel 入口網站。

  8. Adventure Works 不需要依資料表控制資料存取。

Adventure Works 產生的 Microsoft Sentinel 工作區設計如下圖所示，僅包含為了設計簡單起見的重要記錄來源：

Diagram of Adventure Works's solution, with separate workspaces for each Azure AD tenant.

建議的解決方案包括：

  • 每個 Microsoft Entra 租使用者的個別 Microsoft Sentinel 工作區。 每個工作區都會收集與其租使用者相關的所有資料來源資料。

  • 每個大陸的 SOC 小組只能存取其租使用者中的工作區，確保每個 SOC 小組只能存取租使用者界限內產生的記錄。

  • 中央 SOC 小組仍然可以從個別的 Microsoft Entra 租使用者運作，使用 Azure Lighthouse 來存取每個不同的 Microsoft Sentinel 環境。 如果沒有其他租使用者，中央 SOC 小組仍然可以使用 Azure Lighthouse 來存取遠端工作區。

  • 如果中央 SOC 小組需要儲存從歐洲大陸 SOC 小組隱藏的成品，或是想要擷取與非洲大陸 SOC 小組無關的其他資料，也可以建立另一個工作區。

下一步

在本文中，您已檢閱組織一組建議的工作區設計。

準備多個工作區