שיטות מומלצות לשימוש ב-Cloud Armor

בדף הזה מפורטות שיטות מומלצות לאופטימיזציה ולהתאמה של פריסות Google Cloud Armor.

‫Cloud Armor נפרס עם מאזן עומסים גלובלי חיצוני של אפליקציות (ALB), עם מאזן עומסים קלאסי של אפליקציות (ALB) או עם מאזן עומסי רשת חיצוני בשרת proxy. כשפורסים את Cloud Armor, מצמידים מדיניות אבטחה לשירות לקצה העורפי של מאזן העומסים שרוצים להגן עליו. מדיניות אבטחה מורכבת מאוסף של כללים מוגדרים מראש וכללים מותאמים אישית שאתם קובעים.

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

יצירה של מדיניות אבטחה וכללים

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

הוספת תיאורים לכללים

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

כדאי לשקול שימוש ברווחים בעדיפות גבוהה

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

שימוש במצב תצוגה מקדימה

לכללים של מדיניות האבטחה, כולל חתימות של Open Web Application Security Project‏ (OWASP), יכולות להיות השפעות בלתי צפויות על האפליקציה. מומלץ להשתמש במצב תצוגה מקדימה כדי לבדוק אם הוספה של כלל תשפיע לרעה על התנועה בשלב ההפקה.

הפעלה של הגנה דינמית ב-Google Cloud Armor

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

הפעלת ניתוח של JSON

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

בדיקת הלוגיקה

כלל מופעל כשתנאי ההתאמה שלו מחזיר את הערך true. לדוגמה, תנאי ההתאמה origin.region_code == 'AU' מחזיר את הערך true אם קוד האזור של הבקשה הוא AU. אם כלל בעדיפות גבוהה יותר מחזיר את הערך True, המערכת מתעלמת מהפעולה בכלל בעדיפות נמוכה יותר.

בדוגמה הבאה, נניח שרוצים ליצור מדיניות אבטחה כדי לחסום משתמשים מהאזור AU, למעט תנועה בטווח כתובות ה-IP‏ 10.10.10.0/24. נבחן את מדיניות האבטחה הבאה עם שני כללים:

Rule1
expr: inIpRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

בדוגמה הזו, Rule1 מאפשר תנועה שמקורה בטווח כתובות ה-IP‏ 10.10.10.0/24. מכיוון ש-Rule1 הוא הכלל בעדיפות גבוהה יותר, התנועה הזו מותרת לפני שהיא נבדקת מול Rule2, כלומר Cloud Armor לא בודק אותה מול Rule2 (או מול כל כלל אחר שנותר).

כדי להשיג חריגה דומה במסגרת כלל אחד, אפשר לשלב תנאי התאמה באמצעות אופרטורים לוגיים. חשוב לציין שהגישה הזו שונה מהדוגמה של שני כללים מבחינת אופן ההערכה של כללים עוקבים. לדוגמה, הביטוי הבא משתמש בכלל יחיד שדוחה תנועה של AU אלא אם היא מגיעה מטווח כתובות ה-IP הספציפי 10.10.10.0/24:

expr: origin.region_code == 'AU' && !inIpRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1

התנאי הזה מחזיר true (ומפעיל פעולת דחייה) רק אם האזור הוא AU וכתובת ה-IP לא נמצאת בטווח 10.10.10.0/24.

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

זיהוי כתובות ה-IP של הלקוחות של הסורקים

סורקי האבטחה יכולים להיות ממוקמים בתוך Google או מחוצה לה. אם רוצים לקבל הערכה חיצונית ולא מסוננת של האפליקציה, אפשר לאפשר במפורש תעבורה על סמך כתובת IP (או טוקן אחר) לפני ההערכה שלה בהשוואה לכללים אחרים.

קיבוץ ומיון של כללים במדיניות האבטחה

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

  1. כללי דחייה מפורשים (מספר מערכת אוטונומית, אזור, טווחי כתובות IP)
  2. כללים מפורשים להרשאה מהימנה (סורקים, מערכות מהימנות – שימוש בזהירות רבה)
  3. כללי אבטחה (OWASP, כללים מותאמים אישית)
  4. כללי הרשאה מפורשים (ASN, נוכחות של ערך כותרת, טווח כתובות IP)
  5. כללי ברירת מחדל של דחייה

