שיטות מומלצות לשימוש בתגים מאובטחים ב-Cloud NGFW

במסמך הזה מפורטות שיטות מומלצות לארכיטקטורה של תגי אבטחה ב-Cloud Next Generation Firewall ‏(Cloud NGFW), כדי לעזור לכם לתכנן, לנהל ולאכוף אותם. תגי אבטחה מספקים גישה מבוססת-זהויות לאבטחת רשת, על ידי שיוך של הערכת כללי חומת האש לזהויות של עומסי עבודה של מכונות וירטואליות, במקום לכתובות IP דינמיות. תגי אבטחה הם תכונה בסיסית שכלולה בחבילת Cloud Next Generation Firewall Essentials, והם נתמכים בכל חבילות Cloud NGFW. המדריך הזה מיועד לאדריכלי רשת, לאדמינים של אבטחה ולמהנדסי DevOps שמתכננים ומנהלים כללי מדיניות של אבטחת רשת בענן.

במסמך הזה מפורטות שיטות מומלצות שמחולקות לארבעה שלבים מרכזיים במחזור החיים של תג מאובטח:

  1. תכנון סכימת התגים: התאמת התגים לזהויות של עומסי עבודה, הגדרת פילוח מיקרו ושמירה על תגים גסים כדי להימנע מחריגה ממגבלות המכסה של תגים מאובטחים.
  2. הגדרת בקרת גישה וניהול: הגדרת הפרדה בין תפקידים בניהול זהויות וגישה (IAM), בחירת היקפים מתאימים ואכיפת תגים במהלך הקצאת מכונות וירטואליות.
  3. תכנון מדיניות חומת אש ולוגיקת כללים: אופטימיזציה של הערכת כללים, הגדרה של מדיניות היררכית והטמעה של כללי ברירת מחדל בטוחים של דחיית גישה.
  4. הגנה, מעקב וביקורת: מונעים מחיקה מקרית באמצעות השהיות של תגים, מפעילים רישום ביומן של חומת האש ומבצעים ביקורות גישה באופן קבוע.

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

סיכום השיטות המומלצות

בטבלה הבאה מפורטות שיטות מומלצות מרכזיות לאורך מחזור החיים של תג מאובטח:

שלב במחזור החיים המלצה מרכזית תיאור
עיצוב סכימת התגים התאמת תגים ל-Workload Identity מגדירים מפתחות תגים לפי תפקיד בעומס העבודה (למשל env/prod או tier/database), אוכפים ערכים שאינם חופפים ושומרים על תגים גסים כדי לא לחרוג ממגבלות המכסה.
בקרת גישה ומשילות אכיפה של הפרדת תפקידים מקצים את התפקיד roles/resourcemanager.tagAdmin רק לצוותי אבטחה, מגבילים את התפקיד roles/resourcemanager.tagUser לצינורות פריסה ובוחרים את ההיקף הנכון (organization=auto לעומת network).
VM provisioning החלת תגים בזמן היצירה אפשר לקשר תגים מאובטחים לממשקי רשת של מכונות וירטואליות במהלך הקצאת המשאבים, ולהשתמש במדיניות הארגון כדי לדרוש תגים בכל המקרים החדשים.
ארכיטקטורת המדיניות ציון תגי יעד מאובטחים משתמשים בתגי אבטחה של טירגוט בכללי חומת האש כדי להעריך את הביצועים של נכסים סטטיים. כדי להגן על משאבים לא מתויגים, צריך להגדיר כללים של דחייה כברירת מחדל במדיניות היררכית.
אבטחה במספר רשתות קישוריות מאובטחת בין עננים וירטואליים פרטיים (VPC) שמירה על גבולות הזהויות ברשתות VPC שכנות (peering) ובמרכזי קישוריות לרשת (NCC) ללא ניהול של בלוקים סטטיים של CIDR.
הגנה ומעקב הגנה על תגים ומעקב אחריהם כדאי להחיל השהיות של תגים כדי למנוע מחיקה בטעות, להפעיל רישום ביומן של כללי חומת אש לצורך פתרון בעיות ולבדוק את הקצאות ה-IAM באופן קבוע.

עיצוב סכימת התגים

סכימת תגים מובנית היטב מפשטת את כללי חומת האש, מייעלת את ביקורות האבטחה ומונעת מדיניות סותרת.

התאמת תגים ל-Workload Identity

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

  • רמת הסביבה: env/prod, ‏ env/staging, ‏ env/dev
  • רמת האפליקציה: tier/frontend, tier/backend, tier/database
  • סטטוס התאימות: scope/pci-dss, scope/hipaa

דוגמה: מיקרו-פילוח של אפליקציה בשלוש רמות

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

[ Web Tier (tag: tier/frontend) ]
              |
              |  Allow port 8080 (Web can communicate with App)
              v
[ App Tier (tag: tier/backend) ]
              |
              |  Allow port 5432 (App can communicate with DB)
              v
[ Database Tier (tag: tier/database) ]

