דפוסי ארכיטקטורה של רשתות מאובטחות בסביבות היברידיות ומרובות עננים (multi-cloud)

Last reviewed 2025-01-23 UTC

בדף הזה מוצגות כל הדפים ב-Build hybrid and multicloud architectures using Google Cloud בתצוגה של דף יחיד. אפשר להדפיס את הדף הזה, או לשמור אותו בפורמט PDF באמצעות פונקציית ההדפסה של הדפדפן ובחירה באפשרות שמירה כקובץ PDF. בדף הזה לא מוצג חלונית של תוכן העניינים בצד שמאל.

המסמך הזה הוא השלישי מתוך שלושה מסמכים בקבוצה. המאמר עוסק בתבניות של ארכיטקטורת רשת היברידית ומרובת עננים (multi-cloud). בחלק הזה נסקור כמה דפוסי ארכיטקטורה נפוצים של רשתות מאובטחות שאפשר להשתמש בהם בארכיטקטורות היברידיות ומרובות עננים. במאמר מתוארים התרחישים שבהם הכי מומלץ להשתמש בדפוסי הרשת האלה, ומוצגות שיטות מומלצות להטמעה שלהם באמצעות Google Cloud.

ערכת המסמכים לדפוסי ארכיטקטורה היברידיים ומרובי עננים (multi-cloud) מורכבת מהחלקים הבאים:

• יצירת ארכיטקטורות היברידיות ומרובות עננים (multi-cloud): במאמר הזה מוסבר איך לתכנן אסטרטגיה ליצירת הגדרה היברידית ומרובת עננים באמצעות Google Cloud.
• דפוסי ארכיטקטורה היברידיים ומרובי עננים: סקירה של דפוסי ארכיטקטורה נפוצים שאפשר לאמץ כחלק מאסטרטגיה היברידית ומרובת עננים.
• דפוסי ארכיטקטורה של רשתות מאובטחות היברידיות ומרובות עננים (multi-cloud): מאמר שדן בדפוסי ארכיטקטורה של רשתות היברידיות ומרובות עננים מנקודת מבט של רשתות (המסמך הזה).

חיבור Google Cloud מאובטח ומהימן של סביבות מחשוב פרטיות הוא חיוני לכל ארכיטקטורה היברידית ומרובת עננים (multi-cloud) מוצלחת. הקישוריות של הרישות ההיברידי ודפוס הארכיטקטורה של רישות הענן שבוחרים להגדרת ענן היברידי וענן מרובה צריכים לעמוד בדרישות הייחודיות של עומסי העבודה הארגוניים. הוא צריך להתאים גם לדפוסי הארכיטקטורה שאתם מתכוונים להשתמש בהם. יכול להיות שתצטרכו להתאים כל עיצוב, אבל יש תבניות נפוצות שתוכלו להשתמש בהן כתוכנית פעולה.

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

• זהויות
• ניהול המשאבים
• אבטחה
• Networking
• מעקב

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

הסדרה הזו כוללת את הדפים הבאים:

• שיקולים בנושא עיצוב
• דפוסי ארכיטקטורה
  • דוגמת עיצוב משוקפת
  • דוגמת עיצוב עם רשת
  • דפוסי שימוש עם חסימה
    • יציאה עם שער
    • Gated ingress
    • יציאה וכניסה עם שער
  • העברה
• שיטות מומלצות כלליות

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

הכותב: Marwan Al Shawi | Partner Customer Engineer

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

• סעוד אלבזאי | Customer Engineer, Application Modernization
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Cloud Solutions Architect
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Cloud Solutions Architect
• מארק שלגנהוף | כותב טכני, רשתות
• דניאל שטרבל | EMEA Solution Lead, Application Modernization
• אמט וויליאמס | מהנדס קשרי מפתחים

תבניות ארכיטקטורה

במסמכים בסדרה הזו מפורטים דפוסי ארכיטקטורה של רשתות שנועדו להתבסס על מודלים נדרשים של תקשורת בין אפליקציות שנמצאות ב- Google Cloud ובסביבות אחרות (במקום, בעננים אחרים או בשניהם).

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

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

• דוגמת עיצוב משוקפת
• דוגמת עיצוב עם רשת
• דפוסי שימוש עם חסימה
  • יציאה עם שער
  • Gated ingress
  • יציאה עם שער וכניסה עם שער
• תבנית העברה

תבנית משוכפלת

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

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

אם משתמשים בתבנית הזו, צריך לחבר את שני סביבות המחשוב באופן שעומד בדרישות הבאות:

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

ארכיטקטורה

דיאגרמת הארכיטקטורה הבאה מציגה ארכיטקטורת עזר כללית של התבנית הזו, שתומכת ב-CI/CD, בניטור, בניהול הגדרות, במערכות ניהול אחרות ובקשר בין עומסי עבודה:

התיאור של הארכיטקטורה בתרשים שלמעלה:

• עומסי העבודה מופצים בהתאם לסביבות הפונקציונליות (פיתוח, בדיקה, CI/CD וכלי ניהול) ברשתות VPC נפרדות בצד Google Cloud .
• VPC משותף משמש לעומסי עבודה של פיתוח ובדיקות. משתמשים ב-VPC נוסף עבור כלי CI/CD וכלי ניהול. עם VPC משותפים:
  • האפליקציות מנוהלות על ידי צוותים שונים בכל סביבה ובכל פרויקט שירות.
  • פרויקט המארח מנהל ושולט בתקשורת ברשת ובאמצעי הבקרה לאבטחה בין סביבות הפיתוח והבדיקה, וגם מחוץ ל-VPC.
• רשת ה-VPC של CI/CD מחוברת לרשת שבה פועלות עומסי העבודה של הייצור בסביבת המחשוב הפרטית שלכם.
• כללי חומת האש מאפשרים רק תעבורה מורשית.
  • אפשר גם להשתמש ב-Cloud Next Generation Firewall Enterprise עם שירות למניעת חדירות (IPS) כדי להטמיע בדיקה מעמיקה של מנות נתונים למניעת איומים בלי לשנות את העיצוב או הניתוב. ‫Cloud Next Generation Firewall Enterprise פועל על ידי יצירת נקודות קצה של חומת אש אזורית שמנוהלות על ידי Google. נקודות הקצה האלה משתמשות בטכנולוגיית יירוט חבילות כדי לבדוק באופן שקוף את עומסי העבודה ולחפש חתימות של איומים שהוגדרו. הוא גם מגן על עומסי עבודה מפני איומים.
• מאפשר תקשורת בין רשתות ה-VPC המקושרות באמצעות כתובות IP פנימיות.
  • ה-peering בתבנית הזו מאפשר למערכות CI/CD ולמערכות אדמיניסטרטיביות לפרוס ולנהל עומסי עבודה של פיתוח ובדיקות.
• כדאי להקפיד על השיטות המומלצות הכלליות הבאות.

כדי ליצור את החיבור הזה של CI/CD, משתמשים באחת מהאפשרויות לקישוריות היברידית וקישוריות בין כמה עננים שמתאימות לדרישות העסקיות ולדרישות האפליקציות. כדי לאפשר לכם לפרוס ולנהל עומסי עבודה של ייצור, החיבור הזה מספק נגישות לרשת פרטית בין סביבות מחשוב שונות. בכל הסביבות צריך להיות מרחב כתובות IP מסוג RFC 1918 ללא חפיפה.

אם המופעים בסביבות הפיתוח והבדיקה דורשים גישה לאינטרנט, אפשר לשקול את האפשרויות הבאות:

• אפשר לפרוס את Cloud NAT באותה רשת של פרויקט מארח ב-VPC משותף. פריסה לאותה רשת של פרויקט מארח ב-VPC משותף עוזרת למנוע גישה ישירה למופעים האלה מהאינטרנט.
• לתנועה באינטרנט שיוצאת מהרשת, אפשר להשתמש ב-Secure Web Proxy. לפרוקסי יש כמה יתרונות.

מידע נוסף על Google Cloud הכלים והיכולות שעוזרים לכם ליצור, לבדוק ולפרוס בסביבות Google Cloud היברידיות ורב-ענניות, אפשר לקרוא בבלוג DevOps and CI/CD on Google Cloud explained.

וריאציות

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

• VPC משותף לכל סביבה
• חומת אש מרכזית בשכבת האפליקציות
• טופולוגיה של רכזת וחישורים
• ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון למיקרו-שירותים

VPC משותף לכל סביבה

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

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

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

• צוות אחד מנהל את כל הפרויקטים המארחים בכל הסביבות.
• צוותים שונים מנהלים את פרויקטי המארח בסביבות שלהם.

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

אפשר גם להקצות רשת VPC משותפת לכל סביבה ראשית, כמו שמוצג בתרשים הבא:

חומת אש מרכזית בשכבת האפליקציות

בתרחישים מסוימים, דרישות האבטחה עשויות לחייב שימוש בשכבת האפליקציה (שכבה 7) ובבדיקת מנות עמוקה עם מנגנוני חומת אש מתקדמים שחורגים מהיכולות של Cloud Next Generation Firewall. כדי לעמוד בדרישות ובסטנדרטים של הארגון בנושא אבטחה, אפשר להשתמש במכשיר NGFW שמתארח במכשיר וירטואלי לרשת (NVA). כמה Google Cloud שותפים בתחום האבטחה מציעים אפשרויות שמתאימות למשימה הזו.

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

אפשר להשתמש בעיצוב הזה גם עם כמה רשתות VPC משותפות, כמו שמוצג בתרשים הבא.

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

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

הערה: באזורי ענן נתמכים , וכאשר הדבר אפשרי מבחינה טכנית בעיצוב שלכם, אפשר לפרוס מכשירי NVA בלי לדרוש כמה רשתות VPC או ממשקי מכשירים. הפריסה הזו מבוססת על שימוש באיזון עומסים וביכולות של ניתוב על סמך מדיניות. היכולות האלה מאפשרות מנגנון מבוסס-מדיניות ושאינו תלוי בטופולוגיה לשילוב של מכשירי NVA ברשת הענן. מידע נוסף זמין במאמר בנושא פריסת מכשירים וירטואליים לרשת (NVA) ללא שימוש בכמה רשתות VPC.

טופולוגיית Hub-and-spoke

אפשרות נוספת היא להשתמש ב-VPC נפרדים (כולל VPC משותפים) עבור הפיתוח ושלבי הבדיקה השונים. בגרסה הזו, כמו שמוצג בתרשים הבא, כל סביבות הבמה מתחברות ל-VPC של CI/CD ול-VPC הניהולי בארכיטקטורת רכזת-חישורים. האפשרות הזו מתאימה אם אתם צריכים להפריד בין הדומיינים הניהוליים לבין הפונקציות בכל סביבה. מודל התקשורת 'מרכז וחישורים' יכול לעזור בדרישות הבאות:

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

מידע נוסף על אפשרויות עיצוב של רשתות מסוג Hub-and-spoke זמין במאמרים טופולוגיית Hub-and-spoke עם מכשירים מרכזיים וטופולוגיית Hub-and-spoke ללא מכשירים מרכזיים.

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

כחלק מארכיטקטורת רשת מסוג Hub-and-Spoke, אלה אפשרויות הקישוריות העיקריות (בין ה-VPC של ה-Spokes לבין ה-VPC של ה-Hub) ב- Google Cloud:

• קישור בין רשתות VPC שכנות (peering)
• VPN
• שימוש במכשיר וירטואלי לרשת (NVA)
  • עם כמה ממשקי רשת
  • עם Network Connectivity Center ‏(NCC)

מידע נוסף על האפשרות שכדאי לשקול בתכנון זמין במאמר ארכיטקטורת רשת מסוג Hub-and-spoke. גורם משפיע מרכזי בבחירת VPN במקום VPC Peering בין ה-spokes לבין ה-hub VPC הוא הצורך במעבר תנועה. תנועה טרנזיטיבית פירושה שתנועה מ-spoke יכולה להגיע ל-spokes אחרים דרך ה-hub.

ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון למיקרו-שירותים

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

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

