נבדק לאחרונה: מאי 2026
בנו את שירותי AWS של בחינת SC-200 עם Terraform פשוט — בלוק אחד בכל פעם, כאשר כל אחד מהם מקושר בחזרה לתחום במבחן. אותו הקוד עובד גם ב-OpenTofu.
בסיום מעבדה זו, תקימו, באמצעות Terraform פשוט, את תשתית הייחוס של SC-200 SOC – סביבת עבודה של Log Analytics כמישור הנתונים, Microsoft Sentinel המחובר לסביבת עבודה זו, כלל אנליטי מתוזמן שמפעיל אירוע על תבנית KQL לדוגמה, וכלל אוטומציה שרץ בכל פעם שנוצר אירוע. זוהי התשתית שעליה פועל כל זרימת עבודה של ציד ותגובה ב-SC-200.
הכניסו את קטעי הקוד לקובץ main.tf אחד, הריצו terraform init, ולאחר מכן terraform apply שלב אחר שלב.
>= 1.5 או OpenTofu >= 1.6.az login).destroy עובד כהלכה באמצעות Terraform.תמחור Sentinel הוא נושא העלות העיקרי:
כ-$0 לחודש בנפח המעבדה. Sentinel הופך יקר בקנה מידה — צירוף שווה ערך ל-CloudTrail מרובה שרתים (מחברי Defender XDR, מחברי M365) מגיע בקלות ל-10,000$ לחודש עבור ארגון אמיתי.
פתיחה סטנדרטית של Azure.
terraform {
required_version = ">= 1.5"
required_providers {
azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
}
}
provider "azurerm" {
features {}
}
locals {
tags = {
Project = "certlabpro-sc-200"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-sc-200-rg"
location = "eastus"
tags = local.tags
}Microsoft Sentinel הוא שכבה מעל סביבת עבודה של Log Analytics — אין לו מישור נתונים משלו. תחום ניהול סביבת Microsoft Sentinel ב-SC-200 מדגיש תלות זו: כל תכונה של Sentinel קוראת/כותבת מסביבת העבודה, כל מחבר נתונים מכניס אליה נתונים, כל כלל אנליטי מריץ KQL כנגדה.
אנו מספקים את סביבת העבודה ב-SKU PerGB2018 + משאב azurerm_sentinel_log_analytics_workspace_onboarding כדי לצרף את Sentinel. לאחר מכן, הייתם מחברים מקורות נתונים (Azure Activity, כניסות של Microsoft Entra ID, מחברי Defender XDR) דרך הפורטל – הם עתירי שטח פנים וקלים יותר לחיבור באמצעות הממשק הגרפי מאשר דרך Terraform.
resource "azurerm_log_analytics_workspace" "main" {
name = "log-sc200"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
sku = "PerGB2018"
retention_in_days = 30
tags = local.tags
}
resource "azurerm_sentinel_log_analytics_workspace_onboarding" "main" {
workspace_id = azurerm_log_analytics_workspace.main.id
}כללים אנליטיים הם הדרך שבה Sentinel הופך אירועי יומן גולמיים לאירועים. SC-200 בוחן זיהוי סוגי כללים: מתוזמן (מבוסס KQL, הנפוץ ביותר), אירוע Microsoft (מעביר התראות Defender XDR), חריגה (מבוסס למידת מכונה), מודיעין איומים (התאמת מודיעין איומים).
אנו יוצרים כלל מתוזמן עם שאילתת KQL מוגדרת (כל 5 דקות, מסתכל אחורה 5 דקות – צורת ה-זמן אמת כמעט של SC-200). השאילתה כאן היא מציין מיקום (SecurityEvent | take 1); בייצור, ה-KQL הוא הלוגיקה האמיתית של הכלל – בדיקת כניסות בלתי אפשריות, תבניות של פיזור סיסמאות, הסלמות הרשאות חריגות וכו'.
שדה ה-tactics ממפה את הכלל למסגרת MITRE ATT&CK – נדרש לשילוב Defender XDR ולזרימות עבודה של ציד שמתמקדות בטקטיקות.
resource "azurerm_sentinel_alert_rule_scheduled" "stub" {
name = "certlabpro-sc-200-stub-rule"
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
display_name = "Stub rule — lab demonstration"
description = "Sample scheduled analytic rule for the SC-200 lab. Replace KQL with a real hunting pattern."
severity = "Medium"
enabled = true
query = "SecurityEvent | take 1"
query_frequency = "PT5M" # run every 5 minutes
query_period = "PT5M" # look back 5 minutes
trigger_operator = "GreaterThan"
trigger_threshold = 0
tactics = ["InitialAccess"]
techniques = ["T1078"] # Valid Accounts (MITRE ATT&CK)
incident {
create_incident_enabled = true
grouping {
enabled = true
}
}
depends_on = [azurerm_sentinel_log_analytics_workspace_onboarding.main]
}כללי אוטומציה הם הפרימיטיב של SC-200 הגדרת סביבת Microsoft Sentinel שלך לניהול אירועים — הם מופעלים כאשר אירוע נוצר, מתעדכן או נסגר, ומריצים סט פעולות: הקצאת האירוע למשתמש, שינוי חומרתו, הוספת תגים, או הפעלת Playbook של Logic App.
אנו יוצרים כלל שרץ בכל פעם שנוצר אירוע כלשהו. פעולת הדוגמה רק משנה את החומרה לגבוהה ומתייגת את האירוע — בייצור הייתם מפעילים כאן Playbook של Logic App שיפרסם ב-Teams, ייצור כרטיס Jira, יעשיר עם מודיעין איומים, או יפעיל Runbook לתיקון. SC-200 בוחן צורת אוטומציה מופעלת זו כתבנית ה-SOC הסטנדרטית L1.
resource "azurerm_sentinel_automation_rule" "tag_and_escalate" {
name = "0e84e57b-8b8a-4c8b-a0a8-1d3f3e6f9a01" # GUID required
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
display_name = "Tag-and-escalate every new incident"
order = 1
enabled = true
triggers_on = "Incidents"
triggers_when = "Created"
action_incident {
order = 1
severity = "High"
}
action_incident {
order = 2
labels = ["lab-auto-tagged"]
}
depends_on = [azurerm_sentinel_log_analytics_workspace_onboarding.main]
}terraform destroy מפרק הכל. צירוף Sentinel מתנתק מסביבת העבודה; סביבת העבודה נשארת עד להשמדתה בנפרד (Terraform מטפל בשניהם כהלכה). ביצועי כללים אנליטיים נפסקות באופן מיידי. Playbooks של Logic App (שלא סופקו במעבדה זו) יצטרכו להיהרס בנפרד אם הוספתם אותם.
SC-200 מכסה משטחי SecOps נוספים שמעבדה זו אינה יכולה להכיל — Microsoft Defender for Endpoint (ה-EDR של נקודות הקצה), Defender for Identity (איומי AD מקומיים), Defender for Office 365 (הגנת זרימת דואר), Defender for Cloud Apps (CASB), פורטל Defender XDR המאוחד המלא, ציד KQL לעומק, מחברי נתונים של Microsoft Sentinel (Azure Activity, M365, AWS CloudTrail, GCP Audit, מחברי צד שלישי), חוברות עבודה של Sentinel ללוחות מחוונים, מחווני מודיעין איומים, רשימות מעקב, ניתוח התנהגות משתמשים וישויות (UEBA), מחברות לציד מתקדם, ו-Playbooks של Logic App לתזמור תגובות.
אנו נצמדים ל-סביבת עבודה + Sentinel + כלל מתוזמן + כלל אוטומציה מכיוון שהם התשתית שעליה נבנה כל דפוס של SC-200. מחברי נתונים מכניסים נתונים לסביבת העבודה; כללים אנליטיים שואלים את הנתונים; כללי אוטומציה מגיבים לאירועים; Playbooks (Logic Apps) מרחיבים כללי אוטומציה. קבלו את הבסיס נכון; שכבו עליו לפי מקור נתונים.
עבור המשטחים הנ״ל, עיינו בקטעי עיון, מדריך ו-Editorial בדף אישור זה.