VPN רב-דיירים: שער משותף, לפי דייר או לפי מארח
מנהרה אינה בידוד בין דיירים. השוו שער משותף, שערים לפי דייר וחיבורים לפי מארח מבחינת מיפוי זהויות, ניתוב והוצאה משירות.
החליטו מי מקבל לקוח ומה מונע מאותו לקוח להגיע למשאבים של דייר אחר. אלה שתי החלטות, ובחירה ב-IPsec, WireGuard או מוצר mesh לא עונה על אף אחת מהן. מנהרה שעולה בצורה מושלמת יכולה עדיין להשאיר כל דייר מסוגל להגיע לכל האחרים, וסקירה שמתייחסת לשניים כדבר אחד מאשרת את העיצוב הלא נכון. כתבו תחילה את מפת הלקוח אל המשאב: מנהלים, גישת תמיכה, שירותים משותפים והנתיבים שחייבים להישאר אסורים.
התחילו במפה, לא במוצר
המפה הזו היא התוצר הראשון, וכל בחירה בהמשך היא רק החלטה היכן חי הגבול שאוכף אותה. שמרו אותה ניתנת לסקירה: שורה אחת לכל לקוח, שורה אחת לכל שירות משותף והנתיבים האסורים כתובים.
מפה שאיש אינו יכול לקרוא היא מפה שאיש לא יאכוף.
נקודת קבלה אחת ובעיית המיפוי שלה
כל מיקום מוכרע בשאלה תפעולית אחת, והטבלה היא כל ההשוואה.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
שער משותף מרכז את הקבלה ומרכז את הסיכון במקום אחד: הקשר בין זהות הדייר לבין המדיניות שלו. קבוצות או כתובות מנהרה חייבות להתפרש להרשאות המשאב הנכונות, ותווית שונה לכל לקוח אינה מונעת דבר כשלעצמה. הקשרי ניתוב נפרדים יכולים להחזיק קידומות חופפות כאשר הפלטפורמה תומכת בכך והעיצוב שלם. טבלת ניתוב משותפת רגילה אינה יכולה להבחין בין שתי קידומות יעד זהות רק מפני שלאנשים שמאחוריהן יש חשבונות שונים.
זהו המבחן לרוב העיצובים. שני דיירים שמספרים פנימית עם 10.0.0.0/8 זקוקים למצב ניתוב נפרד, לא למוסכמת שמות.
שער לכל דייר קונה גבולות ומערכות
שער אחד לכל לקוח הופך כמה גבולות מנהליים לקלים להסבר, מפני שהקבלה והמדיניות של אותו לקוח יושבות יחד. הוא גם מכפיל את המערכות שזקוקות לאישורים, לתיקונים, לניטור ולבעלים. והוא אינו כופה סידור מוכתב אחד של כתובות ציבוריות: שיתוף נקודות קצה, תרגום ופירוק ריבוב פרוטוקולים תלויים במה שהמימוש באמת תומך בו.
ספרו את המערכות ואת האנשים לפני שתספרו את הרווח הביטחוני. עיצוב עם ארבעה שערים יותר ממה שהצוות יכול לתקן אינו מבודד יותר בפועל.
אם מספר הדיירים משתנה בכל חודש, המודל הזה זקוק לסיפור אוטומציה ולא לתבנית.
חיבורים לכל מארח מעבירים את העבודה
חיבור בכל מכונה מתארחת אינו מסיר את העבודה התפעולית, הוא מעביר אותה למחזור החיים של המכונה. הרשמה, מדיניות לכל מכונה, סבב מפתחות והחלפה הופכים לחלק מההקצאה, והם נכשלים באותו חלון כמו המכונה עצמה. עבור קומץ מארחים ארוכי חיים ברשתות נפרדות זה לרוב נכון, ועבור צי שכבר איבד את המעקב אחרי איזו תמונת מערכת פועלת איפה, לעתים רחוקות.
תנו שם לתפקיד להנפקת זהות, לעדכונים, להסרת גישה, לניטור ולשחזור בכל אפשרות. אחר כך שאלו מה קורה ביום שבו לקוח אחד עוזב.
הוצאה משירות שייכת להשוואה
רוב ההשוואות מדלגות על ההוצאה משירות. הסרת דייר צריכה לבטל את האישורים שלו, להפיל את המדיניות שלו, לשחרר את הכתובות ומצב הניתוב שלו ולהשאיר את כל האחרים ללא פגע. הנחיות הארכיטקטורה של אמון אפס של NIST הן ההפניה הנכונה כאן, מפני שהן שמות אימות והרשאה על המשאב במקום לסמוך על מיקום ברשת, וזה חל גם בתוך המקטע של הלקוח עצמו.
שקלו זרימות מותרות ואסורות, טיפול בכתובות חופפות ואת נוהל ההוצאה משירות לפני שתשקלו מדדי פרוטוקול. אחר כך בחרו תעבורה ושיטת אימות שמתאימות לגבול שבחרתם. שם מוצר ישן יותר, או הטענה שכל עסק חייב לתקנן על פרוטוקול אחד, אינו מכריע דבר מזה. המפה שכתבתם ראשונה כן.