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

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

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 כבר מגנה על האפליקציות. כשמפעילים את ההגנה הדינמית למדיניות אבטחה מסוימת, ההגנה הדינמית פועלת בכל השירותים לקצה העורפי שמקושרים למדיניות האבטחה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ברגע שההגנה הדינמית מזהה מתקפה חשודה, היא יוצרת אירוע בלוח הבקרה של אירועי ההגנה הדינמית ופריט ביומן ב-Cloud Logging. ההתראה מופיעה במטען הייעודי (payload) של JSON בפריט היומן. פריט היומן נוצר במשאב Network Security Policy ב-Cloud Logging. הודעה ביומן מזהה את שירות לקצה העורפי שנמצא תחת מתקפה, וכוללת ציון רמת סמך שמציין עד כמה Adaptive Protection מעריך את השינוי בדפוס התנועה שזוהה כחריגה. הודעת היומן כוללת גם חתימת מתקפה שממחישה את המאפיינים של תנועת הנתונים של המתקפה, וגם כללים מוצעים של 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

התראה על הגנה דינמית ויומן האירועים הרלוונטי של 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 של צד שלישי לפני מאזן העומסים החיצוני של אפליקציות (ALB), מומלץ להגדיר את השדה userIpRequestHeaders כדי להוסיף את כתובת ה-IP (או טווחי כתובות ה-IP) של הספק לרשימת ההיתרים. כך נמנעת טעות בזיהוי של כתובת ה-IP של הלקוח של השרת הפרוקסי ככתובת שמשתתפת בהתקפה על ידי ההגנה האדפטיבית. במקום זאת, הוא בודק את השדה שהוגדר על ידי המשתמש לכתובת ה-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. לצד כל אירוע של מתקפה שמופיע מתחת לתרשים, יש כפתור שפותח חלון אינטראקטיבי שמאפשר לדווח על שגיאה באירוע, עם הקשר אופציונלי. דיווח על שגיאה באירוע עוזר להקטין את הסיכוי לשגיאות דומות בעתיד. עם הזמן, זה משפר את הדיוק של ההגנה הדינמית.

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

נתוני הטלמטריה של 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

ההתראה על הגנה דינמית שנשלחת אל Cloud Logging מורכבת מרשומה ביומן שמכילה את הרכיבים הבאים:

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

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

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

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

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