שני VPN בבת אחת? הגדירו קודם את גבול נקודת הקצה

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

התחילו מהעבודה בפועל: אילו משאבים בכל רשת האדם צריך, והאם שני בעלי הרשתות מתירים גישה בו-זמנית ממכשיר אחד?

בדקו מי מתיר את החפיפה

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

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

אל תתייחסו לשני ממשקים כאל נתב

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

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

התייחסו לנקודת הקצה גם כאל נקודת גישה

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

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

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

בחרו את גבול העבודה שמתאים למודל האיומים

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

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

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

כתבו את האישור כמשימה, לא כסיסמה

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

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

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