自動化 Sentinel 與 Azure DevOps 的整合

Microsoft Entra ID
Azure DevOps
Azure 金鑰保存庫
適用於雲端的 Microsoft Defender
Microsoft Sentinel

本文說明如何使用 Azure DevOps 自動化Microsoft Sentinel 整合和部署作業。 您可以使用 Microsoft Sentinel 功能來實作 Azure DevOps,以協助保護您的部署。 接著,您可以使用 DevSecOps 架構大規模管理和部署Microsoft Sentinel 成品。

架構

下圖顯示 Azure DevOps 和 Microsoft Sentinel IaC 設定。

此圖顯示自動化Microsoft Sentinel 基礎結構作為程式代碼管線的架構。

下載此架構的 Visio 檔案

資料流程

  1. scrum 主要和產品管理會使用 Azure DevOps,將 Epic、使用者劇本和產品待辦專案定義為專案待辦專案的一部分。
    • scrum 主要和產品管理會使用 Azure Boards 來建立待辦專案、在短期衝刺中排程工作、檢閱專案面板、建立存放庫結構,以及設定核准工作流程和分支等安全性規則。
    • Azure Git 存放庫會將腳本和允許以程式代碼的形式管理基礎結構中的Microsoft Sentinel 成品。
    • 成品和原始檔控制會維護解決方案中使用的 DevSecOps 工作流程延伸模組和更新套件或元件,例如 Azure Resource Manager 範本工具組和 PowerShell Pester。
  2. Microsoft Sentinel 成品:
    • 原則。 SIEM 工程師會在參考架構中使用 Azure 原則,來設定及調整 Azure 服務的診斷設定。 這些原則可協助自動部署 Microsoft Sentinel 數據連接器,例如 Azure 金鑰保存庫。 原則相依於 OMSIntegration API。
    • 連接器。 Microsoft Sentinel 會使用邏輯連接器、Azure 數據連接器,從支持的數據源擷取安全性數據,例如Microsoft Entra ID、Azure 資源、Microsoft Defender 或第三方解決方案。 數據連接器的主要清單是由 SecurityInsights API 所管理。 其他人則依賴 OMSIntegration API,並使用 Azure 原則 診斷設定進行管理。
    • 受控識別。 Microsoft Sentinel 會在與劇本、邏輯應用程式或自動化 Runbook 和密鑰保存庫互動時,使用受控識別來代表受控服務識別(MSI) 採取行動。
    • 自動化。 SOC 小組會在調查期間使用自動化。 SOC 小組會使用 Azure 自動化 執行數位鑑識數據擷取程式,例如適用於 Microsoft Defender 的 Azure 虛擬機(VM) 監管鏈或電子檔探索(進階版)。
    • 分析。 SOC 分析師或威脅搜捕人員會使用內建或自定義分析規則來分析和相互關聯 Sentinel Microsoft中的數據,或在發現威脅和事件時觸發劇本。
    • 劇本。 邏輯應用程式會執行 SecOps 可重複的動作,例如指派事件、更新事件,或採取補救動作,例如隔離或包含 VM、撤銷令牌或重設用戶密碼。
    • 威脅搜捕。 威脅搜捕人員會使用主動式威脅搜捕功能,與 Jupyter Notebook 搭配使用進階使用案例,例如數據處理、數據操作、數據視覺效果、機器學習或深度學習。
    • 活頁簿。 SIEM 工程師會使用 Workbooks 儀錶板將趨勢和統計數據可視化,以及檢視Microsoft Sentinel 實例及其子元件的狀態。
    • 威脅情報。 將威脅情報平臺饋送至 Sentinel Microsoft的特定數據連接器。 支援兩種連線方法:TAXII 和圖形 API。 這兩種方法在安全性 API 中可作為 tiIndicators 或威脅情報指標。
  3. Microsoft Entra ID. 身分識別和存取管理功能會傳遞至參考架構中使用的元件,例如受控識別、服務主體、Azure 角色型訪問控制 (RBAC),以用於Microsoft Sentinel、邏輯應用程式和自動化 Runbook。
  4. Azure Pipelines。 DevOps 工程師會使用管線來建立服務連線,以管理不同的 Azure 訂用帳戶,例如具有持續整合和持續傳遞 (CI/CD) 管線的沙箱和生產環境。 如果您以每個 Azure 環境多個訂用帳戶為目標,建議您使用核准工作流程來防止非預期的部署和分隔的服務主體。
  5. Azure Key Vault。 SOC 工程師會使用密鑰保存庫安全地儲存服務主體秘密和憑證。 架構的這個元件有助於在 Azure Pipeline 服務連線使用時,強制執行程式代碼中沒有秘密的 DevSecOps 原則。
  6. Azure 訂閱。 SOC 小組在此參考架構中使用兩個Microsoft Sentinel 實例,在兩個邏輯 Azure 訂用帳戶內分隔,以模擬生產環境與沙盒環境。 您可以使用其他環境來調整需求,例如測試、開發、生產前等等。

數據流範例

  1. 系統管理員會在Microsoft 365 組態檔的分支中新增、更新或刪除專案。
  2. 系統管理員認可並同步處理其分支存放庫的變更。
  3. 系統管理員接著會建立提取要求 (PR),將變更合併至主要存放庫。
  4. 建置管線會在PR上執行。

元件

  • Microsoft Entra ID 是多租用戶雲端式服務,可用來管理身分識別和訪問控制。
  • Azure DevOps 是一項雲端服務,可共同作業程式代碼、建置和部署應用程式,或規劃和追蹤您的工作。
  • Azure 金鑰保存庫 是雲端服務,可安全地儲存和存取秘密。 祕密是指任何您想要嚴密控制存取的項目,例如 API 金鑰、密碼、憑證或密碼編譯金鑰。
  • Azure 原則 是一項服務,可讓您在 Azure 環境中建立、指派和管理原則定義。
  • Microsoft Sentinel 是可調整、雲端原生、SIEM 和安全性協調流程、自動化和回應 (SOAR) 解決方案。
  • Azure 自動化 是一項服務,可透過程式自動化簡化雲端管理。 使用 Azure 自動化 自動化長時間執行、手動、容易出錯且經常重複的工作。 自動化可協助改善公司的可靠性、效率和價值時間。

案例詳細資料

安全性作業中心 (SOC) 小組有時會在整合Microsoft Sentinel 與 Azure DevOps 時遇到挑戰。 此程式牽涉到許多步驟,而設定可能需要數天時間並涉及重複。 您可以將開發這個部分自動化。

