VPN ב-iPad בלי בקשות סיסמה: אישורים או התחברות שמורה
סיסמה שמורה ואישור מכשיר מסירים את הבקשה בדרכים שונות. השוו ביניהם, ואז החליטו בנפרד מה פותח את המנהרה.
«תפסיק לשאול אותי סיסמה» בעצם מאחד שלוש דרישות בתלונה אחת, ופריסה ב-iPad עונה להן במקומות שונים. הבקשה מגיעה מהאימות, התזמון מההפעלה והכיסוי מהאכיפה. תחילה בחרו את פרטי ההתחברות שמסירים את הבקשה, ואז החליטו בנפרד מה קובע מתי המנהרה נפתחת. ערבוב שתי ההחלטות האלה הוא בדיוק מה שמשאיר סיסמה שמורה בפרופיל שעדיין ממתין לנגיעה.
| Saved or shared secret | Device certificate | |
|---|---|---|
| What the user sees | no prompt while the credential stays valid | no prompt, no password to rotate |
| What the admin manages | the secret in the profile and its distribution | enrollment, expiry and revocation per device |
| Typical failure | gateway demands a second factor | expired or revoked certificate |
שתי בעיות בתלונה אחת
תצורת IKEv2 מקורית ב-iPad יכולה להפנות לסיסמה או לאישור, והמפתח AuthenticationMethod קובע איזה מהם חל, בעוד PayloadCertificateUUID נוקב בשם פרטי ההתחברות שמספקים את הזהות. איזה מהם השער יקבל היא שאלה של מדיניות שרת ולא של העדפת לקוח. לכן הדבר הראשון שיש לקבוע הוא מה שירות ה-VPN מתיר, כי iPad לא יכול לנהל משא ומתן לעבר שיטה שהצד השני דוחה.
רק אחרי זה יש טעם לדבר על מתי המנהרה מופעלת, וזו קבוצה אחרת לגמרי של מפתחות פרופיל.
אפשרות ראשונה: פרטי התחברות שה-iPad יכול לעשות בהם שימוש חוזר
סיסמת חשבון שמורה או סוד משותף מספקים שער שמאמת את המשתמש או את הקבוצה, והם מסירים את הבקשה כל עוד הסוד תקף. החולשה היא מחזור החיים: הסוד יושב בפרופיל, כמה מכשירים יכולים לחלוק אותו, והחלפתו מחייבת לגעת בכל פרופיל שנושא אותו. אם השירות דורש גם גורם חד-פעמי או אישור אינטראקטיבי, אין הגדרה מקומית שהופכת את המדיניות הזאת להתחברות ללא השגחה.
סיסמה שנשמרה באפליקציה אחת אינה זמינה אוטומטית למימוש VPN אחר, ולכן אותו חשבון יכול להפסיק לשאול בלקוח אחד ולשאול בכל פעם בלקוח אחר.
אפשרות שנייה: אישור מכשיר עם מפתח משלו
אישור מסיר את הבקשה בדרך חזקה יותר, כי ה-iPad מוכיח בעלות על מפתח פרטי במקום לשחזר סוד. זה מחייב שאישור העלה והמפתח שלו יגיעו דרך נתיב ההרשמה המאושר, ושהשער יקבל אימות באמצעות אישור לאותה התחברות. ייבוא של אישור CA בלבד נותן למכשיר חומר אמון ולא דבר אחר, וזה כשל נפוץ ושקט.
המחיר הוא עבודת מחזור חיים. כל iPad מקבל זהות משלו כדי שאפשר יהיה לבטל מכשיר שאבד בלי להנפיק מחדש את כל הצי, ותאריכי התפוגה הופכים לאירועים תפעוליים אמיתיים. אישור שפג בשקט נראה בדיוק כמו תקלת VPN בבוקר שבו זה קורה.
בחרו לפי מה שהשער מקבל, לא לפי העדפה
שאלו את מנהל ה-VPN שתי שאלות: אילו שיטות אימות השירות מקבל לסוג הלקוח הזה, והאם אחת מהן דורשת קלט אינטראקטיבי. אם התשובה היא אישור בלבד, תכננו הרשמה וחידוש. אם התשובה היא סיסמה בתוספת גורם שני, קבלו שהבקשה היא מדיניות והפסיקו להתייחס אליה כתקלת מכשיר. אם שתיהן מתקבלות, האישור מנצח במחזור החיים עבור צי מפוקח והסיסמה מנצחת במאמץ ההתקנה עבור קומץ מכשירים.
רשמו את השיטה שנבחרה ברשומת הפריסה לצד מזהה הפרופיל, אחרת האדם הבא שיגע בפרופיל יבחר באחרת.
אחר כך הפרידו בין הפעלה לאימות
VPN On Demand פותח את המנהרה כשתנאי מוגדר מתאים, בין אם זה דומיין DNS, סוג ממשק או רשת מחוברת, ו-Apple מתעדת זאת כדורש ללא אינטראקציית משתמש. זה מתאים למשאבים פרטיים שאמורים להיות נגישים רק כשמשהו מבקש אותם. זה לא אותו דבר כמו Always On מנוהל, ששומר על כיסוי נאכף ומגיע עם דרישות פיקוח ופרופיל משלו.
פרטי התחברות שעובדים לא עושים דבר לשני המקרים. iPads רבים מחזיקים אישור תקין לגמרי ובכל זאת ממתינים לנגיעה ידנית כי אף כלל לפי דרישה לא הופעל מעולם.
מסרו את הדרישה בצורה שמנהל יכול לפעול לפיה: ה-iPad הזה צריך להגיע למשאבים האלה בלי קלט חוזר של משתמש, עם סוג פרטי ההתחברות הזה, ותחת כללי ההפעלה והתקלה האלה. אם השירות הנוכחי לא יכול לעמוד בתנאים האלה, בקשות חוזרות הן המדיניות שפועלת כמתוכנן.