באמצעות ארכיטקטורת proxy מבוזרת, כמו service mesh, השירותים יכולים לאמת ביעילות את המתקשרים וליישם מדיניות של בקרת גישה מפורטת לכל בקשה, וכך ליצור סביבת מיקרו-שירותים מאובטחת וניתנת להרחבה. ‫Cloud Service Mesh מאפשר לכם ליצור תשתית משותפת שמתאימה לפריסות שלכם ב-Google Cloud ובסביבה המקומית. ה-mesh משתמש במדיניות הרשאה כדי לאבטח את התקשורת בין השירותים.

אפשר גם לשלב את Apigee Adapter ל-Envoy בארכיטקטורה הזו. זהו פריסה קלה של שער Apigee API בתוך אשכול Kubernetes. ‫Apigee Adapter ל-Envoy הוא פרוקסי קצה ושירות בקוד פתוח שנועד לאפליקציות עם עדיפות לענן.

מידע נוסף בנושא הזה זמין במאמרים הבאים:

• ארכיטקטורה מבוזרת של אפס אמון
• סביבה היברידית של Google Kubernetes Engine‏ (GKE)
• התחברות אל Google
  • מחברים אשכול מקומי לGoogle Cloud רשת.
• הגדרה של רשת משולבת או רשת מרובת עננים
  • פריסת Cloud Service Mesh בסביבות ובאשכולות שונים.

שיטות מומלצות לשימוש בדפוסים משוכפלים

• מערכות ה-CI/CD שנדרשות לפריסה או להגדרה מחדש של פריסות בייצור צריכות להיות בעלות זמינות גבוהה. כלומר, כל רכיבי הארכיטקטורה צריכים להיות מתוכננים כך שיספקו את רמת הזמינות הצפויה של המערכת. מידע נוסף זמין במאמר בנושא Google Cloud מהימנות התשתית.
• כדי למנוע שגיאות בהגדרות של תהליכים חוזרים כמו עדכוני קוד, חשוב להשתמש באוטומציה כדי ליצור סטנדרטיזציה של גרסאות ה-build, הבדיקות והפריסות.
• שילוב של מכשירי NVA מרכזיים בתכנון הזה עשוי לדרוש שילוב של כמה פלחים עם רמות שונות של בקרות גישה לאבטחה.
• כשמתכננים פתרון שכולל מכשירי NVA, חשוב לקחת בחשבון את הזמינות הגבוהה (HA) של מכשירי ה-NVA כדי להימנע מנקודת כשל יחידה שעלולה לחסום את כל התקשורת. פועלים לפי ההנחיות לעיצוב ולהטמעה של זמינות גבוהה ויתירות שספק ה-NVA מספק.
• אם לא מייצאים מסלולי IP מקומיים דרך VPC Peering או VPN אל ה-VPC של הפיתוח והבדיקות, אפשר להגביל את יכולת ההגעה ברשת מסביבות הפיתוח והבדיקות אל הסביבה המקומית. מידע נוסף זמין במאמר בנושא החלפת מסלולים מותאמת אישית ב-VPC Network Peering.
• עבור עומסי עבודה עם כתובות IP פרטיות שעשויים לדרוש גישה לממשקי Google APIs, אפשר לחשוף את ממשקי Google APIs באמצעות נקודת קצה של Private Service Connect ברשת VPC. מידע נוסף זמין במאמר בנושא גישה מוגבלת בסדרה הזו.
• כדאי לעיין בשיטות המומלצות הכלליות לדפוסי ארכיטקטורה של רשתות היברידיות ורשתות מרובות עננים.

תבנית רשת

תבנית הרשת מבוססת על הקמת ארכיטקטורת רשת היברידית. הארכיטקטורה הזו משתרעת על פני כמה סביבות מחשוב. בסביבות האלה, כל המערכות יכולות לתקשר זו עם זו, והתקשורת לא מוגבלת לתקשורת חד-כיוונית על סמך דרישות האבטחה של האפליקציות. דפוס הרשת הזה רלוונטי בעיקר לארכיטקטורות של סביבה היברידית מדורגת, סביבה מרובת עננים עם חלוקה למחיצות או bursting. היא רלוונטית גם לתכנון המשכיות עסקית כדי להקצות סביבת התאוששות מאסון (DR) ב- Google Cloud. בכל המקרים, נדרש לחבר סביבות מחשוב באופן שתואם לדרישות התקשורת הבאות:

• עומסי עבודה יכולים לתקשר אחד עם השני בין גבולות הסביבה באמצעות כתובות IP פרטיות RFC 1918.
• כל אחד מהצדדים יכול ליזום את התקשורת. הפרטים הספציפיים של מודל התקשורת יכולים להשתנות בהתאם לאפליקציות ולדרישות האבטחה, כמו מודלי התקשורת שמוסברים באפשרויות העיצוב שבהמשך.
• כללי חומת האש שבהם אתם משתמשים צריכים לאפשר תנועה בין מקורות ויעדים ספציפיים של כתובות IP, בהתאם לדרישות של האפליקציה או האפליקציות שלשמן נועד הדפוס. מומלץ להשתמש בגישת אבטחה רב-שכבתית כדי להגביל את זרימת התנועה בצורה מדויקת, גם בין סביבות מחשוב וגם בתוכן.

ארכיטקטורה

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

• בכל הסביבות צריך להשתמש במרחב כתובות IP לפי RFC 1918 ללא חפיפה.
• בצד Google Cloud , אפשר לפרוס עומסי עבודה ב-VPC משותף אחד או יותר, או ב-VPC לא משותף. אפשרויות עיצוב נוספות של התבנית הזו מפורטות בהמשך. המבנה שנבחר של רשתות ה-VPC צריך להיות תואם לפרויקטים ולעיצוב היררכיית המשאבים של הארגון.
• רשת ה-VPC של Google Cloud מורחבת לסביבות מחשוב אחרות. הסביבות האלה יכולות להיות מקומיות או בענן אחר. משתמשים באחת מהאפשרויות של קישוריות היברידית וקישוריות בין כמה עננים שעונות על הדרישות של העסק והאפליקציה.

• הגבלת התקשורת רק לכתובות ה-IP המותרות של המקורות והיעדים. אפשר להשתמש באחת מהיכולות הבאות או בשילוב שלהן:

  • כללים של חומת אש או מדיניות של חומת אש.

  • מכשיר וירטואלי לרשת (NVA) עם יכולות בדיקה של חומת אש מהדור הבא (NGFW), שמוצב בנתיב הרשת.

  • ‫Cloud Next Generation Firewall Enterprise עם שירות למניעת חדירות (IPS) להטמעה של בדיקת מנות עמוקה למניעת איומים בלי לשנות את עיצוב הרשת או הניתוב.

וריאציות

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

• ‫VPC אחד לכל סביבה
• שימוש בחומת אש מרכזית בשכבת האפליקציה
• ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון למיקרו-שירותים

ענן וירטואלי פרטי (VPC) אחד לכל סביבה

הסיבות הנפוצות לבחירה באפשרות של VPC אחד לכל סביבה הן:

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

כפי שמודגם בדיאגרמה הבאה, העיצוב של VPC אחד לכל סביבה מאפשר לכל VPC להשתלב ישירות עם הסביבה המקומית או עם סביבות ענן אחרות באמצעות רשתות VPN, או באמצעות Cloud Interconnect עם כמה צירופים ל-VLAN.

אפשר להחיל את התבנית שמוצגת בתרשים הקודם על טופולוגיית רשת מסוג hub-and-spoke באזור נחיתה. בטופולוגיה הזו, אפשר לשתף חיבור היברידי יחיד (או כמה חיבורים היברידיים) עם כל רשתות ה-VPC מסוג spoke. הוא משותף באמצעות VPC מעבר כדי לסיים את הקישוריות ההיברידית ואת שאר רשתות ה-VPC המשניות. אפשר גם להרחיב את העיצוב הזה על ידי הוספת NVA עם יכולות בדיקה של חומת אש מהדור הבא (NGFW) ב-VPC של התעבורה, כפי שמתואר בקטע הבא, 'שימוש בחומת אש מרכזית של שכבת האפליקציה'.

שימוש בחומת אש מרכזית בשכבת האפליקציות

אם הדרישות הטכניות שלכם מחייבות שימוש בשכבת האפליקציה (שכבה 7) ובבדיקת מנות עמוקה עם יכולות מתקדמות של חומת אש שחורגות מהיכולות של Cloud Next Generation Firewall, אתם יכולים להשתמש במכשיר NGFW שמתארח ב-NVA. עם זאת, ה-NVA צריך לעמוד בדרישות האבטחה של הארגון. כדי להטמיע את המנגנונים האלה, אפשר להרחיב את הטופולוגיה כך שכל התנועה בין הסביבות תעבור דרך חומת אש מרכזית של NVA, כמו שמוצג בתרשים הבא.

אפשר להחיל את התבנית שמוצגת בתרשים הבא על העיצוב של אזור הנחיתה באמצעות טופולוגיה של רכזת וחישורים עם מכשירים מרכזיים:

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

ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון למיקרו-שירותים

כשמשתמשים באפליקציות מבוססות-קונטיינר, ארכיטקטורת המיקרו-שירות המבוזרת של zero trust שמתוארת בקטע תבנית משוכפלת רלוונטית גם לתבנית הארכיטקטורה הזו.

ההבדל העיקרי בין התבנית הזו לבין התבנית המשוקפת הוא שאפשר ליזום את מודל התקשורת בין עומסי עבודה ב- Google Cloud לבין סביבות אחרות משני הצדדים. צריך לשלוט בתעבורה בצורה מדויקת, על סמך דרישות האפליקציה ודרישות האבטחה, באמצעות Cloud Service Mesh.

שיטות מומלצות לגבי דפוסים משולבים

• לפני שעושים משהו אחר, צריך להחליט על העיצוב של היררכיית המשאבים ועל העיצוב שנדרש לתמיכה בכל פרויקט ו-VPC. הפעולה הזו יכולה לעזור לכם לבחור את ארכיטקטורת הרשת האופטימלית שתואמת למבנה של הפרויקטים שלכם ב- Google Cloud .
• מומלץ להשתמש בארכיטקטורה מבוזרת של אפס אמון כשמשתמשים ב-Kubernetes בסביבת מחשוב פרטית וב-Google Cloud.
• כשמשתמשים ב-NVAs מרכזיים בתכנון, צריך להגדיר כמה פלחים עם רמות שונות של בקרת גישה לאבטחה ומדיניות בדיקת תנועה. אמצעי הבקרה והמדיניות האלה צריכים להתבסס על דרישות האבטחה של האפליקציות שלכם.
• כשמתכננים פתרון שכולל מכשירי NVA, חשוב לקחת בחשבון את הזמינות הגבוהה (HA) של מכשירי ה-NVA כדי להימנע מנקודת כשל יחידה שעלולה לחסום את כל התקשורת. פועלים לפי ההנחיות לתכנון ולהטמעה של זמינות גבוהה ויתירות שסופקו על ידי ספק האבטחה שלGoogle Cloud שמספק את מכשירי ה-NVA.
• כדי לשפר את הפרטיות, את תקינות הנתונים ואת מודל התקשורת המבוקר, כדאי לחשוף את האפליקציות באמצעות ממשקי API עם שערים של ממשקי API, כמו Apigee ו-Apigee hybrid עם mTLS מקצה לקצה. אפשר גם להשתמש ב-VPC משותף עם Apigee באותו משאב ארגון.
• אם העיצוב של הפתרון שלכם מחייב חשיפה של אפליקציה מבוססת Google Cloud לאינטרנט הציבורי, כדאי לעיין בהמלצות העיצוב שמופיעות במאמר Networking for internet-facing application delivery.
• כדי להגן Google Cloud על השירותים בפרויקטים ולצמצם את הסיכון לזליגת נתונים, אפשר להשתמש ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות ברמת הפרויקט או ברמת רשת ה-VPC. בנוסף, אפשר להרחיב את היקף השירות לסביבה היברידית באמצעות VPN או Cloud Interconnect מורשים. מידע נוסף על היתרונות של גבולות גזרה לשירות זמין במאמר סקירה כללית על VPC Service Controls.
• כדאי לעיין בשיטות המומלצות הכלליות בנושא תבניות של רשתות היברידיות ורשתות מרובות עננים.

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

