המסמך הזה הוא חלק מסדרת מדריכי עיצוב ל-Cross-Cloud Network. בחלק הזה נסביר על שכבת אבטחת הרשת.
הסדרה כוללת את החלקים הבאים:
- Cross-Cloud Network לאפליקציות מבוזרות
- סגמנטציה של רשת וקישוריות לאפליקציות מבוזרות ב-Cross-Cloud Network
- רשתות שירות לאפליקציות מבוזרות ב-Cross-Cloud Network
- אבטחת רשת לאפליקציות מבוזרות ב-Cross-Cloud Network (המסמך הזה)
משטחי אבטחה
כשמתכננים את שכבת האבטחה של Cross-Cloud Network, צריך להביא בחשבון את משטחי האבטחה הבאים:
- אבטחת עומסי עבודה
- אבטחת גבולות הגזרה של הדומיין
אבטחת עומסי העבודה שולטת בתקשורת בין עומסי העבודה בתוך הענן הווירטואלי הפרטי (VPC) וביניהם. אבטחת עומסי העבודה משתמשת בנקודות אכיפת אבטחה שקרובות לעומסי העבודה בארכיטקטורה. בכל פעם שאפשר, Cross-Cloud Network מספק אבטחה של עומסי עבודה באמצעות Cloud Next Generation Firewall מ- Google Cloud.
נדרשת אבטחה היקפית בכל גבולות הרשת. בדרך כלל, ההיקף מחבר בין רשתות שמנוהלות על ידי ארגונים שונים, ולכן לעיתים קרובות נדרשים אמצעי בקרה הדוקים יותר על האבטחה. צריך לוודא שהתקשורת הבאה בין הרשתות מאובטחת:
- תקשורת בין רשתות VPC שונות
- תקשורת בחיבורים היברידיים לספקי שירותי ענן אחרים או למרכזי נתונים מקומיים
- תקשורת לאינטרנט
היכולת להוסיף מכשירים וירטואליים של רשתות צד שלישי (NVA) בסביבתGoogle Cloud היא קריטית כדי לעמוד בדרישות של אבטחת היקף בחיבורים היברידיים.
אבטחת עומסי עבודה בענן
משתמשים במדיניות חומת אש ב-Google Cloud כדי לאבטח את עומסי העבודה ולספק יכולות של חומת אש עם שמירת מצב (stateful), שניתן להרחיב אותן אופקית ולהחיל אותן על כל מכונה וירטואלית. האופי המבוזר של חומות האש של Google Cloud עוזר לכם להטמיע מדיניות אבטחה לחלוקה של הרשת למקטעים קטנים, בלי להשפיע לרעה על הביצועים של עומסי העבודה.
כדי לשפר את יכולת הניהול ולאכוף את התאימות של מדיניות חומת האש, השתמשו במדיניות היררכית של חומת אש. כללי מדיניות היררכיים של חומת אש מאפשרים ליצור ולאכוף מדיניות עקבית של חומת אש בכל הארגון. אפשר להקצות כללי מדיניות היררכיים של חומת אש לארגון או לתיקיות ספציפיות.
בנוסף, כללים של מדיניות חומת אש היררכית יכולים להעביר את ההערכה למדיניות ברמה נמוכה יותר (מדיניות חומת אש של רשת גלובלית או אזורית) באמצעות פעולת goto_next.
כללים ברמה נמוכה יותר לא יכולים לשנות כלל מרמה גבוהה יותר בהיררכיית המשאבים. מבנה הכללים הזה מאפשר לאדמינים ברמת הארגון לנהל את כללי חומת האש שחובה להגדיר במקום אחד. תרחישי שימוש נפוצים במדיניות היררכית של חומת אש כוללים גישה ליעד מבוצר (bastion host) בארגון או בכמה פרויקטים, מתן הרשאה למערכות מרכזיות של בדיקות או בדיקות תקינות, ואכיפה של גבולות רשת וירטואלית בארגון או בקבוצת פרויקטים. דוגמאות נוספות לשימוש בכללי מדיניות היררכיים של חומת אש
אתם יכולים להשתמש במדיניות חומת אש גלובלית ובמדיניות חומת אש אזורית כדי להגדיר כללים ברשת VPC ספציפית, לכל האזורים ברשת (גלובליים) או לאזור אחד (אזוריים).
כדי להשיג אמצעי בקרה מפורטים יותר שנאכפים ברמת המכונה הווירטואלית (VM), מומלץ להשתמש בתגים שמנוהלים על ידי ניהול זהויות והרשאות גישה (IAM) ברמת הארגון או הפרויקט. תגים שמנוהלים על ידי IAM מאפשרים להחיל כללים של חומת אש על סמך הזהות של מארח עומס העבודה, בניגוד לכתובת ה-IP של המארח, והם פועלים גם בקישור בין רשתות VPC שכנות (Peering). כללי חומת אש שנפרסים באמצעות תגים יכולים לספק מיקרו-סגמנטציה בתוך רשת המשנה, עם כיסוי מדיניות שחל באופן אוטומטי על עומסי עבודה בכל מקום שבו הם נפרסים, ללא קשר לארכיטקטורת הרשת.
בנוסף ליכולות של בדיקה עם שמירת מצב (stateful inspection) ותמיכה בתגים, Cloud Next Generation Firewall תומך גם במודיעין איומי סייבר, ב-FQDN ובסינון לפי מיקום גיאוגרפי.
מומלץ לבצע מיגרציה מכללי חומת אש של VPC למדיניות חומת אש. כדי לעזור בהעברה, אתם יכולים להשתמש בכלי ההעברה שיוצר מדיניות גלובלית של חומת אש ברשת וממיר את הכללים הקיימים של חומת האש ב-VPC למדיניות החדשה.
אבטחה היקפית בענן
בסביבת רשת עם כמה עננים, בדרך כלל האבטחה ההיקפית מיושמת בכל רשת. לדוגמה, לרשת המקומית יש קבוצה משלה של חומות אש היקפיות, ולכל רשת בענן יש חומות אש היקפיות נפרדות.
מכיוון ש-Cross-Cloud Network מיועדת להיות המרכז של כל התקשורת, אתם יכולים לאחד ולרכז את אמצעי בקרת האבטחה ההיקפית ולפרוס קבוצה אחת של חומות אש היקפיות ב-Cross-Cloud Network. כדי לספק את חבילת אבטחת ההיקף המובנית שאתם בוחרים, Cross-Cloud Network מספקת אפשרויות גמישות להוספת מכשירי NVA.
בעיצובים שמוצגים בתרשימים, אתם יכולים לפרוס מכשירי NVA של צד שלישי ב-VPC למעבר בפרויקט המרכזי.
אפשר לפרוס מכשירי NVA בממשק רשת יחיד (מצב single-NIC) או בכמה ממשקי רשת בכמה רשתות VPC (מצב multi-NIC). ב-Cross-Cloud Network, מומלץ לפרוס מכשירים וירטואליים לרשת עם כרטיס רשת אחד, כי האפשרות הזו מאפשרת:
- מוסיפים את ה-NVA עם ניתובים על סמך מדיניות.
- הימנעו מיצירת טופולוגיות קשיחות.
- פריסה במגוון טופולוגיות בין רשתות VPC.
- מפעילים התאמה אוטומטית לעומס עבור ה-NVA.
- אפשר להרחיב את הפריסה להרבה רשתות VPC לאורך זמן, בלי לשנות את הפריסה של ממשק ה-NVA.
אם העיצוב שלכם דורש multi-NIC, ההמלצות מפורטות במאמר אבטחה היקפית של NVA עם multi-NIC.
כדי לבצע את ניתוב התנועה שנדרש לפריסת NVA, מומלץ במדריך הזה לאכוף באופן סלקטיבי מסלולים סטטיים ומסלולים שמבוססים על מדיניות בטבלאות הניתוב של ה-VPC. הניתובים על סמך מדיניות גמישים יותר מניתובים רגילים, כי הם מתאימים גם למידע על המקור וגם למידע על היעד. הניתובים האלה על סמך מדיניות נאכפים גם רק במקומות ספציפיים בטופולוגיה של הרשת בענן. רמת הפירוט הזו מאפשרת להגדיר התנהגות ספציפית מאוד של ניתוב תנועה לתהליכי קישוריות ספציפיים מאוד.
בנוסף, העיצוב הזה מאפשר את מנגנוני העמידות שנדרשים על ידי ה-NVA. לפני ה-NVAs יש מאזן עומסים פנימי מסוג TCP/UDP שמאפשר יתירות של ה-NVA, התאמה אוטומטית לעומס (autoscaling) לקיבולת גמישה וסימטריה של זרימה לתמיכה בעיבוד תנועה דו-כיוונית עם שמירת מצב (stateful).
אבטחה היקפית של NVA עם כרטיס רשת אחד
בתכנון שמתואר במאמר קישוריות בין רשתות VPC לשירותים מרכזיים, רשת ה-VPC למעבר משמשת כמרכז לרשתות ה-VPC המקושרות, שמחוברות באמצעות קישור בין רשתות VPC שכנות ו-HA VPN. ה-VPC למעבר מאפשר גם קישוריות בין הרשתות החיצוניות לבין ה-VPCs המקושרים.
כדי להוסיף NVA עם כרטיס רשת אחד, העיצוב הזה משלב את שתי התבניות הבאות:
- הוספת מכשירי NVA לרכזת של קישור בין רשתות VPC שכנות (peering) עם חיבורים היברידיים חיצוניים
- הוספת מכשירי NVA לרכזת VPC של HA VPN עם חיבורים היברידיים חיצוניים
בתרשים הבא מוצגים מכשירי NVA שנוספו לרכזות של קישור בין רשתות VPC שכנות ו-HA VPN:
התרשים שלמעלה ממחיש תבנית משולבת:
- רשת VPC להעברה שמארחת את הצירופים ל-VLAN של Cloud Interconnect, שמספקים קישוריות היברידית או קישוריות לכמה עננים. ה-VPC הזה מכיל גם את ה-NVA עם כרטיס רשת יחיד שעוקבים אחרי החיבורים ההיברידיים.
- רשתות VPC של אפליקציות שמחוברות לרשת ה-VPC למעבר באמצעות קישור בין רשתות VPC שכנות (peering).
- VPC של שירותים מרכזיים שמחובר ל-VPC של המעבר דרך HA VPN.
בתכנון הזה, ה-spokes שמחוברים באמצעות HA VPN משתמשים ב-VPC למעבר כדי לתקשר עם ה-spokes שמחוברים באמצעות קישור בין רשתות VPC שכנות. התקשורת מנותבת דרך חומות האש של ה-NVA של הצד השלישי באמצעות השילוב הבא של איזון עומסים מסוג passthrough, נתיבים סטטיים ונתיבים על סמך מדיניות:
- כדי לנתב את תעבורת הנתונים של HA VPN למאזן העומסים הפנימי, צריך להחיל על ה-Transit VPC נתיבים ללא תגים שמבוססים על מדיניות. בנתיבים האלה שמבוססים על ניתוב על סמך מדיניות, צריך להשתמש בטווחי CIDR של מקור ויעד שמאפשרים סימטריה של תעבורת נתונים.
- כדי לנתב את תעבורת הנתונים הנכנסת למאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי, צריך להחיל נתיבים שמבוססים על מדיניות על החיבורים של Cloud Interconnect ב-Transit VPC. אלה מסלולים אזוריים.
- כדי שתנועה שיוצאת מה-NVA לא תנותב ישירות חזרה ל-NVA, צריך להגדיר את כל ממשקי ה-NVA כיעד של מסלול דילוג על מדיניות כדי לדלג על מסלולים אחרים שמבוססים על מדיניות. לאחר מכן, התנועה עוברת לפי טבלת הניתוב של ה-VPC אחרי שהיא עובדה על ידי ה-NVAs.
- כדי לנתב את התנועה למאזני העומסים הפנימיים של ה-NVA ב-VPC של המעבר, צריך להחיל נתיבים סטטיים על ה-VPCs של האפליקציה. אפשר להגדיר את ההיקף שלהם לפי אזור באמצעות תגי רשת.
אבטחה היקפית של NVA עם כמה כרטיסי רשת (multi-NIC)
במצב multi-NIC, הטופולוגיה סטטית יותר כי מכשירי ה-NVA מגשרים על הקישוריות בין רשתות ה-VPC השונות שבהן נמצאים ממשקי הרשת השונים.
כשנדרשים אזורים מבוססי-ממשק בחומת אש, התכנון הבא של multi-NIC מאפשר את הקישוריות החיצונית הנדרשת. בעיצוב הזה, ממשקי חומת אש שונים מוקצים לרשתות החיצוניות. מומחי אבטחה מתייחסים לרשתות החיצוניות כרשתות לא מהימנות, ולרשתות הפנימיות כרשתות מהימנות. בפריסת NVA עם multi-NIC, התכנון הזה מיושם באמצעות רשתות VPC מהימנות ולא מהימנות.
לתקשורת פנימית, אפשר לאכוף חומת אש באמצעות מודל הוספה של כרטיס רשת (NIC) יחיד שתואם למודל אזור שמבוסס על CIDR.
בעיצוב הזה, מוסיפים מכשירי NVA על ידי הגדרת הפרטים הבאים:
- כדי לנתב את תעבורת הנתונים של HA VPN למאזן העומסים הפנימי, צריך להחיל על ה-VPC המהימן ניתובים על סמך מדיניות ללא תגים. בנתיבים האלה שמבוססים על ניתוב על סמך מדיניות, צריך להשתמש בטווחי CIDR של מקור ויעד שמאפשרים סימטריה של תעבורת נתונים.
- כדי לנתב את תעבורת הנתונים הנכנסת למאזן עומסי הרשת הפנימי להעברת נתונים, צריך להחיל נתיבים שמבוססים על מדיניות על החיבורים של Cloud Interconnect ב-VPC הלא מהימן. אלה מסלולים אזוריים.
- כדי שתנועה שיוצאת מה-NVA לא תנותב ישירות חזרה ל-NVA, צריך להגדיר את כל ממשקי ה-NVA כיעד של מסלול דילוג על מדיניות כדי לדלג על מסלולים אחרים שמבוססים על מדיניות. לאחר מכן, התנועה עוברת לפי טבלת הניתוב של ה-VPC אחרי שהיא עובדה על ידי ה-NVAs.
- כדי לנתב את התנועה למאזני העומסים הפנימיים של ה-NVA ב-VPC המהימן, צריך להחיל נתיבים סטטיים על ה-VPCs של האפליקציה. אפשר להגדיר את ההיקף שלהם לפי אזור באמצעות תגי רשת.
בתרשים הבא מוצגים מכשירי NVA עם כמה כרטיסי רשת, שמוכנסים בין רשתות ה-VPC המהימנות והלא מהימנות בפרויקט ה-hub:
המאמרים הבאים
- מידע נוסף על המוצרים של Google Cloud שמוזכרים במדריך העיצוב הזה:
- לדוגמאות נוספות של ארכיטקטורות, מדריכי עיצוב ושיטות מומלצות, עיינו במאמר מרכז הארכיטקטורה של Cloud.
שותפים ביצירת התוכן
מחברים:
- ויקטור מורנו | מנהל מוצר, Cloud Networking
- Ghaleb Al-habian | מומחה רשת
- דיפאק מייקל | מהנדס לקוחות, מומחה לרשתות
- אוסבלדו קוסטה | Customer Engineer שמתמחה ברשתות
- Jonathan Almaleh | Staff Technical Solutions Consultant
תורמים אחרים:
- זאק סיילס | מומחה רשתות
- כריסטופר אברהם | Customer Engineer שמתמחה ברשתות
- עמנואל מאצה | מומחה מוצר בתחום הרשתות
- אורליאן לגראנד | מהנדס ענן אסטרטגי
- אריק יו | מהנדס לקוחות מומחה לרשתות
- קומאר דהנגופאל | מפתח פתרונות למוצרים שונים
- מארק שלאגנהאוף | כותב טכני, רשתות
- מרוואן אל שאווי | מהנדס לקוחות של שותפים
- אמט וויליאמס | מהנדס קשרי מפתחים