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

Last reviewed 2025-01-30 UTC

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

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

שטחי אבטחה

כשמעצבים את שכבת האבטחה של 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 מספקת אפשרויות גמישות להוספת מכשירי NVA.

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

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

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

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

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

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

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

בתכנון שמתואר במאמר קישור בין רשתות VPC לשימוש בשירותים מרכזיים, רשת ה-VPC המרכזית משמשת כמרכז לרשתות ה-VPC המשניות שמקושרות אליה באמצעות קישור בין רשתות שכנות (peering) של 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.

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

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

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

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

כשנדרשים אזורים מבוססי-ממשק בחומת אש, העיצוב הבא של כרטיסי רשת מרובים (multi-NIC) מאפשר את הקישוריות החיצונית הנדרשת. בארכיטקטורה הזו מוקצים ממשקי חומת אש שונים לרשתות החיצוניות. אנשי מקצוע בתחום האבטחה מתייחסים לרשתות חיצוניות כאל רשתות לא מהימנות, ולרשתות פנימיות כאל רשתות מהימנות. בפריסת 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 עם כמה כרטיסי NIC שמוכנסים בין רשתות ה-VPC הלא מהימנות והמהימנות בפרויקט המרכזי:

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

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

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

מחברים:

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