כדי לאכוף את התהליך הזה, צריך להגדיר שני כללים במדיניות חומת האש:

  1. כלל 1 (אינטרנט לאפליקציה): לאפשר תעבורה נכנסת ביציאה 8080 כשהתג של המקור הוא tier/frontend והתג של היעד הוא tier/backend.
  2. כלל 2 (אפליקציה למסד נתונים): מאפשר כניסה ביציאה 5432 כשהתג של המקור הוא tier/backend והתג של היעד הוא tier/database.

תוצאה: חזית ה-Web לא יכולה לתקשר ישירות עם שכבת מסד הנתונים כי אין כלל חומת אש שמאפשר תעבורת נתונים בין tier/frontend ל-tier/database. ‫Cloud NGFW אוכף את הגבול הזה באופן אוטומטי, גם אם מכונות וירטואליות חולקות את אותה רשת משנה של כתובות IP.

העברה מתגים של רשתות לתגים מאובטחים

כשמשדרגים מתגי רשת VPC לתגי אבטחה של חומת אש, חשוב לשים לב להבדלים הבאים בארכיטקטורה:

יכולת תגי רשת (כללי VPC) תגים מאובטחים (מדיניות חומת אש)
מפרט היעד targetTags = ["web-tier"] targetSecureTags = ["tagValues/1234567890"]
מפרט המקור sourceTags = ["db-client"] sourceSecureTags = ["tagValues/0987654321"]
היקף האכיפה רשת VPC יחידה בלבד בין רשתות VPC שכנות, רכזות (spokes) של NCC ומדיניות היררכית
תמיכה בתכנון מסלול אפשר להשתמש בתגי רשת כצעדים הבאים במסלולים סטטיים (נקראים גם תגי מסלול) אי אפשר להשתמש בתגים מאובטחים לניתוב. כדאי להשתמש בהם רק לסינון תנועה בחומת אש.
בקרת גישה אין הרשאות IAM לתגים ספציפיים תפקידים ב-מנהל המשאבים וב-IAM שולטים באופן מוחלט בגישה לתגים ובקישור שלהם

החלת ערכי תגים ייחודיים

מוודאים שלכל משאב יש רק ערך אחד לכל מפתח תג. לדוגמה, למכונה וירטואלית צריך להקצות את env/prod או את env/dev, אבל לא את שניהם:

  • מומלץ: להקצות תג סביבה יחיד (env/prod) ולאפשר גישה לשירותים משותפים באמצעות כללים מפורשים של חומת אש שמפנים לתגי יעד (כמו env/shared-logging).

  • לא: אל תציבו כמה תגי סביבה (env/prod ו-env/dev) באותה מכונה וירטואלית. הפעולה הזו מאפשרת למכונה הווירטואלית להתאים לכללים של חומת האש של הפיתוח, וכך משאבי הייצור נחשפים לתעבורת נתונים של מפתחים.

כדי לא לחרוג מהמכסות, כדאי להשתמש בתגים גסים

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

כשמתכננים את סכימת התגים, חשוב לעיין במגבלות הבאות:

שימוש בתגים במקום בחשבונות שירות למכונות וירטואליות עם כמה כרטיסי רשת

מומלץ להשתמש בתגי אבטחה במקום בחשבונות שירות כמקורות או כיעדים במדיניות חומת האש. בניגוד לחשבונות שירות, אפשר לקשר תגים מאובטחים ישירות לממשקי רשת (vNIC) של מכונה וירטואלית עם כמה כתובות IP. הגישה הזו מאפשרת לאכוף כללי מדיניות שונים של רשת על כל ממשק רשת.

הגדרת בקרת גישה ופיקוח

מערכת IAM שולטת בתגים מאובטחים כדי לספק בקרת גישה קפדנית והפרדת תפקידים ברורה.

הפרדת תפקידים באמצעות תפקידי IAM

הגדרת גבול תפעולי בין האדמינים שיוצרים תגים לבין הצוותים שמקצים עומסי עבודה:

  • אדמין תגים (roles/resourcemanager.tagAdmin): הרשאה שניתנת באופן בלעדי לאדמינים מרכזיים של רשתות ואבטחה כדי ליצור, לערוך ולמחוק מפתחות וערכים של תגים.
  • ‫Tag User (roles/resourcemanager.tagUser): הרשאה שניתנת לצינורות אוטומטיים של פריסת CI/CD או לחשבונות שירות להקצאת משאבים בהיקפים ספציפיים של פרויקטים או משאבים, כדי לקשר תגים לממשקי רשת של מכונות וירטואליות.
  • Tag Viewer (צפייה בתגים) (roles/resourcemanager.tagViewer): הרשאה שניתנת לצוותי תפעול וביקורת שזקוקים להרשאת קריאה בלבד להגדרות התגים.

