תכנון רשתות להעברת עומסי עבודה בארגון: גישות אדריכליות

Last reviewed 2025-01-13 UTC

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

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

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

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

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

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

במסמך הזה מוזכרות מכונות וירטואליות (VM) כדוגמאות למשאבי עומס עבודה. המידע רלוונטי למשאבים אחרים שמשתמשים ברשתות VPC, כמו מופעי Cloud SQL וצמתים של Google Kubernetes Engine.

סקירה כללית של דפוסי ארכיטקטורה

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

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

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

תבנית חיתוך והעברה

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

דפוס של שירותים היברידיים

עומסי עבודה שנבנו באמצעות שיטת Lift-and-shift (העברה בלי שינויים) עשויים לדרוש גישה לשירותי ענן כמו BigQuery או Cloud SQL. בדרך כלל, הגישה לשירותי ענן כאלה היא בשכבה 4 ובשכבה 7. בהקשר הזה, אי אפשר לבצע בידוד ואבטחה רק בשכבה 3. לכן, נעשה שימוש ב-Service Networking וב-VPC Service Controls כדי לספק קישוריות ואבטחה, על סמך הזהויות של השירות שאליו מתבצעת הגישה ושל השירות שמבקש גישה. במודל הזה, אפשר להגדיר מדיניות עשירה של בקרת גישה.

דפוס מבוזר של אפס אמון

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

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

שילוב של דפוסים

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

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

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

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

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

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

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

שיקולים לתכנון רשתות של ענן וירטואלי פרטי (VPC) ב-Google

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

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

רשתות VPC הן גלובליות

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

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

‫Google Cloud הטמעה של רשת VPC גלובלית עם תת-רשתות שהוגדרו באזורים שונים.

איור 1. Google Cloud הטמעה של רשת VPC גלובלית עם תת-רשתות שהוגדרו באזורים שונים.

שיתוף רשת באמצעות VPC משותף

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

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

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

בידוד סביבות באמצעות רשתות VPC

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

סיבות לבידוד סביבות

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

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

חסרונות של בידוד סביבות

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

תבניות נפוצות של בידוד רשתות VPC

יש כמה תבניות נפוצות לבידוד רשתות VPC:

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

המלצה ליצירת סביבות מבודדות

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

מידע נוסף על תכנון ובנייה של אסטרטגיית בידוד לארגון זמין במאמרים שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC וNetworking בתוכנית ה-blueprint של Google Cloud enterprise foundations.

אבני בניין לרשתות בענן

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

אבני בניין בתחום הקישוריות והאבטחה של רשתות בענן.

איור 2. אבני בניין בתחום הקישוריות והאבטחה של רשתות בענן.

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

קישוריות רשת

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

Cloud VPN

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

‫Cloud VPN מאפשר לכם לחבר את הסביבה המקומית שלכם ו Google Cloud בעלות נמוכה יותר, אבל ברוחב פס נמוך יותר, מאשר Cloud Interconnect (שמתואר בקטע הבא). אם יש לכם ארכיטקטורה תואמת, אתם יכולים להקצות HA VPN כדי לעמוד בדרישות של הסכם רמת שירות (SLA) של עד 99.99% זמינות. לדוגמה, Cloud VPN הוא בחירה טובה לתרחישי שימוש לא קריטיים או להרחבת הקישוריות לספקי ענן אחרים.

Cloud Interconnect

‫Cloud Interconnect מספק קישוריות ייעודית ברמה ארגונית ל- Google Cloud עם תפוקה גבוהה יותר וביצועים אמינים יותר ברשת בהשוואה לשימוש ב-VPN או בגישה לאינטרנט. ‫Dedicated Interconnect מספק קישוריות פיזית ישירה לרשת של Google מהנתבים שלכם. ‫Partner Interconnect מספק קישוריות ייעודית דרך רשת נרחבת של שותפים, שיכולים להציע כיסוי רחב יותר או אפשרויות אחרות של רוחב פס בהשוואה ל-Dedicated Interconnect. ‫Cross-Cloud Interconnect מספק קישוריות ישירה ייעודית מרשתות ה-VPC שלכם לספקי ענן אחרים. Dedicated Interconnect מחייב חיבור במתקן לאחסון ואירוח שרתים (colocation facility) שבו Google נמצאת, אבל Partner Interconnect לא מחייב זאת. ‫Cloud Interconnect מוודא שהתעבורה בין הרשת המקומית או רשת ענן אחרת לבין רשת ה-VPC לא עוברת דרך האינטרנט הציבורי.

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