דפוסים עם שער

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

• יציאה עם שער

• Gated ingress

• תעבורת נתונים נכנסת ויוצאת עם שער (שער דו-כיווני בשני הכיוונים)

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

הערה: באופן כללי, אפשר להחיל את התבנית gated או לשלב אותה עם אפשרות העיצוב של אזור הנחיתה שחושפת את השירותים במודל צרכן-יצרן.

בסדרה הזו נדון בכל דפוס עם חסימה ובאפשרויות העיצוב האפשריות שלו. עם זאת, אפשרות עיצוב נפוצה שמתאימה לכל דפוסי הגישה המוגבלת היא ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון לאפליקציות בקונטיינרים עם ארכיטקטורת מיקרו-שירותים. האפשרות הזו מבוססת על Cloud Service Mesh,‏ Apigee ו-Apigee Adapter ל-Envoy – פריסת שער Apigee קל משקל באשכול Kubernetes. Apigee Adapter ל-Envoy הוא פרוקסי פופולרי של קצה ושירות בקוד פתוח, שמיועד לאפליקציות שמועברות לענן. הארכיטקטורה הזו שולטת בתקשורת מאובטחת משירות לשירות ובכיוון התקשורת ברמת השירות. אפשר לעצב, לכוונן ולהחיל מדיניות תקשורת של תנועה ברמת השירות על סמך הדפוס שנבחר.

דפוסי שער מאפשרים להטמיע את Cloud Next Generation Firewall Enterprise עם שירות למניעת חדירות (IPS) כדי לבצע בדיקה מעמיקה של מנות נתונים למניעת איומים, בלי לבצע שינויים בתכנון או בניתוב. הבדיקה הזו תלויה באפליקציות הספציפיות שאליהן ניגשים, במודל התקשורת ובדרישות האבטחה. אם דרישות האבטחה מחייבות בדיקה מעמיקה של מנות ברמה 7 עם מנגנוני חומת אש מתקדמים שחורגים מהיכולות של Cloud Next Generation Firewall, אפשר להשתמש בחומת אש מרכזית מהדור הבא (NGFW) שמתארחת במכשיר וירטואלי ברשת (NVA). יש כמה Google Cloud שותפים בתחום האבטחה שמציעים מכשירי NGFW שיכולים לעמוד בדרישות האבטחה שלכם. שילוב של מכשירי NVA עם דפוסי גישה מוגבלת כאלה עשוי לדרוש יצירה של כמה אזורי אבטחה בתכנון הרשת, שלכל אחד מהם יש רמות שונות של בקרת גישה.

תעבורת נתונים יוצאת (egress) עם שער

הארכיטקטורה של תבנית הרשת gated egress מבוססת על חשיפה של ממשקי API נבחרים מהסביבה המקומית או מסביבת ענן אחרת לעומסי עבודה שנפרסים ב- Google Cloud. היא עושה זאת בלי לחשוף אותם ישירות לאינטרנט הציבורי מסביבה מקומית או מסביבות ענן אחרות. אפשר להגביל את החשיפה באמצעות שער API או שרת proxy, או מאזן עומסים שמשמש כחזית לעומסי עבודה קיימים. אפשר לפרוס את הפונקציונליות של שער ה-API בפלח רשת מבודד, כמו רשת היקפית.

תבנית הרשת gated egress חלה בעיקר על (אבל לא מוגבלת ל) תבניות של ארכיטקטורת אפליקציות מדורגת ועל תבניות של ארכיטקטורת אפליקציות מחולקת. כשפורסים עומסי עבודה של קצה עורפי ברשת פנימית, יציאה מבוקרת (gated egress) ברשת עוזרת לשמור על רמת אבטחה גבוהה יותר בסביבת המחשוב המקומית. התבנית מחייבת חיבור של סביבות מחשוב באופן שעומד בדרישות התקשורת הבאות:

• עומסי עבודה שפורסים ב- Google Cloud יכולים לתקשר עם שער ה-API או מאזן העומסים (או נקודת קצה של Private Service Connect) שחושפים את האפליקציה באמצעות כתובות IP פנימיות.
• אי אפשר להגיע למערכות אחרות בסביבת המחשוב הפרטי ישירות מתוך Google Cloud.
• אסור ליצור תקשורת מסביבת המחשוב הפרטית לכל עומסי העבודה שנפרסו ב- Google Cloud .
• התנועה לממשקי ה-API הפרטיים בסביבות אחרות מתחילה רק מתוך סביבת Google Cloud .

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

• ‫API OAuth 2.0 עם Transport Layer Security‏ (TLS).
• הגבלת קצב של יצירת בקשות.
• מדיניות הגנה מפני איומים.
• הגדרת TLS דו-כיווני לקצה העורפי של שכבת ה-API.
• סינון לפי רשימת היתרים של כתובות IP מוגדר כך שרק מקורות ויעדים מוגדרים מראש של API מורשים לתקשר משני הצדדים.

כדי לאבטח את ה-proxy ל-API, כדאי לקחת בחשבון את היבטי האבטחה האחרים. מידע נוסף זמין במאמר שיטות מומלצות לאבטחת אפליקציות וממשקי API באמצעות Apigee.

ארכיטקטורה

התרשים הבא מציג ארכיטקטורת הפניה שתומכת בדרישות התקשורת שמופיעות בקטע הקודם:

הנתונים זורמים בתרשים שלמעלה באופן הבא:

• בצד Google Cloud , אפשר לפרוס עומסי עבודה בעננים וירטואליים פרטיים (VPC). יכול להיות שיהיה VPC אחד או כמה (משותפים או לא משותפים). הפריסה צריכה להתבצע בהתאם לפרויקטים ולעיצוב היררכיית המשאבים של הארגון.
• רשתות ה-VPC של סביבת Google Cloud מורחבות לסביבות מחשוב אחרות. הסביבות יכולות להיות מקומיות או בענן אחר. כדי לאפשר תקשורת בין סביבות באמצעות כתובות IP פנימיות, צריך להשתמש בקישוריות מתאימה של רשתות היברידיות ורשתות מרובות עננים.

• כדי להגביל את התנועה שמגיעה מכתובות IP ספציפיות של VPC ומיועדת לשערי גישה או למאזני עומסים מרוחקים, משתמשים בסינון של רשימת היתרים של כתובות IP. התנועה שחוזרת מהחיבורים האלה מותרת כשמשתמשים בכללים בחומת אש עם שמירת מצב. אפשר להשתמש בכל שילוב של היכולות הבאות כדי לאבטח את התקשורת ולהגביל אותה רק לכתובות ה-IP המותרות של המקור והיעד:

  • כללי חומת אש או מדיניות חומת אש.

  • מכשיר וירטואלי לרשת (NVA) עם יכולות בדיקה של חומת אש מהדור הבא (NGFW) שמוצב בנתיב הרשת.

  • ‫Cloud Next Generation Firewall Enterprise עם שירות למניעת חדירות (IPS) להטמעה של בדיקת מנות עמוקה למניעת איומים.

• כל הסביבות חולקות מרחב של כתובות IP מסוג RFC 1918 ללא חפיפה.

וריאציות

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

• שימוש ב- Google Cloud API Gateway ובחלק הקדמי הגלובלי
• חשיפת שירותים מרוחקים באמצעות Private Service Connect

שימוש ב- Google Cloud API gateway ובחלק הקדמי הגלובלי

בגישה הזו, החשיפה של ממשקי ה-API והניהול שלהם מתבצעים בתוך Google Cloud. כפי שמוצג בתרשים הקודם, אפשר לעשות זאת באמצעות הטמעה של Apigee כפלטפורמת ה-API. ההחלטה אם לפרוס שער API או איזון עומסים בסביבה המרוחקת תלויה בצרכים הספציפיים ובהגדרה הנוכחית שלכם. ב-Apigee יש שתי אפשרויות להקצאת קישוריות:

• עם קישור בין רשתות VPC שכנות (peering)
• ללא קישור בין רשתות VPC שכנות (peering)

Google Cloud יכולות גלובליות של קצה קדמי כמו Cloud Load Balancing,‏ Cloud CDN (כשניגשים דרך Cloud Interconnect) ו-Cross-Cloud Interconnect משפרות את המהירות שבה משתמשים יכולים לגשת לאפליקציות עם בק-אנד שמתארח בסביבות מקומיות ובסביבות ענן אחרות.

כדי לייעל את מהירויות העברת התוכן, האפליקציות האלה מועברות מ Google Cloud נקודות נוכחות (PoP). Google Cloud נקודות ה-PoP נמצאות ביותר מ-180 נקודות חילופי אינטרנט ויותר מ-160 מתקני קישוריות ברחבי העולם.

כדי להבין איך נקודות PoP עוזרות לספק ממשקי API עם ביצועים גבוהים כשמשתמשים ב-Apigee עם Cloud CDN כדי לבצע את הפעולות הבאות, כדאי לצפות בסרטון Delivering high-performing APIs with Apigee and Cloud CDN ב-YouTube:

• הפחתת זמן הטעינה.
• ממשקי API של מארחים ברחבי העולם.
• הגדלת הזמינות בזמנים של שיאי תנועה.

דוגמת העיצוב שמוצגת בתרשים הקודם מבוססת על Private Service Connect ללא קישור בין רשתות VPC.

הרשת הצפונית בתכנון הזה נוצרת באמצעות:

• מאזן עומסים (LB בתרשים), שבו מסתיימות בקשות הלקוח, מעבד את התעבורה ואז מעביר אותה לקצה עורפי של Private Service Connect.
• בק-אנד של Private Service Connect מאפשר ל Google Cloud מאזן עומסים לשלוח בקשות של לקוחות דרך חיבור Private Service Connect שמשויך לקובץ מצורף של שירות מנוהל לשירות שפורסם (מופע של זמן הריצה של Apigee) באמצעות קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect.

הרישות מדרום לצפון מתבצע באמצעות:

• נקודת קצה של Private Service Connect שמפנה אל קובץ מצורף לשירות שמשויך למאזן עומסים פנימי (ILB בתרשים) ב-VPC של הלקוח.

• מאזן העומסים הפנימי נפרס עם קבוצות של נקודות קצה ברשת (NEGs של קישוריות היברידית) של קישוריות היברידית.

• הגישה לשירותים היברידיים מתבצעת דרך ה-NEG של הקישוריות ההיברידית באמצעות קישוריות היברידית לרשת, כמו VPN או Cloud Interconnect.

מידע נוסף זמין במאמרים הגדרת מאזן עומסים פנימי אזורי מסוג Network עם קישוריות היברידית ודפוסי פריסה של Private Service Connect.

הערה: בהתאם לדרישות שלכם, אפשר לחשוף את ממשקי ה-API של השרתים העורפיים המקומיים באמצעות Apigee Hybrid, שער API או שרת proxy של צד שלישי או מאזן עומסים.

חשיפת שירותים מרוחקים באמצעות Private Service Connect

משתמשים באפשרות Private Service Connect כדי לחשוף שירותים מרוחקים בתרחישים הבאים:

• אתם לא משתמשים בפלטפורמת API או שאתם רוצים להימנע מחיבור ישיר של כל רשת ה-VPC שלכם לסביבה חיצונית מהסיבות הבאות:
  • יש לכם הגבלות אבטחה או דרישות תאימות.
  • יש חפיפה בטווח כתובות ה-IP, למשל בתרחיש של מיזוג ורכישה.
