רשתות לגישה מאובטחת בתוך הענן: תרשימי עזר לארכיטקטורות

Last reviewed 2025-01-13 UTC

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

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

עומסי עבודה לתרחישי שימוש בתוך הענן נמצאים ברשתות VPC וצריכים להתחבר למשאבים אחרים ב- Google Cloud. יכול להיות שהם יצרכו שירותים שמוצעים באופן מקורי בענן, כמו BigQuery. היקף האבטחה מסופק על ידי מגוון יכולות של צד ראשון (1P) וצד שלישי (3P), כמו חומות אש, VPC Service Controls ומכשירים וירטואליים ברשת.

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

ארכיטקטורה של שיטת Lift-and-shift (העברה בלי שינויים)

התרחיש הראשון לשימוש בענן פנימי הוא ארכיטקטורת שיטת Lift-and-shift (העברה בלי שינויים), שבה מעבירים לענן עומסי עבודה קיימים כמו שהם.

Cloud NGFW

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

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

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

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

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

איור 1. הגדרת חומת אש בין רשתות שמשתמשת בתגי רשת כדי להחיל בקרת יציאה מדויקת.

מכשיר וירטואלי לרשת

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

הגדרה מרכזית של מכשיר רשת ברשת VPC משותפת.

איור 2. הגדרה מרכזית של מכשירי רשת ברשת VPC משותפת.

Cloud IDS

המערכת לגילוי חדירות של Google Cloud (‏Cloud IDS) מאפשרת לכם להטמיע בדיקות אבטחה ורישום ביומן באופן מקורי, על ידי שיקוף תעבורה מרשת משנה ברשת ה-VPC שלכם. באמצעות Cloud IDS, אתם יכולים לבדוק ולעקוב אחרי מגוון רחב של איומים בשכבת הרשת ובשכבת האפליקציה לצורך ניתוח. יוצרים נקודות קצה של Cloud IDS ברשת ה-VPC שלכם. Google Cloud נקודות הקצה האלה מנטרות את תעבורת הנתונים הנכנסת (ingress) והיוצאת (egress) אל הרשת וממנה, וגם את תעבורת הנתונים בתוך רשת ה-VPC, באמצעות הפונקציונליות של רפליקציה של חבילות נתונים שמוטמעת במקבץ הרשת (network stack) של Google Cloud . כדי להתחבר לפרויקט של בעל השירות (הפרויקט שמנוהל על ידי Google) שבו מתארחים התהליכים של Cloud IDS, צריך להפעיל גישה לשירותים פרטיים.

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

הגדרת Cloud IDS לשכפול תעבורת VPC שמשתמשת בגישה לשירותים פרטיים.

איור 3. הגדרת Cloud IDS לשכפול תעבורת VPC שמשתמשת בגישה לשירותים פרטיים.

אפשר לאבטח את Cloud IDS ב-service perimeter של VPC Service Controls באמצעות שלב נוסף. מידע נוסף על התמיכה ב-VPC Service Controls זמין במאמר בנושא מוצרים נתמכים.

Network Connectivity Center

‫Network Connectivity Center הוא מסגרת תזמור שמפשטת את קישוריות הרשת בין משאבים שמחוברים למשאב ניהול מרכזי שנקרא רכזת. הכלי NCC תומך בסוגי הרשתות הבאים:

  • Google Cloud רשתות VPC
  • רשתות בארגון ורשתות ענן אחרות באמצעות Cloud Interconnect או HA VPN
  • חיבורים מוצפנים שמעוגנים במכונות וירטואליות

‫Network Connectivity Center הוא מישור הבקרה של הארכיטקטורה. החיבורים לרשתות נקראים חיבורים היקפיים. אתם יכולים להשתמש במרכז לקישוריות בין רשתות כדי לחבר בין רשתות בטופולוגיה של רשת מלאה או של רכזת וחישורים.

קישור בין רשתות VPC שכנות (peering)

אם יש לכם אפליקציות שפועלות בכמה רשתות VPC, בין אם הן שייכות לאותו פרויקט Google Cloud או לאותו משאב ארגוני, קישור בין רשתות שכנות (peering) מאפשר קישוריות בין רשתות VPC. הקישוריות הזו מאפשרת לתנועה להישאר בתוך הרשת של Google, כך שהיא לא עוברת באינטרנט הציבורי.

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

VPC משותף

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

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

מידע נוסף על שיטות מומלצות ליצירת רשתות VPC זמין במאמר שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC.

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

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

ארכיטקטורה של שירותים היברידיים

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

התחברות לשירות פרטי

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

אפשר להשתמש ב-Private Service Connect בשתי דרכים: כדי לגשת ל-Google APIs או כדי לגשת לשירותים שמארחים ברשתות VPC אחרות.

שימוש ב-Private Service Connect כדי לגשת אל Google APIs

כשמשתמשים ב-Private Service Connect, אפשר לחשוף ממשקי Google API באמצעות נקודת קצה (endpoint) של Private Service Connect שהיא חלק מרשת ה-VPC, כמו שמוצג באיור 7.

הגדרת Private Service Connect כדי לשלוח תנועה לממשקי Google API באמצעות נקודת קצה (endpoint) של Private Service Connect שהיא פרטית לרשת ה-VPC.

איור 7. הגדרת Private Service Connect כדי לשלוח תנועה לממשקי Google API באמצעות נקודת קצה (endpoint) של Private Service Connect שהיא פרטית לרשת ה-VPC.

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