‫Network Connectivity Center לשימוש היברידי

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

בנוסף, אפשר להרחיב את רשת ה-SD-WAN הקיימת ל-Google Cloud על ידי הגדרת VM או נתב של ספק חיצוני כחיבור לוגי של spoke.

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

‫NCC לרשתות VPC

בנוסף, NCC מאפשר ליצור טופולוגיה של רשת משולבת או רשת כוכב בין רשתות VPC רבות באמצעות רשתות VPC מסוג Hub and Spoke. אפשר לחבר את ה-hub לרשתות מקומיות או לעננים אחרים באמצעות NCC hybrid spokes.

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

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

כדי להשתמש בקישור בין רשתות VPC שכנות (peering), הרשתות שמקושרות לא יכולות לכלול כתובות IP חופפות.

אבטחת רשת

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

Cloud NGFW

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

רפליקציה של חבילות נתונים

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

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

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

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

  • חומת אש מהדור הבא (NGFW). מכשירי NGFW NVA מספקים הגנה במצבים שלא מכוסים על ידי Cloud NGFW, או כדי לספק עקביות בניהול עם התקנות NGFW מקומיות.
  • מערכת לגילוי חדירות (IDS) או מערכת למניעת חדירות (IPS). מערכת IDS מבוססת-רשת מספקת תובנות לגבי תעבורה שעלולה להיות זדונית. כדי למנוע חדירות, מכשירי IPS יכולים לחסום תעבורה זדונית מלהגיע ליעד שלה. Google Cloud מציעה את המערכת לגילוי חדירות של Google Cloud (‏Cloud IDS) כשירות מנוהל.
  • שער גישה מאובטח (SWG). שער גישה מאובטח חוסם איומים מהאינטרנט על ידי כך שהוא מאפשר לארגונים להחיל מדיניות ארגונית על תנועה שיוצאת מהאינטרנט ונכנסת אליו. הפעולה הזו מתבצעת באמצעות סינון כתובות URL, זיהוי קוד זדוני ובקרת גישה. Google Cloud מציעה Secure Web Proxy כשירות מנוהל.
  • שער תרגום כתובת רשת (NAT). שער NAT מתרגם כתובות IP ויציאות. לדוגמה, התרגום הזה עוזר להימנע מחפיפה של כתובות IP. Google Cloud שירות Cloud NAT הוא שירות מנוהל.
  • חומת אש לאפליקציות אינטרנט (WAF). חומת אש לאפליקציות אינטרנט (WAF) נועדה לחסום תנועת HTTP(S) זדונית שמיועדת לאפליקציית אינטרנט. Google Cloud מציע פונקציונליות של WAF באמצעות כללי מדיניות האבטחה של Google Cloud Armor. הפונקציונליות המדויקת משתנה בין ספקי WAF, ולכן חשוב להבין מה אתם צריכים.

Cloud IDS

‫Cloud IDS הוא שירות לגילוי חדירות שבאמצעותו אפשר לזהות ברשת איומים כמו פריצות, תוכנות זדוניות, תוכנות ריגול ומתקפות להשגת שליטה. השיטה שבה Cloud IDS מזהה איומים פשוטה: הוא יוצר רשת של Google שמקושרת לרשת שלכם ומכילה מכונות וירטואליות שיקבלו את התעבורה המשוכפלת. תעבורת הנתונים המשוכפלת נבדקת על ידי טכנולוגיות האבטחה של Palo Alto Networks כדי לזהות איומים מתקדמים.

באמצעות Cloud IDS אתם יכולים לנטר את התעבורה בתוך רשתות המשנה ולזהות תנועה רוחבית בין המכונות הווירטואליות שלכם.

Cloud NAT

‫Cloud NAT מספק תמיכה מנוהלת מלאה בתרגום כתובות רשת מוגדרות בתוכנה לאפליקציות. הוא מאפשר תרגום כתובות רשת של המקור (source NAT או SNAT) לתעבורת נתונים שמיועדת לאינטרנט ממכונות וירטואליות שאין להן כתובות IP חיצוניות.

תובנות לגבי חומת האש

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

רישום התנועה ברשת

אתם יכולים להשתמש בכמה Google Cloud מוצרים כדי לרשום ולנתח את תעבורת הרשת.

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

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

יומני תנועה של VPC מתעדים דגימה של תנועת רשת שנשלחת ממכונות וירטואליות ומתקבלת בהן, כולל מופעים שמשמשים כצמתים של Google Kubernetes Engine‏ (GKE). היומנים האלה יכולים לשמש למעקב אחרי הרשת, לניתוח פורנזי, לניתוח אבטחה בזמן אמת ולאופטימיזציה של ההוצאות.

