אבטחה רב-עננית: הגדרת Security Hub, SCC ו-Defender

הערה: כאשר התשתית מפוזרת על פני AWS, GCP ו-Azure, יומני אבטחה מקוטעים הופכים שלושה עננים לשלוש קופסאות שחורות. בפרויקט אחד עם 200 חשבונות AWS, 50 פרויקטים של GCP ו-100 מינויים של Azure, כל צוות סקר באופן ידני אלפי ממצאים בשבוע, וזמן התגובה הממוצע (MTTR) היה 8 שעות. הגדרת שירותי אבטחה מרכזיים—AWS Security Hub, GCP Security Command Center (SCC) ו-Azure Defender for Cloud—הפחיתה את ה-MTTR ל-30 דקות וקיצצה את עלויות האבטחה ב-25%. תיעוד AWS מאשר ש-Security Hub כולל אוטומטית שלושה תקני תאימות: CIS, PCI-DSS ו-AWS Foundational Benchmarks. אך מחוץ לקופסה, שירותים אלה אינם פועלים ביעילות—נדרשת הגדרה ידנית של אינטגרציות, מסגרות תאימות ותגובות אוטומטיות. להלן תצורות ספציפיות וצינור נתונים מ-50+ פרויקטים שכבר יישמנו.

אילו בעיות פותרים Security Hub, SCC ו-Defender?

כל שירות מטפל בשלוש משימות מרכזיות:

• איסוף ממצאים מכלים מובנים: GuardDuty, Inspector, Config ב-AWS; Security Health Analytics, Web Scanner ב-GCP; Defender for Servers, Containers, SQL ב-Azure.
• ניטור תאימות מול CIS, PCI-DSS, SOC 2 ושיטות עבודה מומלצות של הספקים.
• תגובה אוטומטית לאירועים קריטיים—מהודעות ועד תיקון אוטומטי.

טעות אופיינית בהגדרה ראשונית היא אי הפעלת כל המקורות. Security Hub לא יראה ממצאי GuardDuty עד שהאינטגרציה תופעל במפורש. ב-GCP, ה-Standard tier אינו מספק בקרת מכולות בזמן אמת. Azure Defender ללא סט מלא של תוכניות משאיר שרתי bare-metal לא מוגנים.

כיצד אנו מגדירים כל שירות: דוגמה מפורטת על AWS

עבור AWS, אנו משתמשים ב-CLI עם דגלי --enable-default-standards והפעלה מפורשת של כל המקורות:

# Включить Security Hub
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

# Включить GuardDuty как источник находок
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

# Включить AWS Inspector v2
aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA

לאחר ההפעלה, Security Hub ממפה ממצאים ל-ASFF (Amazon Security Finding Format). לתגובה אוטומטית לממצאים קריטיים וגבוהים, אנו נרשמים לאירועים דרך EventBridge:

{ "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {"Label": ["CRITICAL", "HIGH"]},
      "Workflow": {"Status": ["NEW"]}
    }
  }
}

פונקציית Lambda המופעלת על ידי כלל זה מעבדת את הממצא—לדוגמה, סוגרת דלי S3 ציבורי. עבור GCP, אנו משתמשים ב-gcloud לשאילתת ממצאים עם מסנן חומרה, ולשליחה אוטומטית של ממצאים קריטיים ל-PubSub, אנו משתמשים בתצורת Terraform:

resource "google_scc_notification_config" "critical_findings" {
  config_id = "critical-findings-pubsub"
  organization = var.org_id
  description = "Critical and High findings to PubSub"
  pubsub_topic = google_pubsub_topic.security_findings.id
  streaming_config {
    filter = "severity = \"CRITICAL\" OR severity = \"HIGH\""
  }
}

ב-Azure—הפעלת תוכניות הגנה והגדרת ייצוא רציף:

az security pricing create --name Containers --tier Standard
az security pricing create --name VirtualMachines --tier Standard --subplan P2
az security pricing create --name AppServices --tier Standard
# Continuous export настраивается через UI или ARM

השוואת תכונות בין השירותים

למה להגדיר את כל שלושת השירותים?

חלון אבטחה אחד לשלושה עננים מפחית את ה-MTTR בממוצע ב-40% בהשוואה למעבר ידני בין קונסולות. Security Hub מעבד ממצאים פי 3 מהר יותר מאיסוף יומנים ידני מ-10 אזורים. חיסכון בעלויות אירועים: לדוגמה, החלפת תגובה ידנית באוטומטית חסכה ללקוח כ-$1.8k–2.6k בחודש. יישמנו צינור נתונים מרכזי ל-50+ פרויקטים: AWS Security Hub → EventBridge → Kinesis Firehose, GCP SCC → PubSub → Dataflow, Azure Defender → Event Hub. כל הזרמים מתכנסים ל-Elastic, Splunk או Microsoft Sentinel, ומספקים הזנת אירועים אחידה תוך שמירה על ניהול כרטוס ו-runbooks.

תהליך ההגדרה ומה כלול

1. ביקורת תצורה נוכחית — זיהוי מקורות חסרים והגדרות לא מאובטחות.
2. הפעלת שירותים ומסגרות תאימות — CIS, PCI-DSS, בתוספת מדיניות מותאמת אישית.
3. הגדרת איסוף — בחירת חשבון ראשי (Security Hub) או SIEM חיצוני.
4. הודעות אוטומטיות — ממצאים קריטיים → Slack/PagerDuty, גבוהים → דוא"ל.
5. פעולות תיקון — פונקציות Lambda להפרות נפוצות (פורטים פתוחים, דליים ציבוריים).
6. בדיקת E2E — מאירוע מדומה ועד התראה ותיקון אוטומטי.

העבודה כוללת תיעוד מלא של תגובה לאירועים ו-runbooks, הדרכת צוות על קונסולות ולוחות מחוונים, ותמיכה לאחר הפרויקט למשך חודש אחד.

טעויות נפוצות שאנו מתקנים לעיתים קרובות

• אי הפעלת כל מקורות הממצאים — GuardDuty, Inspector, Macie ב-AWS.
• שימוש ב-Standard tier של SCC עבור אשכולות Kubernetes — ללא Premium, לא תראו התקפות מכולות.
• חוסר ייצוא רציף מ-Azure Defender — ממצאים אובדים אם Continuous Export לא מוגדר.
• תיקונים שנשכחו — אירועים קריטיים נשארים ללא טיפול אם אין כללי EventBridge.

אנו מבטיחים סקירת אבטחה מרכזית על פני שלושה עננים עם MTTR מינימלי. לייעוץ בנוגע לפרויקט שלכם, צרו קשר. בקשו ביקורת ראשונית לקבלת תמונת מצב של נקודות תורפה נוכחיות והמלצות תצורה.