為了為雲端現代化,工程師必須不斷學習新的技能和技術,以保護和保護重要的商務資產。 工程師必須建置健全且可調整的解決方案,以跟上不斷變化的安全性環境以及商務需求。 安全性解決方案必須具有彈性、靈活且從開發初期階段精心規劃。 這種早期規劃方法稱為 左移

本文說明如何使用 Azure DevOps 自動化Microsoft Sentinel 整合和部署作業。 您可以針對具有多個實體、訂用帳戶和各種作業模型的複雜組織展開解決方案。 此解決方案支援的一些作業模型包括本機SOC、全域SOC、雲端服務提供者 (CSP)和受控安全性服務提供者(MSSP)。

本文適用於下列物件:

  • SOC 專家,例如分析師和威脅獵人
  • 安全性資訊和事件管理 (SIEM) 工程師
  • 網路安全架構師
  • 開發人員

潛在使用案例

以下是此架構的典型使用案例:

  • 快速原型設計和概念證明。 此解決方案適用於想要改善雲端威脅涵蓋範圍的安全性組織和 SOC 小組,或使用基礎結構即程式代碼 (IaC) 和 Microsoft Sentinel 將其 SIEM 基礎結構現代化。
  • Microsoft Sentinel 即服務。 此開發架構整合服務生命週期管理原則。 這些原則適用於簡單或複雜的小組,例如跨多個客戶租使用者執行可重複、標準化動作的 MSSP,同時結合 Azure DevOps 和 Azure Lighthouse 的強大功能。 例如,需要發佈新威脅執行者或進行中行銷活動Microsoft Sentinel 使用案例的小組可以使用此解決方案。
  • 建置SOC用於威脅偵測的使用案例。 許多群組和威脅情報平臺都依賴 MITRE Att&ck 內容和分類法來分析其安全性態勢,以對抗先進的貿易技術或策略程式。 此解決方案會藉由將 MITRE Att&ck 術語納入 sentinel 成品開發 Microsoft,來定義開發威脅偵測工程實務的結構化方法。

下圖顯示 MITRE Att&ck 雲端案例。

MITRE Att&ck 雲端案例的圖表。

下載此架構的 Visio 檔案

以 MITRE 為基礎的威脅定義攻擊案例

下表說明攻擊案例重要層面的詞彙、定義和詳細數據。

資料項目 描述 Microsoft Sentinel 成品
標題 根據攻擊向量特性或技術描述,攻擊案例的描述性名稱。 MITRE 指令清單
MITRE ATT&CK 策略 與攻擊案例相關的 MITRE ATT&CK 策略 MITRE 指令清單
MITRE ATT&CK 技術 MITRE ATT&CK 技術,包括與攻擊案例相關的技術或子技術標識符。 MITRE 指令清單
數據源 感測器或記錄系統收集的資訊來源,可用來收集與識別所執行動作、動作序列或敵人動作結果相關的資訊。 Microsoft Sentinel 數據連接器自定義記錄來源
描述 有關技術、其用途、其用途、敵人如何利用技術的資訊,以及其使用方式的變化。 包含權威文章的參考,說明與技術相關的技術資訊,以及適當地在野外使用參考中。
偵測 高階分析程式、感測器、數據和偵測策略有助於識別敵人所使用的技術。 本節會通知負責偵測敵人行為的人,例如網路 Defender,因此他們可以採取動作,例如撰寫分析或部署感測器。 應該有足夠的資訊和參考指向有用的防禦方法。 某些技術可能不一定能夠進行偵測,因此應該記錄如下。 分析威脅搜捕
風險降低 防止技術運作或具有對手所需結果的設定、工具或程式。 本節會通知負責減輕對手,例如網路防禦者或決策者,讓他們採取動作,例如變更原則或部署工具。 對於指定的技術而言,風險降低可能不一定可行,因此應該記錄如下。
風險降低 防止技術運作或具有對手所需結果的設定、工具或程式。 本節說明如何減輕攻擊者攻擊對網路防禦者或決策者的影響。 其涵蓋變更原則或部署工具的步驟。 某些技術可能不一定有風險降低,因此應該記錄如下。 劇本、自動化 Runbook

考量

這些考慮會實作 Azure Well-Architected Framework 的要素,這是一組指導原則,可用來改善工作負載的品質。 如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

安全性

安全性可提供保證,以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊,請參閱安全性要素的概觀

一般而言,隨著安全性,自動化會增加作業效率,同時為更複雜的使用案例節省時間,例如威脅偵測工程、威脅情報、SOC 和 SOAR 使用案例。 DevOps 小組必須知道在 sentinel CI/CD Microsoft內容中安全地使用 IaC 的位置。 此程式引進了非人為帳戶在稱為 服務主體受控識別的 Entra標識碼Microsoft使用的特定身分識別

下表摘要說明服務主體的安全性考慮,以及 Microsoft Sentinel 和 Azure DevOps 發行管線所涵蓋的主要使用案例。

使用案例 需求 (最低權限) 角色指派持續時間 許可權範圍 受託 人 安全性考量
啟用Microsoft Sentinel 連接器 安全性系統管理員**

擁有者*

Microsoft Sentinel 參與者

讀取者
JIT (一次性啟用)

基於目的(每次部署新的訂用帳戶和連接器時)
租用戶 SPN 使用金鑰保存庫來儲存服務主體名稱 (SPN) 秘密和憑證。

啟用 SPN 稽核。

定期檢閱許可權指派(適用於 SPN 的 Azure Privileged Identity Management)或 SPN 的可疑活動。

針對特殊許可權帳戶使用Microsoft Entra 證書頒發機構單位和多重要素驗證(支援時)。

使用 Microsoft Entra 自定義角色以取得更細微度。
部署Microsoft Sentinel成品,例如活頁簿、分析、規則、威脅搜捕查詢、筆記本和劇本 Microsoft Sentinel 參與者
Logic Apps 參與者
持續性 Microsoft Sentinel 的工作區或資源群組 SPN 使用 Azure DevOps (ADO) 工作流程核准和檢查來保護使用此 SPN 的管線部署。
指派原則以設定記錄串流功能以Microsoft Sentinel 資源原則參與者 ** 基於目的(每次部署新的訂用帳戶和連接器時) 要監視的所有訂用帳戶 SPN 針對特殊許可權帳戶,請使用Microsoft Entra ID、CA 和 MFA。