• כדי לאפשר תקשורת מאובטחת חד-כיוונית בין לקוחות, אפליקציות ושירותים בסביבות שונות, גם אם יש לכם מועד קצר.
• יכול להיות שתצטרכו לספק קישוריות לכמה רשתות VPC של צרכנים דרך רשת VPC של ספק שירותים (רשת VPC למעבר נתונים) כדי להציע מודלים של שירותים עם דיירים רבים או דייר יחיד, שניתנים להרחבה בקלות, כדי להגיע לשירותים שפורסמו בסביבות אחרות.

שימוש ב-Private Service Connect לאפליקציות שצורכות ממשקי API מספק כתובת IP פנימית לאפליקציות שפורסמו, ומאפשר גישה מאובטחת ברשת הפרטית באזורים שונים ובקישוריות היברידית. ההפשטה הזו מאפשרת לשלב משאבים מעננים שונים ומסביבות מקומיות באמצעות מודל קישוריות היברידי וריבוי עננים (multi-cloud). אתם יכולים להשתמש ב-Private Service Connect כדי לפרסם את השירות עם גישה מפורטת, וכך להאיץ את שילוב האפליקציות ולחשוף בצורה מאובטחת אפליקציות שנמצאות בסביבה מקומית בארגון או בסביבת ענן אחרת. במקרה כזה, אפשר להשתמש באפשרות הבאה:

• קובץ מצורף לשירות שמפנה אל מאזן עומסי רשת פנימי אזורי בשרת proxy או אל מאזן עומסים פנימי של אפליקציות (ALB).
  • מאזן העומסים משתמש ב-Hybrid Network Endpoint Group‏ (NEG) (קישוריות היברידית NEG) ב-VPC של היצרן, שפועל בתכנון הזה כ-VPC למעבר.

בתרשים שלמעלה, עומסי העבודה ברשת ה-VPC של האפליקציה יכולים להגיע לשירותים ההיברידיים שפועלים בסביבה המקומית או בסביבות ענן אחרות, דרך נקודת הקצה של Private Service Connect, כפי שמוצג בתרשים הבא. אפשרות התכנון הזו לתקשורת חד-כיוונית מספקת חלופה לחיבור VPC למעבר.

כחלק מהעיצוב בתרשים הקודם, כמה ממשקי קצה (frontend), קצוות עורפיים (backend) או נקודות קצה יכולים להתחבר לאותו שירות מצורף, וכך לאפשר לכמה רשתות VPC או לכמה צרכנים לגשת לאותו שירות. כפי שמוצג בתרשים הבא, אפשר להעניק לאפליקציה גישה לכמה רשתות VPC. הגישה הזו יכולה לעזור בתרחישים של שירותים מרובי דיירים שבהם השירות שלכם נצרך על ידי כמה רשתות VPC של צרכנים, גם אם טווחי כתובות ה-IP שלהם חופפים.

חפיפה של כתובות IP היא אחת הבעיות הנפוצות ביותר כשמשלבים אפליקציות שנמצאות בסביבות שונות. החיבור של Private Service Connect בתרשים הבא עוזר למנוע את הבעיה של חפיפה בכתובות ה-IP. היא עושה זאת בלי לדרוש הקצאה או ניהול של רכיבי רשת נוספים, כמו Cloud NAT או NVA, כדי לבצע את התרגום של כתובת ה-IP. דוגמה להגדרה מופיעה במאמר פרסום שירות היברידי באמצעות Private Service Connect.

היתרונות של העיצוב:

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

בשלבים מאוחרים יותר אפשר להרחיב את הגישה לתכנון שמוצגת בתרשים הקודם כדי לשלב את Apigee כפלטפורמת ה-API, באמצעות אפשרויות התכנון של הרשת שצוינו קודם, כולל האפשרות Private Service Connect.

כדי להפוך את נקודת הקצה של Private Service Connect לנגישה מאזורים אחרים, אפשר להשתמש בגישה גלובלית ל-Private Service Connect.

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

הערה: כדי לבצע בדיקות תקינות מבוזרות ולחבר כמה עננים וירטואליים פרטיים לסביבות מקומיות באמצעות כמה חיבורים היברידיים, צריך לשרשר מאזן עומסים של אפליקציות (ALB) פנימי עם מאזן עומסים של אפליקציות (ALB) חיצוני. מידע נוסף זמין במאמר שרשור מפורש של Google Cloud מאזני עומסים (LP) L7 עם PSC.

שיטות מומלצות

• יש כמה יתרונות לשימוש ב-Apigee וב-Apigee Hybrid כפתרון לפלטפורמת ה-API. הוא מספק שכבת proxy, והפשטה או חזית (facade) לממשקי ה-API של השירותים לקצה העורפי, בשילוב עם יכולות אבטחה, הגבלת קצב, מכסות וניתוח נתונים.
  • משתמשים ב-Apigee Adapter ל-Envoy עם ארכיטקטורה של פריסת Apigee Hybrid עם Kubernetes, אם זה מתאים לדרישות ולארכיטקטורה.
• העיצוב של רשתות VPC ופרויקטים ב- Google Cloud צריך להתבסס על היררכיית המשאבים ועל הדרישות של מודל התקשורת המאובטח.
• כשמשתמשים בממשקי API עם שערים, כדאי להשתמש גם ברשימת כתובות IP שאפשר לגשת אליהן. רשימת היתרים מגבילה את התקשורת למקורות וליעדים ספציפיים של כתובות IP של צרכני ה-API ושל שערים ל-API, שעשויים להיות מאוחסנים בסביבות שונות.
• משתמשים בכללי חומת אש של VPC או במדיניות חומת אש כדי לשלוט בגישה למשאבי Private Service Connect דרך נקודת הקצה של Private Service Connect.
• אם אפליקציה נחשפת חיצונית דרך מאזן עומסים של אפליקציות, כדאי להשתמש ב-Google Cloud Armor כשכבת אבטחה נוספת להגנה מפני מתקפות DDoS ואיומי אבטחה בשכבת האפליקציה.

• אם המכונות צריכות גישה לאינטרנט, צריך להשתמש ב-Cloud NAT ב-VPC של האפליקציה (הצרכן) כדי לאפשר לעומסי העבודה לגשת לאינטרנט. כך אפשר להימנע מהקצאה של כתובות IP ציבוריות חיצוניות למכונות וירטואליות במערכות שנפרסות מאחורי שער API או מאזן עומסים.

  • לתנועה יוצאת באינטרנט, אפשר להשתמש ב Google Cloud Secure Web Proxy. לפרוקסי יש כמה יתרונות.

• כדאי לעיין בשיטות המומלצות הכלליות בנושא תבניות של רשתות היברידיות ורשתות מרובות עננים.

תעבורת נתונים נכנסת (ingress) עם שער

הארכיטקטורה של התבנית gated ingress מבוססת על חשיפה של ממשקי API נבחרים של עומסי עבודה שפועלים ב- Google Cloud לסביבת המחשוב הפרטית, בלי לחשוף אותם לאינטרנט הציבורי. התבנית הזו היא המקבילה לתבנית של יציאה עם גישה מוגבלת והיא מתאימה לתרחישים של סביבה היברידית בקצה הרשת, סביבה היברידית מדורגת וסביבה מרובת עננים עם חלוקה למחיצות.

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

• עומסי עבודה שפורסים בסביבת מחשוב פרטית או בסביבות ענן אחרות יכולים לתקשר עם שער ה-API או עם מאזן העומסים באמצעות כתובות IP פנימיות. אי אפשר להגיע למערכות אחרות שפריסתן בוצעה ב-Google Cloud .
• אסור לשלוח תקשורת מ Google Cloud אל סביבת המחשוב הפרטי או אל סביבות ענן אחרות. התנועה מתחילה רק מהסביבה הפרטית או מסביבות ענן אחרות אל ממשקי ה-API ב- Google Cloud.

ארכיטקטורה

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

התיאור של הארכיטקטורה בתרשים שלמעלה:

• בצד Google Cloud , אתם פורסים עומסי עבודה ב-VPC של האפליקציה (או בכמה רשתות VPC).
• רשת הסביבה Google Cloud מתרחבת לסביבות מחשוב אחרות (בשרתים מקומיים או בענן אחר) באמצעות קישוריות רשת היברידית או רב-עננית, כדי לאפשר תקשורת בין הסביבות.
• אפשר גם להשתמש ב-VPC מעבר כדי לבצע את הפעולות הבאות:
  • הוספת שכבות אבטחה היקפיות כדי לאפשר גישה לממשקי API ספציפיים מחוץ ל-VPC של האפליקציה.
  • הפניית תנועה לכתובות ה-IP של ממשקי ה-API. אתם יכולים ליצור כללי חומת אש של VPC כדי למנוע ממקורות מסוימים לגשת לממשקי API מסוימים דרך נקודת קצה.
  • בודקים את התנועה בשכבה 7 ב-VPC של התנועה החולפת באמצעות שילוב של מכשיר וירטואלי לרשת (NVA).
• גישה לממשקי API דרך שער API או מאזן עומסים (שרת proxy או מאזן עומסים של אפליקציות) כדי לספק שכבת proxy ושכבת הפשטה או חזית לממשקי ה-API של השירות. אם אתם צריכים לפצל את תעבורת הנתונים בין כמה מופעים של API Gateway, אתם יכולים להשתמש במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
• מתן גישה מוגבלת ומפורטת לשירות שפורסם באמצעות נקודת קצה של Private Service Connect באמצעות שימוש במאזן עומסים דרך Private Service Connect כדי לחשוף אפליקציה או שירות.
• בכל הסביבות צריך להשתמש במרחב כתובות IP לפי RFC 1918 ללא חפיפה.

הדיאגרמה הבאה ממחישה את העיצוב של התבנית הזו באמצעות Apigee כפלטפורמת ה-API.

בתרשים הקודם, השימוש ב-Apigee כפלטפורמת API מספק את התכונות והיכולות הבאות כדי לאפשר את התבנית gated ingress:

• פונקציונליות של שער או שרת Proxy
• יכולות אבטחה
• הגבלת קצב של יצירת בקשות
• Analytics

בעיצוב:

• הקישוריות ברשת הצפונית (לתנועה שמגיעה מסביבות אחרות) עוברת דרך נקודת קצה (endpoint) של Private Service Connect ב-VPC של האפליקציה, שמשויכת ל-VPC של Apigee.
• ברשת ה-VPC של האפליקציה, נעשה שימוש במאזן עומסים פנימי כדי לחשוף את ממשקי ה-API של האפליקציה דרך נקודת קצה (endpoint) של Private Service Connect שמוצגת ברשת ה-VPC של Apigee. מידע נוסף זמין במאמר ארכיטקטורה עם השבתה של שירותי VPC.

• הגדרת כללים של חומת אש וסינון תעבורה ב-VPC של האפליקציה. כך תוכלו להגדיר גישה פרטנית ומבוקרת. הוא גם עוזר למנוע ממערכות להגיע ישירות לאפליקציות שלכם בלי לעבור דרך נקודת הקצה (endpoint) של Private Service Connect ו-API Gateway.

  בנוסף, אפשר להגביל את הפרסום של רשת המשנה של כתובת ה-IP הפנימית של עומס העבודה בעורף ברשת ה-VPC של האפליקציה לרשת המקומית, כדי למנוע גישה ישירה בלי לעבור דרך נקודת הקצה של Private Service Connect ושער ה-API.

יכול להיות שדרישות אבטחה מסוימות יחייבו בדיקת אבטחה היקפית מחוץ ל-VPC של האפליקציה, כולל תנועת נתונים של קישוריות היברידית. במקרים כאלה, אפשר לשלב VPC של תחב"צ כדי להטמיע שכבות אבטחה נוספות. השכבות האלה, כמו חומות אש מהדור הבא (NGFW) של מכשירי NVA עם ממשקי רשת מרובים, או Cloud Next Generation Firewall Enterprise עם שירות למניעת חדירות (IPS), מבצעות בדיקה מעמיקה של מנות מחוץ ל-VPC של האפליקציה, כפי שמוצג בתרשים הבא:

כפי שמוצג בתרשים שלמעלה:

