כחלק מאסטרטגיית ההגנה המעמיקה של הארגון, יכול להיות שיש לכם מדיניות אבטחה שמחייבת שימוש במכשירי רשת מרכזיים לזיהוי וחסימה של פעילות חשודה ברשת. המסמך הזה יעזור לכם לתכנן את התכונות המתקדמות הבאות להגנה על רשתות עבור עומסי עבודה ב-Google Cloud VMware Engine:
- צמצום ההשפעה של התקפות מניעת שירות מבוזרות (DDoS)
- העברת עומס של SSL
- חומות אש מהדור הבא (NGFW)
- מערכת למניעת פריצות (IPS) ומערכת לגילוי חדירות (IDS)
- בדיקה מעמיקה של מנות (DPI)
הארכיטקטורות במסמך הזה משתמשות ב-Cloud Load Balancing ובמכשירי רשת מ-Google Cloud Marketplace. ב-Cloud Marketplace יש מכשירי רשת שמוכנים לייצור ומקבלים תמיכה מהספקים, משותפי אבטחה, כדי לענות על צורכי ה-IT של הארגון. Google Cloud
ההנחיות במסמך הזה מיועדות לאדריכלי אבטחה ולמנהלי רשתות שתפקידם לתכנן, להקצות ולנהל את הקישוריות של הרשת לעומסי עבודה של VMware Engine. המסמך מיועד למי שמכיר את ענן וירטואלי פרטי (VPC), VMware vSphere, VMware NSX, תרגום כתובת רשת (NAT) ו-Cloud Load Balancing.
ארכיטקטורה
בתרשים הבא מוצגת ארכיטקטורה לקישוריות רשת לעומסי עבודה של VMware Engine מרשתות מקומיות ומאינטרנט. בהמשך המסמך, הארכיטקטורה הזו מורחבת כדי לעמוד בדרישות של תרחישי שימוש ספציפיים.
באיור 1 מוצגים הרכיבים העיקריים הבאים של הארכיטקטורה:
- ענן פרטי של VMware Engine: סטאק מבודד של VMware שמורכב ממכונות וירטואליות (VM), אחסון, תשתית רשת ו-VMware vCenter Server. VMware NSX-T מספק תכונות של רשת ואבטחה, כמו מיקרו-פילוח ומדיניות חומת אש. מכונות ה-VM ב-VMware Engine משתמשות בכתובות IP מפלחים ברשת שאתם יוצרים בענן הפרטי.
- שירות כתובות IP ציבוריות: מספק כתובות IP חיצוניות למכונות וירטואליות ב-VMware Engine כדי לאפשר גישה נכנסת מהאינטרנט. שער האינטרנט מספק גישה ליציאה כברירת מחדל למכונות וירטואליות של VMware Engine.
- רשת VPC בדייר VMware Engine: רשת VPC ייעודית שמנוהלת על ידי Google ומשמשת עם כל ענן פרטי של VMware Engine כדי לאפשר תקשורת עםGoogle Cloud שירותים.
רשתות VPC של לקוחות:
- רשת VPC של לקוח 1 (חיצונית): רשת VPC שמארחת את הממשק הציבורי של מכשיר הרשת ומאזן העומסים.
- רשת VPC של לקוח 2 (פנימית): רשת VPC שמארחת את הממשק הפנימי של מכשיר הרשת ומקושרת לרשת ה-VPC של דייר VMware Engine באמצעות מודל הגישה לשירותים פרטיים.
גישה לשירותים פרטיים: מודל גישה פרטית שמשתמש בקישור בין רשתות VPC שכנות (peering) כדי לאפשר קישוריות בין שירותים שמנוהלים על ידי Google לבין רשתות ה-VPC שלכם.
מכשירי רשת: תוכנות רשת שבוחרים מ-Cloud Marketplace ופורסים במכונות Compute Engine.
Cloud Load Balancing: שירות מנוהל של Google שמאפשר לכם לנהל את התנועה לעומסי עבודה מבוזרים עם זמינות גבוהה ב- Google Cloud. אתם יכולים לבחור סוג של איזון עומסים שמתאים לפרוטוקול התנועה ולדרישות הגישה שלכם. הארכיטקטורות במסמך הזה לא משתמשות במאזני העומסים המובנים של NSX-T.
הערות לגבי ההגדרה
בתרשים הבא מוצגים המשאבים שנדרשים כדי לספק קישוריות לרשת עבור עומסי עבודה של VMware Engine:
באיור 2 מוצגות המשימות שצריך לבצע כדי להגדיר את המשאבים בארכיטקטורה הזו. בהמשך מופיע תיאור של כל משימה, כולל קישור למסמך עם מידע נוסף והוראות מפורטות.
יוצרים את רשתות ה-VPC החיצוניות והפנימיות ואת תת-הרשתות לפי ההוראות במאמר יצירת רשת VPC במצב מותאם אישית.
- לכל רשת משנה, בוחרים טווח כתובות IP שהוא ייחודי ברשתות ה-VPC.
- רשת ה-VPC לניהול שמוצגת בתרשים הארכיטקטורה היא אופציונלית. במקרה הצורך, אפשר להשתמש בו כדי לארח ממשקי כרטיס רשת לניהול עבור מכשירי הרשת.
פורסים את מכשירי הרשת הנדרשים מ-Cloud Marketplace.
כדי להבטיח זמינות גבוהה של מכשירי הרשת, צריך לפרוס כל מכשיר בזוג מכונות וירטואליות שמופצות על פני שני אזורים.
אפשר לפרוס את מכשירי הרשת בקבוצות של מופעים. קבוצות המופעים יכולות להיות קבוצות מופעים מנוהלות (MIG) או קבוצות מופעים לא מנוהלות, בהתאם לדרישות הניהול או התמיכה של הספק.
מגדירים את ממשקי הרשת באופן הבא:
-
nic0ברשת ה-VPC החיצונית כדי לנתב תנועה למקור הציבורי. -
nic1לפעולות ניהול, אם ספק המכשיר דורש זאת. -
nic2ברשת ה-VPC הפנימית לתקשורת פנימית עם משאבי VMware Engine.
פריסת ממשקי הרשת ברשתות VPC נפרדות עוזרת להבטיח הפרדה של אזורי אבטחה ברמת הממשק לחיבורים ציבוריים ולחיבורים בארגון.
-
מגדירים את VMware Engine:
- יוצרים ענן פרטי ב-VMware Engine.
- יוצרים פלח רשת למכונות הווירטואליות ב-VMware Engine.
כדי להגדיר קישור בין רשתות VPC שכנות (peering) ולחבר את רשת ה-VPC הפנימית לרשת ה-VPC שמנוהלת על ידי VMware Engine, צריך להשתמש בגישה לשירותים פרטיים.
אם אתם צריכים קישוריות היברידית לרשת המקומית, תוכלו להשתמש ב-Cloud VPN או ב-Cloud Interconnect.
אפשר להרחיב את הארכיטקטורה באיור 2 לתרחישי השימוש הבאים:
| תרחיש לדוגמה | מוצרים ושירותים בשימוש |
|---|---|
| NGFW for public-facing VMware Engine workloads |
|
| NGFW, DDoS mitigation, SSL offloading ורשת להעברת תוכן (CDN) לעומסי עבודה של VMware Engine שפונים לציבור |
|
| NGFW לתקשורת פרטית בין עומסי עבודה של VMware Engine לבין מרכזי נתונים מקומיים או ספקי ענן אחרים |
|
| נקודות יציאה מרכזיות לאינטרנט עבור עומסי עבודה של VMware Engine |
|
בקטעים הבאים מתוארים תרחישי השימוש האלה ומוצגת סקירה כללית של משימות ההגדרה שצריך לבצע כדי ליישם את תרחישי השימוש.
NGFW לעומסי עבודה שפונים לציבור
התרחיש לדוגמה הזה מחייב את הדרישות הבאות:
- ארכיטקטורה היברידית שמורכבת ממופעי VMware Engine ו-Compute Engine, עם מאזן עומסים L4 כקצה קדמי משותף.
- הגנה על עומסי עבודה ציבוריים של VMware Engine באמצעות פתרון IPS/IDS, NGFW, DPI או NAT.
- יותר כתובות IP ציבוריות ממה שנתמך על ידי שירות כתובות ה-IP הציבוריות של VMware Engine.
בתרשים הבא מוצגים המשאבים שנדרשים להקצאת NGFW לעומסי העבודה של VMware Engine שפונים לציבור:
באיור 3 מוצגות המשימות שצריך לבצע כדי להגדיר את המשאבים בארכיטקטורה הזו. בהמשך מופיע תיאור של כל משימה, כולל קישור למסמך עם מידע נוסף והוראות מפורטות.
הקצאת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ברשת ה-VPC החיצונית כנקודת הכניסה של תעבורת נתונים נכנסת שפונה לציבור עבור עומסי עבודה של VMware Engine.
- כדי לתמוך בכמה עומסי עבודה של VMware Engine, צריך ליצור כמה כללי העברה.
- מגדירים לכל כלל העברה כתובת IP ייחודית ומספר יציאת TCP או UDP.
- מגדירים את מכשירי הרשת כקצוות עורפיים למאזן העומסים.
מגדירים את מכשירי הרשת לבצע NAT של כתובת היעד (DNAT) עבור כתובת ה-IP הציבורית של כלל ההעברה, לכתובות ה-IP הפנימיות של המכונות הווירטואליות שמארחות את האפליקציות שפונות לציבור ב-VMware Engine.
- התקני הרשת צריכים לבצע NAT של כתובת המקור (SNAT) לתנועה מממשק
nic2כדי להבטיח נתיב חזרה סימטרי. - בנוסף, מכשירי הרשת צריכים לנתב תנועה שמיועדת לרשתות VMware Engine דרך הממשק
nic2לשער של רשת המשנה (כתובת ה-IP הראשונה של רשת המשנה). - כדי שבדיקות תקינות יעברו בהצלחה, מכשירי הרשת צריכים להשתמש בממשקי משנה או בממשקי לולאה חוזרת כדי להגיב לכתובות ה-IP של כללי ההעברה.
- התקני הרשת צריכים לבצע NAT של כתובת המקור (SNAT) לתנועה מממשק
מגדירים את טבלת הניתוב של רשת ה-VPC הפנימית להעברת תעבורת נתונים של VMware Engine לקישור בין רשתות VPC כצעד הבא.
בהגדרה הזו, המכונות הווירטואליות ב-VMware Engine משתמשות בשירות שער האינטרנט של VMware Engine כדי לצאת למשאבי אינטרנט. עם זאת, תעבורת הנתונים הנכנסת (ingress) מנוהלת על ידי מכשירי הרשת עבור כתובות ה-IP הציבוריות שממופות למכונות הווירטואליות.
NGFW, צמצום של DDoS, SSL offloading ו-CDN
התרחיש לדוגמה הזה מחייב את הדרישות הבאות:
- ארכיטקטורה היברידית שמורכבת ממופעי VMware Engine וממופעי Compute Engine, עם מאזן עומסים L7 כקצה קדמי משותף ומפת URL לניתוב תעבורה לבק-אנד המתאים.
- הגנה על עומסי עבודה ציבוריים של VMware Engine באמצעות פתרון IPS/IDS, NGFW, DPI או NAT.
- הפחתת הסיכון למתקפות DDoS ברמה L3 עד L7 בעומסי עבודה ציבוריים ב-VMware Engine באמצעות Google Cloud Armor.
- סיום SSL באמצעות אישורי SSL בניהול Google או מדיניות SSL כדי לשלוט בגרסאות ובצפנים של SSL שמשמשים לחיבורי HTTPS או SSL לעומסי עבודה של VMware Engine שפונים לציבור.
- האצת העברת נתונים ברשת לעומסי עבודה ב-VMware Engine באמצעות Cloud CDN כדי להציג תוכן ממיקומים שקרובים למשתמשים.
בתרשים הבא מוצגים המשאבים שנדרשים להקצאת יכולות NGFW, להפחתת מתקפות DDoS, להפחתת עומסים של SSL ול-CDN לעומסי עבודה של VMware Engine שפונים לציבור:
באיור 4 מוצגות המשימות שצריך לבצע כדי להגדיר את המשאבים בארכיטקטורה הזו. בהמשך מופיע תיאור של כל משימה, כולל קישור למסמך עם מידע נוסף והוראות מפורטות.
הקצאת מאזן עומסים חיצוני גלובלי של אפליקציות ברשת ה-VPC החיצונית כנקודת הכניסה של תעבורת הנתונים הנכנסת (ingress) שפונה לציבור עבור עומסי עבודה של VMware Engine.
- כדי לתמוך בכמה עומסי עבודה של VMware Engine, צריך ליצור כמה כללי העברה.
- מגדירים כל כלל העברה עם כתובת IP ציבורית ייחודית, ומגדירים אותו להאזנה לתעבורת HTTP(S).
- מגדירים את מכשירי הרשת כקצוות עורפיים למאזן העומסים.
בנוסף, אתם יכולים:
- כדי להגן על מכשירי הרשת, צריך להגדיר כללי מדיניות אבטחה של Cloud Armor במאזן העומסים.
- כדי לתמוך בניתוח נתיבים, בבדיקת תקינות ובכתובת IP מסוג Anycast עבור מכשירי הרשת שפועלים כשרתי קצה של CDN, צריך להגדיר Cloud CDN עבור קבוצות ה-MIG שמארחות את מכשירי הרשת.
- כדי לנתב בקשות לשרתי קצה עורפיים שונים, צריך להגדיר מיפוי של כתובות URL במאזן העומסים. לדוגמה, אפשר לנתב בקשות ל-
/apiלמכונות וירטואליות של Compute Engine, בקשות ל-/imagesלקטגוריה של Cloud Storage ובקשות ל-/appדרך מכשירי הרשת למכונות וירטואליות של VMware Engine.
מגדירים כל מכשיר רשת לבצע תרגום כתובות יעד (DNAT) עבור כתובת ה-IP הפנימית של הממשק
nic0שלו לכתובות ה-IP הפנימיות של המכונות הווירטואליות שמארחות את האפליקציות שפונות לציבור ב-VMware Engine.- התקני הרשת צריכים לבצע SNAT לתעבורת הנתונים מהמקור מממשק
nic2(כתובת IP פנימית) כדי להבטיח נתיב חזרה סימטרי. - בנוסף, ציוד הרשת צריך לנתב תנועה שמיועדת לרשתות VMware Engine דרך הממשק
nic2אל שער רשת המשנה (כתובת ה-IP הראשונה של רשת המשנה).
שלב ה-DNAT נחוץ כי מאזן העומסים הוא שירות מבוסס-פרוקסי שמוטמע בשירות ממשק הקצה של Google (GFE). בהתאם למיקום של הלקוחות, כמה שרתי GFE יכולים ליזום חיבורי HTTP(S) לכתובות ה-IP הפנימיות של מכשירי הרשת בעורף. למנות מה-GFE יש כתובות IP של מקור מאותו טווח שמשמש לבדיקות תקינות (35.191.0.0/16 ו-130.211.0.0/22), ולא כתובות ה-IP המקוריות של הלקוח. מאזן העומסים מוסיף את כתובות ה-IP של הלקוח באמצעות הכותרת
X-Forwarded-For.כדי שבדיקות תקינות יעברו בהצלחה, צריך להגדיר את מכשירי הרשת כך שיגיבו לכתובת ה-IP של כלל ההעברה באמצעות ממשקי משנה או ממשקי לולאה חוזרת.
- התקני הרשת צריכים לבצע SNAT לתעבורת הנתונים מהמקור מממשק
מגדירים את טבלת הניתוב של רשת ה-VPC הפנימית להעברת תעבורת נתונים של VMware Engine לקישור בין רשתות VPC שכנות.
בהגדרה הזו, המכונות הווירטואליות של VMware Engine משתמשות בשירות שער האינטרנט של VMware Engine כדי לצאת לאינטרנט. עם זאת, התעבורה הנכנסת מנוהלת על ידי מכשירי הרשת עבור כתובות ה-IP הציבוריות של המכונות הווירטואליות.
NGFW לקישוריות פרטית
התרחיש לדוגמה הזה מחייב את הדרישות הבאות:
- ארכיטקטורה היברידית שמורכבת ממופעי VMware Engine ו-Compute Engine, עם מאזן עומסים L4 כקצה קדמי משותף.
- הגנה על עומסי העבודה הפרטיים של VMware Engine באמצעות פתרון IPS/IDS, NGFW, DPI או NAT.
- Cloud Interconnect או Cloud VPN לקישוריות עם הרשת המקומית.
בתרשים הבא מוצגים המשאבים שנדרשים להקצאת NGFW לקישוריות פרטית בין עומסי העבודה של VMware Engine לבין רשתות מקומיות או ספקי שירותי ענן אחרים:
באיור 5 מוצגות המשימות שצריך לבצע כדי להגדיר את המשאבים בארכיטקטורה הזו. בהמשך מופיע תיאור של כל משימה, כולל קישור למסמך עם מידע נוסף והוראות מפורטות.
מקצים מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ברשת ה-VPC החיצונית, עם כלל העברה יחיד שמאזין לכל התעבורה. מגדירים את מכשירי הרשת כקצוות עורפיים למאזן העומסים.
מגדירים את טבלת הניתוב של רשת ה-VPC החיצונית כך שתצביע על כלל ההעברה כצעד הבא לניתוב תעבורת נתונים שמיועדת לרשתות VMware Engine.
מגדירים את מכשירי הרשת באופן הבא:
- ניתוב תעבורה שמיועדת לרשתות VMware Engine דרך ממשק
nic2לשער של רשת המשנה (כתובת ה-IP הראשונה של רשת המשנה). - כדי שבדיקות תקינות יעברו בהצלחה, צריך להגדיר את מכשירי הרשת כך שיגיבו לכתובת ה-IP של כלל ההעברה באמצעות ממשקי משנה או ממשקי לולאה חוזרת.
- כדי שהבדיקות של תקינות מאזני העומסים הפנימיים יעברו, צריך להגדיר כמה דומיינים וירטואליים של ניתוב כדי להבטיח ניתוב תקין. השלב הזה נחוץ כדי לאפשר לממשק
nic2להחזיר תנועה של בדיקות תקינות שמגיעה מהטווחים הציבוריים (35.191.0.0/16 ו-130.211.0.0/22), בזמן שנתיב ברירת המחדל של מכשירי הרשת מצביע על הממשקnic0. מידע נוסף על טווחי כתובות ה-IP לבדיקות תקינות של מאזן עומסים זמין במאמר בנושא טווחי כתובות IP של בדיקות תקינות וכללים של חומת אש.
- ניתוב תעבורה שמיועדת לרשתות VMware Engine דרך ממשק
מגדירים את טבלת הניתוב של רשת ה-VPC הפנימית להעברת תעבורת VMware Engine לקישור בין רשתות VPC שכנות כצעד הבא.
עבור תעבורת נתונים חוזרת או תעבורת נתונים שיוצאת מ-VMware Engine לרשתות מרוחקות, צריך להגדיר את מאזן העומסים הפנימי מסוג Network Load Balancer כנקודת הקפיצה הבאה שמוכרזת באמצעות קישור בין רשתות VPC לרשת ה-VPC של הגישה לשירותים פרטיים.
תעבורת נתונים יוצאת (egress) מרכזית לאינטרנט
התרחיש לדוגמה הזה מחייב את הדרישות הבאות:
- סינון כתובות URL, רישום ביומן ואכיפה של תעבורה באופן מרוכז עבור תעבורת נתונים יוצאת באינטרנט.
- הגנה בהתאמה אישית על עומסי עבודה ב-VMware Engine באמצעות מכשירי רשת מ-Cloud Marketplace.
בתרשים הבא מוצגים המשאבים שנדרשים להקצאת נקודות תעבורת נתונים יוצאת (egress) מרכזיות מעומסי עבודה של VMware Engine לאינטרנט:
באיור 6 מוצגות המשימות שצריך לבצע כדי להגדיר את המשאבים בארכיטקטורה הזו. בהמשך מופיע תיאור של כל משימה, כולל קישור למסמך עם מידע נוסף והוראות מפורטות.
הקצאת מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ברשת ה-VPC הפנימית כנקודת הכניסה ליציאה של עומסי עבודה של VMware Engine.
- יוצרים כלל העברה אחד כדי להאזין לכל תעבורת הנתונים.
- מגדירים את מכשירי הרשת כקצוות עורפיים למאזן העומסים.
מגדירים את מכשירי הרשת ל-SNAT של התנועה מכתובות ה-IP הציבוריות שלהם (
nic0). כדי שבדיקות תקינות יעברו בהצלחה, מכשירי הרשת צריכים להגיב לכתובת ה-IP של כלל ההעברה באמצעות ממשקי משנה או ממשקי לולאה חוזרת.מגדירים את רשת ה-VPC הפנימית כך שתפרסם נתיב ברירת מחדל באמצעות קישור בין רשתות VPC שכנות לרשת ה-VPC של הגישה לשירותים פרטיים, כשכלל ההעברה של מאזן העומסים הפנימי מוגדר כנקודת הקפיצה הבאה.
כדי לאפשר לתעבורת נתונים יוצאת (egress) לעבור דרך מכשירי הרשת במקום דרך שער האינטרנט, השתמשו באותו תהליך שבו הייתם משתמשים כדי להפעיל את הניתוב של תעבורת נתונים דרך חיבור מקומי.
המאמרים הבאים
- מידע נוסף על VMware Engine
- כדאי לעיין בשיטות המומלצות לתכנון רשתות VPC.
- מידע על רשתות VMware Engine
- מידע על Cloud Load Balancing
- מה כלול ב-Cloud Marketplace