במדריך הזה מתוארות שיטות מומלצות וארכיטקטורות ארגוניות אופייניות לתכנון של ענן וירטואלי פרטי (VPC) עם Google Cloud. המדריך הזה מיועד למומחי Cloud Architect ולמומחי מערכות שכבר מכירים את המושגים של Google Cloud רשתות.
עקרונות כלליים ושלבים ראשונים
מזהים את מקבלי ההחלטות, את ציר הזמן ואת העבודה שצריך לבצע מראש.
כדאי לתכנן את רשת ה-VPC מוקדם ככל האפשר.
לשמור על פשטות.
שימוש במוסכמות ברורות למתן שמות.
זיהוי מקבלי ההחלטות, ציר הזמן והעבודה המקדימה
השלב הראשון בתכנון רשת ה-VPC הוא לזהות את מקבלי ההחלטות, את לוחות הזמנים ואת העבודה המקדימה שנדרשת כדי לוודא שתוכלו לעמוד בדרישות של בעלי העניין.
בעלי העניין יכולים לכלול בעלי אפליקציות, אדריכלי אבטחה, אדריכלי פתרונות ומנהלי תפעול. הגורמים המעורבים עשויים להשתנות בהתאם לסוג התכנון של רשת ה-VPC: לפרויקט, לענף כלכלי או לארגון כולו.
חלק מהעבודה המקדימה הוא להכיר לצוות את המושגים והמינוחים שקשורים לתכנון רשתות 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) כדי לספק רשת מלאה של יכולת הגעה (reachability) בין כל ה-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 משותפת
חלק מהפריסות הגדולות של ארגונים כוללות צוותים אוטונומיים שכל אחד מהם צריך שליטה מלאה ברשתות ה-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 שתענה על הצרכים שלכם מבחינת עלות, ביצועים ואבטחה.
שימוש ב-VPC spokes של NCC.
משתמשים בקישור בין רשתות VPC שכנות אם צריך להוסיף מכשירי NVA או אם האפליקציה לא תומכת בחיבור לשירות פרטי.
משתמשים בניתוב חיצוני אם לא צריך תקשורת עם כתובת IP פרטית.
שימוש ב-Cloud VPN כדי לקשר רשתות VPC שמארחות נקודות גישה לשירות שלא ניתן להגיע אליהן באופן טרנזיטיבי דרך NCC.
שימוש במכשירים וירטואליים עם כרטיסי רשת וירטואליים מרובים כדי לשלוט בתעבורה בין רשתות VPC דרך מכשיר בענן.
בחירת שיטת חיבור VPC שתענה על הצרכים שלכם מבחינת עלות, ביצועים ואבטחה
השלב הבא אחרי שמחליטים להטמיע כמה רשתות VPC הוא לחבר את רשתות ה-VPC האלה. רשתות VPC הן מרחבים מבודדים לדיירים ב-SDN של Google Andromeda, אבל יש כמה דרכים לאפשר תקשורת ביניהן. בקטעים הבאים מפורטות שיטות מומלצות לבחירת שיטת חיבור ל-VPC.
בטבלה הבאה מפורטים היתרונות והחסרונות של כל אחת מהשיטות, ובסעיפים הבאים מפורטות שיטות מומלצות לבחירת שיטת חיבור VPC.
| יתרונות | חסרונות | |
|---|---|---|
| רכזות (spokes) של Network Connectivity Center VPC |
|
|
| VPC Network Peering |
|
|
| ניתוב חיצוני (כתובת IP ציבורית או שער NAT) |
|
|
| Cloud VPN |
|
|
| מספר ממשקי רשת (Multi-NIC) |
|
|
שימוש ב-NCC VPC spokes
מומלץ להשתמש ב-NCC VPC spokes כשצריך לקשר בין רשתות VPC. רכזות VPC של NCC מאפשרות שימוש חוזר בכתובות ב-VPC באותו פרויקט ובאותו ארגון, או בפרויקט ובארגון אחרים.
השיטה המומלצת לחיבור רשתות VPC היא באמצעות רכזות VPC של NCC, מהסיבות הבאות:
- מישור הנתונים מבוזר, כך שאין צוואר בקבוק בשער. תעבורת הנתונים עוברת בין רשתות VPC כאילו המכונות הווירטואליות נמצאות באותה רשת VPC.
- קישוריות בין רשתות בארגונים שונים. הרשתות כוללות רשתות VPC וגם רשתות חיצוניות.
- עד 250 רשתות VPC לכל רכזת.
- אפשרות להגיע לנקודות גישה לשירותים ברשתות VPC שונות.
- שילוב של Cloud NAT בין רשתות VPC כדי לאפשר שימוש חוזר בכתובות IP ברשתות VPC.
- הגדרת כללים לנגישות לרשת באמצעות טופולוגיות מוגדרות מראש ומסננים לפי תחילית.
משתמשים בקישור בין רשתות VPC שכנות אם צריך להוסיף NVAs או אם האפליקציה לא תומכת ב-Private Service Connect
מומלץ להשתמש בקישור בין רשתות VPC שכנות אם אתם צריכים להוסיף מכשירים וירטואליים לרשת (NVA), כמו מכונות וירטואליות של חומת אש. יכול להיות שתצטרכו להוסיף מכשירי NVA לתנועה שעוברת בין כמה רשתות VPC, או לקישוריות פרטית לשירותים שלא מתפרסמים באמצעות Private Service Connect.
כשמשתמשים בקישור בין רשתות שכנות (peering) של VPC, חשוב לוודא שסך המשאבים שנדרשים לכל הרשתות השכנות שמקושרות ישירות לא חורג מהמגבלות על מכונות וירטואליות, על מספר חיבורי ה-peering ועל כללי ההעברה הפנימית.
קישור רשתות VPC מאפשר לשתי רשתות VPC להתחבר זו לזו באופן פנימי דרך ה-SDN של Google, בין אם הן שייכות לאותו פרויקט או לאותו ארגון ובין אם לא. קישור רשתות VPC ממזג את מישור הבקרה ואת הפצת הזרימה בין כל רשת שכנה, ומאפשר את אותן מאפייני העברה כאילו כל המכונות הווירטואליות היו באותה רשת VPC. כשמקושרות רשתות VPC, כל רשתות המשנה, טווחי כתובות ה-IP של הכינויים וכללי ההעברה הפנימית נגישים, וכל רשת VPC שומרת על חומת האש המבוזרת שלה. קישור רשתות VPC הוא לא טרנזיטיבי.
שימוש בניווט חיצוני אם לא צריך תקשורת של כתובות IP פרטיות
אם לא צריך תקשורת של כתובות IP פרטיות, אפשר להשתמש בניתוב חיצוני עם כתובות IP חיצוניות או עם שער NAT.
כשפורסים רשת VPC, מוקצה נתיב לשער האינטרנט שמוגדר כברירת מחדל ב-Google עם עדיפות של 1, 000. אם הנתיב הזה קיים ולמכונה וירטואלית מוקצית כתובת IP חיצונית, המכונות הווירטואליות יכולות לשלוח תעבורת נתונים יוצאת (egress) דרך שער האינטרנט של Google. אפשר גם לפרוס שירותים מאחורי אחד מפתרונות איזון העומסים הציבוריים הרבים של Google, וכך לאפשר גישה לשירותים מבחוץ.
מכונות וירטואליות עם כתובת חיצונית מתקשרות זו עם זו באופן פרטי דרך רשת הליבה של Google, ללא קשר לאזור ולרמות השירות ברשת. אפשר להשתמש Google Cloud בכללים של חומת אש כדי לשלוט בתנועה חיצונית נכנסת (ingress) למכונות הווירטואליות.
ניתוב חיצוני הוא אפשרות טובה למטרות הרחבה, אבל חשוב להבין איך ניתוב ציבורי משפיע על העלויות. פרטים נוספים זמינים במסמכי התמחור של הרשת.
שימוש ב-Cloud VPN כדי לחבר רשתות VPC שמארחות נקודות גישה לשירותים שלא ניתן להגיע אליהן באופן טרנזיטיבי דרך NCC
שער HA VPN מספק שירות מנוהל לחיבור רשתות VPC על ידי יצירת מנהרות IPsec בין קבוצות של נקודות קצה. אם מגדירים את שירותי Cloud Router במצב פרסום מותאם אישית, אפשר להפעיל ניתוב טרנזיטיבי ברשתות VPC וטופולוגיות של רכזת וחישורים, כמו שמתואר בהמשך המסמך. באמצעות Network Connectivity Center, אפשר להשתמש במנהרות HA VPN כרשת מעבר בין רשתות מקומיות, כמו שמוסבר במסמכי Cloud VPN.
Cloud VPN לא תומך ב-MTU גדול. פרטים נוספים מופיעים במאמר בנושא שיקולים לגבי MTU.
שימוש במכשירים וירטואליים כדי לשלוט בתעבורה בין רשתות VPC דרך מכשיר בענן
מכונות וירטואליות עם כמה ממשקי רשת נפוצות ברשתות VPC שנדרשת בהן אבטחה נוספת או שירותים נוספים ביניהן, כי מכונות וירטואליות עם כמה ממשקי רשת מאפשרות למופעי מכונות וירטואליות לגשר על התקשורת בין רשתות VPC.
כדי לפרוס מכונה וירטואלית בכמה רשתות VPC, צריך לקבל את הרשאת ה-IAM המתאימה לכל רשת VPC שאליה המכונה הווירטואלית מתחברת.
כשפורסים מכונה וירטואלית עם כמה כרטיסי NIC בין רשתות VPC, חשוב לזכור שטווח כתובות ה-IP של רשתות המשנה של הממשקים לא יכול להיות חופף.
קישוריות לשירות
Private Service Connect מאפשר לצרכנים לגשת לשירותים באופן פרטי מתוך רשת ה-VPC שלהם, בלי צורך במודל פריסה שמתמקד ברשת. באופן דומה, היא מאפשרת לספקי שירותים לארח את השירותים האלה ברשתות VPC נפרדות משלהם, ולהציע חיבור פרטי לצרכנים שלהם באותו ארגון או בארגונים שונים. Private Service Connect מאפשר קישוריות לשירותים מנוהלים של צד ראשון וצד שלישי, וכך מבטל את הצורך בהקצאת רשתות משנה לגישה לשירותים פרטיים ולקישור בין רשתות VPC שכנות (peering).
Private Service Connect מציע מודל אבטחה ממוקד שירות עם היתרונות הבאים:
- אין תלות משותפת
- הרשאה מפורשת
- ביצועים בקצב קו
Private Service Connect זמין בסוגים שונים שמספקים יכולות שונות ואופני תקשורת שונים:
- נקודות קצה של Private Service Connect (PSC): נקודות קצה שנפרסות באמצעות כללי העברה שמספקים לצרכן כתובת IP שממופה לשירות Private Service Connect.
- בק-אנדים של Private Service Connect: בק-אנדים נפרסים באמצעות קבוצות של נקודות קצה ברשת (NEGs) שמאפשרות לצרכנים להפנות תנועה למאזן העומסים שלהם לפני שהתנועה מגיעה לשירות Private Service Connect. אם הקצה העורפי נפרס עם מאזן עומסים ב-HTTPS, הוא יכול לתמוך באישורים.
- ממשקי Private Service Connect: ממשקים מאפשרים לצרכן ולבעלים של השירות המנוהל ליצור תעבורה, וכך מתאפשרת תקשורת דו-כיוונית. אפשר להשתמש בממשקים באותה רשת VPC כמו נקודות קצה ושרתי קצה עורפיים.
אפשרות חלופית ל-Private Service Connect היא גישה לשירותים פרטיים, שמאפשרת לצרכנים לקשר את שירותי ההפקה באמצעות קישור בין רשתות VPC שכנות (peering). כשמשתמשים בגישה לשירותים פרטיים, מומלץ לשקול את הקצאת כתובות ה-IP לכל שירות מנוהל, את החפיפה בין כתובות ה-IP ואת המכסה המשותפת.
עיצוב היברידי: חיבור סביבה מקומית
מומלץ להשתמש בניתוב דינמי כשזה אפשרי.
שימוש ברשת VPC לקישוריות כדי להרחיב ארכיטקטורת רכזת-חישורים עם כמה רשתות VPC.
אחרי שמזהים את הצורך בקישוריות היברידית ובוחרים פתרון שעונה על הדרישות של רוחב הפס, הביצועים והאבטחה, צריך לחשוב איך לשלב אותו בתכנון של ה-VPC.
שימוש ב-VPC משותף מייתר את הצורך בשכפול אותו פתרון בכל פרויקט. לדוגמה, כשמשלבים פתרון Cloud Interconnect ב-VPC משותף, כל המכונות הווירטואליות יכולות לגשת לחיבור Cloud Interconnect, בלי קשר לאזור או לפרויקט השירות.
שימוש בניתוב דינמי כשזה אפשרי
ניתוב דינמי זמין בכל הפתרונות ההיברידיים, כולל HA VPN, VPN קלאסי, Dedicated Interconnect ו-Partner Interconnect. הניתוב הדינמי משתמש ב-Cloud Router של Google כרכיב Border Gateway Protocol (BGP) כדי לספק ניתוב דינמי של External BGP (eBGP).
Cloud Router לא נמצא במישור הנתונים, הוא רק יוצר מסלולים ב-SDN.
בניתוב דינמי לא נעשה שימוש בתגים, ו-Cloud Router אף פעם לא מפרסם מחדש קידומות שנלמדו.
אתם יכולים להפעיל כל אחד משני המצבים של Cloud Router, אזורי או גלובלי, בכל רשת VPC. אם תבחרו בניתוב אזורי, Cloud Router יפרסם רק רשתות משנה שנמצאות באותו אזור שבו הוא נפרס. לעומת זאת, ניתוב גלובלי יפרסם את כל רשתות המשנה של רשת ה-VPC הנתונה, ללא קשר לאזור, אבל יטיל עונש על נתיבים שמפורסמים ונלמדים מחוץ לאזור. כך נשמרת סימטריה בתוך האזור, כי תמיד תינתן עדיפות לחיבור מקומי. העונש מחושב על ידי הוספת מדד עונש (MED) ששווה ל-200 + TTL במילישניות בין אזורים.
ניתוב סטטי
ניתוב סטטי זמין רק ב-VPN קלאסי. ניתוב סטטי מאפשר להגדיר מסלול של הצעד הבא שמצביע על מנהרת Cloud VPN.
כברירת מחדל, מסלול סטטי חל על כל המכונות הווירטואליות ברשת, ללא קשר לאזור. ניתוב סטטי מאפשר לאדמינים של רשתות להגדיר באופן סלקטיבי לאילו מכונות וירטואליות הניתוב חל באמצעות תגי מכונות, שאפשר לציין כשיוצרים מסלול.
מסלולים סטטיים חלים באופן גלובלי ברשת ה-VPC, עם אותו סדר עדיפות של מסלולים. לכן, אם יש לכם כמה מנהרות בכמה אזורים לאותה קידומת עם אותו סדר עדיפות, מכונה וירטואלית תשתמש ב-ECMP מבוסס-גיבוב של 5 טאפלים בכל המנהרות. כדי לבצע אופטימיזציה של ההגדרה הזו, אתם יכולים ליצור מסלול מועדף באזור על ידי הפניה לתגי מופעים לכל אזור ויצירת מסלולים מועדפים בהתאם.
אם לא רוצים שתעבורת נתונים יוצאת (יציאה) תעבור דרך שער האינטרנט שמוגדר כברירת מחדל ב-Google, אפשר להגדיר נתיב סטטי מועדף שמוגדר כברירת מחדל כדי לשלוח את כל תעבורת הנתונים בחזרה למקום דרך מנהרה.
שימוש ברשת VPC לקישוריות כדי להרחיב ארכיטקטורת רכזת-הסתעפות עם כמה רשתות VPC
אם אתם צריכים להרחיב ארכיטקטורת רכזת-חישורים עם כמה רשתות VPC, אתם יכולים להגדיר קישוריות היברידית מרכזית ברשת VPC ייעודית אחת או יותר, ואז להוסיף את החיבורים ההיברידיים ואת כל החישורים של ה-VPC לרכזת NCC. תצטרכו להפעיל החלפת מסלולים עם חישורים של VPC. ההגדרה הזו מאפשרת לייצא מסלולים סטטיים או מסלולים שנלמדו באופן דינמי לחישורים של VPC, כדי לספק הגדרה מרכזית ולהרחיב את עיצוב רשת ה-VPC.
התרשים הבא ממחיש עיצוב של קישוריות היברידית מרכזית באמצעות NCC:
לחלופין, אפשר להשתמש בקישור בין רשתות VPC שכנות ובמסלולים מותאמים אישית שפורסמו כדי לספק גישה לחיבורים היברידיים משותפים, אם לא תחרגו ממגבלות המשאבים ואם אתם צריכים להשתמש ב-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. יש גם יתרונות תפעוליים לשימוש בספק יחיד שמטמיע מדיניות אצל ספקי שירותי ענן ובסביבות מקומיות.
בדרך כלל, התנועה מנותבת למכונות הווירטואליות האלה על ידי ציון נתיבים, או עם אותה עדיפות (כדי לפזר את התנועה באמצעות גיבוב של 5 טאפלים) או עם עדיפויות שונות (כדי ליצור נתיב יתיר), כמו שמוצג בנתיבים המרובים לרשת המשנה Dev בתרשים הבא.
רוב הפתרונות דורשים כמה מכונות וירטואליות של ממשקי רשת.
היכולת להרחבה היא גם שיקול חשוב כשפורסים פתרונות של צד שלישי ברשת ה-VPC, מהסיבות הבאות:
- מגבלות: את רוב מכשירי ה-VM צריך להוסיף לנתיב הנתונים. לשם כך נדרשת מכונת VM עם כמה ממשקי רשת שמגשרת בין כמה רשתות VPC שנמצאות באותו פרויקט. מכסות משאבי ה-VPC מוגדרות ברמת הפרויקט, ולכן יכול להיות שהצורך המצטבר במשאבים בכל רשתות ה-VPC יהיה מגביל.
- ביצועים: הוספת נקודת חנק שמבוססת על מכונה וירטואלית אחת למאפייני יכולת ההרחבה האופקית המלאה של רשת 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: מתן הרשאה למשתמשי קצה ← שכבת אינטרנט | יעדים: תגי יעד שצוינו תגי יעד: web מסנן מקור: טווח כתובות IP טווח כתובות IP של המקור: 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 פרטיים לפתרון שמות
אתם יכולים להשתמש באזורים פרטיים ב-Cloud DNS כדי לאפשר לשירותים שלכם להתבצע באמצעות DNS ברשת ה-VPC שלכם, תוך שימוש בכתובות ה-IP הפנימיות שלהם בלי לחשוף את המיפוי הזה כלפי חוץ.
כדי למפות שירותים לכתובות IP שונות מתוך רשת ה-VPC ומחוצה לה, צריך להשתמש ב-split horizon DNS. לדוגמה, יכול להיות ששירות מסוים נחשף דרך איזון עומסים ברשת מהאינטרנט הציבורי, אבל איזון עומסים פנימי מספק את אותו שירות באמצעות אותו שם DNS מתוך רשת ה-VPC.
גישת API לשירותים מנוהלים של Google
מומלץ להשתמש בשער האינטרנט שמוגדר כברירת מחדל.
אם צריך לשנות את נתיב ברירת המחדל, כדאי להוסיף נתיבים מפורשים ל-Google APIs.
פריסת מופעים שמשתמשים ב-Google APIs באותה רשת משנה.
מומלץ להשתמש בשער ברירת המחדל לאינטרנט כשזה אפשרי
הגישה ממשאבים ברשת VPC לממשקי API של Google מתבצעת דרך שער האינטרנט שמוגדר כברירת מחדל. למרות השם של שער הצעד הבא, נתיב התנועה ממופעים אל Google APIs נשאר בתוך הרשת של Google.
כברירת מחדל, רק מכונות וירטואליות עם כתובת IP חיצונית יכולות לתקשר עם ממשקי API ושירותים של 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 באותה רשת משנה
פריסת מכונות שנדרשת להן גישה לשירותים ול-Google APIs באותה רשת משנה והפעלת גישה פרטית ל-Google למכונות ללא כתובות IP חיצוניות. לחלופין, אפשר להגדיר נקודות קצה (endpoints) של Private Service Connect.
אם אתם ניגשים לממשקי Google APIs מהסביבה המקומית שלכם באמצעות גישה פרטית ל-Google, אתם יכולים להשתמש במאמר בנושא הגדרת גישה פרטית ל-Google למארחים מקומיים כדי לגשת לחלק משירותי Google דרך טווחי כתובות IP פרטיות. לפני שמפעילים את התכונה הזו, כדאי לבדוק אילו שירותים נתמכים, כי לא תהיה גישה לממשקי Google API אחרים דרך כתובות ה-IP שסופקו על ידי השירות הזה. הפעלת התכונה הזו עשויה לדרוש הגדרת DNS נוספת, כמו הגדרת תצוגות DNS.
אם אתם ניגשים לממשקי Google APIs מהסביבה המקומית שלכם באמצעות נקודות קצה של Private Service Connect, תוכלו לקרוא פרטים נוספים במאמר בנושא גישה לנקודת הקצה ממארחים מקומיים.
רישום ביומן, מעקב ושקיפות
התאמת הרישום ביומן לתרחישי שימוש ספציפיים ולקהלי יעד.
הגדלת מרווח הזמן של צבירת היומנים ברשתות VPC עם חיבורים ארוכים.
שימוש בדגימה של VPC Flow Logs כדי להקטין את נפח הנתונים.
הסרת מטא-נתונים נוספים כשצריך רק נתוני IP ויציאה. שימוש ב-Network Intelligence Center כדי לקבל תובנות לגבי הרשתות
התאמה אישית של הרישום ביומן למקרים ספציפיים ולקהלים ייעודיים
אפשר להשתמש ב-VPC Flow Logs למעקב אחרי הרשת, לניתוח פורנזי, לניתוח אבטחה בזמן אמת ולאופטימיזציה של ההוצאות. אפשר להפעיל או להשבית יומני זרימה של VPC ברמת רשת המשנה. אם הפעלתם את VPC Flow Logs עבור רשת משנה, המערכת אוספת נתונים מכל מכונות ה-VM ברשת המשנה הזו.
ביומנים האלה מתועמת דגימה של תעבורת הרשת שמכונות וירטואליות שולחות ומקבלות. תרחישי השימוש שלכם ביומנים עוזרים לכם להחליט אילו רשתות משנה דורשות תיעוד, ולכמה זמן.
יומני תנועה מצטברים לפי חיבור במרווחי זמן של 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. רשת VPC למעבר תנועה מוצגת כדי לסיים חיבורים היברידיים ולשתף את הקישוריות ההיברידית בין כל רשתות ה-VPC האחרות, וכך נמנע הצורך ליצור חיבורי VLAN לכל רשת 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.