מדיניות הקבוצה של NPS אינה אכיפת משאבי VPN

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

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

מצאו את המדיניות שבאמת קיבלה את הסשן

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

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

תשובת RADIUS היא הוראה, לא מסנן

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

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

שימו את האכיפה במקום שבו עוברת התעבורה

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

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

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

פרופילי לקוח חיים בצד שאינו מהימן

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

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

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

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

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