סקירה כללית של קבוצות כתובות

קבוצת כתובות מכילה כמה כתובות IP, טווחים של כתובות IP בפורמט CIDR או שילוב של שניהם. אפשר להשתמש בכל קבוצת כתובות בכמה משאבים, כמו כללים במדיניות חומת האש של Cloud NGFW או כללים במדיניות האבטחה של Cloud Armor.

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

מפרטים

למשאבי קבוצות כתובות יש את המאפיינים הבאים:

  • כל קבוצת כתובות מזוהה באופן ייחודי על ידי כתובת URL עם הרכיבים הבאים:
    • סוג המאגר: קובע את סוג קבוצת הכתובות – organization או project.
    • מזהה מאגר: מזהה הארגון או הפרויקט.
    • מיקום: מציין אם קבוצת הכתובות היא משאב global או משאב אזורי (כמו europe-west).
    • ‫Name: שם קבוצת הכתובות בפורמט הבא:
      • מחרוזת באורך 1-63 תווים
      • כולל רק תווים אלפאנומריים
      • הערך לא יכול להתחיל במספר

  • אפשר ליצור מזהה ייחודי של כתובת URL לקבוצת כתובות בפורמט הבא:

    <containerType>/<containerId>/locations/<location>/addressGroups/<address-group-name>

    לדוגמה, לקבוצת כתובות global example-address-group בפרויקט myproject יש את המזהה הייחודי הבא של 4 טופלים:

    projects/myproject/locations/global/addressGroups/example-address-group

  • לכל קבוצת כתובות יש סוג משויך שיכול להיות IPv4 או IPv6, אבל לא שניהם. אי אפשר לשנות את סוג קבוצת הכתובות בשלב מאוחר יותר.

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

  • כשיוצרים קבוצת כתובות, צריך לציין את הקיבולת והסוג שלה. בנוסף, כשמשתמשים ב-Cloud Armor, צריך להגדיר את השדה purpose לערך CLOUD_ARMOR.

  • כשיוצרים קבוצת כתובות עם מטרה שהיא לא CLOUD_ARMOR, הקיבולת המקסימלית של קבוצת הכתובות היא 1,000 כתובות IP.

סוגים של קבוצות כתובות

קבוצות של כתובות מסווגות לפי ההיקף שלהן. ההיקף מציין את הרמה שבה קבוצת הכתובות רלוונטית בהיררכיית המשאבים. קבוצות כתובות מחולקות לסוגים הבאים:

קבוצת כתובות יכולה להיות בהיקף פרויקט או בהיקף ארגון, אבל לא בשניהם.

קבוצות של כתובות בהיקף הפרויקט

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

סוג המאגר של קבוצות כתובות בהיקף הפרויקט תמיד מוגדר לproject. מידע נוסף על יצירה ושינוי של קבוצות כתובות בהיקף הפרויקט זמין במאמר שימוש בקבוצות כתובות בהיקף הפרויקט.

קבוצות כתובות בהיקף הארגון

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

סוג מאגר התגים של קבוצות כתובות בהיקף הארגון תמיד מוגדר לorganization. מידע נוסף על יצירה ושינוי של קבוצות כתובות בהיקף הארגון זמין במאמר בנושא שימוש בקבוצות כתובות בהיקף הארגון.

איך קבוצות של כתובות עובדות עם מדיניות אבטחה

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

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

מומלץ לעיין במכסות ובמגבלות של קבוצות כתובות.

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

דוגמאות

בדוגמאות הבאות אפשר לראות איך אפשר להשתמש בקבוצות של כתובות כדי להגדיר מדיניות אבטחה:

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

המאמרים הבאים