מדיניות אבטחה היררכית היא קטגוריה של מדיניות אבטחה שמרחיבה את טווח ההגנה של חומת האש (WAF) של אפליקציות אינטרנט ב-Cloud Armor וההגנה מפני מתקפות DDoS מעבר לפרויקטים בודדים. הן מצורפות ברמת הארגון, התיקייה או הפרויקט. הן שונות ממדיניות אבטחה ברמת השירות, שמצורפת ישירות לשירותים עורפיים או למאגרי מידע עורפיים.
כשמגדירים מדיניות אבטחה היררכית ברמת הארגון או התיקייה, פרויקטים ברמות נמוכות יותר בהיררכיה יורשים את מדיניות האבטחה הזו. הירושה הזו מאפשרת להגדיר כללים של מדיניות אבטחה שרוצים להחיל על כל הפרויקטים בארגון או על חלק מהם. כך מתאפשרת אכיפת אבטחה עקבית ומרכזית בסביבת Google Cloud .
בדף הזה מוסבר מה ההבדלים בין כללי אבטחה היררכיים לבין כללי אבטחה ברמת השירות. לפני שממשיכים, חשוב לקרוא את סקירת מדיניות האבטחה כדי להבין איך מדיניות האבטחה פועלת. בנוסף, מומלץ להכיר את היררכיית המשאבים.
תרחישים לדוגמה
בארגונים גדולים, ניהול מדיניות אבטחה במספר רב של פרויקטים יכול להיות מורכב ולגזול זמן רב. כללי מדיניות היררכיים בנושא אבטחה מציעים את היתרונות הבאים שיעזרו לכם להתמודד עם האתגרים האלה:
- שליטה מרכזית: מתן אפשרות לאדמינים ברמת הארגון והתיקייה להגדיר ולאכוף מדיניות אבטחה בכמה פרויקטים.
- עקביות: מספקת מצב אבטחה אחיד בכל הארגון, ומפחיתה את הסיכון לטעויות בהגדרות ולפערים באבטחה.
- יעילות: ייעול הפריסה של עדכוני אבטחה ופתרונות, כמו חסימה של טווחי כתובות IP ספציפיים או טיפול בפגיעויות קריטיות, במספר גדול של משאבים בו-זמנית.
- העברת סמכויות: אפשר להעביר סמכויות של אחריות על אבטחה לצוותים או למחלקות שונים על ידי החלת מדיניות ברמות המתאימות בהיררכיה.
אתם יכולים להחיל את העקרונות הכלליים האלה ולשלב ביניהם כדי להתאים אותם לצרכים של הארגון. ריכזנו כאן כמה תרחישים לדוגמה:
- חסימת כתובות IP בכל הארגון: אתם יכולים לחסום תנועה מטווחים של כתובות IP זדוניות ידועות בכל הפרויקטים בארגון.
- הגבלות לפי מיקום גיאוגרפי: אתם יכולים להגביל את התנועה מאזורים גיאוגרפיים ספציפיים ברמת הארגון או התיקייה.
- צמצום הסיכון של CVE: אפשר לפרוס במהירות כללי WAF כדי לצמצם את הסיכון של פגיעויות קריטיות בכמה פרויקטים.
- אכיפת תאימות: אתם יכולים לאכוף את ההקפדה על דרישות רגולטוריות על ידי החלת מדיניות אבטחה עקבית בכל הארגון.
- בקרת גישה מפורטת: אתם יכולים להעניק גישה לכל המשאבים בתיקייה מסוימת לטווחים ספציפיים של כתובות IP או לאזורים גיאוגרפיים מסוימים.
תכונות
מדיניות אבטחה היררכית תומכת בחלק מהתכונות שמדיניות אבטחה ברמת השירות תומכת בהן. בטבלה הבאה מוצגות השוואה בין התכונות של Cloud Armor שאפשר להשתמש בהן עם מדיניות אבטחה היררכית ומדיניות אבטחה ברמת השירות:
| סוג הקצה הקדמי |
|
|
| נקודת צירוף (משאב מוגן) | שירות לקצה העורפי | צמתים בהיררכיית המשאבים |
| פעולות של כלל |
|
|
| כתובת ה-IP של הלקוח | ||
| מיקום גיאוגרפי של לקוחות | ||
| מספר ASN של הלקוח | ||
| ניהול בוטים | (רק EXTERNAL_302 ובקשת קישוט) |
|
| סינון בשכבה 7 | ||
| WAF | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| הגנה דינמית | ||
| קבוצות כתובות | ||
| קבוצות כתובות ברמת הארגון | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| רישום בקשות ביומן |
איך פועלים כללי מדיניות אבטחה היררכיים
כשיוצרים מדיניות אבטחה היררכית, יוצרים אותה ברמת הארגון או התיקייה, והמשאב הזה הוא הבעלים של מדיניות האבטחה ההיררכית. אחרי שיוצרים מדיניות אבטחה היררכית, כללי מדיניות האבטחה לא חלים על אף אחד מהמשאבים.
לאחר מכן, משייכים את מדיניות האבטחה ההיררכית לארגון, לתיקייה או לפרויקט, שיכולים להיות זהים למשאב שבבעלותו המדיניות. אחרי שמקשרים מדיניות אבטחה היררכית למשאב, הכללים של מדיניות האבטחה חלים על המשאבים המוגנים בצומת הזה ומתחתיו בהיררכיית המשאבים. כדי לעזור לכם להחליט לאיזה משאב לצרף את מדיניות האבטחה ההיררכית, הנה רשימה של תרחישי שימוש בסיסיים לכל משאב:
- ארגון: כדאי להגדיר מדיניות אבטחה היררכית ברמת הארגון כסוג ברירת המחדל של מדיניות אבטחה היררכית.
לכללי המדיניות האלה יש הרשאות רחבות של ניהול זהויות והרשאות גישה (IAM), והם חלים על כל הצמתים בארגון. כדי לציין את המשאבים האלה, משתמשים בדגל
--organizationבמהלך השיוך. - תיקייה: משתמשים במדיניות אבטחה היררכית כשרוצים להחיל את אותם כללים של מדיניות אבטחה על כמה פרויקטים, אבל לא על כל הארגון. כדי לציין את המשאבים האלה, משתמשים בדגל
--folderבמהלך השיוך. - פרויקט: משתמשים בסוג הזה של מדיניות אבטחה היררכית כשרוצים להחיל את אותם כללי מדיניות אבטחה על כל המשאבים בפרויקט, למשל כשרוצים להחיל רשימת כתובות IP חסומות על כמה שירותי קצה עורפי.
כדי לציין את המשאבים האלה, משתמשים בדגל
--projectבמהלך השיוך. - ברמת השירות: משתמשים במדיניות אבטחה ברמת השירות כשצריך כללי מדיניות אבטחה ייחודיים ששונים בין כל אחד מהשירותים. כל מדיניות אבטחה ברמת השירות מחילה את הכללים שלה רק על המדיניות בקצה העורפי שאליה היא מצורפת. מציינים את המשאבים האלה באמצעות הדגל
--project-number.
אפשר להשתמש רק באחד מהדגלים האלה לכל מדיניות אבטחה היררכית. מציינים את שאר הדגלים, כמו --name או --type, בדיוק כמו שמגדירים מדיניות אבטחה ברמת השירות. למידע נוסף על האופן שבו פועלות מדיניות אבטחה היררכיות, אפשר לעיין ברשימה הבאה:
- כשמדיניות אבטחה היררכית משויכת לצומת בהיררכיית המשאבים, כל המשאבים המוגנים שמתחת לצומת הזה בהיררכיה מקבלים בירושה את המדיניות.
- אתם יכולים לראות את מדיניות האבטחה שחלה על כל משאב מוגן בפרויקט, בכל מדיניות האבטחה ההיררכית ובכל מדיניות האבטחה ברמת השירות. מידע נוסף מופיע במאמר בנושא הצגת כל הכללים האפקטיביים של Cloud Armor למשאב מוגן.
- אפשר להעביר כללי מדיניות היררכיים של אבטחה מצומת אחת בהיררכיית משאבים לצומת אחרת. כדאי לעשות את זה כשמתכננים לארגן מחדש את מבנה התיקיות.
- כשמוחקים צומת בהיררכיית המשאבים, כמו תיקייה או פרויקט, מדיניות האבטחה ההיררכית שמצורפת לצומת הזה נמחקת רק אם יצרתם אותה מתחת לצומת הזה בהיררכיית המשאבים.
- אם יצרתם את מדיניות האבטחה במקום אחר ואז העברתם אותה לצומת, היא לא תימחק.
- כדי למנוע מחיקה לא מכוונת של מדיניות אבטחה היררכית, מומלץ להעביר כל מדיניות אבטחה היררכית שרוצים לשמור לצומת אחר בהיררכיית המשאבים לפני שמוחקים את הצומת הקיים.
סדר ההערכה של הכללים
מערכת Cloud Armor מעריכה את כללי מדיניות האבטחה בסדר הבא:
- מדיניות אבטחה היררכית ברמת הארגון
- מדיניות אבטחה היררכית ברמת התיקייה (מתחילים בתיקיית האב, ואז עוברים לכל תיקיית משנה)
- מדיניות אבטחה היררכית ברמת הפרויקט
- מדיניות אבטחה ברמת השירות
הסדר הזה של הערכת הכללים אומר שיכול להיות שתהיה לכם מדיניות אבטחה היררכית עם עדיפות נמוכה, שהמערכת תעריך לפני מדיניות אבטחה ברמת השירות עם עדיפות גבוהה. חשוב לחשוב היטב על הכללים הקיימים במדיניות האבטחה ברמת השירות עם עדיפות גבוהה, ולשקול מה יקרה אם Cloud Armor לא יעריך בקשה שמותרת או נדחית על ידי מדיניות אבטחה היררכית.
הפעולה goto_next
ל-Cloud Armor יש פעולת כלל שייחודית לכללי מדיניות אבטחה היררכיים: הפעולה goto_next. כש-Cloud Armor מחיל את הפעולה הזו, הוא מפסיק להעריך את הכללים במדיניות האבטחה הנוכחית ומתחיל להעריך את הכללים במדיניות האבטחה הבאה.
נניח שיש לכם מדיניות אבטחה היררכית ברמת הארגון עם הרבה כללים שאתם רוצים להשתמש בהם כדי להגביל בקשות בכל הארגון. אתם רוצים לאפשר לבקשות שמגיעות מטווח כתובות IP מסוים לדלג על ההערכה של הכללים האלה שחלים על כל הארגון. לכן, יוצרים כלל בעדיפות גבוהה שתואם לטווח כתובות ה-IP הזה עם הפעולה goto_next. הבקשות מטווח כתובות ה-IP הזה נבדקות קודם לפי הכלל הזה, ומכיוון שהן עומדות בתנאי ההתאמה, הן לא נבדקות לפי כללים אחרים במדיניות האבטחה ההיררכית הזו ברמת הארגון.
באותו מקרה לדוגמה, אם השתמשתם בפעולה allow או deny במקום בפעולה goto_next, הבקשה תאושר או תידחה ברגע שתנאי ההתאמה יתקיים. הערכה היררכית כזו אומרת שלא מתבצעת הערכה של מדיניות אבטחה נוספת ביחס לבקשה הזו.
שיוך ל-Google Cloud Armor Enterprise והתנהלות החיוב
כשמצרפים כללי מדיניות היררכיים לאבטחה, כל אחד מהפרויקטים שמקבלים בירושה את כללי המדיניות ההיררכיים לאבטחה צריך להיות רשום ל-Cloud Armor Enterprise. הם כוללים את כל הפרויקטים בארגון או בתיקייה עם מדיניות אבטחה היררכית שלא נכללים בהם באופן מפורש, ואת כל הפרויקטים עם מדיניות אבטחה היררכית שמצורפת ישירות לפרויקט.
- פרויקטים שמקושרים לחשבון לחיוב ב-Cloud עם מינוי שנתי ל-Cloud Armor Enterprise נרשמים אוטומטית למינוי הזה אם הם עדיין לא רשומים.
- אם אין לכם מינוי ל-Cloud Armor Enterprise Annual, פרויקטים נרשמים אוטומטית ל-Cloud Armor Enterprise Paygo כשהם מקבלים בירושה מדיניות אבטחה היררכית. אם נרשמתם למינוי Cloud Armor Enterprise Annual בחשבון לחיוב אחרי שהפרויקט שלכם נרשם אוטומטית ל-Cloud Armor Enterprise Paygo, הפרויקט לא נרשם אוטומטית ל-Annual. מידע נוסף על Cloud Armor Enterprise Paygo זמין במאמר Cloud Armor Standard לעומת Cloud Armor Enterprise.
- אם מעדכנים מדיניות אבטחה היררכית כדי להחריג פרויקט אחרי שהפרויקט נרשם אוטומטית ל-Cloud Armor Enterprise, הפרויקט לא יבוטל אוטומטית. כדי לבטל את ההרשמה של הפרויקט באופן ידני, אפשר לעיין במאמר הסרת פרויקט מ-Cloud Armor Enterprise.
- אי אפשר להסיר פרויקט מ-Cloud Armor Enterprise אם יש בו מדיניות אבטחה היררכית שעברה בירושה.
תהליך ההרשמה האוטומטית יכול להימשך עד סוף יום העסקים הבא. במהלך התקופה הזו, כללי מדיניות האבטחה ההיררכיים שלכם יהיו בתוקף ולא יחויבו עלויות של Cloud Armor Enterprise. כשמצרפים את הפרויקט, יומני הביקורת מתעדכנים כדי לשקף את הסטטוס של Cloud Armor Enterprise בפרויקט. תוכלו לראות את רמת הפרויקט החדשה גם בGoogle Cloud מסוף.
פרויקטים נרשמים אוטומטית רק אם לפחות שירות לקצה העורפי אחד למאזני עומסים חיצוניים גלובליים משתמש ב-HTTP, ב-HTTPS, ב-HTTP2, ב-H2C או ב-GRPC.
מגבלות
אלו המגבלות שחלות על כללי מדיניות אבטחה היררכיים:
- מדיניות אבטחה היררכית לא זמינה בפרויקטים שלא נמצאים בארגון.
- בפרויקטים חדשים או בפרויקטים ששוחזרו לאחרונה, יכול להיות שיעברו כמה שעות עד שמדיניות האבטחה שעברה בירושה בפרויקט תתעדכן.
- בפרויקט שבו הופעל לאחרונה Compute Engine API, יכול להיות שיעברו כמה שעות עד שמדיניות אבטחה שעברה בירושה בפרויקט הזה תתעדכן.
- אתם יכולים לשנות את ההגדרות של כללי WAF שהוגדרו מראש במדיניות אבטחה היררכית שבבעלותכם, אבל בעלי השירותים שמקבלים בירושה מדיניות אבטחה היררכית לא יכולים לשנות את ההגדרות של הכללים.