משתמש Mac רגיל עם VPN מנוהל: מה מחלקת ה-IT חייבת לקחת על עצמה

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

שלושה מסלולי מסירה ומה כל אחד מכריע

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

scutil --nc list
sudo profiles show -type configuration
system_profiler SPConfigurationProfileDataType

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

החליטו לפי בעלות על המכשיר, לא לפי ותק

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

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

הפרידו את הפרופיל מהחשבון

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

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

מסרו בלי סיסמת מנהל

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

scutil --nc start "Acme VPN"
scutil --nc status "Acme VPN"
log show --predicate 'subsystem == "com.apple.networkextension"' --last 10m

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

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

היכנסו כמשתמש רגיל ואז כתבו את היציאה

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

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