התבנית מסועפת מבוססת על הקמת ארכיטקטורת רשת היברידית. הארכיטקטורה הזו משתרעת על פני כמה סביבות מחשוב. בסביבות האלה, כל המערכות יכולות לתקשר זו עם זו, והתקשורת לא מוגבלת לתקשורת חד-כיוונית על סמך דרישות האבטחה של האפליקציות. דפוס הרשת הזה רלוונטי בעיקר לארכיטקטורות של סביבה היברידית מדורגת, סביבה מרובת עננים (multi-cloud) עם חלוקה למחיצות או bursting. היא רלוונטית גם לתכנון המשכיות העסקית כדי להקצות סביבת התאוששות מאסון (DR) ב- Google Cloud. בכל המקרים, נדרש לחבר סביבות מחשוב באופן שתואם לדרישות התקשורת הבאות:
- עומסי עבודה יכולים לתקשר אחד עם השני בין גבולות הסביבה באמצעות כתובות IP פרטיות RFC 1918.
- התקשורת יכולה להתחיל מכל אחד מהצדדים. הפרטים של מודל התקשורת יכולים להשתנות בהתאם לאפליקציות ולדרישות האבטחה, כמו מודלי התקשורת שמוסברים באפשרויות העיצוב שבהמשך.
- כללי חומת האש שבהם אתם משתמשים צריכים לאפשר תנועה בין מקורות ויעדים ספציפיים של כתובות IP, בהתאם לדרישות של האפליקציה או האפליקציות שלשמן נועד הדפוס. מומלץ להשתמש בגישת אבטחה רב-שכבתית כדי להגביל את זרימת התנועה בצורה מדויקת, גם בין סביבות מחשוב וגם בתוכן.
ארכיטקטורה
הדיאגרמה הבאה ממחישה ארכיטקטורת הפניה ברמה גבוהה של דפוס רשת.
- בכל הסביבות צריך להשתמש במרחב כתובות IP לפי RFC 1918 ללא חפיפה.
- בצד Google Cloud , אפשר לפרוס עומסי עבודה ב-VPC משותף אחד או יותר, או ב-VPC לא משותף. אפשרויות עיצוב נוספות של התבנית הזו מפורטות בהמשך. המבנה שנבחר של רשתות ה-VPC צריך להיות תואם לפרויקטים ולעיצוב היררכיית המשאבים של הארגון.
- רשת ה-VPC של Google Cloud מורחבת לסביבות מחשוב אחרות. הסביבות האלה יכולות להיות מקומיות או בענן אחר. משתמשים באחת מהאפשרויות של קישוריות היברידית וקישוריות בין כמה עננים שעונות על הדרישות של העסק והאפליקציה.
הגבלת התקשורת רק לכתובות ה-IP המותרות של המקורות והיעדים. אפשר להשתמש בכל אחת מהיכולות הבאות או בשילוב שלהן:
מכשיר וירטואלי לרשת (NVA) עם יכולות בדיקה של חומת אש מהדור הבא (NGFW), שמוצב בנתיב הרשת.
Cloud Next Generation Firewall Enterprise עם שירות למניעת פריצות (IPS) להטמעה של בדיקת מנות עמוקה למניעת איומים בלי לשנות את עיצוב הרשת או הניתוב.
וריאציות
אפשר לשלב את דפוס הארכיטקטורה המשולב עם גישות אחרות כדי לעמוד בדרישות עיצוב שונות, תוך התחשבות בדרישות התקשורת של הדפוס. האפשרויות של התבניות מתוארות בקטעים הבאים:
- VPC אחד לכל סביבה
- שימוש בחומת אש מרכזית בשכבת האפליקציה
- ארכיטקטורה מבוזרת של מיקרו-שירותים עם מודל אבטחה של אפס אמון
ענן וירטואלי פרטי (VPC) אחד לכל סביבה
הסיבות הנפוצות לבחירה באפשרות של VPC אחד לכל סביבה הן:
- סביבת הענן מחייבת הפרדה ברמת הרשת של רשתות ה-VPC והמשאבים, בהתאם לעיצוב היררכיית המשאבים של הארגון.
אם נדרש הפרדה בין דומיינים אדמיניסטרטיביים, אפשר גם לשלב אותה עם פרויקט נפרד לכל סביבה.
- כדי לנהל באופן מרכזי משאבי רשת ברשת משותפת ולספק בידוד רשת בין הסביבות השונות, משתמשים בVPC משותף לכל סביבה שיש לכם ב- Google Cloud, כמו פיתוח, בדיקה וייצור.
- דרישות לגבי קנה מידה שעשויות לחרוג ממכסות ה-VPC עבור VPC או פרויקט יחיד.
כפי שמודגם בדיאגרמה הבאה, העיצוב של VPC אחד לכל סביבה מאפשר לכל VPC להשתלב ישירות עם סביבה מקומית או עם סביבות ענן אחרות באמצעות רשתות VPN, או באמצעות Cloud Interconnect עם כמה צירופים ל-VLAN.
אפשר להחיל את התבנית שמוצגת בתרשים הקודם על טופולוגיית רשת מסוג hub-and-spoke באזור נחיתה. בטופולוגיה הזו, אפשר לשתף חיבור היברידי יחיד (או כמה חיבורים היברידיים) עם כל רשתות ה-VPC מסוג spoke. הוא משותף באמצעות VPC מעבר כדי לסיים גם את הקישוריות ההיברידית וגם את רשתות ה-VPC האחרות מסוג Hub and Spoke. אפשר גם להרחיב את העיצוב הזה על ידי הוספת NVA עם יכולות בדיקה של חומת אש מהדור הבא (NGFW) ב-VPC של התעבורה, כפי שמתואר בקטע הבא, 'שימוש בחומת אש מרכזית של שכבת האפליקציה'.
שימוש בחומת אש מרכזית בשכבת האפליקציה
אם הדרישות הטכניות שלכם מחייבות בדיקה של שכבת האפליקציה (שכבה 7) ובדיקה מעמיקה של מנות עם יכולות מתקדמות של חומת אש שחורגות מהיכולות של Cloud Next Generation Firewall, אתם יכולים להשתמש במכשיר NGFW שמתארח ב-NVA. עם זאת, ה-NVA צריך לעמוד בדרישות האבטחה של הארגון. כדי להטמיע את המנגנונים האלה, אפשר להרחיב את הטופולוגיה כדי להעביר את כל התנועה בין הסביבות דרך חומת אש מרכזית של NVA, כמו שמוצג בתרשים הבא.
אפשר להחיל את התבנית שמוצגת בדיאגרמה הבאה על העיצוב של אזור הנחיתה באמצעות טופולוגיה של רכזת ו-spoke עם מכשירים מרכזיים:
כפי שמוצג בדיאגרמה הקודמת, ה-NVA פועל כשכבת אבטחה היקפית ומשמש כבסיס להפעלת בדיקת תנועה מוטבעת. היא גם אוכפת כללי מדיניות מחמירים של בקרת גישה. כדי לבדוק את זרימות התנועה ממזרח למערב ומצפון לדרום, העיצוב של NVA מרכזי עשוי לכלול מספר פלחים עם רמות שונות של אמצעי בקרה לגישה לאבטחה.
ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון למיקרו-שירותים
כשמשתמשים באפליקציות בקונטיינרים, ארכיטקטורת המיקרו-שירות המבוזרת של מודל אבטחה של אפס אמון שמתוארת בקטע תבנית משוכפלת רלוונטית גם לתבנית הארכיטקטורה הזו.
ההבדל העיקרי בין התבנית הזו לבין התבנית המשוקפת הוא שאפשר ליזום את מודל התקשורת בין עומסי עבודה ב- Google Cloud לבין סביבות אחרות משני הצדדים. צריך לשלוט בתעבורה בצורה מדויקת, על סמך דרישות האפליקציה ודרישות האבטחה, באמצעות Cloud Service Mesh.
שיטות מומלצות לשימוש בדפוסים משולבים
- לפני שעושים משהו אחר, צריך להחליט על העיצוב של היררכיית המשאבים ועל העיצוב שנדרש לתמיכה בכל פרויקט ו-VPC. הפעולה הזו יכולה לעזור לכם לבחור את ארכיטקטורת הרשת האופטימלית שתתאים למבנה של Google Cloud הפרויקטים שלכם.
- מומלץ להשתמש בארכיטקטורה מבוזרת של אפס אמון כשמשתמשים ב-Kubernetes בסביבת מחשוב פרטית וב-Google Cloud.
- כשמשתמשים ב-NVA מרכזיים בתכנון, צריך להגדיר כמה פלחים עם רמות שונות של אמצעי בקרת גישה לאבטחה ומדיניות בדיקת תנועה. אמצעי הבקרה והמדיניות האלה צריכים להתבסס על דרישות האבטחה של האפליקציות שלכם.
- כשמתכננים פתרון שכולל מכשירי NVA, חשוב לקחת בחשבון את הזמינות הגבוהה (HA) של מכשירי ה-NVA כדי להימנע מנקודת כשל יחידה שעלולה לחסום את כל התקשורת. פועלים לפי ההנחיות לתכנון ולהטמעה של זמינות גבוהה ויתירות שסופקו על ידי ספק האבטחה שלGoogle Cloud שסיפק את מכשירי ה-NVA.
- כדי לשפר את הפרטיות, את תקינות הנתונים ואת מודל התקשורת המבוקר, כדאי לחשוף את האפליקציות באמצעות ממשקי API עם שערים של API, כמו Apigee ו-Apigee hybrid עם mTLS מקצה לקצה. אפשר גם להשתמש ב-VPC משותף עם Apigee באותו משאב ארגון.
- אם הפתרון שלכם מחייב חשיפה של אפליקציה מבוססת Google Cloud לאינטרנט הציבורי, כדאי לעיין בהמלצות התכנון שמופיעות במאמר Networking for internet-facing application delivery.
- כדי להגן על השירותים בפרויקטים שלכם ולצמצם את הסיכון לזליגת נתונים, אתם יכולים להשתמש ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות ברמת הפרויקט או ברמת רשת ה-VPC. Google Cloud בנוסף, אפשר להרחיב את היקף השירות לסביבה היברידית באמצעות VPN או Cloud Interconnect מורשים. מידע נוסף על היתרונות של גבולות גזרה לשירות זמין במאמר סקירה כללית על VPC Service Controls.
- כדאי לעיין בשיטות המומלצות הכלליות בנושא תבניות של רשתות היברידיות ורשתות מרובות עננים.
אם אתם רוצים לאכוף בידוד מחמיר יותר וגישה מפורטת יותר בין האפליקציות שלכם שמארחות ב- Google Cloudלבין סביבות אחרות, כדאי להשתמש באחד מדפוסי הגישה המוגבלת שמתוארים במסמכים האחרים בסדרה הזו.