סקירה כללית על Adaptive Protection ב-Google Cloud Armor

התכונה 'הגנה דינמית' ב-Google Cloud Armor עוזרת לכם להגן על Google Cloud האפליקציות, האתרים והשירותים שלכם מפני מתקפות מניעת שירות מבוזרות (DDoS) מסוג L7, כמו הצפות HTTP ופעילות זדונית אחרת בשכבה 7 (ברמת האפליקציה) בתדירות גבוהה. התכונה 'הגנה דינמית' יוצרת מודלים של למידת מכונה שמבצעים את הפעולות הבאות:

1. זיהוי פעילות חריגה ושליחת התראות לגביה
2. יצירת חתימה שמתארת את המתקפה הפוטנציאלית
3. יצירת כלל WAF מותאם אישית ב-Cloud Armor לחסימת החתימה

אתם מפעילים או משביתים את ההגנה האדפטיבית לפי מדיניות אבטחה.

התראות על תנועה חריגה (מתקפות פוטנציאליות), כולל החתימות של המתקפות, מופיעות בלוח הבקרה של אירועים ב-Adaptive Protection עם יומני אירועים שנשלחים אל Cloud Logging, שבו אפשר לנתח אותם ישירות או להעביר אותם ליומן במורד הזרם או לתהליך עבודה של מעקב אחרי אירועי אבטחה. התראות על מתקפות פוטנציאליות נוצרות גם כממצאים בSecurity Command Center.

זמינות של הגנה דינמית

התראות מלאות של Adaptive Protection זמינות רק אם נרשמתם ל-Google Cloud Armor Enterprise. אחרת, תקבלו רק התראה בסיסית. התראה בסיסית מכילה רק מידע מינימלי, כמו ציון רמת הסמך של הזיהוי וגודל המתקפה. התראה בסיסית לא כוללת חתימת תקיפה או כלל מוצע לפריסה על ידי המשתמשים.

אם הפרויקטים שלכם עדיין לא רשומים ב-Cloud Armor Enterprise, כדאי לקרוא את המאמר שימוש ב-Cloud Armor Enterprise כדי לקבל מידע על אופן ההרשמה.

Cloud Logging ו-Cloud Monitoring

כדי להשתמש ביעילות ב-Adaptive Protection, צריך להבין איך הרישום ביומן וההתראות פועלים ב- Google Cloud. לכן מומלץ להכיר את Cloud Logging, את ההתראות ואת מדיניות ההתראות.

• מידע כללי על רישום ביומנים זמין במאמרי העזרה בנושא Cloud Logging.
• מידע על התראות זמין במסמכי העזרה של Cloud Monitoring.
• למידע על רישום ביומנים שספציפי ל-Cloud Armor, ראו שימוש ברישום ביומנים של בקשות.

כדי להבטיח רישום נכון ביומן ודיווח תקין, ל-Cloud Armor צריכה להיות גישה ליומנים הבאים. הם צריכים להיות מאוחסנים ב-Cloud Logging או להיות מנותבים אל קטגוריה של רישום ביומן שאפשר לגשת אליה ב-Cloud Armor.

• networksecurity.googleapis.com/dos_attack
• networksecurity.googleapis.com/network_dos_attack
• networksecurity.googleapis.com/network_dos_attack_mitigations

הגדרה ושיפור של התראות

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

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

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

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

• רמת הסמך מציינת את רמת הביטחון של המודלים של Adaptive Protection בחיזוי שהשינוי שנצפה בדפוס התנועה הוא אנומליה.
• שיעורי הבסיס המושפעים שמשויכים לכלל המוצע מייצגים את אחוז תנועת הבסיס הקיימת שנלכדת על ידי הכלל. מוצגים שני שיעורים. הראשון הוא האחוז ביחס לתנועה בשירות הספציפי לקצה העורפי שנמצא תחת מתקפה. השני הוא האחוז ביחס לכל התנועה שעוברת דרך מדיניות האבטחה, כולל כל יעדי שירות לקצה העורפי שהוגדרו (לא רק זה שנמצא תחת מתקפה).

