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

קבוצת כתובות מכילה כמה כתובות 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 המורשות צריכה לגשת אליה.

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