כללי מדיניות אבטחה היררכיים הם קטגוריה של כללי מדיניות אבטחה שמרחיבים את היקף ההגנה של חומת האש ליישומי אינטרנט (WAF) ושל ההגנה מפני DDoS של Google Cloud Armor מעבר לפרויקטים ספציפיים. הן מצורפות ברמת הארגון, התיקייה או הפרויקט. הן שונות ממדיניות אבטחה ברמת השירות, שמצורפת ישירות לשירותים לקצה העורפי או לקטגוריות לקצה העורפי.
כשמגדירים מדיניות אבטחה היררכית ברמת הארגון או התיקייה, פרויקטים ברמות נמוכות יותר בהיררכיה יורשים את מדיניות האבטחה הזו. הירושה הזו מאפשרת לכם להגדיר כללים של מדיניות אבטחה שאתם רוצים להחיל על כל הפרויקטים בארגון או על כמה מהם. כך אפשר לאכוף את האבטחה באופן עקבי ומרוכז בסביבת Google Cloud .
בדף הזה מוסבר מה ההבדל בין מדיניות אבטחה היררכית לבין מדיניות אבטחה ברמת השירות. לפני שממשיכים, כדאי לקרוא את הסקירה הכללית של מדיניות האבטחה כדי לוודא שאתם מבינים איך פועלת מדיניות האבטחה. בנוסף, מומלץ להכיר את היררכיית המשאבים.
תרחישים לדוגמה
בארגונים גדולים, ניהול מדיניות האבטחה בפרויקטים רבים יכול להיות מורכב ולגזול זמן רב. כדי להתמודד עם האתגרים האלה, אתם יכולים להשתמש בכללי מדיניות אבטחה היררכיים, שמציעים את היתרונות הבאים:
- בקרה מרוכזת: אדמינים ברמת הארגון והתיקייה יכולים להגדיר ולאכוף מדיניות אבטחה בכמה פרויקטים.
- עקביות: מצב אבטחה אחיד בכל הארגון, שמפחית את הסיכון להגדרות שגויות ולפערי אבטחה.
- יעילות: ייעול הפריסה של עדכוני אבטחה ופעולות לצמצום סיכונים, כמו חסימה של טווחי כתובות IP ספציפיים או טיפול בנקודות חולשה קריטיות, במספר גדול של משאבים בו-זמנית.
- האצלת סמכויות: אפשר להאציל את האחריות על האבטחה לצוותים או למחלקות שונות, על ידי החלת כללי מדיניות ברמות המתאימות בהיררכיה.
אתם יכולים ליישם ולשלב את העקרונות הכלליים האלה בהתאם לצרכים של הארגון שלכם. הנה כמה תרחישים לדוגמה:
- חסימת כתובות IP ברמת הארגון: אתם יכולים לחסום תעבורת נתונים מטווחים של כתובות IP שידועות כזדוניות בכל הפרויקטים בארגון.
- הגבלות על סמך מיקום גיאוגרפי: אתם יכולים להגביל את התנועה מאזורים גיאוגרפיים ספציפיים ברמת הארגון או התיקייה.
- הפחתת הסיכון לפרצות אבטחה (CVE): אתם יכולים לפרוס במהירות כללי WAF כדי להפחית את הסיכון לפרצות אבטחה קריטיות בכמה פרויקטים.
- אכיפת תאימות: אתם יכולים לאכוף את הציות לדרישות הרגולטוריות על ידי החלת מדיניות אבטחה עקבית בכל הארגון.
- בקרת גישה פרטנית: אתם יכולים לתת לטווחים ספציפיים של כתובות IP או לאזורים גיאוגרפיים ספציפיים גישה לכל המשאבים בתיקייה מסוימת.
תכונות
מדיניות אבטחה היררכית תומכת בקבוצת משנה של התכונות שנתמכות במדיניות אבטחה ברמת השירות. בטבלה הבאה מוצגת השוואה בין התכונות של Cloud Armor שאפשר להשתמש בהן עם מדיניות אבטחה היררכית ומדיניות אבטחה ברמת השירות:
| סוג הקצה הקדמי |
|
|
| נקודת צירוף (משאב מוגן) | שירות לקצה העורפי | צמתים בהיררכיית המשאבים |
| פעולות של כלל |
|
|
| כתובת ה-IP של הלקוח | ||
| המיקום הגיאוגרפי של הלקוח | ||
| מספר המערכת האוטונומית (ASN) של הלקוח | ||
| הגבלת קצב של יצירת בקשות | ||
| טביעת אצבע דיגיטלית של TLS (JA3 ו-JA4) | ||
| ניהול בוטים | (רק
EXTERNAL_302 ועיטור בקשה) |
|
| סינון HTTP | ||
| סינון לפי גוף ההודעה | ||
| 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 Annual, נרשמים אוטומטית ל-Cloud Armor Enterprise Annual אם הם עדיין לא רשומים.
- בלי מינוי שנתי ל-Cloud Armor Enterprise, פרויקטים נרשמים באופן אוטומטי ל-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 שהוגדרו מראש במדיניות אבטחה היררכית שבבעלותכם, אבל הבעלים של שירותים שירשו מדיניות אבטחה היררכית לא יכולים לשנות את הכללים.