מניעת תיוג עצמי והסלמת הרשאות

  • מומלץ: להעניק את ההרשאה roles/resourcemanager.tagUser באופן בלעדי לצינורות פריסה של תשתית כקוד (IaC) שעברו ביקורת (כמו תהליכי עבודה של google_tags_tag_binding Terraform) ברמת הפרויקט או ברמת ממשק הרשת.
  • לא: לא מעניקים את ההרשאה roles/resourcemanager.tagUser לקבוצות מפתחים באופן נרחב ברמת הארגון. כך מפתחים לא יכולים לצרף בעצמם תגי ייצור (כמו env/prod) לעומסי עבודה לא מורשים של פיתוח.

הגדרת היקף למפתחות תגים בצורה מתאימה

הגדרת מפתחות תגים מאובטחים ברמה של היררכיית המשאבים שתואמת למדיניות התפעולית שלכם:

  • תגים בהיקף הארגון (purpose-data=organization=auto): הגדרת מפתחות ברמת הארגון או התיקייה לניהול אבטחה מרכזי במספר רשתות VPC, רשתות מקושרות ומדיניות חומת אש היררכית.
  • תגים בהיקף הרשת (purpose-data=network): לשימוש רק בבידוד ברמת הפרויקט, שבו התגים חייבים להיות מוגבלים באופן קבוע לרשת VPC אחת.

אכיפת הקצאת תגים במהלך יצירת מכונות וירטואליות

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

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

תכנון של כללי מדיניות לחומת אש והלוגיקה של הכללים

כדי לשפר את הערכת הכללים ולשמור על הגנה עקבית, כדאי לשלב תגים מאובטחים במדיניות חומת האש.

שימוש במדיניות חומת אש היררכית לאכיפה מרכזית

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

ציון תגי אבטחה ליעד היעילות

כשיוצרים כללים למדיניות חומת אש, מומלץ לציין תגי אבטחה של יעד (targetSecureTags) בכל הזדמנות. מערכת Cloud NGFW מעריכה תגי יעד ותגי מקור באופן שונה:

  • טירגוט תגים מאובטחים (התאמה סטטית): כללים עם תגי יעד חלים באופן סטטי רק על מכונות וירטואליות שכוללות את התגים האלה. כך מצמצמים את מספר הכללים שנבדקים בכל מכונה וירטואלית ומשפרים את הביצועים.

  • תגי מקור מאובטחים (התאמה דינמית לכל חיבור): כללים שמציינים רק תגי מקור (sourceSecureTags) ללא תגי יעד מוערכים באופן דינמי לכל חיבור בכל מכונות ה-VM ברשת, מה שמגדיל את תקורה העיבוד.

הטמעה של ברירות מחדל בטוחות באמצעות היררכיית ברירות מחדל של דחייה

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

  1. כלל ברירת מחדל של דחייה: יוצרים כלל בעדיפות נמוכה (לדוגמה, עדיפות 65000) ברמת הארגון או התיקייה שדוחה את כל התנועה כברירת מחדל.

  2. כללים להתרה בתנאי: יוצרים כללים בעדיפות גבוהה יותר שמתירים תנועה רק בין תגים מאובטחים ספציפיים (למשל, tier/frontend ל-tier/backend).

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

שימוש בתגים מאובטחים ברשתות שכנות וב-NCC

שימוש בתגים מאובטחים כדי לשלוט בתעבורה בין רשתות VPC שמקושרות באמצעות קישור בין רשתות שכנות (peering) של VPC או רשתות מסוג Hub and Spoke של NCC. תגים מאובטחים שומרים על גבולות שמודעים לזהות ברשתות מחוברות, בלי שתצטרכו לנהל שינויים בבלוקים של CIDR.

הגנה, מעקב וביקורת

אמצעי בקרה תפעוליים רציפים מבטיחים שהגדרות התגים המאובטחים שלכם יישארו מאובטחות ועמידות.

הגנה על ערכי תגים קריטיים באמצעות השהיות תגים

איך למנוע השבתות לא מכוונות שמתרחשות כשמוחקים תגים שנמצאים בשימוש:

  • כדי למנוע מחיקה, אפשר להחיל השהיות תגים על ערכים קריטיים של תגים מאובטחים.
  • לפני שמנתקים את התג Secure מממשקי הרשת של המכונה הווירטואלית, צריך לוודא שאין כללים פעילים של חומת אש שמסתמכים עליו. כדי למחוק ערך של תג מאובטח, צריך להסיר את כל הקישורים למשאבים (ואת כל ההחזקות של התגים). Google Cloud

הפעלת רישום ביומן של כללים לחומת אש

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

ביצוע ביקורת באופן קבוע על הקצאות של תפקידים ב-IAM

חשוב לבדוק מעת לעת את ההקצאות של חשבונות משתמשים ל-roles/resourcemanager.tagAdmin ול-roles/resourcemanager.tagUser. הביקורת הזו מוודאת שרק לצינורות מורשים יש הרשאות לקישור תגים, וכך מונעת הסלמת הרשאות ושומרת על בידוד הסביבה.

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