* 僅考慮Microsoft Entra 診斷設定。
** 特定連接器需要額外的許可權,例如「安全性系統管理員」或「資源原則參與者」,以允許串流數據Microsoft Sentinel 工作區、Microsoft Entra ID、Microsoft 365 或 Microsoft Defender,以及 Azure 金鑰保存庫 等平臺即服務 (PaaS) 資源。

特殊許可權存取模型

建議您採用特殊許可權存取模型策略,從特殊許可權存取的高影響和高可能性攻擊中快速降低公司的風險。 在DevOps模型中的自動程式案例中,以服務主體身分識別為基礎

特殊許可權存取應該是每家公司的最高安全性優先順序。 這些身分識別的任何危害都會產生高度負面影響。 特殊許可權身分識別可以存取業務關鍵資產,這幾乎一律會在攻擊者入侵這些帳戶時造成重大影響。

特殊許可權存取的安全性非常重要,因為它是所有其他安全性保證的基礎。 控制特殊許可權帳戶的攻擊者可能會破壞所有其他安全性保證。

基於這個理由,建議您遵循最低許可權原則,以邏輯方式將服務主體分散到不同的層級或層級。 下圖顯示如何根據存取類型和需要存取的位置來分類服務主體。

管線中特殊許可權存取模型分層架構的圖表。

層級 0 服務主體

層級 0 服務主體具有最高層級的許可權。 這些服務主體可讓某人以全域管理員身分執行全租使用者或根管理群組管理工作。

基於安全性考慮和管理能力,我們建議您在此層級只有一個服務主體。 此服務主體的許可權會持續存在,因此我們建議您只授與所需的最低許可權,並讓帳戶受到監視和保護。

將此帳戶的秘密或憑證安全地儲存在 Azure 金鑰保存庫 中。 強烈建議您盡可能在專用的系統管理訂用帳戶中找到金鑰保存庫。

層級 1 服務主體

層級 1 服務主體已提升的許可權,這些許可權僅限於商務組織層級的管理群組。 這些服務主體可讓某人在範圍中的管理群組下建立訂用帳戶。

基於安全性考慮和管理能力,我們建議您在此層級只有一個服務主體。 此服務主體的許可權會持續存在,因此強烈建議您只授與所需的最低許可權,並讓帳戶受到監視和保護。

將此帳戶的秘密或憑證安全地儲存在 Azure 金鑰保存庫。 強烈建議您盡可能在專用的系統管理訂用帳戶中找到金鑰保存庫。

層級 2 服務主體

層級 2 服務主體僅限於訂用帳戶層級。 這些服務主體會授權某人在訂用帳戶下執行系統管理工作,以作為訂用帳戶擁有者。

基於安全性考慮和管理能力,我們建議您在此層級只有一個服務主體。 此服務主體的許可權會持續存在,因此強烈建議您只授與所需的最低許可權,並讓帳戶受到監視和保護。

將此帳戶的秘密或憑證安全地儲存在 Azure 金鑰保存庫。 強烈建議您在專用的系統管理資源群組中找到金鑰保存庫。

層級 3 服務主體

層級 3 服務主體僅限於工作負載管理員。 在一般案例中,每個工作負載都包含在相同的資源群組內。 此結構會將服務主體許可權限制為僅此資源群組。

基於安全性考慮和管理性,我們建議您每個工作負載只有一個服務主體。 此服務主體的許可權會持續存在,因此強烈建議您只授與所需的最低許可權,並讓帳戶受到監視和保護。

將此帳戶的秘密或憑證安全地儲存在 Azure 金鑰保存庫 中。 強烈建議您在專用的系統管理資源群組中找到金鑰保存庫。

層級 4 服務主體

層級 4 服務主體具有最有限的許可權。 這些服務主體可讓某人執行限制為一個資源的系統管理工作。

建議您盡可能使用受控識別。 在非受控識別的情況下,請將秘密或憑證安全地儲存在儲存層級 3 秘密的 Azure 金鑰保存庫。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊,請參閱卓越營運要素的概觀 (部分機器翻譯)。

Microsoft Sentinel 解決方案是由三個區塊所組成,可確保作業完成且成功。

第一個區塊是環境定義,構成基本架構元素。 您對此區塊的主要考慮是考慮要部署的生產和非生產環境數目,然後確定所有情況下的設定都是同質的。

第二個區塊是Microsoft Sentinel 連接器部署,您可以在其中考慮小組所需的連接器種類,以及啟用連接器的安全性需求。

第三個區塊是 sentinel 成品生命週期管理Microsoft,其中涵蓋元件的編碼、部署和使用或破壞。 例如,此區塊包含分析規則、劇本、活頁簿、威脅搜捕等等。

請考慮成品之間的這些相依性:

  • 分析規則中定義的自動化規則
  • 需要新數據源或連接器的活頁簿或分析
  • 管理現有元件的更新
    • 如何為您的成品建立版本
    • 如何識別、測試及部署更新或全新的分析規則

建置、測試及部署基礎結構

在管理Microsoft Sentinel 解決方案和 DevOps 時,請務必考慮企業架構的連線和安全性層面。

Azure DevOps 可以使用Microsoft裝載的代理程式或自我裝載的代理程式來建置、測試及部署活動。 視公司的需求而定,您可以使用Microsoft裝載、自我裝載或這兩種模型的組合。

  • Microsoft 裝載的代理程式。 此選項是使用 Azure DevOps 代理程式最快的方式,因為它是整個組織的共用基礎結構。 如需在管線中使用Microsoft裝載代理程序的詳細資訊,請參閱 Microsoft裝載的代理程式。 Microsoft裝載的代理程式可以在混合式網路環境中運作,並授與IP範圍的存取權。 若要下載這些代理程式授與存取權的IP範圍,請參閱 Azure IP 範圍和服務標籤 – 公用雲端
  • 自我裝載的代理程式。 此選項可讓您在為組建和部署安裝相依軟體時,提供專用的資源和更多控制權。 自我裝載代理程式可以透過 Azure 上的 VM、擴展集和容器運作。 如需自我裝載代理程式的詳細資訊,請參閱 Azure Pipelines 代理程式

GitHub 執行器

GitHub 可以針對與建置、測試和部署相關的活動,使用 GitHub 裝載的執行器或自我裝載執行器。 視公司的需求而定,您可以使用 GitHub 裝載、自我裝載或這兩種模型的組合。

GitHub 裝載執行器

此選項是使用 GitHub 工作流程最快的方式,因為它是整個組織的共用基礎結構。 如需詳細資訊,請參閱 關於 GitHub 裝載的執行器。 GitHub 裝載的代理程式會根據特定網路需求,在混合式網路環境中運作。 如需網路需求的詳細資訊,請參閱 支援的執行器和硬體資源