אפשר לסנן התראות ב-Cloud Logging לפי רמת הביטחון או לפי שיעורי הבסיס שהושפעו, או לפי שניהם. מידע נוסף על כוונון ההתראות זמין במאמר בנושא ניהול מדיניות ההתראות.

ההגנה הדינמית נועדה להגן על שירותי קצה עורפי מפני התקפות DDoS ברמה 7 בהיקף גדול. בתרחישים הבאים, הבקשות לא נספרות בהגנה הדינמית:

• בקשות שמטופלות ישירות מ-Cloud CDN
• בקשות שנדחו על ידי מדיניות אבטחה של Cloud Armor

מודלים מגורענים

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

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

חתימות התקפה שזוהו מכוונות רק לתעבורת ההתקפה שנכנסת ליחידת התעבורה הגרנולרית. עם זאת, הסינון עדיין חל על כל הבקשות שתואמות לכלל שנפרס, כמו שהיה קורה ללא ההגדרות הגרנולריות. לדוגמה, אם רוצים שכלל שנפרס אוטומטית יתאים רק ליחידת תעבורה גרנולרית ספציפית, כדאי להשתמש בתנאי התאמה כמו evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ....

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

• עומס: העומס המקסימלי בשירות לקצה העורפי, בהתאם למאזן עומסים של אפליקציות (ALB) שהוגדר. האפשרות הזו לא זמינה ליחידות תעבורת נתונים מפורטות, ולא זמינה לבק-אנדים בלי שרת (serverless) כמו Cloud Run, פונקציות Cloud Run או בק-אנדים חיצוניים של מקורות.
• שאילתות מוחלטות לשנייה (QPS): כמות התעבורה המרבית, בשאילתות לשנייה, ששירות לקצה העורפי או יחידת התעבורה מקבלים.
• ביחס לערך הבסיס של QPS: מכפלה של נפח התנועה הממוצע לטווח ארוך. לדוגמה, ערך של 2 מייצג נפח תנועה של פי שניים מהנפח הבסיסי.

מידע נוסף על הגדרת מודלים גרנולריים זמין במאמר הגדרת הגנה אדפטיבית ב-Google Cloud Armor.

צריכה ופרשנות של התראות

ברגע שהתכונה 'הגנה דינמית' מזהה מתקפה חשודה, היא יוצרת אירוע בלוח הבקרה של אירועי ההגנה הדינמית ופריט ביומן ב-Cloud Logging. ההתראה נמצאת במטען ה-JSON של פריט היומן. פריט היומן נוצר במשאב Network Security Policy ב-Cloud Logging. הודעת היומן מזהה את שירות ה-Backend שנמצא תחת מתקפה וכוללת ציון מהימנות שמציין עד כמה ההגנה הדינמית מעריכה את השינוי בדפוס התעבורה שזוהה כאנומליה. הודעת היומן כוללת גם חתימת מתקפה שממחישה את המאפיינים של תעבורת המתקפה, יחד עם כללים מוצעים של Cloud Armor שאפשר להחיל כדי לצמצם את המתקפה.

הסבר על חתימות של התקפות

התראה על הגנה דינמית כוללת חתימת תקיפה, שהיא תיאור של מאפייני התעבורה של התקיפה הפוטנציאלית. אתם יכולים להשתמש בחתימה כדי לזהות את המתקפה ולחסום אותה. החתימה מופיעה בשתי צורות: כטבלה שקלה לקריאה וככלל WAF מוכן מראש של Cloud Armor שאפשר לפרוס במדיניות האבטחה הרלוונטית. אם אתם לא מנויים ל-Cloud Armor Enterprise, חתימת התקפה לא נכללת בהתראה הבסיסית.

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

לכל ערך מאפיין שההגנה האדפטיבית סבורה שמצביע על מתקפה פוטנציאלית, ההגנה האדפטיבית מציגה את הפרטים הבאים:

