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

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

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

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

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

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

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

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

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

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

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

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

הפעלת ניתוח 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. כללי ברירת המחדל לדחייה

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

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

שיפור הכלל

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

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

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

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

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

שימוש בכללים יציבים או בכללי קנרי

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

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

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

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

בחירת שיעור דגימה של Cloud Logging

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

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

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

ניהול כללי

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

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

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

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

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

שימוש ב-Terraform

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