自我裝載執行器

此選項可為您的公司提供專用的資源基礎結構。 自我裝載執行器可透過 Azure 上的 VM 和容器運作,並支援自動調整。

選擇執行器的考慮

在Microsoft Sentinel 解決方案中選擇代理程式和執行器的選項時,請考慮下列需求:

  • 您的公司是否需要專用資源,才能在Microsoft Sentinel 環境中執行程式?
  • 您要隔離生產環境 DevOps 活動的資源與其餘環境嗎?
  • 您是否需要測試某些案例,這些案例需要存取只能在內部網路上使用的重要資源或資源?

發行程序的協調流程和自動化

您可以使用 Azure DevOps 或 GitHub 來設定部署程式。 Azure DevOps 支援使用 YAML 管線或發行管線。 如需在 Azure DevOps 中使用 YAML 管線的詳細資訊,請參閱 使用 Azure Pipelines。 如需在 Azure DevOps 中使用發行管線的詳細資訊,請參閱 發行管線。 如需搭配 GitHub Actions 使用 GitHub 的詳細資訊,請參閱 瞭解 GitHub Actions

Azure DevOps

您可以在 Azure DevOps 部署中執行下列部署活動。

  • 使用 YAML 管線自動觸發 PR 核准或視需要執行。
  • 使用 Azure DevOps 群組來管理不同環境的服務連線。
  • 在您的重要環境中,使用服務連線功能和 Azure DevOps 群組來設定部署核准,以指派小組中的特定用戶權力。

GitHub

您可以在 GitHub 部署中執行下列部署活動。

  • 使用 GitHub 建立 PR 或部署活動。
  • 使用 GitHub 秘密來管理服務主體認證。
  • 透過與 GitHub 相關聯的工作流程整合部署核准。

使用 Microsoft Sentinel 基礎結構自動部署

視您的企業架構而定,您可以部署一或多個Microsoft Sentinel 環境:

  • 在其生產環境上需要多個實例的組織,可以在每個地理位置的相同租用戶上設定不同的訂用帳戶。
  • 生產環境上的集中式實例可讓您存取相同租使用者上的一或多個組織。
  • 需要生產階段、生產前、整合等多個環境的群組可以視需要建立和終結它們。

實體與邏輯環境定義

您在設定環境定義、實體或邏輯方面有兩個選擇。 兩者都有不同的選項和優點:

  • 實體定義 - Microsoft Sentinel 架構的元素是使用下列基礎結構即程式代碼選項來定義 (IaC):
    • Bicep 範本
    • Azure Resource Manager 範本 (ARM 範本)
    • Terraform
  • 邏輯定義 - 這可作為在群組中設定不同小組並定義其環境的抽象層。 定義會在部署管線和工作流程中設定為使用實體基礎結構層的建置環境輸入。

當您定義邏輯環境時,請考慮下列幾點:

  • 命名規範
  • 環境識別
  • 連接器和組態

程式碼存放庫

假設上一節中顯示的環境方法,請考慮下列 GitHub 程式代碼存放庫組織。

實體定義 - 根據 IaC 選項,思考使用在主要部署定義中連結的個別模塊定義的方法。

下列範例示範如何組織程序代碼。

GitHub 中可能用於實體環境定義的程式代碼組織圖表。

將此存放庫的存取限制為小組,以定義實體層級的架構,確保企業架構中的同質定義。

您可以將分支和合併策略調整為每個組織的部署策略。 如果您的小組必須從定義開始,請參閱 採用 Git 分支策略

如需 ARM 範本的詳細資訊,請參閱 在部署 Azure 資源時使用連結和巢狀範本。

如需設定 Bicep 環境的詳細資訊,請參閱 安裝 Bicep 工具。 如需 GitHub 的詳細資訊,請參閱 GitHub 流程

邏輯定義會定義公司的環境。 Git 存放庫會收集公司的不同定義。

下列範例示範如何組織程序代碼。

GitHub 中邏輯環境定義的可能程式代碼組織圖表。

存放庫會反映不同小組所執行的PR動作。 多個環境是由不同的小組所定義,並由公司的擁有者或核准者核准。

執行環境部署的許可權等級為層級 2。 此層級可確保針對具有必要安全性和隱私權的環境建立資源群組和資源。 此層級也會設定生產環境、生產階段和生產階段前允許動作的用戶許可權。

想要隨選環境進行測試和開發環境,以及在完成測試之後終結環境的組織,可以實作 Azure DevOps 管線或 GitHub 動作。 他們可以使用 Azure DevOps 事件或 GitHub 動作,視需要設定排程觸發程式來終結環境。

Microsoft Sentinel 連接器自動設定

Microsoft Sentinel 連接器是解決方案的重要組成部分,可支援在企業架構環境中與不同的元素連線,例如Microsoft Entra ID、Microsoft 365、Microsoft Defender、威脅情報平台解決方案等等。

當您定義環境時,您可以使用連接器組態來設定具有同質組態的環境。

服務主體層級模型必須支援在 DevOps 模型中啟用連接器。 此焦點可確保正確的許可權層級,如下表所示。

連接器案例 許可權存取模型層級 Azure 最低許可權 需要工作流程核准
Microsoft Entra ID 層級 0 全域管理員或安全性系統管理員 建議需求
Microsoft Entra ID Protection 層級 0 全域管理員或安全性系統管理員 建議需求
適用於身分識別的 Microsoft Defender 層級 0 全域管理員或安全性系統管理員 建議需求
Microsoft Office 365 層級 0 全域管理員或安全性系統管理員 建議需求
Microsoft Cloud App Security 層級 0 全域管理員或安全性系統管理員 建議需求
Microsoft Defender 全面偵測回應 (部分機器翻譯) 層級 0 全域管理員或安全性系統管理員 建議需求
適用於 IOT 的 Microsoft Defender 層級 2 參與者 建議需求
適用於雲端的 Microsoft Defender 層級 2 安全性讀取者 選擇性
Azure 活動 層級 2 訂閱讀者 選擇性
威脅情報平台 層級 0 全域管理員或安全性系統管理員 建議需求
安全性事件 層級 4 選擇性
Syslog 層級 4 選擇性
DNS (預覽) 層級 4 選擇性
Windows 防火牆 層級 4 選擇性
透過 AMA 的 Windows 安全性事件 層級 4 選擇性

Microsoft Sentinel 成品部署

