אבטחת רשת לאפליקציות מבוזרות ב-Cross-Cloud Network

Last reviewed 2025-01-30 UTC

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

הסדרה מורכבת מהחלקים הבאים:

שטחי אבטחה

כשמעצבים את שכבת האבטחה של Cross-Cloud Network, צריך להתייחס לנקודות הבאות:

  • אבטחת עומסי עבודה
  • אבטחת גבולות הגזרה של הדומיין

אמצעי הבקרה על אבטחת עומסי העבודה שולטים בתקשורת בין עומסי עבודה ברשת הענן הווירטואלי הפרטי (VPC) ובתוכה. אבטחת עומסי עבודה משתמשת בנקודות לאכיפת אבטחה שקרובות לעומסי העבודה בארכיטקטורה. ככל האפשר, Cross-Cloud Network מספק אבטחה לעומסי עבודה באמצעות Cloud Next Generation Firewall מ- Google Cloud.

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

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

היכולת להוסיף מכשירים וירטואליים לרשת (NVA) של צד שלישי בסביבתGoogle Cloud היא חיונית כדי לעמוד בדרישות של אבטחת היקף ברשתות היברידיות.

אבטחת עומסי עבודה בענן

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

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

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

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

כדי להשיג אמצעי בקרה מפורטים יותר שנאכפים ברמת המכונה הווירטואלית (VM), מומלץ להשתמש בתגים שמנוהלים על ידי ניהול זהויות והרשאות גישה (IAM) ברמת הארגון או הפרויקט. תגים שמנוהלים על ידי IAM מאפשרים להחיל כללי חומת אש על סמך הזהות של מארח עומס העבודה, ולא על סמך כתובת ה-IP של המארח. התגים האלה פועלים גם בקישור בין רשתות שכנות של VPC. כללי חומת אש שנפרסים באמצעות תגים יכולים לספק מיקרו-פילוח בתוך רשת משנה עם כיסוי מדיניות שמוחל באופן אוטומטי על עומסי עבודה, בכל מקום שבו הם נפרסים, ללא קשר לארכיטקטורת הרשת.

בנוסף ליכולות של בדיקה עם שמירת מצב ולתמיכה בתגים, Cloud Next Generation Firewall תומכת גם בסינון לפי מודיעין איומי סייבר, FQDN ומיקום גאוגרפי.

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

אבטחת גבולות גזרה בענן

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

רשת Cross-Cloud Network מיועדת להיות המרכז של כל התקשורת, ולכן אפשר לאחד ולרכז את אמצעי בקרת האבטחה ההיקפית ולפרוס קבוצה אחת של חומות אש היקפיות ברשת Cross-Cloud Network. כדי לספק חבילת אבטחה מובנית של גבולות גזרה, Cross-Cloud Network מספקת אפשרויות גמישות להוספת NVAs.

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

אפשר לפרוס NVAs בממשק רשת יחיד (מצב NIC יחיד) או בכמה ממשקי רשת בכמה רשתות VPC (מצב multi-NIC). במקרה של Cross-Cloud Network, מומלץ להשתמש בפריסה של NVA עם כרטיס רשת יחיד, כי האפשרות הזו מאפשרת לכם:

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

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

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

בנוסף, העיצוב הזה מאפשר את מנגנוני העמידות שנדרשים על ידי מכשירי ה-NVA. מכשירי ה-NVA ממוקמים לפני מאזן עומסים פנימי מסוג TCP/UDP כדי לאפשר יתירות של NVA, שינוי גודל אוטומטי (autoscaling) לקיבולת גמישה וסימטריה של זרימת הנתונים לתמיכה בעיבוד תנועה דו-כיוונית עם שמירת מצב.

אבטחה היקפית של NVA עם כרטיס רשת יחיד

בתכנון שמתואר במאמר קישור בין רשתות שכנות של VPC לשירותים מרכזיים, רשת ה-VPC המרכזית משמשת כמרכז לרשתות ה-VPC המשניות שמקושרות אליה באמצעות קישור בין רשתות שכנות של VPC ו-HA VPN. בנוסף, רשת ה-VPC המעברית מאפשרת קישוריות בין הרשתות החיצוניות לבין רשתות ה-VPC המקושרות.

לצורך הוספת NVA עם כרטיס רשת יחיד, העיצוב הזה משלב את שני הדפוסים הבאים:

  • הוספת מכשירי NVA במרכז של קישור בין רשתות VPC שכנות עם חיבורים חיצוניים היברידיים
  • הוספת מכשירי NVA במרכז HA VPN VPC עם חיבורים היברידיים חיצוניים

בתרשים הבא מוצגים מכשירי NVA שהוכנסו למרכזים של קישור בין רשתות VPC שכנות (peering) ו-HA VPN:

מכשירי NVA שמוכנסים לרכזות לקישור בין רשתות VPC שכנות (peering) ול-HA VPN

התרשים שלמעלה ממחיש דפוס משולב:

  • רשת VPC למעבר נתונים שמארחת את קובצי ה-VLAN של Cloud Interconnect שמספקים קישוריות היברידית או מרובת עננים. ה-VPC הזה מכיל גם את מכשירי ה-NVA עם כרטיס רשת יחיד שמנטרים את החיבורים ההיברידיים.
  • רשתות VPC של אפליקציות שמחוברות לרשת ה-VPC המרכזית באמצעות קישור בין רשתות VPC שכנות (peering).
  • רשת VPC של שירותים מרכזיים שמחוברת לרשת ה-VPC של התנועה דרך HA VPN.

בתכנון הזה, ה-spokes שמחוברים באמצעות HA VPN משתמשים ב-VPC המרכזי כדי לתקשר עם ה-spokes שמחוברים באמצעות קישור בין רשתות VPC שכנות. התקשורת מנותבת דרך חומות האש של NVA של צד שלישי באמצעות השילוב הבא של איזון עומסים של העברת נתונים, מסלולים סטטיים ומסלולים מבוססי-מדיניות:

  1. כדי להפנות את תעבורת הנתונים של HA VPN למאזן העומסים הפנימי, צריך להחיל נתיבים מבוססי-מדיניות לא מתויגים על רשת ה-VPC המרכזית. במסלולים מבוססי-מדיניות האלה, צריך להשתמש בטווחי CIDR של מקור ויעד שמספקים סימטריה של התנועה.
  2. כדי להפנות תעבורה נכנסת למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, צריך להחיל מסלולים מבוססי-מדיניות על חיבורי Cloud Interconnect ב-Transit VPC. אלה מסלולים אזוריים.
  3. כדי שהתנועה שיוצאת מ-NVA לא תנותב ישירות בחזרה ל-NVA, צריך להגדיר את כל הממשקים של NVA כיעד של skip-policy-based route כדי לדלג על נתיבים אחרים שמבוססים על מדיניות. אחרי שהתנועה עוברת עיבוד על ידי מכשירי ה-NVA, היא פועלת לפי טבלת הניתוב של ה-VPC.
  4. כדי להפנות תעבורה למאזני העומסים הפנימיים של NVA ב-Transit VPC, צריך להחיל מסלולים סטטיים על ה-VPC של האפליקציה. אפשר להגדיר את ההיקף שלהם לפי אזור באמצעות תגי רשת.

אבטחה היקפית של NVA עם כמה כרטיסי NIC

במצב multi-NIC, הטופולוגיה סטטית יותר כי מכשירי NVA מגשרים על הקישוריות בין רשתות ה-VPC השונות שבהן נמצאים ממשקי הרשת השונים.

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

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

בארכיטקטורה הזו, מוסיפים מכשירי NVA על ידי הגדרת הפרטים הבאים:

  1. כדי להפנות את תעבורת הנתונים של HA VPN למאזן העומסים הפנימי, צריך להחיל נתיבים מבוססי-מדיניות לא מתויגים על ה-VPC המהימן. במסלולים מבוססי-מדיניות האלה, צריך להשתמש בטווחי CIDR של מקור ויעד שמספקים סימטריה של התנועה.
  2. כדי להפנות תעבורה נכנסת למאזן עומסי רשת פנימיים להעברת סיגנל ללא שינוי, צריך להחיל נתיבים מבוססי-מדיניות על חיבורי Cloud Interconnect ב-VPC הלא מהימן. אלה מסלולים אזוריים.
  3. כדי שהתנועה שיוצאת מ-NVA לא תנותב ישירות בחזרה ל-NVA, צריך להגדיר את כל הממשקים של NVA כיעד של skip-policy-based route כדי לדלג על נתיבים אחרים שמבוססים על מדיניות. אחרי שהתנועה עוברת עיבוד על ידי מכשירי ה-NVA, היא פועלת לפי טבלת הניתוב של ה-VPC.
  4. כדי להפנות תעבורה למאזני עומסים פנימיים של NVA ב-VPC המהימן, צריך להחיל מסלולים סטטיים על ה-VPC של האפליקציה. אפשר להגדיר את ההיקף שלהם לפי אזור באמצעות תגי רשת.

התרשים הבא מציג מכשירי NVA עם כמה כרטיסי רשת שמוכנסים בין רשתות ה-VPC הלא מהימנות והמהימנות בפרויקט המרכזי:

ממשקי NVA לתקשורת פנימית

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

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: