סקירה כללית על הגנה דינמית

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

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

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

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

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

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

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

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

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

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

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

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

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