Service Networking

בלוקים של Service Networking אחראים לספק שירותי חיפוש שמציינים לשירותים לאן בקשה צריכה להגיע (DNS, ‏ Service Directory) ולדאוג שהבקשות יגיעו למקום הנכון (Private Service Connect,‏ Cloud Load Balancing).

Cloud DNS

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

Cloud Load Balancing

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

מאזני העומסים שלנו מאפשרים גם לנתב את התנועה ולשנות את קנה המידה שלה בעננים מרובים או בסביבות היברידיות. כך, Cloud Load Balancing הוא ה"דלת הקדמית" שדרכה אפשר לשנות את קנה המידה של כל אפליקציה, לא משנה איפה היא נמצאת או בכמה מקומות היא מתארחת. Google מציעה סוגים שונים של איזון עומסים: גלובלי ואזורי, חיצוני ופנימי, וגם שכבה 4 ושכבה 7.

Service Directory

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

Cloud Service Mesh

‫Cloud Service Mesh נועד להריץ אפליקציות מורכבות ומבוזרות על ידי הפעלה של קבוצה עשירה של מדיניות לניהול תעבורת נתונים ואבטחה בארכיטקטורות של Service mesh.

‫Cloud Service Mesh תומך בפריסות אזוריות וגלובליות שמבוססות על Kubernetes, גם Google Cloud וגם בתשתית מקומית, ונהנות ממוצר Istio מנוהל. הוא תומך גם בשימוש בשרתי proxy במכונות וירטואליות או ב-gRPC ללא proxy. Google Cloud

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

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

באמצעות Private Service Connect, רשת VPC של צרכן יכולה להשתמש בכתובת IP פרטית כדי להתחבר לGoogle API או לשירות ברשת VPC אחרת.

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

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

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

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

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

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

חיבור לרשת (VPC) מאפליקציית serverless

חיבור לרשת (VPC) מאפליקציית serverless מאפשר לכם להתחבר ישירות לרשת ה-VPC משירותים שמארחים בסביבות serverless כמו Cloud Run,‏ App Engine או פונקציות Cloud Run. הגדרת חיבור לרשת (VPC) מאפליקציית serverless מאפשרת לסביבת ה-serverless לשלוח בקשות לרשת ה-VPC באמצעות DNS פנימי וכתובות IP פנימיות. התשובות לבקשות האלה משתמשות גם ברשת הווירטואלית שלכם.

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

לחיבור לרשת (VPC) מאפליקציית serverless יש את היתרונות הבאים:

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

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

Direct VPC egress מאפשר לשירות Cloud Run לשלוח תעבורת נתונים לרשת VPC בלי להגדיר מחבר Serverless VPC Access.

אבטחת השירות

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

‫Cloud Armor ל-DDoS/WAF

‫Cloud Armor הוא חומת אש ליישומי אינטרנט (WAF) ושירות לצמצום הסיכון של מתקפות מניעת שירות מבוזרות (DDoS). הוא עוזר לכם להגן על יישומי האינטרנט והשירותים שלכם מפני סוגים שונים של איומים, כולל מתקפות DDoS, מתקפות מבוססות אינטרנט כמו פרצות אבטחה XSS‏ (cross-site scripting) והזרקות SQL‏ (SQLi), ומתקפות מבוססות-הונאה ואוטומציה.

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

שרת proxy לאימות זהויות (IAP)

שרת proxy לאימות זהויות (IAP) מספק בקרות גישה מבוססות הקשר לאפליקציות ולמכונות וירטואליות מבוססות ענן שפועלות ב- Google Cloud או שמחוברות ל- Google Cloudבאמצעות כל אחת מהטכנולוגיות של רשתות היברידיות. שרת ה-IAP מאמת את זהות המשתמש וקובע אם בקשת המשתמש מגיעה ממקורות מהימנים, על סמך מאפיינים הקשריים שונים. שרת ה-IAP תומך גם במנהור TCP לגישת SSH/RDP ממשתמשים בארגון.

VPC Service Controls

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

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

העברת תוכן

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

Cloud CDN

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

Media CDN

‫Media CDN הוא פתרון של Google להעברת מדיה, והוא מיועד לעומסי עבודה של יציאה עם תפוקה גבוהה.

ניראות (observability)

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

Network Intelligence Center

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

תרשימי עזר לארכיטקטורה

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

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

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

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