שימוש ב-reCAPTCHA לניהול בוטים

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

הגדרת ספים להגבלת קצב של יצירת בקשות

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

שיפור הכלל

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

בחירה של רמת הרגישות של כלל WAF שהוגדר מראש

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

הפעלת רישום מפורט (verbose) ביומן

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

שימוש בכללים יציבים או בכללי גרסה ראשונית (canary)

יש שני סוגים של כללי WAF שהוגדרו מראש ב-Cloud Armor: יציבים וניסיוניים. כשמוסיפים כללים חדשים ל-OWASP Core Rule Set (CRS) הנוכחי, אנחנו מפרסמים אותם בגרסאות Canary של הכללים לפני שאנחנו מפרסמים אותם באופן אוטומטי בגרסאות היציבות של הכללים. מומלץ לפרוס את כללי הגרסה הראשונית (canary) בסביבת בדיקה כדי לראות את ההשפעות של שינויים ותוספות בסביבה שלכם. אפשר לבדוק את שמות הכללים בדף התאמה של כללי WAF ב-Cloud Armor כדי לוודא שגרסת הקנרי מסונכרנת עם הגרסה היציבה.

רישום ביומן ומעקב

בקטעים הבאים מפורטות שיטות מומלצות והמלצות להגדרת רישום ביומן ומעקב.

שימוש ב-Security Command Center

‫Cloud Armor משתלב אוטומטית עם Security Command Center. ‫Cloud Armor מייצא ממצאים שונים אל Security Command Center:

  • עלייה מותרת בתנועה
  • הגדלת יחס הדחייה

חשוב לוודא שאנשי האבטחה של האתר בודקים את הממצאים האלה.

בחירת תדירות דגימה ב-Cloud Logging

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

הערה: יומני Adaptive Protection מוצגים במסוף בקטע Google Cloud resource, ולא בקטע של מאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות (ALB).network_security_policy

שימוש בלוח הבקרה של Cloud Monitoring

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

ניהול כללי

בהמשך מפורטות שיטות מומלצות והמלצות נוספות להגדרת Cloud Armor.

הגדרה של בקרת גישה לניהול זהויות והרשאות גישה (IAM)

בהתאם לשיטות המומלצות הכלליות של Google Cloud IAM, חשוב לוודא שלאנשים הנכונים יש גישה ל-Cloud Armor. כדי להגדיר, לשנות, לעדכן ולמחוק מדיניות אבטחה של Cloud Armor, נדרש התפקיד אדמין לענייני אבטחה של Compute. בנוסף, כדי לצרף מדיניות אבטחה של Cloud Armor לשירות לקצה העורפי, צריך את התפקיד Compute Network Admin או את ההרשאה compute.backendServices.setSecurityPolicy.

צמצום מספר כללי המדיניות

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

שימוש ב-Terraform

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

הגדרת Cloud Armor באמצעות Google Kubernetes Engine

אם אתם משתמשים ב-Google Kubernetes Engine ‏ (GKE), אתם צריכים להגדיר את Cloud Armor ותכונות Ingress אחרות באמצעות BackendConfigפרמטרים. מומלץ להימנע מהגדרה ידנית של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או של מאזן עומסים קלאסי של אפליקציות שישמשו כנקודת כניסה. מידע נוסף על הגדרת Cloud Armor עם GKE זמין במאמר בנושא הגדרת תכונות של Ingress.

אחרי שמגדירים מדיניות אבטחה של Cloud Armor, אפשר גם להשתמש ב-Kubernetes Gateway כדי להפעיל אותה ב-GKE. חשוב ליצור מדיניות אבטחה של קצה עורפי ב-Cloud Armor לפני שמפנים למדיניות במשאב המדיניות GCPBackendPolicy. אם מפעילים שער אזורי, צריך ליצור כללי מדיניות אזוריים לאבטחת עורף השרת ב-Cloud Armor.