במדריך הזה מפורטות שיטות מומלצות וארכיטקטורות אופייניות לארגונים לתכנון ענן וירטואלי פרטי (VPC) עם Google Cloud. המדריך הזה מיועד למומחי Cloud Architect ולמומחי מערכות שכבר מכירים את המושגים של Google Cloud רשתות.
עקרונות כלליים ושלבים ראשונים
מזהים את מקבלי ההחלטות, את ציר הזמן ואת העבודה המקדימה.
כדאי לתכנן את רשת ה-VPC מוקדם ככל האפשר.
לשמור על פשטות.
שימוש במוסכמות ברורות למתן שמות.
זיהוי מקבלי ההחלטות, ציר הזמן והעבודה המקדימה
השלב הראשון בתכנון רשת ה-VPC הוא לזהות את מקבלי ההחלטות, את לוחות הזמנים ואת העבודה המקדימה שנדרשת כדי לוודא שתוכלו לעמוד בדרישות של בעלי העניין.
בעלי העניין יכולים לכלול בעלי אפליקציות, אדריכלי אבטחה, אדריכלי פתרונות ומנהלי תפעול. הגורמים המעורבים עשויים להשתנות בהתאם לתוכנית שלכם לגבי רשת ה-VPC – אם היא מיועדת לפרויקט, לענף כלכלי (LOB) או לארגון כולו.
חלק מהעבודה המקדימה הוא להכיר לצוות את המושגים והמינוחים שקשורים לתכנון רשת VPC. דוגמאות למסמכים שימושיים:
- מסמכי מנהל המשאבים
- חומרי עזר שקשורים לניהול זהויות והרשאות גישה (IAM)
- מסמכי תיעוד של ענן וירטואלי פרטי (VPC)
כדאי לתכנן את רשת ה-VPC מוקדם ככל האפשר
הגדרת רשת VPC צריכה להיות חלק מוקדם בתכנון ההגדרה הארגונית ב- Google Cloud. אם תצטרכו לשנות בהמשך דברים בסיסיים כמו האופן שבו הרשת שלכם מפולחת או המיקום של עומסי העבודה, זה עלול לשבש את הפעילות בארגון.
להגדרות שונות של רשתות VPC יכולות להיות השלכות משמעותיות על ניתוב, קנה מידה ואבטחה. תכנון קפדני והבנה מעמיקה של השיקולים הספציפיים שלכם עוזרים לכם ליצור בסיס אדריכלי מוצק לעומסי עבודה מצטברים.
לשמור על פשטות
הדרך הכי טובה להבטיח ארכיטקטורה שקל לנהל, אמינה ומובנת היא לשמור על פשטות העיצוב של טופולוגיית רשת ה-VPC.
שימוש במוסכמות ברורות למתן שמות
כדאי להשתמש במוסכמות פשוטות, אינטואיטיביות ועקביות למתן שמות. כך אדמינים ומשתמשי קצה יכולים להבין מה המטרה של כל משאב, איפה הוא נמצא ומה מבדיל אותו ממשאבים אחרים.
קיצורים מקובלים של מילים ארוכות עוזרים לשמור על תמציתיות. שימוש במינוח מוכר ככל האפשר משפר את הקריאות.
כשקובעים את כללי מתן השמות, כדאי להתייחס לרכיבים שמוצגים בדוגמה הבאה:
- שם החברה: Acme Company:
acmeco - יחידה עסקית: משאבי אנוש:
hr - קוד האפליקציה: מערכת התגמול:
comp - קוד אזור: northamerica-northeast1:
na-ne1, europe-west1: eu-we1 - קודי סביבה:
dev,test,uat,stage,prod
בדוגמה הזו, סביבת הפיתוח של מערכת הפיצויים של מחלקת משאבי האנוש נקראת acmeco-hr-comp-eu-we1-dev.
לגבי משאבי רשת נפוצים אחרים, כדאי להשתמש בתבניות כמו אלה:
רשת VPC
תחביר:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
דוגמה:acmeco-hr-dev-vpc-1Subnet
תחביר:{company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
דוגמה:acmeco-hr-na-ne1-dev-vpc-1-subnet-1
הערה: אם רשת משנה מכילה משאבים באזור אחד בלבד, אפשר להשתמש ב-zone-label במקום ב-region-label.כלל חומת אש
תחביר:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
דוגמה:acmeco-hr-internet-internal-tcp-80-allow-ruleIP route
תחביר:{priority}-{VPC-label}-{tag}-{next hop}
דוגמה:1000-acmeco-hr-dev-vpc-1-int-gw
כתובות ורשתות משנה
שימוש בתת-רשתות במצב מותאם אישית ברשתות VPC ארגוניות.
קיבוץ אפליקציות לפחות רשתות משנה עם טווחי כתובות גדולים יותר.
שימוש ברשתות VPC במצב מותאם אישית
רשתות במצב אוטומטי יכולות להיות שימושיות בשלב הראשוני של המחקר, אבל רשתות VPC במצב מותאם אישית מתאימות יותר לרוב סביבות הייצור.
אנחנו ממליצים לחברות להשתמש ברשתות VPC במצב מותאם אישית מההתחלה מהסיבות הבאות:
- רשתות VPC במצב מותאם אישית משתלבות טוב יותר עם תוכניות קיימות לניהול כתובות IP. מכיוון שכל הרשתות במצב אוטומטי משתמשות באותה קבוצה של טווחי כתובות IP פנימיות, יכול להיות שיהיה חפיפה בין טווחי כתובות ה-IP במצב אוטומטי כשמתחברים לרשתות הארגוניות המקומיות.
- אי אפשר לקשר בין שתי רשתות VPC במצב אוטומטי באמצעות קישור בין רשתות VPC שכנות (peering) כי תת-הרשתות שלהן משתמשות באותם טווחי כתובות IP ראשיים.
- לכל רשתות המשנה במצב אוטומטי יש את אותו שם כמו הרשת. אתם יכולים לבחור שמות ייחודיים ותיאוריים לרשתות משנה במצב מותאם אישית, כדי שיהיה קל יותר להבין את רשתות ה-VPC ולתחזק אותן.
- כשמוסיפים Google Cloud אזור חדש, רשתות VPC במצב אוטומטי מקבלות באופן אוטומטי רשת משנה חדשה באותו אזור. רשתות VPC במצב מותאם אישית מקבלות רשתות משנה חדשות רק אם מציינים אותן. הדבר הזה יכול להיות חשוב גם מבחינת ריבונות וגם מבחינת ניהול כתובות IP.
אם אין לה משאבים, אפשר למחוק את defaultהרשת. אי אפשר למחוק רשת VPC עד שמסירים את כל המשאבים שתלויים בה, כולל מכונות וירטואליות (VM).
מידע נוסף על ההבדלים בין רשתות VPC במצב אוטומטי לבין רשתות VPC במצב מותאם אישית זמין בסקירה הכללית על רשתות VPC.
קיבוץ אפליקציות לפחות רשתות משנה עם טווחי כתובות גדולים יותר
באופן מסורתי, רשתות ארגוניות מסוימות מחולקות לטווחים קטנים רבים של כתובות, מסיבות שונות. לדוגמה, יכול להיות שהפעולה הזו בוצעה כדי לזהות או לבודד אפליקציה, או כדי לשמור על דומיין שידור קטן.
עם זאת, מומלץ לקבץ אפליקציות מאותו סוג לרשתות משנה מעטות יותר, שקל יותר לנהל אותן, עם טווחי כתובות גדולים יותר באזורים שבהם רוצים להפעיל אותן.
בניגוד לסביבות רשת אחרות שבהן נעשה שימוש במסכה של רשת משנה,Google Cloud משתמשת בגישה של שירותי Networking מוגדרי-תוכנה (SDN) כדי לספק רשת מלאה של נגישות בין כל ה-VMs ברשת ה-VPC הגלובלית. מספר רשתות המשנה לא משפיע על התנהגות הניתוב.
אתם יכולים להשתמש בחשבונות שירות או בתגי רשת כדי להחיל מדיניות ניתוב ספציפית או כללי חומת אש. הזהות ב- Google Cloud לא מבוססת רק על כתובת ה-IP של רשת המשנה.
חלק מהתכונות של VPC – כולל Cloud NAT, גישה פרטית ל-Google, VPC Flow Logs וטווחים של כתובות IP עם כינוי – מוגדרות לכל רשת משנה. אם אתם צריכים שליטה מדויקת יותר בתכונות האלה, אתם יכולים להשתמש ברשתות משנה נוספות.
רשת VPC יחידה ו-VPC משותף
מתחילים עם רשת VPC אחת למשאבים עם דרישות משותפות.
שימוש ב-VPC משותף לניהול של כמה קבוצות עבודה.
הקצאת התפקיד 'משתמש רשת' ברמת רשת המשנה.
משתמשים בפרויקט מארח יחיד אם המשאבים דורשים כמה ממשקי רשת.
משתמשים בכמה פרויקטים מארחים אם דרישות המשאבים חורגות מהמכסה של פרויקט יחיד.
משתמשים בכמה פרויקטים מארחים אם צריך מדיניות ניהול נפרדת לכל VPC.
מתחילים עם רשת VPC אחת למשאבים שיש להם דרישות משותפות
במקרים פשוטים רבים, רשת VPC יחידה מספקת את התכונות שאתם צריכים, וקל יותר ליצור, לתחזק ולהבין אותה בהשוואה לחלופות מורכבות יותר. כשמקבצים משאבים עם דרישות ומאפיינים משותפים לרשת VPC אחת, מתחילים להגדיר את הגבול של רשת ה-VPC כהיקף לבעיות פוטנציאליות.
דוגמה להגדרה כזו מופיעה בארכיטקטורת ההפניה פרויקט יחיד, רשת VPC יחידה.
גורמים שעשויים להוביל אתכם ליצור רשתות VPC נוספות כוללים את היקף הפעילות, אבטחת הרשת, שיקולים פיננסיים, דרישות תפעוליות וניהול זהויות והרשאות גישה (IAM).
שימוש ב-VPC משותף לניהול של כמה קבוצות עבודה
לארגונים עם כמה צוותים, VPC משותף הוא כלי יעיל להרחבת הפשטות האדריכלית של רשת VPC יחידה לכמה קבוצות עבודה. הגישה הפשוטה ביותר היא לפרוס פרויקט מארח יחיד של VPC משותף עם רשת VPC משותפת יחידה, ואז לצרף את פרויקטים של שירותים של הצוות לרשת של הפרויקט המארח.
במקרה כזה, מדיניות הרשת והשליטה בכל משאבי הרשת מרוכזות וקלות יותר לניהול. מחלקות בפרויקט שירות יכולות להגדיר ולנהל משאבים שאינם משאבי רשת, וכך לאפשר הפרדה ברורה של תחומי האחריות בין צוותים שונים בארגון.
המשאבים בפרויקטים האלה יכולים לתקשר ביניהם באופן מאובטח ויעיל יותר בתוך תחומי הפרויקטים באמצעות כתובות IP פנימיות. תוכלו לנהל משאבים משותפים ברשת, כמו תת-רשתות, מסלולים וחומות אש, מפרויקט מארח מרכזי. כך תוכלו לאכוף מדיניות רשת עקבית בכל הפרויקטים.
דוגמה להגדרה כזו מופיעה בארכיטקטורת ההפניה פרויקט מארח יחיד, כמה פרויקטים של שירותים, VPC משותף יחיד.
הקצאת תפקיד משתמש ברשת ברמת רשת המשנה
האדמין המרכזי של ה-VPC המשותף יכול להעניק לחברים את התפקיד 'משתמש ברשת' (networkUser) ברמת תת-הרשת, כדי להגדיר הרשאות מדויקות בפרויקט השירות, או לכל תת-הרשתות ברמת הפרויקט המארח.
בהתאם לעיקרון של הרשאות מינימליות, מומלץ להעניק את תפקיד משתמש הרשת ברמת רשת המשנה למשתמש, לחשבון השירות או לקבוצה המשויכים.
מכיוון שתת-רשתות הן אזוריות, השליטה המפורטת הזו מאפשרת לכם לציין באילו אזורים כל פרויקט שירות יכול להשתמש כדי לפרוס משאבים.
בארכיטקטורות של VPC משותף, יש לכם גם את הגמישות לפרוס כמה פרויקטים מארחים של VPC משותף בארגון. כל פרויקט מארח של VPC משותף יכול להכיל רשת VPC משותפת אחת או יותר. במקרה כזה, בסביבות שונות יכולים להיות כללי מדיניות שונים.
מידע נוסף זמין במאמר בנושא תפקידי IAM לרשתות.
משתמשים בפרויקט מארח יחיד אם המשאבים דורשים כמה ממשקי רשת
אם יש לכם פרויקט שירות שצריך לפרוס משאבים בכמה רשתות VPC מבודדות – לדוגמה, מכונות וירטואליות עם כמה ממשקי רשת – הפרויקט המארח צריך להכיל את כל רשתות ה-VPC שמספקות את השירותים. הסיבה לכך היא שפרויקט שירות יכול להיות מצורף רק לפרויקט מארח אחד.
שימוש בכמה פרויקטים מארחים אם דרישות המשאבים חורגות מהמכסה של פרויקט יחיד
במקרים שבהם אי אפשר לעמוד בדרישות המשאבים המצטברות של כל רשתות ה-VPC במסגרת המכסה של פרויקט, כדאי להשתמש בארכיטקטורה עם כמה פרויקטים מארחים עם רשת VPC משותפת אחת לכל פרויקט מארח, במקום פרויקט מארח יחיד עם כמה רשתות VPC משותפות. חשוב להעריך את דרישות ההיקף שלכם, כי שימוש בפרויקט מארח יחיד מחייב כמה רשתות VPC בפרויקט המארח, והמכסות נאכפות ברמת הפרויקט.
דוגמה להגדרה כזו מופיעה במאמר ארכיטקטורת עזר של VPC משותף עם כמה פרויקטים מארחים וכמה פרויקטים של שירותים.
משתמשים בכמה פרויקטים מארחים אם צריך מדיניות ניהול נפרדת לכל רשת VPC
לכל פרויקט יש מכסה משלו, ולכן כדי להגדיל את המשאבים המצטברים, צריך להשתמש בפרויקט מארח נפרד של VPC משותף לכל רשת VPC. כך לכל רשת VPC יש הרשאות IAM נפרדות לניהול רשתות ואבטחה, כי הרשאות IAM מיושמות גם ברמת הפרויקט. לדוגמה, אם פורסים שתי רשתות VPC (רשת VPC A ורשת VPC B) באותו פרויקט מארח, התפקיד של מנהל הרשת (networkAdmin) חל על שתי רשתות ה-VPC.
החלטה אם ליצור כמה רשתות VPC
יוצרים רשת VPC אחת לכל פרויקט כדי למפות את מכסות רשת ה-VPC לפרויקטים.
יצירת רשת VPC לכל צוות אוטונומי, עם שירותים משותפים ברשת VPC משותפת.
יצירת רשתות VPC בפרויקטים שונים כדי להשתמש באמצעי בקרה נפרדים של IAM.
בידוד מידע אישי רגיש ברשת VPC משלהם.
יצירת רשת VPC אחת לכל פרויקט כדי למפות מכסות של משאבי VPC לפרויקטים
מכסות הן מגבלות שמוגדרות ברמת הפרויקט או ברמת הרשת. לכל המשאבים יש מכסה ראשונית שמוגדרת כברירת מחדל, שמטרתה להגן עליכם מפני שימוש לא צפוי במשאבים. עם זאת, יכול להיות שתרצו מכסה גדולה יותר בגלל הרבה גורמים. לרוב המשאבים, אפשר לבקש מכסה נוספת.
מומלץ ליצור רשת VPC אחת לכל פרויקט אם אתם צופים שתחרגו ממכסות ברירת המחדל של משאבי ה-VPC. כך קל יותר למפות הגדלות של מכסות ברמת הפרויקט לכל רשת VPC, במקום לשילוב של רשתות VPC באותו פרויקט.
המגבלות נועדו להגן על משאבי המערכת באופן מצטבר. בדרך כלל אי אפשר להגדיל את המגבלות בקלות, אבל צוותי התמיכה והמכירות יכולים לעזור לכם להגדיל חלק מהמגבלות.Google Cloud
במאמר מכסות ומגבלות של משאבי VPC תוכלו לקרוא על הערכים הנוכחיים.
התמיכה של Google יכולה להגדיל חלק ממגבלות ההרחבה, אבל יכול להיות שיהיו מקרים שבהם תצטרכו ליצור כמה רשתות VPC כדי לעמוד בדרישות ההרחבה. אם יש לכם דרישה להרחבת רשת ה-VPC מעבר למגבלות, מומלץ לדון במקרה עם צוותי המכירות והתמיכה כדי להבין מה הגישה הכי טובה לדרישות שלכם.Google Cloud
יצירת רשת VPC לכל צוות אוטונומי, עם שירותים משותפים ברשת VPC משותפת
חלק מהפריסות הגדולות של Enterprise כוללות צוותים אוטונומיים שכל אחד מהם צריך שליטה מלאה ברשתות ה-VPC שלו. כדי לעמוד בדרישה הזו, אפשר ליצור רשת VPC לכל יחידה עסקית, עם שירותים משותפים ברשת VPC משותפת (לדוגמה, כלי ניתוח, צינור CI/CD ומכונות בנייה, שירותי DNS/ספריות).
יצירת רשתות VPC בפרויקטים שונים כדי להשתמש באמצעי בקרה נפרדים של IAM
רשת VPC היא משאב ברמת הפרויקט עם אמצעי בקרה מפורטים לניהול זהויות והרשאות גישה (IAM) ברמת הפרויקט, כולל התפקידים הבאים:
networkAdminsecurityAdminnetworkUsernetworkViewer
כברירת מחדל, אמצעי הבקרה של IAM נפרסים ברמת הפרויקט, וכל תפקיד IAM חל על כל רשתות ה-VPC בפרויקט.
אם אתם צריכים אמצעי בקרה עצמאיים של IAM לכל רשת VPC, אתם צריכים ליצור את רשתות ה-VPC בפרויקטים שונים.
אם אתם צריכים תפקידי IAM בהיקף של משאבי Compute Engine ספציפיים, כמו מכונות וירטואליות, דיסקים ותמונות, אתם יכולים להשתמש במדיניות IAM למשאבי Compute Engine.
בידוד של מידע אישי ורגיש ברשת VPC משלו
לחברות שעוסקות ביוזמות של ציות, במידע אישי רגיש או בנתונים בפיקוח גבוה שחלים עליהם תקני ציות כמו HIPAA או PCI-DSS, כדאי לנקוט באמצעי אבטחה נוספים. אחת השיטות שיכולות לשפר את האבטחה ולהקל על הוכחת התאימות היא לבודד כל אחת מהסביבות האלה ברשת VPC משלה.
חיבור של כמה רשתות VPC
בחירת שיטת הקישור ל-VPC שתענה על הצרכים שלכם מבחינת עלות, ביצועים ואבטחה.
שימוש ב-NCC VPC spokes.
משתמשים בקישור בין רשתות VPC שכנות אם צריך להוסיף מכשירי NVA או אם האפליקציה לא תומכת בחיבור לשירות פרטי.
משתמשים בניתוב חיצוני אם לא צריך תקשורת עם כתובת IP פרטית.
שימוש ב-Cloud VPN כדי לחבר רשתות VPC שמארחות נקודות גישה לשירותים שלא ניתן להגיע אליהן באופן טרנזיטיבי דרך NCC.
שימוש במכשירים וירטואליים עם כמה כרטיסי רשת (NIC) כדי לשלוט בתעבורה בין רשתות VPC דרך מכשיר בענן.
בחירת שיטת החיבור ל-VPC שתענה על הצרכים שלכם מבחינת עלות, ביצועים ואבטחה
אחרי שמחליטים להטמיע כמה רשתות VPC, השלב הבא הוא לחבר את רשתות ה-VPC האלה. רשתות VPC הן מרחבים מבודדים לדיירים ב-SDN של Google Andromeda, אבל יש כמה דרכים לאפשר תקשורת ביניהן. בקטעים הבאים מפורטות שיטות מומלצות לבחירת שיטת חיבור ל-VPC.
בטבלה הבאה מפורטים היתרונות והחסרונות של כל אחת מהשיטות, ובסעיפים הבאים מפורטות שיטות מומלצות לבחירת שיטת חיבור ל-VPC.
| יתרונות | חסרונות | |
|---|---|---|
| רכזות (spokes) של Network Connectivity Center VPC |
|
|
| VPC Network Peering |
|
|
| ניתוב חיצוני (כתובת IP ציבורית או שער NAT) |
|
|
| Cloud VPN |
|
|
| מספר ממשקי רשת (Multi-NIC) |
|
|
שימוש ב-VPC spokes של NCC
מומלץ להשתמש ב-NCC VPC spokes כשצריך לקשר בין רשתות VPC. רכזות של NCC VPC מאפשרות שימוש חוזר בכתובות ב-VPC באותו פרויקט ובאותו ארגון, או בפרויקט ובארגון אחרים.
השיטה המומלצת לחיבור רשתות VPC היא באמצעות רכזות VPC של NCC, מהסיבות הבאות:
- מישור הנתונים מבוזר, כך שאין צוואר בקבוק בשער. התעבורה עוברת בין רשתות VPC כאילו המכונות הווירטואליות נמצאות באותה רשת VPC.
- קישוריות בין רשתות בארגונים שונים. הרשתות כוללות רשתות VPC וגם רשתות חיצוניות.
- עד 250 רשתות VPC לכל רכזת.
- אפשרות להגיע לנקודות גישה לשירותים בכל רשתות ה-VPC.
- שילוב של Cloud NAT בין רשתות VPC כדי לאפשר שימוש חוזר בכתובות IP ברשתות VPC.
- הגדרת כללים לנגישות לרשת באמצעות טופולוגיות שהוגדרו מראש ומסננים לפי תחילית.
משתמשים בקישור בין רשתות VPC שכנות אם צריך להוסיף NVAs או אם האפליקציה לא תומכת ב-Private Service Connect
מומלץ להשתמש בקישור בין רשתות VPC שכנות (peering) אם צריך להוסיף מכשירים וירטואליים לרשת (NVA), כמו מכונות וירטואליות של חומת אש. יכול להיות שתצטרכו להוסיף מכשירי NVA לתנועה שעוברת בין כמה רשתות VPC או לקישוריות פרטית לשירותים שלא פורסמו באמצעות Private Service Connect.
כשמשתמשים בקישור בין רשתות VPC שכנות (peering), חשוב לוודא שסך המשאבים שנדרשים לכל הרשתות השכנות שמקושרות ישירות לא חורג מהמגבלות על מופעי מכונות וירטואליות, מספר חיבורי ה-peering וכללי ההעברה הפנימית.
קישור בין רשתות VPC שכנות מאפשר לשתי רשתות VPC להתחבר זו לזו באופן פנימי דרך ה-SDN של Google, בלי קשר לשאלה אם הן שייכות לאותו פרויקט או לאותו ארגון. קישור בין רשתות VPC שכנות (peering) ממזג את מישור הבקרה ואת הפצת הזרימה בין כל רשת שכנה, ומאפשר את אותן מאפייני העברה כאילו כל המכונות הווירטואליות היו באותה רשת VPC. כשמבצעים קישור בין רשתות VPC, יש גישה לכל רשתות המשנה, לטווחים של כתובות IP עם כינוי ולכללי העברה פנימית, וכל רשת VPC שומרת על חומת האש המבוזרת שלה. קישור בין רשתות VPC שכנות (peering) הוא לא טרנזיטיבי.
שימוש בניתוב חיצוני אם לא צריך תקשורת עם כתובות IP פרטיות
אם לא צריך תקשורת של כתובות IP פרטיות, אפשר להשתמש בניתוב חיצוני עם כתובות IP חיצוניות או עם שער NAT.
כשפורסים רשת VPC, מוקצה נתיב לשער ברירת המחדל של Google באינטרנט עם עדיפות של 1,000. אם הנתיב הזה קיים, ולמכונה וירטואלית מוקצית כתובת IP חיצונית, המכונות הווירטואליות יכולות לשלוח תעבורת נתונים יוצאת (יציאה) דרך שער האינטרנט של Google. אפשר גם לפרוס שירותים מאחורי אחד מפתרונות איזון העומסים הציבוריים הרבים של Google, וכך לאפשר גישה לשירותים מבחוץ.
מכונות וירטואליות עם כתובת חיצונית מתקשרות זו עם זו באופן פרטי דרך רשת הליבה של Google, ללא קשר לאזור ולרמות השירות ברשת. אפשר להשתמש בכללים של חומת אש כדי לשלוט בתנועה חיצונית נכנסת (ingress) למכונות הווירטואליות. Google Cloud
ניתוב חיצוני הוא אפשרות טובה למטרות הרחבה, אבל חשוב להבין איך ניתוב ציבורי משפיע על העלויות. פרטים נוספים מופיעים במסמכי התמחור לרשת.
שימוש ב-Cloud VPN כדי לחבר רשתות VPC שמארחות נקודות גישה לשירותים שלא ניתן להגיע אליהן באופן טרנזיטיבי דרך NCC
שער HA VPN מספק שירות מנוהל לחיבור רשתות VPC באמצעות יצירת מנהרות IPsec בין קבוצות של נקודות קצה. אם מגדירים את נתבי Cloud במצב פרסום מותאם אישית, אפשר להפעיל ניתוב טרנזיטיבי ברשתות VPC ובטופולוגיות של רכזת וחישורים, כמו שמתואר בהמשך המאמר. באמצעות Network Connectivity Center, אפשר להשתמש במנהרות HA VPN כרשת מעבר בין רשתות מקומיות, כמו שמוסבר במסמכי Cloud VPN.
Cloud VPN לא תומך ב-MTU גדול. לפרטים נוספים, אפשר לעיין בקטע שיקולים לגבי MTU.
שימוש במכשירים וירטואליים כדי לשלוט בתעבורה בין רשתות VPC דרך מכשיר בענן
מכונות וירטואליות עם כמה ממשקי רשת נפוצות ברשתות VPC שנדרשים בהן שירותים או אבטחה נוספים, כי הן מאפשרות למכונות וירטואליות לגשר על התקשורת בין רשתות VPC.
כדי לפרוס מכונה וירטואלית בכמה רשתות VPC, צריך לקבל את הרשאת ה-IAM המתאימה לכל רשת VPC שאליה המכונה הווירטואלית מתחברת.
כשפורסים מכונה וירטואלית עם כמה כרטיסי רשת בין רשתות VPC, חשוב לזכור שטווח כתובות ה-IP של רשתות המשנה של הממשקים לא יכול להיות חופף.
קישוריות לשירות
Private Service Connect מאפשר לצרכנים לגשת לשירותים באופן פרטי מתוך רשת ה-VPC שלהם, בלי צורך במודל פריסה שמתמקד ברשת. באופן דומה, היא מאפשרת לספקי שירותים לארח את השירותים האלה ברשתות VPC נפרדות משלהם, והם יכולים להציע חיבור פרטי לצרכנים שלהם באותו ארגון או בארגונים שונים. Private Service Connect מאפשר קישוריות לשירותים מנוהלים של צד ראשון וצד שלישי, וכך מבטל את הצורך בהקצאת רשתות משנה לגישה לשירותים פרטיים ולקישור בין רשתות VPC שכנות.
Private Service Connect מציע מודל אבטחה מבוסס-שירות עם היתרונות הבאים:
- אין תלות משותפת
- הרשאה מפורשת
- ביצועים במהירות הקו
שירות Private Service Connect זמין בכמה סוגים שמספקים יכולות שונות ואופני תקשורת שונים:
- נקודות קצה של Private Service Connect: נקודות קצה שנפרסות באמצעות כללי העברה שמספקים לצרכן כתובת IP שממופה לשירות Private Service Connect.
- קצוות עורפיים מסוג Private Service Connect: קצוות עורפיים נפרסים באמצעות קבוצות של נקודות קצה ברשת (NEGs) שמאפשרות לצרכנים להפנות תנועה למאזן העומסים שלהם לפני שהתנועה מגיעה לשירות Private Service Connect. אם ה-backends נפרסים עם מאזן עומסים ב-HTTPS, הם יכולים לתמוך באישורים.
- ממשקי Private Service Connect: ממשקים מאפשרים לצרכן ולבעלים של השירות המנוהל ליצור תעבורה, וכך מתאפשרת תקשורת דו-כיוונית. אפשר להשתמש בממשקים באותה רשת VPC כמו נקודות קצה ושרתי קצה עורפיים.
אפשרות חלופית ל-Private Service Connect היא גישה לשירותים פרטיים, שמאפשרת לצרכנים לקשר את שירותי ההפקה באמצעות קישור בין רשתות VPC שכנות. כשמשתמשים בגישה לשירותים פרטיים, מומלץ לשקול את הקצאת כתובות ה-IP לכל שירות מנוהל, את החפיפה בין כתובות ה-IP ואת המכסה המשותפת.
עיצוב היברידי: חיבור סביבה מקומית
מומלץ להשתמש בניתוב דינמי כשזה אפשרי.
שימוש ברשת VPC לקישוריות כדי להרחיב ארכיטקטורת רכזת-חישורים עם כמה רשתות VPC.
אחרי שמזהים את הצורך בקישוריות היברידית ובוחרים פתרון שעונה על הדרישות של רוחב הפס, הביצועים והאבטחה, צריך לחשוב איך לשלב אותו בתכנון של ה-VPC.
שימוש ב-VPC משותף מייתר את הצורך בשכפול אותו פתרון בכל פרויקט. לדוגמה, כשמשלבים פתרון Cloud Interconnect ב-VPC משותף, כל המכונות הווירטואליות יכולות לגשת לחיבור Cloud Interconnect, בלי קשר לאזור או לפרויקט השירות.
שימוש בניתוב דינמי כשהדבר אפשרי
ניתוב דינמי זמין בכל הפתרונות ההיברידיים, כולל HA VPN, VPN קלאסי, Dedicated Interconnect ו-Partner Interconnect. ניתוב דינמי משתמש ב-Cloud Router של Google כרכיב BGP כדי לספק ניתוב דינמי של External BGP (eBGP).
Cloud Router לא נמצא במישור הנתונים, הוא רק יוצר מסלולים ב-SDN.
בניתוב דינמי לא נעשה שימוש בתגים, ו-Cloud Router אף פעם לא מפרסם מחדש קידומות שנלמדו.
אפשר להפעיל כל אחד משני המצבים של Cloud Router – אזורי או גלובלי – בכל רשת VPC. אם בוחרים ניתוב אזורי, Cloud Router מפרסם רק רשתות משנה שנמצאות באותו אזור שבו Cloud Router נפרס. לעומת זאת, ניתוב גלובלי מפרסם את כל רשתות המשנה של רשת ה-VPC הנתונה, ללא קשר לאזור, אבל הוא מעניש נתיבים שמפורסמים ונלמדים מחוץ לאזור. כך נשמרת סימטריה באזור, כי תמיד יש העדפה לחיבור מקומי. החישוב מתבצע על ידי הוספת מדד עונשין (MED) ששווה ל-200 + TTL במילישניות בין אזורים.
ניתוב סטטי
ניתוב סטטי זמין רק ב-VPN קלאסי. ניתוב סטטי מאפשר להגדיר מסלול לניתוב לשלב הבא שמצביע על מנהרת Cloud VPN.
כברירת מחדל, מסלול סטטי חל על כל המכונות הווירטואליות ברשת, ללא קשר לאזור. ניתוב סטטי מאפשר לאדמינים של רשתות להגדיר באופן סלקטיבי לאילו מכונות וירטואליות הניתוב חל באמצעות תגי מכונה, שאפשר לציין כשיוצרים נתיב.
מסלולים סטטיים חלים באופן גלובלי ברשת ה-VPC, עם אותה עדיפות מסלול כמו כל אחד מהם. לכן, אם יש לכם כמה מנהרות בכמה אזורים לאותה קידומת עם אותה עדיפות, מכונה וירטואלית תשתמש ב-ECMP מבוסס-גיבוב של 5 טאפלים בכל המנהרות. כדי לייעל את ההגדרה הזו, אפשר ליצור מסלול מועדף באזור על ידי הפניה לתגי מופעים לכל אזור ויצירת מסלולים מועדפים בהתאם.
אם לא רוצים שתעבורת נתונים יוצאת (יציאה) תעבור דרך שער האינטרנט שמוגדר כברירת מחדל ב-Google, אפשר להגדיר נתיב סטטי מועדף שמוגדר כברירת מחדל כדי לשלוח את כל תעבורת הנתונים בחזרה לשרתים המקומיים דרך מנהרה.
שימוש ברשת VPC לקישוריות כדי להרחיב ארכיטקטורת רכזת-הסתעפות עם כמה רשתות VPC
אם אתם צריכים להרחיב ארכיטקטורת רכזת ו-spoke עם כמה רשתות VPC, אתם יכולים להגדיר קישוריות היברידית מרכזית ברשת VPC ייעודית אחת או יותר, ואז להוסיף את החיבורים ההיברידיים ואת כל ה-spoke של ה-VPC לרכזת NCC. צריך להפעיל את האפשרות החלפת מסלולים עם רשתות VPC מסוג Hub and Spoke. ההגדרה הזו מאפשרת לייצא מסלולים סטטיים או מסלולים שנלמדו באופן דינמי לרשתות VPC מסוג Hub and Spoke כדי לספק הגדרה מרכזית ולהתאים את העיצוב של רשת ה-VPC.
התרשים הבא ממחיש עיצוב של קישוריות היברידית מרכזית באמצעות NCC:
לחלופין, אפשר להשתמש בקישור בין רשתות VPC שכנות (peering) ובמסלולים מותאמים אישית שפורסמו כדי לספק גישה לחיבורים היברידיים משותפים, אם לא תחרגו ממגבלות המשאבים ואם אתם צריכים להשתמש ב-NVA.
בתרשים הבא מוצגת קישוריות היברידית מרכזית עם מסלולים מותאמים אישית של קישור בין רשתות VPC:
העיצוב המרכזי הזה שונה מפריסה רגילה של קישוריות היברידית, שבה נעשה שימוש במנהרות VPN או בחיבורי VLAN בכל רשת VPC בנפרד.
אבטחת רשת
מגדירים יעדי אבטחה ברורים.
הגבלה של גישה חיצונית
הגדרת אזורי אבטחה למידע אישי רגיש.
ניהול התעבורה באמצעות Google Cloud כללי חומת אש כשזה אפשרי.
כדאי להשתמש בכמה שפחות כללים לחומת האש, עם היקף רחב יותר, כשזה אפשרי.
מבודדים מכונות וירטואליות באמצעות חשבונות שירות כשזה אפשרי.
שימוש באוטומציה כדי לעקוב אחרי כללי מדיניות אבטחה כשמשתמשים בתגים.
שימוש בכלים נוספים שיעזרו לכם לאבטח את האפליקציות ולהגן עליהן.
Google Cloud מספק מאפייני אבטחה חזקים בכל התשתית והשירותים שמוצעים, החל מאבטחה פיזית של מרכזי הנתונים וחומרת אבטחה מותאמת אישית ועד לצוותי חוקרים ייעודיים. עם זאת, אבטחת המשאבים שלכם היא אחריות משותפת.Google Cloud עליכם לנקוט צעדים מתאימים כדי להבטיח שהאפליקציות והנתונים שלכם מוגנים.
זיהוי יעדי אבטחה ברורים
לפני שמעריכים אמצעי בקרת אבטחה מבוססי-ענן או כאלה שיכולים לפעול בענן, כדאי להתחיל עם קבוצה של יעדי אבטחה ברורים שכל בעלי העניין מסכימים עליהם כחלק מהותי מהמוצר. המטרות האלה צריכות להתמקד בהשגה, בתיעוד ובחזרה על הפעולות, כדי שאפשר יהיה להתייחס אליהן ולשפר אותן במהלך הפיתוח.
הגבלה של גישה חיצונית
כשיוצרים Google Cloud משאב שמשתמש ברשת VPC, בוחרים רשת ותת-רשת שבהן המשאב נמצא. למשאב מוקצית כתובת IP פנימית מתוך אחד מטווחי ה-IP שמשויכים לתת-הרשת. משאבים ברשת VPC יכולים לתקשר ביניהם באמצעות כתובות IP פנימיות, אם כללי חומת האש מאפשרים זאת.
רצוי להגביל את הגישה לאינטרנט רק למשאבים שזקוקים לה. משאבים שיש להם רק כתובת IP פנימית פרטית עדיין יכולים לגשת להרבה שירותים וממשקי Google API דרך Private Service Connect או גישה פרטית ל-Google. הגישה הפרטית מאפשרת למשאבים ליצור אינטראקציה עם שירותים מרכזיים ב-Google וב- Google Cloud , ועדיין להישאר מבודדים מהאינטרנט הציבורי.
בנוסף, אפשר להשתמש בכללי מדיניות ארגוניים כדי להגביל עוד יותר את המשאבים שיכולים להשתמש בכתובות IP חיצוניות.
כדי לאפשר למכונות וירטואליות לגשת לאינטרנט, משתמשים ב-Secure Web Proxy אם אפשר להוריד את התנועה דרך HTTP(S) ורוצים להטמיע אמצעי בקרה של זהויות. אחרת, צריך להשתמש ב-Cloud NAT.
הגדרת גבולות שירות למידע אישי רגיש
עבור עומסי עבודה שכוללים מידע אישי רגיש, כדאי להשתמש ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות מסביב למשאבי ה-VPC ולשירותים שמנוהלים על ידי Google, ולשלוט בתנועת הנתונים מעבר לגבולות הגזרה. באמצעות VPC Service Controls, אתם יכולים לקבץ פרויקטים ואת הרשת המקומית שלכם למתחם היקפי יחיד שמונע גישה לנתונים דרך שירותים שמנוהלים על ידי Google. גבולות גזרה לשירות לא יכולים להכיל פרויקטים מארגונים שונים, אבל אפשר להשתמש בגשרים בין גבולות גזרה כדי לאפשר לפרויקטים ולשירותים בגבולות גזרה שונים לתקשר ביניהם.
ניהול התעבורה באמצעות Google Cloud כללי חומת אש כשניתן
Google Cloud VPC כולל חומת אש עם שמירת מצב, שניתנת להרחבה אופקית ומוחלת על כל מכונה וירטואלית באופן מבוזר. פרטים נוספים זמינים במאמר סקירה כללית על Cloud NGFW.
ב-Google Cloud Marketplace יש מערכת אקולוגית גדולה של פתרונות צד שלישי, כולל מכונות וירטואליות שמספקות אבטחה מתקדמת, כמו הגנה מפני דליפת מידע, ניצול לרעה של אפליקציות והסלמה של הרשאות. הן גם מזהות איומים מוכרים ולא מוכרים ומחילות סינון של כתובות URL. יש גם יתרונות תפעוליים לשימוש בספק יחיד להטמעת מדיניות אצל ספקי שירותי ענן ובסביבות מקומיות.
בדרך כלל התנועה מנותבת למכונות הווירטואליות האלה על ידי ציון מסלולים, או עם אותה עדיפות (כדי להפיץ את התנועה באמצעות hash של 5 טאפלים) או עם עדיפויות שונות (כדי ליצור נתיב יתיר), כמו שמוצג במסלולים המרובים לרשת המשנה Dev בתרשים הבא.
רוב הפתרונות דורשים כמה מכונות וירטואליות של ממשקי רשת.
היכולת להרחבה היא גם שיקול חשוב כשפורסים פתרונות של צד שלישי ברשת ה-VPC, מהסיבות הבאות:
- מגבלות: את רוב מכשירי ה-VM צריך להוסיף לנתיב הנתונים. לשם כך נדרשת מכונה וירטואלית עם כמה ממשקי רשת שמגשרת בין כמה רשתות VPC שנמצאות באותו פרויקט. מכיוון שמכסות משאבי VPC מוגדרות ברמת הפרויקט, יכול להיות שהצורך המצטבר במשאבים בכל רשתות ה-VPC יהפוך למגבלה.
- ביצועים: הוספה של נקודת חנק שמבוססת על VM יחיד למאפייני המדרגיות האופקית המלאה של רשת VPC, נוגדת את המתודולוגיות של עיצוב הענן. כדי לצמצם את הסיכון הזה, אפשר להציב כמה מכשירים וירטואליים ברשת (NVA) בקבוצת מופעי מכונה מנוהלים מאחורי מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
כדי להתחשב בגורמים האלה בארכיטקטורות עם דרישות של היקף גדול, צריך להעביר את אמצעי בקרת האבטחה לנקודות הקצה. כדאי להתחיל בחיזוק המכונות הווירטואליות ובשימוש Google Cloud בכללי חומת אש. האסטרטגיה הזו יכולה לכלול גם הצגה של סוכני בדיקה של נקודות קצה מבוססות-מארח שלא משנים את ארכיטקטורת ההעברה של רשת ה-VPC באמצעות כמה מכונות וירטואליות של ממשקי רשת.
דוגמה נוספת להגדרה הזו מופיעה במאמר ארכיטקטורת עזר של חומת אש ברמה 7 עם שמירת מצב בין רשתות VPC.
כדאי להשתמש בכמה שפחות כללים לחומת האש, אבל כאלה שמכסים טווח רחב ככל האפשר
אפשר לתכנת רק מספר מסוים של כללים בכל מכונה וירטואלית. עם זאת, אפשר לשלב הרבה כללים בהגדרה מורכבת אחת. לדוגמה, אם כל המכונות הווירטואליות ברשת ה-VPC צריכות לאפשר באופן מפורש 10 יציאות TCP של תעבורת נתונים נכנסת, יש לכם שתי אפשרויות: לכתוב 10 כללים נפרדים, שכל אחד מהם מגדיר יציאה אחת, או להגדיר כלל אחד שכולל את כל 10 היציאות. האפשרות היעילה יותר היא להגדיר כלל אחד שכולל את כל 10 היציאות.
יוצרים קבוצת כללים כללית שחלה על כל רשת ה-VPC, ואז משתמשים בקבוצות כללים ספציפיות יותר לקבוצות קטנות יותר של מכונות וירטואליות באמצעות יעדים. במילים אחרות, כדאי להתחיל בהגדרת כללים רחבים, ולהגדיר כללים יותר ספציפיים בהדרגה לפי הצורך:
- החלת כללי חומת אש שמשותפים לכל המכונות הווירטואליות ברשת ה-VPC.
- החלת כללי חומת אש שאפשר לקבץ בכמה מכונות וירטואליות, כמו קבוצת מכונות של שירות או רשת משנה.
- החלת כללי חומת אש על מכונות וירטואליות ספציפיות, כמו שער NAT או מארח bastion.
בידוד מכונות וירטואליות באמצעות חשבונות שירות, כשניתן
בארגונים רבים יש סביבות שבהן נדרשים כללים ספציפיים לקבוצת משנה של מכונות וירטואליות ברשת VPC. יש שתי גישות נפוצות שאפשר לנקוט במקרים כאלה: בידוד של רשת משנה וסינון של יעדים.
בידוד של רשת משנה
עם בידוד רשתות משנה, רשת המשנה יוצרת את גבול האבטחה שבו מוחלים כללי חומת האש. Google Cloud הגישה הזו נפוצה במבנים של רשתות מקומיות ובמקרים שבהם כתובות IP ומיקום ברשת הם חלק מהזהות של המכונה הווירטואלית.
כדי לזהות את המכונות הווירטואליות בתת-רשת ספציפית, אפשר להחיל על המופעים האלה תג ייחודי, תג רשת או חשבון שירות. כך אפשר ליצור כללים לחומת האש שחלים רק על המכונות הווירטואליות ברשת משנה – אלה עם התג המשויך, תג הרשת או חשבון השירות. לדוגמה, כדי ליצור כלל של חומת אש שמאפשר את כל התקשורת בין מכונות וירטואליות באותה רשת משנה, אפשר להשתמש בהגדרת הכלל הבאה בדף של כללי חומת האש:
- יעדים: תגי יעד שצוינו
- תגי יעד: subnet-1
- מסנן מקור: תת-רשתות
- רשתות משנה: בוחרים רשת משנה לפי שם (לדוגמה: subnet-1).
סינון של קהלים לטירגוט
בעזרת סינון לפי יעד, כל המכונות הווירטואליות נמצאות באותה רשת משנה או שהן חלק מקבוצה שרירותית של רשתות משנה. בגישה הזו, החברות ברשת המשנה לא נחשבת לחלק מזהות המכונה בכללי חומת האש. במקום זאת, אפשר להשתמש בתגים, בתגי רשת או בחשבונות שירות כדי להגביל את הגישה בין מכונות וירטואליות באותה רשת משנה. לכל קבוצת מכונות וירטואליות שמשתמשת באותם כללי חומת אש מוחל אותו תג רשת.
כדי להמחיש את זה, נניח שיש אפליקציה עם שלוש שכבות (אינטרנט, אפליקציה, מסד נתונים) שכל המופעים שלה נפרסים באותה רשת משנה. שכבת האינטרנט יכולה לתקשר עם משתמשי הקצה ועם שכבת האפליקציה, ושכבת האפליקציה יכולה לתקשר עם שכבת מסד הנתונים, אבל אסור שתהיה תקשורת אחרת בין השכבות. למופעים שמריצים את שכבת האינטרנט יש תג רשת web, למופעים שמריצים את שכבת האפליקציה יש תג רשת app, ולמופעים שמריצים את שכבת מסד הנתונים יש תג רשת db.
הכללים הבאים של חומת האש מטמיעים את הגישה הזו:
| כלל 1: מתן הרשאה למשתמשי קצה ← שכבת אינטרנט | Targets: Specified target tags Target tags: web Source filter: IP ranges Source IP ranges: 0.0.0.0/0 |
| כלל 2: מתן הרשאה מרמת האינטרנט לרמת האפליקציה | יעדים: תגי יעד שצוינו תגי יעד: app מסנן מקור: תגי מקור תגי מקור: web |
| כלל 3: מתן הרשאה מרמת האפליקציה ← לרמת מסד הנתונים | יעדים: תגי יעד שצוינו תגי יעד: db מסנן מקור: תגי מקור תגי מקור: app |
עם זאת, למרות שאפשר להשתמש בתגי רשת לסינון טירגוט באופן הזה, מומלץ להשתמש בתגים או בחשבונות שירות כשזה אפשרי. תגי היעד לא מוגבלים בגישה, ומי שיש לו תפקיד instanceAdmin יכול לשנות אותם בזמן שהמכונות הווירטואליות פועלות. הגישה לתגים ולחשבונות שירות מוגבלת, כלומר משתמש ספציפי צריך לקבל הרשאה מפורשת כדי להשתמש בחשבון שירות.
יכול להיות רק חשבון שירות אחד לכל מופע, אבל יכולים להיות כמה תגים. בנוסף, אפשר לשנות חשבונות שירות שמוקצים למכונה וירטואלית רק כשהמכונה הווירטואלית מושבתת.
שימוש באוטומציה למעקב אחרי מדיניות אבטחה כשמשתמשים בתגים
אם אתם משתמשים בתגי רשת, חשוב לזכור שאדמין של מכונה יכול לשנות את התגים האלה. הדבר עלול לעקוף את מדיניות האבטחה. לכן, אם אתם משתמשים בתגי רשת בסביבת ייצור, כדאי להשתמש במסגרת אוטומציה כדי להתגבר על חוסר השליטה של IAM בתגי הרשת.
שימוש בכלים נוספים שיעזרו לכם לאבטח את האפליקציות ולהגן עליהן
בנוסף לכללי חומת האש, תוכלו להשתמש בכלים הנוספים האלה כדי לאבטח את האפליקציות ולהגן עליהן:
- בעזרת מאזן עומסים גלובלי של HTTP(S) תוכלו לתמוך בזמינות גבוהה ובנורמליזציה של פרוטוקולים. Google Cloud
- שילוב של Google Cloud Armor עם מאזן העומסים של HTTP(S) מאפשר לספק הגנת DDoS ולחסום או לאפשר כתובות IP בקצה הרשת.
- כדי לשלוט בגישה לאפליקציות, בעזרת IAP תוכלו לאמת את זהות המשתמש וההקשר של הבקשה, כדי לקבוע אם המשתמש צריך לקבל גישה.
- Security Command Center מספק ממשק יחיד לתובנות אבטחה, לזיהוי אנומליות ולזיהוי נקודות חולשה.
שירותי רשת: NAT ו-DNS
שימוש בכתובות IP חיצוניות קבועות עם Cloud NAT.
שימוש חוזר בכתובות IP ברשתות VPC באמצעות Cloud NAT.
שימוש באזורי DNS פרטיים לפתרון שמות.
שימוש בכתובות IP חיצוניות קבועות עם Cloud NAT
אם אתם צריכים כתובות IP חיצוניות קבועות ממגוון מכונות וירטואליות, אתם יכולים להשתמש ב-Cloud NAT. דוגמה למקרה שבו אתם צריכים כתובות IP יוצאות קבועות היא כשצד שלישי מאפשר בקשות מכתובות IP חיצוניות ספציפיות. שימוש ב-Cloud NAT מאפשר לכם להשתמש במספר קטן של כתובות IP של NAT לכל אזור, שמשמשות לתקשורת יוצאת.
Cloud NAT גם מאפשר למכונות וירטואליות לתקשר באינטרנט בלי שיהיו להן כתובות IP חיצוניות משלהן. Google Cloud כללי חומת האש הם stateful. המשמעות היא שאם חיבור מותר בין מקור ליעד או בין יעד ליעד סופי, כל התנועה הבאה בכל אחד מהכיוונים תהיה מותרת כל עוד החיבור פעיל. במילים אחרות, כללי חומת האש מאפשרים תקשורת דו-כיוונית אחרי שנוצר חיבור.
שימוש חוזר בכתובות IP בכמה רשתות VPC באמצעות Cloud NAT
אפשר לעשות שימוש חוזר בכתובות IP בכמה רשתות VPC כשמופעל Cloud NAT ל-NCC. שירות Cloud NAT בין רשתות VPC זמין כשמחוברות רשתות VPC באמצעות רכזות VPC של NCC. אם כתובות ה-IP של ה-VPC חופפות לטווחים ברשתות חיצוניות, צריך להפעיל Hybrid NAT. רק חיבורים שנוצרו מעומסי עבודה ב- Google Cloud לרשתות חיצוניות מתורגמים.
שימוש באזורי DNS פרטיים לפתרון שמות
כדי לאפשר לשירותים שלכם לעבור רזולוציית DNS בתוך רשת ה-VPC באמצעות כתובות ה-IP הפנימיות שלהם, בלי לחשוף את המיפוי הזה כלפי חוץ, אתם יכולים להשתמש באזורים פרטיים ב-Cloud DNS.
כדי למפות שירותים לכתובות IP שונות מתוך רשת ה-VPC ומחוצה לה, צריך להשתמש ב-split horizon DNS. לדוגמה, יכול להיות ששירות מסוים נחשף דרך איזון עומסים ברשת מהאינטרנט הציבורי, אבל איזון עומסים פנימי מספק את אותו שירות באמצעות אותו שם DNS מתוך רשת ה-VPC.
גישת API לשירותים מנוהלים של Google
אם אפשר, משתמשים בשער ברירת המחדל באינטרנט.
מוסיפים נתיבים מפורשים לממשקי Google API אם צריך לשנות את נתיב ברירת המחדל.
פריסת מופעים שמשתמשים ב-Google APIs באותה רשת משנה.
מומלץ להשתמש בשער ברירת המחדל לאינטרנט כשזה אפשרי
הגישה ממשאבים ברשת ה-VPC לממשקי Google API מתבצעת דרך שער האינטרנט שמוגדר כברירת מחדל. למרות השם של שער הצעד הבא למעבר, נתיב התנועה ממופעים אל Google APIs נשאר בתוך הרשת של Google.
כברירת מחדל, רק מכונות וירטואליות עם כתובת IP חיצונית יכולות לתקשר עם Google APIs ושירותים של Google. אם אתם צריכים גישה ממופעים ללא כתובת IP חיצונית, הגדירו נקודות קצה של Private Service Connect או השתמשו בתכונה גישה פרטית ל-Google לכל רשת משנה. הפעולה הזו לא מאטה את התקשורת עם ממשקי Google API.
ב-Google Kubernetes Engine (GKE), הגישה הפרטית ל-Google מופעלת אוטומטית ברשתות משנה שבהן נפרסים צמתים. כל הצמתים ברשתות המשנה האלה ללא כתובת IP חיצונית יכולים לגשת לשירותים מנוהלים של Google.
הוספת מסלולים מפורשים לממשקי Google API אם צריך לשנות את מסלול ברירת המחדל
אם אתם צריכים לשנות את נתיב ברירת המחדל, אתם צריכים להוסיף נתיבים מפורשים לטווחי כתובות ה-IP של היעד של Google API.
בסביבות שבהן המסלול שמוגדר כברירת מחדל (0.0.0.0/0) לא משתמש בנקודת הקפיצה הבאה של שער האינטרנט שמוגדר כברירת מחדל, צריך להגדיר מסלולים מפורשים עבור טווחי כתובות ה-IP של היעד שמשמשים את Google APIs. מגדירים את ה-next-hop של המסלולים המפורשים לשער ברירת המחדל לאינטרנט. דוגמה לתרחיש כזה היא כשצריך לבדוק את כל התנועה דרך מכשיר מקומי.
פריסת מופעים שמשתמשים ב-Google APIs באותה רשת משנה
פריסת מופעים שנדרשת להם גישה לשירותים ולממשקי ה-API של Google באותה רשת משנה והפעלת גישה פרטית ל-Google למופעים ללא כתובות IP חיצוניות. אפשרות אחרת היא להגדיר נקודות קצה של Private Service Connect.
אם אתם ניגשים לממשקי Google API מהסביבה המקומית שלכם באמצעות גישה פרטית ל-Google, אתם יכולים להשתמש במאמר הגדרת גישה פרטית ל-Google למארחים מקומיים כדי לגשת לחלק משירותי Google באמצעות טווחי כתובות IP פרטיות. לפני שמפעילים את התכונה הזו, כדאי לבדוק אילו שירותים נתמכים, כי לא תהיה גישה לממשקי Google API אחרים דרך כתובות ה-IP שסופקו על ידי השירות הזה. הפעלת התכונה הזו עשויה לדרוש הגדרת DNS נוספת, כמו הגדרת תצוגות DNS.
אם אתם ניגשים ל-Google APIs מהסביבה המקומית שלכם באמצעות נקודות קצה של Private Service Connect, תוכלו לקרוא פרטים נוספים במאמר גישה לנקודת הקצה ממארחים מקומיים.
רישום ביומן, מעקב ושקיפות
התאמת הרישום ביומן לתרחישי שימוש ספציפיים ולקהלי יעד.
הגדלת מרווח הזמן של צבירת היומנים ברשתות VPC עם חיבורים ארוכים.
שימוש בדגימה של יומני זרימה של VPC כדי להקטין את נפח הנתונים.
הסרת מטא-נתונים נוספים כשצריך רק נתוני IP ויציאה. שימוש ב-Network Intelligence Center כדי לקבל תובנות לגבי הרשתות
התאמה אישית של הרישום ביומן למקרים ספציפיים ולקהלים ייעודיים
אפשר להשתמש ב-VPC Flow Logs למעקב אחר הרשת, פורנזיקה דיגיטלית, ניתוח אבטחה בזמן אמת ואופטימיזציה של ההוצאות. אפשר להפעיל או להשבית יומני זרימה של VPC ברמת רשת המשנה. אם הפעלתם את VPC Flow Logs עבור רשת משנה, המערכת אוספת נתונים מכל מכונות ה-VM ברשת המשנה הזו.
ביומנים האלה מתועדת דגימה של תנועות ברשת שנשלחות ומתקבלות על ידי מכונות וירטואליות. תרחישי השימוש שלכם ב-Logging עוזרים לכם לקבוע אילו רשתות משנה דורשות רישום ביומן, ולכמה זמן.
יומני זרימה מצטברים לפי חיבור במרווחי זמן של 5 שניות ממכונות וירטואליות של Compute Engine, ואז מיוצאים בזמן אמת. אתם יכולים לראות את יומני הזרימה ב-Cloud Logging ולייצא אותם לכל יעד שנתמך בייצוא של Cloud Logging.
בדף 'הוספת יומנים' ב-Logging אפשר לעקוב אחרי נפח היומנים בפרויקט, להשבית את כל הוספת היומנים או להחריג (למחוק) רשומות ביומן שלא מעניינות אתכם. כך תוכלו לצמצם את החיובים על יומנים מעבר למכסת היומנים החודשית.
יומנים הם חלק חשוב מאוד בהצלחה התפעולית והאבטחתית, אבל הם לא שימושיים אם לא בודקים אותם ולא פועלים לפיהם. התאמה של היומנים לקהל היעד שלהם, כדי להבטיח הצלחה תפעולית ואבטחה ברשתות ה-VPC.
פרטים נוספים זמינים במאמר בנושא שימוש ב-VPC Flow Logs.
הגדלת מרווח הצבירה של יומנים ברשתות VPC עם חיבורים ארוכים
ברשתות VPC שבהן רוב החיבורים הם ארוכי טווח, כדאי להגדיר את מרווח הזמן של צבירת היומנים ל-15 דקות כדי לצמצם באופן משמעותי את מספר היומנים שנוצרים ולאפשר ניתוח מהיר ופשוט יותר.
דוגמה לזרימת עבודה שבה כדאי להגדיל את מרווח הזמן של צבירת היומנים היא ניטור רשת, שכולל את המשימות הבאות:
- ביצוע אבחון רשת
- סינון של יומני התנועה לפי מכונות וירטואליות ולפי אפליקציות כדי להבין את השינויים בתנועה
- ניתוח הגידול בתנועת הגולשים כדי לחזות את הקיבולת
שימוש בדגימה של VPC Flow Logs כדי לצמצם את הנפח
שימוש בדגימה של יומני זרימה של VPC כדי להקטין את נפח יומני הזרימה של VPC, אבל עדיין לראות דגימות ברמה נמוכה ותצוגות מצטברות.
דוגמה לתהליך עבודה שבו מתאים להשתמש בדגימה כדי לצמצם את נפח הנתונים היא הבנת השימוש ברשת ואופטימיזציה של הוצאות התנועה ברשת. תהליך העבודה הזה כולל את המשימות הבאות:
- הערכת תעבורה בין אזורים ותחומים
- הערכת התנועה למדינות מסוימות באינטרנט
- זיהוי הדוברים העיקריים
הסרת מטא-נתונים נוספים כשצריך רק נתוני IP ויציאה
בתרחישי שימוש באבטחה שבהם אתם מתעניינים רק בכתובות IP ובפורטים, כדאי להסיר את המטא-נתונים הנוספים כדי לצמצם את נפח הנתונים שנצרכים ב-Cloud Logging.
דוגמה לזרימת עבודה שבה מתאים להסיר מטא-נתונים היא פורנזיקה דיגיטלית של רשתות, שכולל את המשימות הבאות:
- קביעה של כתובות ה-IP שדיברו עם מי ומתי
- זיהוי כתובות IP שנפרצו, על סמך ניתוח של זרימות נתונים ברשת
שימוש ב-Network Intelligence Center כדי לקבל תובנות לגבי הרשתות
Network Intelligence Center הוא מסוף יחיד לניהול של Google Cloud הראות של הרשת, המעקב והפתרון של בעיות. בקטעים הבאים מוסבר על הרכיבים של Network Intelligence Center.
הטופולוגיה של הרשת
אפשר להשתמש בטופולוגיה של הרשת כדי להציג את הטופולוגיה של הרשת.
בדיקות קישוריות
אפשר להשתמש בבדיקות קישוריות כדי לאבחן בעיות בקישוריות של רשתות ה-VPC.
מרכז הבקרה לביצועי הענן
אפשר להשתמש בלוח בקרה לביצועי הענן כדי לבדוק את הביצועים של הרישות הפיזי שמהווה בסיס לרשתות הווירטואליות של ה-VPC.
תובנות לגבי חומת האש
אפשר להשתמש בתובנות לגבי חומת האש כדי להבין את הכללים של חומת האש ואת האינטראקציה ביניהם.
Network Analyzer
אפשר להשתמש ב-Network Analyzer כדי לעקוב אחרי הגדרות רשת ה-VPC ולזהות הגדרות שגויות והגדרות לא אופטימליות.
Flow Analyzer
אפשר להשתמש בFlow Analyzer כדי להבין טוב יותר את תנועת הנתונים ב-VPC.
תרשימי עזר לארכיטקטורה
בקטע הזה נציג כמה ארכיטקטורות שממחישות חלק מהשיטות המומלצות שמופיעות במסמך הזה.
פרויקט יחיד, רשת VPC יחידה
ארכיטקטורת ההפניה הראשונית הזו כוללת את כל הרכיבים שנדרשים לפריסת ארכיטקטורות זמינות מאוד במספר אזורים, עם בידוד ברמת רשת המשנה והסכם רמת שירות (SLA) של 99.99% לחיבור למרכזי הנתונים המקומיים.
פרויקט מארח יחיד, כמה פרויקטים של שירות, VPC משותף יחיד
בהמשך לארכיטקטורת ההפניה הראשונית, פרויקטים מארחים של VPC משותף ומספר פרויקטים של שירות מאפשרים לאדמינים להעביר אחריות אדמיניסטרטיבית – כמו יצירה וניהול של מכונות וירטואליות – לאדמינים של פרויקטים של שירות, תוך שמירה על שליטה מרכזית במשאבי רשת כמו תת-רשתות, מסלולים וחומות אש.
כמה פרויקטים מארחים, כמה פרויקטים של שירותים, כמה רשתות VPC משותפות
בתרשים הבא מוצגת ארכיטקטורה לבידוד VPC, שמבוססת על העיצוב שלנו לזמינות גבוהה, תוך הפרדה בין סביבת הייצור לבין פרויקטים אחרים. יש הרבה סיבות לשקול בידוד של VPC, כולל דרישות ביקורת (כמו PCI), שיקולי מכסה בין סביבות או פשוט שכבת בידוד לוגית נוספת. צריך רק שני חיבורי Interconnect (לצורך יתירות) לכל מיקום, אבל אפשר להוסיף כמה חיבורי Interconnect לכמה רשתות VPC או לאזורים שונים.
שימוש בבידוד יכול גם להוביל לצורך בשכפול, כי צריך להחליט איפה למקם שירותי ליבה כמו שרתי proxy, אימות ושירותי ספריות. שימוש ברשת VPC של שירותים משותפים יכול לעזור לכם להימנע משכפול כזה, ולאפשר לכם לשתף את השירותים האלה עם רשתות VPC אחרות באמצעות NCC, ובמקביל לרכז את הניהול והפריסה.
חומת אש ברמה 7 עם שמירת מצב בין רשתות VPC
בארכיטקטורה הזו יש כמה רשתות VPC שמגשרות ביניהן באמצעות מכשיר חומת אש מהדור הבא (NGFW) ברמה 7, שפועל כגשר עם כמה כרטיסי רשת בין רשתות VPC.
רשת VPC חיצונית לא מהימנה מוצגת כדי לסיים חיבורים היברידיים וחיבורים מבוססי-אינטרנט שמסתיימים ברגל החיצונית של L7 NGFW לצורך בדיקה. יש הרבה וריאציות של העיצוב הזה, אבל העיקרון המרכזי הוא סינון התנועה דרך חומת האש לפני שהתנועה מגיעה לרשתות VPC מהימנות.
העיצוב הזה מחייב שכל רשת VPC תהיה בפרויקט שבו מוסיפים את ה-NGFW מבוסס מכונה וירטואלית. המכסות נאכפות ברמת הפרויקט, ולכן צריך להתייחס לסך כל משאבי ה-VPC.
כמה רשתות VPC שמקושרות ביניהן באמצעות NCC
בארכיטקטורה הזו יש כמה רשתות VPC שמחוברות זו לזו באמצעות NCC. כדי להימנע מהצורך ליצור צירופים ל-VLAN לכל רשת VPC, אפשר להשתמש ברשת VPC למעבר תעבורה כדי לסיים חיבורים היברידיים ולשתף את הקישוריות ההיברידית בין כל רשתות ה-VPC האחרות. הגישה הזו מאחדת את הקישוריות החיצונית ואת שיקולי הניתוב שקשורים אליה. באופן דומה, אפשר להוסיף רשתות VPC משותפות של שירותים כדי לארח שירותים נפוצים כמו שרתי proxy, אימות ושירותי ספריות. יש הרבה וריאציות של העיצוב הזה, אבל העיקרון המרכזי הוא לטפל בשירותים השונים ובסוגי החיבורים כחיבורים ל-NCC hub, שמספק קישוריות בין כל השירותים. ארכיטקטורת ההפניה הזו מתוארת בפירוט במאמר קישוריות בין רשתות VPC בענן באמצעות Network Connectivity Center.
המאמרים הבאים
- Cross-Cloud Network לאפליקציות מבוזרות
- מידע מעמיק על VPC ושיטות מומלצות (סרטון מ-Cloud NEXT'18)
- טופולוגיות של רשתות היברידיות ומרובות עננים (multi-cloud)
- בחירת היררכיית משאבים ל Google Cloud אזור הנחיתה
- שיטות מומלצות לבחירת אזורים ב-Compute Engine
- Google Cloud למומחי מרכזי נתונים: רישות
- מסמכי תיעוד של VPC
- סקירה כללית על רישות ב-GKE
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.