• הסבירות להתקפה
• החלק היחסי של המאפיין בהתקפה, שהוא אחוז התנועה הפוטנציאלית של ההתקפה שהיה לה הערך הזה בזמן זיהוי ההתקפה
• החלק היחסי של המאפיין בנתוני הבסיס, שהוא אחוז התנועה בנתוני הבסיס שהיה לה ערך המאפיין הזה בזמן זיהוי המתקפה

מפרט הרשומות ב-Cloud Logging כולל פרטים על המידע בכל התראה.

הדוגמה הבאה היא של טבלה שקלה לקריאה ומכילה את החתימה של התקפה פוטנציאלית:

שם המאפיין	ערך	סוג התאמה	סבירות ההתקפה	החלק היחסי בהתקפה	השיעור בערך הבסיס
UserAgent	‪"foo"	התאמה מדויקת	0.7	0.85	0.12
UserAgent	"bar"	התאמה מדויקת	0.6	0.7	0.4
כתובת IP של לקוח	'a.b.c.d'	התאמה מדויקת	0.95	0.1	0.01
כתובת IP של לקוח	a.b.c.e	התאמה מדויקת	0.95	0.1	0.01
כתובת IP של לקוח	a.b.c.f	התאמה מדויקת	0.05	0.1	0.1
RegionCode	בריטניה	התאמה מדויקת	0.64	0.3	0.1
RegionCode	IN	התאמה מדויקת	0.25	0.2	0.3
RequestUri	/urlpart	מחרוזת משנה	0.7	0.85	0.12

התראה של Adaptive Protection ואירוע Cloud Logging רלוונטי מכילים את הפרטים הבאים:

• מזהה התראה ייחודי, או alertID, שמשמש להתייחסות להתראה ספציפית כשמדווחים על משוב משתמשים (מידע נוסף בהמשך)
• שירות הקצה העורפי שנמצא תחת מתקפה, או backendService
• ציון המהימנות, או confidence, שהוא מספר בין 0 ל-1 שמציין עד כמה מערכת ההגנה האדפטיבית מעריכה את האירוע שזוהה כמתקפה זדונית

מקבלים גם קבוצה של חתימות וכללים שמאפיינים את המתקפה שזוהתה. באופן ספציפי, המערך מספק רשימה של headerSignatures, כל אחד מהם תואם לכותרת HTTP אחת ומכיל רשימה של significantValues לכותרת הספציפית. כל ערך משמעותי הוא ערך של כותרת שנצפה או מחרוזת משנה שלו.

דוגמה לחתימה:

...
headerSignatures: [
  0: {
   name: "Referer"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_EQUALS"
     proportionInAttack: 0.6
     proportionInBaseline: 0.01
     value: "foo.attacker.com"
    }
   ]
  }
...

ההתראה מציינת שהערך foo.attacker.com בכותרת Referer חשוב לאפיון המתקפה. באופן ספציפי, 60% מהתנועה של המתקפה (proportionInAttack) כוללת את הערך Referer, ורק 1% מהתנועה של קו הבסיס מתוך כל התנועה (proportionInBaseline) כוללת את אותו ערך Referer. בנוסף, מתוך כל התנועה שתואמת לערך Referer, ‏ 95% היא תנועת התקפה (attackLikelihood).

הערכים האלה מצביעים על כך שאם תחסמו את כל הבקשות עם foo.attacker.com בשדה הכותרת Referer, תחסמו בהצלחה 60% מההתקפה וגם 1% מהתנועה הבסיסית.

המאפיין matchType מציין את הקשר בין המאפיין בתנועת התקפה לבין הערך המשמעותי. הערך יכול להיות MATCH_TYPE_CONTAINS או MATCH_TYPE_EQUALS.

החתימה הבאה תואמת לתנועה עם מחרוזת משנה /api? ב-URI של הבקשה:

...
headerSignatures: [
  0: {
   name: "RequestUri"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_CONTAINS"
     proportionInAttack: 0.9
     proportionInBaseline: 0.01
     value: "/api?"
    }
   ]
  }
...

פריסת כללים מוצעים