• הקישוריות של הרשת לכיוון צפון (לתנועה שמגיעה מסביבות אחרות) עוברת דרך VPC מעבר נפרד אל נקודת הקצה של Private Service Connect ב-VPC המעבר שמשויך ל-VPC של Apigee.
• ברשת ה-VPC של האפליקציה, נעשה שימוש במאזן עומסים פנימי (ILB בתרשים) כדי לחשוף את האפליקציה דרך נקודת קצה (endpoint) של Private Service Connect ברשת ה-VPC של Apigee.

אפשר להקצות כמה נקודות קצה באותה רשת VPC, כמו שמוצג בדיאגרמה הבאה. כדי לכסות תרחישי שימוש שונים, אתם יכולים לשלוט בנתיבי הרשת האפשריים השונים באמצעות Cloud Router וכללי חומת אש של VPC. לדוגמה, אם אתם מחברים את הרשת המקומית שלכם אל Google Cloud באמצעות כמה חיבורים היברידיים לרשת, אתם יכולים לשלוח חלק מהתנועה מהרשת המקומית אל ממשקי Google API ספציפיים או שירותים שפורסמו דרך חיבור אחד, ואת שאר התנועה דרך חיבור אחר. בנוסף, אפשר להשתמש בגישה גלובלית ל-Private Service Connect כדי לספק אפשרויות למעבר לגיבוי במקרה של כשל.

וריאציות

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

• גישה לממשקי API של Google מסביבות אחרות

• חשיפת בק-אנדים של אפליקציות לסביבות אחרות באמצעות Private Service Connect

• שימוש בארכיטקטורת Hub and Spoke כדי לחשוף את ה-Back-end של האפליקציה לסביבות אחרות

גישה ל-Google APIs מסביבות אחרות

אם אתם צריכים לגשת לשירותי Google, כמו Cloud Storage או BigQuery, בלי לשלוח תעבורת נתונים דרך האינטרנט הציבורי, Private Service Connect הוא הפתרון בשבילכם. כפי שמוצג בתרשים הבא, הוא מאפשר גישה אל ממשקי ה-API והשירותים הנתמכים של Google (כולל מפות Google, ‏ Google Ads ו-Google Cloud) מסביבות מקומיות או מסביבות ענן אחרות, באמצעות חיבור לרשת היברידית דרך כתובת ה-IP של נקודת הקצה של Private Service Connect. מידע נוסף על גישה ל-Google APIs דרך נקודות קצה של Private Service Connect זמין במאמר מידע על גישה ל-Google APIs דרך נקודות קצה.

בתרשים שלמעלה, הרשת המקומית שלכם צריכה להיות מחוברת לרשת ה-VPC של התנועה (הצרכן) באמצעות מנהרות Cloud VPN או באמצעות קובץ מצורף של Cloud Interconnect VLAN.

אפשר לגשת אל Google APIs באמצעות נקודות קצה או שרתי קצה עורפיים. נקודות קצה מאפשרות לכם לטרגט חבילה של ממשקי Google API. בק-אנדים מאפשרים לכם לטרגט Google API אזורי ספציפי.

הערה: נקודות קצה של Private Service Connect נרשמות ב-Service Directory עבור Google APIs, שבו אפשר לאחסן, לנהל ולפרסם שירותים.

חשיפת קצוות עורפיים של אפליקציות לסביבות אחרות באמצעות Private Service Connect

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

בארכיטקטורה כזו, אפשר להשתמש ב-API Gateway מקומי או במאזן עומסים (LB) בסביבה מקומית פרטית, או בסביבות ענן אחרות, כדי לחשוף ישירות את הקצה הקדמי של האפליקציה לאינטרנט הציבורי. שימוש ב-Private Service Connect ב- Google Cloud מאפשר קישוריות פרטית לבק-אנדים שנחשפים דרך נקודת קצה של Private Service Connect, באופן אידיאלי באמצעות ממשקי API מוגדרים מראש, כפי שמוצג בתרשים הבא:

העיצוב בתרשים הקודם מבוסס על פריסה של Apigee Hybrid שכוללת מישור ניהול ב- Google Cloud ומישור זמן ריצה שמתארח בסביבה אחרת. אפשר להתקין ולנהל את מישור זמן הריצה בשער API מבוזר באחת מפלטפורמות Kubernetes הנתמכות בסביבה המקומית או בסביבות ענן אחרות. בהתאם לדרישות שלכם לעומסי עבודה מבוזרים ב- Google Cloud ובסביבות אחרות, אתם יכולים להשתמש ב-Apigee ב- Google Cloud עם Apigee Hybrid. מידע נוסף מופיע במאמר בנושא שערי API מבוזרים.

שימוש בארכיטקטורת רכזת וחישורים כדי לחשוף את העורפים של האפליקציות לסביבות אחרות

בתרחישים מסוימים, יכול להיות שיהיה צורך לחשוף ממשקי API משרתי קצה עורפיים של אפליקציות שמתארחים ב- Google Cloud ברשתות VPC שונות. כפי שמודגם בתרשים הבא, רשת VPC מרכזית משמשת כנקודה מרכזית לחיבור בין רשתות ה-VPC השונות (רשתות משנה), ומאפשרת תקשורת מאובטחת באמצעות קישוריות פרטית היברידית. אפשר גם להשתמש ביכולות של שער API מקומי בסביבות אחרות, כמו Apigee Hybrid, כדי להפסיק את הבקשות של הלקוח באופן מקומי במקום שבו מתארח קצה קדמי של האפליקציה.

כפי שמוצג בתרשים שלמעלה:

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

• העיצוב הזה מניח שרשתות VPC מסוג Spoke לא צריכות תקשורת ישירה בין רשתות VPC.

  • אם נדרשת תקשורת בין רכזות, אפשר להשתמש ב-NVA כדי לאפשר תקשורת כזו.
  • אם יש לכם בק-אנדים שונים ברשתות VPC שונות, אתם יכולים להשתמש ב-Private Service Connect כדי לחשוף את הבק-אנדים האלה ל-VPC של Apigee.
  • אם משתמשים בקישור בין רשתות VPC שכנות (peering) לחיבורים צפונה ודרומה בין רשתות VPC מסוג spoke לבין רשת VPC מסוג hub, צריך לקחת בחשבון את ההגבלה על טרנזיטיביות של רשתות VPC באמצעות קישור בין רשתות VPC שכנות. כדי לעקוף את ההגבלה הזו, אפשר להשתמש באחת מהאפשרויות הבאות:
    • כדי לקשר בין רשתות ה-VPC, משתמשים ב-NVA.
    • במקרים הרלוונטיים, כדאי לשקול את המודל של Private Service Connect.
    • כדי ליצור קישוריות בין ה-VPC של Apigee לבין שרתים עורפיים שנמצאים בGoogle Cloud פרויקטים אחרים באותו ארגון בלי להשתמש ברכיבי רשת נוספים, צריך להשתמש בVPC משותף.

• אם נדרשים מכשירי NVA לבדיקת תנועה – כולל תנועה מהסביבות האחרות שלכם – החיבור ההיברידי לסביבות מקומיות או לסביבות ענן אחרות צריך להסתיים ב-VPC ההיברידי.

• אם העיצוב לא כולל את NVA, אפשר לסיים את הקישוריות ההיברידית ב-VPC של הרכזת.

• אם נדרשות פונקציות מסוימות של איזון עומסים או יכולות אבטחה, כמו הוספת הגנה מפני מתקפות DDoS או WAF של Google Cloud Armor, אפשר לפרוס מאזן עומסים חיצוני של אפליקציות (ALB) בהיקף דרך VPC חיצוני לפני ניתוב בקשות של לקוחות חיצוניים אל השרתים העורפיים.

שיטות מומלצות

• במקרים שבהם צריך לקבל באופן מקומי בקשות של לקוחות מהאינטרנט, שמתארחות בחזית קצה קדמי פרטית במקום או בסביבת ענן אחרת, כדאי להשתמש ב-Apigee Hybrid כפתרון לשער API. הגישה הזו גם מאפשרת לבצע בצורה חלקה העברה של הפתרון לסביבה שמתארחת באופן מלא ב- Google Cloud, תוך שמירה על העקביות של פלטפורמת ה-API‏ (Apigee).
• משתמשים ב-Apigee Adapter ל-Envoy עם ארכיטקטורה של פריסת Apigee Hybrid עם Kubernetes, אם זה מתאים לדרישות ולארכיטקטורה.
• העיצוב של רשתות VPC ופרויקטים ב- Google Cloud צריך לעמוד בדרישות של היררכיית המשאבים ומודל התקשורת המאובטח, כפי שמתואר במדריך הזה.
• שילוב של רשת VPC למעבר בתכנון הזה מאפשר גמישות באספקת אמצעי אבטחה נוספים למערך וקישוריות היברידית מחוץ לרשת ה-VPC של עומס העבודה.
• שימוש ב-Private Service Connect כדי לגשת לממשקי Google APIs ולשירותים מסביבות מקומיות או מסביבות ענן אחרות באמצעות כתובת ה-IP הפנימית של נקודת הקצה ברשת קישוריות היברידית. מידע נוסף זמין במאמר גישה לנקודת הקצה ממארחים מקומיים.
• כדי להגן Google Cloud על השירותים בפרויקטים ולצמצם את הסיכון לזליגת נתונים, אפשר להשתמש ב-VPC Service Controls כדי לציין גבולות גזרה לשירות ברמת הפרויקט או ברמת רשת ה-VPC.
  • במקרה הצורך, אפשר להרחיב את גבולות הגזרה של השירות לסביבה היברידית באמצעות VPN או Cloud Interconnect. מידע נוסף על היתרונות של גבולות גזרה לשירות זמין במאמר סקירה כללית על VPC Service Controls.
• משתמשים בכללי חומת אש של VPC או בכללי מדיניות של חומת אש כדי לשלוט בגישה ברמת הרשת למשאבי Private Service Connect דרך נקודת הקצה של Private Service Connect. לדוגמה, כללי חומת אש לתעבורה יוצאת ב-VPC של האפליקציה (הלקוח) יכולים להגביל את הגישה ממכונות וירטואליות לכתובת ה-IP או לרשת המשנה של נקודות הקצה שלכם. מידע נוסף על הכללים של חומת האש ב-VPC זמין במאמר בנושא הכללים של חומת האש ב-VPC.
• כשמתכננים פתרון שכולל מכשירי NVA, חשוב לקחת בחשבון את הזמינות הגבוהה (HA) של מכשירי ה-NVA כדי להימנע מנקודת כשל יחידה שעלולה לחסום את כל התקשורת. פועלים לפי ההנחיות לעיצוב ולהטמעה של זמינות גבוהה ויתירות שספק ה-NVA מספק.
• כדי לחזק את אבטחת ההיקף ולאבטח את שער ה-API שנפרס בסביבה המתאימה, אפשר להטמיע מנגנונים של איזון עומסים וחומת אש של אפליקציות אינטרנט בסביבת המחשוב האחרת (היברידית או בענן אחר). צריך להטמיע את האפשרויות האלה ברשת ההיקפית שמחוברת ישירות לאינטרנט.
• אם המכונות צריכות גישה לאינטרנט, צריך להשתמש ב-Cloud NAT ב-VPC של האפליקציה כדי לאפשר לעומסי העבודה לגשת לאינטרנט. כך תוכלו להימנע מהקצאת כתובות IP חיצוניות ציבוריות למכונות וירטואליות במערכות שנפרסות מאחורי API Gateway או מאזן עומסים.
• לתנועה באינטרנט יוצאת, צריך להשתמש ב-Secure Web Proxy. לפרוקסי יש כמה יתרונות.
• כדאי לעיין בשיטות המומלצות הכלליות בנושא תבניות של רשתות היברידיות ורשתות מרובות עננים.

תעבורת נתונים יוצאת (egress) עם שער ותעבורת נתונים נכנסת (ingress) עם שער

