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

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

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

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

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

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

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

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

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

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

מחברים:

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