在實作Microsoft Sentinel成品時,DevOps 會獲得更大的相關性,因為每個公司都會建立多個成品來防止和補救攻擊。

實作成品可以是一個小組或多個小組的責任。 自動建置和成品部署通常是最常見的程式需求,並決定代理程式和執行器的方法和條件。

部署和管理 Sentinel 成品Microsoft需要使用 Microsoft Sentinel REST API。 如需詳細資訊,請參閱 Microsoft Sentinel REST API。 下圖顯示 Azure REST API 堆疊上的 Azure DevOps 管線。

Microsoft Sentinel API 堆棧上的 Azure DevOps 管線圖表。

您也可以使用 PowerShell 來實作存放庫。

如果您的小組使用 MITRE,請考慮分類不同的成品,併為每個成品指定策略和技術。 請確定您為每個成品類型包含對應的元數據檔案。

例如,如果您要使用 Azure ARM 範本建立新的劇本,而且檔名是Playbook.arm.json,您會新增名為 Playbook.arm.mitre.jsonJSON 檔案。 此檔案的元數據接著會包含 CSV、JSON 或 YAML 格式,這些格式會對應至您所使用的 MITRE 策略或技術。

遵循這種做法,您的小組可以根據您在設定期間針對您使用的不同成品類型所完成的工作評估MITRE 涵蓋範圍。

組建成品

建置程序的目標是要確保您產生品質最高的成品。 下圖顯示您可以採取的一些建置程序動作。

顯示Microsoft Sentinel 建置程序的圖表。

下載此架構的 Visio 檔案

  • 您可以將成品定義以 JSON 或 YAML 格式的描述性架構為基礎,然後驗證架構以避免語法錯誤。
    • 使用 ARM樣本測試工具組來驗證ARM範本。
    • 使用 PowerShell 驗證自定義模型的 YAML 和 JSON 檔案。
  • 驗證您的關注清單設定,並確定您定義的無類別網路變數間路由 (CIDR) 記錄遵循正確的架構,例如 10.1.0.0/16。
  • 使用關鍵字查詢語言 (KQL) 查詢,您可以在語法層級進行驗證,以取得分析規則、搜捕規則和即時串流規則,您可以在語法層級進行驗證。
  • 將 KQL 本機驗證設為一個選項。
  • DevOps 管線中整合 KQL 內嵌驗證 工具。
  • 如果您要實作以 PowerShell 為基礎的邏輯來 Azure 自動化,您可以使用下列元素來包含語法驗證和單元測試:
  • 根據成品隨附的元數據檔案,產生 MITRE 指令清單元數據報告。

匯出成品

通常,多個小組會處理數個Microsoft Sentinel 實例,以產生必要的成品並加以驗證。 為了重複使用現有的成品,您的公司可以設定自動程式,從現有環境取得成品定義。 自動化也可以提供有關安裝期間由不同開發小組所建立之任何成品的資訊。

下圖顯示範例成品擷取程式。

顯示Microsoft Sentinel成品擷取程序的圖表。

下載此架構的 Visio 檔案

部署成品

部署程式的目標是:

  • 縮短上市時間。
  • 提高與設定和管理解決方案相關的多個小組的效能。
  • 設定整合測試以評估環境的健康情況。

開發小組會使用程式,以確保他們可以部署、測試及驗證正在開發中的成品使用案例。 架構和SOC小組會驗證QA環境的管線品質,並針對攻擊案例使用整合測試。 在測試案例中,小組通常會將不同的成品合併為分析規則、補救劇本、監看清單等等。 每個使用案例的一部分包括模擬攻擊,其中會從擷取、偵測和補救評估整個鏈結。

下圖顯示部署程式順序,可確保您的成品以正確的順序部署。

顯示Microsoft Sentinel成品部署程序的圖表。

下載此架構的 Visio 檔案

以程式代碼身分管理 Sentinel 成品可讓您彈性地維護作業,並將 CI/CD DevOps 管線中的部署自動化。

Microsoft解決方案提供下列成品的自動化工作流程。

成品 自動化工作流程
關注清單 程式代碼檢閱
架構驗證

[部署]
建立、更新、刪除關注清單和 專案
分析規則融合
Microsoft 安全性
ML 行為分析
異常狀況
已排程
程式代碼檢閱
KQL 語法驗證
結構描述驗證
Pester

[部署]
建立、啟用、更新、刪除、匯出
警示範本支援
自動化規則 程式代碼檢閱
結構描述驗證

[部署]
建立、啟用、更新、刪除、匯出
連接器 程式代碼檢閱
結構描述驗證

[部署]
動作:啟用、刪除(停用)、更新
搜捕規則 程式代碼檢閱
KQL 語法驗證
結構描述驗證
Pester

[部署]
動作:建立、啟用、更新、刪除、匯出
劇本 程式代碼檢閱
TTK

[部署]
動作:建立、啟用、更新、刪除、匯出
活頁簿 [部署]
動作:建立、更新、刪除
Runbook 程式代碼檢閱
PowerShell 語法驗證
Pester

[部署]
動作:建立、啟用、更新、刪除、匯出

視您選擇的自動化語言而定,可能不支援某些自動化功能。 下圖顯示語言支援哪些自動化功能。

支援的自動化功能圖表。

* 開發中尚未記載的功能
** Microsoft Operational InsightsMicrosoft Insights 資源提供者 API 支援的自動化方法

Azure 自動化

下圖顯示使用受控服務識別簡化Microsoft Sentinel 存取的元件。

使用受控服務識別簡化Microsoft Sentinel 存取的圖表。

下載此架構的 Visio 檔案

如果您需要授與其他資源的存取權,請使用受控識別,以確保所有重要作業的唯一身分識別。

使用 Azure 自動化 來設定劇本。 針對下列複雜的工作和自動化功能使用PowerShell腳本:

  • 與第三方解決方案整合,其中需要不同層級的認證,並根據 entra ID 或自定義認證Microsoft:
    • Microsoft Entra 使用者認證
    • Microsoft Entra 服務主體認證
    • 憑證驗證
    • 自訂認證
    • 受控識別
  • 實作可重複使用組織腳本的解決方案,或需要使用PowerShell命令的解決方案,以避免將複雜的翻譯轉譯成劇本:
    • 以 PowerShell 為基礎的解決方案
    • 以 Python 為基礎的解決方案
  • 在混合式案例中實作解決方案,其中補救動作可能會影響您的雲端和內部部署資源。

Microsoft Sentinel 存放庫

