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

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

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

אם יש לכם ארכיטקטורת Hub-and-Spoke, אפשר לשקף את התנועה מכל אחד מה-Spokes למופעי 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 או לאותו משאב ארגוני, קישור בין רשתות VPC שכנות מאפשר קישוריות בין רשתות VPC. הקישוריות הזו מאפשרת לתנועה להישאר בתוך הרשת של Google, כך שהיא לא עוברת באינטרנט הציבורי.

ארכיטקטורת רכזת-חישורים היא מודל פופולרי לקישוריות בין רשתות VPC. המודל הזה שימושי כשלארגון יש אפליקציות שונות שצריכות לגשת לקבוצה משותפת של שירותים, כמו רישום ביומן או אימות. המודל שימושי גם אם הארגון צריך להטמיע קבוצה משותפת של מדיניות אבטחה לתנועה שיוצאת מהרשת דרך הרכזת. להנחיות להגדרת ארכיטקטורת רכזת-חישורים באמצעות קישור בין רשתות VPC שכנות (peering), אפשר לעיין במאמר קישוריות בין רשתות VPC בענן באמצעות קישור בין רשתות VPC שכנות (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 APIs באמצעות נקודת קצה (endpoint) של Private Service Connect שהיא חלק מרשת ה-VPC, כמו שמוצג באיור 7.

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

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

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

הגדרת Private Service Connect כדי לשלוח תנועה ל-Google APIs באמצעות בק-אנד של Private Service Connect.

איור 8. הגדרת Private Service Connect כדי לשלוח תנועה ל-Google APIs באמצעות בק-אנד של 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 ללא שרת נתמכים בכל אזור שתומך ב-Cloud Run, בפונקציות Cloud Run או בסביבה הרגילה של App Engine. מידע נוסף זמין ברשימת השירותים הנתמכים ופרוטוקולי הרשת הנתמכים לשימוש ב-VPC Serverless access connector.

תעבורת נתונים יוצאת (egress) ישירה מ-VPC

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

VPC Service Controls

VPC Service Controls עוזר למנוע זליגת מידע משירותים כמו Cloud Storage או BigQuery, על ידי מניעת גישה מורשית מהאינטרנט או מפרויקטים שלא נכללים במתחם אבטחה היקפית. לדוגמה, נניח ששגיאה אנושית או אוטומציה שגויה גורמות להגדרת מדיניות IAM בצורה שגויה בשירות כמו Cloud Storage או BigQuery. כתוצאה מכך, משאבים בשירותים האלה הופכים לנגישים לציבור. במקרה כזה, יש סיכון לחשיפת נתונים. אם השירותים האלה מוגדרים כחלק מגבולות הגזרה של VPC Service Controls, הגישה הנכנסת למשאבים נחסמת, גם אם מדיניות 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 מספק רשת מיקרו-שירותים מבוזרת של mTLS Zero Trust, שמוכנה לשימוש מיידי ומבוססת על Istio. מגדירים את הרשת באמצעות רצף פעולות משולב. ‫Managed Cloud Service Mesh, עם מישורי נתונים ומישורי בקרה שמנוהלים על ידי Google, נתמך ב-GKE. אפשר גם להשתמש במישור בקרה בתוך האשכול, שמתאים לסביבות אחרות כמו Google Distributed Cloud או GKE Multi-Cloud. ‫Cloud Service Mesh מנהל את הזהויות והאישורים בשבילכם, ומספק מודל של מדיניות הרשאות שמבוסס על Istio.

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

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

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

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