ההתראות של Adaptive Protection כוללות גם הצעה לכלל Cloud Armor שמוצג בשפת הכללים המותאמים אישית. אפשר להשתמש בכלל הזה כדי ליצור כלל במדיניות האבטחה של Cloud Armor, במטרה לצמצם את ההשפעה של המתקפה. בנוסף לחתימה, ההתראה כוללת את שיעור התנועה הבסיסית המושפעת, כדי לעזור לכם להעריך את ההשפעה של פריסת הכלל. שיעור התנועה הבסיסית המושפעת הוא שיעור משוער של התנועה הבסיסית שתואם לחתימת המתקפה שזוהתה על ידי Adaptive Protection. אם אין לכם מינוי ל-Cloud Armor Enterprise, ההתראות הבסיסיות שנשלחות על ידי Adaptive Protection לא כוללות הצעה לכלל Cloud Armor שאפשר להחיל.

חלק מחתימת ההתראה וגם שיעור הבסיס המושפע מופיעים בהודעת היומן שנשלחת אל Cloud Logging. הדוגמה הבאה היא מטען ה-JSON של התראה לדוגמה, יחד עם תוויות המשאבים שאפשר לסנן לפיהן את היומנים.

...
 jsonPayload: {
   alertId: "11275630857957031521"
   backendService: "test-service"
   confidence: 0.71828485
   headerSignatures: [

    0: {
     name: "RequestUri"
     significantValues: [
      0: {
       attackLikelihood: 0.88
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0.01
       value: "/"
      }
     ]
    }
    1: {
     name: "RegionCode"
     significantValues: [
      0: {
       attackLikelihood: 0.08
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.17
       proportionInBaseline: 0.28
       value: "US"
      }
      1: {
       attackLikelihood: 0.68
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.09
       proportionInBaseline: 0.01
       value: "DE"
      }
      2: {
       attackLikelihood: 0.74
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.05
       proportionInBaseline: 0
       value: "MD"
      }
     ]
    }
     2: {
     name: "UserAgent"
     significantValues: [
      0: {
       attackLikelihood: 0.92
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0
       value: "Unusual browser"
      }
      1: {
       attackLikelihood: 0.87
       proportionInAttack: 0.7
       proportionInBaseline: 0.1
       missing: true
      }
     ]
    }
   ]
   suggestedRule: [
    0: {
     action: "DENY"
     evaluation: {
       impactedAttackProportion: 0.95
       impactedBaselineProportion: 0.001
       impactedBaselinePolicyProportion: 0.001
     }
     expression: "evaluateAdaptiveProtection('11275630857957031521')"
    }
   ]
   ruleStatus: RULE_GENERATED
   attackSize: 5000
 }
 resource: {
    type: "network_security_policy",
    labels: {
      project_id: "your-project",
      policy_name: "your-security-policy-name"
    }
 },
}
}
...

כדי להטמיע כללים מוצעים, מעתיקים את ביטוי ה-CEL מחתימת הכלל ומדביקים אותו בתנאי ההתאמה של כלל חדש שנוצר, או לוחצים על הלחצן החלה בלוח הבקרה של Adaptive Protection בממשק המשתמש של Cloud Armor.

כדי לפרוס את הכלל, יוצרים כלל חדש במדיניות האבטחה של Cloud Armor שמגן על שירותי ה-Backend הממוקדים שזוהו בהתראה. בשלב הבא, במהלך הגדרת הכלל, מעתיקים את ביטוי ה-CEL מההתראה ומדביקים אותו בשדה תנאי התאמה של הכלל, ומגדירים את פעולת הכלל ל-deny. בדוגמה שלמעלה, מעתיקים את הביטוי evaluateAdaptiveProtection('11275630857957031521') מהקטע suggestedRule של ההתראה.

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

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