經驗豐富的DevOps小組可能會考慮使用 Azure DevOps 內建的 CI/CD 管線,在基礎結構中管理 Microsoft Sentinel。 產品群組瞭解客戶和合作夥伴在建置 Azure DevOps 安全性架構時所面臨的挑戰,因此下列兩個計劃可協助:

  • 記錄參考架構
  • 在 Ignite 2021 上宣布開發新的解決方案,稱為「Microsoft Sentinel 存放庫」

為了支持選擇符合小組需求的解決方案,下表會比較功能和技術準則。

使用案例和功能 Azure DevOps 和 GitHub 自定義方法 Microsoft Sentinel 存放庫
我們想要快速開始部署Microsoft Sentinel 成品,而不需要花時間定義 Azure DevOps 架構元件,例如代理程式、管線、Git、儀錶板、Wiki、服務主體、RBAC、稽核等等。 不建議 建議需求
我們有小型小組和低技能集來管理 CI/CD 管線。 不建議 建議需求
我們想要控制及管理 CI/CD 管線的所有安全性層面。 支援 不支援
我們需要整合閘道和分支以進行監督整合,才能讓開發人員觸發部署管線,例如原始檔控制、程式代碼檢閱、復原、工作流程核准等等。 支援 部分支援
我們有自定義的 Git 或存放庫結構。 支援 支援
我們不會使用 Resource Manager 或 Bicep IaC 語言來建置成品。 支援 不支援
我們想要集中管理將成品部署至單一Microsoft Entra 租使用者中的多個Microsoft Sentinel 工作區。 支援 支援
我們想要跨多個Microsoft Entra 租使用者整合或擴充 CI/CD 管線。 支援 支援
根據訂用帳戶、位置、環境等,我們有不同參數化的劇本。 支援 TBD,要記錄的指導方針
我們想要在相同的存放庫上整合不同的成品,以撰寫使用案例。 支援 支援
我們希望能夠大量移除成品。 支援 不支援

可用性、效能和延展性

針對Microsoft Sentinel 案例選擇公司中 Azure DevOps 代理程式的架構時,請考慮下列需求:

  • 生產環境可能需要專用的代理程式集區,以用於Microsoft Sentinel 環境的作業。
  • 非生產環境可能會與大量實例共用代理程式集區,以處理小組的不同需求,特別是 CI/CD 做法。
    • 攻擊模擬案例是需要專用代理程式的特殊案例。 請考慮您的測試需求是否需要專用集區。
  • 在混合式網路案例中運作的組織可能會考慮整合網路內的代理程式。

組織可以根據容器為代理程式建立自己的映像。 如需詳細資訊,請參閱 在 Docker 中執行自我裝載代理程式。

使用 Azure DevOps Microsoft Sentinel 跨租使用者管理

身為全域 SOC 或 MSSP,您可能必須管理多個租使用者。 Azure Lighthouse 同時支援跨數個Microsoft Entra 租用戶的調整作業,讓您的管理工作更有效率。 如需詳細資訊,請參閱 Azure Lighthouse 概觀

跨租使用者管理在下列案例中特別有效:

將客戶上線的方法

您有兩個選項可將客戶上線、受控服務供應專案和 ARM 範本。

使用ARM範本手動上線

如果您不想將供應專案發佈至 Azure Marketplace 做為服務提供者,或不符合所有需求,您可以使用 ARM 範本手動將客戶上線。 這是企業案例中最有可能的選項,其中相同企業有多個租使用者。

下表比較上線方法。

考量 受控服務供應項目 ARM 範本
需要合作夥伴中心帳戶 No
需要銀級或金級雲端平臺專長認證等級Azure 專家受控服務提供者 (MSP) 狀態 No
透過 Azure Marketplace 提供給新客戶 No
可以限制特定客戶的供應項目 是 (僅適用於私人供應專案,無法與透過 CSP 方案的轉銷商建立的訂用帳戶搭配使用) Yes
要求客戶在 Azure 入口網站中接受 No
可以使用自動化將多個訂用帳戶、資源群組或客戶上線 No Yes
立即存取新的內建角色和 Azure Lighthouse 功能 不一定 (在某些延遲之後正式推出) Yes

如需發佈受控服務供應專案的詳細資訊,請參閱 將受控服務供應專案發佈至 Azure Marketplace

如需如何建立 ARM 範本的詳細資訊,請參閱 建立和部署 ARM 範本

下圖顯示 MSSP 租使用者與客戶資源提供者租使用者與 Azure Lighthouse 與 Microsoft Sentinel 之間的高階架構整合。

顯示Microsoft Sentinel 受控服務識別架構的圖表。

下載此架構的 Visio 檔案

  1. MSP 供應專案會透過ARM樣本或 Azure Marketplace 服務供應專案整合。
  2. Azure 委派的資源管理會檢查要求是否來自合作夥伴租使用者,並呼叫受控服務提供者。
  3. 受控服務提供者會使用 RBAC 來控制 MSP 的存取權。
  4. MSP 會在客戶資源上完成 SecOps 動作。
  5. 計費程式會將費用視為客戶費用。 如果客戶實體在相同Microsoft Entra 租使用者中有個別工作區,就有可能進行分割計費。
  6. 數據的安全性和主權取決於客戶的租用戶界限。
跨多個租使用者的身分識別

若要使用 Azure DevOps 管理Microsoft Sentinel,請評估元件的下列設計決策。

使用案例 優點
用於管理DevOps動作、單一服務主體的全域身分識別 此案例適用於涉及所有租使用者的全域部署程式。

使用統一身分識別可協助存取不同的租使用者,但可能會讓管理特定租使用者的核准動作程式變得複雜。

這種身分識別的保護機制和授權模型也非常重要,以避免因相關全球影響而產生的非授權使用方式。
用於管理DevOps動作、多個服務主體的專用身分識別 此案例適用於每個租使用者或租用戶動作專用的部署程式需要核准時。

在此情況下,保護及授權此身分識別使用方式的建議與全域案例相同,即使影響降低也一樣。
程序代碼存放庫組織
使用案例 優點
針對所有租使用者使用單一版本的程式代碼整合存放庫 此案例有助於為存放庫中的程式碼提供統一版本。

在此情況下,管理租使用者特定版本之程式代碼的統一版本可能需要支援每個案例的分支。
依租使用者使用特定程式代碼資料夾的整合存放庫 此案例可補充單一存放庫案例。 在這裡,資料夾結構可以依租使用者分割專用成品。
依租使用者指定的專用存放庫 此方法會在管理程式代碼成品時提供隔離。 這可讓具有不同小組或需求之租用戶之間的演進變得更容易。