בדפוס gated egress ו-gated ingress נעשה שימוש בשילוב של gated egress ו-gated ingress בתרחישים שבהם נדרש שימוש דו-כיווני בממשקי API נבחרים בין עומסי עבודה. עומסי עבודה יכולים לפעול ב- Google Cloud, בסביבות פרטיות מקומיות או בסביבות ענן אחרות. בדפוס הזה, אתם יכולים להשתמש בשערי API, בנקודות קצה של Private Service Connect או במאזני עומסים כדי לחשוף ממשקי API ספציפיים, ובאופן אופציונלי לספק אימות, הרשאה וביקורת על קריאות ל-API.

ההבדל העיקרי בין התבנית הזו לבין תבנית הרשת הוא שהתבנית הזו מתאימה לתרחישים שבהם נדרש שימוש דו-כיווני ב-API או תקשורת עם מקורות ויעדים של כתובות IP ספציפיות – לדוגמה, אפליקציה שפורסמה דרך נקודת קצה של Private Service Connect. מכיוון שהתקשורת מוגבלת לממשקי API חשופים או לכתובות IP ספציפיות, אין צורך שתהיה התאמה בין הרשתות בסביבות השונות בתכנון שלכם. תרחישים נפוצים שבהם כדאי להשתמש בפידים משלימים כוללים, בין היתר:

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

התקשורת פועלת באופן הבא:

• עומסי עבודה שפורסים ב- Google Cloud יכולים לתקשר עם שער ה-API (או עם כתובות IP ספציפיות של יעד) באמצעות כתובות IP פנימיות. אי אפשר להגיע למערכות אחרות שנפרסו בסביבת המחשוב הפרטית.
• לעומת זאת, עומסי עבודה שאתם פורסים בסביבות מחשוב אחרות יכולים לתקשר עם שער ה-API בצד Google Cloud(או עם כתובת IP ספציפית של נקודת קצה שפורסמה) באמצעות כתובות IP פנימיות. אי אפשר להגיע למערכות אחרות שנפרסו ב- Google Cloud .

ארכיטקטורה

בתרשים הבא מוצגת ארכיטקטורת הפניה לדפוס של יציאה מוגבלת וכניסה מוגבלת:

הגישה העיצובית בתרשים שלמעלה כוללת את הרכיבים הבאים:

• בצד Google Cloud , אתם פורסים עומסי עבודה ב-VPC (או ב-VPC משותף) בלי לחשוף אותם ישירות לאינטרנט.
• הרשת Google Cloud הסביבתית מורחבת לסביבות מחשוב אחרות. הסביבה הזו יכולה להיות מקומית או בענן אחר. כדי להרחיב את הסביבה, משתמשים בדפוס תקשורת מתאים לקישוריות היברידית ורב-ענן כדי לאפשר תקשורת בין סביבות, כך שיוכלו להשתמש בכתובות IP פנימיות.
• אפשרות נוספת היא להפעיל גישה לכתובות IP ספציפיות של יעדים. כך תוכלו להשתמש ב-VPC מעבר כדי להוסיף שכבת אבטחה היקפית מחוץ ל-VPC של האפליקציה.
  • אתם יכולים להשתמש ב-Cloud Next Generation Firewall או במכשירים וירטואליים ברשת (NVA) עם חומות אש מהדור הבא (NGFW) ב-VPC של המעבר כדי לבדוק את התעבורה ולאפשר או לאסור גישה לממשקי API מסוימים ממקורות ספציפיים לפני שהם מגיעים ל-VPC של האפליקציה.
• צריך לגשת לממשקי API דרך שער API או מאזן עומסים כדי לספק שכבת proxy, וגם הפשטה או חזית לממשקי ה-API של השירות.
• באפליקציות שמוצגות כ-API, אפשר גם להשתמש ב-Private Service Connect כדי לספק כתובת IP פנימית לאפליקציה שפורסמה.
• בכל הסביבות נעשה שימוש בטווח כתובות IP לפי RFC 1918 ללא חפיפה.

יישום נפוץ של התבנית הזו כולל פריסה של בק-אנד של אפליקציה (או קבוצת משנה של בק-אנד של אפליקציה) ב- Google Cloud , תוך אירוח של רכיבי בק-אנד וקצה קדמי אחרים בסביבות מקומיות או בעננים אחרים (תבנית tiered hybrid או תבנית partitioned multicloud). כשאפליקציות מתפתחות ועוברות לענן, נוצרים לרוב יחסי תלות והעדפות לשירותי ענן ספציפיים.

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

באפליקציות מבוזרות, אפשר להשתמש ביכולות של חיבור היברידי וחיבור מרובה עננים של Cloud Load Balancing חיצוני כדי להפסיק בקשות של משתמשים ולהפנות אותן לקצה הקדמי או לקצה העורפי בסביבות אחרות. הניתוב הזה מתבצע דרך חיבור לרשת היברידית, כפי שמוצג בתרשים הבא. השילוב הזה מאפשר הפצה הדרגתית של רכיבי אפליקציה בסביבות שונות. בקשות מחזית האפליקציה לשירותים לקצה העורפי שמתארחים ב- Google Cloud מתקשרות בצורה מאובטחת דרך חיבור הרשת ההיברידית שנוצר באמצעות מאזן עומסים פנימי (ILB בתרשים).

השימוש Google Cloud בעיצוב שמוצג בתרשים שלמעלה עוזר במקרים הבאים:

• הוא מאפשר תקשורת דו-כיוונית בין Google Cloud, בין סביבות מקומיות ובין סביבות ענן אחרות באמצעות ממשקי API מוגדרים מראש בשני הצדדים, שתואמים למודל התקשורת של התבנית הזו.
• כדי לספק ממשקי קצה גלובליים לאפליקציות שפונות לאינטרנט עם רכיבי אפליקציה מבוזרים (ממשקי קצה או קצה עורפי), וכדי להשיג את המטרות הבאות, אתם יכולים להשתמש ביכולות המתקדמות של איזון עומסים ואבטחה של Google Cloud שמפוזרים בנקודות נוכחות (PoPs):
• שימוש בשירותים מנוהלים ללא שרתים מאפשר להפחית את הוצאות ההון ולפשט את הפעולות.
• אופטימיזציה של חיבורים לשרתי קצה עורפיים של אפליקציות באופן גלובלי לשיפור המהירות וזמן האחזור.
  • Google Cloud רשת חוצת עננים מאפשרת תקשורת בין רכיבי אפליקציה בענן מרובה באמצעות חיבורים פרטיים אופטימליים.
• כדי לשפר את הביצועים של אפליקציות שמשתמשות ב-Cloud Load Balancing גלובלי, אפשר לספק גישה ל-Cloud CDN כדי לשמור במטמון תוכן סטטי עם ביקוש גבוה.
• אבטחת ממשקי הקצה הגלובליים של אפליקציות שפונות לאינטרנט באמצעות היכולות של Google Cloud Armor, שמספקות חומת אש ליישומי אינטרנט (WAF) ושירותים לצמצום מתקפות DDoS בפריסה גלובלית.
• אפשר גם לשלב את Private Service Connect בתכנון. השימוש ב-Private Service Access מאפשר גישה פרטית ומפורטת ל-API של שירותים Google Cloud או לשירותים שפרסמתם מסביבות אחרות, בלי לעבור דרך האינטרנט הציבורי.

וריאציות

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

• שערי API מבוזרים
• תקשורת דו-כיוונית בין ממשקי API באמצעות Private Service Connect
• תקשורת דו-כיוונית באמצעות נקודות קצה וממשקים של Private Service Connect

שערי API מבוזרים

בתרחישים כמו זה שמבוסס על דפוס של מרובה עננים (multi-cloud) מחולק, אפשר לבנות אפליקציות (או רכיבי אפליקציות) בסביבות ענן שונות – כולל סביבה פרטית מקומית. הדרישה הנפוצה היא לנתב בקשות של לקוחות לחלק הקדמי של האפליקציה ישירות לסביבה שבה האפליקציה (או רכיב החלק הקדמי) מתארחת. כדי להשתמש בסוג התקשורת הזה, צריך מאזן עומסים מקומי או שער API. יכול להיות שהאפליקציות האלה והרכיבים שלהן ידרשו גם יכולות ספציפיות של פלטפורמת API לצורך שילוב.

בתרשים הבא מוצג איך Apigee ו-Apigee Hybrid מתוכננים לתת מענה לדרישות כאלה באמצעות שער API מקומי בכל סביבה. ניהול פלטפורמת ה-API מרוכז ב- Google Cloud. העיצוב הזה עוזר לאכוף אמצעי בקרה מחמירים על הגישה, כך שרק כתובות IP שאושרו מראש (כתובות IP של יעד ושל API או כתובות IP של נקודת קצה של Private Service Connect) יכולות לתקשר בין Google Cloud לבין הסביבות האחרות.

ברשימה הבאה מתוארים שני נתיבי תקשורת שונים בתרשים שלמעלה שמשתמשים בשער ה-API של Apigee:

• בקשות של לקוחות מגיעות לחלק הקדמי של האפליקציה ישירות בסביבה שמארחת את האפליקציה (או את רכיב החלק הקדמי).
• שערי API ושרתי proxy בכל סביבה מטפלים בבקשות API של לקוחות ואפליקציות בכיוונים שונים בכמה סביבות.
  • הפונקציונליות של API Gateway ב- Google Cloud(Apigee) חושפת את רכיבי האפליקציה (קצה קדמי או בק-אנד) שמארחים ב- Google Cloud.
  • הפונקציונליות של שער ה-API בסביבה אחרת (היברידית) חושפת את רכיבי חזית האפליקציה (או העורף שלה) שמתארחים בסביבה הזו.

אפשר גם להשתמש ב-VPC למעבר. רשת VPC למעבר יכולה לספק גמישות להפרדה בין נושאים ולביצוע בדיקת אבטחה וקישוריות היברידית ברשת VPC נפרדת. מבחינת נגישות לכתובת IP, רשת VPC למעבר (שבה מצורפת הקישוריות ההיברידית) מאפשרת לעמוד בדרישות הבאות כדי לשמור על נגישות מקצה לקצה:

• צריך לפרסם את כתובות ה-IP של ממשקי ה-API לטירגוט בסביבות האחרות שבהן מתארחים לקוחות או שולחי בקשות.
• צריך לפרסם את כתובות ה-IP של המארחים שצריכים לתקשר עם ממשקי ה-API של היעד בסביבה שבה נמצא ה-API של היעד – לדוגמה, כתובות ה-IP של שולח הבקשה ל-API (הלקוח). החריג הוא כשמתבצעת תקשורת דרך מאזן עומסים, שרת proxy, נקודת קצה של Private Service Connect או מופע NAT.

כדי להרחיב את הקישוריות לסביבה המרוחקת, העיצוב הזה משתמש ב-VPC ישיר עם יכולת החלפת נתיבים של לקוחות. העיצוב מאפשר לבקשות API ספציפיות שמקורן בעומסי עבודה (workloads) שמתארחים ב-VPC של האפליקציה Google Cloud לעבור דרך ה-VPC של המעבר. לחלופין, אפשר להשתמש בנקודת קצה של Private Service Connect ב-VPC של האפליקציה שמשויך למאזן עומסים עם קצה עורפי של קבוצת נקודות קצה ברשת היברידית ב-VPC של המעבר. ההגדרה הזו מתוארת בקטע הבא: תקשורת דו-כיוונית בין ממשקי API באמצעות Private Service Connect.

תקשורת דו-כיוונית בין ממשקי API באמצעות Private Service Connect

לפעמים, יכול להיות שארגונים לא יצטרכו להשתמש בשער API (כמו Apigee) באופן מיידי, או שירצו להוסיף אותו מאוחר יותר. עם זאת, יכול להיות שיהיו דרישות עסקיות להפעלת תקשורת ושילוב בין אפליקציות מסוימות בסביבות שונות. לדוגמה, אם החברה שלכם רכשה חברה אחרת, יכול להיות שתצטרכו לחשוף אפליקציות מסוימות לחברה הזו. יכול להיות שהם יצטרכו לחשוף אפליקציות לחברה שלכם. יכול להיות שלכל אחת מהחברות יש עומסי עבודה משלה שמתארחים בסביבות שונות (Google Cloud, מקומיות או בעננים אחרים), והן צריכות להימנע מחפיפה בכתובות ה-IP. במקרים כאלה, אפשר להשתמש ב-Private Service Connect כדי לאפשר תקשורת יעילה.