מומלץ להגדיר את העדיפות של הכלל החדש כגבוהה יותר מכל כלל אחר שהפעולה שלו מוגדרת כ'אישור'. הסיבה לכך היא שכדי שהכלל יפעל בצורה מיטבית ויצמצם את ההשפעה של המתקפה, צריך לפרוס אותו במיקום עם העדיפות הלוגית הכי גבוהה, כדי להבטיח שכל התנועה שתואמת לכלל תיחסם. כללים במדיניות אבטחה של Cloud Armor מוערכים לפי סדר העדיפות, וההערכה מסתיימת אחרי שהכלל הראשון שתואם מופעל והפעולה המשויכת לכלל מתבצעת. אם אתם צריכים להעניק חריגה לכלל הזה עבור תנועה מסוימת או לקוחות ספציפיים, אפשר ליצור כלל מסוג 'אישור' עם עדיפות גבוהה יותר, כלומר עם ערך מספרי נמוך יותר. מידע נוסף על עדיפות של כללים זמין במאמר סדר ההערכה של כללים.

פריסה אוטומטית של כללים מוצעים

אפשר גם להגדיר את ההגנה האדפטיבית כך שתפרוס באופן אוטומטי כללים מוצעים. כדי להפעיל פריסה אוטומטית של כללים, יוצרים כלל placeholder עם עדיפות ופעולה לפי בחירתכם באמצעות הביטוי evaluateAdaptiveProtectionAutoDeploy() בתנאי ההתאמה. הכלל הזה מחזיר את הערך true לבקשות שמזוהות על ידי Adaptive Protection כבקשות שמגיעות מתנועת תקיפה, ו-Cloud Armor מחיל את הפעולה על הבקשה התוקפת. כל סוגי הפעולות של Cloud Armor נתמכים, כמו allow,‏ deny,‏ throttle ו-redirect. בנוסף, אפשר להשתמש במצב תצוגה מקדימה כדי לרשום ביומן שהכלל הופעל, בלי לבצע את הפעולה שהוגדרה.

אם אתם משתמשים בשרת proxy במעלה הזרם, כמו CDN של צד שלישי, לפני מאזן העומסים של האפליקציה החיצונית, מומלץ להגדיר את השדה userIpRequestHeaders כדי להוסיף לרשימת ההיתרים את כתובת ה-IP (או טווחי כתובות ה-IP) של הספק. כך, Adaptive Protection לא יזהה בטעות את כתובת ה-IP של הלקוח של ה-proxy ככתובת שמשתתפת בהתקפה. במקום זאת, המערכת תבדוק את השדה שהוגדר על ידי המשתמש כדי למצוא את כתובת ה-IP של הלקוח של התעבורה לפני שהיא הגיעה ל-proxy.

מידע נוסף על הגדרת פריסה אוטומטית של כללים זמין במאמר בנושא פריסה אוטומטית של כללים מוצעים של Adaptive Protection.

סטטוס הכלל

אם לא מוצג כלל כשמנסים לפרוס כלל מוצע, אפשר להשתמש בשדה ruleStatus כדי לברר את הסיבה.

הערך בשדה attackSize הוא מספר השאילתות לשנייה (QPS).

 ]
ruleStatus: RULE_GENERATED
attackSize: 5000
}

בטבלה הבאה מתוארים הערכים האפשריים של השדה והמשמעות שלהם.

סטטוס הכלל	תיאור
RULE_GENERATED	נוצר כלל שניתן לשימוש כרגיל.
BASELINE_TOO_RECENT	לא חלף מספיק זמן כדי לצבור תנועת גולשים מהימנה כבסיס להשוואה. נדרש עד שעה אחת כדי ליצור כללים.
NO_SIGNIFICANT_VALUE_DETECTED	לא נמצאו כותרות עם ערכים משמעותיים שמשויכים לתנועת גולשים שמגיעה מהתקפות, ולכן לא ניתן ליצור כלל.
NO_USABLE_RULE_FOUND	לא ניתן ליצור כלל שניתן להשתמש בו.
שגיאה	אירעה שגיאה לא מוגדרת במהלך יצירת הכלל.

מעקב, משוב ודיווח על שגיאות באירועים

כדי לצפות במרכז הבקרה של ההגנה הדינמית או לבצע בו פעולות, נדרשות ההרשאות הבאות.

• compute.securityPolicies.list
• compute.backendServices.list
• logging.logEntries.list