合併變更需要建立存放庫之間的程式,這可能需要努力維護。
建置和部署程式
使用案例 優點
所有租用戶的單一建置程式 當所有租使用者都使用相同的成品版本時,這是實作產生和套件的最直接選項。
依租用戶建置程式 不同的程式代碼版本會部署到每個租使用者。
所有租使用者的全域部署程式 部署的新部署和更新會套用至所有租使用者。 部署和更新程式的步驟會用於所有租使用者。
依租使用者排序的全域部署程式租使用者 部署的新部署和更新會套用至一或多個租使用者。
依租使用者的專用部署程式 部署程式會針對每個租用戶進行調整。

成本最佳化

成本優化是減少不必要的費用,並提升營運效率。 如需詳細資訊,請參閱成本最佳化要素的概觀

解決方案的成本取決於下列因素:

  • 貴公司每月饋送至 Microsoft Sentinel Log Analytics 工作區的數據量
  • 您選擇的承諾層或計費方法,例如隨用隨付 (PAYG)
  • 數據表或全域層級的數據原則保留率

如需詳細資訊,請參閱 Azure 數據類型保留

若要計算價格,請參閱 Microsoft Sentinel 定價計算機。 如需進階定價考慮和範例的詳細資訊,請參閱 規劃Microsoft Sentinel 的成本

如果您使用下列元件擴充解決方案,可能會產生額外的成本:

  • 劇本 - Azure Logic Apps 和 Azure Functions 的運行時間。 如需詳細資訊,請參閱 定價詳細數據
  • 匯出至外部記憶體,例如 Azure 數據總管、事件中樞或 Azure 儲存體 帳戶。
  • 機器學習工作區和 Jupyter Notebook 元件所使用的計算。

部署此案例

下一節說明以涵蓋各種 DevOps 程式之範例使用案例形式部署此案例的步驟。

建置並釋放 Microsoft Sentinel 架構

首先,在專用存放庫中設定必要的 NuGet 元件,其中不同的進程可以取用您產生的版本。

如果您使用 Azure DevOps,您可以建立元件摘要,以裝載 PowerShell Microsoft Sentinel 架構中的不同 NuGet 套件。 如需詳細資訊,請參閱 開始使用 NuGet 套件

如何建立元件摘要來裝載 NuGet 套件的螢幕快照。

如果您的小組選擇 GitHub 登錄,您可以將它連線為 NuGet 存放庫,因為它與摘要通訊協定相容。 如需詳細資訊,請參閱 GitHub 套件簡介。

當您有可用的 NuGet 存放庫時,管線會包含 NuGet 的服務連線。 這些螢幕快照顯示名為 Microsoft Sentinel NuGet Framework Connection 之新服務連線的組態。

如何建立新服務連線的螢幕快照。

如何編輯服務連線的螢幕快照。

設定摘要之後,您可以匯入管線,以便直接從特定分支中的 GitHub 建置 PowerShell 架構。 如需詳細資訊,請參閱 建置 GitHub 存放庫。 在此情況下,您會建立新的管線,然後選擇 [GitHub] 作為程式代碼來源。

另一個選項是將 Git 存放庫匯入為以 Git 為基礎的 Azure DevOps 存放庫。 在這兩種情況下,若要匯入管線,請指定下列路徑:

src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml

現在您可以第一次執行管線。 然後,架構會建置並發行至 NuGet 摘要。

定義您的Microsoft Sentinel 環境

從 Microsoft Sentinel 開始並使用這些範例時,請定義公司中的環境,例如,環境即程序代碼或 EaC。 您可以指定每個案例中組成環境的不同元素。

Microsoft Sentinel 架構包含 Azure 上的下列元素:

  • Log Analytics 工作區 - 此工作區會形成解決方案的基礎。 安全性相關信息會儲存在這裡,工作區是 Kusto 查詢語言 (KQL) 的引擎。
  • 透過 Log Analytics 工作區Microsoft Sentinel 解決方案 - 此解決方案會擴充 Log Analytics 工作區的功能,以包含 SIEM 和 SOAR 功能。
  • 金鑰保存庫 - 金鑰保存庫會保留補救程式期間所使用的秘密和密鑰。
  • 自動化帳戶 - 此帳戶為選擇性帳戶,並用於補救程式。 您使用的補救程式是以 PowerShell 和 Python Runbook 為基礎。 此程式包含系統管理的身分識別,可根據最佳做法使用不同的資源。
  • 使用者受控識別 - 這項功能可作為Microsoft Sentinel 統一身分識別層,管理Microsoft Sentinel 劇本與 Runbook 之間的互動。
  • 邏輯應用程式連線 - 這些連線適用於Microsoft Sentinel、密鑰保存庫,以及使用使用者受控識別的自動化。
  • 外部邏輯應用程式連線 - 這些是涉及補救程式且以劇本為基礎的外部資源的連線。
  • Azure 事件中樞 - 這項功能是選擇性的,可處理Microsoft Sentinel 與其他解決方案之間的整合,例如Splunk、Azure Databricks和機器學習,以及復原。
  • 儲存器帳戶 - 這項功能是選擇性的,可處理Microsoft Sentinel 與其他解決方案之間的整合,例如Splunk、Azure Databricks和機器學習,以及復原。

藉由使用存放庫的範例,您可以使用 JSON 檔案來定義環境,以指定不同的邏輯概念。 可用來定義環境的選項可以是常值或自動。

在常值定義中,您可以指定環境中每個資源的名稱和元素,如本範例所示。

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Literal",
            "ResourceGroupName": "<resource-group-name>"
         }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Literal",
            "LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
            "ManagedIdentityName": "<user-managed-identity-name>",
            "SentinelConnectionName": "<Sentinel-API-connection-name>",
            "KeyVaultName": "<Key-Vault-name>",
            "KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
        },
        "Automation":
        {
            "Type": "Literal",
            "AutomationAccountName": "<automation-account-name>",
            "AutomationAccountConnectionName": "<automation-account-API-connection-name>"
        },
        "Integration":
        {
            "Type": "Literal",
            "EventHubNamespaces": [
                "<Event-Hubs-namespace-1-name>",
                "<Event-Hubs-namespace-2-name>",
                "<Event-Hubs-namespace-3-name>",
                "<Event-Hubs-namespace-4-name>",
                "<Event-Hubs-namespace-5-name>",
                "<Event-Hubs-namespace-6-name>",
                "<Event-Hubs-namespace-7-name>",
                "<Event-Hubs-namespace-8-name>",
                "<Event-Hubs-namespace-9-name>",
                "<Event-Hubs-namespace-10-name>",
            ],
            "StorageAccountName": "<storage-account-name>"
        }
    }
}

在自動定義中,專案名稱會根據命名慣例自動產生,如此範例所示。

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Automatic"
        }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Automatic"
        },
        "Automation":
        {
            "Type": "Automatic"
        },
        "Integration":
        {
            "Type": "Automatic",
            "MaxEventHubNamespaces": 5
        }
    }
}

您可以在 Microsoft Sentinel 環境路徑下的 GitHub 存放庫中找到範例,並使用範例作為準備使用案例的參考。

部署Microsoft Sentinel 環境

當您至少定義一個環境時,可以建立 Azure 服務連線來與 Azure DevOps 整合。 建立服務連線之後,請將連結的服務主體設定為擁有者角色,或目標訂用帳戶上類似的許可權等級。

  1. 匯入管線,以建立此檔案中所定義的新環境。

    src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml

  2. 接下來,輸入代表環境的服務連線名稱。

    如何輸入服務連線名稱的螢幕快照。

  3. 選擇存放庫中環境定義的分支。 

  4. 在 [Azure 環境連線] 方塊中 輸入訂用帳戶的 Azure DevOps 服務連線 名稱。

  5. 輸入服務連線可用來解析相同訂用帳戶中多個環境的環境名稱。

  6. 選擇要套用至連接器的動作。

  7. 如果您想要使用 PowerShell 架構元件的發行前版本,請選取 [使用 PowerShell 發行前版本成品 ]。

管線包含下列步驟作為部署流程的一部分:

  • 部署 NuGet 元件。
  • 使用 NuGet 工具與成品存放庫進行連線。
  • 解決摘要。
  • 安裝必要的模組。
  • 取得環境定義。
  • 驗證目的地中存在哪些資源。
  • 如果 Log Analytics 和 sentinel 不在工作區中,請新增 Microsoft Sentinel。
  • 如果您已經有Log Analytics,請在Log Analytics實例上新增 Microsoft Sentinel。
  • 建立受控識別來代表 Sentinel 與 Logic Apps Microsoft之間的互動。
  • 建立 Azure 金鑰保存庫,並將管理秘密和金鑰的角色指派設定為受控識別。
  • 如果適用,請建立 Azure 自動化 帳戶,並開啟系統指派的受控識別。
  • 為系統指派的受控識別設定金鑰保存庫的角色指派。
  • 如果事件中樞定義不存在,請建立事件中樞定義,並設定定義是否包含整合元素。
  • 為系統指派的受控識別設定金鑰保存庫的角色指派。
  • 如果記憶體帳戶定義不存在,請建立記憶體帳戶定義,並設定定義是否包含整合元素。
  • 為系統指派的受控識別設定金鑰保存庫的角色指派。
  • 部署連接器動作。
  • 在自動化帳戶上部署整合 Runbook。
  • 如果將 Logic Apps 連線定義為環境的一部分,請部署它們。

終結Microsoft Sentinel 環境

當不再需要環境時,例如開發或測試環境的情況,您可以終結它,如此檔案中所定義。

src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml

當您部署環境管線時,您可以指定代表環境的服務連線名稱。

使用您的 Microsoft Sentinel 環境

環境就緒之後,您可以開始建立成品來設定不同的使用案例。

  1. 從您所處理的環境導出成品,如此檔案中所定義。

    src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.yml

  2. 選擇存放庫中環境定義的分支。

    如何選擇要匯出成品之分支的螢幕快照。

  3. 在 [Azure 環境連線] 方塊中,輸入要匯出之環境的 Azure DevOps 服務連線名稱。

  4. 如果您想要使用 PowerShell 架構元件的發行前版本,請選取 [使用 PowerShell 發行前版本成品 ]。

  5. 選擇分析和搜捕規則的格式。

    結果中提供成品輸出檔案。 擁有成品之後,您可以在 Git 存放庫中包含輸出檔案。

在 Microsoft Sentinel 環境中建置您的成品

將您的成品放在Microsoft Sentinel MITRE 使用案例路徑之下。 根據不同類型的成品設定資料夾結構。

  1. 啟動此檔案中所定義的建置程式。

    src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yaml

  2. 選擇存放庫中環境定義的分支。

    如何選擇要建置成品的分支圖表。](./media/build-artifacts-pipeline.png)

  3. 如果您想要使用 PowerShell 架構元件的發行前版本,請選取 [使用 PowerShell 發行前版本成品 ]。

管線是由下列步驟所組成:

  • 部署 NuGet 元件。
  • 將 NuGet 工具連線至成品存放庫。
  • 解決摘要。
  • 安裝必要的模組。
  • 取得測試工具組架構,以驗證ARM範本。
  • 驗證 ARM 範本。
  • 驗證 PowerShell Runbook 程式代碼並執行語法驗證。
  • 如果適用,請執行 Pester 單元測試。
  • 驗證搜捕和分析規則中的 KQL 語法。

將您的成品部署至 Microsoft Sentinel 環境

在部署成品時,您可以使用Microsoft Sentinel 存放庫或此存放庫上的部署管線範例。 如需詳細資訊,請參閱 從存放庫部署自定義內容。

Microsoft Sentinel 存放庫

如果您使用 Microsoft Sentinel 存放庫,您可以設定發行程式,將成品包含在連線至每個Microsoft Sentinel 實例的存放庫中。 在存放庫中認可成品之後,會在建立管線並啟用 Microsoft Sentinel 存放庫時自動完成一些步驟。

此外,您也可以根據本檔中所述的做法,自定義Microsoft Sentinel 存放庫執行的部署程式。 要考慮的一個重要層面是發行核准,您可以遵循下列方法進行設定:

Microsoft Sentinel 部署管線範例

藉由使用Microsoft Sentinel 部署管線範例,您可以設定發行程式。

  1. 將此檔案中所定義的發行程式設定為 。

    src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.yml

  2. 選擇存放庫中環境定義的分支。

    如何選擇要設定發行程式的分支螢幕快照。

  3. 在 [Azure 環境連線] 方塊中,輸入要匯出之環境的 Azure DevOps 服務連線名稱。

  4. 如果您想要使用 PowerShell 架構元件的發行前版本,請選取 [使用 PowerShell 發行前版本成品 ]。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者:

若要查看非公開的 LinkedIn 設定檔,請登入 LinkedIn。

下一步