באפליקציות שמוצגות כ-API, אפשר גם להשתמש ב-Private Service Connect כדי לספק כתובת פרטית לאפליקציות שפורסמו, וכך לאפשר גישה מאובטחת ברשת הפרטית באזורים שונים ודרך קישוריות היברידית. ההפשטה הזו מאפשרת לשלב משאבים מעננים שונים ומסביבות מקומיות באמצעות מודל קישוריות היברידי וריבוי עננים (multi-cloud). הוא גם מאפשר להרכיב אפליקציות בסביבות מרובות עננים ובסביבות מקומיות. האפשרות הזו יכולה לענות על דרישות תקשורת שונות, כמו שילוב של אפליקציות מאובטחות שבהן לא נעשה שימוש בשער API או שלא מתוכנן שימוש כזה.

כפי שמוצג בתרשים הבא, אפשר להשתמש ב-Private Service Connect עם Cloud Load Balancing כדי ליצור שני נתיבי תקשורת נפרדים. כל נתיב מתחיל בכיוון אחר למטרה אחרת של קישוריות, באופן אידיאלי באמצעות קריאות ל-API.

• כל ההמלצות והשיקולים לגבי עיצוב של Private Service Connect שמופיעים במדריך הזה רלוונטיים לעיצוב הזה.
• אם נדרשת בדיקה נוספת בשכבה 7, אפשר לשלב NVAs עם העיצוב הזה (ב-VPC של התעבורה).
• אפשר להשתמש בעיצוב הזה עם או בלי שערים של API.

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

תקשורת דו-כיוונית באמצעות נקודות קצה וממשקים של Private Service Connect

כפי שמוסבר בדפוס של תעבורת נתונים נכנסת (ingress) עם גישה מוגבלת, אחת מהאפשרויות לאפשר תקשורת בין לקוח לשירות היא באמצעות נקודת קצה (endpoint) של Private Service Connect כדי לחשוף שירות ב-VPC של יצרן ל-VPC של צרכן. אפשר להרחיב את הקישוריות הזו לסביבה מקומית או אפילו לסביבה של ספק אחר של שירותי ענן באמצעות קישוריות היברידית. עם זאת, בתרחישים מסוימים, השירות המתארח יכול לדרוש גם תקשורת פרטית.

כדי לגשת לשירות מסוים, כמו אחזור נתונים ממקורות נתונים שיכולים להיות מאוחסנים ב-VPC של הצרכן או מחוצה לו, התקשורת הפרטית הזו יכולה להיות בין ה-VPC של האפליקציה (היצרן) לבין סביבה מרוחקת, כמו סביבה מקומית.

בתרחיש כזה, ממשקי Private Service Connect מאפשרים למכונה וירטואלית של בעלים של שירות מנוהל לגשת לרשת של צרכן. היא עושה זאת על ידי שיתוף ממשק רשת, תוך שמירה על ההפרדה בין תפקידי היוצר והצרכן. ממשק הרשת הזה ב-VPC של הצרכן מאפשר למכונה הוירטואלית של האפליקציה לגשת למשאבים של הצרכן כאילו הם נמצאים באופן מקומי ב-VPC של היצרן.

ממשק Private Service Connect הוא ממשק רשת שמצורף ל-VPC של הצרכן (המעבר). אפשר להגיע ליעדים חיצוניים שאפשר להגיע אליהם מרשת ה-VPC של הצרכן (טרנזיט) שאליה מצורף הממשק של Private Service Connect. לכן, אפשר להרחיב את החיבור הזה לסביבה חיצונית באמצעות קישוריות היברידית, כמו סביבה מקומית, כפי שמוצג בתרשים הבא:

אם רשת ה-VPC של הצרכן שייכת לארגון או לישות חיצוניים, כמו ארגון צד שלישי, בדרך כלל לא תהיה לכם אפשרות לאבטח את התקשורת עם ממשק Private Service Connect ברשת ה-VPC של הצרכן. במקרה כזה, אפשר להגדיר מדיניות אבטחה במערכת ההפעלה של האורח במכונה הווירטואלית של ממשק Private Service Connect. מידע נוסף זמין במאמר הגדרת אבטחה לממשקי Private Service Connect. לחלופין, אפשר לשקול גישה אחרת אם היא לא עומדת בתקנים או בדרישות התאימות לאבטחה של הארגון.

שיטות מומלצות

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

  • הגישה הזו גם מאפשרת להעביר את הפתרון לסביבה שמארחת את כל הנתונים ב- Google Cloudתוך שמירה על העקביות של פלטפורמת ה-API‏ (Apigee).

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

  • משתמשים ב-Cloud Interconnect או ב-Cross-Cloud Interconnect.
  • כדי לסיים את החיבורים של המשתמשים בחלק הקדמי המטורגט בסביבה המתאימה, צריך להשתמש ב-Hybrid.

• במקרים שבהם זה רלוונטי לדרישות ולארכיטקטורה שלכם, כדאי להשתמש ב-Apigee Adapter for Envoy עם פריסה היברידית באמצעות Kubernetes.

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

• כדי להגן על שירותים Google Cloud בפרויקטים ולצמצם את הסיכון לזליגת נתונים, אפשר להשתמש ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות ברמת הפרויקט או ברמת רשת ה-VPC.

  • אפשר להרחיב את גבולות הגזרה של השירות לסביבה היברידית באמצעות VPN מורשה או Cloud Interconnect. מידע נוסף על היתרונות של גבולות גזרה לשירות זמין במאמר סקירה כללית על VPC Service Controls.

• כדי לשלוט בגישה ברמת הרשת למשאבי Private Service Connect דרך נקודת הקצה של Private Service Connect, אפשר להשתמש בכללי חומת אש של ענן וירטואלי פרטי (VPC) או במדיניות חומת אש. לדוגמה, כללי חומת אש לתעבורה יוצאת ב-VPC של האפליקציה (הלקוח) יכולים להגביל את הגישה ממכונות וירטואליות לכתובת ה-IP או לרשת המשנה של נקודות הקצה שלכם.

• כשמשתמשים בממשק Private Service Connect, צריך להגן על התקשורת עם הממשק על ידי הגדרת אבטחה לממשק Private Service Connect.

• אם עומס עבודה ברשת משנה פרטית דורש גישה לאינטרנט, כדאי להשתמש ב-Cloud NAT כדי להימנע מהקצאת כתובת IP חיצונית לעומס העבודה ומחשיפתו לאינטרנט הציבורי.

  • לתנועה באינטרנט יוצאת, צריך להשתמש ב-Secure Web Proxy. לפרוקסי יש כמה יתרונות.

• כדאי לעיין בשיטות המומלצות הכלליות בנושא תבניות של רשתות היברידיות ורשתות מרובות עננים.

דפוסי העברה

בדפוס ההעברה, הארכיטקטורה מבוססת על שימוש בשירותי אחסון שסופקו על ידיGoogle Cloudכדי לחבר סביבת מחשוב פרטית לפרויקטים ב- Google Cloud. התבנית הזו רלוונטית בעיקר להגדרות שמתבססות על תבנית הארכיטקטורה של ניתוח נתונים בענן היברידי מרובה עננים, שבה:

• עומסי עבודה שפועלים בסביבת מחשוב פרטית או בענן אחר מעלים נתונים למיקומי אחסון משותפים. בהתאם לתרחישי השימוש, יכול להיות שההעלאות יתבצעו בכמויות גדולות או במנות קטנות יותר.
• עומסי עבודה שמתארחים ב-Google Cloudאו שירותי Google אחרים (לדוגמה, שירותי ניתוח נתונים ובינה מלאכותית) צורכים נתונים ממיקומי האחסון המשותפים ומעבדים אותם בסטרימינג או באצווה.

ארכיטקטורה

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

בתרשים הארכיטקטורה שלמעלה מוצגים תהליכי העבודה הבאים:

• בצד Google Cloud , פורסים עומסי עבודה ברשת VPC של אפליקציה. עומסי העבודה האלה יכולים לכלול עיבוד נתונים, ניתוח ויישומים חזיתיים שקשורים לניתוח.
• כדי לחשוף באופן מאובטח אפליקציות frontend למשתמשים, אפשר להשתמש ב-Cloud Load Balancing או ב-API Gateway.
• קבוצה של קטגוריות Cloud Storage או תורים של Pub/Sub מעלים נתונים מסביבת המחשוב הפרטית והופכים אותם לזמינים לעיבוד נוסף על ידי עומסי עבודה שנפרסו ב- Google Cloud. באמצעות כללי המדיניות של ניהול זהויות והרשאות גישה (IAM), אתם יכולים להגביל את הגישה לעומסי עבודה מהימנים.
• שימוש ב-VPC Service Controls כדי להגביל את הגישה לשירותים ולצמצם את הסיכונים לזליגת נתונים לא רצויה משירותי Google Cloud .
• בארכיטקטורה הזו, התקשורת עם קטגוריות של Cloud Storage או עם Pub/Sub מתבצעת ברשתות ציבוריות, או באמצעות קישוריות פרטית באמצעות VPN,‏ Cloud Interconnect או Cross-Cloud Interconnect. בדרך כלל, ההחלטה לגבי אופן החיבור תלויה בכמה היבטים, כמו אלה:
  • נפח תנועת גולשים צפוי
  • האם מדובר בהגדרה זמנית או קבועה
  • דרישות אבטחה ותאימות

גרסה נוספת

אפשר גם להשתמש באפשרויות העיצוב שמפורטות בתבנית של כניסה מוגבלת, שבה נעשה שימוש בנקודות קצה (endpoints) של Private Service Connect ל-Google APIs. הוא מספק גישה ל-Cloud Storage, ל-BigQuery ולממשקי API אחרים של שירותי Google. הגישה הזו דורשת כתובות IP פרטיות דרך חיבור רשת היברידית ומרובת עננים, כמו VPN,‏ Cloud Interconnect ו-Cross-Cloud Interconnect.

שיטות מומלצות

• נעילת הגישה לקטגוריות של Cloud Storage ולנושאים של Pub/Sub.
• כשזה רלוונטי, כדאי להשתמש בפתרונות משולבים להעברת נתונים שמתאימים ל-Cloud, כמו Google Cloud חבילת הפתרונות. הפתרונות האלה נועדו להעביר, לשלב ולשנות נתונים ביעילות כדי לענות על הצרכים של תרחישי השימוש שלכם.

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

• כדי לצמצם את זמן האחזור ולמנוע העברה של נתונים בכמויות גדולות באינטרנט הציבורי, מומלץ להשתמש ב-Cloud Interconnect או ב-Cross-Cloud Interconnect, כולל גישה לנקודות קצה של Private Service Connect בענן הווירטואלי הפרטי (VPC) שלכם עבור Google APIs.

• כדי להגן Google Cloud על שירותים בפרויקטים ולצמצם את הסיכון לזליגת נתונים, כדאי להשתמש ב-VPC Service Controls. אמצעי הבקרה האלה יכולים לציין אזורי שירות ברמת הפרויקט או ברמת רשת ה-VPC.

  • אפשר להרחיב את גבולות הגזרה של השירות לסביבה היברידית באמצעות VPN מורשה או Cloud Interconnect. מידע נוסף על היתרונות של גבולות גזרה לשירות זמין במאמר סקירה כללית על VPC Service Controls.

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

• אם נדרשת גישה לאינטרנט, אפשר להשתמש ב-Cloud NAT באותו VPC כדי לטפל בתעבורה יוצאת מהמכונות לאינטרנט הציבורי.

• כדאי לעיין בשיטות המומלצות הכלליות לטופולוגיות של רשתות היברידיות ורשתות מרובות עננים.

