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

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. אתם יכולים להשתמש בתגים, בחשבונות שירות ובתגי רשת כדי להחיל כללי חומת אש מפורטים על מכונות וירטואליות. הנחיות להטמעה של ניהול התעבורה באמצעות Google Cloud כללי חומת אש זמינות במאמר מדיניות של חומת אש ברשת בתוכנית הבסיסית לארגונים.

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

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

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

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

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

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

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

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

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

Cloud IDS

המערכת לגילוי חדירות של Google Cloud (‏Cloud IDS) מאפשרת לכם להטמיע בדיקות אבטחה ורישום ביומן באופן מקורי, על ידי שיקוף תעבורה מרשת משנה ברשת ה-VPC שלכם. באמצעות Cloud IDS, אתם יכולים לבדוק ולעקוב אחרי מגוון רחב של איומים בשכבת הרשת ובשכבת האפליקציה לצורך ניתוח. יוצרים נקודות קצה של Cloud IDS ברשת ה-VPC שלכם. Google Cloud נקודות הקצה האלה מנטרות את תעבורת הנתונים הנכנסת והיוצאת לרשת וממנה, וגם את תעבורת הנתונים ברשת ה-VPC, באמצעות הפונקציונליות של רפליקציה של חבילות נתונים שמוטמעת במערך הרשתות של 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 הוא מישור הבקרה של הארכיטקטורה. החיבורים לרשתות נקראים חיבורים היקפיים. אתם יכולים להשתמש ב-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 ספציפית ולאזור. לאחר מכן תוכלו להגדיר את השירותים חסרי השרת כך שישתמשו במחבר לתעבורת נתונים יוצאת ברשת. אפשר לציין מחבר באמצעות רשת משנה או טווח 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.

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

תעבורת נתונים יוצאת (egress) ישירה של VPC מאפשרת לשירות 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 מסתמך על fleets לניהול התצורה והזהות של פריסת שירותים מרובי אשכולות. בדומה ל-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.

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