שיטות מומלצות לשימוש ב-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.

בודקים את ההיגיון

כלל מופעל כשתנאי ההתאמה שלו מתקיים. לדוגמה, תנאי ההתאמה origin.region_code == 'AU' מתקיים אם קוד האזור של הבקשה הוא 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

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

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

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

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

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

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

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

הגדרת ערכי סף להגבלת קצב של יצירת בקשות

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

כוונון כללים

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

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

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

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

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

שימוש בכללים יציבים או בכללי Canary

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

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

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

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

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

ביומנים של Cloud Armor לכל בקשה נעשה שימוש בתשתית הרישום ביומן של מאזן העומסים הגלובלי החיצוני של אפליקציות (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 Security Admin. בנוסף, כדי לצרף מדיניות אבטחה של Cloud Armor לשירות לקצה העורפי, צריך את התפקיד "אדמין של רשת Compute" או את ההרשאה compute.backendServices.setSecurityPolicy.

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

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

שימוש ב-Terraform

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