כשמתכננים ומטמיעים זהויות בענן, היררכיית משאבים ורשתות באזור הנחיתה, כדאי לעיין בהמלצות התכנון שבמאמר תכנון אזור הנחיתה ב- 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 בשלב מוקדם, ולבדוק אילו שירותים תומכים בהן. מידע נוסף זמין במאמר מבוא ל-IPv6 ב- 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 פועלת כהפשטה או כחזית עבור ממשקי ה-API של שירות הבק-אנד, בשילוב עם יכולות אבטחה, הגבלת קצב, מכסות וניתוח נתונים.
פלטפורמת API (שער או שרת proxy) ומאזן עומסים של אפליקציות לא סותרים זה את זה. לפעמים, שימוש משולב בשערי API ובמאזני עומסים יכול לספק פתרון חזק ומאובטח יותר לניהול ולהפצה של תנועת נתונים ב-API בהיקף גדול. שימוש בשערי Cloud Load Balancing API מאפשר לכם לבצע את הפעולות הבאות:
להשתמש ב-Apigee וב-Cloud CDN כדי לספק ממשקי API עם ביצועים גבוהים, כדי:
- הפחתת זמן האחזור
- אירוח ממשקי 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 מספק מסוף מרכזי לניהול הרשאות הגישה לרשת, מעקב ופתרון בעיות.