האם צריך VPN ל-Apple MDM? שלושה צורכי גישה, תשובה אחת
Apple MDM פועל על APNs ועל HTTPS שהמכשיר יוזם, לא על מנהרת LAN. הפרידו בין ניהול, שיתוף מסך וגישה לאפליקציות פרטיות לפני שמוסיפים VPN.
השאלה היא לעתים רחוקות אם ניהול מכשירי Apple זקוק להצפנה, כי הוא זקוק לה. השאלה האמיתית היא אם הצי שלכם זקוק ל-VPN כללי לפני שאפשר בכלל לנהל מק או אייפד, וברוב הפריסות המנוהלות דרך האינטרנט התשובה היא לא. Apple מאפשרת למכשיר להגיע לשירות ניהול לפי לוח הזמנים שלו, והתעבורה שחשובה היא ערוץ פקודות חתום, לא הפעלת שולחן עבודה. אם זה יעבוד אצלכם תלוי בשלושה תנאים, וקל להתבלבל ביניהם כי מבחוץ כולם נראים כמו גישה מרחוק.
תנו שם לצורך לפני שבוחרים אמצעי העברה
פקודות ניהול ופרופילי תצורה הם צורך אחד, שיתוף מסך אינטראקטיבי הוא צורך שני, והגעה לאפליקציה פנימית פרטית היא צורך שלישי. יש להם בעלים שונים, אימות שונה, ולעתים קרובות חשיפה מקובלת שונה מאוד. ערבוב שלהם יחד הוא הדרך שבה צי מגיע לרשימת פורטים ציבורית שאיש לא יכול להגן עליה.
שלושת הצרכים אינם חולקים אמצעי העברה אחד:
| Need | What actually carries it |
|---|---|
| Management commands and profiles | The enrolled device pulls from a service it can reach; APNs only wakes it |
| Interactive screen sharing | A remote-support tool or private desktop path with its own authentication |
| Private application access | That application's permitted network path, which may well be a VPN |
הבלבול מתחיל בדרך כלל ברשימת בדיקה ישנה של שרת. מסמך היסטורי של OS X Server מפרט סט ארוך של פורטים, ומישהו מעביר את כולם בקצה כי שירות הניהול נמצא אי שם בפנים. זו אינה ארכיטקטורת ניהול, והיא מרחיבה את המשטח החשוף הרבה מעבר למישור הבקרה שניסיתם לפרסם.
מה בעצם עושה התראת ה-push
בזרימה המתועדת של Apple, שרת הניהול שולח התראת APNs כדי לומר למכשיר שמחכה לו עבודה. לאחר מכן המכשיר פותח חיבור לשרת הניהול ומבקש את הפקודות שלו. ה-push הוא פעמון דלת, לא מנהרה: הוא אינו נושא מטען שרירותי, לא הפעלת שולחן עבודה מרחוק, ולא תעבורה של אפליקציה אחרת.
לכן המכשיר חייב להיות רשום בשירות המיועד, לבטוח בנקודות הקצה הצפויות, ולהצליח להגיע גם לשירות הניהול וגם לשירותי Apple שהזרימה תלויה בהם. ההנחיה של Apple להכנת הרשת מפרטת את התלויות האלה, והן אינן חלקים ניתנים למשא ומתן בזרימה. שרת ניהול שקיים רק בתוך הרשת שלכם עדיין זקוק לנתיב נתמך שהמכשיר יכול באמת להשתמש בו. לקרוא לזה MDM לא הופך נקודת קצה בלתי נגישה לנגישה.
השאירו את הנתיבים המותרים מפורשים, כולל כל מדיניות פרוקסי ובדיקת TLS שנמצאת באמצע. מכשיר בדיקה ששובר את שרשרת האישורים הצפויה ייראה בדיוק כמו רישום שבור.
כשה-VPN הוא התשובה השגויה
אם שירות הניהול שלכם מפורסם באינטרנט עם אישור תקין והמכשיר יוזם כל חיבור, VPN מוסיף קפיצה בלי להוסיף שליטה. המכשיר כבר מאמת את עצמו עם זהות הרישום שלו, והשרת כבר מחליט אילו פקודות יקבל. מנהרה מול זה משנה את נתיב הרשת, לא את החלטת האמון.
אותו מישור בקרה יכול גם לספק את פרופיל ה-VPN עצמו. הסדר הזה חשוב: תצורת VPN מנוהלת מגיעה כסתם מטען נוסף, כך שהמכשיר לא צריך שהמנהרה תתקיים לפני שהוא מקבל את הפרופיל שיוצר אותה.
כשה-VPN הוא התשובה הנכונה
יש ציים שנקודת הקצה של הניהול שלהם לא אמורה להיות נגישה מהאינטרנט לעולם, וזו תכנון לגיטימי ולא חוסר אומץ. סביבות מפוקחות, צוותי IT פנימיים קטנים ושרתים שמארחים גם ממשקי ניהול אחרים מגיעים לשם לעתים קרובות. במקרה כזה נתיב גישה מוגן מול שירות הניהול הוא ארכיטקטורה מכוונת, לא פתרון עוקף.
שיתוף מסך וגישה לאפליקציות פרטיות שייכים בדרך כלל גם לצד הזה של הקו. שניהם חושפים הרבה יותר מערוץ פקודות, ושניהם ראויים לאימות משלהם במקום לרכוב על זהות הרישום.
מלכודת האתחול ששוברת את השחזור
הנה התקלה שמולה הייתי מתכנן: הנתיב היחיד לשירות הניהול עובר דרך VPN, ופרופיל ה-VPN או האישור במכשיר פג תוקף. המכשיר לא יכול להגיע לשרת כדי לאסוף פקודת החלפה, והשרת לא יכול לדחוף דבר דרך מנהרה שלא תעלה. השחזור תלוי כעת במשתמש שאולי נמצא מאות קילומטרים משם.
השאירו נתיב שני ובלתי תלוי לשחזור, בין אם ערוץ ניהול מחוץ לרצועה, מנהל מקומי, או שירות ניהול שנשאר נגיש בלי המנהרה. בדקו אותו כשהכול עובד, כי בזמן תקלה לא תקבלו בדיקה נקייה.
אחר כך כתבו איזה משלושת הצרכים כל נתיב משרת, והסירו את העברות הפורטים שלא משרתות אף אחד מהם. צי שאפשר לנהל בלי מנהרה כללית, ושעדיין אפשר לתקן כשהמנהרה היא הדבר שנשבר, הוא התוצאה ששווה לתכנן עבורה.