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