Microsoft AZ-500: Microsoft Sentinel 與安全營運 — 學習指南

By Laurynas Brazys · 12 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

屬於 Microsoft Azure Security Engineer Associate AZ-500 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Microsoft Sentinel 是 Azure 的雲端原生 SIEM 和 SOAR 平台，建構於 Azure Monitor Log Analytics 之上。它集中管理安全性遙測資料，應用分析來偵測威脅，產生事件供分析師進行分類處理，並透過 Logic Apps 自動化編排回應。有效的維運取決於精心設計的工作區架構、審慎的資料上線、具成本意識的資料保留策略、精確的分析與實體對應，以及一套能將警示與 SOC 工作流程及業務風險對齊的自動化與調校機制。

Sentinel 架構與資料管理

• 工作區與多租戶考量

  • Sentinel 以每個 Log Analytics 工作區為單位執行。應根據資料主權、延遲和管理隔離需求來選擇工作區的邊界。單一的「中央 SOC」工作區可簡化關聯分析和內容管理；而對於有嚴格落地要求、自主性需求或 MSSP/Lighthouse 模型的場景，使用多個工作區可能更為合適。雖然支援跨工作區查詢，但會增加查詢延遲和成本；當跨實體的關聯分析至關重要時，建議優先考慮整合。
  • 在工作區上使用以資源為情境的 RBAC 來劃分職責：Sentinel Reader 用於儀表板，Responder 用於事件處理，Contributor 用於內容管理，而 Automation Contributor 則用於 playbooks。

• 擷取路徑

  • 資料透過原生連接器、Azure Monitor 代理程式或 API 進入工作區中的資料表。對於 Microsoft 來源，建議優先使用原生連接器（結構描述經優化、可靠性高）；對於 Windows/Syslog，則建議使用 AMA+DCR 以獲得篩選能力和個別資料表的方案控制權。對於第三方設備，將 CEF 透過 Syslog 路由至 CommonSecurityLog 資料表，以利用內建的剖析器和分析內容。

• 保留、封存與搜尋

  • 設定各資料表的保留期限，將熱資料（用於互動式分析）保留在操作偵測的窗口期內（通常為 30-120 天）。將較舊的資料封存至 Log Analytics Archive 層，最長可達 7 年，以極低的成本滿足合規性要求；在調查時可使用 Search Jobs 或 Restore 功能。維運考量：僅保留分析師經常需要深入探查的資料；其餘的則予以封存，以滿足稽核/法規需求，同時避免增加熱路徑的開銷。

• 成本控制

  • 承諾層（容量保留）能針對穩定的資料量，可預測地降低擷取成本；建議在建立 30-60 天的基準線後再啟用，以避免過度承諾。
  • 資料表層級的計費方案：對安全性關鍵資料表（如 SecurityEvent、SignInLogs、CommonSecurityLog）使用 Analytics 模式。對於您不常查詢、內容詳細但價值較低的診斷資料，則使用 Basic Logs；切勿將高信號的安全性資料表放在 Basic 模式，因為它們會失去完整的查詢功能且無法用於警示。
  • 在計費前，使用 DCR 進行擷取時轉換，以捨棄或遮罩欄位和資料列（最小化 PII、降低雜訊）。在維運上，於擷取前消除雜訊是控制成本和提升資料精確度最有效的方法。
  • 設定工作區的每日上限，並針對異常的資料量激增設定警示，以捕捉因設定錯誤或攻擊而產生的日誌風暴。

資料連接器與擷取

• Azure Activity

  • 使用 Azure Activity 連接器，透過診斷設定將訂閱層級的控制平面操作串流至 AzureActivity 資料表。理由：這能捕捉角色變更、策略更新和部署等活動——這些是攻擊者權限提升或竄改的主要指標。

• Microsoft Entra ID (Azure AD)

  • 啟用 AuditLogs 和 SignInLogs 連接器。若有授權，可選擇性地擷取 Enriched Azure AD logs。理由：身分識別是主要的攻擊面；登入異常和目錄變更是大多數偵測和 UEBA 的基礎。

• Microsoft Defender 產品

  • Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps 和 Defender for Cloud 的連接器能帶入高精確度的警示和遙測資料。理由：Microsoft 的安全性警示具有高度關聯性，能提升事件品質；擷取這些資料可用於驅動 Fusion 和 Microsoft 安全性規則，且僅需最少的調校。

• Windows 事件

  • 使用帶有 DCR 的 Azure Monitor Agent (AMA)：將網域控制器 (DC) 和關鍵伺服器的 Windows Security Events 傳送至 SecurityEvent 資料表（可選 Common、Minimal 或 All）；並視需要將一般的 Windows Event 通道傳送至 WindowsEvent。理由：SecurityEvent 是驗證和程序稽核的骨幹；DCR 篩選功能可修剪雜訊（例如，排除沒有 CommandLine 的 4688 事件）。

