הגדרת AWS GuardDuty לזיהוי איומים ותגובה אוטומטית
דמיינו שאתם מקבלים התראת GuardDuty על אירוע קריטי ב-3 לפנות בוקר. ללא הגדרה נכונה, סביר להניח שמדובר באזעקת שווא. אבל אם זו מתקפה אמיתית, כל שעת השבתה עולה כסף רב, ופריצת מידע עלולה להוביל להפסדים של מיליוני דולרים. ללא הגדרה נכונה, אתם מסתכנים בהחמצת מתקפה קריטית או בטביעה בים של אזעקות שווא. אנו מגדירים את GuardDuty כך שתראו רק איומים אמיתיים, עם תגובה אוטומטית שחוסמת מתקפות תוך דקות. ביצענו מאות פרויקטים—מסטארטאפים ועד ארגונים עם עשרות חשבונות. לאחר ההגדרה שלנו, אזעקות השווא יורדות ב-90%. אנו מתעדים כל שלב ומכשירים את הצוות שלכם. עם 5 שנות ניסיון בשוק, המומחיות שלנו באבטחת AWS מדברת בעד עצמה.
מדוע GuardDuty דורש הגדרה נכונה
ניתן להפעיל את GuardDuty בשלוש לחיצות בקונסולה, אך ללא הגדרה נכונה, הוא חסר תועלת. עליכם:
- לציין אילו נתונים לנתח (CloudTrail, VPC Flow Logs, DNS, יומני S3);
- להגדיר חשבונות מרובים דרך Organizations כדי להימנע מהפעלה ידנית לכל חשבון;
- להגדיר ערוצי התראה (Slack, PagerDuty, Telegram) וליצור מסנני חומרה;
- לכתוב כללי דיכוי למקורות מהימנים—שרתי בדיקות חדירה, סורקים, סקריפטים לגיטימיים.
ללא שלבים אלה, אתם מסתכנים בהחמצת מתקפה או בהצפה מאזעקות שווא. אירוע אחד שהוחמץ עלול להוביל לעלויות שחזור החורגות בהרבה מגבולות סבירים. בניסיון שלנו, סטארטאפ עם 5 חשבונות קיבל מעל 3,000 התראות בחודש, מתוכן רק 15 היו אמיתיות—השאר היה רעש מסורקי אבטחה. לאחר הגדרת כללי דיכוי וסינון חומרה, אזעקות השווא ירדו ל-5%.
כיצד GuardDuty מנתח נתונים: מקורות וחומרה
GuardDuty מנתח שלוש שכבות נתונים ומייצר ממצאים בשלוש קטגוריות.
אישורים שנפרצו
-
UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B— התחברות מוצלחת מ-IP חריג או מיקום גיאוגרפי לא רגיל. -
Recon:IAMUser/MaliciousIPCaller— ניסיונות למפות משאבי IAM מ-IP של TOR או מרשתות תקיפה ידועות.
מופעים שנפרצו
-
Backdoor:EC2/C&CActivity.B— EC2 מתקשר עם תשתית C2. -
CryptoCurrency:EC2/BitcoinTool.B!DNS— שאילתות DNS לבריכות כרייה (קלאסי לאחר פריצת פגיעות אתר).
חריגות נתונים
-
Exfiltration:S3/AnomalousBehavior— הורדת נתונים גדולה פתאומית מ-S3 בפרק זמן קצר.
| חומרה | טווח | דוגמה | פעולה |
|---|---|---|---|
| נמוכה | 1–3.9 | PortProbe | התעלם או אחסן בארכיון |
| בינונית | 4–6.9 | MaliciousIPCaller | ניתוח ידני |
| גבוהה | 7–8.9 | C&CActivity | חסימה אוטומטית (WAF/SG) |
| קריטית | 9–10 | ConsoleLoginSuccess | התראה מיידית דרך PagerDuty |
כיצד להפוך תגובה לאירועים לאוטומטית עם EventBridge
GuardDuty שולח ממצאים ל-EventBridge. משם, ל-SNS, Lambda, SQS. הגדרת התראה מינימלית:
resource "aws_cloudwatch_event_rule" "guardduty_high" {
name = "guardduty-high-severity"
description = "GuardDuty findings severity >= 7"
event_pattern = jsonencode({
source = ["aws.guardduty"]
detail-type = ["GuardDuty Finding"]
detail = {
severity = [{
numeric = [">=", 7]
}]
}
})
}
resource "aws_cloudwatch_event_target" "sns" {
rule = aws_cloudwatch_event_rule.guardduty_high.name
target_id = "SendToSNS"
arn = aws_sns_topic.security_alerts.arn
}חומרה ב-GuardDuty: נמוכה (1–3.9), בינונית (4–6.9), גבוהה (7–8.9), קריטית (9–10). לחסימה אוטומטית של IP ב-WAF או ב-Security Group, הגיבו לגבוהה ומעלה. בינונית נכנסת לתור לניתוח ידני.
ההשפעה הכלכלית של ההתקנה
GuardDuty הוא אחד מכלי האבטחה המשתלמים ביותר. העלות הממוצעת לחברה עם 10 חשבונות נמוכה, ומניעת אירוע אחד יכולה לחסוך מאות אלפי דולרים. לפי AWS, ההתקנה בדרך כלל מחזירה את עצמה תוך מספר חודשים. בניסיון שלנו, לקוחות מדווחים על הפחתה משמעותית בעלויות חקירת אירועים.
תהליך התקנה ב-5 שלבים
- ביקורת על היומנים הנוכחיים והגדרות האבטחה.
- הפעלת גלאי עם מקורות הנתונים הנדרשים (S3, Kubernetes, Malware Protection).
- חיבור חשבונות מרובים דרך AWS Organizations עם מנהל מורשה.
- יצירת כללי EventBridge להתראות (Slack, PagerDuty, Telegram).
- כתיבת כללי דיכוי ל-IP מהימנים וסורקים סטנדרטיים.
כל שלב כולל קוד Terraform ותיעוד. זמן התקנה ממוצע: יומיים. התוצאה היא מערכת עובדת עם תגובה אוטומטית ותוכנית פעולה ברורה לכל סוג אירוע.
מה כלול בעבודה
| תיעוד | בקרת גישה | הכשרה | תמיכה |
|---|---|---|---|
| קוד Terraform לתשתית, מדריך תגובה לאירועים | תפקידי IAM, מדיניות Service Control לחשבונות חברים | סמינר מקוון לצוות שלכם על טיפול בממצאים | שבועיים של תמיכה לאחר השחרור |
כיצד לבדוק את פעולת GuardDuty?
לאימות, השתמשו במחולל הממצאים לדוגמה: resource "aws_cloudwatch_event_rule" "guardduty_high" { name = "guardduty-high-severity" description = "GuardDuty findings severity >= 7" event_pattern = jsonencode({ source = ["aws.guardduty"] detail-type = ["GuardDuty Finding"] detail = { severity = [{ numeric = [">=", 7] }] } }) } resource "aws_cloudwatch_event_target" "sns" { rule = aws_cloudwatch_event_rule.guardduty_high.name target_id = "SendToSNS" arn = aws_sns_topic.security_alerts.arn } . זה יוצר ממצאים מדומים מכל הסוגים והחומרות. ודאו שההתראות מגיעות לערוצים הנכונים וכללי הדיכוי מאחסנים כראוי אירועים ידועים.
הגדרת Terraform לחשבונות מרובים
ב-AWS Organizations, עדיף להגדיר את GuardDuty באופן מרכזי. חשבון אחד (Security או Audit) הופך למנהל מורשה ואוסף ממצאים מכל חשבונות החברים.
# В management account
resource "aws_guardduty_organization_admin_account" "main" {
admin_account_id = var.security_account_id
}
# В security account
resource "aws_guardduty_detector" "main" {
enable = true
datasources {
s3_logs {
enable = true
}
kubernetes {
audit_logs {
enable = true
}
}
malware_protection {
scan_ec2_instance_with_findings {
ebs_volumes {
enable = true
}
}
}
}
}
resource "aws_guardduty_organization_configuration" "main" {
auto_enable_organization_members = "ALL"
detector_id = aws_guardduty_detector.main.id
}aws guardduty create-sample-findings --detector-id ... מפעיל אוטומטית את GuardDuty עבור חשבונות חדשים. אחרת, יש להפעיל כל חשבון ידנית.
כללי דיכוי: כיצד לחסל רעש
לאחר הפעלת GuardDuty, צפו לרעש בשבועות הראשונים. דוגמה טיפוסית: בדיקות חדירה פנימיות מייצרות # В management account resource "aws_guardduty_organization_admin_account" "main" { admin_account_id = var.security_account_id } # В security account resource "aws_guardduty_detector" "main" { enable = true datasources { s3_logs { enable = true } kubernetes { audit_logs { enable = true } } malware_protection { scan_ec2_instance_with_findings { ebs_volumes { enable = true } } } } } resource "aws_guardduty_organization_configuration" "main" { auto_enable_organization_members = "ALL" detector_id = aws_guardduty_detector.main.id } . עבור מקורות ידועים, צרו כלל דיכוי:
resource "aws_guardduty_filter" "pentest_suppression" {
detector_id = aws_guardduty_detector.main.id
name = "suppress-internal-pentest"
action = "ARCHIVE"
rank = 1
finding_criteria {
criterion {
field = "service.action.networkConnectionAction.remoteIpDetails.ipAddressV4"
equals = ["10.0.1.50"] # IP пентест-сервера
}
}
}דיכוי אינו מוחק ממצאים—הם נשמרים בארכיון. ההיסטוריה המלאה נשמרת לצורך ביקורת.
כדי להגדיר כללי דיכוי אופטימליים לתשתית שלכם, צרו קשר—ננתח את היומנים שלכם ונציע כללים מוכנים. קבלו ייעוץ ליישום GuardDuty בפרויקט שלכם.







