Mac VPN On Demand: מה באמת מוכיח התאמת SSID?
התאמת SSID היא תנאי של כלל, לא הוכחה לאמון. בנו את כלל On Demand, בחרו את ברירת המחדל לרשתות לא מוכרות והשאירו את החסימה בנפרד.
חיבור ה-VPN בכל מקום מלבד ה-Wi-Fi של המשרד נשמע כמו מדיניות של שתי שורות, והחלק הקשה מעולם לא היה זיהוי שם רשת. החלק הקשה הוא להחליט מה שם תואם רשאי להוכיח. כל נקודת גישה יכולה לשדר SSID מוכר, ופינג מוצלח לכתובת אחת מוכיח רק שבדיקה אחת קיבלה תשובה. אף אחת משתי התצפיות אינה מוכיחה שה-Mac נמצא ברשת פנימית מאומתת.
שם אינו זהות
SSID הוא תווית שרדיו משדר. הוא אינו מפתח, תעודה או הצהרה על הבעלות על החומרה, ומקום אירועים או משרד שכן יכול לשדר את אותה מחרוזת בלי שום תיאום. התייחסות לתווית כהוראה לכבות את ההגנה מוסרת את ההחלטה למי שהגדיר את נקודת הגישה הקרובה.
בדיקת הפינג נכשלת מסיבה עדינה יותר: היא עונה על שאלה של נגישות, לא של שייכות. יעד שמגיב עשוי להיות נגיש מכל מקום, עשוי להיות נגיש רק דרך המנהרה שעליה אתם מנסים להחליט, או עשוי להיות פורטל לכידה שמחזיר משהו שנראה כמו תשובה. נגישות היא עובדה שימושית וגבול אמון גרוע.
כיצד On Demand מעריך סט חוקים
מודל On Demand של Apple מצמיד פעולה לתנאי רשת אופציונליים, והחוקים מוערכים לפי סדר: החוק הראשון שכל תנאיו מתאימים מספק את הפעולה, והשאר אינם נבדקים. הסדר הזה הוא המדיניות, ולכן חוק שמתווסף «ליתר ביטחון» יכול לשכתב בשקט התנהגות שעבדה.
תנאי SSID מתייחס לרשת המחוברת הראשית הנוכחית, לא לכל שם שנראה בסריקה. זה יוצר שלושה מצבים נפרדים, ולכווץ אותם לשניים זו טעות התצורה הרגילה:
| State | What the rule sees | What it must not be taken to mean |
|---|---|---|
| No SSID criterion applied | Nothing to compare | That the network is unknown or unsafe |
| Unknown network | Connected, name does not match | That no rule below applies |
| Recognized network | Primary network matches | That the network is trusted |
הגדירו אותו במקום שבו המדיניות נמצאת
לקוח VPN מאושר או זרימת עבודה ניהולית הם המקום שאליו שייך החוק הזה, וספקים שונים חושפים תת-קבוצות שונות של הבקרות הזמינות. אפשרות חסרה בפאנל הזה פירושה אפוא שהלקוח לא חשף אותה, ולא שהפלטפורמה אינה יכולה לבטא אותה.
הפעלה אוטומטית זקוקה גם להסדר אימות שיכול להסתיים בלי אדם, כגון תעודה או שיטה נתמכת אחרת. קוד חד-פעמי מאוחסן אינו ההסדר הזה, וחוק שמופעל בזמן שהאימות אינו יכול להסתיים מייצר ניסיון חיבור שנכשל בשקט ברקע.
שני דפוסים שכדאי לכתוב ב-runbook
הראשון הוא השם המחקה. מקום כנסים, מלון או שוכר באותו בניין משדר את המחרוזת שהחוק שלכם מתייחס אליה כ«פנים», וההגנה נכבית בדיוק במקום שבו הייתם רוצים אותה הכי פחות. השם לא שיקר; החוק שאל אותו שאלה שהוא אינו יכול לענות עליה.
השני הוא הבדיקה שמביסה את עצמה. סקריפט עושה פינג לכתובת פרטית, רואה תשובה דרך המנהרה, מסיק שהוא כבר ברשת הפנימית ומתנתק. אז הבדיקה נכשלת, ולכן הסקריפט מתחבר מחדש וחוזר, והמנהרה מתנדנדת בזמן שכל צעד בודד נראה נכון. בדיקה שתוצאה שלה תלויה במנהרה אינה יכולה גם להחליט אם המנהרה צריכה להתקיים.
החליטו על ברירת המחדל ואכפו אותה בנפרד
מקרה הרשת הלא מוכרת ומקרה הכבל צריכים תשובות מפורשות ולא ברירת מחדל בירושה. אם תעבורה מוגנת חייבת להישאר חסומה בזמן שהמערכת עדיין מסווגת את הרשת או מעלה את המנהרה, זה דורש בקרת אכיפה נתמכת משל עצמה; טריגר On Demand מספק התנהגות חיבור, לא ערובה לחסימה.
כשהחוק של המנהל כתוב כראוי, הוא מציין את החריגה המאושרת, את הראיות שמצדיקות אותה ואת הנסיגה המכוונת כשהראיות האלה חסרות. זיהוי שם Wi-Fi הוא קלט לגיטימי להחלטה הזו. הוא אינו ההצדקה להחלטה, ולעולם לא צריך להיות השורה היחידה בחוק.