רכזו גישת VPN של שותפים בלי לאחד את השותפים

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

התחילו בחוזה שכל שותף כבר חתם עליו

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

הרשומה הזו היא התוצר. אם אינכם יכולים לכתוב אותה עבור שותף אחד, אותו שותף אינו מוכן לריכוז.

נתבו לפי הקשר, לא רק לפי יעד

שני שותפים ישתמשו בסופו של דבר באותו טווח פרטי, כי כל ארגון בוחר מאותו מרחב RFC 1918. טבלת ניתוב רגילה אחת אינה יכולה לבחור את השותף הנכון רק לפי כתובת יעד, ולכן טווחים חופפים זקוקים להקשרי ניתוב נפרדים או לתכנון אחר מוסכם. מודל דומיין ההעברה ב־RFC 4364 מסביר למה ההפרדה הזו חשובה, ופריסה אינה חייבת להריץ MPLS כדי לדרוש את אותה תכונה מפלטפורמת השער שלה.

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

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

החליטו מה העובד מקליד ומה השותף רושם

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

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

אסרו במפורש מעבר בין שותפים

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

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

הפעילו את זה כשירות משותף, לא כמחשב נייד גדול יותר

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

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

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