אחרי שמפעילים את ההגנה הדינמית בכללי מדיניות האבטחה של Cloud Armor, אפשר לראות את הדף הבא בחלונית Network Security > Cloud Armor. בתרשים מוצג נפח התעבורה לאורך זמן עבור מדיניות האבטחה ושירות לקצה העורפי שנבחרו, ומשך הזמן שנבחר. כל המקרים של התקפות פוטנציאליות שההגנה הדינמית התריעה עליהם מסומנים בהערה בתרשים ומפורטים מתחת לתרשים. כשלוחצים על אירוע ספציפי של מתקפה, מוצג חלון צדדי עם חתימת המתקפה והכלל המוצע בפורמט טבלאי. זה אותו מידע שמופיע ברשומות ביומן של Cloud Logging שמתואר במאמר מפרט הרשומות ב-Cloud Logging. לוחצים על הלחצן החלה כדי להוסיף את הכלל המוצע לאותה מדיניות אבטחה.

מרכז הבקרה של Adaptive Protection (לחצו כדי להגדיל)

מרכז הבקרה של Adaptive Protection (לחצו כדי להגדיל)

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

מעקב, התראות ורישום ביומן

נתוני הטלמטריה של Adaptive Protection נשלחים ל-Cloud Logging ול-Security Command Center. הודעת היומן של Adaptive Protection שנשלחת אל Cloud Logging מתוארת בקטעים הקודמים של המסמך הזה. רשומה ביומן נוצרת בכל פעם שההגנה האדפטיבית מזהה מתקפה פוטנציאלית, וכל רשומה מכילה ציון מהימנות שמתאר את רמת הביטחון של המודלים בכך שהתעבורה שנצפתה היא אנומלית. כדי לכוונן את ההתראות, אפשר להגדיר מדיניות התראות ב-Cloud Logging כך שהתראה תופעל רק כשציון רמת הסמך של הודעת יומן של Adaptive Protection גבוה מסף שצוין על ידי המשתמש. מומלץ להתחיל עם סף נמוך, עם רמת מהימנות > 0.5, כדי לא לפספס אזהרות על התקפות פוטנציאליות. אפשר להגדיל את סף מהימנות ההתראה במדיניות ההתראה לאורך זמן אם שיעור הבסיס של ההשפעה של ההתראות לא מקובל.

מרכז הבקרה של Security Command Center מכיל גם ממצאים מ-Adaptive Protection. הם נמצאים בכרטיס Cloud Armor בקטגוריה Application DDoS Attacks (מתקפות DDoS על אפליקציות). כל ממצא כולל את פרטי השירות, רמת הביטחון לגבי ההתקפה, החתימה שמשויכת להתקפה וקישור להתראה הספציפית בלוח הבקרה של Adaptive Protection. צילום המסך הבא הוא דוגמה לממצא של ניסיון מתקפת DDoS על אפליקציה:

ממצא של מתקפת DDoS ברמת האפליקציה (לחצו כדי להגדיל).

מפרט של רשומה ב-Cloud Logging

ההתראה של Adaptive Protection שנשלחת אל Cloud Logging מורכבת מרשומה ביומן שמכילה את הרכיבים הבאים:

• רמת הביטחון של ההתראה: רמת הביטחון של Adaptive Protection לגבי האירוע שנצפה הוא מתקפה.
• הפריסה האוטומטית: הדגל מציין אם הקריטריונים להגנה אוטומטית הופעלו בזמן הזיהוי. שימו לב שהדגל לא מצביע בהכרח על כך שכבר בוצעה פעולה שהשפיעה על התנועה. ההגנה האוטומטית היא דינמית, והמערכת מעריכה באופן רציף את קריטריוני ההפעלה ומזהה תוקפים. כדי לראות את הפעולות הספציפיות שבוצעו, צריך לבדוק את השדות הרלוונטיים בתיעוד הבקשות של Cloud Armor.
• חתימת התקפה
  • שם המאפיין: השם של המאפיין שתואם למאפיין Value שבהמשך, כמו שם מסוים של כותרת בקשה או מקור גיאוגרפי.
  • ערך: הערך שאליו מתאים המאפיין בתנועה הזדונית.
  • סוג ההתאמה: הקשר בין Value לבין המאפיין בתנועה של התקפות. הערך שווה למאפיין בתנועה של התקפות או שהוא מחרוזת משנה שלו.
  • סבירות למתקפה: הסבירות לכך שבקשה מסוימת היא זדונית, בהינתן שהמאפיין הרלוונטי של הבקשה הזו תואם ל-Value.
  • החלק היחסי בהתקפה: אחוז התנועה הפוטנציאלית של ההתקפה שתואמת לValue.
  • השיעור בבסיס: אחוז התנועה הרגילה בבסיס שתואמת ל-Value.