המלצות כלליות

כשמתכננים ומגדירים זהויות בענן, היררכיית משאבים ורשתות באזור הנחיתה, כדאי לעיין בהמלצות לתכנון שמפורטות במאמר תכנון אזור הנחיתה ב- Google Cloud ובשיטות המומלצות לאבטחה שמפורטות Google Cloud במאמר תוכנית לניהול יסודות האבטחה בארגון. כדאי לאמת את העיצוב שבחרתם באמצעות המסמכים הבאים:

• שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC
• בחירת היררכיית משאבים ל Google Cloud אזור הנחיתה
• ‫Google Cloud Well-Architected Framework: אבטחה, פרטיות ותאימות

כמו כן, כדאי להקפיד על השיטות המומלצות הכלליות הבאות:

• כשבוחרים אפשרות לקישוריות של רשת היברידית או רשת מרובת עננים, חשוב לקחת בחשבון את הדרישות העסקיות והדרישות של האפליקציה, כמו הסכמי רמת שירות (SLA), ביצועים, אבטחה, עלות, אמינות ורוחב פס. למידע נוסף, קראו את המאמר בחירת מוצרים של Network Connectivity ואת המאמר דפוסי חיבור של ספקי שירותי ענן אחרים ל- Google Cloud.

• מומלץ להשתמש ברשתות VPC משותפות ב- Google Cloud במקום בכמה רשתות VPC, אם זה מתאים לדרישות של העיצוב של היררכיית המשאבים. מידע נוסף זמין במאמר האם כדאי ליצור כמה רשתות VPC.

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

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

• כדי לחשוף בצורה מאובטחת אפליקציות למשתמשים עסקיים בהגדרה היברידית, וכדי לבחור את הגישה שהכי מתאימה לדרישות שלכם, כדאי לפעול לפי הדרכים המומלצות לשילוב Google Cloud עם מערכת ניהול הזהויות שלכם.

  • אפשר גם לעיין במאמר דפוסי אימות של משתמשים בכוח העבודה בסביבה היברידית.

• כשמתכננים את הסביבות המקומיות והסביבות בענן, חשוב לקחת בחשבון את כתובות IPv6 בשלב מוקדם, ולבדוק אילו שירותים תומכים בהן. מידע נוסף זמין במאמר An Introduction to IPv6 on Google Cloud. המאמר מסכם את השירותים הנתמכים בזמן כתיבת הבלוג.

• כשמתכננים, פורסים ומנהלים את הכללים של חומת האש ב-VPC, אפשר:

  • אם אתם צריכים שליטה קפדנית על האופן שבו כללי חומת האש מוחלים על מכונות וירטואליות, מומלץ להשתמש בסינון שמבוסס על חשבון שירות במקום בסינון שמבוסס על תג רשת.
  • כדאי להשתמש במדיניות חומת אש כשמקבצים כמה כללים של חומת אש, כדי שתוכלו לעדכן את כולם בבת אחת. אפשר גם להגדיר את המדיניות כהיררכית. פרטים נוספים על מדיניות היררכית של חומת אש זמינים במאמר מדיניות היררכית של חומת אש.
  • כדי לסנן תנועה חיצונית של IPv4 ו-IPv6 על סמך מיקומים גיאוגרפיים או אזורים ספציפיים, צריך להשתמש באובייקטים של מיקום גיאוגרפי במדיניות חומת האש.
  • כדי לאבטח את הרשת על ידי מתן אפשרות לתעבורת נתונים או חסימתה על סמך נתוני Threat Intelligence, כמו כתובות IP זדוניות ידועות או טווחי כתובות IP של ענן ציבורי, אפשר להשתמש בThreat Intelligence לכללים של מדיניות חומת האש . לדוגמה, אתם יכולים לאפשר תנועה מטווחים ספציפיים של כתובות IP בענן ציבורי אם השירותים שלכם צריכים לתקשר רק עם הענן הציבורי הזה. מידע נוסף זמין במאמר בנושא שיטות מומלצות לכללים של חומת אש.

• תמיד כדאי לתכנן את האבטחה של הענן והרשת באמצעות גישת אבטחה רב-שכבתית, תוך התחשבות בשכבות אבטחה נוספות, כמו:

  • Google Cloud Armor
  • המערכת לגילוי חדירות (IDS) של Google Cloud
  • Cloud Next Generation Firewall IPS
  • מודיעין איומי סייבר לכללי מדיניות חומת אש

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

• כשמחליטים איפה צריך לבצע פענוח DNS בהגדרה היברידית, מומלץ להשתמש בשתי מערכות DNS סמכותיות עבור סביבתGoogle Cloud הפרטית ועבור המשאבים המקומיים שמתארחים בשרתי DNS קיימים בסביבה המקומית. מידע נוסף זמין במאמר בחירה של המקום שבו מתבצע פענוח DNS.

• במקרים שבהם אפשר, תמיד כדאי לחשוף אפליקציות דרך ממשקי API באמצעות שער API או מאזן עומסים. מומלץ לשקול שימוש בפלטפורמת API כמו Apigee. ‫Apigee פועל כהפשטה או כחזית (facade) לממשקי ה-API של שירותי הקצה העורפי, בשילוב עם יכולות אבטחה, הגבלת קצב, מכסות וניתוח נתונים.

• פלטפורמת API (שער או שרת proxy) ומאזן עומסים של אפליקציות לא סותרים זה את זה. לפעמים, שימוש משולב בשערי API ובמאזני עומסים יכול לספק פתרון חזק ומאובטח יותר לניהול ולהפצה של תנועת נתונים ב-API בהיקף גדול. שימוש בשערי Cloud Load Balancing API מאפשר לכם לבצע את הפעולות הבאות:

  • העברת ממשקי API עם ביצועים גבוהים באמצעות Apigee ו-Cloud CDN, כדי:

    • הפחתת זמן הטעינה
    • אירוח ממשקי API באופן גלובלי

    • הגדלת הזמינות בעונות השיא של התנועה

      מידע נוסף זמין בסרטון Delivering high-performing APIs with Apigee and Cloud CDN ב-YouTube.

  • הטמעה של ניהול מתקדם של תעבורת נתונים.

  • כדי להגן על ממשקי ה-API, אפשר להשתמש ב-Cloud Armor כשירות להגנה מפני DDoS, כחומת אש לאפליקציות אינטרנט (WAF) וכשירות אבטחת רשת.

  • ניהול יעיל של איזון עומסים בין שערים בכמה אזורים. מידע נוסף זמין בסרטון Securing APIs and Implementing multi-region failover with PSC and Apigee.

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

• כשמשתמשים ב-Cloud Load Balancing, כדאי להשתמש ביכולות האופטימיזציה של קיבולת האפליקציה שלו, במקרים הרלוונטיים. הפעולה הזו יכולה לעזור לכם להתמודד עם חלק מהבעיות שקשורות לקיבולת שעלולות לקרות באפליקציות שמופצות ברחבי העולם.

  • למידע מעמיק על זמן האחזור, אפשר לקרוא את המאמר אופטימיזציה של זמן האחזור באפליקציות באמצעות איזון עומסים.

• ב-Cloud VPN, התנועה בין הסביבות מוצפנת. ב-Cloud Interconnect, צריך להשתמש ב-MACsec או ב-HA VPN דרך Cloud Interconnect כדי להצפין את התנועה במעבר בשכבת הקישוריות. מידע נוסף זמין במאמר איך אפשר להצפין את התעבורה ב-Cloud Interconnect.

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

• אם אתם צריכים נפח תנועה גדול יותר בחיבור היברידי ל-VPN ממה שמנהרת VPN יחידה יכולה לתמוך בו, כדאי לשקול להשתמש באפשרות ניתוב HA VPN פעיל/פעיל.

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

• כשמתחברים למשאבים של Google Cloud ומנסים לבחור בין Cloud Interconnect,‏ Direct Peering או Carrier Peering, מומלץ להשתמש ב-Cloud Interconnect, אלא אם צריך לגשת לאפליקציות של Google Workspace. מידע נוסף זמין בהשוואה בין התכונות של Direct Peering עם Cloud Interconnect ושל Carrier Peering עם Cloud Interconnect.

• צריך להקצות מספיק מקום לכתובות IP מתוך מרחב כתובות ה-IP הקיים של RFC 1918, כדי שיהיה מקום למערכות שמארחות בענן.

• אם יש לכם מגבלות טכניות שמחייבות אתכם לשמור על טווח כתובות ה-IP, אתם יכולים:

  • להשתמש באותן כתובות IP פנימיות עבור עומסי העבודה המקומיים בזמן ההעברה אל Google Cloud, באמצעות רשתות משנה היברידיות.

  • הקצאה ושימוש בכתובות IPv4 ציבוריות משלכם למשאביGoogle Cloud באמצעות העברת כתובות IP משלכם (BYOIP) אל Google.

• אם הפתרון שלכם מחייב חשיפה של אפליקציה מבוססת-Google Cloudלאינטרנט הציבורי, כדאי לעיין בהמלצות לעיצוב שמופיעות במאמר Networking for internet-facing application delivery.

• במקרים הרלוונטיים, כדאי להשתמש בנקודות קצה (endpoints) של Private Service Connect כדי לאפשר לעומסי עבודה ב- Google Cloud, בפריסה מקומית או בסביבת ענן אחרת עם קישוריות היברידית, לגשת באופן פרטי ל-Google APIs או לשירותים שפורסמו, באמצעות כתובות IP פנימיות בצורה מפורטת.

• כשמשתמשים ב-Private Service Connect, צריך לשלוט בפרטים הבאים:

  • מי יכול לפרוס משאבים של Private Service Connect.
  • האם אפשר ליצור קשר בין צרכנים לבין יצרנים.
  • אילו תעבורת נתונים ברשת מורשית לגשת לחיבורים האלה.

  מידע נוסף זמין במאמר אבטחה ב-Private Service Connect.

• כדי להשיג הגדרת ענן חזקה בהקשר של ארכיטקטורה היברידית ומרובת עננים (multi-cloud):

  • ביצוע הערכה מקיפה של רמות המהימנות הנדרשות של האפליקציות השונות בסביבות. הפעולה הזו יכולה לעזור לכם לעמוד ביעדים שלכם בנוגע לזמינות ולחוסן.
  • להבין את יכולות האמינות ועקרונות התכנון של ספק שירותי הענן. מידע נוסף זמין במאמר בנושא Google Cloud מהימנות התשתית.

• ניראות ומעקב ברשת הענן חיוניים לשמירה על תקשורת מהימנה. ‫Network Intelligence Center מספק מסוף מרכזי לניהול של הרשאות גישה לרשת, מעקב ופתרון בעיות.

דפוסי ארכיטקטורה של רשתות היברידיות ומרובות עננים (multi-cloud) מאובטחות: מה צפוי בהמשך

• במאמר הזה מוסבר על תבניות ארכיטקטורה נפוצות שאפשר להשתמש בהן כדי להטמיע את תבניות הרשת שמוסברות במאמר.
• איך ניגשים לפתרונות היברידיים ולפתרונות מרובי עננים ואיך בוחרים את עומסי העבודה המתאימים
• Google Cloud מידע נוסף על Cross-Cloud Network פלטפורמת רשת גלובלית שהיא פתוחה, מאובטחת ומותאמת לאפליקציות ולמשתמשים במקום ובסביבות ענן אחרות.
• תכנון תשתית אמינה לעומסי העבודה ב- Google Cloud: הנחיות לתכנון שיעזרו לכם להגן על האפליקציות מפני כשלים ברמת המשאב, האזור והתחום.
• כדי לקבל מידע נוסף על תכנון ארכיטקטורות עם זמינות גבוהה ב-Google Cloud, אפשר לעיין בתבניות לאפליקציות עמידות שניתנות להרחבה.
• אפשרויות החיבור האפשריות לחיבור אשכול GKE שפועל בסביבת on-premises או בסביבת edge לרשת Google Cloud , וגם ההשפעה של ניתוק זמני מ- Google Cloud.