בדף הזה מפורטות שיטות מומלצות לאופטימיזציה ולהתאמה של פריסות 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, ולכן אתם מגדירים את הכלל הראשון במדיניות לחסימת תנועה כזו. בנוסף, אתם רוצים לאפשר באופן מפורש תנועה מסוימת לאפליקציה בלי שהמדיניות בנושא אבטחה תעבד אותה. בדוגמה הזו, אנחנו ממליצים על המבנה הבא של סדר העדיפויות של הכללים, מהעדיפות הגבוהה ביותר לעדיפות הנמוכה ביותר:
- כללי דחייה מפורשים (מספר מערכת אוטונומית, אזור, טווחי כתובות IP)
- כללים מהימנים להרשאה מפורשת (סורקים, מערכות מהימנות – שימוש זהיר במיוחד)
- כללי אבטחה (OWASP, כללים מותאמים אישית)
- כללי הרשאה מפורשים (ASN, נוכחות של ערך כותרת, טווח כתובות IP)
- כללי ברירת המחדל לדחייה
שימוש ב-reCAPTCHA לניהול בוטים
Cloud Armor משתלב עם reCAPTCHA של Google כדי לזהות בוטים בשכבת ה-WAF. באינטגרציה הזו, reCAPTCHA יוצר טוקנים של reCAPTCHA, ו-Cloud Armor מבצע את תהליך ההערכה של הטוקנים במקום reCAPTCHA. הפעולה הזו מפחיתה את העומס על המקור, ויכולה להפחית את העלויות שלכם. בנוסף, היא מציבה את אמצעי הבקרה של האבטחה קרוב יותר למשתמש הקצה מאשר לשרתי הקצה העורפיים שלכם. מידע נוסף מופיע במאמר סקירה כללית על ניהול בוטים.
הגדרת ספים להגבלת קצב של יצירת בקשות
הגבלת קצב של יצירת בקשות היא יכולת גמישה וחשובה למניעת ניצול לרעה ולצמצום איומים בהיקף גדול, כמו דחיסת פרטי כניסה או התקפות DDoS ברמה 7. כשפורסים הגבלת קצב של יצירת בקשות בפעם הראשונה, חשוב לבחור סף שמתאים לאפליקציה. מומלץ להתחיל עם אכיפה במצב תצוגה מקדימה. כשמנתחים את תעבורת הנתונים ומבינים אותה, אפשר לשנות את הפרמטרים של הגבלת קצב של יצירת בקשות. בנוסף, חשוב לקחת בחשבון את העדיפות שאתם מקצים לכלל הגבלת קצב של יצירת בקשות. יכול להיות שכלל בעדיפות גבוהה יותר יאפשר או יחסום תעבורת נתונים באופן מפורש לפני שהמערכת תעריך אותה בהתאם לכלל הגבלת קצב של יצירת בקשות.
שיפור הכלל
יכול להיות שאפליקציות אינטרנט יאפשרו בקשות שנראות כמו התקפות, ויכול להיות שהן יאפשרו או אפילו ידרשו ממשתמשים לשלוח בקשות שתואמות לחתימות בכללים שהוגדרו מראש ב-WAF. חשוב מאוד לאמת את הכללים של Cloud Armor מול האפליקציה ולטפל בממצאים שאולי לא רלוונטיים לאפליקציה לפני שמקדמים את הכלל על ידי השבתת מצב התצוגה המקדימה באפליקציית ייצור. בקטעים הבאים מפורטות שיטות מומלצות והמלצות להתאמת הכללים שהוגדרו מראש ב-WAF.
בחירה של רמת הרגישות של כלל WAF שהוגדר מראש
כשמטמיעים כלל WAF שהוגדר מראש, אפשר לבחור רמת רגישות מתאימה בהתאם לדרישות האבטחה ולציר הזמן. מומלץ להתחיל עם רמת רגישות של 1 ברוב האפליקציות שצריכות לעמוד בדרישות האבטחה של הארגון. כללים שהוגדרו לרגישות 1 משתמשים בחתימות באיכות גבוהה ומפחיתים את הרעש הפוטנציאלי מהכלל. חתימות שמשויכות לרגישות גבוהה יותר עשויות לזהות ולמנוע קבוצה גדולה יותר של ניסיונות ניצול לרעה, אבל עלולות להוביל לרעשי רקע באפליקציות מוגנות מסוימות. עם זאת, בעומסי עבודה (workloads) שחלים עליהם דרישות אבטחה מחמירות יותר, כדאי להשתמש ברמת הרגישות הגבוהה ביותר. בתרחישי השימוש האלה, יכול להיות שיהיו הרבה רעשי רקע או ממצאים לא רלוונטיים, ולכן צריך לבצע כוונון לפני שמדיניות האבטחה עוברת לשלב הייצור.
הפעלת רישום מפורט (verbose) ביומן
אם אתם צריכים מידע נוסף על מאפייני הבקשה ומטענים ייעודיים (payloads) שמפעילים כלל מסוים של WAF, אתם יכולים להפעיל רישום מפורט ביומן. רישום מפורט ביומן מספק פרטים מבקשות שמפעילות כללים מסוימים, כולל קטע קוד של החלק הבעייתי בבקשה. זה עוזר לפתור בעיות ולכוון את Cloud Armor. רישום מפורט ביומן יכול לגרום לתוכן של בקשות ממשתמשי קצה להירשם ביומן ב-Cloud Logging, ולכן יש סיכוי שתצברו ביומנים פרטים אישיים מזהים של משתמשי קצה. לכן, לא מומלץ להפעיל רישום מפורט ביומן עבור עומסי עבודה של ייצור למשך פרקי זמן ארוכים.
שימוש בכללים יציבים או בכללי Canary {: #stable-vs-canary }
יש שני סוגים של כללי WAF שהוגדרו מראש ב-Cloud Armor: יציבים וקנרי. כללים חדשים או עדכונים לכללים קיימים מתוך OWASP Core Rule Set (CRS) זמינים קודם דרך canary rulesets, ואחרי תקופת בדיקה כדי לוודא יציבות, הם מועברים ל-stable ruleset.
מומלץ לשמור על כללי קנרי במצב תצוגה מקדימה עם עדיפות גבוהה יותר, ולשמור על כללים יציבים במצב אכיפה עם עדיפות נמוכה יותר. הגישה הזו עוזרת לכם לאמת את השינויים בכללים באופן יסודי לפני שהם משפיעים על סביבת הייצור. כדי לוודא שכללי הקנרי מסונכרנים עם קבוצת הכללים היציבה, בודקים את שמות הכללים במאמר התאמה של כללי 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) וגם במאזן עומסים קלאסי של אפליקציות, היומנים לא מופעלים כברירת מחדל, ולכן חשוב להפעיל את הרישום ביומן באופן ידני.
הערה: יומני Adaptive Protection מוצגים במסוף בקטע Google Cloud משאב, ולא בקטע של מאזן עומסים גלובלי חיצוני של אפליקציות (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פרמטרים. מומלץ להימנע מהגדרה ידנית של איזון עומסים חיצוני גלובלי של אפליקציות או איזון עומסים קלאסי של אפליקציות שישמשו כנקודת כניסה. מידע נוסף על הגדרת Cloud Armor באמצעות GKE זמין במאמר הגדרת תכונות של Ingress.
אחרי שמגדירים מדיניות אבטחה של Cloud Armor, אפשר גם להשתמש ב-Kubernetes Gateway כדי להפעיל אותה ב-GKE. חשוב ליצור מדיניות אבטחה של קצה עורפי ב-Cloud Armor לפני שמפנים למדיניות במשאב המדיניות GCPBackendPolicy. אם מפעילים שער אזורי, צריך ליצור כללי מדיניות אזוריים לאבטחת העורף ב-Cloud Armor.