• הצעה לכלל
  • תנאי התאמה: הביטוי שישמש בתנאי ההתאמה של הכללים כדי לזהות תנועה זדונית.
  • שיעור הבסיס שמושפע: האחוז המשוער של תנועה טובה לשירות הקצה העורפי הספציפי שנמצא תחת מתקפה, שנתפס על ידי הכלל המוצע.
  • שיעור הבסיס שמושפע מהמדיניות: אחוז התנועה הטובה הצפוי לכל שירותי הקצה העורפי באותה מדיניות אבטחה, שנתפס על ידי הכלל המוצע.
  • שיעור התקפות מושפע: אחוז התנועה של התקפות שצפוי להיכלל בכלל המוצע.
• סטטוס הכלל: פרטים נוספים על יצירת הכלל.

סקירה כללית על למידת מכונה ופרטיות

• נתוני אימון ונתוני זיהוי
  • התכונה 'הגנה דינמית' יוצרת כמה מודלים כדי לזהות מתקפות פוטנציאליות ולזהות את החתימות שלהן. האותות שבהם המודלים האלה משתמשים כדי לקבוע אם מתקפת סייבר מתרחשת, נגזרים מהמטא-נתונים שנצפו בתנועת הבקשות הנכנסות מהפרויקטים שלכם. המטא-נתונים האלה כוללים: כתובת ה-IP של הלקוח, המיקום הגיאוגרפי של הלקוח והערכים של חלק מכותרות בקשות ה-HTTP.
  • התכונות בפועל שבהן נעשה שימוש במודלים הן מאפיינים סטטיסטיים שנגזרים מהאותות שצוינו למעלה. כלומר, נתוני האימון של המודלים לא כוללים את הערכים בפועל של מטא-נתונים כלשהם, כמו כתובות IP או ערכים של כותרות בקשות.
  • קבוצה משותפת של מודלים לזיהוי, שאומנו רק באמצעות נתונים מלאכותיים, משותפת לכל הלקוחות כדי לקבוע אם מתרחשת מתקפה, כשמפעילים לראשונה את Adaptive Protection. אחרי שתדווחו על אירוע תקיפה שגוי, המודלים יעודכנו באמצעות אותות תנועה ספציפיים מהפרויקטים שלכם. המודלים האלה הם מקומיים לפרויקטים שלכם ולא נעשה בהם שימוש עבור לקוחות אחרים.
• נתונים של יצירת חתימה
  • אחרי שההגנה הדינמית קובעת שמתרחשת מתקפה פוטנציאלית, היא יוצרת חתימת מתקפה שעוזרת ליעד לצמצם את המתקפה במהירות. כדי להשיג את המטרה הזו, אחרי שמפעילים את ההגנה הדינמית במדיניות אבטחה, מדדי תנועה ומטא-נתונים של בקשות לשירות קצה עורפי (שמשויך למדיניות האבטחה) נרשמים באופן רציף כדי ללמוד את מאפייני תנועת הבסיס.
  • מכיוון שההגנה הדינמית צריכה ללמוד על תנועת הבסיס, יכול להיות שיעברו עד שעה לפני שהיא תיצור כללים לצמצום של מתקפות פוטנציאליות.

המאמרים הבאים

• מידע על תרחישים נפוצים לדוגמה לשימוש בהגנה דינמית
• מידע על התכונות במסלולים של Cloud Armor Enterprise
• איך מפעילים את Cloud Armor Enterprise