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

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

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

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

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

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

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

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

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

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

  • הוספת מכשירי NVA במרכז של קישור בין רשתות VPC שכנות (peering) עם חיבורים חיצוניים היברידיים
  • הוספת מכשירי 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.

בתכנון הזה, הרשתות מסוג Hub & Spoke שמחוברות באמצעות HA VPN משתמשות ב-VPC המעבר כדי לתקשר עם הרשתות מסוג Hub & Spoke שמחוברות באמצעות קישור בין רשתות שכנות (peering) של VPC. התקשורת מנותבת דרך חומות האש של NVA של צד שלישי באמצעות השילוב הבא של איזון עומסים מסוג passthrough, מסלולים סטטיים ומסלולים מבוססי-מדיניות:

  1. כדי להפנות את התעבורה ב-HA VPN למאזן העומסים הפנימי, צריך להחיל נתיבים מבוססי-מדיניות לא מתויגים על רשת ה-VPC של ה-Transit. בנתיבים מבוססי-המדיניות האלה, צריך להשתמש בטווחים של CIDR של מקור ויעד שמספקים סימטריה של התעבורה.
  2. כדי להפנות תעבורת נתונים נכנסת למאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי, צריך להחיל נתיבים מבוססי-מדיניות על חיבורי Cloud Interconnect ב-VPC של רשת המעבר. אלה מסלולים אזוריים.
  3. כדי שהתנועה שיוצאת מ-NVA לא תנותב ישירות בחזרה ל-NVA, צריך להגדיר את כל הממשקים של NVA כיעד של מסלול מבוסס-מדיניות עם דילוג כדי לדלג על מסלולים אחרים מבוססי-מדיניות. לאחר מכן, התנועה תפעל לפי טבלת הניתוב של VPC אחרי שהיא תעבור עיבוד על ידי NVAs.
  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 כיעד של מסלול מבוסס-מדיניות עם דילוג כדי לדלג על מסלולים אחרים מבוססי-מדיניות. לאחר מכן, התנועה תפעל לפי טבלת הניתוב של VPC אחרי שהיא תעבור עיבוד על ידי NVAs.
  4. כדי להפנות תעבורה למאזני עומסים פנימיים של NVA ב-VPC המהימן, צריך להחיל נתיבים סטטיים על רשתות ה-VPC של האפליקציה. אפשר להגדיר את ההיקף שלהם לפי אזור באמצעות תגי רשת.

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

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

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

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

מחברים:

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