• Syslog 與 CEF

  • 對於 Linux，可使用 AMA Syslog DCR 選擇特定的 facility/severity 傳送至 Syslog 資料表。對於第三方防火牆/IDS/EDR，將 CEF 轉發到基於 Log Analytics 代理程式的轉發器，或透過 AMA 擷取至 CommonSecurityLog；並使用供應商提供的剖析器內容。理由：CEF 維護了標準化的欄位，減輕了剖析的負擔；CommonSecurityLog 則能啟用預先建置的偵測規則。

• 維運衛生

  • 確保時間同步 (NTP) 和一致的設備時區，以進行準確的關聯分析。
  • 對重疊的資料來源進行去重複處理（例如，不要同時擷取原始資料和標準化後的重複資料）。
  • 在啟用分析規則前，使用 Watchlists 或範例查詢來驗證結構描述，以避免誤報。

分析、偵測與調查

• 分析規則類型

  • 排程規則：以固定頻率（例如：每 5 分鐘執行一次，回溯 1 小時的資料）對歷史資料執行 KQL 查詢。適用於大多數的偵測情境；請調整回溯期間以超過典型的資料延遲，避免遺漏。
  • 近乎即時 (NRT)：使用受限的 KQL 和固定的短回溯期間，達到分鐘級以下的偵測。應謹慎使用於分秒必爭的高緊急性模式（例如：大規模角色指派）。為了效能，操作時應使用最少的 join 和簡單的篩選條件。
  • Fusion：由機器學習驅動，跨 Microsoft 信號（Defender、Entra、Cloud Apps）進行多階段關聯。原理：透過為一個攻擊殺傷鏈產生單一事件，大幅減少警示疲勞。
  • 異常規則：使用動態閾值的用戶/實體基準線。可快速偵測到不尋常的地理位置、流量或程序模式；請維護排除清單以處理經核准的異常情況（例如：維護期間）。
  • Microsoft 安全性規則：從 Defender 警示自動建立事件。請保持啟用，並調整自動化規則以進行路由/嚴重性設定；它們提供高信度的信號，且調整的負擔較低。

• 實體對應與事件

  • 在規則設定中，將 KQL 輸出欄位對應到實體（Account、Host、IP、URL、File），以支援事件圖表和 UEBA。不良的對應會降低調查的精確度。
  • 警示分組策略會影響事件的數量和上下文。依實體/時間範圍分組以合併相關警示，在保留故事線的同時減少雜訊。

• 調查與 UEBA

  • 事件會呈現時間軸、證據和相關實體；調查圖表會根據實體對應和資料查詢自動建立關聯性。
  • 啟用 UEBA 以使用同儕基準線、裝置角色和風險信號來豐富實體資訊。原理：上下文資訊可縮短分類時間，並為應變範圍提供依據。

• 用於偵測工程的 KQL 基礎

  • 篩選與投影

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - 解析與正規化

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• 聯結 (Joining)

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - 摘要與時間範圍分析

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

威脅獵捕、自動化、威脅情資、報告與 SOC 調校

• 威脅獵捕工作流程

  • 獵捕查詢：從 Sentinel 範本開始；隨著環境特定的白名單演進。將有潛力的線索儲存為自訂查詢以便重複使用。
  • 書籤：在獵捕過程中擷取證據與樞紐分析點；稍後附加到事件上以保留分析師的上下文。
  • 即時串流：持續執行 KQL 篩選器，以便在事件一發生時就發現；在活躍事件期間，這是確認圍堵措施是否有效的理想方式。
  • 監看清單：上傳以 CSV 為基礎的允許/拒絕/優先順序集合 (VIP 使用者、經核准的 IP、資產層級)。使用 _GetWatchlist 函數來參考，以進行擴充與抑制。

• 自動化規則與 playbook

  • 自動化規則在事件/警示建立時進行分類：設定嚴重性、指派擁有者、新增標籤、以分類結果關閉，或根據條件 (規則名稱、策略、實體) 觸發 playbook。
  • Playbook (Logic Apps) 實作 SOAR：使用 VirusTotal/MDTI 進行擴充、在 Teams 中通知、開立工單 (ServiceNow/Jira)、隔離端點 (MDE)，或停用帳戶 (Entra)。使用受控識別與最低權限 RBAC (在工作區上使用 Sentinel Responder 角色；對目標系統使用有限範圍的角色)。理由：將動作程式碼化、可重複執行，能縮短 MTTR 並減少人為錯誤。

• 威脅情資 (TI)

  • 使用內建的提供者、手動上傳、GitHub 自動化或 TAXII 收集器 (STIX 2.0/2.1) 來擷取 TI 指標。將欄位 (指標類型、模式、信賴度、TLP) 標準化，並設定到期時間以防止過時的比對。
  • 指標比對：啟用基於 TI 的分析規則，將 IP/網域/URL/雜湊與遙測資料 (CommonSecurityLog, DNS, Proxy, SignInLogs) 進行比對。使用信賴度閾值與監看清單的例外項目來減少雜訊。理由：TI 將搜尋範圍縮小到已知的惡意目標，但必須經過篩選整理以避免誤報。

• 活頁簿與報告

  • 使用 Azure Monitor Workbooks 建立營運儀表板。依訂用帳戶、工作區或時間範圍進行參數化；及早彙總資料 (summarize, make-series) 以維持查詢效率。
  • 提供分層檢視：高階主管態勢 (依嚴重性/SLA 分類的事件)、SOC 維運 (開啟 vs. 關閉、佇列老化、分析師負載)、偵測健康度 (連接器狀態、資料延遲)，以及控制措施涵蓋範圍 (MITRE 對應)。理由：針對不同角色設計的檢視有助於決策，而不會讓使用者淹沒在原始事件中。

• SOC 調校與程序

  • 減少誤報：精簡 KQL 述詞、新增基準線 (動態閾值)、利用實體允許清單 (監看清單)，並排除良性來源。用補償性控制措施來驗證每一次的抑制。
  • 嚴重性標準化：將規則嚴重性對應到衝擊與信賴度，而非頻率。高嚴重性應意味著需要喚醒待命人員；中嚴重性需立即分類；低嚴重性則列入待辦的獵捕清單。
  • 升級與交接：定義事件狀態、擁有者與 SLA；自動擴充並路由到正確的佇列；透過 playbook 開立具雙向更新的 ITSM 工單。為每種策略記錄圍堵步驟 (停用使用者、隔離端點、撤銷權杖、封鎖指標)。

實務問題情境

Contoso Ltd. 在將多個資料來源上線到 Microsoft Sentinel 後，面臨警示疲勞與緩慢的回應速度。事件數量龐大、分組不佳且缺乏自動化。CISO 要求在不損失偵測逼真度的前提下，將平均回應時間 (MTTR) 減少 50%。

1. 透過 DCR 篩選與資料表方案來重新架構資料擷取

• 行動：將 DC 上的 Windows 安全性事件移至 AMA+DCR 並使用 “Common” 預設集；將詳細的診斷資料表切換為 Basic Logs；啟用 90 天的熱資料保留與 1 年的封存。
• 理由：在保留可操作的安全性資料的同時，減少雜訊與熱路徑成本，從而釋放分析週期與預算，用於更高逼真度的偵測。

2. 啟用 Microsoft Defender 連接器與 Fusion

• 行動：連接 MDE、MDI、MDO、MDC 與 Cloud Apps；確保 Microsoft 安全性分析與 Fusion 功能已開啟。
• 理由：高信賴度的警示與機器學習關聯功能，會將重複的警示合併為單一、豐富的事件，從而減輕分類的負擔。

3. 標準化實體對應與警示分組

• 行動：更新排程規則以對應 Account、Host、IP 與 URL；設定依據 Account 以及 4 小時的時間視窗來為相關警示分組。
• 理由：正確的對應能為調查圖表與 UEBA 提供動力；分組則能在保留攻擊鏈上下文的同時，降低事件數量。

4. 實作 triage 自動化規則與目標式 playbook

• 行動：建立自動化規則，以根據策略自動加上標籤、依信賴度設定嚴重性、指派到佇列，並觸發 playbook：擴充指標 (MDTI)、開立 ServiceNow 工單、隔離裝置 (MDE)，以及在取得核准後暫停高風險使用者 (Entra)。
• 理由：確定性的分類加上 SOAR 動作能縮短 MTTR 並標準化回應；核准機制則為高衝擊步驟強制執行了防護措施。

5. 導入監看清單與經過篩選整理的 TI 比對

• 行動：建立 VIP 使用者與經核准服務的監看清單；新增一個經過篩選整理、信賴度 >= 70 且 7 天到期的 TAXII feed；啟用針對 proxy/DNS 的 TI 比對規則。
• 理由：優先處理高價值目標，並使用新鮮、可信的 TI 來集中調查，減少誤報。

6. 發布基於角色的活頁簿與 SLA

• 行動：建立高階主管、SOC 維運與偵測健康度活頁簿；設定事件 SLA (高：4 小時，中：24 小時，低：3 天) 並報告違規情況。
• 理由：可見度與問責制能推動維運紀律；目標導向的儀表板可防止上下文切換與白費力氣。

7. 建立持續調校的節奏

• 行動：每週審查被歸類為誤報而關閉的事件；根據記錄的理由調整規則、抑制與排除項目；監控擷取異常與查詢效能。
• 理由：若沒有回饋迴路，安全維運會逐漸偏離正軌；隨著環境演變，持續的精進能維持訊號品質。

透過執行這些步驟，Contoso 將偵測與業務風險對齊，從源頭減少雜訊，並自動化重複性任務——從而實現更快、更一致的事件回應，且不犧牲涵蓋範圍。

← 安全態勢管理與治理 · 所有領域 · 應用程式安全與 DevSecOps →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →