آیا برای Apple MDM به VPN نیاز دارید؟ سه نیاز دسترسی، یک پاسخ
Apple MDM روی APNs و HTTPS که خود دستگاه آغاز میکند کار میکند، نه روی تونل LAN. پیش از افزودن VPN، مدیریت، اشتراک صفحه و دسترسی به برنامههای خصوصی را جدا کنید.
این پرسش بهندرت درباره این است که آیا مدیریت دستگاههای Apple به رمزنگاری نیاز دارد، چون نیاز دارد. پرسش واقعی این است که آیا ناوگان شما پیش از آنکه بتوان یک Mac یا iPad را اصلاً مدیریت کرد به یک 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 پاسخ درست است
ناوگانی وجود دارد که در آن نقطه پایانی مدیریت هرگز نباید از اینترنت دسترسیپذیر باشد، و این یک طراحی مشروع است نه کمبود جسارت. محیطهای تحت نظارت، تیمهای کوچک فناوری اطلاعات داخلی و سرورهایی که میزبان رابطهای مدیریتی دیگر هم هستند اغلب به آنجا میرسند. در این حالت یک مسیر دسترسی محافظتشده در مقابل سرویس مدیریت معماری آگاهانه است، نه یک راهحل موقت.
اشتراک صفحه و دسترسی به برنامههای خصوصی معمولاً به آن سمت خط هم تعلق دارند. هر دو بسیار بیشتر از یک کانال فرمان را آشکار میکنند، و هر دو شایسته احراز هویت خودشان هستند بهجای سواری بر هویت ثبت.
تله راهاندازی که بازیابی را میشکند
این همان خرابی است که برای مقابله با آن طراحی میکردم: تنها مسیر به سرویس مدیریت از VPN میگذرد، و پروفایل یا اعتبارنامه VPN روی دستگاه منقضی شده است. دستگاه نمیتواند به سرور برسد تا فرمان جایگزین بگیرد، و سرور نمیتواند چیزی را از تونلی که بالا نمیآید عبور دهد. بازیابی اکنون به کاربری وابسته است که ممکن است صدها مایل دورتر باشد.
یک مسیر دوم و مستقل برای بازیابی نگه دارید، چه کانال مدیریت خارج از باند باشد، چه مدیر محلی، چه سرویس مدیریتی که بدون تونل دسترسیپذیر میماند. آن را وقتی همه چیز کار میکند آزمایش کنید، چون در زمان یک حادثه آزمون پاکی نخواهید داشت.
سپس بنویسید هر مسیر به کدام یک از سه نیاز خدمت میکند، و هدایت پورتهایی را که به هیچکدام خدمت نمیکنند حذف کنید. ناوگانی که بدون یک تونل عمومی مدیریت میشود و هنوز وقتی تونل همان چیزی است که شکسته قابل تعمیر است، نتیجهای است که ارزش طراحی برای آن را دارد.