הגדרת Private Service Connect כדי לשלוח תנועה לממשקי API של Google באמצעות עורף (backend) של Private Service Connect.

איור 8. הגדרת Private Service Connect כדי לשלוח תנועה לממשקי API של Google באמצעות עורף (backend) של Private Service Connect.

שימוש ב-Private Service Connect בין רשתות VPC או ישויות

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

הגדרת Private Service Connect לפרסום ולשימוש בשירותים מנוהלים דרך נקודת קצה.

איור 9. הגדרת Private Service Connect לפרסום שירות מנוהל באמצעות קובץ מצורף עם השירות וצריכת השירות באמצעות נקודת קצה.

גישה לשירותים פרטיים

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

מחבר גישה ל-VPC מאפליקציית serverless

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

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

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

מחברי גישה ל-VPC מאפליקציית serverless נתמכים בכל אזור שתומך ב-Cloud Run, בפונקציות Cloud Run או בסביבה הרגילה של App Engine. מידע נוסף זמין ברשימת השירותים הנתמכים ופרוטוקולי הרשת הנתמכים לשימוש ב-VPC Serverless access connector.

יציאה ישירה מ-VPC

תעבורת נתונים יוצאת (egress) ישירה מ-VPC מאפשרת לשירות Cloud Run לשלוח תעבורה לרשת VPC בלי להגדיר מחבר של חיבור לרשת (VPC) מאפליקציית serverless.

VPC Service Controls

VPC Service Controls עוזר למנוע זליגת נתונים משירותים כמו Cloud Storage או BigQuery, על ידי מניעת גישות מורשות מהאינטרנט או מפרויקטים שלא נכללים במתחם אבטחה היקפית. לדוגמה, נניח ששגיאה אנושית או אוטומציה שגויה גורמות להגדרת מדיניות IAM בצורה שגויה בשירות כמו Cloud Storage או BigQuery. כתוצאה מכך, המשאבים בשירותים האלה הופכים לנגישים לציבור. במקרה כזה, יש סיכון לחשיפת נתונים. אם השירותים האלה מוגדרים כחלק מגבולות הגזרה של VPC Service Controls, תעבורת נתונים נכנסת (ingress) למשאבים נחסמת, גם אם מדיניות IAM מאפשרת גישה.

בעזרת VPC Service Controls אפשר ליצור גבולות גזרה על סמך מאפייני לקוח כמו סוג הזהות (חשבון שירות או משתמש) ומקור הרשת (כתובת IP או רשת VPC).

VPC Service Controls עוזר לצמצם את סיכוני האבטחה הבאים:

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

איור 11 מראה איך VPC Service Controls מאפשר להגדיר מתחם אבטחה היקפית כדי לצמצם את הסיכונים האלה.

גבולות גזרה לשירות של VPC הורחבו לסביבות היברידיות באמצעות שירותי גישה פרטית.

איור 11. גבולות גזרה לשירות של VPC הורחבו לסביבות היברידיות באמצעות שירותי גישה פרטית.

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

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

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

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

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

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

אתם יכולים להטמיע ארכיטקטורות מבוזרות של Zero Trust כשירותים שמנוהלים על ידי Cloud Service Mesh ו-Cloud Service Mesh.

Cloud Service Mesh

‫Cloud Service Mesh מספק רשת מיקרו-שירותים מבוזרת של Zero Trust עם mTLS מוכן לשימוש, שמבוססת על Istio. מגדירים את הרשת באמצעות תהליך משולב. ‫Managed Cloud Service Mesh, עם מישורי נתונים ומישורי בקרה שמנוהלים על ידי Google, נתמך ב-GKE. אפשר גם להשתמש במישור בקרה בתוך האשכול, שמתאים לסביבות אחרות כמו Google Distributed Cloud או GKE Multi-Cloud. ‫Cloud Service Mesh מנהל את הזהויות והאישורים בשבילכם, ומספק מודל של מדיניות הרשאות שמבוסס על Istio.

‫Cloud Service Mesh מסתמך על ציים לניהול הזהות והגדרת הפריסה של שירותים מרובי אשכולות. בדומה ל-Cloud Service Mesh, כשעומסי העבודה שלכם פועלים בסביבת קישוריות שטוחה (או משותפת) של רשת VPC, אין דרישות מיוחדות לקישוריות לרשת מעבר להגדרת חומת האש. אם הארכיטקטורה שלכם כוללת כמה אשכולות Cloud Service Mesh ברשתות VPC נפרדות או בסביבות רשת שונות, למשל דרך חיבור Cloud Interconnect, אתם צריכים גם שער מזרח-מערב. השיטות המומלצות לרישות ב-Cloud Service Mesh זהות לשיטות שמתוארות במאמר שיטות מומלצות לרישות ב-GKE.

בנוסף, Cloud Service Mesh משתלב עם שרת proxy לאימות זהויות (IAP). ‫IAP מאפשר להגדיר מדיניות גישה מפורטת כדי לשלוט בגישת המשתמשים לעומס עבודה על סמך מאפיינים של הבקשה המקורית, כמו זהות המשתמש, כתובת ה-IP וסוג המכשיר. רמת השליטה הזו מאפשרת ליצור סביבה של אפס אמון מקצה לקצה.

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

המאמרים הבאים